Uso Kubernetes desde 2019. En 2024 di una charla en Cloud Native Santiago, la comunidad de la CNCF en Chile, sobre cómo implementar políticas de seguridad y cumplimiento en Kubernetes con Kyverno. Me gusta su modelo declarativo, su ecosistema y la idea de que todo el estado deseado del sistema vive en un manifiesto.
Y aun así, cuando un equipo pequeño me pregunta dónde desplegar sus contenedores, muchas veces mi respuesta no es Kubernetes.
Este post no es un ataque a Kubernetes. Es lo contrario: es lo que aprendí justamente porque lo conozco de cerca.
Kubernetes no es solo desplegar, es operar
La demo de Kubernetes dura diez minutos: un kubectl apply y tu aplicación está corriendo. Lo que la demo no muestra es el día 2.
Un cluster de Kubernetes es un sistema que tienes que operar. Hay que actualizar la versión, y Kubernetes saca versiones nuevas varias veces al año. Hay que ajustar los requests y limits de cada carga. Hay que gestionar el ingress, los certificados, los add-ons, las políticas de red y de seguridad. Cada pieza funciona, pero cada pieza es algo más que alguien tiene que entender a las dos de la mañana.
En un equipo con una persona de plataforma dedicada, ese trabajo tiene dueño. En un equipo de tres desarrolladores que también atienden el producto, ese trabajo compite con todo lo demás. Y casi siempre pierde.
Los datos sobre operar Kubernetes
No encontré ninguna métrica que diga "con menos de N personas, no uses Kubernetes". Esa línea no la mide nadie, y desconfío de quien te la dé con decimales. Lo que sí hay son datos que muestran lo difícil que es operarlo bien:
- Más del 65% de las cargas en Kubernetes usan menos de la mitad del CPU y la memoria que solicitan, según el Container Report de Datadog de 2023. Ajustar los recursos es difícil, y el costo de no hacerlo se paga cada mes.
- Solo el 40% de las organizaciones con Kubernetes corre una versión de un año o menos, según el mismo reporte. El resto va atrasado.
- En Amazon EKS, ir atrasado tiene precio. Un cluster con soporte estándar cuesta $0.10 por hora. Cuando su versión sale del soporte estándar, pasa a soporte extendido y cuesta $0.60 por hora: seis veces más, solo por no haber actualizado.
- El 46% de las organizaciones que empiezan con cloud native dice que la falta de capacitación es su mayor desafío, según la encuesta anual de la CNCF de 2023.
- Mientras tanto, el 46% de las organizaciones que usan contenedores ya corre contenedores serverless, contra un 31% dos años antes, según Datadog. El mercado se está moviendo hacia operar menos.
Ninguno de estos datos dice "no uses Kubernetes". Dicen algo más útil: operar Kubernetes bien requiere habilidades y tiempo, y cuando faltan, se paga en recursos desperdiciados y versiones atrasadas.
Antes de Kubernetes: la opción más simple que funciona
Mi regla es elegir la solución más simple que resuelve el problema a un costo aceptable. Kubernetes casi nunca es la más simple. Así es como lo pienso, de lo más simple a lo más complejo.
Un cron con un script. Si la tarea es correr algo cada hora, cada noche o cada lunes, quizás no necesitas ni un contenedor. Un script programado con Amazon EventBridge Scheduler y una función Lambda resuelve muchos casos que he visto montados sobre un cluster completo.
AWS Lambda. Para cargas por eventos, tráfico irregular o tareas cortas. No operas servidores y pagas por ejecución. El límite es claro: una función puede correr como máximo 900 segundos, es decir, 15 minutos. Si tu tarea necesita más, Lambda no es la herramienta.
Amazon ECS con Fargate. Para servicios que corren todo el tiempo, como una API o un worker. Es contenedores sin cluster que operar: no actualizas nodos ni versiones de un plano de control. Para un equipo pequeño que vive en AWS, es mi primera opción para contenedores la mayoría de las veces.
Kubernetes. Cuando el problema de verdad lo pide.
Cuándo sí uso Kubernetes
Kubernetes paga su costo cuando se cumplen varias de estas condiciones:
- Hay un equipo, o al menos una persona, que se hace cargo de la plataforma.
- Hay muchos servicios y varios equipos que despliegan sobre la misma base, y conviene un estándar común.
- Necesitas el ecosistema: operadores, GitOps, o políticas como código con herramientas como Kyverno. Gobernar decenas de servicios con políticas declarativas es donde Kubernetes brilla.
- Necesitas portabilidad real entre nubes o con tu propio datacenter, no como deseo sino como requisito.
- Corres cargas que el ecosistema de Kubernetes resuelve mejor, como nodos con GPU gestionados con el NVIDIA GPU Operator.
Si no se cumple ninguna, Kubernetes probablemente es una solución buscando un problema.
La herramienta no es la identidad
Me gusta Kubernetes, y sigo aprendiendo sobre él, sobre todo en infraestructura para cargas de IA con GPU. Pero me pagan por resolver problemas, no por usar las herramientas que me gustan.
El criterio no es "Kubernetes sí" o "Kubernetes no". El criterio es cuánto cuesta operar cada opción, quién la va a operar, y qué pasa cuando falla. A veces la respuesta es un cluster de Kubernetes. Muchas veces es un servicio en ECS. Y algunas veces es un cron con un script.
No quiero elegir Kubernetes porque me guste. Quiero elegirlo cuando el problema lo justifique.
¿Y tú? ¿Has visto un cluster de Kubernetes que no debió existir, o un equipo que se quedó corto por no adoptarlo a tiempo?