No me gusta Kubernetes, y no es por la tecnología
Kubernetes en AWS
Qué es Kubernetes y qué aporta Amazon EKS, cómo decidir entre Lambda, ECS con Fargate o EKS en AWS, y mi opinión como arquitecto sobre cuándo merece la pena asumir su complejidad.
3 artículos
No me gusta Kubernetes. Lo digo como arquitecto y no como crítica a la tecnología, que es potente y está bien diseñada: me disgusta lo que exige. Hace falta mucho conocimiento para entenderlo, hay que mantenerlo de forma continua y ese mantenimiento tiene un coste. Mi criterio al diseñar es otro: elegir la solución que cumpla todos los requisitos del cliente y sea la más fácil de mantener.
Este artículo es la tercera parte de una serie, la de opinión, y se entiende sin haber leído las anteriores. Los conceptos básicos de Kubernetes y Amazon EKS están en la Parte 1, y la comparativa entre Lambda, ECS con Fargate y EKS, con su árbol de decisión, en la Parte 2.
Lo que sigue es una opinión personal, basada en mi experiencia como arquitecto. No es una recomendación válida para todos los contextos: si el tuyo es distinto, es razonable que tu conclusión también lo sea.
Ilustración generada con IA para este artículo; resume la idea: usar la abstracción más simple que cumpla el requisito.
Mi criterio: requisitos cubiertos y mantenimiento mínimo
Mi criterio de diseño tiene dos partes: cumplir todos los requisitos del cliente y, entre las opciones que los cumplen, elegir la que resulte más fácil de mantener. En la práctica parto del servicio que deja menos infraestructura a mi cargo y solo subo de nivel cuando un requisito concreto lo exige.
Kubernetes casi nunca sale como punto de partida con ese criterio. No porque no cumpla requisitos, sino porque suele cumplirlos con más piezas, más decisiones y más trabajo recurrente que otras opciones. Los dos apartados siguientes detallan ese coste, y el tercero analiza el argumento que más se usa para justificarlo.
Lo que no me gusta: complejidad, conocimiento y mantenimiento
Mi experiencia con EKS en plataformas empresariales apunta en una dirección: ejecutar los contenedores de la aplicación era lo más sencillo. Lo difícil estaba alrededor. Kubernetes exige mucho conocimiento para entenderlo y, después, hay que mantenerlo: actualizaciones, add-ons, nodos, escalado, GitOps, aislamiento entre equipos y apagado de los entornos que nadie usa (el lado del coste lo cuento en FinOps en AWS).
Si el criterio es la solución más fácil de mantener que cumpla los requisitos, ese trabajo recurrente entra en la comparación igual que el precio o el rendimiento.
El calendario de versiones
Kubernetes publica una versión menor más o menos cada cuatro meses y EKS sigue ese ritmo. Según la documentación de versiones de EKS, cada versión tiene 14 meses de soporte estándar y después 12 meses de soporte extendido, que cuesta más. En la página de precios, la tarifa por clúster pasa de 0,10 a 0,60 dólares por hora.
Lo que más me importa es lo que ocurre al terminar el soporte extendido: EKS actualiza el control plane automáticamente, en un momento que tú no eliges. La fecha límite se conoce de antemano: figura en el calendario de versiones y, para el fin del soporte estándar, AWS avisa a través de AWS Health con al menos 60 días de antelación. Lo que no se avisa es el momento exacto de la actualización automática, que puede producirse en cualquier momento a partir de esa fecha. Los add-ons y los nodos siguen siendo responsabilidad tuya, así que conviene actualizar antes, a tu ritmo.
Cada actualización es un pequeño proyecto: comprobar que los add-ons, los controllers y los CRDs (las extensiones de la API de Kubernetes que se instalan en el clúster) soportan la nueva versión, actualizar nodos o AMIs, probar los despliegues y tener a alguien disponible por si algo falla.
Cuánto cuesta no actualizar
La diferencia de tarifa parece pequeña por hora, pero se acumula. Estas son las cifras por clúster, calculadas con 730 horas al mes y 8.760 horas al año:
| Soporte estándar (0,10 $/h) | Soporte extendido (0,60 $/h) | Diferencia | |
|---|---|---|---|
| Por mes | 73 $ | 438 $ | +365 $ |
| Por año | 876 $ | 5.256 $ | +4.380 $ |
| 3 entornos (dev, pre y prod), por año | 2.628 $ | 15.768 $ | +13.140 $ |
Es solo la tarifa del control plane de cada clúster. No incluye nodos, almacenamiento, tráfico ni ningún otro coste, y las tarifas son las publicadas en la página de precios de EKS en el momento de escribir este artículo.
El sobrecoste depende de la upgrade policy del clúster (propiedad supportType). Con EXTENDED, el valor por defecto, el clúster entra en soporte extendido y paga la tarifa mayor. Con STANDARD no hay cargo por soporte extendido, a cambio de que EKS actualice el clúster automáticamente al terminar el soporte estándar. Una vez en soporte extendido, no se puede volver a STANDARD hasta que el clúster esté en una versión con soporte estándar.
Aun así, la tarifa es lo de menos. El coste real es el tiempo de ingeniería de cada actualización (revisar compatibilidades, actualizar nodos y add-ons, probar y desplegar) y la guardia de quien la ejecuta y vigila el resultado. Para seguir en soporte estándar hay que subir de versión al menos una vez cada 14 meses, en cada clúster y en cada entorno, y ese trabajo conviene presupuestarlo desde el principio.
Con Amazon ECS sobre AWS Fargate ese trabajo no existe en esa forma: no hay un calendario de versiones de un orquestador que actualizar ni add-ons de clúster que mantener, y AWS gestiona el plano de control y la infraestructura donde se ejecutan las tareas. Sigue habiendo trabajo (imágenes, dependencias, configuración), pero no un ciclo de versiones del propio orquestador.
Qué gestiona AWS y qué sigue a tu cargo
EKS ha ido absorbiendo parte de ese trabajo, pero no todo. Esta tabla resume qué gestiona AWS y qué sigue siendo tuyo en cada modalidad (el detalle está en la Parte 1):
| Lo gestiona AWS | Sigue a tu cargo | |
|---|---|---|
| Amazon EKS estándar (AWS opera el control plane; los nodos los gestionas tú) | El control plane: API Server, Scheduler y etcd en alta disponibilidad, y sus parches | Los nodos y sus actualizaciones (managed node groups o Karpenter), los add-ons (VPC CNI, CoreDNS, kube-proxy, drivers CSI, AWS Load Balancer Controller), las actualizaciones de versión y los workloads |
| EKS Auto Mode (EKS en el que AWS gestiona también los nodos y los componentes básicos del clúster) | Compute y escalado de nodos, red de Pods, balanceadores, DNS, almacenamiento de bloques y actualizaciones de nodos, que se sustituyen como máximo a los 21 días | Los workloads, los add-ons y controllers propios, los Pod Disruption Budgets y los NodePools personalizados |
| EKS Capabilities (herramientas de plataforma que AWS ejecuta por ti, fuera de tus nodos) | Argo CD (GitOps), ACK (recursos de AWS desde Kubernetes) y kro (composición de recursos), con coste por hora | Los repositorios, las definiciones de aplicaciones y las políticas |
Dos términos de la tabla, en una frase cada uno:
- Pod Disruption Budget (PDB): limita cuántos Pods de una aplicación pueden estar parados a la vez. Si es demasiado estricto, bloquea la sustitución de nodos y las actualizaciones.
- NodePool: define qué tipo de nodos puede crear Auto Mode (por ejemplo, instancias concretas o Spot). Los de por defecto no se tocan, y los personalizados los mantienes tú.
Sigue siendo tuyo lo que no aparece en la tabla: la observabilidad, la seguridad y el RBAC (el control de acceso de Kubernetes), quién está de guardia y el conocimiento que necesita el equipo para diagnosticar un problema cuando aparece. Auto Mode y Capabilities reducen mucho el trabajo, pero Kubernetes sigue ahí: si el equipo no necesitaba Kubernetes, lo ha añadido igualmente.
Portable no significa Kubernetes
La portabilidad suele aparecer en la lista de requisitos por defecto de toda arquitectura nueva: escalable, segura, con alta disponibilidad y portable. Casi siempre con el mismo argumento: por si algún día hay que cambiar de proveedor. Y casi siempre se traduce de forma automática en Kubernetes, sin concretar qué riesgo cubre, con qué probabilidad ni en qué plazo.
Necesitamos que sea portable.
Esa cobertura preventiva tiene un coste cierto y continuo: complejidad de la plataforma, mantenimiento permanente y conocimiento que el equipo debe adquirir y conservar. A cambio ofrece un beneficio hipotético que, en los proyectos que he visto, rara vez ha llegado a materializarse. No digo que el requisito sea ilegítimo, sino que hay que tratarlo como cualquier otro: concretarlo y costearlo antes de aceptarlo.
Mis argumentos son tres:
- Los nuevos desarrollos en cuentas aisladas y con pocos microservicios no justifican EKS por portabilidad. No hay plataforma que aprovechar y todo el coste de montarla y mantenerla recae en el proyecto.
- Lo portable son las aplicaciones, no la plataforma. Con imágenes estándar corren igual en Amazon ECS, en EKS o en un servidor propio, y la plataforma hay que rehacerla al cambiar de proveedor, también con Kubernetes. Lo que no viaja con el clúster se detalla en la Parte 2.
- Un desarrollo cloud-native ya está acoplado al cloud elegido. El acoplamiento está en la identidad (AWS IAM), las colas (Amazon SQS), las bases de datos (Amazon DynamoDB, Amazon RDS), los servicios gestionados en general y la infraestructura como código, y Kubernetes no lo elimina.
La portabilidad que se aprovecha de verdad está en capas que no exigen Kubernetes:
- infraestructura como código, para poder recrear el entorno;
- contratos de API claros, para que los consumidores no dependan del proveedor;
- datos exportables en formatos abiertos;
- lógica de negocio separada de la integración con el proveedor, para que cambiar una cola o una base de datos toque una capa y no todo el código.
Cuándo sí elijo Kubernetes
Hay contextos en los que Kubernetes es la decisión correcta. Son los casos que justifican la plataforma, y los requisitos concretos están desarrollados en la Parte 2:
- Clientes grandes con un clúster ya en marcha y muchas aplicaciones. La plataforma, el equipo y los procesos ya existen, así que un workload más apenas cambia el coste.
- Un requisito regulatorio. Una normativa que obliga a poder operar fuera de un proveedor concreto.
- Multicloud que se va a ejecutar. Una estrategia real, no una posibilidad futura.
- Cargas on-premises. AWS ofrece EKS Hybrid Nodes y EKS Anywhere para este caso. No he usado ninguno de los dos en un proyecto real, y me interesa mucho la experiencia de quien lo haya hecho.
Antes de aceptar un requisito de portabilidad, me hago estas preguntas:
- ¿Qué riesgo concreto cubre (regulatorio, contractual, estratégico) y quién lo ha formulado?
- ¿Qué probabilidad y qué plazo tiene? ¿Hay una decisión o una fecha, o es una precaución genérica?
- ¿Qué costaría migrar lo que Kubernetes no cubre (identidad, datos, servicios gestionados, infraestructura como código)?
- ¿Existe ya una plataforma Kubernetes con un equipo que mantenga actualizaciones, add-ons y nodos, o la crearía este proyecto?
Si, tras responderlas, el requisito sigue teniendo un riesgo y un plazo concretos, EKS es una respuesta razonable. Si no, es una preferencia, y las preferencias no suelen justificar una plataforma entera: el cliente obtiene lo que necesita con una plataforma más sencilla de operar.
Conclusión
Kubernetes no llega solo. Con él vienen la complejidad de una plataforma completa, el conocimiento que exige al equipo, un mantenimiento continuo y el coste de todo lo anterior, que se paga cada mes aunque nadie lo vea en el diagrama de arquitectura. Por eso no lo descarto como opción, pero tampoco lo asumo de partida: lo elijo cuando un requisito concreto lo justifica, y en el resto de casos busco la solución que cubra lo mismo con menos que mantener.
Antes de añadir Kubernetes a una arquitectura, pregunto qué requisito lo necesita y quién va a mantenerlo dentro de dos años.
Referencias
En este blog
- Kubernetes y EKS: muy potente, muy complejo y no siempre necesario (Parte 1)
- ¿De verdad necesitas Kubernetes? Lambda vs ECS vs EKS en AWS (Parte 2)
- FinOps en AWS