Kubernetes 1.37: Descontinuação do IPVS no Kube-Proxy e Estabilização da API metrics.k8s.io
Aprofundamento CEVIU
Aprofundamento
A versão 1.37 do Kubernetes traz mudanças importantes para quem lida com a plataforma diariamente. Uma das descontinuações mais notáveis é o modo IPVS no kube-proxy. Historicamente introduzido na versão 1.8 para resolver gargalos de performance do iptables, o IPVS agora está em fase de saída por depender ainda do iptables e por não conseguir implementar Serviços Kubernetes de forma autônoma. Clusters rodando com IPVS verão avisos de deprecation, com a previsão de desativação por padrão na versão 1.40 e remoção total na 1.43.
Outro ponto crucial é a estabilização da API metrics.k8s.io, uma base para recursos como o Horizontal Pod Autoscaler (HPA) e comandos kubectl top. A API entra em status GA após quase nove anos em Beta, sinalizando maturidade e confiabilidade. Do lado da segurança e isolamento, o kubelet em User Namespace, ou Rootless Mode, alcança a fase Beta. Isso permite que componentes de nó operem sem privilégios de root, um ganho considerável para limitar o impacto de vulnerabilidades. A remoção gradual do suporte a Cgroup v1 continua, empurrando o ecossistema para o Cgroup v2 e suas capacidades mais avançadas de gerenciamento de recursos.
O que mudou
O cenário de rede do Kubernetes vê uma mudança significativa. O modo IPVS no kube-proxy, introduzido na versão 1.8 como uma otimização sobre o iptables, está sendo descontinuado. Isso é uma evolução na arquitetura de rede, reconhecendo que o IPVS não atingiu a autonomia esperada, ainda dependendo do iptables para certas funcionalidades.
A API metrics.k8s.io, fundamental para observabilidade e escalabilidade, alcança o status de estável (GA) após quase nove anos em Beta. Isso representa um amadurecimento e uma validação de seu design e funcionalidade. Além disso, o Kubelet em User Namespace (Rootless Mode), que oferece maior segurança ao permitir que componentes de nó operem sem privilégios de root, avança para a fase Beta, indicando maior estabilidade e adoção em ambientes de produção.
Por que isso importa
Para engenheiros de plataforma e equipes de DevOps, as mudanças na versão 1.37 do Kubernetes são cruciais para a manutenção da saúde e segurança dos clusters. A descontinuação do IPVS exige planejamento para a migração, evitando interrupções. A estabilização da API de métricas garante uma base mais sólida para automação e observabilidade, essenciais para sistemas resilientes.
A evolução do Kubelet para um modo sem root e a transição para Cgroup v2 são avanços importantes em segurança e gerenciamento de recursos, respectivamente. Entender e implementar essas novidades proativamente assegura que os ambientes Kubernetes permaneçam atualizados, seguros e eficientes, aproveitando as últimas melhorias da comunidade.
Linha do tempo
CEVIU News publica notícia sobre as novidades do Kubernetes 1.37.
Previsão de lançamento oficial do Kubernetes 1.37.
Perguntas frequentes
O que significa a descontinuação do IPVS no kube-proxy?
Significa que o modo IPVS, usado para balanceamento de carga de serviços, será removido em versões futuras do Kubernetes. A partir da versão 1.37, clusters usando IPVS começarão a receber avisos de deprecation, preparando para sua desativação padrão na versão 1.40 e remoção completa na 1.43. É um movimento para simplificar a arquitetura de rede e focar em soluções mais robustas.
Por que a API metrics.k8s.io demorou tanto para ficar estável?
A API metrics.k8s.io passou por quase nove anos em fase Beta. Esse longo período reflete a necessidade de garantir ampla compatibilidade, robustez e funcionalidade em diversos cenários de uso. Sua estabilização na versão 1.37 indica que a API atingiu um nível de maturidade e confiança da comunidade, tornando-a segura para uso em produção sem grandes mudanças futuras.
Quais os benefícios do Kubelet em User Namespace (Rootless Mode)?
O Kubelet em User Namespace, que agora está em Beta, permite que os componentes de nó do Kubernetes funcionem como um usuário sem privilégios no sistema hospedeiro. Isso cria uma camada extra de isolamento. O principal benefício é a redução do risco em caso de vulnerabilidades, pois qualquer comprometimento desses componentes teria um impacto limitado no sistema operacional subjacente.
Como a remoção do cgroup v1 afeta meus clusters?
A remoção gradual do suporte ao cgroup v1 implica que os clusters precisarão migrar para o cgroup v2. Isso é importante porque distribuições Linux modernas e runtimes de contêineres já utilizam cgroup v2 por padrão. A transição garante compatibilidade com tecnologias mais recentes e acesso a recursos avançados de gerenciamento de recursos, como o redimensionamento de Pods em tempo real e proteção de memória hierárquica.
Fontes
- kubernetes.iofonte original
- Categoria
- CEVIU DevOps
- Publicado
- 03 de agosto de 2026
- Editoria
- CEVIU DevOps
