O guia do hater para Kubernetes

Artigo original ↗ Discussão no Hacker News ↗

Kubernetes polariza engenheiros como um padrão poderoso para implantar e escalar containers que também introduz complexidade substancial, especialmente para equipes que não precisam de seu conjunto completo de recursos. Os comentaristas ponderam seus benefícios — APIs agnósticas de cloud, ferramentas ricas, autoscaling e uma “única interface” entre ambientes — contra fragilidade operacional, curva de aprendizado íngreme, dor de templating em YAML/Helm e a tendência cultural de superengenharia. Muitos argumentam que opções mais simples (VMs, ECS, Docker Compose, Nomad, k3s, Dokku) muitas vezes são suficientes, e que o verdadeiro desafio é escolher uma infraestrutura proporcional à escala, às habilidades e às necessidades de negócio da empresa, em vez de seguir o hype.

Posição geral sobre Kubernetes

  • Muitos veem Kubernetes como poderoso, mas excessivamente complexo; outros argumentam que sua complexidade corresponde a problemas do mundo real em grande escala.
  • Visão comum: apenas uma pequena minoria “precisa” de k8s para sobreviver, mas um grupo muito maior o considera operacionalmente benéfico.
  • Vários o comparam a git ou systemd: design central sólido, UX dolorosa.

Complexidade operacional e fragilidade

  • Clusters autogeridos são descritos como frágeis: upgrades do etcd, control planes subdimensionados e falhas opacas.
  • k8s gerenciado (GKE/EKS/AKS) é frequentemente recomendado para evitar a dor do control plane, embora alguns ainda relatem “problemas estranhos” frequentes.
  • Depurar implantações falhas do Helm, crash loops e o comportamento de operators/CRDs é uma reclamação recorrente.

Ferramentas: YAML, Helm, operators, alternativas

  • Forte aversão a YAML e, especialmente, ao YAML templated pelo Go do Helm; as pessoas relatam bugs sutis de espaçamento/templating.
  • Alternativas mencionadas: kustomize, envsubst, Jsonnet, Pulumi, Terraform, CDK, cdk8s; alguns preferem “só código” em vez de YAML templated.
  • Operators e CRDs são vistos tanto como a principal força do k8s (infra programável, Ceph/Rook, operators do GitHub) quanto como uma grande fonte de complexidade e acoplamento em todo o cluster.

Autoscaling, deploys e latência

  • HPA, VPA e KEDA são elogiados quando amplamente adotados; ajustar HPA em tempo real é considerado melhor do que escalonar manualmente às 4h da manhã.
  • Deploys sem downtime são um grande motivador; muitos observam que isso também pode ser alcançado com setups blue/green mais simples e reverse proxies.
  • Cold-starts do k8s para workloads efêmeras e sensíveis à latência são difíceis de reduzir abaixo de ~0,5–2s sem trabalho profundo nos internos; alguns migram para Nomad ou schedulers personalizados.

Cloud, lock-in e portabilidade

  • Vozes pró-k8s destacam: modelo declarativo, balanceamento de carga e reinícios integrados, ferramentas de observabilidade e, especialmente, APIs agnósticas de cloud entre local, on-prem (k3s) e cloud.
  • Críticos respondem que as configurações reais ainda dependem fortemente das particularidades de cada cloud e que a “migração de cloud” é supervalorizada em relação à frequência com que isso realmente acontece.

Quando não usar Kubernetes e alternativas

  • Para sistemas simples ou de pequena escala, muitos preferem: ASGs, ECS/Fargate, Cloud Run, Docker Compose, Swarm, Nomad, Dokku, Kamal, VMs simples com scripts.
  • Usuários de homelab frequentemente consideram k3s ou apenas Docker Compose suficientes.

Dinâmicas culturais e organizacionais

  • k8s pode se tornar uma “armadilha de esperteza” e um símbolo de status, gerando culturas de heróis de plataforma e camadas infinitas de ferramentas.
  • Vários argumentam que o verdadeiro problema é a adoção movida por hype e o uso indevido, não a tecnologia em si.