Você já se pegou revirando um manifesto antigo e se perguntando por que aquela configuração está ali? Se você lida com Kubernetes, sabe que o backlog técnico é um companheiro constante. Recentemente, me deparei com uma notícia que me fez refletir sobre isso. A versão 1.36 do Kubernetes, apelidada de “Haru”, foi lançada — e trouxe algumas despedidas dolorosas, junto com melhorias significativas.

No dia 22 de abril, o Kubernetes 1.36 chegou ao mundo e trouxe consigo a aposentadoria de três componentes que muitos de nós ainda usamos: gitRepo, IPVS no kube-proxy e Ingress-NGINX. Se, como eu, você adiou algumas migrações, é hora de tomar um café forte e encarar as mudanças. A ênfase desta versão não está em novidades chamativas, mas sim em amadurecimento operacional, algo que é música para os ouvidos de quem trabalha com plataforma.

O que aconteceu

A nova versão do Kubernetes, chamada de “Haru”, marca uma fase de consolidação e limpeza de código. Com 70 melhorias, sendo 18 promovidas a estáveis, 25 em beta e 25 novas em alpha, esta versão foi construída em 15 semanas com a participação de 491 desenvolvedores de 106 empresas. O objetivo principal? Graduar recursos que já deveriam estar estáveis há tempos e descartar código que representa riscos.

Entre as novidades estáveis, temos a User Namespaces (KEP-127), que permite rodar pods cujo root não é o root do nó, melhorando o isolamento em ambientes multi-tenant. Outra é a aceleração do SELinux mount (KEP-1710), que promete reduzir o tempo de inicialização de pods em sistemas com SELinux ativo. Além disso, a Gateway API v1.5 consolida-se como o substituto do Ingress, trazendo mais estabilidade ao roteamento de tráfego.

Por que isso importa

Essas mudanças são um reflexo do amadurecimento do Kubernetes como plataforma. Lembro de noites em claro tentando resolver problemas de isolamento de containers — a User Namespaces vem para resolver justamente isso, oferecendo um nível extra de segurança em ambientes complexos. Se você leva DevSecOps a sério, sabe do que estou falando.

A aceleração do SELinux mount é outra vitória para quem, assim como eu, já quebrou a cabeça com pods que demoravam séculos para iniciar em sistemas baseados em RHEL ou derivados. A redução no tempo de start é uma melhoria que, embora técnica, tem impacto direto no dia a dia de quem opera clusters.

Deprecações, como a do gitRepo, podem parecer uma dor de cabeça à primeira vista, mas são cruciais para a segurança. Clonar repositórios Git como volume de um pod sempre me pareceu arriscado — um vetor fácil para execução de código indesejado. Agora, com a remoção, somos forçados a buscar alternativas mais seguras, como initContainers.

Na prática

Se você ainda usa o plugin gitRepo, é hora de migrar. Considere esta configuração em um initContainer que substitui o gitRepo:

template:
  spec:
    containers:
    - name: app-container
      image: myapp:latest
    initContainers:
    - name: git-clone
      image: alpine/git
      args: ["clone", "--", "myrepo.git"]
      volumeMounts:
      - name: git-repo
        mountPath: /repo
    volumes:
    - name: git-repo
      emptyDir: {}

Além disso, se ainda opera com IPVS no kube-proxy, é fundamental planejar a migração para nftables ou iptables — faça isso em um ambiente de homologação para evitar surpresas em produção. Para quem utiliza Ingress-NGINX, o caminho é começar a transição para a Gateway API.

O que eu acho disso

A chegada do Kubernetes 1.36 é um sinal claro de que a plataforma está amadurecendo. Embora as deprecações possam ser vistas como um inconveniente, acredito que são necessárias para garantir a segurança e estabilidade da infraestrutura.

Por outro lado, estou cético quanto à rapidez com que muitas equipes conseguirão adotar essas mudanças. A dívida técnica é um problema real e, em alguns casos, ela pode atrasar a migração para versões mais seguras. Mas, no final, a saúde do cluster agradece.

Fechamento

Estou curioso para saber: como anda a saúde do seu cluster? Já começou a planejar as migrações necessárias para não ficar para trás com a nova versão do Kubernetes? Compartilhe suas experiências!