Yo no necesitaba Kubernetes, y probablemente tú tampoco

Por qué dejé Kubernetes y elegí Google Cloud Run

Antecedentes de la adopción de Kubernetes

• En Clara.io, una plataforma de edición 3D en línea lanzada en 2013, se optimizó la infraestructura usando servidores bare metal, pero eso requería demasiado trabajo para la administración y el monitoreo del hardware.
• En 2018, para el proyecto Threekit.com, se eligió Kubernetes. En ese momento, Azure, AWS y Docker estaban adoptando Kubernetes como estándar, y se estaba volviendo dominante.

Limitaciones de Kubernetes

1. Problemas de costo:

   • El costo base de construir un clúster es alto, incluyendo nodos de administración y configuraciones redundantes del clúster.
   • El autoescalado lento obliga a sobreaprovisionar servicios, lo que genera costos por recursos no utilizados.

2. Dificultad para gestionar cargas de trabajo:

   • La programación de trabajos es compleja, y tanto el scheduler integrado como Argo son ineficientes para grandes volúmenes de trabajo.

3. Sobrecarga de complejidad:

   • Su abundancia de funciones hace que incluso las tareas simples se vuelvan complejas.
   • Administrar Kubernetes requiere personal de DevOps dedicado, lo que termina elevando los costos.

Migración a Google Cloud Run

Cloud Run reemplaza la complejidad de Kubernetes y ofrece un entorno simplificado y rentable.

Nueva configuración

• Infraestructura basada en contenedores Docker:
  • Incluye servicios con autoescalado y contenedores para trabajos de larga duración.
  • Cloud Run automatiza el despliegue de contenedores, el escalado, la gestión de interrupciones y la ejecución de tareas.

Ventajas de Cloud Run

1. Eficiencia de costos:

   • Se cobra según el tiempo de uso de CPU y memoria.
   • Los servicios inactivos no generan costo.
   • Ejemplo: el sitio Web3D Survey puede operar por $4 al mes mientras procesa 500,000 visitas mensuales.

2. Autoescalado rápido y estable:

   • Escala en cuestión de segundos, más rápido que Kubernetes.
   • Puede responder con rapidez a picos repentinos de demanda.

3. Sin carga de administrar Kubernetes:

   • Cloud Run está basado en Borg de Google, por lo que no hace falta administrar clústeres de Kubernetes.

4. Tareas asíncronas sencillas:

   • Con Cloud Run Tasks, el reintento automático y la ejecución de trabajos masivos se vuelven simples.

Posible problema de Kubernetes: el lock-in del clúster

• Depender de funciones de Kubernetes dificulta integrar o ampliar recursos fuera del clúster.
• Eso termina atando la arquitectura a una infraestructura específica, lo que complica la expansión y la migración y aumenta los costos.

Preguntas comunes sobre usar Cloud Run

“¿No te preocupa depender de GCP?”

• Con una configuración basada en Docker, migrar a otra nube como AWS podría hacerse en alrededor de una semana.
• En la práctica, fuera de factores políticos, rara vez se cambia de proveedor de nube.

“¿Cloud Run no es al final Kubernetes gestionado?”

• Cloud Run usa la interfaz de Knative, pero corre sobre Borg de Google, no sobre Kubernetes.
• Elimina la complejidad de Kubernetes y ofrece una interfaz simplificada.

Desventajas del flujo de trabajo actual

1. La gestión de nombres de servicios es incómoda:

   • Hace falta una capa de abstracción para mantener una configuración consistente entre el entorno local y el servidor.
   • No tiene las funciones de gestión de nombres que ofrece Kubernetes.

2. Falta de emulación de Cloud Run Task:

   • No existe un entorno simple de emulación local para desarrollar tareas, incluyendo captura y seguimiento de la salida de logs.

Conclusión

• Cloud Run es la mejor solución en términos de costo, velocidad, escalabilidad y simplicidad
• Kubernetes puede ser útil para grandes empresas o para casos con requisitos complejos, pero
• En proyectos donde importan la simplicidad y la eficiencia, Cloud Run es mucho más práctico
• PD: Tal vez algunos problemas podrían resolverse agregando extensiones específicas a Kubernetes, pero eso solo aumentaría la complejidad, y no quiero depender de un entorno de Kubernetes que excede necesidades simples

[blurblah]

No existe la solución mágica. Supongo que se trata de usarlo bien según la situación jaja.
Si adoptas Kubernetes sin criterio solo porque está de moda, puede terminar complicándote la vida, pero aun así creo que en entornos de mayor escala es una herramienta bastante buena.
Incluso si lo adoptas, si solo lo implementas y ahí termina todo, no vas a poder aprovecharlo bien.
Y, como pasa con cualquier herramienta, no puede satisfacer al 100% las necesidades de los desarrolladores o los usuarios, así que parece indispensable contar con un nivel adecuado de automatización.

[bungker]

No necesitaba Kubernetes, y ustedes probablemente tampoco.

Una vez que Kubernetes ya está implementado, parece que solo queda disfrutar la vida... llorando

[riki3]

Kubernetes es mi sustento y hubo una época en la que creía que esta era la respuesta correcta,
pero con el paso del tiempo me he encontrado experimentando muchos problemas y desperdiciando tiempo.

Se lo recomiendo a otros, pero creo que no lo usaría en mi propio servicio. Más que k8s, ya me cansé de los contenedores en general.

[joon14]

Si usas AWS, ¿podría pensarse que es parecido a ECS?

[tujuc]

Sí, justo eso. :)

[eclipsense]

No poder usar Kubernetes es el problema; de ahí a decir que Kubernetes no sirve, me parece un poco excesivo.

[tujuc]

Yo también pienso de forma parecida al autor.
Nuestra empresa todavía no tiene un tamaño como para usar kube, además.

Yo creía que todos los desarrolladores podrían administrar todo usando Kube.
Al final, me resultó mejor dar guías para que puedan construir la infraestructura y resolver problemas aunque estén por debajo del promedio de los desarrolladores de la empresa...

[doolayer]

???: Yo no necesitaba IA, y ustedes probablemente tampoco la necesitarán.

[ilbanin00]

Con cualquier producto, siempre habrá aspectos que implican concesiones.

[bbulbum]

Como he usado servicios administrados, la verdad es que no he sentido mayores dificultades con la gestión,,
Creo que cualquier herramienta es útil si se usa dentro de un límite razonable, pero me da la impresión de que con Kubernetes en particular se le critica sobre todo por “permitir configuraciones complejas”.

[tujuc]

Como es una tecnología con la que puedes hacer casi cualquier cosa tal como quieres... :) creo que por eso mucha gente termina usándola de forma compleja jajajaja...

[GN⁺]

Opiniones en Hacker News

• Expresa frustración con la "tecnología en la nube" y menciona que al usar Kubernetes se termina gastando mucho tiempo editando archivos YAML y resolviendo errores. Opina que preferiría evitar la integración con la nube y configurar los servidores directamente.

• Kubernetes implica costos considerables de infraestructura, además del tiempo de DevOps y administración. Sugiere que usar el Kubernetes administrado de un proveedor de nube es más eficiente.

• Explica que Kubernetes no es una herramienta de orquestación de contenedores, sino una herramienta para crear clústeres de computadoras; si no necesitas un clúster, no necesitas usar Kubernetes.

• Señala que la inversión excesiva en DevOps está disminuyendo y comparte una visión crítica de Kubernetes. Destaca que para una startup pequeña, un solo servidor puede ser suficiente.

• Menciona como puntos de atención al usar Cloud Run las limitaciones de conexiones TCP, la elección del entorno de ejecución y la configuración del autoescalado.

• Indica que Cloud Run es adecuado para startups pequeñas, pero carece de controles de firewall, un elemento básico de la arquitectura de seguridad. Explica que al final terminarás necesitando una VPC.

• Sostiene que comparar Google Cloud Run con Kubernetes no es justo, y explica las ventajas y desventajas de cada uno. Enfatiza que Kubernetes es adecuado para tareas complejas.

• Explica que Kubernetes tiene una curva de aprendizaje pronunciada, pero que es una herramienta poderosa si se usa correctamente.

• No está de acuerdo con las críticas hacia Kubernetes y enfatiza que al desplegar aplicaciones complejas puede ser necesaria la API de Kubernetes.

• Explica que la complejidad de Kubernetes surge principalmente de las tareas de administración de sistemas, y que Kubernetes en sí es estable.

• Señala que IaC y CM deberían reducir la configuración y facilitar la administración, pero en la práctica requieren más esfuerzo. Enfatiza que en muchos casos no se necesita Kubernetes y que es más importante contar con un buen administrador de sistemas.