Kubernetes v1.37 (Garhwal): novidades e melhorias

TL;DR

O Kubernetes v1.37 ("Garhwal") traz 67 melhorias: 16 Stable, 23 Beta, 27 Alpha e 1 remoção. As mudanças de destaque são o redimensionamento in-place para containers init e sidecar (GA), tolerância configurável do HPA (GA), node declared features (GA), scale-to-zero para o HorizontalPodAutoscaler (Beta), Memory QoS (Beta), gerenciadores de recursos em nível de Pod (Beta), gang scheduling via nova Workload API (Beta) e modo rootless do Kubelet (Beta). O trabalho em Alpha inclui uma Eviction Request API cooperativa e checkpoint/restore em nível de Pod, além do progresso contínuo na Dynamic Resource Allocation (DRA). Ponto de atenção: a rotulagem de montagem do SELinux muda por padrão nesta versão e pode quebrar workloads existentes em clusters com SELinux habilitado.

O Kubernetes v1.37, também conhecido como "Garhwal", traz um conjunto robusto de mudanças para equipes que se preocupam com gerenciamento de recursos, autoscaling e agendamento. Esta versão tem 67 melhorias. 16 delas agora são Stable (GA), 23 agora são Beta, 27 agora são Alpha e 1 é uma remoção. O nome vem de Garhwal, uma região do Himalaia em Uttarakhand, na Índia. O tema fala de camadas que se conectam e se apoiam, dos campos em terraços aos riachos de montanha, o que combina com uma versão que continua construindo sobre o trabalho das anteriores.

Estes são alguns dos recursos que mais nos empolgam no Kubernetes v1.37: redimensionamento in-place para containers init e sidecar, scale to zero para o HorizontalPodAutoscaler, Memory QoS e gang scheduling nativo por meio da Workload API. Muitos deles tornam o Kubernetes melhor em usar bem os recursos, escalar com base na demanda real e posicionar workloads fortemente acoplados.

Estas são as principais mudanças do Kubernetes v1.37:

Recursos Stable do Kubernetes v1.37

1. Redimensionamento in-place de Pods para containers init e sidecar

Grupo do recurso: SIG Node | KEP: #1287

O redimensionamento in-place de Pods se tornou Stable (GA) no Kubernetes v1.35. No v1.37, esse suporte se estende a containers init e sidecar, e essa parte agora também é GA.

Antes dessa mudança, você podia redimensionar a CPU e a memória de um container de aplicação em execução sem reiniciá-lo, mas containers init e sidecar ficavam de fora. Um container sidecar é um container init com restartPolicy: Always, ou seja, ele roda durante toda a vida do Pod. Se um sidecar precisasse de mais CPU ou memória, sua única opção real era recriar o Pod. Isso significava downtime também para a aplicação principal, mesmo que só o sidecar precisasse da mudança.

Com o v1.37, o feature gate InPlacePodVerticalScalingInitContainers é GA. Você pode alterar as requests ou limits de CPU e memória de um container sidecar em execução, e o kubelet atualiza as configurações de cgroup do container in place. O Pod continua rodando. Você controla o que acontece por recurso com resizePolicy. NotRequired significa aplicar a mudança ao vivo, e RestartContainer significa reiniciar apenas aquele container para aplicá-la. O v1.37 também adiciona duas partes Alpha ao mesmo recurso: redimensionar in place volumes emptyDir baseados em memória (o gate InPlacePodVerticalScalingMemoryBackedVolumes) e permitir que o scheduler faça preempção de Pods de menor prioridade para abrir espaço para um redimensionamento adiado (o gate InPlacePodVerticalScalingSchedulerPreemption).

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  initContainers:
  - name: log-shipper        # sidecar
    image: log-shipper:1.0
    restartPolicy: Always
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
  containers:
  - name: app
    image: app:1.0
    # ...

Com essa configuração, você pode aumentar a CPU do sidecar sem nenhum reinício. Aumentar a memória reinicia apenas aquele container, nunca o Pod inteiro.

2. Tolerância configurável para HorizontalPodAutoscalers

Grupo do recurso: SIG Autoscaling | KEP: #4951

No Kubernetes v1.37, a tolerância configurável para o HorizontalPodAutoscaler (HPA) chegou à disponibilidade geral (GA).

