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

Kubernetes 1.37: recursos estáveis (GA)

1. Metrics API chega ao GA

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

A API metrics.k8s.io ficou anos em beta. É 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 alterar nada agora. Mas, se você constrói 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 container de um pod, mesmo quando os containers foram 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 container.

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 containers do pod passam a 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-container com uso de recursos em picos.

3. DRA: taints e tolerations de dispositivos

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

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

Um taint NoSchedule impede que novos pods usem aquele 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 no 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% para o cluster inteiro, para evitar escalar por causa de 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 é bem 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 passar por 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 nativamente, sem o sidecar extra ou o encanamento de webhooks que muitos service meshes usam hoje.

6. Saída KYAML no kubectl

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

KYAML é um subconjunto mais rigoroso do YAML, com sabor Kubernetes: chaves para maps, colchetes para listas, aspas duplas para strings. Ele ainda permite comentários e vírgulas finais, mas elimina as armadilhas clássicas do YAML, como o "no" ser interpretado silenciosamente como boolean false (o "problema da Noruega").

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

7. Aceleração da mudança recursiva de labels SELinux (SELinuxMount)

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

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

O SELinuxMount chega ao GA e vem habilitado por padrão na v1.37. Em vez de rotular 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 aceita a mudança via CSIDriver.spec.seLinuxMount: true.

Um detalhe importante para lembrar: 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 o antigo relabeling recursivo), esses pods podem passar a falhar na inicialização. Se você 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 em UserNS executa o kubelet dentro de um user namespace do Linux. Ele ainda parece 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 escalando de/para zero com 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 com facilidade, já que ele exige geração de código em tempo de compilação. CBOR é um formato binário que não tem esse requisito, e benchmarks iniciais mostram até 8x mais velocidade na codificação e 2x na decodificação de recursos customizados em comparação com JSON. Os clientes negociam o formato automaticamente e voltam para JSON quando falam com API servers mais antigos, então a adoção acontece de forma segura.

Recursos alpha do Kubernetes 1.37

Estes são 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 storage, você geralmente só descobre por uma montagem que falhou ou um travamento de I/O; não há um sinal estruturado sobre o qual 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 não saudáveis 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 daquele 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 container

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

Algumas aplicações, como bancos de dados e aplicações 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 container runtime oferece por padrão. Até agora, as opções usuais eram scripts de entrypoint customizados ou alterar a configuração do host.

O Kubernetes v1.37 adiciona um campo ulimits ao Container.SecurityContext. O kubelet repassa esses limites ao container runtime. Esse recurso atualmente 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 só se diferentes fabricantes de hardware 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 compatíveis, mas cada fabricante descreve a topologia do seu próprio jeito.

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

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