· ReadyStack
Worked example
Real numbers from this tool, line by line.
Six lines in one Kubernetes chart bundle would have been rejected by the cluster, and the platform engineer who owns the EKS upgrade ticket found all six in the editor, before the pull request.
They were not typos. Every one of them was valid YAML, indented correctly, and would round-trip through any formatter without complaint: an Ingress on extensions/v1beta1, a CronJob on batch/v1beta1, a PodDisruptionBudget on policy/v1beta1, a HorizontalPodAutoscaler on autoscaling/v2beta2, a CustomResourceDefinition on apiextensions.k8s.io/v1beta1, and an alpha seccomp annotation on the CronJob's pod template.
Kubernetes removed those API versions in 1.22 (released 4 August 2021), 1.25 (23 August 2022) and 1.26 (9 December 2022). The bundle was written in 2026. That gap is the whole story: an assistant learned Kubernetes YAML from six years of manifests in which batch/v1beta1 was the correct answer, so batch/v1beta1 is what it writes, and it will defend the choice if you ask it twice.
Nothing local disagrees. The YAML parses, the linter is quiet, the diff looks like a hundred other diffs. The first thing that objects is the API server, and it objects in the middle of the apply: no matches for kind "CronJob" in version "batch/v1beta1". Half the bundle is already in, the CronJob is not, and the object you thought you were managing is now unmanaged - which is the version of this failure that does not page anyone.
The seccomp annotation is the quieter one. seccomp.security.alpha.kubernetes.io/pod stopped being read by the kubelet in 1.25. It does not fail. It does not warn. The manifest still says the pod is confined and the pod runs unconfined, and the only way to notice is to know that the annotation died.
Kubernetes Removed API Lint reads the manifest open in the editor and marks each of these on its own line. It carries 36 rules: 29 removed apiVersion and kind pairs, spread across the eight releases that did the removing - 1.16, 1.18, 1.22, 1.25, 1.26, 1.27, 1.29 and 1.32 - then 6 annotations and fields that still parse but no longer do anything (the alpha seccomp annotation, scheduler.alpha.kubernetes.io/critical-pod, the beta.kubernetes.io/os and /arch node selectors that now match no node, the failure-domain topology labels, kubernetes.io/ingress.class, and pod.spec.serviceAccount), and 1 catch-all for any other alpha or beta apiVersion it has no row for.
Each finding names the release that removed the API, the date that release shipped, and the replacement to type. The date matters, so it is an input: move the "as of" date back before a removal shipped and that rule reports as a warning instead of an error. The same repository read as of June 2021 produces six warnings where today it produces six errors - which is a fair picture of a cluster you have not upgraded yet.
It runs offline. No cluster, no kubeconfig, no upload. Checking the file in your editor is free, all 36 rules, no key and no account, and the same engine runs in a browser tab at the product page. The paid half is a different job, not a smaller one: sweep every .yaml and .yml in the workspace and write a dated Markdown report you keep - the artefact the upgrade ticket asks for. That is $29 once, one key per person or CI seat, seven-day full refund. A freelance Kubernetes platform engineer bills roughly $75-$150 an hour, and reading one repository for removed APIs is most of a working day.
15 seconds — what it actually does
Questions people ask
What does Kubernetes Removed API Lint actually do?
It reads the YAML manifest open in your editor, splits it into documents, and runs 15 rules over every apiVersion and kind. For each hit it names the minor release that removed that apiVersion, quotes the error the API server returns, and gives the replacement. On the sample bundle it reports 11 findings over 6 distinct removed apiVersions.
Who is this for?
Platform and backend engineers who own Kubernetes manifests or a Helm chart in a repo, and anyone accepting YAML from an assistant. If you have ever run kubectl apply against a freshly upgraded cluster and read no matches for kind in version, you are the reader. It is written for people who find out at rollout.
Why is a chatbot or kubectl not enough?
kubectl validates against the cluster you are pointing at, not the one you get after the upgrade, so a manifest that applies today tells you nothing about 1.25. A chatbot is the source of the problem: it was trained on years of published YAML, and most published Kubernetes YAML uses apiVersions that were removed in 1.16 and 1.22.
What is free and what needs a licence key?
Free, with no key: check the manifest open in the editor against all 15 rules and get the removal release and replacement for every hit, with line numbers. That is a complete answer for that file. The key buys scope, not depth: sweep every manifest in the workspace and write one dated migration report ordered by removal version.
What would this cost me otherwise?
A freelance Kubernetes consultant bills about 120 US dollars an hour, and reading one chart repo for beta apiVersions before an upgrade is most of a day. The other price is the rollback: a removed apiVersion fails partway through kubectl apply, so half the bundle is live and half is not. The licence is 29 US dollars once.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.