Blog: Moving Forward From Beta

Author: Tim Bannister, The Scale Factory

In Kubernetes, features follow a defined
lifecycle.
First, as the twinkle of an eye in an interested developer. Maybe, then,
sketched in online discussions, drawn on the online equivalent of a cafe
napkin. This rough work typically becomes a
Kubernetes Enhancement Proposal (KEP), and
from there it usually turns into code.

For Kubernetes v1.20 and onwards, we’re focusing on helping that code
graduate into stable features.

That lifecycle I mentioned runs as follows:

Usually, alpha features aren’t enabled by default. You turn them on by setting a feature
gate; usually, by setting a command line flag on each of the components that use the
feature.

(If you use Kubernetes through a managed service offering such as AKS, EKS, GKE, etc then
the vendor who runs that service may have decided what feature gates are enabled for you).

There’s a defined process for graduating an existing, alpha feature into the beta phase.
This is important because beta features are enabled by default, with the feature flag still
there so cluster operators can opt out if they want.

A similar but more thorough set of graduation criteria govern the transition to general
availability (GA), also known as “stable”. GA features are part of Kubernetes, with a
commitment that they are staying in place throughout the current major version.

Having beta features on by default lets Kubernetes and its contributors get valuable
real-world feedback. However, there’s a mismatch of incentives. Once a feature is enabled
by default, people will use it. Even if there might be a few details to shake out,
the way Kubernetes’ REST APIs and conventions work mean that any future stable API is going
to be compatible with the most recent beta API: your API objects won’t stop working when
a beta feature graduates to GA.

For the API and its resources in particular, there’s a much less strong incentive to move
features from beta to GA than from alpha to beta. Vendors who want a particular feature
have had good reason to help get code to the point where features are enabled by default,
and beyond that the journey has been less clear.

KEPs track more than code improvements. Essentially, anything that would need
communicating to the wider community merits a KEP. That said, most KEPs cover
Kubernetes features (and the code to implement them).

You might know that Ingress
has been in Kubernetes for a while, but did you realize that it actually went beta in 2015? To help
drive things forward, Kubernetes’ Architecture Special Interest Group (SIG) have a new approach in
mind.

Avoiding permanent beta

For Kubernetes REST APIs, when a new feature’s API reaches beta, that starts a countdown.
The beta-quality API now has nine calendar months to either:

• reach GA, and deprecate the beta, or
• have a new beta version (and deprecate the previous beta).

To be clear, at this point only REST APIs are affected. For example, APIListChunking is
a beta feature but isn’t itself a REST API. Right now there are no plans to automatically
deprecate APIListChunking nor any other features that aren’t REST APIs.

If a REST API reaches the end of that 9 month countdown, then the next Kubernetes release
will deprecate that API version. There’s no option for the REST API to stay at the same
beta version beyond the first Kubernetes release to come out after the 9 month window.

What this means for you

If you’re using Kubernetes, there’s a good chance that you’re using a beta feature. Like
I said, there are lots of them about.
As well as Ingress, you might be using CronJob,
or PodSecurityPolicy, or others.
There’s an even bigger chance that you’re running on a control plane with at least one beta
feature enabled.

If you’re using or generating Kubernetes manifests that use beta APIs like Ingress, you’ll
need to plan to revise those. The current APIs are going to be deprecated following a
schedule (the 9 months I mentioned earlier) and after a further 9 months those deprecated
APIs will be removed. At that point, to stay current with Kubernetes, you should already
have migrated.

What this means for Kubernetes contributors

The motivation here seems pretty clear: get features stable. Guaranteeing that beta
features will be deprecated adds a pretty big incentive so that people who want the
feature continue their effort until the code, documentation and tests are ready for this
feature to graduate to stable, backed by several Kubernetes’ releases of evidence in
real-world use.

What this means for the ecosystem

In my opinion, these harsh-seeming measures make a lot of sense, and are going to be
good for Kubernetes. Deprecating existing APIs, through a rule that applies across all
the different Special Interest Groups (SIGs), helps avoid stagnation and encourages
fixes.

Let’s say that an API goes to beta and then real-world experience shows that it
just isn’t right – that, fundamentally, the API has shortcomings. With that 9 month
countdown ticking, the people involved have the means and the justification to revise
and release an API that deals with the problem cases. Anyone who wants to live with
the deprecated API is welcome to – Kubernetes is open source – but their needs do not
have to hold up progress on the feature.