Guía para quienes odian Kubernetes

Guía crítica sobre Kubernetes

• Kubernetes se ha ganado entre algunos técnicos la reputación de ser innecesariamente complejo y una pérdida de tiempo, y usarlo en equipos pequeños suele considerarse sobreingeniería.
• En Jamsocket lo han operado en producción durante varios años y encontraron una forma eficiente de usarlo: aprovechar solo las funciones necesarias e ignorar el resto.

Por qué usar Kubernetes

• Kubernetes es el camino más consolidado cuando quieres estas tres cosas al mismo tiempo:
  • Ejecutar múltiples procesos/servidores/trabajos programados.
  • Ejecutarlos con redundancia y distribuir la carga.
  • Configurar su definición y sus relaciones mutuas como código.
• Kubernetes es una capa de abstracción que permite tratar un pool de computadoras como si fuera una sola computadora sin cabeza (headless).
• Jamsocket despliega varias veces al día, y si su producto tiene problemas también se ven afectados los productos de sus clientes, así que las implementaciones continuas les dan la confianza para desplegar con frecuencia.

Cómo usan Kubernetes

• Jamsocket es un servicio que crea procesos dinámicos que pueden comunicarse con aplicaciones web, parecido a AWS Lambda, pero la vida del proceso depende de una conexión WebSocket y no de una sola petición/respuesta.
• Usan Kubernetes para operar procesos de larga duración como el servidor API, el registro de contenedores, controladores, recolectores de logs, algunos servicios DNS y la recolección de métricas.
• Cosas para las que no usan Kubernetes: procesos temporales, sitios estáticos/de marketing y cosas que almacenan datos directamente.
• Usan Google Kubernetes Engine para delegar externamente la administración de Kubernetes, y migrar a Amazon EKS sería relativamente sencillo si hiciera falta.

Recursos de Kubernetes que usan activamente

• Deployments: la mayoría de los pods se crean mediante despliegues.
• Services: usan ClusterIP para servicios internos y LoadBalancer para servicios externos.
• CronJobs: los usan para scripts de limpieza y tareas similares.
• ConfigMaps y Secrets: los usan para pasar datos a los recursos anteriores.

Cosas que usan con cautela

• Usan StatefulSet y PersistentVolumeClaim, pero prefieren guardar los datos importantes en servicios administrados fuera de Kubernetes.
• Evitan RBAC en la medida de lo posible porque añade complejidad.

Cosas que evitan activamente

• Escribir YAML a mano: generan las definiciones de recursos de Kubernetes con TypeScript y Pulumi.
• Recursos no estándar y operadores: permiten que software de terceros use la infraestructura de Kubernetes, pero en la práctica son difíciles de manejar.
• Helm: no lo usan por los operadores y las convenciones de YAML.
• Todo lo que tenga "mesh" en el nombre: consideran que no lo necesitan.
• Recursos Ingress: evitan añadir indirección innecesaria.
• Replicar localmente todo el stack de k8s: usan Docker Compose o scripts propios para levantar solo las partes necesarias del sistema.

La gente no debería esperar a un Pod

• Kubernetes fue diseñado poniendo el foco en la robustez y la modularidad por encima del tiempo de arranque de los contenedores, y no es adecuado cuando una persona tiene que esperar a que arranque un Pod.
• Jamsocket usa Plane, un orquestador en Rust con licencia MIT, para programar y ejecutar rápidamente procesos para cargas de trabajo interactivas.

Abstracciones de nivel superior

• Algunas alternativas a Kubernetes son muy buenas, especialmente cuando no necesitas definir la infraestructura como código.
• También se puede elegir otra solución en lugar de Kubernetes usando servicios como Railway, Render y Flight Control.
• Si administras tu enfoque hacia Kubernetes de forma sistemática, nadie puede decir que es demasiado pronto.

Opinión de GN⁺

• Aunque Kubernetes es una herramienta poderosa para manejar complejidad y automatización, especialmente en sistemas a gran escala, esa misma complejidad puede ser una carga para proyectos pequeños o startups.
• Este artículo propone maneras de evitar la complejidad excesiva que puede surgir al usar Kubernetes, ayudando a que principiantes o equipos pequeños también puedan aprovechar sus ventajas.
• Antes de usar Kubernetes, hay que evaluar cuidadosamente si las funciones que realmente se necesitan justifican la complejidad de administración y el costo, considerando también la capacidad técnica del equipo.
• En lugar de Kubernetes, puede ser mejor usar servicios más simples y fáciles de administrar. Por ejemplo, Docker Swarm, Apache Mesos y Nomad, cada uno con sus propias ventajas y desventajas.
• Al adoptar Kubernetes, también hay que considerar la integración con la infraestructura existente, la seguridad, el costo operativo y la curva de aprendizaje.
• Los beneficios de elegir Kubernetes incluyen escalabilidad, alta disponibilidad y una experiencia de despliegue consistente en distintos entornos de nube. Pero para ello hace falta comprender la gestión de recursos y la orquestación.

