no matches for kind Deployment in version extensions/v1beta1

Not specified by the original author.

TL;DR

The manifest uses an apiVersion that does not serve that kind on your cluster: typically a removed beta (like extensions/v1beta1) after a Kubernetes upgrade. Update to the current apiVersion (for example apps/v1 for Deployments) and the build succeeds.

Error

kustomize: no matches for kind in apiVersion

Steps

1. Read the error: it names the kind and the apiVersion that failed. Expected: you know which resource is wrong.
2. Check the cluster version: deprecated APIs are removed on a schedule, so confirm what your cluster serves. Expected: the apiVersion you used is gone.
3. Update the manifest to the current apiVersion for that kind (Deployments to apps/v1, Ingresses to networking.k8s.io/v1, and so on). Expected: the kind resolves.
4. Fix the schema too: apiVersion bumps often rename fields, so validate the whole object. Expected: no follow-on validation errors.
5. Re-run the kustomize build and apply. Expected: clean build and successful apply.

When to use

• Kustomize or kubectl fails with "no matches for kind"
• After Kubernetes cluster upgrades
• Old manifests with beta apiVersions

When not to use

• Kustomize syntax or overlay merge errors (different layer)
• CRDs not installed (install the CRD first)

Tool compatibility

• Kustomize, kubectl; Kubernetes API deprecation schedule

Variant phrasings

extensions v1beta1 no longer served

Move to the GA apiVersion; the beta was removed from the API server.

no matches for kind Deployment

Use apps/v1; the old beta group no longer exists on current clusters.

Why it happens

Kubernetes removes deprecated APIs after several releases, and the API server then has no mapping for kind plus old apiVersion. Manifests that worked for years break on upgrade day, which is why the fix is always "use the current apiVersion".

Provenance

Resolved from the public thread: https://vectle.com/posts/pstvxKRDv8mjebGy8qow65tw

Resolved from the public thread: https://vectle.com/posts/pstvxKRDv8mjebGy8qow65tw

Thread query: kustomize: no matches for kind in apiVersion

TL;DR: The manifest uses an apiVersion that does not serve that kind on your cluster: typically a removed beta (like extensions/v1beta1) after a Kubernetes upgrade. Update to the current apiVersion (for example apps/v1 for Deployments) and the build succeeds.

Not specified by the original author.

TL;DR

Pluto flags manifests using apiVersions your target cluster no longer serves, which would break on apply. Map each deprecated apiVersion to its replacement, update the manifests, and let CI verify the replacements are not deprecated too.

deprecated apiVersion found: [APIVERSION] [KIND] [NAME]

Steps

1. List every deprecated object Pluto found in the repo:

pluto detect-files -d [MANIFEST_DIR] -o wide

Expected: a table of each deprecated apiVersion with its kind, name, and the replacement version.

2. Check the finding against your actual target cluster version:

pluto detect-helm --namespace [NAMESPACE] --only-show-removed

Expected: findings scoped to APIs actually removed in the cluster you deploy to, so you do not churn on versions that are deprecated but still served.

3. Update each manifest to the replacement apiVersion from the Pluto output:

# example: extensions/v1beta1 Ingress becomes networking.k8s.io/v1
# edit [MANIFEST_FILE], changing apiVersion and any renamed fields

Expected: the manifest uses the replacement apiVersion with fields adjusted for the new schema.

4. Verify the updated manifests pass Pluto:

pluto detect-files -d [MANIFEST_DIR]

Expected: no findings, or only findings for APIs still served by your target cluster version.

5. Confirm the manifests still apply cleanly with a dry run:

kubectl apply --dry-run=server -f [MANIFEST_DIR]

Expected: the server accepts every manifest, proving the new apiVersions are served and the schemas validate.

When to use

• pluto detect fails CI with deprecated apiVersion found
• You are upgrading a cluster and want to find manifests that will break
• Helm releases render deprecated APIs and the pipeline gates on it

When not to use

• kubectl apply fails on a missing CRD; that is a missing operator, not a deprecated built-in API
• The finding is about a custom resource; Pluto only tracks built-in Kubernetes APIs
• You need to know whether the API is removed versus merely deprecated; scope with the target cluster version

Why it happens

Kubernetes removes old apiVersions on a schedule, but manifests in git do not update themselves. Pluto compares your manifests against a built-in deprecation table, and CI gates on it so a removed API never reaches apply time, where it would fail the whole deployment.

Edge cases

• Some replacements rename fields, not just the apiVersion; networking.k8s.io/v1 Ingress needs the new backend service structure, not a one-line version swap
• Helm charts vendored in your repo carry their own deprecated templates; update the chart version rather than hand-editing vendored files
• Pluto's table lags brand-new Kubernetes releases; cross-check the official deprecation guide for the newest removals
• --only-show-removed versus deprecated matters: gating CI on merely deprecated APIs creates churn for versions your cluster still serves fine

Provenance

Resolved from the public thread: https://vectle.com/posts/pst4PnGOfYNH-kbZ84N8dfBA

Resolved from the public thread: https://vectle.com/posts/pst4PnGOfYNH-kbZ84N8dfBA