O HPA altera o número de réplicas de Pods com base em métricas como CPU ou memória. Antes desse recurso, o HPA usava uma tolerância fixa de 10% em todo o cluster. Ele só agia quando o uso se afastava mais de 10% do alvo. Esse valor único não servia para todos os workloads. Serviços sensíveis podiam reagir devagar demais, e, para mudá-lo, era preciso editar uma flag global do controller que afetava todos os HPAs do cluster.

Com o v1.37, o feature gate HPAConfigurableTolerance é GA. Você pode definir a tolerância por HPA e por direção de escalonamento no campo behavior. Uma tolerância mais rígida no scale up permite que um serviço crítico reaja a pequenos aumentos de carga. Uma tolerância mais folgada em outros pontos mantém estáveis os workloads menos movimentados. Isso era Beta no v1.35 e agora é o comportamento padrão.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  behavior:
    scaleUp:
      tolerance: 0.05

A tolerância é uma proporção, não pontos percentuais. Com 0.05 e um alvo de 60%, o HPA faz scale up quando o uso de CPU passa de cerca de 63% (60% vezes 1,05). Isso reage mais cedo do que a antiga tolerância fixa de 10% permitiria.

3. Node Declared Features

Grupo do recurso: SIG Node | KEP: #5328

No Kubernetes v1.37, o recurso node declared features chegou à disponibilidade geral (GA).

Antes desse recurso, o Kubernetes assumia que um nó podia lidar com qualquer recurso suportado pelo control plane, desde que as versões estivessem dentro do skew suportado. Isso nem sempre é verdade. Quando um novo recurso era ativado no control plane, o scheduler ainda podia colocar um Pod que o usava em um nó mais antigo que ainda não o suportava. O Pod então falhava em tempo de execução ou ficava travado depois do agendamento, mesmo que o posicionamento parecesse correto.

Com o v1.37, o feature gate NodeDeclaredFeatures é GA. Cada nó agora publica o conjunto de recursos que entende em um campo status.declaredFeatures no objeto Node. O scheduler e as verificações de admissão usam essa informação para colocar os Pods que usam esses recursos apenas em nós que os suportam. Isso transforma uma falha em tempo de execução em uma decisão de agendamento clara, o que importa principalmente durante upgrades, quando as versões dos nós estão misturadas. Node declared features era Alpha no v1.35.

Recursos Beta do Kubernetes v1.37

4. Scale to Zero para HorizontalPodAutoscalers

Grupo do recurso: SIG Autoscaling | KEP: #2021

No Kubernetes v1.37, o scale to zero para o HorizontalPodAutoscaler chegou a Beta e vem ativado por padrão.

Antes desse recurso, um HPA não conseguia reduzir um workload a zero réplicas. O mínimo era uma. Para um serviço que só tem trabalho parte do tempo, como um consumidor de fila ou um worker de batch, isso significava pagar para manter pelo menos um Pod rodando mesmo quando não havia nada a fazer.

Com o v1.37, você pode definir spec.minReplicas: 0 em um HPA e deixá-lo reduzir o workload a zero quando estiver ocioso, trazendo-o de volta quando a demanda retornar. Isso funciona para workloads baseados em métricas Object ou External, como o tamanho de uma fila. Não funciona para métricas de CPU ou memória, porque essas métricas vêm de Pods em execução, e não há nenhum quando está em zero. Isso pode cortar custos de consumidores de fila, jobs de batch e workloads de GPU que ficam ociosos entre execuções. Enquanto o HPA mantém um workload em zero, ele registra uma condição ScaledToZero definida como True, para você diferenciar um workload que ele reduziu a zero de um que foi desligado manualmente. Quando volta a escalar, a condição se torna False com o motivo NotScaledToZero.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: queue_messages
      target:
        type: AverageValue
        averageValue: "30"

Com essa configuração, o workload cai para zero Pods quando a fila está vazia, e o HPA o escala de volta assim que as mensagens chegam.

5. Memory QoS

Grupo do recurso: SIG Node | KEP: #2570

No Kubernetes v1.37, o Memory QoS chegou a Beta.

