· ReadyStack
Worked example
Real numbers from this tool, line by line.
6 dead apiVersions in one eight-object bundle - that is the first lint pass over one service's manifests, for the platform engineer who owns the chart repo on a managed Kubernetes cluster.
_fixtures/dirty.yaml - 11 findings
L2 error Deployment on extensions/v1beta1 was removed in 1.16. Use apps/v1.
L7 error The seccomp alpha annotation stopped being honoured in Kubernetes 1.25. Use securityContext.seccompProfile.
L16 warn beta.kubernetes.io/os is a deprecated node label. Use kubernetes.io/os.
L21 error CronJob on batch/v1beta1 was removed in 1.25. Use batch/v1.
L36 error PodDisruptionBudget on policy/v1beta1 was removed in 1.25. Use policy/v1.
L46 error HorizontalPodAutoscaler on autoscaling/v2beta2 was removed in 1.26. Use autoscaling/v2.
L65 error Ingress on networking.k8s.io/v1beta1 was removed in 1.22. Use networking.k8s.io/v1.
L70 warn The kubernetes.io/ingress.class annotation went away with the v1beta1 Ingress. Use spec.ingressClassName.
L81 error CustomResourceDefinition on apiextensions.k8s.io/v1beta1 was removed in 1.22. Use apiextensions.k8s.io/v1.
L93 error PodSecurityPolicy was removed in 1.25. Move the namespace to Pod Security Admission labels.
L105 error Deployment on apps/v1 has no spec.selector. apps/v1 requires it and never defaults it.Eleven findings over six distinct removed apiVersions - policy/v1beta1 appears twice, for the PodDisruptionBudget and the PodSecurityPolicy. One service, eight objects - Deployment, CronJob, PodDisruptionBudget, autoscaler, Ingress, CRD, PodSecurityPolicy, worker Deployment - written in an afternoon or asked for in one prompt.
The YAML is out of date before you read it
Ask an assistant for a Kubernetes Deployment and there is a fair chance you get apiVersion: extensions/v1beta1 - that is what most published Kubernetes YAML says, and all of it is training data. It stopped being served in 1.16.
Two of those removals carry a trap the apiVersion line does not show: policy/v1beta1 PodDisruptionBudget went in 1.25 and the empty selector flipped meaning - under v1beta1 it matched no pods, under policy/v1 it matches every pod in the namespace; and the v1beta1 Ingress backend block changed shape in 1.22, so editing the apiVersion alone still leaves a rejected manifest.
Nothing warns you until the cluster moves
kubectl apply validates against the cluster you are pointing at right now. If that cluster is still on 1.24, a batch/v1beta1 CronJob applies without a word: the manifest is not correct, it is early. A managed control plane upgrades on the provider's calendar, not yours. The first hard error arrives partway through a rollout: kubectl applies documents in order, so objects before the dead one are live and objects after it are not. The message itself is calm: no matches for kind "Deployment" in version "extensions/v1beta1".
The ones that never error at all
Three of the fifteen rules catch failures that raise no error at all. The seccomp alpha annotation at L7 stopped being honoured in 1.25 but is still a legal annotation, so the pod applies and runs unconfined. The kubernetes.io/ingress.class annotation at L70 was retired with the v1beta1 Ingress, and a controller watching only IngressClass ignores it. The beta.kubernetes.io/os node selector at L16 can match no node and leave the pod Pending.
What the lint does
It reads the manifest open in the editor and runs fifteen rules over every apiVersion and kind, offline - no cluster connection, no kubectl context. Each finding carries the line number, the removal release, and the replacement. On the clean version of the same eight objects it reports zero.
Free in the editor and in the browser: all fifteen rules on one file. The licensed part is scope, not depth - sweep every manifest in the workspace into one dated migration report, ordered by removal version.
Free web version: https://getreadystack.com/tools/k8s-removed-api-lint
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.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. Kubernetes Removed API Lint checks the file you open against 15 rules, each naming its legal or official basis, from a rule set dated 2026-09-20, and points at the exact line. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.