Kubernetes em produção: 10 lições que só se aprende com downtime

Kubernetes é a plataforma de orquestração de containers mais adotada do mundo. Mas rodar K8s em produção é radicalmente diferente de rodar em laboratório. Estas 10 lições vêm de incidentes reais — cada uma custou horas de downtime, madrugadas em war rooms e postmortems dolorosos.

1. Sempre defina resource requests e limits

Sem resource requests e limits, o scheduler do Kubernetes não consegue tomar decisões inteligentes. Pods sem limits podem consumir toda a memória do node e causar OOMKill em cascata.

```yaml

resources:

requests:

cpu: "250m"

memory: "256Mi"

limits:

cpu: "500m"

memory: "512Mi"

```

Regra de ouro: requests devem refletir o consumo médio; limits devem acomodar picos sem exagero. Use VPA (Vertical Pod Autoscaler) para sugestões baseadas em métricas reais.

2. PodDisruptionBudgets são obrigatórios

Sem PDB, um `kubectl drain` durante manutenção pode derrubar todos os pods de um serviço simultaneamente.

```yaml

apiVersion: policy/v1

kind: PodDisruptionBudget

metadata:

name: api-pdb

spec:

minAvailable: 2

selector:

matchLabels:

app: api-server

```

3. Health probes precisam ser inteligentes

Liveness probes que retornam 200 sempre são inúteis. Readiness probes que verificam dependências externas podem causar restart loops.

```yaml

livenessProbe:

httpGet:

path: /healthz

port: 8080

initialDelaySeconds: 30

periodSeconds: 10

failureThreshold: 3

readinessProbe:

httpGet:

path: /ready

port: 8080

initialDelaySeconds: 5

periodSeconds: 5

```

Dica: liveness verifica se o processo está vivo; readiness verifica se pode receber tráfego. Nunca misture os dois.

4. RBAC não é opcional

Cluster admin para todos é receita para desastre. Implemente RBAC granular desde o dia zero.

```yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

namespace: producao

name: deployer

rules:

resources: ["deployments"]

verbs: ["get", "list", "update", "patch"]

```

5. Namespace isolation com Network Policies

Sem Network Policies, qualquer pod pode se comunicar com qualquer outro pod no cluster. Em caso de comprometimento, o blast radius é o cluster inteiro.

```yaml

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: deny-all-ingress

namespace: producao

spec:

podSelector: {}

policyTypes:

```

6. Logging e observabilidade centralizados

Quando um pod reinicia, os logs anteriores se perdem. Sem logging centralizado, debugging pós-incidente é impossível. Use Loki, Fluentd ou Datadog desde o primeiro deploy.

7. Image pull policy e registry privado

Usar `latest` tag em produção é roleta russa. Sempre use tags imutáveis com digest e registry privado com scan de vulnerabilidades.

8. Secrets management adequado

Kubernetes Secrets são base64, não criptografados. Use Sealed Secrets, External Secrets Operator ou Vault para secrets de produção.

9. Horizontal Pod Autoscaler com métricas custom

HPA baseado apenas em CPU é insuficiente. Configure métricas custom como requests per second, queue depth ou latência P99.

10. Teste o disaster recovery regularmente

Backup do etcd, restore de namespaces, failover multi-região — se você nunca testou, não funciona. Simule falhas em ambientes de staging mensalmente.

Conclusão

Kubernetes em produção exige disciplina, observabilidade e automação. Cada uma dessas lições poderia ter sido evitada com preparação adequada. Invista em plataforma engineering e SRE — o custo de prevenção é sempre menor que o custo de downtime.