{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }}

The checker reads resource apiVersion, kind, metadata.name, and metadata.namespace from up to 250 resources.
{{ sourceStatus }}
Select the control-plane version the manifests must support after the upgrade.
Keep the gate focused on this upgrade or include later cleanup work.
Choose where this manifest set came from so each migration row points to the right verification workflow.
This traceable label changes handoff titles and filenames, not removal classifications.
{{ workflowFeedback }}
Adds advisory rows for alpha or beta versions absent from the official removal table. Off keeps the primary result limited to documented built-in removals.
{{ flag_unknown_beta ? 'Enabled' : 'Disabled' }}
Leave blank to use the review label for handoffs.
PriorityResourceRequired changeMigration checkWorkflow actionCopy
{{ row.priority }}{{ row.resource }}{{ row.change }}{{ row.check }}{{ row.workflow_action }}
ResourceCurrent APIRemovedReplacementStatusSourceCopy
{{ row.resource }}{{ row.api_version }}{{ row.removed_in }}{{ row.replacement }}{{ row.status }}{{ row.source }}
{{ snippetText }}
Kubernetes Resource Requests Checker Check Kubernetes manifests for missing resource requests and invalid limits, with QoS clues and scheduler-footprint evidence before rollout.
Kubernetes Pod Security Context Checker Check Kubernetes workload YAML for inherited security contexts, Pod Security gaps, weighted findings, and a reviewable hardening patch.
Kubernetes NetworkPolicy Generator Build Kubernetes NetworkPolicy YAML from pod labels and allow rules with selector checks, rollout guidance, and security review warnings.
Kubernetes Deployment Generator Build Kubernetes Deployment YAML with optional Service and policy resources, plus checks for rollout, probes, resources, and security choices.

A Kubernetes upgrade can remove an API version even though the resource kind still exists. A manifest that worked on the old control plane may then fail before an object is created, because the target API server no longer recognizes its apiVersion and kind pair.

Deprecation and removal are different states. A deprecated API is still served for a time and usually emits warnings. A removed API is unavailable in that Kubernetes release and blocks an apply, upgrade, rollback, or controller request that still uses it. The target minor version decides which state matters for an upgrade gate.

Source manifest
The Git, Kustomize, rendered Helm, stored release, or exported object text being reviewed.
Replacement API
The served API version to migrate toward when Kubernetes documents a successor.
Migration check
A field, default, selector, or behavior change that must be reviewed in addition to replacing the version string.

Changing only apiVersion is sometimes unsafe. Ingress backends changed shape, several workload APIs require explicit selectors, and an empty PodDisruptionBudget selector behaves differently in policy/v1 than in policy/v1beta1. PodSecurityPolicy has no in-place successor after its removal and requires a different admission approach.

Source context affects remediation. Helm users should scan rendered output and then fix the chart or values that generated it. A cluster export can show the version currently served by the API server rather than the version originally submitted. Static text also misses API calls made by controllers, operators, scripts, and clients.

A clean manifest scan is an upgrade prerequisite, not final proof. Server-side dry runs against the target minor version, API warning logs, audit records, the deprecated-API metric, installed custom resources, and live client behavior complete the review.

How to Use This Tool:

Use the exact rendered or stored manifest set that the upgrade, GitOps reconciliation, or rollback path will apply.

  1. Paste Kubernetes YAML or JSON containing up to 250 resources. Fix parser errors or missing apiVersion/kind fields before interpreting the scan.
  2. Select the target control-plane minor version. Choose the current-upgrade horizon for a gate, the next-known removal for near-term cleanup, or all known removals for backlog planning.
  3. Set Source context so remediation points back to manifests, rendered Helm output, stored release data, or the owner of a cluster export.
  4. Enable unlisted pre-GA advisories only when alpha and beta APIs outside the built-in removal table also need an owner review.
  5. Resolve every blocker in its owning source, render again, and repeat the scan. Then run a server-side dry run against a target-version cluster.

Interpreting Results:

Upgrade blocker means the target version is equal to or newer than the documented removal release. Deprecated warning means the API is deprecated by the target but not yet removed. Future removal appears only when the selected horizon reaches a later removal. Pre-GA advisory is an owner check for an unlisted alpha or beta API, not an official removal claim.

A replacement snippet is a starting point. Follow its migration check and validate the full object on the target API server; no-successor rows require a new control rather than an apiVersion edit.

Technical Details:

Each parsed resource is matched by the exact combination of API version and kind against a fixed table of documented built-in removals. The table covers removal releases from Kubernetes 1.16 through 1.32. Selecting a target after 1.32 applies the same published mapping and does not imply additional removals.

Lookup Core

ComparisonClassificationGate meaning
Target version ≥ removal versionBlockerThe target API server does not serve the matched built-in API.
Target version ≥ deprecation version and < removal versionWarningThe API remains served but should be migrated.
Target version < deprecation versionFutureIncluded only when the selected horizon reaches that removal.
Unlisted version matches an alpha or beta patternAdvisoryShown only when the optional advisory switch is enabled.

The target-gate horizon excludes future rows. The next-known horizon includes future matches only through the first removal release after the target. The all-known horizon includes every matching removal in the table. Findings sort from blocker to warning, future, and advisory, then by removal version and resource name.

Mechanism limits

The parser reads resource identity rather than validating full Kubernetes schemas. Custom resource definitions, operator compatibility, admission policies, and field-level migration correctness remain outside the lookup. Input is limited to 512 KiB and 250 resources.

Limitations and Privacy:

Manifest parsing and lookup run locally and do not contact a cluster. Remove secrets from Kubernetes objects before sharing evidence. Because the scan sees only supplied text, supplement it with target-cluster dry runs, warning and audit data, generated manifests, and stored Helm release checks.

Worked Examples:

PodDisruptionBudget for a 1.25 upgrade

A policy/v1beta1 PodDisruptionBudget is a blocker when the target is 1.25 because that API was removed in 1.25. The replacement is policy/v1, but the selector must also be reviewed because an empty selector changes meaning.

Future cleanup beyond the gate

A flowcontrol.apiserver.k8s.io/v1beta3 resource is not a blocker for a 1.29 target, but it is deprecated and removed in 1.32. An all-known horizon keeps that later migration visible without confusing it with the current upgrade blockers.

References: