Kubernetes Cloud: servicios en la nube para Kubernetes, mini guía práctica

Amazon EKS, Google GKE y Azure AKS siguen siendo las plataformas Kubernetes gestionadas dominantes – pero en 2026 lucen muy diferentes respecto a hace apenas unos años.

Los tres principales servicios Kubernetes gestionados – Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE) y Azure Kubernetes Service (AKS) – siguen representando la gran mayoría de las cargas de trabajo Kubernetes en producción a nivel mundial. Si gestionas infraestructura para clientes o ejecutas aplicaciones contenedorizadas a escala, es muy probable que ya estés utilizando al menos uno de ellos.

Los tres cubren los aspectos fundamentales: el proveedor de nube se encarga del control plane (clustering de etcd, alta disponibilidad del servidor API, parcheo de los nodos master) para que puedas centrarte en desplegar cargas de trabajo. Pero la definición de «gestionado» se ha ampliado significativamente. Hoy, cada proveedor ofrece también un modo automatizado y con opiniones predefinidas que gestiona el plano de datos (nodos worker) – reduciendo o incluso eliminando la necesidad de configurar, parchear y escalar nodos manualmente. Comprender estas diferencias es esencial para tomar la decisión correcta de plataforma.

Veamos más de cerca cada servicio y qué ha cambiado.

Amazon Elastic Kubernetes Service (EKS)

Amazon EKS está disponible de forma general desde 2018 y ha madurado hasta convertirse en una plataforma potente y flexible, profundamente integrada con el ecosistema AWS. EKS permite ejecutar aplicaciones Kubernetes en las regiones cloud de AWS en todo el mundo u on-premises mediante EKS Anywhere.

La adición reciente más significativa es EKS Auto Mode, la respuesta de AWS al Kubernetes completamente gestionado. Auto Mode automatiza el aprovisionamiento, el parcheo y el escalado del plano de datos utilizando Karpenter y Bottlerocket internamente. En lugar de gestionar los tradicionales grupos de nodos, AWS aprovisiona nodos correctamente dimensionados bajo demanda en función de los requisitos de tus pods, gestiona el bin-packing y reemplaza los nodos automáticamente. Logra un equilibrio entre la automatización y la flexibilidad que los equipos nativos de AWS esperan.

EKS también introdujo las Pod Identities, un mecanismo simplificado para conceder a los pods acceso seguro a los servicios de AWS – reemplazando en la mayoría de los escenarios la configuración más antigua y compleja de IRSA (IAM Roles for Service Accounts).

Un detalle que los MSPs deben tener en cuenta: AWS ofrece Extended Support para versiones de Kubernetes más antiguas, pero el coste sube de $0,10 a $0,60 por hora por clúster (un aumento de 6 veces). Para los equipos que gestionan múltiples clústeres y que podrían no actualizar a tiempo, este coste puede acumularse rápidamente. Permanecer en una versión soportada no es solo una buena práctica – es una decisión de control de costes.

EKS sigue siendo ideal para organizaciones ya invertidas en el ecosistema AWS y para equipos de plataforma que desean un control granular sobre la infraestructura. El trade-off es una superficie operativa más compleja en comparación con GKE Autopilot o AKS Automatic, particularmente en lo relativo al networking VPC CNI y la configuración de IAM.

Google Kubernetes Engine (GKE)

Google Kubernetes Engine se beneficia de la posición única de Google como creador del propio Kubernetes. GKE sigue las versiones upstream de Kubernetes más rápido que sus competidores – normalmente en dos semanas a través de su canal de lanzamiento Rapid – y sigue siendo una de las plataformas Kubernetes gestionadas más avanzadas disponibles.

El principal diferenciador de GKE es Autopilot, un modo operativo completamente gestionado y «sin nodos». Con Autopilot, defines tus pods y Google se encarga de todo lo demás: aprovisionamiento de nodos, bin-packing, parcheo del sistema operativo, actualizaciones y escalado. Pagas por la CPU, memoria y almacenamiento efímero que tus pods realmente solicitan, no por la capacidad inactiva de los nodos. Este modelo elimina el sobreaprovisionamiento a nivel de nodo y es particularmente rentable para cargas de trabajo variables o con picos.

Autopilot ha madurado considerablemente y ahora soporta GPUs NVIDIA A100/H100 y TPUs de Google, haciéndolo viable también para cargas de trabajo de inferencia y entrenamiento AI/ML. GKE también utiliza Dataplane V2, basado en eBPF, que gestiona el enrutamiento de paquetes y la aplicación de políticas de red directamente en el kernel – evitando completamente iptables para una mejor escalabilidad en clústeres de gran tamaño.

GKE ofrece Release Channels estructurados (Rapid, Regular, Stable) con actualizaciones automatizadas. Los clústeres inscritos en el canal Extended pueden permanecer en una versión menor de Kubernetes más antigua durante aproximadamente 30 meses, pero durante el período de soporte extendido se aplica un coste adicional de gestión del clúster de $0,50 por clúster por hora. Este coste se exime para los clústeres que utilizan GKE Enterprise edition, que incluye el soporte extendido en su pricing por vCPU.

El trade-off con Autopilot es una flexibilidad reducida: restringe los contenedores privilegiados, ciertas configuraciones de DaemonSet y las herramientas personalizadas basadas en eBPF. Si tu stack requiere acceso a nivel de kernel o capabilities de Linux elevadas, GKE Standard (el modo tradicional con nodos autogestionados) es la opción apropiada.

Azure Kubernetes Service (AKS)

Microsoft AKS ha crecido hasta convertirse en una plataforma completamente madura con una ventaja significativa para los equipos que cuidan el presupuesto: el control plane base de AKS es gratuito. Solo se paga por los nodos worker y los recursos asociados, lo que marca una diferencia significativa para las organizaciones que gestionan muchos clústeres (un escenario común para los MSPs).

El desarrollo reciente más notable es AKS Automatic, que alcanzó la disponibilidad general en septiembre de 2025. AKS Automatic es la visión de Microsoft de una experiencia Kubernetes completamente gestionada: aplica configuraciones predeterminadas con opiniones para seguridad, escalado y networking de serie, reduciendo drásticamente la barrera operativa. Al igual que GKE Autopilot y EKS Auto Mode, automatiza la gestión de nodos, pero preserva mayor flexibilidad a nivel de Kubernetes que las restricciones más estrictas de Autopilot. AKS Automatic utiliza un SKU dedicado con un coste del control plane de $0,16 por hora por clúster – más alto que el tier Standard de $0,10/hora, pero competitivo dado el nivel de automatización incluido.

AKS se organiza en tres niveles: Free (control plane gestionado, sin SLA), Standard ($0,10/hora por clúster, SLA de uptime del 99,95% para clústeres con redundancia de zona) y Premium (añade Long-Term Support con hasta 24 meses en versiones de Kubernetes seleccionadas y gestión avanzada de flotas). La opción LTS del tier Premium es particularmente relevante para entornos enterprise y MSPs que necesitan ventanas de actualización más amplias.

AKS se integra estrechamente con el ecosistema Microsoft mediante Workload Identity con Entra ID para la autenticación segura y sin secrets de los pods a los recursos de Azure, Azure Policy for AKS para la aplicación de la gobernanza, e integración nativa con Azure DevOps y GitHub Actions para pipelines CI/CD.

AKS es la opción natural para las organizaciones que ejecutan cargas de trabajo basadas en Windows junto a contenedores Linux, y para equipos que ya operan dentro del ecosistema Azure y Microsoft 365.

Comparativa rápida

EKSGKEAKS
Coste del control plane$0,10/hora ($73/mes)$0,10/hora (Standard y Autopilot)Gratuito (base), $0,10/hora (Standard), $0,16/hora (Automatic), $0,60/hora (Premium)
Modo completamente gestionadoEKS Auto ModeGKE AutopilotAKS Automatic
Adopción de nuevas versiones K8s4-8 semanas después del upstream1-2 semanas (canal Rapid)3-6 semanas
Soporte extendido+12 meses ($0,60/hora total, vs $0,10/hora estándar)Hasta 30 meses ($0,50/hora extra; gratuito con Enterprise edition)Hasta 24 meses (tier Premium)
Opción serverless/sin nodosFargate (por pod), Auto ModeAutopilot (completamente sin nodos)AKS Automatic
Más adecuado paraEquipos nativos de AWS, máxima flexibilidadActualizaciones más rápidas, cargas AI/MLConciencia de costes, ecosistema Microsoft

El auge del Kubernetes «No-Ops»

La tendencia más importante en el Kubernetes gestionado en los últimos dos años es el cambio hacia lo que muchos llaman modos «No-Ops». GKE Autopilot fue pionero en este enfoque, y tanto EKS Auto Mode como AKS Automatic han seguido. La premisa es la misma: el proveedor gestiona todo el ciclo de vida de la infraestructura para que los equipos de plataforma puedan concentrarse exclusivamente en las cargas de trabajo.

Para MSPs y sysadmins que gestionan Kubernetes para múltiples clientes, estos modos actúan como un multiplicador de fuerza. En lugar de parchear nodos, ajustar AMIs y gestionar configuraciones del autoscaler para cada clúster, defines las especificaciones de los pods y dejas que el proveedor gestione el resto. El trade-off es menor personalización a nivel de nodo, pero para la mayoría de las cargas de trabajo estándar es un compromiso que merece la pena aceptar.

Vale la pena señalar que «No-Ops» no significa «sin responsabilidad». Sigues siendo responsable del dimensionamiento de las resource requests, la seguridad a nivel de aplicación, las políticas de red y la planificación de las actualizaciones. La automatización redistribuye la carga operativa; no la elimina.

Read related articles

Stefano Corbetti in Contenerización 25 de agosto de 2026

Cómo funciona Repository Docker

¿No tienes claro cuál es la diferencia entre un repositorio Docker y un registro Docker? Esta guía explica cómo funcionan ambos, cómo etiquetar y hacer push de las imágenes, y cómo autenticarse de forma segura en Docker Hub y otros registros.