Kubernetes 1.36: os riscos das novas mudanças

Você já teve que lidar com uma atualização de versão que quebrou tudo? Quem trabalha com Kubernetes sabe que cada nova versão é um campo minado de mudanças e melhorias. E a versão 1.36, prevista para o final de abril de 2026, não será diferente.

A notícia vem direto do blog oficial do Kubernetes, onde Chad Crowell e sua equipe detalham as novidades. Entre retiradas e depreciações, a versão 1.36 promete acelerar processos e melhorar a segurança, mas sempre com aquele risco de dor de cabeça para quem administra clusters.

O que aconteceu

No anúncio, a equipe do Kubernetes destaca várias mudanças na v1.36. A retirada do suporte ao controle de ingress NGINX é uma das principais mudanças, como parte de um esforço contínuo para melhorar a segurança do ecossistema. A comunidade é incentivada a buscar controladores de ingress alternativos que estejam mais alinhados com as práticas de segurança atuais. Além disso, o campo .spec.externalIPs em Service está sendo depreciado, dada sua vulnerabilidade a ataques man-in-the-middle. Isso tem gerado alertas sobre a necessidade de adaptar serviços para outras soluções de roteamento externo.

Outra grande mudança é a desativação permanente do driver de volume gitRepo, um recurso já obsoleto desde a v1.11, mas que ainda era usado em alguns ambientes. A partir da v1.36, esse caminho está fechado, e qualquer carga de trabalho existente precisará migrar para abordagens suportadas, como contêineres de inicialização ou ferramentas de sincronização externa.

Por que isso importa

Para quem gerencia clusters Kubernetes, as depreciações e remoções não são apenas avisos. Elas representam mudanças necessárias nas práticas operacionais. A retirada de funcionalidades como o gitRepo e o controle de ingress NGINX reflete um movimento contínuo em direção a um ecossistema mais seguro e eficiente. Essas mudanças são sempre uma faca de dois gumes: melhoram a segurança e a eficiência, mas exigem que nós, como profissionais, estejamos sempre atualizados com as melhores práticas.

Historicamente, o Kubernetes tem aprimorado seu processo de depreciação com cada nova versão, oferecendo alternativas e guias de migração claros. O ciclo de vida do Kubernetes é projetado para evoluir sem rupturas abruptas, mas, como sempre, isso depende de nós seguirmos essas diretrizes de perto.

Por exemplo, a substituição do campo .spec.externalIPs por opções como LoadBalancer ou NodePort já era esperada por muitos na comunidade. A novidade aqui é o encorajamento para adotar a API Gateway como uma solução mais flexível, capaz de lidar com o tráfego externo de maneira segura.

Na prática

Para quem está no dia a dia com Kubernetes, essas mudanças significam ajustes em scripts de deployment e políticas de segurança. A remoção do gitRepo exige, por exemplo, que você repense como seus códigos são puxados para dentro de contêineres. Aqui está um exemplo de como usar um contêiner de inicialização para substituir o gitRepo:

apiVersion: v1
kind: Pod
metadata:
  name: git-sync
spec:
  containers:
  - name: main
    image: your-application-image
  initContainers:
  - name: git-sync
    image: k8s.gcr.io/git-sync
    args:
    - "--repo=https://github.com/your/repo.git"
    - "--branch=main"
    - "--root=/git"
    volumeMounts:
    - name: git-volume
      mountPath: /git
  volumes:
  - name: git-volume
    emptyDir: {}

Essa configuração inicializa um contêiner que clona o repositório antes de iniciar o contêiner principal.

O que eu acho disso

Confesso que algumas dessas mudanças, como a depreciação do .spec.externalIPs, são um alívio. Era um campo que já causava dores de cabeça, e sua remoção por questões de segurança faz todo o sentido. No entanto, o ritmo acelerado das mudanças exige que a gente esteja sempre preparado para ajustes constantes, o que pode ser desafiador para times menores.

A retirada do gitRepo é simbólica de uma tendência maior no Kubernetes: abandonar práticas antigas em favor de soluções mais seguras e eficientes. Isso é ótimo, mas também significa que a curva de aprendizado pro Kubernetes nunca estabiliza.

Por fim, a adoção acelerada de features como o SELinux para volumes pode trazer ganhos de performance, mas é necessário cuidado na implementação para evitar misturas perigosas entre pods privilegiados e não privilegiados. A responsabilidade é sempre nossa.

Fechamento

Com tantas mudanças no horizonte, como você está se preparando para a chegada do Kubernetes v1.36? Compartilhe suas estratégias e preocupações nos comentários!