{{ result.summary.heading }}
{{ result.summary.primary }}
{{ result.summary.line }}
{{ badge.label }}
Manifest {{ stageModel.target }} {{ stageModel.marker }} Replacement
Name the manifest set, Helm render, cluster export, or pull request being checked.
Choose the cluster version you are preparing to run after the upgrade.
Control whether the result focuses only on this upgrade or also shows future cleanup work.
Tell the checker where the manifests came from so migration actions point to the right workflow.
Paste the resource definitions to check. Multi-document YAML and Kubernetes List objects are scanned as separate resources.
{{ sourceMeta }}
Use this only as a cleanup hint for CRDs or vendor APIs; official removal findings remain separate.
{{ params.flag_unknown_beta ? 'On' : 'Off' }}
Use a compact value for screenshots or a larger value for upgrade handoff exports.
rows
{{ header }} Copy
{{ cell }}
No rows for this tab
The current manifest and scan horizon did not produce this artifact.
 
{{ result.patchText }}
Tags: Devops, Security
Dockerfile Security Basics Checker Check a Dockerfile for risky defaults before build time, with weighted findings for base images, users, secrets, package hygiene, and runtime surface.
IAM Policy Wildcards Checker Review AWS IAM policy JSON for wildcard Action, Resource, Principal, NotAction, and NotResource risks with severity-ranked remediation rows.
Kubernetes Pod Security Context Checker Check Kubernetes workload YAML for securityContext gaps, Pod Security profile blockers, inherited settings, risk scores, and patch cues.
Container Security Scan Analyzer Review container scan output, normalize severities and fixes, test critical/high gate limits, and rank packages for remediation.
Customize
Advanced
:

Kubernetes API removals are upgrade blockers because the API server may reject manifests that worked on older clusters. A resource written with an old apiVersion can stop applying after a control plane upgrade, and some migrations require field changes rather than a simple version string replacement.

The risk is highest in long-lived repositories, Helm charts, cluster exports, and generated manifests that still contain beta API groups. Ingress, PodDisruptionBudget, HorizontalPodAutoscaler, CronJob, Event, FlowSchema, and PriorityLevelConfiguration have all had version transitions that can matter during upgrades. A static manifest scan helps teams find those blockers before the upgrade window.

Good migration planning separates three cases: APIs already removed by the target version, APIs deprecated but still accepted, and APIs scheduled for a later removal. That separation keeps the upgrade gate focused while still exposing cleanup work that should be queued before the next cluster cycle.

Risk class Meaning Operational response
Blocker The API was removed at or before the target version. Migrate before the control plane reaches that version.
Warning The API is deprecated for the selected horizon but not yet removed by the target gate. Plan the replacement while the old version is still accepted.
Future cleanup The API is known to be removed after the target version. Track the migration so the next upgrade is easier.
Advisory A beta API is not in the known rule table but deserves review. Confirm whether the API is stable, custom, or provider-specific.

How to Use This Tool:

  1. Enter a Review label that identifies the repository, chart, cluster export, or release being checked.
  2. Select the Target Kubernetes version, such as v1.22, v1.25, v1.29, or v1.32.
  3. Choose a Scan horizon: Target gate only, Target plus next known removal, or All known removals.
  4. Set the Source context to manifest repository, Helm template, Helm release metadata, or cluster export so warnings match the evidence source.
  5. Paste YAML or JSON manifests, or load a source file, then choose a sample only when you need a quick demonstration.
  6. Review Upgrade Snapshot, API Findings, Migration Queue, Manifest Inventory, Removal Version Map, Migration Snippets, and JSON.

Scan rendered manifests when possible. Helm values and conditionals can hide version-specific output until templates are rendered for the same settings used in the cluster.

Interpreting Results:

Upgrade blocked means at least one manifest uses an API removed by the selected target version. Migration warning means the API is still accepted for the target but is already deprecated or inside the selected horizon. Future cleanup points to a known later removal. Ready to upgrade means no known removed or horizon-matched APIs were found in the submitted content.

  • API Findings lists kind, API version, removal version, replacement, and source location when available.
  • Migration Queue groups work by priority so target blockers appear before cleanup tasks.
  • Manifest Inventory shows what was parsed, including documents that are not in the deprecated API rule table.
  • Migration Snippets provide starting-point replacements and comments for common API transitions.

