Kubernetes API Deprecation Checker

Paste your manifests, pick the version you are upgrading to, and see what stops working. Removed APIs, the field changes that come with them, and the renamed labels that leave a pod Pending with no useful event.

Only the versions where something was actually removed are listed. The table covers removals through 1.32.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Check. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

extensions/v1beta1 Ingress

An API version removed in 1.22, and what it became

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: web

A current manifest

What a manifest already on supported API versions looks like

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Waiting for the deprecation warning to become an error

    A removed API returns a hard error at apply time, and the removal lands in a minor upgrade. A cluster upgrade then fails a deploy that worked the day before.

    Instead:Check manifests against the target version BEFORE upgrading, which is what this page is for.

  2. Assuming Helm charts are already updated

    A chart pinned to an old version can carry a removed apiVersion, and helm template shows it only when rendered.

    Instead:Render the chart and check the output, not the values file.

  3. Trusting kubectl convert

    It was removed as a built-in in 1.20 and the plugin does not cover every conversion, particularly where fields have no equivalent.

    Instead:Read the migration notes for the specific resource. Some conversions genuinely change behaviour.

What it catches

All of it is readable from the manifests. None of it is reported by anything at the point you would want to hear it.

Already broken, and breaks later, are different problems

Pick a target version and the report separates the objects that cannot be created on it from the ones that still work and stop working on a later upgrade. The first is a failed deploy today; the second is a planned piece of work. Reporting them at the same severity is how the urgent one gets lost.

The field changes an apiVersion bump does not fix

Moving an Ingress to networking.k8s.io/v1 also means pathType on every path and a backend under service.name, or the object is rejected. An HPA needs its metric targets restructured. A CertificateSigningRequest needs a signerName. Each is checked separately, because a one-line change that leaves a manifest unapplyable is worse than no change.

The migration that changes behaviour without changing a line

A PodDisruptionBudget with an empty selector matched no pods under policy/v1beta1 and matches every pod in the namespace under policy/v1. The same three characters go from inert to blocking every node drain in that namespace. Nothing about the migration flags it, and the first symptom is an upgrade that will not finish.

What it cannot see, said out loud

This reads apiVersion and kind pairs plus a fixed list of fields, annotations and renamed node labels. It is not schema validation, it does not know your cluster version, and it covers removals through 1.32. kubent and pluto read a live cluster and Helm release history, which catches what is running but not in your repository, and the report says so.

How an API removal actually reaches you

Nothing warns you at the moment it matters. A removed API is not a deprecation notice on apply, it is an object the API server has never heard of, and the error reads like a typo.

The error names the kind, not the version

This is why an upgrade breaks a deploy that has not been touched in two years and the message sends people looking for a spelling mistake. The API server is not refusing the object, it is refusing the group and version, and it says so in a way that puts the kind first.

kubectl apply -f cronjob.yaml

error: unable to recognize "cronjob.yaml": no matches for
kind "CronJob" in version "batch/v1beta1"

the manifest is fine. batch/v1beta1 went in 1.25.

Deprecated and removed are years apart

An API is deprecated for at least three releases before it is removed, and during that window everything works normally. Beta APIs get a deprecation warning in the kubectl output, which is exactly where nobody reads it in CI. The gap is long enough that whoever wrote the manifest has usually moved on.

batch/v1beta1 CronJob
  deprecated  1.21   April 2021
  removed     1.25   August 2022

policy/v1beta1 PodSecurityPolicy
  deprecated  1.21
  removed     1.25   and nothing replaced it

The apiVersion line is rarely the whole change

Some migrations are one line. Several are not, and the ones that are not fail after the change rather than before it, which is the worse order. An Ingress is the common case: four separate things moved between the beta and v1.

# extensions/v1beta1
spec:
  backend:                    -> spec.defaultBackend
  rules:
    - http:
        paths:
          - path: /
                                -> pathType now required
            backend:
              serviceName: api  -> backend.service.name
              servicePort: 80   -> backend.service.port.number

Storage version, and why an old object can still be there

Changing your manifest does not change what is stored. Objects created under an old version stay written in etcd under it until something rewrites them, which is why an upgrade can fail on an object nobody has applied for years. Reading and re-applying every affected object is the step people skip.

kubectl get <kind> -A -o yaml | kubectl apply -f -

# or, more carefully, one kind at a time. This is what
# kubent and pluto find that a repo scan cannot: objects
# that exist in the cluster and in no file you have.

Related kubernetes tools

Kubernetes API Version Checker Will this apply on that cluster Kubernetes Service Checker Will this Service have any endpoints? Kubernetes Ingress to Gateway API Which annotations silently stop working Kubernetes YAML Generator Answer a few questions, get a manifest Kubernetes YAML Validator Is this YAML valid, and where is it wrong? Kubernetes Rollout & Probe Timing Restart loops, capacity dips and stuck drains
All 55 kubernetes tools

Elsewhere on the site

Terraform Validator & Formatter AWS IAM Policy Validator & Analyzer Docker Container Image Reference Parser VPC Subnet & CIDR Calculator