Kubernetes 1.37: rootless chega a beta, o piloto continua necessário

O que muda — e o que fica igual

O projeto Kubernetes publicou em 4 de setembro de 2026 a promoção de KubeletInUserNamespace a beta na versão 1.37. O gate passa a estar ativo por defeito, mas não cria por si um user namespace: os clusters existentes que executam componentes como root não são convertidos automaticamente.

A funcionalidade trata dos componentes do nó, incluindo kubelet e runtimes, a correrem como utilizador não privilegiado no host. É distinta de hostUsers: false nos pods, que coloca esses pods em namespaces de utilizador. A distinção interessa porque um manifesto de aplicação não demonstra com que privilégios o nó funciona.

O anúncio também explicita que esta fronteira não mitiga vulnerabilidades do próprio kernel. A leitura correta é uma camada adicional a avaliar, não uma promessa de isolamento absoluto. Atualizações, controlo de acesso e restrição de capacidades continuam a fazer parte do desenho operacional.

Autorize um piloto com pré-requisitos escritos

O guia oficial enumera cgroup v2, systemd com sessão de utilizador, configuração adequada de sysctl à distribuição e entradas para o utilizador em /etc/subuid e /etc/subgid. A lista histórica refere Kubernetes 1.22 ou superior; o estado beta tratado aqui é o de 1.37. Não confunda a versão mínima em que surgiu a experiência com o marco de maturidade agora anunciado.

Se a opção escolhida for Docker rootless, a documentação exige newuidmap e newgidmap, além de pelo menos 65 536 identificadores subordinados de utilizador e grupo. Este é um requisito dessa opção, não uma licença para aplicar os mesmos comandos a qualquer distribuição ou desligar o runtime de produção.

Propomos um host ou conjunto de nós isolado, sem dados únicos e com configuração anterior preservada. Antes de migrar uma carga, confirme os seus volumes e plugins: o guia avisa que a maioria dos drivers de volumes não locais, como NFS e iSCSI, não funciona neste contexto, e que alguns CNI podem não funcionar. Uma lista de pods em execução não demonstra compatibilidade de leitura, escrita ou rede.

• Identidade: verificar o utilizador real dos processos e o estado do nó; guardar versão do kernel, runtime, Kubernetes e configuração relevante, sem segredos.
• Carga: testar resolução de nomes, tráfego entre pods, acesso autorizado aos volumes, limites de recursos e recolha de logs com dados sintéticos.
• Recuperação: reiniciar o nó de ensaio, confirmar o regresso do serviço e restaurar um volume de teste; interromper a adoção se o driver exigir privilégios incompatíveis.
• Retorno: manter capacidade fora do piloto, retirar a carga de teste de forma controlada e restaurar a configuração conhecida se os critérios não forem cumpridos.

Perspetiva Velqory: decidir pela carga, não pelo rótulo

Para equipas pequenas, um ambiente de desenvolvimento ou de integração contínua pode ser um candidato a avaliação antes de uma carga com armazenamento crítico. Isto é uma proposta de sequência, não uma recomendação universal de migração. A escolha depende da compatibilidade, da equipa que mantém o host e do custo de recuperar uma falha.

O critério de avanço deve ser operacional: a mesma carga cumpre os resultados mínimos de rede, dados e recuperação sem exceções de privilégio que anulem a intenção do piloto? Se a resposta for desconhecida, manter o ambiente atual é uma decisão válida enquanto se recolhe prova. A beta não obriga a alterar a produção.

Fontes e validade: anúncio e documentação Kubernetes, complementados pelos pré-requisitos de Docker rootless, consultados em 6 de setembro de 2026. Não executámos este piloto nem medimos desempenho. Rever após mudanças de versão, kernel, runtime ou drivers; confirmar novamente as limitações antes de implementar.