Objetivos desta aula
- Configurar probes que ajudam em vez de atrapalhar
- Definir requests/limits com critério
- Aplicar HPA e RBAC mínimo
Liveness diz 'se falhar, reinicie'; readiness diz 'se falhar, não mande tráfego'; startup dá tempo extra para aplicações de inicialização lenta. O erro clássico é apontar liveness para um endpoint que checa o banco: quando o banco oscila, o Kubernetes reinicia toda a aplicação e transforma uma degradação em queda total.
Requests definem o que o scheduler reserva; limits, o teto. CPU acima do limite sofre throttling (fica lento); memória acima do limite resulta em OOMKilled (o container morre). Definir memória com folga real e observar o consumo antes de apertar é a prática correta.
HPA escala réplicas por métrica, mas só funciona com requests definidos e metrics-server ativo. E RBAC fecha o ciclo: cada aplicação e cada pessoa com o mínimo necessário, nunca cluster-admin distribuído por conveniência.
1. Três probes, três perguntas
- startupProbe: "já terminou de iniciar?" — protege apps lentos no boot
- readinessProbe: "pode receber tráfego?" — se falha, sai do Service, mas não reinicia
- livenessProbe: "travou?" — se falha, o kubelet reinicia o contêiner
Nunca faça a liveness depender do banco: se o banco cair, todos os Pods reiniciam em cascata.
2. Requests e limits
Request é o que o scheduler reserva; limit é o teto. Passar do limite de memória = OOMKilled; passar do de CPU = lentidão (throttling). Defina requests sempre; muitos times evitam limite de CPU e mantêm o de memória.
3. Classes de QoS
Guaranteed (request = limit), Burstable e BestEffort (sem nada). Sob pressão de memória, BestEffort é despejado primeiro.
4. HPA: escalar por métrica
O HorizontalPodAutoscaler ajusta réplicas com base em CPU (percentual do request!), memória ou métricas customizadas. Sem requests, o HPA de CPU não funciona. Para escalar nós, use Cluster Autoscaler ou Karpenter.
5. PodDisruptionBudget
Garante um mínimo de Pods durante manutenções de nó (drain). Sem PDB, um upgrade de cluster pode derrubar todas as réplicas de uma vez.
6. RBAC: quem pode o quê
Role/ClusterRole listam verbos sobre recursos; RoleBinding liga a um usuário, grupo ou ServiceAccount. Cada app deve ter sua ServiceAccount com o mínimo — e automountServiceAccountToken: false se não fala com a API.
Na prática
Probes corretas e HPA
yaml
containers:
- name: api
startupProbe:
httpGet: { path: /health, port: http }
failureThreshold: 30
periodSeconds: 2
livenessProbe:
httpGet: { path: /health, port: http } # sem dependencias externas
periodSeconds: 10
timeoutSeconds: 2
failureThreshold: 3
readinessProbe:
httpGet: { path: /ready, port: http } # com dependencias
periodSeconds: 5
failureThreshold: 2
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: cloudshop-api }
spec:
scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: cloudshop-api }
minReplicas: 2
maxReplicas: 8
metrics:
- type: Resource
resource:
name: cpu
target: { type: Utilization, averageUtilization: 70 }RBAC mínimo e diagnóstico
yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: cloudshop-api }
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: cloudshop-api-read }
rules:
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: { name: cloudshop-api-read }
subjects: [{ kind: ServiceAccount, name: cloudshop-api }]
roleRef: { kind: Role, name: cloudshop-api-read, apiGroup: rbac.authorization.k8s.io }Nota de segurança: Evite ClusterRoleBinding com cluster-admin para aplicações. Verifique com kubectl auth can-i --as=system:serviceaccount:ns:sa.
Investigar consumo e permissões
bash
kubectl top pods
kubectl describe pod <pod> | grep -A5 -E 'Limits|Requests|Last State'
kubectl get pod <pod> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.reason}' # OOMKilled?
kubectl get hpa
kubectl auth can-i list secrets --as=system:serviceaccount:cloudshop:cloudshop-apiProbes, recursos e HPA da API
yaml
# trecho do container da API
readinessProbe:
httpGet: { path: /ready, port: 3000 } # checa dependências leves
periodSeconds: 5
livenessProbe:
httpGet: { path: /healthz, port: 3000 } # só "o processo responde?"
initialDelaySeconds: 10
failureThreshold: 3
resources:
requests: { cpu: 200m, memory: 256Mi }
limits: { memory: 512Mi }
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: api, namespace: cloudshop }
spec:
scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: api }
minReplicas: 3
maxReplicas: 15
metrics:
- type: Resource
resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }RBAC mínimo para um job de leitura
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: read-pods, namespace: cloudshop }
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: { name: read-pods, namespace: cloudshop }
subjects: [{ kind: ServiceAccount, name: reporter, namespace: cloudshop }]
roleRef: { kind: Role, name: read-pods, apiGroup: rbac.authorization.k8s.io }
# teste: kubectl auth can-i delete pods --as=system:serviceaccount:cloudshop:reporter -n cloudshop -> noPor que isso importa
Probes e limites malfeitos são a causa número um de instabilidade em clusters de empresas reais.
Erro comum
Liveness apontando para endpoint que depende do banco, causando reinício em cascata.
Dica de produção
Comece com limites generosos, observe métricas por uma semana e só então aperte.
Alerta de segurança
ServiceAccount com permissão de ler todos os Secrets é escalonamento de privilégio no cluster.
Pergunta de entrevista
O que acontece quando um container excede requests? E limits?
Glossário
- OOMKilled
- Container encerrado pelo kernel por exceder o limite de memória.
- throttling
- Redução forçada de CPU quando o container excede seu limite.
- OOMKilled
- Contêiner encerrado por ultrapassar o limite de memória.
- Throttling
- Redução forçada de CPU quando o contêiner atinge o limite.
- PDB
- PodDisruptionBudget: mínimo de Pods disponíveis durante interrupções voluntárias.
- ServiceAccount
- Identidade usada por Pods para falar com a API do Kubernetes.
Conexão com o CloudShop
Ajustar probes e limites da API do CloudShop com base no consumo medido.
Quiz da aula
1. Falha de readiness probe causa:
2. A readinessProbe falha. O que o Kubernetes faz?
3. O HPA por CPU não escala. Qual o primeiro item a checar?
Minhas anotações
Salvo automaticamente neste navegador.