Melhores Práticas para Otimizar o Desempenho de Clusters Kubernetes

Problemas de desempenho em clusters Kubernetes geralmente se manifestam como implantações lentas, Pods pendentes, vizinhos barulhentos ou contas de nuvem surpreendentes. A correção raramente é uma configuração mágica; você precisa de dimensionamento preciso de recursos, regras de escalonamento que correspondam à demanda e observabilidade suficiente para identificar onde a pressão começa.

Use esta lista de verificação para ajustar seu cluster sem adivinhação.

Comece com Solicitações e Limites

O escalonador usa solicitações (requests) de CPU e memória para decidir onde os Pods se encaixam. Se as solicitações forem muito baixas, os nós parecem mais vazios do que realmente são e as cargas de trabalho competem por recursos. Se as solicitações forem muito altas, o escalonador desperdiça capacidade e os Pods podem ficar pendentes.

Defina solicitações com base em dados de uso reais. Por exemplo, se um contêiner de API fica em torno de 300 milicores durante o tráfego normal e atinge perto de 700 milicores durante o aquecimento da implantação, você pode começar com:

resources:
  requests:
    cpu: "300m"
    memory: "512Mi"
  limits:
    memory: "1Gi"

Tenha cuidado com limites de CPU. Um limite estrito de CPU pode limitar serviços sensíveis à latência mesmo quando o nó tem CPU sobressalente. Limites de memória ainda são úteis porque um contêiner que excede seu limite de memória pode ser morto antes de empurrar todo o nó para pressão de memória.

Use Escalonamento Automático com Sinais Claros

O Horizontal Pod Autoscaler funciona bem quando sua métrica acompanha a demanda do usuário. A CPU pode ser suficiente para serviços simples sem estado, mas profundidade de fila, taxa de requisições ou métricas personalizadas da aplicação geralmente são melhores sinais de escalonamento.

kubectl autoscale deployment api \
  --cpu-percent=70 \
  --min=3 \
  --max=20

O Cluster Autoscaler, Karpenter ou a camada de escalonamento automático de nós do seu provedor de nuvem deve ter espaço para adicionar nós antes que os Pods fiquem pendentes por longos períodos. Verifique se os grupos de nós cobrem os tamanhos de instância, zonas, requisitos de GPU ou taints que suas cargas de trabalho precisam.

Mantenha o Escalonamento Previsível

O desempenho cai quando Pods críticos caem em nós sobrecarregados ou inadequados. Use restrições de distribuição de topologia para serviços de alto tráfego, afinidade de nó para cargas de trabalho específicas de hardware e taints para nós que devem executar apenas uma classe restrita de Pods.

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: kubernetes.io/hostname
  whenUnsatisfiable: ScheduleAnyway
  labelSelector:
    matchLabels:
      app: api

Isso impede que réplicas se acumulem em um único nó quando o cluster tem melhores opções de posicionamento.

Ajuste a Rede Onde Realmente Dói

A maioria dos clusters não precisa de ajustes exóticos de rede. Comece encontrando o caminho lento: tempo de consulta DNS, sobrecarga do service mesh, tráfego entre zonas, ingress sobrecarregado ou latência entre Pod e banco de dados.

Verificações úteis incluem:

kubectl top pods -A
kubectl get endpointslices -A
kubectl describe ingress <nome>
kubectl logs -n kube-system -l k8s-app=kube-dns

Para serviços com muitas comunicações, mantenha os Pods e suas principais dependências na mesma Região e, quando possível, na mesma zona. Se você usa um service mesh, meça a latência p95 e p99 com e sem injeção de sidecar para uma carga de trabalho antes de aplicar mudanças no mesh amplamente.

Corresponda o Armazenamento à Carga de Trabalho

As escolhas de armazenamento podem dominar o desempenho para bancos de dados, filas e cargas de trabalho de CI. Escolha volumes com base em latência, IOPS, throughput e comportamento de falha, não apenas capacidade.

Por exemplo, um Pod PostgreSQL precisa de uma classe de volume persistente com latência previsível e comportamento de backup claro. Um cache de build pode se importar mais com throughput e pode tolerar reconstruções. Um serviço web sem estado deve evitar volumes persistentes completamente, a menos que tenha um motivo real.

Observe estes sintomas:

• Pods presos em ContainerCreating porque volumes anexam lentamente.
• Latência da aplicação aumentando enquanto a CPU permanece normal.
• Pressão de disco no nó expulsando Pods.
• StatefulSets bloqueados porque um volume está vinculado a uma zona.

Observe o Cluster Antes de Alterá-lo

Otimização sem métricas de base é apenas ruído. No mínimo, monitore CPU, memória, reinicializações, Pods pendentes, condições de pressão do nó, latência do servidor API e latência p95 da carga de trabalho.

kubectl get nodes
kubectl describe node <nome-do-nó>
kubectl get pods -A --field-selector=status.phase=Pending
kubectl top nodes

Se você usa Prometheus, adicione alertas para pressão sustentada do nó, altas taxas de reinicialização, HPA no máximo de réplicas e réplicas indisponíveis em implantações críticas.

Conclusão

Otimize o Kubernetes de dentro para fora da carga de trabalho. Dimensione solicitações corretamente, evite limitação desnecessária de CPU, escale com base em sinais de demanda, mantenha réplicas distribuídas e escolha armazenamento que se ajuste à carga de trabalho. Depois, meça após cada alteração para saber se o cluster ficou mais rápido, mais barato ou simplesmente diferente.