A clean result is limited to the submitted manifests and known rule table. Admission webhooks, operators, CRDs, generated runtime objects, and provider-specific APIs still need separate review.

Technical Details:

The scanner parses YAML or JSON documents, extracts apiVersion, kind, metadata name, and namespace, then compares each resource with a rule table of Kubernetes API removals. Each rule includes the removed version, replacement API, and migration notes. If parsing fails, the fallback scanner still looks for version and kind pairs so obvious blockers are not missed.

Classification is based on the selected target version and scan horizon. If the target version is at or beyond the removal version, the finding is a blocker. If the target is before removal but the API is inside the selected horizon, the finding is a warning or future cleanup item. Optional beta API review adds advisory rows for unknown beta APIs that may need manual confirmation.

Field Calculation role Boundary or caution
Target Kubernetes version Sets the upgrade gate for removal classification. Use the control plane version you intend to reach, not the current worker node version.
Scan horizon Controls whether later removals appear alongside target blockers. All-known-removals mode is useful for cleanup planning but can be noisy.
Source context Changes explanatory warnings for repositories, Helm output, and cluster exports. Cluster exports may show converted versions rather than the source manifests that will be reapplied.
Unknown beta APIs Adds advisory findings for beta versions outside the known rule table. CRDs and provider APIs can legitimately use beta versions, so review those rows manually.

The default v1.32 target catches removals such as flowcontrol.apiserver.k8s.io/v1beta3 for FlowSchema and PriorityLevelConfiguration, while older gates catch familiar removals such as networking.k8s.io/v1beta1 Ingress at v1.22 and policy/v1beta1 PodDisruptionBudget at v1.25.

Accuracy Notes:

This is a static manifest review. It cannot prove that every generated manifest, operator-created resource, admission mutation, or environment-specific Helm branch has been covered.

  • Scan rendered Helm output for each values file used in production-like environments.
  • Review CRDs and custom controllers separately because their version lifecycles are outside the core Kubernetes rule table.
  • Do not rely only on cluster exports when the original deployment repository still contains old API versions.
  • Apply migrated manifests in a staging cluster or API dry run before the upgrade window.

Worked Examples:

A manifest repository targeting v1.32 that contains flowcontrol.apiserver.k8s.io/v1beta3 FlowSchema resources should produce blocker findings because that beta version is removed at the target gate. The migration queue should point to flowcontrol.apiserver.k8s.io/v1.

An Ingress manifest still using networking.k8s.io/v1beta1 is a blocker for v1.22 and newer. The migration is not only the API version; the v1 Ingress shape also uses pathType and a different backend service structure.

A cluster export may look clean if the API server already converted stored objects to a newer version. The source chart or repository can still contain old versions that fail when reapplied, so scan both when possible.

FAQ:

Can I fix every finding by changing only apiVersion?

No. Some migrations require field changes, renamed paths, different selectors, or changed default behavior. Always review the replacement notes and test the migrated manifest.

Should I scan Helm chart source or rendered output?

Scan rendered output for each important values set. Source templates can contain conditional branches, while rendered manifests show what the cluster will actually receive.

Why does the checker warn about cluster exports?

The API server can convert stored objects to a served version. That export may not reveal old versions still present in Git or Helm release metadata.

What should I do with unknown beta API advisories?

Identify whether the resource is a core Kubernetes API, CRD, or provider-specific API, then check the owning project's version policy before changing it.

Glossary:

API removal
The point where a Kubernetes API version is no longer served by the API server.
Deprecated API
An API version that still works for now but has a documented replacement or removal path.
Rendered manifest
The final YAML or JSON produced by a tool such as Helm before it is applied to a cluster.
CRD
CustomResourceDefinition, an extension mechanism with its own version lifecycle.
Dry run
A validation mode that asks the API server to check a manifest without persisting it.

References: