Adeus gitRepo, IPVS, Ingress-NGINX: as novidades que o Kubernetes 1.36 traz

Pois é, parece que abril foi o mês das despedidas no mundo do Kubernetes. No dia 22, o time de release entregou a versão 1.36 “Haru”  e junto com ela vieram funcionalidades importantes, mas também três aposentadorias que vão doer em quem deixou pra adiar a migração.

Se o seu cluster ainda usa gitRepo, IPVS no kube-proxy ou Ingress-NGINX, prepara o café. A gente precisa conversar.

Pois é, parece que abril foi o mês das despedidas no mundo do Kubernetes. No dia 22, o time de release entregou a versão 1.36 “Haru”  e junto com ela vieram funcionalidades importantes, mas também três aposentadorias que vão doer em quem deixou pra adiar a migração.

Se o seu cluster ainda usa gitRepo, IPVS no kube-proxy ou Ingress-NGINX, prepara o café. A gente precisa conversar.

O que é o Haru  e por que esse release importa

“Haru” (春) significa primavera em japonês, e o time escolheu o nome para marcar o primeiro release de 2026 como um momento de céu limpo e horizonte aberto. Beleza, poesia à parte, o número é robusto: 70 enhancements no total, sendo 18 promovidos a estável, 25 entrando em beta e 25 novos alphas. Tudo entregue em 15 semanas, com contribuição de 491 desenvolvedores de 106 empresas  e mais de 2.200 colaboradores se a gente contar o ecossistema cloud-native completo em volta.

A leitura que vale aqui não é “olha quanta novidade brilhante”. É outra: o Kubernetes está num momento de maturidade operacional. Em vez de empilhar paradigma novo, o projeto está graduando coisas que já deveriam ter saído há tempos e jogando fora código que virou risco. É o tipo de release menos sexy para o marketing, mas que o pessoal de plataforma adora.

Os destaques: o que graduou para estável

A graduação mais aguardada  e celebrada  é a User Namespaces (KEP-127) finalmente em GA, depois de vários anos em desenvolvimento alpha desde a v1.25. Em outras palavras: agora você consegue rodar pods cujo root dentro do container não é o root do nó. O isolamento de containers em ambientes multi-tenant, que sempre foi um dos calcanhares de Aquiles do Kubernetes, ganhou um avanço estrutural. Vale lembrar que é uma feature exclusiva de Linux  e que faz toda a diferença para quem leva DevSecOps a sério.

Logo atrás vem o SELinux mount acelerado (KEP-1710) em GA. Em clusters com SELinux em modo enforcing, antes era preciso fazer relabel recursivo de cada arquivo do volume  operação que travava o startup de pods com volumes grandes. Agora a flag -o context=XYZ aplica o label inteiro no momento do mount. Spoiler: para quem roda RHEL, AlmaLinux ou Rocky com SELinux ativo (e deveria), o tempo de inicialização de pods vai cair de forma sensível.

E tem mais coisa boa subindo:

• OCI Volumes estáveis, permitindo montar imagens OCI (artefatos, modelos de IA, datasets) diretamente como volume abrindo caminho pra fluxos de MLOps mais limpos.
• HPA com scale-to-zero, recurso que muita gente da CNCF pediu há anos pra workloads com tráfego intermitente.
• Gateway API v1.5 (lançada em fevereiro) como o substituto definitivo do Ingress, com mais recursos saindo do “experimental” para o “standard”.

As deprecações que vão te morder

Beleza, mas onde isso entra no seu dia a dia? Aqui:

1. O plugin gitRepo foi removido. Ele permitia clonar um repositório Git diretamente como volume de um pod. Parecia útil, mas era um vetor clássico para execução de código como root no nó. Saiu de cena por motivo de segurança, ponto. Se você ainda usa em algum manifesto antigo (e você provavelmente nem lembra), o upgrade vai quebrar. Migre para initContainer com clone explícito ou use ConfigMap/Secret.

