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.

What Beta APIs are Removed in Kubernetes 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.

  • Beta versions of the ValidatingWebhookConfiguration and MutatingWebhookConfiguration API (the admissionregistration.k8s.io/v1beta1 API versions)
  • The beta CustomResourceDefinition API (apiextensions.k8s.io/v1beta1)
  • The beta APIService API (apiregistration.k8s.io/v1beta1)
  • The beta TokenReview API (authentication.k8s.io/v1beta1)
  • Beta API versions of SubjectAccessReview, LocalSubjectAccessReview, SelfSubjectAccessReview (API versions from authorization.k8s.io/v1beta1)
  • The beta CertificateSigningRequest API (certificates.k8s.io/v1beta1)
  • The beta Lease API (coordination.k8s.io/v1beta1)
  • All beta Ingress APIs (the extensions/v1beta1 and networking.k8s.io/v1beta1 API versions)

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.

Why Is It Important (and What Can I Do)?

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

The release notes warn that this command will turn off v1beta1 of EndpointSlice, which is important to remember for testing.

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.

Why Does Kubernetes Remove Beta APIs?

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.

What Beta APIs are Going Away in the Future

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:

  • The beta CronJob API (batch/v1beta1)
  • The beta EndpointSlice API (networking.k8s.io/v1beta1)
  • The beta PodDisruptionBudget API (policy/v1beta1)
  • The beta PodSecurityPolicy API (policy/v1beta1)

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.