0 XP
Módulo 8 · Kubernetes e Helm

Probes, recursos, autoscaling e RBAC

Avançado 50 min+25 XPkubectlHPARBAC

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-api

Probes, 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  -> no

Por 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. 1. Falha de readiness probe causa:

  2. 2. A readinessProbe falha. O que o Kubernetes faz?

  3. 3. O HPA por CPU não escala. Qual o primeiro item a checar?

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima