Você deve definir os limites de CPU do Kubernetes?

Gerenciar os recursos disponíveis para seus pods e contêineres é uma etapa de prática recomendada para a administração do Kubernetes. Você precisa impedir que os pods consumam avidamente a CPU e a memória do cluster. O uso excessivo por um conjunto de pods pode causar contenção de recursos que desacelera os contêineres vizinhos e desestabiliza seus hosts.

No entanto, o gerenciamento de recursos do Kubernetes costuma ser mal compreendido. Dois mecanismos são fornecidos para controlar as alocações: solicitações e limites. Isso leva a quatro configurações possíveis por pod, se você definir uma solicitação e um limite para CPU e memória.

Seguir esse caminho simples geralmente não é ideal: os limites da CPU devem ser ignorados porque prejudicam o desempenho e desperdiçam a capacidade disponível. Este artigo explicará o problema para que você possa executar um cluster mais eficiente.

Como funcionam as solicitações e os limites

As solicitações são usadas para agendamento. Novos pods serão atribuídos apenas a nós que podem atender às suas solicitações. Se não houver nó correspondente, o pod permanecerá em estado pendente até que os recursos estejam disponíveis.

Os limites definem a utilização máxima de recursos permitida ao pod. Quando o limite é atingido, o pod não pode usar mais recursos, mesmo que haja capacidade livre em seu nó. O efeito real de atingir o limite depende do recurso em questão: exceder uma restrição de CPU resulta em limitação, enquanto ultrapassar um limite de memória fará com que o Pod OOM killer elimine processos de contêiner.

No exemplo a seguir, um pod com essas restrições só agende para nós que podem fornecer 500m (equivalente a 0,5 núcleos de CPU). Seu consumo máximo de tempo de execução pode ser de até 1000m antes da aceleração se o Node tiver capacidade disponível.

resources:
  requests:
    cpu: 500m
  limits:
    cpu: 1000m

Por que os limites de CPU são perigosos

Para entender por que os limites de CPU são problemáticos, considere o que acontece se um pod com a configuração de recurso mostrada acima (solicitação de 500 m, limite de 1.000 m) for implantado em um nó quad core com uma capacidade total de 4.000 m de CPU. Para simplificar, não há outros pods em execução no Node.

$ kubectl get pods -o wide
NAME            READY       STATUS      RESTARTS    AGE     IP              NODE
demo-pod        1/1         Running     0           1m      10.244.0.185    quad-core-node

O pod é agendado para o nó imediatamente porque a solicitação de 500m é atendida imediatamente. O pod entra no estado Running. A carga pode ser baixa com um uso de CPU de algumas centenas de milicores.

Em seguida, há um aumento repentino no tráfego: as solicitações são inundadas e a utilização efetiva da CPU do pod salta para 2.000 m. Devido ao limite da CPU, isso é reduzido para 1000m. No entanto, o nó não está executando nenhum outro pod, portanto, poderia fornecer os 2.000 m completos, se o pod não fosse limitado por seu limite.

A capacidade do Node foi desperdiçada e o desempenho do Pod foi reduzido desnecessariamente. Ignorar o limite de CPU permitiria que o pod usasse os 4.000 m completos, atendendo potencialmente a todas as solicitações até quatro vezes mais rápido.

Nenhum limite ainda impede a monopolização dos recursos do pod

Ignorar os limites da CPU não compromete a estabilidade, desde que você tenha configurado as solicitações apropriadas em cada pod. Quando vários pods são implantados, a parte do tempo de CPU de cada pod aumenta proporcionalmente à sua solicitação.

Aqui está um exemplo do que acontece com dois pods ilimitados quando implantados em um nó de 8 núcleos (8.000m), cada um exigindo simultaneamente 100% de consumo de CPU:

Se o Pod 1 estiver em um período mais silencioso, o Pod 2 poderá usar ainda mais ciclos de CPU:

As solicitações de CPU ainda são importantes

Esses exemplos demonstram por que as solicitações de CPU são importantes. A configuração de solicitação adequada evita a contenção, garantindo que os pods sejam agendados apenas para os nós que podem suportá-los. Ele também garante a distribuição ponderada dos ciclos de CPU disponíveis quando vários pods experimentam uma demanda maior.

Os limites de CPU não oferecem esses benefícios. Eles são valiosos apenas em situações em que você deseja limitar um pod acima de um determinado limite de desempenho. Este é quase sempre um comportamento indesejável; você está afirmando que seus outros pods sempre estarão ocupados, quando eles podem estar ociosos e criando ciclos de CPU sobressalentes no cluster.

Não definir limites permite que esses ciclos sejam usados ​​por qualquer carga de trabalho que precise deles. Isso resulta em melhor desempenho geral porque o hardware disponível nunca é desperdiçado.

E a memória?

A memória é gerenciada no Kubernetes usando os mesmos conceitos de solicitação e limite. No entanto, a memória é um recurso fisicamente diferente da utilização da CPU, que exige seu próprio método de alocação. A memória não pode ser comprimida: não pode ser revogada depois de alocada a um processo contêiner. Os processos compartilham a CPU conforme ela se torna disponível, mas recebem pedaços individuais de memória.

Definir uma solicitação e um limite idênticos é a abordagem de prática recomendada para o gerenciamento de memória do Kubernetes. Isso permite que você antecipe com segurança o consumo total de memória de todos os pods em seu cluster.

Pode parecer lógico definir uma solicitação relativamente baixa com um limite muito maior. No entanto, usar essa técnica para muitos pods pode ter um efeito desestabilizador: se vários pods excederem suas solicitações, a capacidade de memória do cluster poderá se esgotar. O matador de OOM intervirá para eliminar os processos de contêiner, possivelmente causando interrupção em suas cargas de trabalho. Qualquer um dos seus pods pode ser removido, não apenas aquele que causou o esgotamento da memória.

O uso de solicitações e limites iguais impede que um pod seja agendado, a menos que o nó possa fornecer a memória necessária. Ele também garante que o pod não pode usar mais memória do que sua alocação explícita, o que elimina o risco de uso excessivo quando vários pods excedem suas solicitações. A superutilização ficará aparente quando você tentar agendar um pod e nenhum nó puder atender à solicitação de memória. O erro ocorre mais cedo e de forma mais previsível, sem afetar nenhum outro pod.

Resumo

O Kubernetes permite distinguir entre a quantidade de recursos que um contêiner requere um limite superior que é permitido escalar, mas não pode ultrapassar. No entanto, esse mecanismo é menos útil na prática do que pode parecer à primeira vista.

A definição de limites de CPU impede que seus processos usem capacidade adicional de CPU à medida que ela se torna disponível. Isso acelera desnecessariamente o desempenho quando um pod pode estar temporariamente usando ciclos que nenhum vizinho exige.

Use a solicitação de CPU sensata para evitar que os pods sejam agendados em nós que já estão muito ocupados para fornecer um bom desempenho. Deixe o campo de limite indefinido para que os pods possam acessar recursos adicionais ao executar tarefas exigentes nos momentos em que a capacidade estiver disponível. Por fim, dê a cada pod uma solicitação e um limite de memória, certificando-se de usar o mesmo valor para ambos os campos. Isso evitará o esgotamento da memória e criará um ambiente de cluster mais estável e previsível.