API Version

Para que las funcionalidades y los recursos de Kubernetes sean creados también son necesarias nuevas APIs.

Las versiones estables son las que llamamos de V1.

Pero encontramos por el camino varias versiones diferentes y vamos a entender cómo ellas aparecen.

Explicando mejor cada una de ellas tenemos:

Alpha

Cuando una API acabó de ser incluida en el código de Kubernetes por la primera vez

No está disponible por padrón y precisa ser habilitada para ser usada.

Todavía puede tener bugs y puede ser depreciada rápidamente. Generalmente es utilizada por usuarios que tienen interés en dar su feedback y colaborar con Kubernetes. No debe ser usada en producción.

Crear un objeto alpha que no está habilitado no funcionará.

Beta

Avanzando un poco en la versión alpha con bugs ya corregidos tenemos la beta.

Esta ya está disponible por padrón, todavía puede contener errores menores, pero ya fue testada y aprobada incluyendo tests end to end. La tendencia es que en el futuro ellas pasen a ser v1, pero no es garantizado.

GA Stable

Después de algunos meses y algunas releases las betas pasan para GA que son consideradas las versiones estables que conocemos v1. Son mucho más confiables y estarán presentes en varias releases futuras de Kubernetes pudiendo ser usadas por todos los usuarios.

Aquí tenemos un ejemplo de la versión 1.30 de Kubernetes.

Si quiere buscar otras versiones

Un ejemplo de la evolución.

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

Podemos observar que el Kubernetes soporta varias versiones al mismo tiempo a fin de dar soporte a versiones anteriores.

---

Podemos observar que el API group ofrece soporte a varias versiones al mismo tiempo. Eso significa que seremos capaces de crear el mismo objeto usando cualquiera de esas versiones.

Aunque soporte varias versiones, solamente una puede ser la versión preferencial o almacenada.

La versión preferencial es aquella que es recuperada por el comando kubectl y la almacenada es aquella que es almacenada en el etcd.

Cuando una versión es definida diferente de la preferencial ella es convertida para la versión preferencial.

> 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"
  }
}

Para observar lo que tenemos dentro del etcd es necesario realizar la búsqueda en el propio etcd.

Para habilitar las versiones alpha podemos pasar el parámetro para el servicio del kube-api-server.

En el caso para habilitar la versión v2alpha1 del batch podemos pasar

--runtime-config=batch/v2alpha1

Es necesario la reinicialización del servicio si for pod estático o servicio en el sistema operativo.