O que entrevistas de emprego me ensinaram sobre Kubernetes

Artigo original ↗ Discussão no Hacker News ↗

Kubernetes como o novo padrão

  • Muitos comentadores dizem que o Kubernetes efetivamente “venceu” o VM+systemd e a maioria dos outros orquestradores, em grande parte devido a:
    • Ofertas gerenciadas nas principais nuvens terem se tornado maduras e prontas para uso.
    • Um enorme ecossistema de ferramentas, empresas e talentos construído em torno dele.
    • Ele atuar como uma “língua franca” para infraestrutura e GitOps.

Adequação para equipes pequenas e startups

  • Há forte discordância sobre quando o Kubernetes faz sentido:
    • Alguns o veem como razoável até mesmo para equipes muito pequenas, se já forem “cloud native”, citando implantações uniformes, onboarding mais fácil e conhecimento compartilhado.
    • Outros veem adotar k8s com 2–3 engenheiros como um sinal de alerta: complexidade desnecessária em vez de apenas usar VMs ou plataformas de contêiner mais simples.
    • Vários argumentam que os benefícios não técnicos do artigo (operacionais/organizacionais) não compensam a complexidade em um N muito pequeno.

Complexidade, upgrades e rotatividade do ecossistema

  • Muitos observam que k8s não é “batteries included”: ingress, gerenciamento de certificados, DNS, armazenamento e GitOps adicionam múltiplos controladores com seus próprios ciclos de upgrade e mudanças incompatíveis.
  • O ritmo de upgrade é visto como:
    • Um recurso (segurança regular e controle de deriva com upgrades de cluster “push-button”).
    • Ou um fardo (rotatividade constante de APIs, mudanças em ingress/gateway, manter addons sincronizados).
  • Alguns enfatizam as camadas de rede e DNS (por exemplo, escalonamento do CoreDNS, overlays) como exageradas para muitas startups.

Alternativas e stacks “mais simples”

  • Menções frequentes de:
    • “linux + web server + database + language runtime” tradicionais em VMs, muitas vezes gerenciados com Ansible, scripts shell ou NixOS.
    • Orquestradores mais leves e ferramentas do tipo PaaS (Nomad, Docker Swarm, ECS/Fargate, Cloud Run, sistemas semelhantes ao Heroku, projetos customizados “kube-lite”).
  • Um padrão recorrente: equipes tentam k8s, depois algumas retornam a configurações mais simples e “chatas” para reduzir a carga operacional.

LLMs e facilidade de uso

  • Alguns afirmam que LLMs tornam k8s e Terraform dramaticamente mais fáceis: gerando manifests, charts de Helm, painéis e depurando clusters.
  • Outros alertam fortemente contra usar LLMs para trabalhar em sistemas que você não entende, porque os erros são sutis e de alto impacto.

Workloads com estado e serviços gerenciados

  • Vários argumentam que estado durável (bancos de dados, blob stores, caches) geralmente é melhor mantido fora do Kubernetes via serviços gerenciados da nuvem:
    • As ofertas gerenciadas são consideradas mais confiáveis e mais fáceis de migrar do que operadores com estado dentro do cluster.
  • Outros relatam sucesso com operadores modernos de banco de dados nativos de k8s, mas admitem que eles adicionam complexidade significativa.

Contratação, hype e cultura

  • Kubernetes é visto como:
    • Atrativo para contratação e para enriquecer o currículo; alguns chamam isso de “resume++” ou movido por hype.
    • Também uma escolha segura e padrão para CTOs que querem evitar infraestrutura sob medida e confiar em padrões amplamente compreendidos.
  • Alguns criticam a adoção de k8s por mascarar problemas culturais/de processo com ferramentas, em vez de corrigir os fundamentos.