Lançamento do Kubernetes 1.37: novidades, mudanças beta e estáveis

Kubernetes 1.37: recursos estáveis (GA)

1. A Metrics API se torna estável

Grupo do recurso: SIG Instrumentation | KEP: KEP-5207

A API metrics.k8s.io ficou em beta por anos. É a API por trás do kubectl top e das métricas de CPU e memória do Horizontal Pod Autoscaler. Na v1.37, ela finalmente se torna estável.

Não há mudança funcional aqui. Tanto a v1 quanto a v1beta1 continuam funcionando, então você não precisa mudar nada agora. Mas, se você está construindo ferramentas que usam essa API, já pode adotar a v1 com confiança, porque ela é estável e não vai mudar de forma inesperada.

2. Recursos no nível do pod

Antes disso, era preciso definir requests e limits de recursos para cada contêiner de um pod, mesmo que os contêineres fossem feitos para trabalhar juntos.

Os recursos no nível do pod permitem definir requests/limits de CPU, memória e hugepages no nível do pod, em vez do (ou junto com o) nível do contêiner.

spec:
  resources:
    requests:
      cpu: "1"
      memory: "512Mi"
    limits:
      cpu: "2"
      memory: "1Gi"
  containers:
  - name: app
    image: my-app
  - name: sidecar
    image: my-sidecar

Todos os contêineres do pod podem então compartilhar o mesmo pool de recursos, em vez de cada um ter sua própria alocação fixa. Isso reduz o desperdício de recursos e funciona melhor para workloads multi-contêiner com picos de uso de recursos.

3. DRA: taints e tolerations de dispositivos

Grupo do recurso: SIG Scheduling | KEP: KEP-5055

Isso traz o modelo de taints de nós para o Dynamic Resource Allocation (DRA). Drivers DRA ou uma DeviceTaintRule que você mesmo escreve podem aplicar um taint a um dispositivo específico (por exemplo, uma GPU superaquecendo ou sendo drenada para manutenção).

Um taint NoSchedule impede que novos pods usem esse dispositivo, enquanto um taint NoExecute remove os pods que já o estão usando. Se um workload ainda precisar usar o dispositivo, ele pode adicionar uma toleration correspondente ao seu ResourceClaim.

Isso permite isolar uma única GPU ou NIC em vez de fazer cordon no nó inteiro.

4. Tolerância configurável no HPA

Grupo do recurso: SIG Autoscaling | KEP: KEP-4951

O Horizontal Pod Autoscaler (HPA) sempre usou uma tolerância fixa de 10% em todo o cluster para evitar escalonamentos causados por pequenas variações nas métricas. Mas os mesmos 10% não fazem sentido para todo workload. Uma variação de 10% em um workload com 500 pods é muito diferente de uma em um workload com 5 pods.

Com esse recurso agora estável, você pode definir uma tolerância personalizada para cada HPA, com valores separados para scale-up e scale-down em spec.behavior.scaleUp e spec.behavior.scaleDown. Assim, cada workload escala de forma mais adequada sem alterar o padrão do cluster inteiro.

5. Certificados para pods

Grupo do recurso: SIG Auth | KEP: KEP-4317

Isso dá aos pods uma forma nativa de obter certificados X.509 de curta duração sem depender de bearer tokens. Uma nova API PodCertificateRequest cuida da emissão, e um volume projetado PodCertificate permite que o kubelet entregue a chave e o certificado diretamente ao pod, com rotação automática.

Isso torna configurações de mTLS (incluindo ferramentas de terceiros como o HashiCorp Vault) mais fáceis de montar de forma nativa, sem o sidecar extra nem toda a estrutura de webhooks que muitos service meshes usam hoje.

6. Saída KYAML no kubectl

Grupo do recurso: SIG CLI | KEP: KEP-5295

O KYAML é um subconjunto mais rígido do YAML, no estilo Kubernetes: chaves para mapas, colchetes para listas, aspas duplas para strings. Ele continua permitindo comentários e vírgulas finais, mas elimina as armadilhas clássicas do YAML, como interpretar valores silenciosamente como booleano false (o famoso "problema da Noruega").

Agora é uma opção de saída estável do kubectl, então você pode gerar manifestos nesse formato sem se preocupar com coerções de tipo acidentais quebrando sua configuração.

7. Mudança recursiva de labels SELinux mais rápida (SELinuxMount)

Grupo do recurso: SIG Storage | KEP: KEP-1710

Em nós com SELinux habilitado, o Kubernetes costumava rerotular cada arquivo de um volume, um por um, antes que o pod pudesse iniciar. Em um volume com milhões de arquivos, isso sozinho podia levar minutos.

O SELinuxMount chega ao GA e vem habilitado por padrão na v1.37. Em vez de rerotular arquivo por arquivo, os volumes são montados com -o context=<label>; o volume inteiro recebe o label correto em uma única operação de montagem. Isso só entra em ação quando o driver CSI do volume opta por esse comportamento via CSIDriver.spec.seLinuxMount: true.

Um detalhe importante: uma única montagem só pode carregar um contexto SELinux. Se hoje você tem pods com labels SELinux diferentes compartilhando o mesmo volume no mesmo nó (o que funcionava bem com a antiga rerotulagem recursiva), esses pods podem passar a falhar na inicialização. Se precisar do comportamento antigo para um workload específico, defina seLinuxChangePolicy: Recursive na spec do pod. Clusters sem SELinux habilitado não veem mudança alguma.

Recursos beta do Kubernetes 1.37

8. Kubelet em user namespace (modo rootless)

Grupo do recurso: SIG Node | KEP: KEP-2033

Componentes do nó, como o kubelet, normalmente rodam como root no host. Se o kubelet for comprometido, um invasor pode obter acesso root ao nó.

O Kubelet in UserNS executa o kubelet dentro de um user namespace do Linux. Ele continua parecendo rodar como root dentro do namespace, mas no host real é mapeado para um usuário sem privilégios. Esse recurso passa para beta no Kubernetes v1.37 e adiciona uma camada extra de isolamento sem mudar a forma como você usa o kubelet no dia a dia.

9. HPA com escala de/para zero em métricas de objeto e externas

Grupo do recurso: SIG Autoscaling | KEP: KEP-2021

O Horizontal Pod Autoscaler (HPA) já consegue escalar para zero réplicas usando métricas de objeto ou externas há algum tempo. Mas não havia uma forma fácil de saber se foi o HPA que escalou um workload para zero ou se alguém o zerou de outra maneira.

O Kubernetes v1.37 adiciona uma condição de status ScaledToZero ao objeto HPA, deixando essa diferença clara. Isso é especialmente útil para workloads orientados a eventos, como os que usam profundidade de fila ou gatilhos no estilo KEDA, que escalam para zero quando ociosos e voltam a escalar quando chega trabalho novo.

10. Serializador CBOR

Grupo do recurso: SIG API Machinery | KEP: KEP-4222

Os recursos nativos do Kubernetes usam Protobuf para manter as chamadas de API rápidas, mas CRDs não conseguem usar Protobuf facilmente, já que ele exige geração de código em tempo de compilação. O CBOR é um formato binário que não tem esse requisito, e benchmarks iniciais mostram codificação até 8x mais rápida e decodificação 2x mais rápida para recursos personalizados em comparação com JSON. Os clientes negociam o formato automaticamente e recorrem ao JSON com servidores de API mais antigos, então a adoção acontece com segurança.

Recursos alpha do Kubernetes 1.37

Estes recursos estão em alpha: não estão prontos para produção, mas vale a pena testá-los em um cluster de staging.

11. Volume Health Monitor

Grupo do recurso: SIG Storage | KEP: KEP-1432

Hoje, se um volume CSI tem um problema no nível do armazenamento, você normalmente só descobre por causa de uma montagem que falhou ou de um travamento de I/O; não há um sinal estruturado para agir. Este recurso introduz quatro novos RPCs CSI para que os drivers possam reportar a saúde dos volumes de uma forma que os controllers consigam usar. No lado do controller, ControllerListVolumeHealth lista volumes com problemas e ControllerGetVolumeHealth verifica um volume específico; um monitor de saúde no lado do controller consulta esses RPCs e grava o resultado em PersistentVolumeClaim.status.healthStatus. No lado do nó, o kubelet chama NodeGetVolumeHealth para volumes individuais (registrado em Pod.status.volumeHealth) e NodeGetStorageHealth para a saúde dos drivers naquele nó. Isso dá aos controllers de remediação algo legível por máquina para agir, em vez de cruzar dashboards de fornecedores manualmente.

12. ulimits por contêiner

Grupo do recurso: SIG Node | KEP: KEP-5758

Algumas aplicações, como bancos de dados e sistemas de alta concorrência, precisam de limites POSIX mais altos — como o número máximo de arquivos abertos ou de processos — do que o runtime de contêiner fornece por padrão. Até agora, as opções usuais eram scripts de entrypoint personalizados ou mudanças na configuração do host.

O Kubernetes v1.37 adiciona um campo ulimits ao Container.SecurityContext. O kubelet repassa esses limites ao runtime de contêiner. Por enquanto, o recurso funciona apenas com o perfil Privileged dos Pod Security Standards, e o Kubernetes verifica o suporte do nó antes de agendar o pod, para que ele não rode em um nó que não consiga aplicar os limites exigidos.

13. DRA: atributos derivados

Grupo do recurso: SIG Scheduling | KEP: KEP-6080

O DRA já consegue combinar dispositivos por atributos compartilhados, mas apenas se fornecedores de hardware diferentes usarem o mesmo nome de atributo — o que geralmente não acontece. Digamos que você queira uma GPU e uma NIC rápida no mesmo nó NUMA: o scheduler precisa de nomes e valores de atributos correspondentes, mas cada fornecedor descreve a topologia à sua maneira.

Os atributos derivados permitem escrever uma expressão CEL na sua solicitação de dispositivo que constrói um atributo virtual a partir do que o driver já expõe. Isso dá a você uma chave comum, como um ID de nó NUMA, que o scheduler pode usar para fazer o match. Assim, você consegue parear GPUs e NICs no mesmo nó NUMA sem esperar que todos os fornecedores concordem com um esquema único de nomes.

Este recurso está em alpha e a API ainda está tomando forma, então teste em um cluster de staging e confira o KEP para ver os campos exatos antes de usar.