API Version

For Kubernetes functionalities and resources to be created, new APIs are also needed.

Stable versions are what we call V1.

But we encounter several different versions along the way and let's understand how they appear.

Explaining each of them better:

Alpha

When an API has just been included in the Kubernetes code for the first time

It's not available by default and needs to be enabled to be used.

It may still have bugs and can be deprecated quickly. It's generally used by users who are interested in giving their feedback and collaborating with Kubernetes. Should not be used in production.

Creating an alpha object that's not enabled won't work.

Beta

Moving forward a bit from the alpha version with bugs already fixed, we have beta.

This one is available by default, may still contain minor errors, but has already been tested and approved including end-to-end tests. The tendency is for them to become v1 in the future, but it's not guaranteed.

GA Stable

After a few months and a few releases, betas move to GA which are considered the stable versions we know as v1. They're much more reliable and will be present in several future Kubernetes releases and can be used by all users.

Here we have an example of Kubernetes version 1.30.

If you want to search for other versions

An example of evolution:

API GROUP	1.25	1.26	1.27	1.28	1.29	1.30
admissionregistration.k8s.io	v1	v1, v1alpha1	v1, v1alpha1	v1, v1beta1, v1alpha1	v1, v1beta1, v1alpha1	v1, v1beta1, v1alpha1
apiextensions.k8s.io	v1	v1	v1	v1	v1	v1
apiregistration.k8s.io	v1	v1	v1	v1	v1	v1
apps	v1	v1	v1	v1	v1	v1
authentication.k8s.io	v1	v1, v1alpha1	v1, v1beta1, v1alpha1	v1, v1beta1, v1alpha1	v1, v1beta1, v1alpha1	v1, v1beta1, v1alpha1
authorization.k8s.io	v1	v1	v1	v1	v1	v1
autoscaling	v1, v2, v2beta2	v2, v1	v2, v1	v2, v1	v2, v1	v2, v1
batch	v1	v1	v1	v1	v1	v1
certificates.k8s.io	v1	v1	v1, v1alpha1	v1, v1alpha1	v1, v1alpha1	v1, v1alpha1
coordination.k8s.io	v1	v1	v1	v1	v1	v1
core	v1	v1	v1	v1	v1	v1
discovery.k8s.io	v1	v1	v1	v1	v1	v1
events.k8s.io	v1	v1	v1	v1	v1	v1
flowcontrol.apiserver.k8s.io	v1beta2, v1beta1	v1beta3, v1beta2	v1beta3, v1beta2	v1beta3, v1beta2	v1, v1beta3	v1, v1beta3
internal.apiserver.k8s.io	v1alpha1	v1alpha1	v1alpha1	v1alpha1	v1alpha1	v1alpha1
networking.k8s.io	v1, v1alpha1	v1, v1alpha1	v1, v1alpha1	v1, v1alpha1	v1, v1alpha1	v1, v1alpha1
node.k8s.io	v1	v1	v1	v1	v1	v1
policy	v1	v1	v1	v1	v1	v1
rbac.authorization.k8s.io	v1	v1	v1	v1	v1	v1
resource.k8s.io		v1alpha1	v1alpha2	v1alpha2	v1alpha2	v1alpha2
scheduling.k8s.io	v1	v1	v1	v1	v1	v1
storage.k8s.io	v1, v1beta1	v1, v1beta1	v1	v1	v1, v1alpha1	v1, v1alpha1
storagemigration.k8s.io						v1alpha1

We can observe that Kubernetes supports multiple versions at the same time to provide support for previous versions.

---

We can observe that the API group offers support for multiple versions at the same time. This means we'll be able to create the same object using any of these versions.

Although it supports multiple versions, only one can be the preferred or stored version.

The preferred version is the one that's retrieved by the kubectl command and the stored one is the one that's stored in etcd.

When a version is defined different from the preferred one, it's converted to the preferred version.

> kubectl proxy
Starting to serve on 127.0.0.1:8001

❯ curl http://localhost:8001/apis/batch
{
  "kind": "APIGroup",
  "apiVersion": "v1",
  "name": "batch",
  "versions": [
    {
      "groupVersion": "batch/v1",
      "version": "v1"
    }
  ],
  "preferredVersion": {
    "groupVersion": "batch/v1",
    "version": "v1"
  }
}

To observe what we have inside etcd, it's necessary to search in etcd itself.

To enable alpha versions, we can pass the parameter to the kube-api-server service.

In the case of enabling version v2alpha1 of batch, we can pass

--runtime-config=batch/v2alpha1

The service needs to be restarted if it's a static pod or service in the operating system.