2. O modo IPVS no kube-proxy foi removido. Foi deprecado na 1.35 e agora caiu de vez. Quem ainda depende disso precisa migrar para nftables (recomendado) ou iptables. Em clusters grandes, faça isso num ambiente de homologação primeiro  comportamento de balanceamento muda em casos de borda.

3. Ingress-NGINX foi aposentado. Esse é o golpe maior. Em 24 de março de 2026, o SIG Network e o Security Response Committee anunciaram oficialmente o fim do projeto. Os deployments existentes continuam funcionando, charts e imagens permanecem no registry, mas não haverá mais releases, bugfixes nem patches de segurança. Sim, nem para CVEs novos. Convenhamos: ingress-nginx é um componente que fica no caminho crítico do tráfego, faz TLS, expõe seus workloads para a internet. Rodar um software sem manutenção nessa posição é dívida técnica que vira dívida de segurança em questão de meses.

A pergunta mais importante não é se você vai migrar é se você vai migrar antes ou depois do primeiro CVE crítico aparecer e ninguém corrigir.

Antes de subir o cluster, atenção

Se você cuida de cluster em produção, esse é o checklist mínimo:

• Audite manifestos antigos procurando gitRepo  kubectl get pods –all-namespaces -o yaml | grep gitRepo é um começo.
• Verifique a configuração do kube-proxy  se o mode estiver em ipvs, planeje a transição.
• Faça inventário do seu ingress controller atual  se for Ingress-NGINX, comece o piloto com Gateway API (Istio Gateway, Kong, Envoy Gateway, Traefik 3+, ou o próprio nginx-gateway-fabric da F5).
• Em hosts com SELinux, atenção: na v1.37 (prevista para o segundo semestre), o feature gate SELinuxMount vai ligar por padrão. Workloads que dependiam do comportamento antigo podem quebrar  antecipe testes agora.

Vale também conferir o status dos seus volumes persistentes. O 1.36 introduziu, em alpha, o campo status.lastUsedTime em PVCs. É pequeno, mas resolve um problema que toda equipe de mais de seis meses tem: PVCs órfãos consumindo storage. Quando graduar, vai ser o tipo de coisa que paga o upgrade só na economia de cloud.

E se você ainda está numa versão antiga?

Pois é. O Kubernetes mantém suporte ativo apenas para as três últimas minor versions  agora 1.36, 1.35 e 1.34. Quem está em 1.33 ou anteriores rodando em produção já está fora do ciclo oficial de patches. Em ambientes regulados (financeiro, saúde, governo), isso é assunto de auditoria.

A 4Linux trabalha desde 2015 com formação Kubernetes para times de operações no Brasil, e o padrão que vemos é o mesmo de sempre: o upgrade não é o problema, o problema é a dívida acumulada que aparece quando você tenta subir. Por isso, faça a migração em saltos curtos (1.33 → 1.34 → 1.35 → 1.36), com homologação real, não pulando de cabeça.

No fim das contas

O Kubernetes 1.36 não vai ganhar manchete na imprensa generalista. Não tem demo bombástica, não tem reescrita radical, não promete revolucionar nada. E é exatamente por isso que ele é importante: é um release que arruma a casa.

User Namespaces em GA fecha um buraco de isolamento que existia desde sempre. SELinux mount acelerado tira fricção. O fim do gitRepo, do IPVS e do Ingress-NGINX limpa código velho que estava virando responsabilidade de quem opera. E o Gateway API consolida-se como o futuro definitivo de roteamento no cluster.

A pergunta que fica não é “o que de novo eu posso usar?”. É outra: quanto da minha infra de hoje sobrevive ao Haru? Quem tem essa resposta na ponta da língua dorme melhor.

E você, já abriu o kubectl describe pra ver como anda seu cluster?

Fontes

• Kubernetes v1.36 release announcement (kubernetes.io/blog)
• Kubernetes v1.36 Sneak Peek (kubernetes.io/blog)
• Ingress-NGINX retirement announcement (SIG Network)
• Gateway API v1.5 release notes
• Kubernetes Releases — supported versions