Antes desse recurso, o kubelet definia um limite rígido de memória para um container (cgroup memory.max), mas não dava ao kernel nenhum sinal mais suave. Um container podia usar memória até o limite e então sofrer um OOM kill quase sem aviso. Também não havia proteção de memória ligada à request de um container, então, sob pressão de memória, o kernel podia recuperar páginas de um container que ainda estava dentro da sua request.

Com o v1.37, o feature gate MemoryQoS é Beta. Ele usa os controles de memória do cgroup v2 para dar sinais melhores ao kernel. O kubelet define memory.min a partir da request de memória do container, o que protege essa quantidade de memória contra reclaim. Quando você define memoryThrottlingFactor na configuração do kubelet, o kubelet também define memory.high como um ponto de throttling abaixo do limite. O kernel então desacelera o container e recupera páginas antes que ele atinja o limite rígido e sofra um OOM kill. Por padrão, memoryThrottlingFactor não é definido, e memory.high fica desativado a menos que você o configure. O cgroup v2 é obrigatório, e já é o único modo suportado desde o v1.35.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9

Com essa configuração, o kubelet define memory.high para os containers abaixo do limite de memória, usando o fator de 0,9. O kernel recupera memória e faz throttling do container antes que ele atinja o limite rígido, o que torna os OOM kills menos prováveis sob pressão.

6. Gerenciadores de recursos em nível de Pod

Grupo do recurso: SIG Node | KEP: #5526

No Kubernetes v1.37, os gerenciadores de recursos em nível de Pod chegaram a Beta.

