Aprendizados dos nossos anos de Kubernetes em produção

Artigo original ↗ Discussão no Hacker News ↗

Kubernetes em produção gera reações mistas, com muitos engenheiros argumentando que sua complexidade, armadilhas operacionais (como expiração de certificados derrubando clusters) e a carga constante de upgrades não se justificam para equipes pequenas ou aplicativos simples que poderiam rodar em VMs ou em plataformas de contêiner mais leves. Outros destacam benefícios como uma abstração unificada para implantação, portabilidade entre on-prem e cloud e ferramentas ricas — desde que você use serviços gerenciados (EKS/AKS/GKE), mantenha os clusters sem particularidades e invista em uma equipe de plataforma. O tópico também aborda alternativas como ECS, Nomad, Ray e Proxmox, trade-offs em torno de workloads com estado e ambientes de desenvolvimento, além de uma preocupação mais ampla de que o Kubernetes muitas vezes é adotado cedo demais por uma escalabilidade percebida, e não por necessidade comprovada.

Kubernetes para equipes pequenas vs. grandes organizações

  • Muitos argumentam que Kubernetes é exagerado para equipes pequenas/startups; a complexidade e o custo de manutenção esmagam a velocidade.
  • Alguns dizem que ele faz mais sentido principalmente quando você tem centenas de engenheiros e uma equipe dedicada de plataforma.
  • Outros contrapõem que o tamanho da equipe é menos importante do que a complexidade e a escala do problema; algumas pessoas até usam k8s em projetos pessoais porque gostam de ter uma única abstração padrão.

Clusters gerenciados vs. auto-gerenciados

  • Há forte consenso: gerenciar sozinho os planos de controle é arriscado; expiração de certificados e problemas de atualização já causaram indisponibilidades de vários dias.
  • Ofertas gerenciadas (EKS/AKS/GKE) são vistas como muito mais confiáveis e reduzem drasticamente a dor, embora não sejam livres de falhas.
  • Vários კომენტadores veem as indisponibilidades do artigo mais como resultado de práticas operacionais ruins (sem manifests/backup, má gestão de certificados) do que de falhas inerentes do k8s.

Complexidade, abstrações e benefícios

  • Críticos listam curvas de aprendizado íngremes: PKI/certificados, etcd, rede CNI, DNS, ingress controllers, Helm, GitOps, proliferação de YAML, depreciações frequentes.
  • Defensores destacam o modelo unificado de recursos: os mesmos manifests em on-prem/cloud, armazenamento/ingress pluggáveis, descoberta automática de serviços, escalonamento, failover e fluxos de manutenção de nós.
  • Alguns descrevem o k8s como uma excelente plataforma de desenvolvimento/QA (ambientes consistentes, fácil subir topologias complexas), mas “apenas ok” para produção em comparação com runtimes mais opinativos.

Alternativas e abordagens mais simples

  • Opções sugeridas: ECS, Fargate, Azure Container Apps, Nomad, Ray, Docker Compose/Swarm, Proxmox, Ubuntu MicroCloud, VMs simples com CI/CD, ou monólitos em servidores com autoscaling.
  • Para muitos produtos, os comentaristas acreditam que algumas VMs + balanceador de carga + banco gerenciado teriam sido mais baratos, mais simples e suficientemente escaláveis.

Ambientes de desenvolvimento e GitOps

  • Algumas equipes executam clusters locais/de dev (kind/k3s/k3d, Tilt, kustomize) ou pequenos clusters compartilhados espelhando produção, muitas vezes com mocks para S3 e outros serviços.
  • GitOps (Argo/Flux) recebe reações mistas: alguns veem isso como essencial para versionamento e detecção de drift; outros acham que adiciona outra camada de sincronização e preferem Helm/kubectl diretamente.

Custo, equipe e TCO

  • Preocupação frequente: artigos raramente quantificam custos de infraestrutura, tempo de engenharia ou custo de oportunidade em comparação com stacks mais simples.
  • Vários observam que é preciso pelo menos parte de um FTE para cuidar de k8s mesmo em serviços gerenciados.

“Learnings” vs. “lessons”

  • Longos subfóruns debatem “learnings” como jargão corporativo vs. uso moderno aceitável; muitos acham irritante, alguns defendem como uma nuance útil.