A removed API
PodSecurityPolicy, gone in 1.25, checked against the target version
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restricted
Kubernetes API Version Checker
Check every apiVersion in a manifest against a target cluster version. This covers apiVersion and kind, which is the part that changes between releases and breaks applies, and it deliberately does not ship a field-level OpenAPI schema.
The table behind this comes from the upstream deprecated API migration guide and covers built-in kinds through 1.33.
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.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
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.
A current manifest
A manifest already on a supported version for the chosen target
apiVersion: apps/v1 kind: Deployment metadata: name: api
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Validating against the running version instead of the target
The point is to catch what breaks on upgrade. Checking against today's version finds nothing.
Instead:Set the target to the version you are moving to.
Assuming a deprecated API still works
Deprecated and removed are different. A removed API is a hard error at apply time.
Instead:Check the removal version, not the deprecation notice.
Only checking your own manifests
Charts, operators and vendored YAML carry old apiVersions too.
Instead:Render everything that gets applied, then check the output.
Why this is not a field-level schema check
A per-version field check means shipping megabytes of OpenAPI and being wrong whenever your cluster differs from the copy bundled here. The apiVersion half is what breaks applies between releases, and it fits in a small table that can be right.
PodSecurityPolicy is the one with nowhere to go
Every other removal on this list is a move to a new group or version. PSP was deleted in 1.25 with no successor object, so a cluster upgrading past it loses the enforcement silently. Pod Security Admission replaced it and is configured with labels on the Namespace rather than as an object you apply.
PodDisruptionBudget inverted an empty selector
policy/v1beta1 matched no pods with an empty selector; policy/v1 matches every pod in the namespace. The same object therefore reverses meaning across the 1.25 removal, going from protecting nothing to blocking every eviction, which stops node drains cluster-wide. The object is valid in both versions, so nothing warns.
What this cannot see
Fields, which `kubectl apply --dry-run=server` checks against your actual cluster including its webhooks and CRDs. Custom resources, whose versions belong to whoever wrote the CRD. And anything removed after 1.33, until somebody adds it here.
Related kubernetes tools
Kubernetes API Deprecation Checker What breaks on the next upgrade Kubernetes Service Checker Will this Service have any endpoints? Kubernetes Ingress to Gateway API Which annotations silently stop working Kubernetes Pod and Service CIDR Fixed at cluster creation Kubernetes Cluster Cost Estimator At your rates, not a price table Kubernetes YAML Validator Is this YAML valid, and where is it wrong?
All 55 kubernetes tools