API Version

Para que as funcionalidades e os recursos do Kubernetes sejam criados também são necessárias novas APIs.

As versões estáveis são as que chamamos de V1.

Mas encontramos pelo caminho várias versões diferentes e vamos entender como elas aparecem.

Explicando melhor cada uma delas temos:

Alpha

Quando uma API acabou de ser incluída no código do Kubernetes pela primeira vez

Não é disponível por padrão e precisa ser habilitada para ser usada.

Ainda pode ter bugs e pode ser depreciada rapidamente. Geralmente é utilizada por usuários que têm interesse em dar seu feedback e colaborar com o Kubernetes. Não deve ser usada em produção.

Criar um objeto alpha que não está habilitado não funcionará.

Beta

Avançando um pouco na versão alpha com bugs já corrigidos temos a beta.

Esta já é disponível por padrão, ainda pode conter erros menores, mas já foi testada e aprovada incluindo testes end to end. A tendência é que no futuro elas passem a ser v1, mas não é garantido.

GA Stable

Depois de alguns meses e algumas releases as betas passam para GA que são consideradas as versões estáveis que conhecemos v1. São muito mais confiáveis e estarão presentes em várias releases futuras do Kubernetes podendo ser usadas por todos os usuários.

Aqui temos um exemplo da versão 1.30 do Kubernetes.

Se quiser buscar outras versões

Um exemplo da evolução.

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

Podemos observar que o Kubernetes suporta várias versões ao mesmo tempo a fim de dar suporte a versões anteriores.

---

Podemos observar que o API group oferece suporte a várias versões ao mesmo tempo. Isso significa que seremos capazes de criar o mesmo objeto usando qualquer uma dessas versões.

Embora suporte várias versões, somente uma pode ser a versão preferencial ou armazenada.

A versão preferencial é aquela que é recuperada pelo comando kubectl e a armazenada é aquela que é armazenada no etcd.

Quando uma versão é definida diferente da preferencial ela é convertida para a versão 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 o que temos dentro do etcd é necessário realizar a busca no próprio etcd.

Para habilitar as versões alpha podemos passar o parâmetro para o serviço do kube-api-server.

No caso para habilitar a versão v2alpha1 do batch podemos passar

--runtime-config=batch/v2alpha1

É necessário a reinicialização do serviço se for pod estático ou serviço no sistema operacional.