[GN⁺]

Opiniones de Hacker News

• Resumen del primer comentario:

  • Cuando se adopta un sistema complejo como Kubernetes, esa complejidad sigue expandiéndose y varios componentes se refuerzan entre sí hasta volverse considerados indispensables.
  • Cuando la nube apareció por primera vez, a la gente le atraía reducir la complejidad del balanceo de carga y la administración de bases de datos.
  • Los servidores de aplicaciones sin estado (stateless) no eran un gran problema de mantenimiento, pero al evangelizar los microservicios se terminaron creando problemas que no existían.
  • Ahora esa cultura ya se asentó y cuesta simplemente asentir ante la afirmación de que los microservicios son indispensables.

• Resumen del segundo comentario:

  • Como alguien que introduce Kubernetes en pymes, comenta que hubo ingenieros inconformes, pero que la mayoría respondió que está satisfecha.
  • Kubernetes es complejo, pero es una herramienta para problemas complejos.
  • Tener un estándar es mejor que un caos simple no documentado, y sostiene que kubectl explain X es mucho mejor que la documentación de AWS.
  • Kubernetes sí es complejo, pero funciona igual que en los trabajos anteriores de muchos desarrolladores, y la velocidad importa.

• Resumen del tercer comentario:

  • Criticar a Kubernetes está de moda, pero sigue siendo la mejor solución.
  • Permite definir la infraestructura de forma declarativa y ofrece balanceo de carga, autorrecuperación y escalado.
  • Proporciona una gran observabilidad de todo el stack y permite usar mucho software ya empaquetado.
  • Se puede construir una infraestructura casi igual en la nube, en servidores propios y en entornos locales, evitando depender de un proveedor de nube específico.

• Resumen del cuarto comentario:

  • Una gran ventaja de Kubernetes son Helm y los Operators.
  • Si se va a pagar el costo de la complejidad, entonces también se debería obtener el beneficio de un “App Store” de componentes de infraestructura y de poder gestionar las operaciones de forma programática.
  • Por ejemplo, para configurar algo tan complejo como Ceph, Rook es una buena opción.
  • Helm u Operators no convierten la infraestructura en appliances administrados “turnkey”, pero las interfaces declarativas en general son mejores de administrar.

• Resumen del quinto comentario:

  • Kubernetes es una buena tecnología, pero por su complejidad tiende a convertir a sus mantenedores en los héroes de la empresa.
  • La gran cantidad de ajustes y palancas puede desviar la atención de los objetivos reales del proyecto.

• Resumen del sexto comentario:

  • La empresa actual está dividida entre Kubernetes y un sistema de despliegue personalizado basado en Ansible.
  • El enfoque con Ansible funciona bien, pero migrar a Kubernetes puede reducir los tiempos de despliegue de horas a minutos y permitir autoescalado más rápido y eficiente.
  • Entre los equipos anteriores, el feedback constante fue la dificultad de averiguar por qué falla un despliegue con Helm y la necesidad de aprender una nueva forma de operar.

• Resumen del séptimo comentario:

  • En una conversación con un exingeniero de confiabilidad del sitio de Google, se dijo que las empresas que realmente necesitan Kubernetes se pueden contar con los dedos de una mano.
  • Mucha gente tiende a desarrollar siguiendo la moda.

• Resumen del octavo comentario:

  • Kubernetes puede ser la herramienta correcta, pero debe aceptarse como un mal necesario.
  • El software que puede fallar en la colaboración por fallas de múltiples partes suele causar problemas con frecuencia.

• Resumen del noveno comentario:

  • Escribir YAML directamente puede ser un problema, por lo que en su lugar usan TypeScript y Pulumi para generar definiciones de recursos de Kubernetes.
  • En vez de hacer lint a YAML, introducen un runtime completo de lenguaje de programación y librerías de terceros, además de la complejidad adicional de mantener versiones y compilar proyectos.

• Resumen del décimo comentario:

  • Como alguien que fue entusiasta de Kubernetes, opina que lo bueno de Kubernetes son los elementos básicos (deployment, service, configmaps) y que el resto solo debería usarse en situaciones especiales.
  • El equipo prefiere escribir YAML puro y usar kustomize para mantener la configuración clara y explícita.