Aprendizajes de nuestros años con Kubernetes en producción

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

Kubernetes en producción genera reacciones mixtas, y muchos ingenieros sostienen que su complejidad, sus trampas operativas (como que la expiración de certificados tumbe clústeres) y la carga constante de actualizaciones no se justifican para equipos pequeños o aplicaciones sencillas que podrían ejecutarse en VMs o en plataformas de contenedores más ligeras. Otros destacan ventajas como una abstracción unificada para el despliegue, portabilidad entre local y cloud, y herramientas potentes, siempre que uses servicios gestionados (EKS/AKS/GKE), mantengas los clústeres sin personalizaciones raras y inviertas en un equipo de plataforma. El hilo también menciona alternativas como ECS, Nomad, Ray y Proxmox, los compromisos de las cargas con estado y los entornos de desarrollo, y una preocupación más amplia de que Kubernetes se adopta demasiado pronto por una escalabilidad percibida en lugar de una necesidad demostrada.

Kubernetes para equipos pequeños frente a organizaciones grandes

  • Muchos sostienen que Kubernetes es excesivo para equipos pequeños/startups; la complejidad y el coste de mantenimiento aplastan la velocidad.
  • Algunos dicen que tiene sentido principalmente cuando tienes cientos de ingenieros y un equipo de plataforma dedicado.
  • Otros replican que el tamaño del equipo importa menos que la complejidad y la escala del problema; incluso algunas personas usan k8s para proyectos personales porque les gusta tener una única abstracción estándar.

Clústeres gestionados frente a autogestionados

  • Hay un fuerte consenso: autogestionar los planos de control es arriesgado; la caducidad de certificados y los problemas de actualización han causado interrupciones de varios días.
  • Las ofertas gestionadas (EKS/AKS/GKE) se consideran mucho más fiables y reducen drásticamente el dolor, aunque no están libres de caídas.
  • Varios comentaristas ven las caídas del artículo más como resultado de malas prácticas operativas (sin manifiestos/copia de seguridad, mala gestión de certificados) que de fallos inherentes de k8s.

Complejidad, abstracciones y beneficios

  • Los críticos enumeran curvas de aprendizaje pronunciadas: PKI/certificados, etcd, redes CNI, DNS, controladores de ingress, Helm, GitOps, proliferación de YAML, deprecaciones frecuentes.
  • Los partidarios destacan el modelo unificado de recursos: los mismos manifiestos en local/cloud, almacenamiento/ingress conectables, descubrimiento automático de servicios, escalado, failover y flujos de trabajo de mantenimiento de nodos.
  • Algunos describen k8s como una excelente plataforma de desarrollo/QA (entornos consistentes, fácil levantar topologías complejas), pero “solo aceptable” para producción en comparación con runtimes más opinados.

Alternativas y enfoques más simples

  • Opciones sugeridas: ECS, Fargate, Azure Container Apps, Nomad, Ray, Docker Compose/Swarm, Proxmox, Ubuntu MicroCloud, VMs normales con CI/CD, o monolitos sobre servidores con autoescalado.
  • Para muchos productos, los comentaristas creen que unas pocas VMs + balanceador de carga + base de datos gestionada habrían sido más baratas, más simples y suficientemente escalables.

Entornos de desarrollo y GitOps

  • Algunos equipos ejecutan clústeres locales/de desarrollo (kind/k3s/k3d, Tilt, kustomize) o pequeños clústeres compartidos que reflejan producción, a menudo con mocks para S3 y otros servicios.
  • GitOps (Argo/Flux) recibe reacciones mixtas: algunos lo consideran esencial para el versionado y la detección de desvíos; otros creen que añade otra capa de sincronización y prefieren Helm/kubectl directos.

Coste, personal y TCO

  • Preocupa con frecuencia que los artículos rara vez cuantifican los costes de infraestructura, el tiempo de los ingenieros o el coste de oportunidad frente a stacks más simples.
  • Varios señalan que se necesitan al menos FTE parciales para encargarse de k8s incluso en servicios gestionados.

“Learnings” frente a “lessons”

  • Un largo subhilo debate “learnings” como jerga corporativa frente a un uso moderno aceptable; a muchos les resulta irritante, y algunos lo defienden como un matiz útil.