Kubernetes 1.22 transforma APIs antigas em dívida de upgrade

Kubernetes 1.22 chegou com 53 enhancements e uma mudança que deve ocupar times de plataforma: a remoção de várias APIs beta que já estavam depreciadas.¹ O release troca tolerância histórica por disciplina de compatibilidade.

Isso inclui versões beta de recursos como Ingress, IngressClass, Lease, APIService, webhooks de admissão, CustomResourceDefinition, revisões de acesso e CertificateSigningRequest, em favor das APIs estáveis correspondentes.¹ Objetos existentes continuam acessíveis por APIs GA, mas manifests, Helm charts, operadores e integrações que ainda chamam versões antigas podem quebrar.

Depreciação deixou de ser aviso distante

Kubernetes sempre sinalizou depreciações com antecedência, mas muitos ambientes tratam o aviso como ruído. A versão 1.22 mostra o custo dessa postura. Quando a API sai, não basta atualizar o binário do cluster. É preciso revisar tudo que conversa com o API server.

Esse trabalho passa por repositórios de infraestrutura, pipelines de CI/CD, charts de terceiros, templates internos, controladores customizados, ferramentas de backup, scanners de segurança e documentação de times de aplicação. Um apiVersion antigo em um manifesto esquecido pode bloquear deploy no pior momento.

O ponto não é punir usuários. Remover APIs antigas reduz carga de manutenção, testes e ambiguidade para o projeto. O problema aparece quando organizações deixam a compatibilidade para a semana do upgrade. Em Kubernetes, API é contrato de produção. Contrato vencido precisa ser renegociado antes da janela de mudança.

Plataforma precisa enxergar manifests

Para equipes de SRE e plataforma, Kubernetes 1.22 pede inventário de uso de API. Isso envolve varrer repositórios, inspecionar objetos no cluster, validar charts contra versões novas e rodar testes de admissão antes da atualização real.

Ferramentas de política também ganham importância. Gatekeepers, linters, validação em pull request e ambientes de staging devem bloquear APIs depreciadas cedo. A mensagem precisa chegar ao time de aplicação quando o manifesto é escrito, não quando o cluster de produção rejeita o deploy.

Operadores e CRDs exigem cuidado adicional. Muitos produtos cloud native empacotam seus próprios controladores e podem depender de versões específicas do Kubernetes. Antes de atualizar o cluster, é preciso verificar matriz de suporte do fornecedor, versão do operador e planos de migração.

Segurança e estabilidade avançam juntas

O release também traz avanços relevantes fora das remoções. Windows CSI chega a GA, há mecanismo estável de aviso para uso de APIs depreciadas, recursos ligados a seccomp avançam e o PodSecurity admission aparece como substituto planejado para PodSecurityPolicy.¹

Essas mudanças reforçam a maturidade da plataforma. Kubernetes cresce quando remove arestas antigas e oferece caminhos mais claros para operação segura. Mas maturidade do projeto exige maturidade do consumidor. Clusters de produção precisam ter processo contínuo de leitura de release notes, testes automatizados e rastreabilidade de dependências.

A versão 1.22 é um bom filtro de realidade. Quem trata Kubernetes como produto gerenciado invisível pode descobrir que suas aplicações ainda falam dialetos antigos da API. Quem trata a plataforma como engenharia viva tem uma oportunidade de reduzir dívida e preparar upgrades com menos improviso.