La respuesta corta

Para la mayoría de desarrolladores indie, fundadores solos y equipos pequeños que sostienen unas pocas aplicaciones en producción, Kubernetes gestionado suele ser la mejor opción por defecto. El autogestionado solo merece la pena cuando hay una razón concreta: requisitos estrictos de residencia de datos, personalización profunda o un ingeniero de plataforma dedicado que realmente quiera asumir ese trabajo.

El motivo no es que Kubernetes sea un mal software. Es cuánta semana desaparece en mantener el clúster vivo en lugar de enviar funcionalidades.

Por qué esta decisión pesa más de lo que parece

Kubernetes es el orquestador de contenedores por defecto por una buena razón: aporta despliegues consistentes, escalado y rollouts entre entornos. La trampa es que el orquestador en sí es una pieza de infraestructura compleja, con su propio ritmo de actualizaciones, modelo de seguridad y necesidades de observabilidad.

Cuando lo gestionas tú, no estás solo ejecutando tu aplicación: también estás ejecutando:

  • Actualizaciones de versión, aproximadamente cada pocos meses, con una ventana de soporte para cada release.
  • Parches y hardening del plano de control (RBAC, network policies, pod security standards, manejo de secretos).
  • Un stack de observabilidad —métricas, logs, trazas— si quieres saber qué ocurre antes de que te lo digan los usuarios.
  • Plomería de red: plugins CNI, ingress controllers, service meshes, DNS interno.
  • Backup y recuperación ante desastres, porque Kubernetes no incluye copias nativas de las cargas de trabajo.

Nada de esto es imposible. Solo es trabajo continuo, y no se detiene cuando el clúster está “montado”.

Qué significa realmente “Kubernetes gestionado”

Un servicio de Kubernetes gestionado (EKS, GKE, AKS y ofertas similares) ejecuta por ti el plano de control: API server, scheduler, etcd y controller manager. Normalmente sigues gestionando los nodos worker, tus cargas de trabajo y la configuración a nivel de aplicación, pero el proveedor se encarga del aprovisionamiento del clúster, las actualizaciones del plano de control y la alta disponibilidad del mismo.

Lo que normalmente sigues asumiendo:

  • Pools de nodos y parcheo del SO de los nodos (salvo que el proveedor también lo abstraiga)
  • Despliegues y rollouts de la aplicación
  • Políticas de seguridad del clúster y decisiones de IAM/RBAC
  • Ingress, DNS, TLS y observabilidad de tus cargas

Lo que delegas:

  • Aprovisionamiento y uptime del plano de control
  • Actualizaciones de versión de Kubernetes del plano de control
  • Backups de etcd a nivel del plano de control
  • La pregunta de “si el API server está levantado a las 3 de la mañana”

Qué significa realmente “Kubernetes autogestionado”

Autogestionado significa que instalas y operas cada componente de Kubernetes tú mismo —plano de control y nodos worker— sobre servidores bare-metal, VMs en la nube o una mezcla. Tú eliges la distribución (upstream, kops, kubeadm o una opción empaquetada por un proveedor), el CNI, el ingress controller, la capa de almacenamiento y el stack de observabilidad.

También te quedas con todo el ciclo de actualizaciones, parches de seguridad, estrategia de backups y planificación de capacidad dentro de casa.

Los trade-offs, vistos desde la trinchera del fundador

Atención operativa

Este es el más importante. Múltiples reportes de practitioners en este terreno señalan que una proporción significativa de equipos que corren Kubernetes autogestionado se topa con problemas de estabilidad, seguridad u operación en los primeros 18 meses —no porque la tecnología esté mal, sino porque operar en producción exige habilidades especializadas que van mucho más allá de la instalación inicial.

Como fundador, la pregunta práctica es: ¿cuántas horas a la semana quieres dedicar al clúster en lugar del producto? Si la respuesta es “casi cero”, gana el gestionado.

Complejidad de escalado

Kubernetes es excelente escalando cargas de trabajo una vez montado. Lo que es menos obvio es que las decisiones de escalado —cuántos nodos, cuándo hacer autoscale, cómo absorber picos, cómo planificar capacidad— son trabajo analítico continuo. Los servicios gestionados suelen exponer primitivas de escalado más simples (node pools, autoscalers, opciones serverless) que ocultan parte de esto.

Previsibilidad de costes

El autogestionado parece más barato a primera vista: solo el cómputo subyacente. El coste real es el tiempo de ingeniería. Estimaciones de practitioners suelen caer en el rango de aproximadamente medio ingeniero a tiempo completo dedicado a operaciones para un único clúster de producción no trivial —más si es crítico para el negocio. Para un equipo pequeño, eso es una rebanada importante de la nómina yendo a infraestructura en lugar del roadmap.

Kubernetes gestionado mueve parte de ese coste a una línea predecible en tu factura de la nube, más la prima del servicio gestionado. El trueque es tiempo de ingeniero variable por una cuota fija.

Portabilidad y lock-in

Un argumento habitual a favor del autogestionado es “sin lock-in de proveedor”. La realidad es más matizada. Los servicios de Kubernetes gestionado suelen correr Kubernetes upstream-compatible, así que tus cargas de trabajo y manifiestos son portables. Lo que sí se pega es la cola alrededor: roles IAM, balanceadores, storage classes, anotaciones de ingress, integraciones de secretos y herramientas de observabilidad.

Si la portabilidad te importa de verdad, céntrate en las partes que realmente te atan (IAM, red, almacenamiento) más que en el plano de control.

Personalización y control

