O Kubernetes 1.37 promove a Metrics API a estável e o suporte a componentes de nó rootless a beta. Isso não significa que atualizar a versão do cluster habilite toda a cadeia de métricas ou converta seus nós para rootless. A avaliação precisa separar maturidade da API, configuração e compatibilidade dos componentes.

Metrics API: versão estável não instala o provedor

O anúncio específico da Metrics API registra a promoção de metrics.k8s.io/v1, sem mudança nos campos de CPU e memória em relação a v1beta1. O provedor, como o Metrics Server, precisa servir a versão e registrar seu APIService. No Kubernetes 1.37, kubectl top prefere v1 quando disponível, mas o controlador HPA ainda usa v1beta1. Por isso, a documentação orienta manter as duas versões durante a transição. Não é uma substituição de toda a observabilidade do cluster.

Rootless: a opção e o estado real do nó

Segundo a documentação da promoção de rootless a beta, KubeletInUserNamespace fica habilitado por padrão, mas não move automaticamente o kubelet para um namespace de usuário. Clusters existentes que executam esses componentes como root continuam assim. O namespace deve ser preparado externamente. A opção também não deve ser confundida com hostUsers: false, que trata namespaces dos pods. A documentação aponta possíveis incompatibilidades com drivers CNI e CSI e ressalta que namespaces de usuário não mitigam vulnerabilidades do próprio kernel.

Watch cache: duas graduações diferentes

O anúncio do release 1.37 distingue ResilientWatchCacheInitialization, estável desde 1.34, de WatchCacheInitializationPostStartHook, estável e permanentemente habilitado em 1.37, com padrão habilitado desde 1.36. O conjunto reduz pressão na inicialização do cache; não se deve atribuir todo esse comportamento como novidade exclusiva de 1.37.

O KEP-4568 descreve quais requisições podem ser encaminhadas ao etcd e quais são rejeitadas enquanto o cache não está pronto. Clientes precisam tratar respostas de limitação, como HTTP 429, sem transformá-las em tentativas imediatas e ilimitadas.

HPA e certificados: verificar as dependências

O release também promove a escala para zero do HPA a beta, habilitada por padrão. É necessário configurar minReplicas: 0 e usar métricas de objetos ou externas; CPU e memória não permitem essa retomada sem pods ativos. Isso não equivale a desligar nós ou garantir economia de infraestrutura.

A documentação de Pod Certificates e Cluster Trust Bundles descreve fundamentos estáveis para emissão e distribuição de certificados. A arquitetura inclui aplicação, kubelet e um controlador assinador. A aplicação precisa consumir chaves, certificados e bundles para TLS ou mTLS. Portanto, não se trata de criptografia automática de todo o tráfego apenas por atualizar o cluster.

Roteiro proposto para homologação

Antes da atualização, registrar as versões do cluster, runtime, provedor de métricas e plugins de rede e armazenamento. Selecionar workloads de teste representativos e estabelecer os mesmos critérios de aceite para antes e depois.

  • Métricas: conferir as versões realmente servidas, a disponibilidade dos APIServices e a continuidade da decisão do HPA. Uma resposta de kubectl top isoladamente não valida o autoscaling.
  • Rootless: verificar a identidade e o namespace dos processos do nó, além de montagem de volumes e conectividade dos pods de teste. A presença da feature gate não é o critério de sucesso.
  • Recuperação: em laboratório isolado, observar readiness e respostas dos clientes durante reinicialização controlada do plano de controle. Registrar o tempo de recuperação e a quantidade de tentativas, sem simular falhas em produção.
  • Escala para zero: medir o intervalo entre a chegada de trabalho e seu processamento, testar ausência de métricas e verificar separadamente o efeito sobre a capacidade faturada.
  • Certificados: conferir emissão, renovação, consumo pela aplicação e rejeição de uma identidade de teste não autorizada.

O que ficou fora

Esta análise seleciona recursos relevantes para operação; não é uma lista completa de mudanças nem um procedimento de upgrade. Os ensaios propostos não foram executados neste site. Recursos alpha e a sequência de atualização exigem consulta às notas oficiais e à documentação da distribuição usada. A disponibilidade no Kubernetes upstream não comprova suporte imediato de todo provedor gerenciado.