Agora você tem uma imagem definida, é hora de ajudar o Kubernetes a agendar essa imagem com eficiência para os nodes apropriados e uma das melhores dicas de otimização é que você precisa ser mais específico com as restrições de recursos.

O que isso significa é que você pode definir as solicitações e colocar limites na CPU, memória e outros recursos, pois caso você decida usar um microsserviço baseado em Go como servidor de e-mail, portanto, pode designar o perfil de recurso abaixo:

resources:
   requests:
     memory: 1Gi
     cpu: 250m
   limits:
     memory: 2.5Gi
     cpu: 750m

Alguns pontos merecem atenção para essa definição:

• As solicitações da CPU geralmente não são definidas ou são muito baixas;
• Em alta demanda, os CPUs do nodes são totalmente utilizadas e o workload está recebendo apenas o que foi solicitado e fica com a CPU com consumo alto, causando aumento de latência, timeout e etc.

Por favor não faço isso:

resources: {}

E nem isso com CPU muito baixo:

resources:
  requests:
    cpu: "1m"

• Por outro lado, ter limite de CPU pode aumentar o consumo dos pods, mesmo que a CPU do node não seja totalmente utilizado no que novamente pode causar aumento da latência.
• A super alocação de memória pode causar mais problemas. Atingir um limite de CPU resulta em estrangulamento, atingir o limite de memória fará com que seu pod seja encerrado.

Já viu OOMKilled?

Seria dele que estamos falando. Quer minimizar a frequência com que isso pode acontecer?

Não comprometa demais sua memória e use a solicitação de memória de configuração de QoS (Quality of Service) garantida igual ao limite.

Estável | "Burstable"

Provável obter OOMkilled com mais frequência:

resources:
    requests:
      memory: "128Mi"
      cpu: "500m"
    limits:
      memory: "256Mi"
      cpu: 2

Garantido | "Guaranteed"

Indicado e Garantido para aplicações que usam desses valores de recursos, onde a boa prática é configurar valores iguais, tanto em requests e limits: