Querido amigo, construiste Kubernetes

• Carta a un amigo

  • Explica cómo intentó evitar Kubernetes, pero al final terminó creando un sistema parecido.
  • El amigo eligió una "tecnología aburrida" y quería una ejecución simple de contenedores, pero al final surgieron problemas por scripts y configuraciones complejas.
  • Incluso al cambiar a Docker Compose, se dio cuenta de que no podía resolver todos los problemas y que se necesitaban soluciones separadas para despliegue, actualizaciones continuas, rollback y escalado.

• Escalado de servidores y complejidad de red

  • Surge la necesidad de escalar a un segundo servidor.
  • Intenta el descubrimiento de servicios usando una red superpuesta como Tailscale.
  • Se esfuerza por resolver la complejidad de red, pero al final se enfrenta a aún más problemas.

• Mantenimiento y automatización

  • Surge la pregunta de quién administrará las configuraciones complejas y los cambios de configuración no documentados cuando la persona que creó los scripts se vaya de vacaciones o deje la empresa.
  • Para resolver los problemas de mantenimiento de los scripts personalizados, usa Ansible para volver las VM inmutables y gestionables por versión.
  • Piensa que, al no usar Kubernetes, será más fácil de mantener.

• Creación de contenedores y problemas de seguridad

  • Aparece el requisito de crear otros contenedores de manera programática.
  • Montar el socket de Docker en una aplicación web es riesgoso desde el punto de vista de seguridad, así que escribe un servicio aparte para resolverlo.
    • Resuelve el problema escribiendo un servicio separado que solo expone las partes seguras de la API de Docker.

• Conclusión

  • Al final se da cuenta de que terminó construyendo un sistema similar a Kubernetes.
    • Completa un sistema complejo que incluye un formato de configuración estándar, método de despliegue, red superpuesta, descubrimiento de servicios, nodos inmutables y un servidor API

• PS

  • No niega la posibilidad de que exista una solución mejor para reemplazar Kubernetes.
  • Pero recomienda entender bien los problemas que Kubernetes intenta resolver antes de concluir que es complejo.

[savvykang]

No termino de entender eso de adoptar Kubernetes para resolver el traspaso de despliegues.

[kandk]

El mantenimiento y la automatización se pueden gestionar fácilmente a nivel de código.
También es posible hacer infraestructura como código.

[savvykang]

En entornos de servicios de k8s administrados como EKS hay balanceador de carga y también se puede integrar Route 53, pero en k8s autohospedado no hay implementación de balanceador de carga y la integración con DNS también es limitada. Supongo que en empresas que tienen un equipo dedicado a administrar k8s, las ventajas que mencionaste sí podrían ser reales.

A primera vista parece una solución razonable, pero cuando la usas en la práctica no funciona en todas las situaciones

[kandk]

Es fácil de usar incluso sin un equipo de administración de k8s. Solo hay que usar EKS.

[savvykang]

¿No es básicamente lo mismo que afirmar que con solo entregar el código fuente ya queda completada la transferencia de responsabilidades? Me parece que igual siguen siendo necesarios el manual de trabajo y el historial de ejecución de las tareas.

[kbumsik]

La Infra as Code, en sí, existe precisamente para que todo termine con solo entregar el código fuente.
Ah, claro, pero igual que con cualquier código, tiene que haber una documentación básica.

[kandk]

Es posible si el código fuente está bien escrito y la documentación está bien hecha.
Tener por separado un manual de trabajo y un historial de ejecución de tareas ayudaría, pero parece que eso es otro tema distinto a este artículo.

[GN⁺]

Opiniones de Hacker News

• He tenido experiencia desplegando con éxito usando scripts de shell en varias empresas

  • Con 2 servicios PHP se manejaban más de mil millones de solicitudes al día, y los despliegues se hacían sin tiempo de inactividad transfiriendo archivos al servidor y ejecutando migraciones
  • En industrias que no necesitan escala web, como las cuentas de retiro, los despliegues se hacían desde Jenkins con comandos de Docker
  • Los entornos de prueba podían levantarse bajo demanda en unos minutos
  • La empresa actual quiere adoptar Kubernetes, pero está teniendo dificultades por la complejidad

• Kubernetes requiere dos o tres personas dedicadas solo a gestionar archivos YAML

  • Si eliges un proveedor cloud, puede resolver las partes complejas, pero con un costo adicional
  • Los archivos YAML son archivos de configuración que no deberían escribir personas, sino generarse con herramientas
  • La mayoría de los sitios web y servicios no necesitan Kubernetes

• La idea de que lo simple es frágil es equivocada

  • Entender y depurar la complejidad de los archivos YAML y de Kubernetes es más difícil
  • Una alternativa a Kubernetes son los scripts de shell

• Hay casos en los que Kubernetes no es necesario

  • Con instancias EC2 y scripts de shell simples se puede manejar a más de 100,000 usuarios concurrentes
  • Si no hay problemas, no hace falta cambiar por cambiar

• Con scripts de shell se pueden gestionar fácilmente reglas de iptables y ediciones de sysctl

  • En lugar de crear contenedores de forma programática usando una cola de trabajos, se pueden empujar las tareas

• Criticar Kubernetes es visto como algo poco profesional

  • Si no se trata de una aplicación a gran escala como Google o Netflix, es mejor escribir scripts simples

• Es incorrecto asumir que todas las limitaciones de un sistema hecho en casa son costos y que toda la flexibilidad de una solución genérica es una ventaja

  • Se quiere que el código siga patrones similares y que los servicios se desplieguen de la misma manera

• El problema de Kubernetes es que innumerables bibliotecas de código abierto hacen que el sistema sea difícil de entender y provoquen errores

• Quienes ya superaron la curva de aprendizaje de Kubernetes dicen que la complejidad no es tan grave

  • Un curso para enseñar Kubernetes a desarrolladores toma unos 30 minutos y les permite escribir charts de Helm