← Back to Kubernetes Deprecated API Check
Kubernetes publishes its own Deprecated API Migration Guide, so a platform engineer can, in principle, read it and cross-check a manifest against it by eye. This page names no product or company: "reading the guide and checking by hand" is a manual habit anyone maintaining Kubernetes manifests already has, not a competing tool.
It genuinely works for a single manifest file checked right after reading the guide. It gets harder to trust the moment there is more than one file, more than one release wave to remember, or a kind that did not follow its apiVersion siblings' removal date -- which is exactly the case the table below covers.
| Case | Reading the guide and checking by hand | This tool |
|---|---|---|
| A single manifest, checked right after reading the guide | Works fine -- the guide is short enough to hold in your head for one file | Works the same way, instantly, with no re-reading required |
extensions/v1beta1 Ingress among other extensions/v1beta1 kinds | Easy to over-generalize: most extensions/v1beta1 kinds left in 1.16, but Ingress specifically stayed accepted until 1.22 | Looks up the exact apiVersion+kind pair, never the apiVersion alone, so Ingress is never misclassified against its siblings |
| A Helm chart or Kustomize overlay's rendered output | The apiVersion a reviewer needs may only exist in the final render, not the source template -- has to be re-checked after every chart bump or values change | Reads the rendered helm template / kustomize build output directly, document by document, every time |
Comparing a found removedIn release against a target upgrade version | Requires parsing and comparing Kubernetes minor versions correctly by hand for every match -- string comparison alone gets "1.9" vs "1.22" wrong | Parses and compares versions numerically every time, reporting removed versus merely deprecated |
| Re-checking a manifest repo on every dependency bump or chart upgrade | Manual, and the first step skipped under deadline pressure | CLI scans a whole render output in one pass; exits non-zero to block a CI gate |
Four of the five kinds under extensions/v1beta1 -- DaemonSet,
Deployment, ReplicaSet, NetworkPolicy -- were removed in
Kubernetes 1.16. Ingress under that same apiVersion stayed accepted for six
more releases, until 1.22, per Kubernetes' own migration guide. A reviewer who has correctly learned
"extensions/v1beta1 means the 1.16 wave" from checking the other four kinds will apply
that same rule to an Ingress manifest and get the wrong answer in either direction --
clearing a manifest that is fine for six more releases as if it were already broken, or the reverse.
This tool's table keys on the exact apiVersion+kind pair, so Ingress
carries its own removedIn value independent of its siblings.
A source Helm chart template or Kustomize base often does not name a fixed apiVersion at
all -- it can come from a chart default, be overridden in values.yaml, or be patched by an
overlay, and only becomes visible once you run helm template or kustomize build.
Checking that rendered output by eye works the first time; it is the step most likely to be skipped
after a routine chart version bump that "shouldn't have changed anything." This tool reads the same
rendered output, document by document, with no dependency on remembering to re-run the check.
This tool's table lists only removals Kubernetes has documented with a fixed release number -- it deliberately leaves out every in-progress or future-dated deprecation that has not shipped a removal release yet, and it has no cluster access, so it cannot tell you what your cluster is actually running today. Planning ahead for a still-beta deprecation, or understanding the reasoning behind a removal, is still a job for reading Kubernetes' own guide.
It tells you the facts this tool's table encodes -- Kubernetes publishes the guide and this tool's DEPRECATED_APIS table is sourced from it, not guessed. What reading it once does not do is re-check every apiVersion+kind pair in every manifest your Helm chart or Kustomize overlay renders, every time you edit one, against every release wave. That cross-referencing is the part that stops happening under time pressure, not the reading.
The guide groups removals by release, and most extensions/v1beta1 kinds (DaemonSet, Deployment, ReplicaSet, NetworkPolicy) were removed in 1.16 -- but Ingress under the same apiVersion stayed accepted for six more releases, until 1.22. A hand-check that remembers "extensions/v1beta1 was the 1.16 wave" and applies that to every kind under it will wrongly clear an Ingress manifest that is actually fine until 1.22, or wrongly flag it as already broken. This tool looks up the exact apiVersion+kind pair, never the apiVersion alone.
A Helm chart or Kustomize overlay can render dozens of documents across many templated files, and the apiVersion a reviewer needs to check is not always in the source template -- it can be set by a chart default, a values override, or a Kustomize patch, and only appears in the final helm template / kustomize build output. Reading the rendered output document by document, correctly, every time a chart version or values file changes, is the step a hand-check skips first under deadline pressure.
Yes, in principle: find each apiVersion+kind pair's removedIn release in the guide, then compare it against the target version you plan to upgrade to. In practice this means correctly parsing and comparing Kubernetes minor versions (is 1.22 before or after 1.9? -- string comparison gets this wrong) for every match, by hand, across every manifest. This tool does the version comparison the same way every time and reports removed versus merely deprecated-but-still-accepted.
This tool's table only lists removals Kubernetes has documented with a fixed release number -- it deliberately excludes in-progress or future-dated deprecations that have not shipped a removal release yet. If you want to plan ahead for a deprecation that is still beta, or want the full context and rationale behind a removal, the guide itself is still the source to read.