Introduction

The error deployment.extensions not found usually means your manifest or command is referring to an old Kubernetes API group that no longer serves Deployments. Modern clusters expose Deployment resources under apps/v1, so anything that still asks for extensions is using an outdated API version.

Why This Error Happens

In older Kubernetes releases, Deployments were available under extensions/v1beta1. That API was deprecated and later removed. When a newer cluster sees a request for deployment.extensions, it cannot resolve that resource anymore, so it returns a not-found style error.

This appears in a few common places:

• old YAML manifests with apiVersion: extensions/v1beta1
• Helm charts or templates written for older clusters
• shell commands that explicitly request the extensions API group

The fix is usually simple: update the resource definition to apps/v1 and make sure the manifest matches the newer schema requirements.

Update the Manifest to apps/v1

A modern Deployment manifest looks like this:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: web
5spec:
6  replicas: 2
7  selector:
8    matchLabels:
9      app: web
10  template:
11    metadata:
12      labels:
13        app: web
14    spec:
15      containers:
16        - name: nginx
17          image: nginx:1.27
18          ports:
19            - containerPort: 80

Two details matter when migrating from older examples:

• 'apiVersion must be apps/v1'
• the selector field is required and must match the pod template labels

If the labels do not match, Kubernetes rejects the Deployment even after you fix the API version.

Verify What the Cluster Supports

If you are unsure which resource versions the cluster accepts, ask the API server directly.

kubectl api-resources | grep -i deployment
kubectl explain deployment --api-version=apps/v1

Those commands show the supported resource group and help you confirm that the cluster expects apps/v1.

If the error comes from a generated manifest, render the final YAML first and inspect it. For example, with Helm you should check the rendered output rather than only the template source.

If you are migrating a large repository, validating manifests in CI is worth the effort. A simple dry run against a recent cluster or schema validator catches removed API versions before they reach deployment time.

Updating Existing Tooling

Sometimes the problem is not a handwritten manifest. It may come from an old chart, CI template, operator, or kubectl snippet that still references extensions.

Search for stale API versions in your repository:

grep -R "extensions/v1beta1" .

Then replace them with apps/v1 and review each manifest for required selectors and any other schema differences. The API version string is often only half of the migration.

Common Pitfalls

The most common mistake is changing only the apiVersion line and forgetting the selector. Older Deployment examples sometimes omitted fields that are required in apps/v1.

Another mistake is assuming the cluster is broken because the message says not found. In this case, the issue is usually manifest compatibility, not a missing controller installation.

Be careful with generated YAML. A Helm chart may look modern at first glance, but one helper template or conditional branch can still emit the removed API group.

Finally, do not confuse Deployments with unrelated custom resources. deployment.extensions refers to the built-in Deployment kind and its old API group, not to CRDs.

Summary

• 'deployment.extensions not found means your config is using the removed Deployment API group.'
• Replace extensions/v1beta1 with apps/v1.
• Add the required selector and keep it aligned with pod template labels.
• Use kubectl api-resources and kubectl explain to confirm supported versions.
• Search templates and generated YAML for stale API references, not just handwritten manifests.