Kubernetes é o padrão de orquestração de containers, mas operá-lo em produção é uma disciplina que se aprende — muitas vezes da forma mais dura. Compilamos 10 lições de anos a gerir clusters em produção, desde startups a ambientes enterprise multi-cluster.
## 1. Comece com Limites de Recursos
A lição número um do K8s em produção: **nunca rode um pod sem resource requests e limits**. Um processo com memory leak sem limits pode derrubar um nó inteiro. O scheduler precisa de requests para tomar decisões corretas.
“`yaml
resources:
requests:
memory: “256Mi”
cpu: “250m”
limits:
memory: “512Mi”
cpu: “500m”
“`
Use Vertical Pod Autoscaler (VPA) em modo recomendação para descobrir valores realistas antes de aplicá-los.
## 2. Health Checks São Obrigatórios
Liveness probe sem readiness probe é o erro mais comum. O pod reinicia mas continua a receber tráfego enquanto ainda não está pronto. Resultado: erros 502 em cascata.
– **Liveness**: “o processo ainda está vivo?” (reinicia se falhar)
– **Readiness**: “o processo está pronto para receber tráfego?” (remove do service se falhar)
– **Startup**: “o processo já arrancou?” (dá mais tempo no início, evita restart loops)
## 3. Network Policies Não São Opcionais
Por padrão, qualquer pod comunica com qualquer outro. Network Policies implementam zero-trust a nível de rede. Num cluster multi-tenant, são essenciais.
## 4. Observabilidade em 3 Pilares
Não vá para produção sem:
– **Métricas**: Prometheus + kube-state-metrics (métricas de objetos K8s)
– **Logs**: Agregação centralizada (Loki, ELK) com retenção definida
– **Tracing**: Jaeger ou Tempo para aplicações distribuídas
E dashboards: Node Exporter, K8s Cluster, NGINX Ingress e workload-specific.
## 5. Gestão de Secrets
Nunca ponha secrets em plain text no Git. Use:
– **Sealed Secrets** — secrets encriptados que só o cluster consegue abrir
– **External Secrets Operator** — sincroniza com AWS Secrets Manager, Vault, GCP
– **SOPS** — encriptação com AWS KMS, GCP KMS, PGP
## 6. Estratégia de Backup
K8s não faz backup sozinho. Precisa de:
– Backup do etcd (ou use clusters geridos que fazem isto por si)
– Backup de volumes persistentes (Velero para snapshots em S3)
– Backup de manifests (mas se usa GitOps, o Git já é o backup)
## 7. Atualizações do Cluster
Mantenha o cluster atualizado. K8s lança 3 versões por ano com ~1 ano de suporte cada. Ficar mais de 2 versões atrás significa upgrades mais arriscados. Automatize com Kured para patches de segurança.
## 8. Políticas com OPA/Gatekeeper
Kyverno ou OPA/Gatekeeper permitem validar e mutar objetos antes de chegarem ao cluster:
– “Todo deployment precisa de resource limits”
– “Imagens só podem vir do nosso registry”
– “Ingress precisa de TLS”
## 9. Multi-Cluster Não É Luxo
Um cluster por ambiente (dev, staging, prod) é o mínimo. Separar workloads críticos em clusters independentes reduz blast radius. Ferramentas como ArgoCD facilitam multi-cluster.
## 10. Automação de Disaster Recovery
Teste o seu disaster recovery regularmente. O melhor DR é o que se pratica:
– Recrie o cluster do zero usando só Terraform + ArgoCD
– Restaure volumes de backup e valide integridade
– Documente o RTO e RPO reais, não os teóricos
## Conclusão
Kubernetes resolve problemas reais mas introduz complexidade real. A diferença entre um cluster que traz paz e um que tira o sono está na disciplina de operações: resource management, observabilidade, segurança e automação.
Na Cloud Architects, operamos clusters para clientes com tudo isto como padrão — incluindo agentes autônomos que mantêm o cluster saudável 24/7.