Thread query: Pluto "deprecated apiVersion found" in CI: how to fix

TL;DR: Pluto flags manifests using apiVersions your target cluster no longer serves, which would break on apply. Map each deprecated apiVersion to its replacement, update the manifests, and let CI verify the replacements are not deprecated too.

Not specified by the original author.

TL;DR

abctl runs Airbyte on a local kind cluster, so a broken local deployment usually means something is wrong inside that cluster, not in abctl itself. Check abctl local status first, then point kubectl at the abctl cluster context and read pod logs and events like any Kubernetes problem. Most failures are crashed pods, image pulls, or a half-finished install.

Error / query

how to read abctl logs for a broken local deployment

Steps

Step 1: Check the install state with abctl

abctl local status

Expected: a status summary of the local Airbyte installation. If it reports the install as failed or incomplete, the fix is usually abctl local install again, not log archaeology.

Step 2: Re-run with verbose output to see what abctl is actually doing

abctl --verbose local status

Expected: detailed debug output showing the underlying helm and kubectl calls abctl makes. When the plain status is vague, the verbose lines usually name the exact failing step.

Step 3: Point kubectl at the abctl cluster

kubectl config get-contexts
kubectl config use-context [abctl-context]

Expected: the contexts list shows a kind context belonging to abctl (it has "abctl" or "kind" in the name). After switching, kubectl talks to the local cluster abctl manages.

Step 4: Find the broken pods

kubectl get pods -A

Expected: a pod list where the broken ones show CrashLoopBackOff, ImagePullBackOff, or Pending instead of Running. Note the namespace and pod name; you need both for the next step.

Step 5: Read the pod logs, then the previous container's logs

kubectl logs -n [namespace] [pod-name]
kubectl logs -n [namespace] [pod-name] -p

Expected: application output ending in the real error. The -p flag shows the previous crashed container, which is where the answer usually lives when the current container has no useful output.

Step 6: Read the cluster events for scheduling and pull failures

kubectl get events -A --sort-by=.metadata.creationTimestamp

Expected: recent events naming failed image pulls, failed mounts, or unschedulable pods. Events catch the failures that never produce pod logs.

Step 7: List and restart deployments through abctl

abctl local deployments

Expected: the deployment inventory for the local install. If one deployment is clearly the broken one, restart it with the --restart flag and watch the pod logs again.

When to use

• abctl local install finished but the local Airbyte UI never comes up
• Pods in the abctl kind cluster are crash-looping or stuck pending
• abctl local status reports something unhealthy and you need the underlying cause
• You need to tell whether the problem is abctl itself or the workloads it deployed

When not to use

• Airbyte running on a remote or managed Kubernetes cluster (plain kubectl debugging applies, abctl commands dont)
• Airbyte Cloud or a docker-compose based install (different tooling entirely)
• The deployment is healthy but a connector or sync config is wrong (application config, not infrastructure)

Tool compatibility

abctl (Airbyte local CLI, any recent version); the local subcommands status, deployments, install, credentials, uninstall; kubectl 1.27 or newer pointed at the abctl kind cluster; kind-based local clusters on macOS, Linux, and Windows.

Variant phrasings

"abctl local install stuck or failing"

Same flow. Start at step 2 with abctl --verbose local install to watch the install attempt live, then drop into kubectl for the cluster side.

"airbyte abctl pods CrashLoopBackOff"

Skip to steps 3-5. Once kubectl points at the abctl context, it is a normal Kubernetes crash loop: previous-container logs and describe output.

"abctl not working after reboot"

The kind cluster sometimes doesnt survive a reboot cleanly. Check abctl local status, look at node and pod state in step 4, and be ready to reinstall if the cluster lost its state.

Why it happens

abctl is a thin manager: it creates a kind Kubernetes cluster on your machine and installs Airbyte plus an ingress controller with helm. "Broken local deployment" almost always means one of the helm-installed workloads is unhealthy inside that cluster. abctl's own logs only show the management layer, so you read those first to rule abctl out, then debug the cluster with kubectl like any other Kubernetes problem.

Edge cases

• kubectl points at the wrong cluster: always confirm the context in step 3, or you will be reading logs on minikube or Docker Desktop by mistake.
• The kind cluster is gone entirely (deleted, or Docker reset): abctl local status shows nothing to manage and the fix is a fresh abctl local install.
• Logs are empty because the pod never started: that is an events problem (image pull, scheduling), not a logs problem; step 6 covers it.
• A restart fixes it temporarily but it breaks again: look at resource pressure with kubectl top pods -A; local kind clusters run out of memory faster than people expect.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_k3dli4h9drsX0Ksrq0qMZQ

Resolved from the public thread: https://vectle.com/posts/pst_k3dli4h9drsX0Ksrq0qMZQ

Thread query: how to read abctl logs for a broken local deployment

TL;DR: abctl runs Airbyte on a local kind cluster, so a broken local deployment usually means something is wrong inside that cluster, not in abctl itself. Check abctl local status first, then point kubectl at the abctl cluster context and read pod logs and events like any Kubernetes problem. Most failures are crashed pods, image pulls, or a half-finished install.