El autogestionado te da acceso total a etcd, a cada admission controller, a cada opción de CNI y a cada versión de Kubernetes. Los servicios gestionados te limitan a versiones soportadas y a valores por defecto preconfigurados. Si tu negocio necesita realmente una versión no soportada, un CNI a medida o políticas de admisión inusuales, es una razón real para autogestionar —y suele ser rara en equipos pequeños.

Cuándo el Kubernetes autogestionado merece lo que cuesta

Autogestionar vale la pena cuando se cumple al menos una de estas:

  • Requisitos estrictos de regulación o residencia de datos que excluyen planos de control en nubes públicas.
  • Ya tienes un ingeniero de plataforma en el equipo que trata las operaciones de Kubernetes como un producto que quiere poseer.
  • Necesitas personalización inusual: versiones específicas de Kubernetes, plugins CNI/CSI a medida o integración profunda con hardware on-prem que los servicios gestionados no pueden acomodar.
  • Optimizas coste de cómputo a escala y tienes la madurez operativa para acompañarlo —normalmente ya pasada la etapa de equipo pequeño.

Si nada de eso aplica, Kubernetes autogestionado es en gran parte pagar un impuesto operativo por adelantado a cambio de flexibilidad que tal vez nunca uses.

Cuándo el Kubernetes gestionado es la decisión correcta

El gestionado es la opción correcta cuando:

  • Tu equipo es pequeño (o eres tú solo) y tu atención es el recurso escaso.
  • Manejas cargas en producción pero Kubernetes en sí no es el producto.
  • Quieres delegar actualizaciones de versión y parches del plano de control.
  • Estás en una sola nube y no necesitas versiones exóticas de Kubernetes.
  • Prefieres previsibilidad de coste por encima del mínimo coste posible.

Si eso te describe, Kubernetes gestionado es la respuesta aburrida y correcta.

Y cuando ninguno de los dos es la opción correcta

Esta es la parte que la mayoría de artículos de “gestionado vs autogestionado” se saltan. Para muchas apps pequeñas en producción, Kubernetes en sí es excesivo.

Si tienes:

  • Uno o dos servicios
  • Tráfico predecible
  • Una base de datos pequeña, colas simples y jobs en background básicos
  • Ninguna necesidad de estrategias de despliegue complejas ni de autoscaling más allá de “agrandar la caja”

…entonces una plataforma más simple te ahorrará más tiempo que cualquier opción de Kubernetes. Considera:

  • Plataformas PaaS para apps (estilo Render, Fly, Railway, Heroku) que despliegan desde git, manejan TLS y escalan con un slider.
  • Hosts de contenedores con orquestación integrada (Fly apps, Railway services, Cloud Run, App Runner) que te dan despliegue basado en contenedores sin la abstracción del clúster.
  • Despliegues en una sola VM detrás de un balanceador, con una base de datos gestionada al lado, cuando el tráfico es genuinamente bajo.

El encuadre honesto: elige Kubernetes cuando la forma de tu carga de trabajo lo justifique. Si no lo hace, la mejor decisión sobre Kubernetes es la que no tomas.

Pasos prácticos a seguir

  1. Escribe qué necesita realmente tu app. Número de servicios, comportamiento de escalado, patrón de tráfico, restricciones de residencia de datos. Si no puedes rellenar esto honestamente, no estás listo para comparar plataformas de orquestación.
  2. Estima el coste operativo con honestidad. Multiplica el tiempo que un ingeniero competente dedicaría por semana al mantenimiento del clúster por su coste cargado. Compara esa cifra con la prima del servicio gestionado.
  3. Prueba primero la opción más simple. Despliega en un PaaS o en un host de contenedores durante un trimestre. Si lo superas, ese es el momento de mirar Kubernetes —y sabrás por qué lo necesitas.
  4. Si eliges Kubernetes gestionado, quédate en la nube que ya usas. EKS si estás en AWS, GKE si estás en GCP, AKS si estás en Azure. El beneficio marginal de integración suele ganarle a la portabilidad entre nubes.
  5. Si eliges autogestionado, trátalo como un producto. Responsable dedicado, runbooks documentados, procedimientos de upgrade y restore ensayados, y presupuesto para tooling de observabilidad. El autogestionado a medias es como ocurren los outages.

Preguntas frecuentes

¿Kubernetes gestionado es solo “Kubernetes con pasos extra”?

No. Es Kubernetes con el plano de control abstraído. Tus cargas, manifiestos y herramientas siguen siendo Kubernetes estándar. Lo que cambia es quién está de guardia por el API server.

¿Puedo cambiar después sin reescribir mi app?

Normalmente sí a nivel de carga de trabajo, porque los servicios gestionados corren Kubernetes upstream. Lo que quizá tengas que reescribir es la cola: anotaciones de ingress, roles IAM, storage classes y manejo de secretos. Presupuesta ese trabajo, no reescribir la aplicación.

¿Los servicios gestionados me atan a una nube?

La capa de Kubernetes, no. Las piezas específicas de la nube —IAM, red, almacenamiento, balanceadores— sí. Si evitar el lock-in de nube es prioridad, sopesa eso frente al ahorro operativo.

¿Qué tamaño necesita tener mi equipo para autogestionar con responsabilidad?

No hay número fijo, pero como regla aproximada: al menos un ingeniero cuyo trabajo principal sea operaciones de plataforma, con cobertura de backup, y disposición para tratar el clúster como un producto con on-call, runbooks y roadmap. Si ese no es tu equipo, autogestionar competirá silenciosamente con el trabajo de producto.

Fuentes