Dominando Solicitações e Limites de Recursos do Kubernetes para Desempenho Máximo

O Kubernetes oferece recursos poderosos para automatizar a implantação, o dimensionamento e o gerenciamento de aplicações em contêineres. No entanto, alcançar o desempenho máximo e manter a estabilidade em seu cluster depende criticamente de como você define os requisitos de recursos para suas cargas de trabalho. Configurações de recursos incorretas são uma fonte primária de gargalos de desempenho, agendamento imprevisível e utilização ineficiente do cluster.

Este guia se aprofunda nas Solicitações de Recursos (Resource Requests) e Limites (Limits) do Kubernetes. Compreender a distinção e aplicá-los corretamente é fundamental para garantir a Qualidade de Serviço (QoS) para suas aplicações, prevenir vizinhos barulhentos (noisy neighbors) e otimizar seus gastos com infraestrutura. Exploraremos como essas configurações interagem com o agendador do Kubernetes e o sistema operacional subjacente.

Entendendo os Conceitos Centrais: Solicitações vs. Limites

No Kubernetes, cada especificação de contêiner dentro de um Pod deve definir seu consumo esperado de recursos usando resources.requests e resources.limits. Essas configurações governam CPU e Memória, os dois recursos mais críticos para a saúde da aplicação.

1. Solicitações de Recursos (requests)

Solicitações representam a quantidade de recursos que um contêiner tem a garantia de receber após o agendamento. Esta é a quantidade mínima de recursos que o kube-scheduler usa ao decidir em qual nó colocar um Pod.

• Agendamento: Um nó deve ter recursos alocáveis disponíveis suficientes que satisfaçam a soma de todas as solicitações de Pods antes que um novo Pod possa ser agendado nele.
• Garantias: Se o nó ficar com poucos recursos posteriormente, o contêiner ainda receberá pelo menos a quantidade solicitada (a menos que esteja sujeito a despejo).

2. Limites de Recursos (limits)

Limites definem a quantidade máxima de recursos que um contêiner tem permissão para consumir. Exceder esses limites resulta em comportamentos específicos e definidos para CPU e Memória.

• Limites de CPU: Se um contêiner tentar usar mais CPU do que seu limite, o cgroups do kernel Linux restringirá (throttle) seu uso, impedindo-o de consumir ciclos adicionais.
• Limites de Memória: Se um contêiner exceder seu limite de memória, o sistema operacional encerrará o processo imediatamente (OOMKill: Out Of Memory Kill – Eliminação por Falta de Memória).

Comportamento de CPU vs. Memória

É crucial entender a diferença qualitativa em como o Kubernetes impõe os limites de CPU versus Memória:

Recurso	Comportamento ao Exceder o Limite	Mecanismo de Imposição
CPU	Restringido (desacelerado)	cgroups (controle de largura de banda da CPU)
Memória	Terminado (OOMKill)	Kernel OOM Killer

Dica: Como a restrição de CPU (throttling) é geralmente menos disruptiva do que um OOMKill, a melhor prática geralmente é definir um limite de CPU que seja ligeiramente superior ao seu pico de uso típico, enquanto define um limite de memória rigoroso para evitar a instabilidade do nó.

Definição de Recursos nas Especificações de Pod

Os recursos são definidos dentro do bloco spec.containers[*].resources. As quantidades são especificadas usando sufixos padrão do Kubernetes (por exemplo, m para mili-CPU, Mi para Mebibytes).

Definições de Unidades de CPU

• 1 unidade de CPU é igual a 1 núcleo completo (ou vCPU em provedores de nuvem).
• 1000m (milicores) é igual a 1 unidade de CPU.

Definições de Unidades de Memória

• Mi (Mebibytes) ou Gi (Gibibytes) são comuns.
• 1024Mi = 1Gi.

Exemplo de Configuração YAML

Considere um contêiner que requer um mínimo garantido de 500m de CPU e 256Mi de memória, mas que nunca deve exceder 1 CPU e 512Mi:

resources:
  requests:
    memory: "256Mi"
    cpu: "500m"
  limits:
    memory: "512Mi"
    cpu: "1"

Classes de Qualidade de Serviço (QoS)

A relação entre Solicitações (Requests) e Limites (Limits) determina a classe de Qualidade de Serviço (QoS) atribuída a um Pod. Essa classe dita a prioridade do Pod quando os recursos se tornam escassos e o nó precisa recuperar memória (despejo).

O Kubernetes define três classes de QoS:

1. Guaranteed (Garantida)

