Lo que las entrevistas de trabajo me enseñaron sobre Kubernetes

Artículo original ↗ Discusión en Hacker News ↗

Kubernetes como el nuevo valor predeterminado

  • Muchos comentaristas dicen que Kubernetes ha “ganado” de facto frente a VM+systemd y la mayoría de los demás orquestadores, en gran medida debido a:
    • Las ofertas gestionadas en las principales nubes que se han vuelto maduras y listas para usar.
    • Un enorme ecosistema de herramientas, empresas y talento construido en torno a él.
    • Que actúa como una “lingua franca” para la infraestructura y GitOps.

Adecuación para equipos pequeños y startups

  • Hay un fuerte desacuerdo sobre cuándo Kubernetes tiene sentido:
    • Algunos lo ven razonable incluso para equipos muy pequeños si ya son “cloud native”, citando despliegues uniformes, incorporación más fácil y conocimiento compartido.
    • Otros consideran que adoptar k8s con 2–3 ingenieros es una señal de alarma: complejidad innecesaria frente a simplemente usar VMs o plataformas de contenedores más simples.
    • Varios sostienen que los beneficios no técnicos del artículo (operativos/organizativos) no compensan la complejidad con N muy pequeño.

Complejidad, actualizaciones y rotación del ecosistema

  • Muchos señalan que k8s no viene “con todo incluido”: ingress, gestión de certificados, DNS, almacenamiento y GitOps añaden múltiples controladores con sus propios ciclos de actualización y cambios incompatibles.
  • El ritmo de actualizaciones se ve como:
    • Una ventaja (seguridad regular y control de deriva con actualizaciones del clúster “con solo pulsar un botón”).
    • O una carga (rotación constante de APIs, cambios en ingress/gateway, mantener los complementos sincronizados).
  • Algunos destacan las capas de red y DNS (por ejemplo, el escalado de CoreDNS, overlays) como excesivas para muchas startups.

Alternativas y pilas “más simples”

  • Menciones frecuentes de:
    • El tradicional “linux + servidor web + base de datos + runtime del lenguaje” en VMs, a menudo gestionado con Ansible, scripts de shell o NixOS.
    • Orquestadores más ligeros y herramientas tipo PaaS (Nomad, Docker Swarm, ECS/Fargate, Cloud Run, sistemas tipo Heroku, proyectos personalizados “kube-lite”).
  • Un patrón recurrente: los equipos prueban k8s y luego algunos vuelven a configuraciones más simples y “aburridas” para reducir la carga operativa.

LLMs y facilidad de uso

  • Algunos afirman que los LLMs hacen que k8s y Terraform sean mucho más fáciles: generación de manifiestos, Helm charts, paneles de control y depuración de clústeres.
  • Otros advierten enérgicamente contra usar LLMs para trabajar en sistemas que no entiendes, porque los errores son sutiles y de alto impacto.

Cargas con estado y servicios gestionados

  • Varios sostienen que el estado duradero (bases de datos, blob stores, cachés) suele mantenerse mejor fuera de Kubernetes mediante servicios gestionados de la nube:
    • Las ofertas gestionadas se consideran más fiables y más fáciles de migrar que los operadores con estado dentro del clúster.
  • Otros informan de éxito con operadores modernos de bases de datos nativos de k8s, pero admiten que añaden una complejidad considerable.

Contratación, hype y cultura

  • Kubernetes se ve como:
    • Atractivo para contratar y mejorar el currículum; algunos lo llaman “resume++” o impulsado por el hype.
    • También una opción segura y estándar para CTOs que quieren evitar infra a medida y confiar en patrones ampliamente comprendidos.
  • Algunos critican adoptar k8s por enmascarar problemas culturales/de proceso con herramientas en lugar de corregir los fundamentos.