Ready to Work Together?
Let's discuss how our expertise can help transform your business.
Jordan Saunders
·
Jul 19, 2021
Thinking about upgrading to Kubernetes v1.22? There’s a number of beta APIs that will be making their exit in the new version that could have a big impact on how your code works going forward.
It bears repeating that these beta APIs -- some of which may have been enabled by default -- won’t just be deprecated in the new version of Kubernetes. They will be removed entirely.
Check out the list below and make a plan before making your move to v1.22.
If you are using any of the beta API versions listed below, they will immediately stop serving in version 1.22. These APIs were previously deprecated in “favor of newer and more stable API versions,” per the release notes.
If you are using any of these and need some help, check out this link for documentation covering migration options, specific nuances, and in some cases, paths forward and tips about switching to the stable APIs.
In short, if your code relies on any of the beta APIs above, which were enabled by default, and upgrade to v1.22, your application will probably not work as it did before.
For software developers, specifically authors of 3rd party integrations, the removal of these APIs is critically important because they could potentially break the applications. Any developer that has created an Ingress controller, webhook authenticator, API aggregators, or another tool that relies on the APIs listed above will probably be negatively impacted.
The release notes for v1.22 includes a guide for testing out your upgrade so you can run your Kubernetes cluster in an environment that only uses the new APIs to make sure your code works as it should.
To try out the API removals prior to upgrading to Kubernetes v1.22, add the following to the kube-apiserver command list arguments:
--runtime-config=admissionregistration.k8s.io/v1beta1=false,apiextensions.k8s.io/v1beta1=false,apiregistration.k8s.io/v1beta1=false,authentication.k8s.io/v1beta1=false,authorization.k9s.io/v1=false,certificates.k8s.io/v1beta=false,coordination.k8s.io/v1beta1=false,extensions/v1beta1/ingresses=false,networking.k8s.io/v1beta1=false
Once you've switched all the kube-apiservers in your cluster to use that setting, the beta APIs are removed. You can test that API clients (kubectl, deployment tools, custom controllers etc) still work how you expect, and you can revert if you need to without having to plan a more disruptive downgrade.
Kubernetes has a defined deprecation policy for features which includes its own API. According to the policy, stable API are only deprecated when a newer, equally stable version of the API becomes available.
For those that are using a stable version of the Kubernetes API, “there won't ever be a new version released that forces you to switch to an alpha or beta feature,” according to the documentation. The big differentiator here is how stable versions are treated in comparison to alpha or beta versions.
Alpha versions of the API are for testing and since they may be incomplete to begin with, are nearly always disabled by default. Sometimes alpha features don’t work out and are removed from Kubernetes releases.
Features that survive alpha testing move to beta and are typically enabled by default, which is an important distinction from their alpha counterparts.
Once an API reaches beta, a countdown begins. Within roughly a year’s time, or three release cycles, per the documentation, the beta API will either reach General Availability (GA) or a new beta version be created and released. In either case, whether it reaches GA or it’s back to the drawing board, the previous beta version will be deprecated.
More APIs will be removed with the release of Kubernetes 1.25, when it is released sometime next year. Specifically, PodSecurityPolicy won’t make the jump to stable and will be removed altogether. To learn more about how to move forward with PodSecurityPolicy, read the PodSecurityPolicy Deprecation: Past, Present, and Future post here.
Here’s the list of beta APIs planned for removal as it stands now:
Click this link for the official list of API removals for Kubernetes 1.25.
Getting started with Kubernetes can be a challenge. Keeping up to date with different versions can be tough too. Contact us if you have any questions about DevOps consulting services, Kubernetes, or getting started with your project.
Author at NextLink Labs
A Jenkinsfile with one stage, no scanning, no caching. Here's how NextLink Labs used Claude Code to rewrite it into a production GitLab pipeline with rootless BuildKit, Trivy scanning, Skopeo retag, and a proper DAG — in under an hour.
Alex Podobnik
·
Apr 28, 2026
Someone set that up manually a while back. Sound familiar? Here's how NextLink Labs uses Claude Code's agentic loop to import hand-built AWS infrastructure into Terraform — compressing a multi-day job into an afternoon.
Alex Podobnik
·
Apr 24, 2026
Most LLM-generated Terraform is bad — not because of the tool, but because of the prompt. Here's how NextLink Labs uses Claude Code and CLAUDE.md conventions to generate Terraform modules that are close to merge-ready.
Alex Podobnik
·
Apr 24, 2026
One account becomes five, and eventually nobody knows which guardrails are where. Here's how NextLink Labs manages AWS Organizations, OU hierarchies, and Service Control Policies with Terraform and GitLab CI.
Colin Soleim
·
Apr 22, 2026
Let's discuss how our expertise can help transform your business.