Kubernetes para Gerentes V2
Em outubro de 2023 publiquei o post Kubernetes para Gerente voltado para gestores de times técnicos. Naquele momento, o tema parecia urgente porque havia um movimento quase emocional em direção ao Kubernetes. Muitos gestores com quem eu conversava sentiam que precisavam migrar simplesmente porque outras empresas do mercado estavam fazendo o mesmo.
As perguntas que levantei naquela época tinham um objetivo claro: reduzir o ruído, baixar a ansiedade e criar um diálogo mais racional entre quem gerencia times e quem toma decisões técnicas no dia a dia, os techleads.
Passados pouco mais de dois anos, a pergunta “migrar ou não migrar para Kubernetes” praticamente deixou de existir. O Kubernetes se consolidou como uma plataforma madura e extremamente versátil. Ainda assim, em 2025, o diálogo continua necessário e as perguntas precisam evoluir, por isso resolvi criar essa V2.
A seguir, veja algumas questões que considero fundamentais no contexto atual:
Escalabilidade, capacidade e custo
Em vez de simplesmente “adicionar mais nós”, vamos usar Karpenter para provisionamento just-in-time ou ainda dependemos apenas do cluster autoscaler tradicional?
Como está a configuração do Vertical Pod Autoscaler (VPA) para evitar desperdício?
Além de CPU e memória, as aplicações exigem GPUs ou TPUs para workloads de IA ou LLMs?
Vamos usar HPA baseado apenas em CPU? HPA + métricas customizadas? Já testou se a regra funciona?
As aplicações suportam scale-to-zero no Kubernetes?
O time entende o impacto financeiro do autoscaling? Existe visibilidade clara de custo por aplicação ou por namespace?
Tráfego, rede e exposição de serviços
Ainda vamos utilizar Ingress Controllers legados ou faz sentido migrar para o Kubernetes Gateway API para obter mais controle sobre tráfego L4 e L7?
O NGINX vai deixar de ser o ingress controller? Existe planos de migração?
Como será implementado o mTLS?
O rate limit será feito no gateway ou via service mesh para suportar picos extremos? É necessário um novo deploy para ajustar essas políticas? Pode ser feito sem GMUD?
Segurança, identidade e segredos
Vamos utilizar External Secrets integrado ao provider de cloud?
Como as aplicações se autenticam em serviços externos?
Estamos usando serviços de identidade para eliminar chaves e segredos estáticos?
Ainda existem secrets definidos diretamente em YAML ou, pior, versionados em repositórios?
Nas imagens, existe uma estratégia clara para scanning contínuo de CVEs e remediação?
Resiliência, disponibilidade e dados
Como está definida a estratégia de backup do cluster e das aplicações? Não estamos assumindo que “o cluster nunca vai cair”, certo?
O cluster será “zonal” ou regional?
As aplicações estão preparadas para falha de zona? O banco de dados também?
O custo de uma arquitetura multi-AZ está justificado pelo negócio e alinhado com a arquitetura? Quem tomou essa decisão?
O time entende os limites de escalabilidade do etcd e seus impactos operacionais?
Performance e testes
Já foram executados testes automatizados de carga, stress e spike?
Esses testes consideram todas as aplicações rodando simultaneamente?
Em cenários como Black Friday, todas as aplicações estarão sob carga máxima ao mesmo tempo. Sim, por que na black friday todas as APPs vão estar em utilização máxima ao mesmo tempo.
As aplicações implementam corretamente liveness, readiness e startup probes? Essa pergunta continua válida desde sempre.
Organização, isolamento e governança
Além da separação por namespaces, existem Network Policies, ResourceQuotas e LimitRanges bem definidos?
O acesso ao cluster segue o princípio de menor privilégio via RBAC?
Os times entendem claramente quais permissões possuem e por quê?
Operação, GitOps e governança de mudanças
O cluster é gerenciado via GitOps com ferramentas como ArgoCD ou Flux?
Usar kubectl diretamente em produção não escala e não é auditável. Isso está claro?
Existe estratégia de rollback automatizado?
Como os drifts de configuração são detectados e tratados?
É possível fornecer trilhas de auditoria claras sobre mudanças em ambientes produtivos?
O Disaster Recovery já foi testado de verdade ou existe apenas um procedimento documentado que nunca foi executado?
Observabilidade e suporte
Como os times de desenvolvimento acessam métricas, logs centralizados e traces distribuídos?
Existe uma política clara de retenção de logs? Ela atende requisitos de compliance e auditoria?
Como os times de desenvolvimento podem ter acesso para visualizar métricas? Aos logs centralizados? Aos traces distribuídos?
Qual é a política de retenção de logs? Atendem ao compliance da empresa? É auditável?
Modelo operacional
Vamos usar cluster gerenciado ou self-hosted? Em 2025, operar Kubernetes “na mão” não justifica, né?
O time está preparado para dar suporte fora do horário comercial? Existe compartilhamento de conhecimentos?
Existe uma documentação da infra?
A documentação é viva? Existem runbooks claros para os times de suporte e plantão?
Resumo
As perguntas fundamentais sobre arquitetura, disponibilidade e operações permanecem relevantes, mas o ecossistema Kubernetes amadureceu de forma significativa. Em 2025, alguns temas deixaram de ser diferenciais e se tornaram obrigatórios:
- Segurança passou a ser mais sofisticada e inegociável
- GitOps deixou de ser opcional e virou padrão operacional
- FinOps ganhou importância crítica com o aumento dos custos de cloud
- Platform Engineering emergiu como disciplina estruturante
- Observabilidade se consolidou com OpenTelemetry
- Workloads de IA e ML se tornaram comuns em clusters de produção
Minha sugestão é simples, transforme essas perguntas em um checklist de avaliação ou em um ponto de partida para conversas mais maduras com os tech leads do seu time.
Não se deixe convencer por quem tem um vacubulário cheio de siglas e expressões estranhas, questione sempre. Gerenciar times técnicos nunca foi simples. Exige estudo contínuo, decisões difíceis e muito trabalho. Quem acha que é fácil ainda não entendeu o tamanho do desafio, mas tamos aqui para trazer luz aos temas.
Abraços!
Vida longa e próspera a todos!!
Referências
- https://www.cve.org/
- https://velero.io/
- https://etcd.io/docs/v3.3/dev-guide/limit/
- https://kubernetes.io/docs/concepts/workloads/autoscaling/vertical-pod-autoscale/
- https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/
- https://kubernetes.io/docs/concepts/workloads/autoscaling/
- https://kubernetes.io/docs/concepts/services-networking/network-policies/
- https://kubernetes.io/docs/concepts/policy/resource-quotas/
- https://kubernetes.io/docs/concepts/policy/limit-range/
Entre em contato:
NewsLetter - https://engineeringmanager.com.br/Linkdin - linkedin.com/in/leonardoml/
Twitter: @infraascode_br
Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!
|
|
