Kubernetes: detecte e resolva APIs descontinuadas automaticamente

Conforme o conjunto de funcionalidades do Kubernetes evolui, as APIs também precisam acompanhar esse movimento. Existem regras definidas para garantir compatibilidade e estabilidade¹. Isso não acontece a cada release, mas, em algum momento, você vai precisar usar a nova versão e o novo formato da API, já que a versão antiga deixará de ser suportada.

Algumas APIs descontinuadas foram mantidas nas últimas versões do K8s e finalmente serão removidas de vez na release 1.16 do Kubernetes. São elas, com seus respectivos API Groups e versões:

• Deployment — extensions/v1beta1, apps/v1beta1 e apps/v1beta2
• NetworkPolicy — extensions/v1beta1
• PodSecurityPolicy — extensions/v1beta1
• DaemonSet — extensions/v1beta1 e apps/v1beta2
• StatefulSet — apps/v1beta1 e apps/v1beta2
• ReplicaSet — extensions/v1beta1, apps/v1beta1 e apps/v1beta2

Se você tentar criar um recurso usando uma dessas APIs no 1.16, a operação simplesmente vai falhar.

Dá para revisar manualmente todos os seus manifestos, mas isso pode tomar um bom tempo. É fácil deixar algo passar, e a coisa fica ainda mais complicada quando há várias equipes fazendo deploy no cluster ou quando os manifestos atuais não estão centralizados em um só lugar. É aí que entra o Kube-No-Trouble, ou kubent.

Normalmente, a informação sobre qual versão da API foi usada para criar um determinado recurso não fica acessível, já que o recurso é sempre convertido e armazenado internamente na versão de armazenamento preferencial. Mas, se você usa kubectl ou Helm para fazer deploy dos seus recursos, o manifesto original também fica armazenado dentro do cluster — e dá para tirar proveito disso².

A forma mais simples de instalar é:

sh -c "$(curl -sSL 'https://git.io/install-kubent')"

Isso instala a versão mais recente do kubent em /usr/local/bin ³.

Configure o contexto atual do kubectl para apontar para o cluster que você quer verificar e rode a ferramenta kubent:

Fig. 1: Exemplo de saída da execução do kubent

O kubent se conecta ao seu cluster, busca todos os recursos potencialmente afetados, faz a varredura e mostra um resumo dos que foram identificados.

Você também pode usar a flag -f json para obter a saída em formato JSON, o que é mais útil se quiser integrar a ferramenta ao seu pipeline de CI/CD ou processar os resultados depois. Mais detalhes sobre as opções de configuração disponíveis estão no README do repositório doitintl/kube-no-trouble.

Em alguns casos, basta alterar o apiVersion no manifesto. Em outros, a estrutura pode ter mudado e vai ser preciso fazer ajustes. Vale também ficar atento: muitos valores padrão mudaram entre as versões⁴, então, só trocando o apiVersion e aplicando o mesmo manifesto, o resultado pode ser bem diferente do esperado. Por exemplo, o updateStrategy.type do StatefulSet mudou de OnDelete para RollingUpdate, o que muda bastante o comportamento.

O comando kubectl convert, antes bastante usado, agora está descontinuado e pode não converter seus recursos corretamente em relação aos valores padrão mencionados acima.

Talvez a melhor abordagem seja simplesmente aplicar os recursos (que você já tem em mãos, se os detectou com o kubent) e buscar a nova versão pela API. Isso garante que o recurso seja transformado corretamente para a nova versão. Você deve ter notado que o kubectl é meio não determinístico quanto à versão que retorna. Para solicitar uma versão específica da API, use o formato completo:

kubectl get ingress.v1beta1.extensions -o yaml

Espero que isso ajude você a identificar e lidar com APIs descontinuadas nos seus clusters Kubernetes antes que elas virem dor de cabeça.

A ferramenta kubent ainda está em estágio inicial e eu adoraria receber comentários, sugestões e saber se ela foi útil para você. Boa navegação! ⛵⛵⛵

• [1] O documento Deprecation Policy do Kubernetes define como diferentes partes do sistema podem ser tornadas obsoletas e removidas.
• [2] Isso acontece na forma da anotação kubectl.kubernetes.io/last-applied-configuration no caso do kubectl, ou como um ConfigMap ou Secret no caso do Helm.
• [3] Se, assim como eu, você não confia em scripts aleatórios postados em blogs, baixe a release mais recente para sua plataforma e descompacte onde preferir.
• [4] Um ótimo artigo sobre o tema é o Kubernetes 1.16 API deprecations and changed defaults, do David Schweikert.

Referências adicionais:

• Kube-No-Trouble — repositório do kubent no GitHub — https://github.com/doitintl/kube-no-trouble
• Post Deprecated APIs Removed In 1.16: Here"s What You Need To Know, por Vallery Lancey — https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/