Principal

Início Componentes Troubleshooting kubectl Cheatsheet Glossário

Conceitos

Ciclo de Vida do Pod Scheduling Avançado QoS Classes Lifecycle Hooks Admission Controllers Garbage Collection CRDs & Operators Audit Logging Metrics Pipeline Reconciliation Loop

Avançado

Helm Charts GitOps com ArgoCD Security Hardening Networking EKS a Fundo

Conceitos · Resources

QoS Classes (Quality of Service)

O Kubernetes classifica automaticamente cada Pod em uma QoS Class baseada em seus resource requests e limits. Isso determina quem morre primeiro quando o node fica sem memória.

// COMO VERIFICAR A CLASSE DO SEU POD

$ kubectl get pod <nome> -o jsonpath='{.status.qosClass}'# Retorna: Guaranteed, Burstable ou BestEffort$ kubectl describe pod <nome> | grep QoS# QoS Class: Burstable

🏆GuaranteedÚltima a ser removida

CONDIÇÃO

Todos os containers têm requests E limits definidos, E requests == limits (para CPU e memória).

O Kubernetes garante que esses pods recebem exatamente os recursos solicitados. São os últimos a serem evictados quando o node tem pressão de memória.

EXEMPLO

resources:
  requests:
    memory: "256Mi"
    cpu: "500m"
  limits:
    memory: "256Mi"  # igual ao request
    cpu: "500m"      # igual ao request

USO IDEAL

APIs críticas de produção, bancos de dados, qualquer workload onde latência e disponibilidade são prioridade máxima.

💡 Para atingir Guaranteed, requests e limits devem ser IGUAIS em todos os containers, incluindo init containers.

⚡BurstableRemovida se necessário

CONDIÇÃO

Pelo menos um container tem requests ou limits definidos, mas não é Guaranteed (requests ≠ limits ou algum container sem definição).

Pode usar mais recursos do que solicitou (burst) quando disponível. É evictado quando o node tem pressão, priorizando pods com maior uso relativo ao request.

EXEMPLO

resources:
  requests:
    memory: "128Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"  # diferente do request
    cpu: "1000m"     # diferente do request

USO IDEAL

Maioria dos workloads: serviços com carga variável que podem ter picos mas não são ultra-críticos.

💡 A maioria dos seus pods será Burstable. É o balanço entre garantia e eficiência de recursos.

🎲BestEffortPrimeira a ser removida

CONDIÇÃO

Nenhum container tem requests ou limits definidos.

Usa recursos disponíveis sem garantia alguma. São os primeiros evictados quando o node fica com pressão de memória, independente do uso atual.

EXEMPLO

# Sem resources definidos = BestEffort
spec:
  containers:
  - name: app
    image: nginx
    # sem resources: ← BestEffort

USO IDEAL

Apenas para tarefas não-críticas: jobs de desenvolvimento local, scratchpads, experimentos.

⚠️ Nunca use BestEffort em produção. Sem requests, o HPA não funciona, o scheduler não consegue alocar corretamente e o pod é o primeiro a morrer sob pressão.

Ordem de Eviction por Pressão de Memória (OOM)

Quando o node fica sem memória, o kubelet remove pods nessa ordem:

1ºBestEffortSem requests/limits — eliminados imediatamente

2ºBurstable (usando > request)Usando mais do que pediu — candidatos prioritários

3ºBurstable (usando ≤ request)Respeitando o request — evictados se necessário

4ºGuaranteedÚltima opção — só se não houver outra saída

🖥️ CPU — Compressível

CPU é throttled (limitada) quando um pod excede o limit, mas o pod não é morto. A aplicação fica mais lenta, não morre. Por isso CPU limit alto é menos arriscado que memory limit baixo.

💾 Memória — Incompressível

Memória não pode ser throttled. Quando um processo excede o memory limit, o kernel mata o processo com OOMKill (exit code 137). Por isso memory limit baixo causa CrashLoopBackOff.