Kubernetes se tornou o padrão de facto para orquestração de containers, adotado por 96% das organizações que utilizam containers segundo a CNCF Survey. No entanto, rodar Kubernetes em desenvolvimento é relativamente simples; operá-lo em produção, com alta disponibilidade, segurança e observabilidade, é um desafio completamente diferente.
Este artigo compila lições aprendidas de equipes que operam Kubernetes em escala, apresentando práticas avançadas que vão muito além do básico. Se você já tem um cluster funcionando e quer elevar seu nível operacional, este guia é para você.
Observabilidade é essencial para operar Kubernetes em produção
Arquitetura do Cluster: Decisões que Importam
Managed vs Self-Managed
A primeira decisão é se você vai gerenciar o cluster ou usar um serviço managed. Para a maioria das equipes, clusters managed (EKS, AKS, GKE) são a escolha correta, pois eliminam a complexidade de operar o plano de controle (control plane).
| Aspecto | Managed (EKS/AKS/GKE) | Self-Managed (kubeadm/Rancher) |
|---|---|---|
| Control Plane | Gerenciado pelo provedor | Sua responsabilidade |
| Atualizações | One-click upgrade | Manutenção manual |
| HA do API Server | Incluído | Configurar manualmente |
| Custo | ~$73/mês (EKS) | Servidores + operação |
| Controle | Limitado | Total |
| Curva de aprendizado | Menor | Maior |
Multi-Cluster vs Single Cluster
Para a maioria dos casos, um único cluster bem configurado é suficiente. Multi-cluster se justifica quando você precisa de:
- Isolamento entre ambientes (dev, staging, production)
- Alta disponibilidade entre regiões geográficas
- Isolamento de segurança entre equipes
- Compliance com requisitos regulatórios específicos
Namespaces: Organização e Isolamento
Namespaces são a unidade básica de organização em Kubernetes. Uma boa estratégia de namespaces previne conflitos e facilita a gestão de permissões:
- Por ambiente: development, staging, production
- Por equipe: team-backend, team-frontend, team-data
- Por aplicação: app-api, app-web, app-worker
- Sistema: kube-system, monitoring, ingress-nginx
Lições Aprendida
Evite colocar muitos serviços no mesmo namespace. Quando um namespace cresce demais, ele se torna difícil de gerenciar e monitorar. Prefira namespaces menores e mais específicos.
Gerenciamento de Recursos
Requests e Limits
Toda container DEVE ter requests e limits de CPU e memória definidos. Sem isso, um único container pode consumir todos os recursos do node, derrubando outros pods.
- Requests: Recurso garantido para o pod (o scheduler usa isso para decidir onde colocar o pod)
- Limits: Recurso máximo que o pod pode usar (se exceder, é throttled ou OOMKilled)
Regra prática: comece com requests conservadores e limits generosos. Monitore o uso real e ajuste gradualmente. Ferramentas como VPA (Vertical Pod Autoscaler) podem automatizar essa otimização.
Horizontal Pod Autoscaler (HPA)
O HPA escala automaticamente o número de réplicas de um pod baseado em métricas como CPU, memória ou métricas customizadas:
- Configure métricas customizadas para escalar baseado em negócio (ex: requisições por segundo, tamanho da fila)
- Defina minReplicas e maxReplicas adequados
- Teste o comportamento de escala em staging antes de produção
- Combine com PDB (Pod Disruption Budget) para garantir disponibilidade durante escalas
Cluster Autoscaler
O Cluster Autoscaler adiciona ou remove nodes do cluster baseado na demanda. Quando pods ficam pendentes por falta de recursos, novos nodes são provisionados automaticamente. Quando nodes ficam subutilizados, são removidos.
A configuração correta de recursos é fundamental para a estabilidade
Observabilidade: Métricas, Logs e Traces
Sem observabilidade, operar Kubernetes em produção é como pilotar de olhos fechados. Implemente as três pilares:
1. Métricas (Prometheus + Grafana)
Prometheus é o padrão de coleta de métricas no ecossistema Kubernetes. Combinado com Grafana para visualização, ele fornece visibilidade completa do cluster:
- Cluster: Uso de CPU, memória, pods, nodes
- Aplicação: Latência, throughput, taxas de erro
- Infraestrutura: Disco, rede, I/O
Alertas essenciais no Prometheus:
- Node com CPU ou memória acima de 90%
- Pod com restarts frequentes (CrashLoopBackOff)
- PVC (Persistent Volume Claim) quase cheio
- Deployment sem pods disponíveis
2. Logs (EFK/ELK ou Loki)
Centralize logs de todos os pods em um sistema de busca:
- EFK Stack: Elasticsearch + Fluentd + Kibana
- Loki + Grafana: Alternativa mais leve e custo-efetiva
- Cloud-native: CloudWatch Logs, Azure Monitor, Cloud Logging
Estruture seus logs com campos padronizados (timestamp, level, service, trace_id) para facilitar filtragem e correlação.
3. Distributed Tracing (Jaeger/Tempo)
Em arquiteturas de microsserviços, uma requisição pode passar por dezenas de serviços. Distributed tracing permite rastrear o caminho completo de uma requisição, identifying gargalos e pontos de falha.
Implemente OpenTelemetry como padrão de instrumentação — ele unifica métricas, logs e traces em um único padrão vendor-agnostic.
Deploy Strategies
A estratégia de deploy determina como novas versões são aplicadas:
Rolling Update (Padrão)
O Kubernetes substitui pods antigos por novos gradualmente. É a estratégia padrão e adequada para a maioria dos casos. Configure maxUnavailable e maxSurge para controlar a velocidade.
Blue/Green
Mantém duas versões da aplicação simultaneamente. O tráfego é alternado instantaneamente para a nova versão. Ideal quando você precisa de rollback instantâneo.
Canary
Envia uma pequena porcentagem do tráfego para a nova versão, monitora comportamento, e gradualmente aumenta. Ideal para validar mudanças com risco mínimo. Ferramentas como Argo Rollouts e Flagger automatizam canary deploys.
Recomendação
Para Produção, prefira Canary ou Blue/Green sobre Rolling Update. Eles oferecem mais controle e capacidade de rollback rápido.
Segurança em Kubernetes
Pod Security Standards
O Kubernetes oferece três níveis de segurança para pods:
- Privileged: Sem restrições (evitar em produção)
- Baseline: Restrições mínimas para prevenir configurações inseguras
- Restricted: Restrições rigorosas seguindo melhores práticas de segurança
Network Policies
Por padrão, todos os pods no Kubernetes podem se comunicar entre si. Network Policies restringem esse tráfego. Comece com uma política default deny-all e abra apenas as comunicações necessárias.
RBAC Detalhado
Configure ClusterRoles e RoleBindings com o mínimo de permissões necessário. Evite usar cluster-admin exceto para emergências. Use ferramentas como kubectl-who-can para auditar permissões.
Segurança em Kubernetes deve ser implementada desde o início
Backup e Disaster Recovery
Backup em Kubernetes vai além de backup de dados. Você precisa preservar:
- Recursos Kubernetes: Deployments, Services, ConfigMaps, Secrets (use tools como Velero)
- Dados persistentes: PVs e PVCs (snapshot + backup off-site)
- Etcd: O banco de dados do control plane (se self-managed)
- Configurações: Helm charts, Kustomize files, manifests
Teste seus procedimentos de recovery regularmente. Um backup que nunca foi testado não é um backup.
GitOps: Deploy declarativo e versionado
GitOps é uma abordagem onde o estado desejado da infraestrutura é declarado em arquivos YAML versionados no Git. Ferramentas como ArgoCD e Flux monitoram o repositório e sincronizam automaticamente o cluster.
Benefícios do GitOps:
- Auditabilidade: Cada mudança é um commit rastreável
- Rollback: Basta reverter um commit
- Reprodutibilidade: O estado do cluster é sempre previsível
- Colaboração: PRs e reviews antes de aplicar mudanças
Lições Aprendidas em Produção
- Comece simples: Não implemente tudo de uma vez. Evolua gradualmente
- Invista em observabilidade antes de escalar: Você não pode gerenciar o que não pode ver
- Automatize os patches de segurança: Use tools como Renovate para atualizar dependências
- Teste em staging com production-like traffic: Use ferramentas como Litmus para chaos engineering
- Documente tudo: Runbooks para operações comuns salvam tempo em incidentes
- Cultura de blameless post-mortems: Aprenda com falhas sem culpar indivíduos
- Negocie resource quotas por namespace: Previne que uma equipe consuma todos os recursos
Conclusão
Kubernetes em produção exige maturidade operacional significativa. Não é apenas sobre tecnologia, mas sobre processos, cultura e ferramentas trabalhando juntos. Os clusters mais bem-sucedidos são aqueles onde a observabilidade, automação e segurança foram implementadas desde o início.
Lembre-se: Kubernetes é uma ferramenta poderosa, mas complexa. Não adote porque é "moda", adote quando a complexidade justifica os benefícios de escalabilidade, portabilidade e ecossistema que ele oferece. E quando adotar, faça com planejamento, paciência e compromisso com as melhores práticas.
Sobre o Blog Wirebird
O Blog Wirebird é uma fonte confiável de conteúdo técnico sobre Cloud Computing, DevOps, arquitetura de sistemas e transformação digital. Nossa missão é democratizar o acesso a conhecimento de qualidade para profissionais e empresas que buscam inovar com tecnologia.