O Kubernetes v1.34 adicionou recursos em nível de Pod (KEP #2837), que permitem definir requests e limits de CPU e memória para o Pod inteiro, e não só por container. Mas os gerenciadores de recursos do kubelet ainda não entendiam esses valores em nível de Pod. Antes desse recurso, o CPU Manager, o Memory Manager e o Topology Manager só olhavam para as requests por container. Um Pod que definisse recursos em nível de Pod podia ficar sem pinning exclusivo de CPU ou alinhamento NUMA.

Com o v1.37, o feature gate PodLevelResourceManagers é Beta. Ele vem desativado por padrão no v1.37: foi ativado e depois desativado de novo no fim do ciclo de release, após a equipe encontrar problemas críticos, então você mesmo o habilita se quiser usá-lo. Quando está ativo, o CPU Manager (política estática), o Memory Manager e o Topology Manager levam em conta os recursos em nível de Pod ao atribuir CPUs, memória e localidade de hardware. Isso ajuda workloads sensíveis a latência e de alto desempenho que definem recursos em nível de Pod, para que continuem recebendo núcleos exclusivos e memória alinhada por NUMA.

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  resources:              # pod-level resources
    requests:
      cpu: "2"
      memory: "4Gi"
    limits:
      cpu: "2"
      memory: "4Gi"
  containers:
  - name: app
    image: app:1.0
    # containers can set their own resources, or use the pod-level ones

Com essa configuração, o Pod é Guaranteed em nível de Pod, e os gerenciadores do kubelet podem fazer pinning de CPUs inteiras e alinhar a memória para ele, mesmo quando o container não define suas próprias requests.

7. Gang Scheduling com a Workload API

Grupo do recurso: SIG Scheduling | KEP: #4671

No Kubernetes v1.37, o gang scheduling nativo por meio da Workload API chegou a Beta.

Antes desse recurso, o Kubernetes agendava Pods um de cada vez. Para um job fortemente acoplado, como uma execução de treinamento distribuído em que todos os workers precisam começar juntos, isso causava agendamento parcial. Alguns Pods iniciavam enquanto outros ficavam pendentes, segurando recursos sem produzir nada. As equipes precisavam adicionar um scheduler externo para obter o comportamento de tudo ou nada (gang). O Kubernetes v1.35 introduziu o gang scheduling nativo como Alpha por meio de uma nova Workload API.

Com o v1.37, a API agora é scheduling.k8s.io/v1beta1. Você a ativa com o feature gate GenericWorkload. No v1.37, os gates mais antigos GangScheduling e WorkloadAwarePreemption foram fundidos em GenericWorkload, então um único gate agora cobre tanto o gang scheduling quanto a preempção workload-aware. O modelo tem três partes. Um Workload contém um ou mais podGroupTemplates, cada um com uma política de agendamento como gang e um minCount. Um PodGroup é criado a partir de um template e acompanha um grupo em execução. Cada Pod aponta para o seu grupo com schedulingGroup.podGroupName. O scheduler segura os Pods até que pelo menos minCount deles possam rodar juntos e então os posiciona. Se não conseguir atingir o minCount, nenhum é vinculado, e os Pods esperam até haver espaço. O campo minCount continua editável depois da criação, o que ajuda jobs elásticos a escalar para cima ou para baixo.

O Workload define o template:

apiVersion: scheduling.k8s.io/v1beta1
kind: Workload
metadata:
  name: training-job
spec:
  podGroupTemplates:
  - name: workers
    schedulingPolicy:
      gang:
        minCount: 4

Um PodGroup é criado a partir desse template:

apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: training-job-workers-0
spec:
  workloadRef:
    workloadName: training-job
    templateName: workers
  schedulingPolicy:
    gang:
      minCount: 4

Cada Pod entra no grupo pelo nome:

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
spec:
  schedulingGroup:
    podGroupName: training-job-workers-0
  containers:
  - name: trainer
    image: trainer:1.0
    # ...

Com essa configuração, o Kubernetes agenda os workers apenas quando pelo menos quatro deles podem rodar juntos. Se o cluster não comportar quatro, nenhum deles inicia.

8. Kubelet em User Namespace (modo Rootless)

Grupo do recurso: SIG Node | KEP: #2033

No Kubernetes v1.37, a execução do kubelet em um user namespace, também chamada de modo Rootless, chegou a Beta.

Antes desse recurso, componentes do nó como o kubelet rodavam como root no host. Se o kubelet fosse comprometido, um invasor poderia obter root no nó inteiro.

Com o v1.37, o feature gate KubeletInUserNamespace é Beta. Ele executa o kubelet e os demais componentes do nó dentro de um user namespace do Linux. Eles ainda parecem root dentro do namespace, mas no host mapeiam para um usuário sem privilégios. Isso adiciona uma camada de isolamento sem mudar a forma como você usa o kubelet no dia a dia. Esse recurso está em desenvolvimento desde o v1.22, então chegar a Beta é um grande passo.

Recursos Alpha do Kubernetes v1.37

9. Eviction Request API

Grupo do recurso: SIG Node | KEP: #4563

Antes desse recurso, drenar um nó para manutenção era uma ação do lado do cliente. Uma ferramenta como kubectl drain despejava os Pods um a um e respeitava os PodDisruptionBudgets, mas a intenção vivia no cliente, não no cluster. Controllers e aplicações não conseguiam ver que um nó estava sendo drenado, coordenar uma transição segura nem participar da decisão. Uma aplicação com estado podia ser despejada em um momento ruim porque nada avisava que a manutenção estava chegando.

Com o v1.37, um recurso Alpha adiciona a API EvictionRequest para que o despejo possa ser cooperativo em vez de uma exclusão forçada. Um solicitante cria um EvictionRequest para um Pod, e os componentes registrados por meio do novo campo spec.evictionResponders do Pod cuidam de uma transição suave. O v1.37 também adiciona novas condições de ciclo de vida do Node (MaintenancePlanned, MaintenanceInProgress, GracefulNodeShutdownInProgress, DrainInProgress e Drained) que os controllers podem observar para saber em que ponto do fluxo de manutenção o nó está. Juntas, essas peças permitem que uma aplicação ou operator faça a drenagem no seu próprio ritmo, por exemplo movendo um líder ou persistindo o estado antes de o Pod sair.

10. Checkpoint e restore em nível de Pod

Grupo do recurso: SIG Node | KEP: #5823

Antes desse recurso, o Kubernetes podia fazer checkpoint de um único container (KEP #2008), principalmente para análise forense. Você podia capturar o estado de um container, mas não de um Pod inteiro de uma vez, então um Pod com vários containers não podia ser capturado como uma unidade.

Com o v1.37, um recurso Alpha adiciona checkpoint e restore em nível de Pod. Ele estende a Container Runtime Interface (CRI) com as chamadas CheckpointPod e RestorePod, para que o kubelet e um runtime compatível possam capturar juntos todos os containers de um Pod e depois restaurá-los. Isso já é útil para trabalho forense hoje e prepara o terreno para usos futuros, como mover um Pod em execução entre nós. O recurso precisa de um runtime de containers que suporte as novas chamadas CRI.