Requests e limits de recursos no Kubernetes: agendamento, throttling e OOM kills

O que é

Cada contêiner de um Pod pode declarar resources.requests e resources.limits para CPU e memória. A documentação do Kubernetes (citada) separa os dois papéis: o scheduler usa os requests para escolher um nó com capacidade livre suficiente, e o kubelet reserva para o contêiner pelo menos a quantidade solicitada; os limits são aplicados pelo kubelet e pelo runtime de contêineres e, em última instância, pelo kernel por meio de cgroups. A forma de aplicação difere conforme o recurso: limites de CPU são aplicados por throttling, de modo que um contêiner nunca recebe mais CPU do que o seu limit; limites de memória são aplicados de forma reativa, por meio de out-of-memory kills (OOM kills), que, segundo a documentação, só ocorrem quando o kernel detecta pressão de memória. Assim, um contêiner pode usar mais memória do que o seu limit por um tempo e só depois ser encerrado. Se um limit for definido sem um request, o Kubernetes copia o limit para o request.

A página sobre QoS (citada) deriva uma classe a partir desses campos: Guaranteed quando todos os contêineres têm requests iguais aos limits, tanto para CPU quanto para memória; Burstable quando pelo menos um contêiner tem um request ou limit, mas os critérios de Guaranteed não são atendidos; e BestEffort quando nada é definido. Sob pressão no nó, os Pods BestEffort são removidos (evicted) primeiro, depois os Burstable e por fim os Guaranteed, e somente Pods que excedem seus requests são candidatos à remoção.

Por que importa

Os requests determinam o bin-packing e, portanto, o custo; os limits determinam o modo de falha. Um limit de CPU próximo ao uso típico transforma picos de latência em throttling, que não aparece nos logs da aplicação; um limit de memória abaixo do working set real transforma um vazamento lento em reinicializações periódicas com exit code 137. Pods sem requests são alocados onde houver espaço e são os primeiros a ser removidos.

Como aplicar

• Defina sempre requests e limits de memória; para serviços cuja remoção seria um incidente, defina-os iguais, o que resulta na classe Guaranteed.
• Defina os requests de CPU com base no uso observado; seja criterioso com os limits de CPU, porque o custo de excedê-los é o throttling, e não a remoção.
• Acompanhe a contagem de reinicializações do contêiner, o último motivo de encerramento (OOMKilled) e as métricas de throttling de CPU do runtime, e não apenas a latência da aplicação.
• Aplique padrões por namespace com LimitRange, para que campos esquecidos não gerem Pods BestEffort silenciosamente, e limite os totais com ResourceQuota.
• Dimensione os requests para o processo de JVM, Node.js ou Python em si, incluindo as configurações de heap do runtime, e não para o contêiner ocioso.

Armadilhas

Um limit de memória não é uma reserva de memória no nó: a soma dos limits de todos os Pods pode exceder a capacidade do nó. Alterar requests ou limits historicamente exigia recriar o Pod; a página citada descreve o redimensionamento in-place, cuja disponibilidade depende da versão do cluster.

Limits de CPU: em geral, é melhor não usá-los

Um request de CPU é convertido no peso de CPU do cgroup, que já garante ao contêiner a sua parcela quando há disputa no nó; um limit de CPU acrescenta apenas throttling. A cota do CFS é concedida por período de 100 ms. Assim, um contêiner limitado a uma CPU cujas quatro threads acordam ao mesmo tempo consome a cota do período em 25 ms e espera os 75 ms restantes, a cada período, o que aparece como latência enquanto os gráficos de CPU parecem tranquilos. Compare container_cpu_cfs_throttled_periods_total com container_cpu_cfs_periods_total antes de culpar o código. Mantenha limits de CPU onde forem necessários: na política static do CPU manager (QoS Guaranteed com CPUs inteiras), em um cluster multi-tenant em que a capacidade ociosa não possa ser consumida, ou para um Pod que precise da classe de QoS Guaranteed, que exige limits de CPU iguais aos requests. Defina sempre limits de memória.