Definição: Todos os contêineres no Pod devem ter Solicitações e Limites idênticos e não nulos para ambos CPU e Memória.

• Benefício: Estes Pods são os últimos a serem despejados durante a pressão de recursos, garantindo estabilidade máxima.
• Caso de Uso: Componentes críticos do sistema ou bancos de dados que exigem isolamento rigoroso de desempenho.

2. Burstable (Expansível)

Definição: Pelo menos um contêiner no Pod tem Solicitações definidas, mas ou as Solicitações e Limites não são iguais para todos os contêineres, ou alguns recursos não são limitados (embora definir limites seja altamente recomendado).

• Benefício: Permite que os contêineres excedam suas solicitações (burst), utilizando a capacidade não utilizada no nó, até seus limites definidos.
• Prioridade de Despejo: Despejados antes dos Pods BestEffort, mas depois dos Pods Guaranteed.
• Caso de Uso: A maioria das aplicações stateless padrão onde uma ligeira variação na latência é aceitável.

3. BestEffort (Melhor Esforço)

Definição: O Pod não tem Solicitações nem Limites definidos para nenhum contêiner.

• Benefício: Nenhum, além da simplicidade.
• Risco: Estes Pods são os primeiros candidatos a despejo quando o nó sofre pressão de recursos. Eles também estão sujeitos a restrições (throttling) ou OOMKills imediatamente se a capacidade do nó for excedida.
• Caso de Uso: Jobs em lote não críticos ou agentes de log que podem ser facilmente reiniciados.

Estratégias Práticas de Otimização

A gestão eficaz de recursos requer medição, iteração e planejamento cuidadoso.

Estratégia 1: Medir e Definir Solicitações com Precisão

As Solicitações devem refletir a carga típica ou mínima sustentável que sua aplicação requer. Se você definir solicitações muito altas, desperdiça capacidade do cluster porque o agendador reserva esse recurso mesmo que o contêiner não o esteja usando.

Melhor Prática: Use ferramentas de monitoramento (como Prometheus/Grafana) para analisar dados históricos de uso. Defina as solicitações próximas ao percentil 90 do uso observado durante a operação normal.

Estratégia 2: Definir Limites Conservadores

Os Limites atuam como uma rede de segurança. Para memória, defina sempre limites ligeiramente acima do seu pico medido para evitar falhas. Para CPU, definir limites impede que um processo descontrolado prive processos irmãos críticos no mesmo nó de recursos.

Aviso sobre Limites de CPU: Definir limites de CPU de forma muito agressiva (por exemplo, 50% da necessidade real) leva a uma degradação severa do desempenho devido à restrição constante (throttling). Sempre prefira a QoS Burstable, a menos que você tenha uma necessidade específica de isolamento Guaranteed.

Estratégia 3: Aproveitando o Vertical Pod Autoscaler (VPA)

O ajuste manual de recursos é difícil e demorado. O Vertical Pod Autoscaler (VPA) monitora o uso em tempo de execução e ajusta automaticamente as Solicitações e Limites definidos nas especificações do seu Pod ao longo do tempo. O VPA ajuda a fazer a transição de cargas de trabalho de estados mal configurados (ou BestEffort) para configurações Burstable ou Guaranteed ideais.

Estratégia 4: Resource Quotas para Namespaces

Para evitar o consumo excessivo de recursos entre equipes ou ambientes, os administradores devem usar Resource Quotas (Cotas de Recursos) no nível de Namespace. Uma ResourceQuota impõe limites agregados na quantidade total de Solicitações e Limites de CPU/Memória que podem existir dentro desse namespace, garantindo a justiça.

Exemplo de Cota de Namespace

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: development
spec:
  hard:
    requests.cpu: "10"
    limits.memory: "20Gi"

Isto garante que o total de CPU solicitada em todos os Pods no namespace development não pode exceder 10 núcleos, e os limites totais de memória não podem exceder 20Gi.

Conclusão

Dominar Solicitações e Limites de Recursos do Kubernetes não se trata apenas de prevenir falhas; trata-se de alcançar desempenho previsível e maximizar o retorno do seu investimento em infraestrutura. Ao definir corretamente as Solicitações (Requests) para garantia de agendamento e os Limites (Limits) para segurança contra consumo descontrolado, você eleva seus Pods à classe QoS desejada (preferencialmente Burstable ou Guaranteed). Revise regularmente as métricas de desempenho e considere utilizar ferramentas como o VPA para manter o alinhamento ideal de recursos à medida que suas aplicações evoluem.