Kubernetes 1.22 landed this week, and it’s one of the most significant releases in recent memory — not because of flashy new features, but because of what it removes. This release drops a large batch of deprecated beta APIs that have been hanging around for years, and it graduates several important features to stable. For those of us running Kubernetes in production, this is the release that demands attention.
The Great API Cleanup#
The headline change is the removal of several beta API versions that have long been superseded by stable equivalents. Specifically, Kubernetes 1.22 removes:
- Ingress beta APIs (
extensions/v1beta1andnetworking.k8s.io/v1beta1) — replaced bynetworking.k8s.io/v1(stable since 1.19) - CustomResourceDefinition beta APIs (
apiextensions.k8s.io/v1beta1) — replaced byapiextensions.k8s.io/v1(stable since 1.16) - ValidatingWebhookConfiguration and MutatingWebhookConfiguration beta APIs — stable equivalents available since 1.16
- CertificateSigningRequest beta APIs — stable since 1.19
- Several other beta resources in the
rbac.authorization.k8s.io/v1beta1group
If you’re thinking “we should have migrated off those ages ago” — you’re right. These deprecations were announced one to two years ago, with the stable replacements available even longer. But I’ve seen enough production clusters to know that many teams are still running manifests with extensions/v1beta1 Ingress resources because, well, they worked and nobody prioritised the migration.
Those teams are about to have a bad day if they upgrade without preparation.
How to Prepare#
Before upgrading to 1.22, you need to audit your cluster. The Kubernetes project has made this relatively straightforward:
Use
kubectl convert: This plugin can convert manifests between API versions. Run it against your stored YAML files to identify what needs updating.Check the API deprecation guide: The official deprecation guide lists every removed API with its replacement.
Audit with
kubectl get --raw: Query the API discovery endpoints to see which API versions your workloads are actually using.Watch audit logs: If you’ve enabled audit logging, search for requests to deprecated API endpoints. This reveals which controllers, operators, and CI/CD pipelines are still using old APIs.
Test with
--warnings-as-errors: Recent kubectl versions surface deprecation warnings. Treat these as errors in your CI pipeline to catch issues before they hit production.
The critical thing many people miss: it’s not just your own manifests that matter. Helm charts, operators, and third-party controllers may also reference deprecated APIs. Check that your installed operators are compatible with 1.22 before upgrading. The Helm mapkubeapis plugin can help update stored Helm release metadata.
Features Graduating to Stable#
Beyond the removals, 1.22 promotes several features to GA (Generally Available):
Server-Side Apply reaches GA after a long beta. This is significant — it moves apply logic from kubectl to the API server, enabling proper field-level ownership tracking. If you’ve ever had two controllers fighting over the same resource fields, Server-Side Apply is the solution. It tracks which manager owns which fields and prevents conflicts.
External Credential Providers graduate to stable, allowing kubectl to authenticate using external credential systems. This is essential for enterprise environments using custom identity providers.
Bound Service Account Token Volumes reach GA, replacing the old non-expiring service account tokens with time-bound, audience-bound tokens. This is a meaningful security improvement — the old tokens were essentially permanent credentials that never expired and could be used against any audience.
PodDisruptionBudget graduates its policy/v1 API to stable, though the policy/v1beta1 version is deprecated (not yet removed).
The Maturity Signal#
What I find most interesting about 1.22 is what it signals about Kubernetes’ maturity. A project that aggressively removes deprecated APIs is a project that’s confident in its stable interfaces. The Kubernetes API deprecation policy — at least three releases of overlap for beta-to-GA transitions — gives users reasonable migration windows.
Compare this to the early days of Kubernetes (I remember running 1.4 and 1.5 in production) when breaking changes between minor versions were common and often poorly documented. The project has come a long way in API governance.
This maturity also means that the “upgrade every release” cadence is becoming more important, not less. With the support window at roughly 14 months (three minor versions), and deprecated APIs being removed on schedule, falling behind means accumulating migration debt that compounds with each skipped release.
My Take#
I’ve been running Kubernetes in production environments since before it hit 1.0, and 1.22 feels like a watershed moment. The project is choosing long-term API cleanliness over short-term convenience, and that’s the right call.
My advice for teams: don’t skip this upgrade, but don’t rush it either. Spend a week auditing your manifests, Helm charts, and operators against the API migration guide. Set up a staging cluster running 1.22 and deploy your full stack against it. Fix the breakages there, not in production.
And if this upgrade is painful for your team, take it as a signal to invest in your upgrade processes. Kubernetes isn’t slowing down its release cadence, and the API deprecation cycle will continue. The teams that treat Kubernetes upgrades as routine maintenance rather than a quarterly fire drill are the ones that sleep well at night.
Fifty-three enhancements in one release — thirteen graduating to stable, twenty-four in beta, and sixteen entering alpha. The Kubernetes train keeps moving, and 1.22 is a reminder to stay on board.