Start an API server, preferably in a test cluster, with the runtime-config flag set to turn off the API versions you expect to lose, then see what breaks. The Kubernetes docs give the form runtime-config equals GROUP/VERSION equals false. It simulates a removal so you find old manifests and add-ons before the real upgrade.
Why this matters for the supply chain
Charts, operators and add-ons you did not write may still use old API versions. When a release removes a version, the failure is a broken install or a controller that cannot talk to the API. Third party code is usually the cause, so a test beats guessing.
The steps
- Read the deprecation guide for each Kubernetes version between your current one and the target. It lists removed API versions and what to migrate to.
- Collect every manifest source: Git repositories, Helm charts rendered with helm template, operator bundles and CI templates.
- In a non production cluster, add the flag to the API server startup arguments.
--runtime-config=GROUP/VERSION=false
- Apply your manifests and install your charts. Note each failure.
- Fix by moving to the version the guide recommends, and update charts or operators that cannot be changed.
- Repeat until a clean pass.
The docs include an example that lists several versions in one comma separated flag value, so you can test several removals together.
Find use in a live cluster
The guide points to client warnings, metrics and audit information, available since Kubernetes 1.19, to locate use of deprecated APIs in a running cluster. This post did not confirm metric names, so use the linked Kubernetes blog post for details.
Who owns the fix
| Source | Who fixes it |
|---|---|
| Your own manifests | You |
| A vendor chart | Ask for a new chart version, or render and patch |
| An operator | Upgrade the operator first, and then the cluster |
| An old CI template | Update the template |
If a vendor chart still uses a removed version, treat that as a maintenance signal about the project.
Pair it with the upgrade plan
Combine this test with the skew rules in which Kubernetes components should you upgrade first and the end of support dates in how long Kubernetes versions are supported.
Try it yourself
Try it yourself
Click through it at your own pace, or open it full screen. Look at how ongoing checks surface drift, which is the same habit an upgrade test builds.
Quick check
Should I run the flag on a production API server?
No. Use a test cluster, since the point is to simulate a removal that could break workloads.
Does the test cover add-ons?
Only if you install them in the test cluster. Include every add-on you run.
Safeguard dependency scanning and continuous monitoring help you notice outdated components you still run.
Sources
Last reviewed: 19 October 2026.
