Alpha, Beta, and Stable

Kubernetes has a strict process for accepting new API resources. New resources come in as alpha, progress through beta, and eventually graduate as Generally Available (GA). We sometimes refer to GA as stable.

Alpha resources are experimental and should be considered hairy and scary. Expect bugs, expect features to be dropped without warning, and expect lots of things to change when they move into beta. A lot of clusters turn off alpha APIs by default.

Lifecycle of Kubernetes API resources

A new resource called xyz in the apps API group that goes through two alpha versions will have the following API names:

• /apis/apps/v1alpha1/xyz

• /apis/apps/v1alpha2/xyz

The phase after alpha is beta.

Beta resources are considered pre-release and are starting to look like the final GA product. However, we should expect small changes when promoted to GA. Most clusters enable beta APIs by default, and some people use beta resources in production. However, that’s not a recommendation, we need to make those decisions ourself.

The same xyz resource in the apps API group that progresses through two beta versions will be served through the following APIs:

• /apis/apps/v1beta1/xyz

• /apis/apps/v1beta2/xyz

The final phase after beta is Generally Available (GA), sometimes referred to as stable.

GA resources are considered production-ready, and Kubernetes has a strong long-term commitment to them.

Most GA resources are v1. However, some have continued to evolve and progressed to v2. If we want to create a v2 version of a resource, we have to put it through the same incubation and graduation process. For example, the xyz resource in the apps API would go through the same alpha and beta process before reaching v2

• /apis/apps/v2alpha1/xyz

• /apis/apps/v2beta1/xyz

• /apis/apps/v2/xyz

Examples of paths to stable resources include the following:

• /apis/networking.k8s.io/v1/ingresses

• /apis/batch/v1/cronjobs

• /apis/autoscaling/v2/horizontalpodautoscalers

We can normally deploy an object via one API, then read it back and manage it using a more recent API. For example, we can deploy an object via a v1beta2 API and then update and manage it later through the stable v1 API.

Resource deprecation

As mentioned in the previous section, alpha and beta objects will experience a lot of changes before being promoted to GA. However, once an object is GA, it doesn’t change, and Kubernetes is strongly committed to maintaining long-term usability and support.

At the time of writing, Kubernetes has the following commitments to beta and GA resources:

• Beta: Resources in beta have a 9-month window to either release a newer beta version or graduate to GA. This is to prevent resources from staying permanently in beta. For example, the Ingress resource remained in beta for over 15 Kubernetes releases!

• GA: GA resources are expected to be long-lived. When deprecated, Kubernetes will continue to serve and support GA objects for 12 months or three releases, whichever is longest.

Recent versions of Kubernetes return deprecation warning messages whenever we use a deprecated resource. For example, deploying an Ingress from the old extensions/v1beta1 API resulted in the following deprecation warning while the v1beta1 API was deprecated.