Si ya sabes construir una imagen con Docker y ejecutar un contenedor, tienes la mitad del camino hecho: sabes empaquetar software. Lo que Kubernetes resuelve es la otra mitad, la que aparece cuando ese contenedor deja de estar solo en tu portátil y pasa a ser uno de los cuarenta que deben estar vivos, accesibles y actualizados a las tres de la madrugada de un viernes de puente. Esta lección explica exactamente qué problema resuelve la orquestación de contenedores, de dónde viene Kubernetes, qué aporta frente a las alternativas y —muy importante— cuándo no conviene usarlo. Es la lección que da sentido a todas las demás: sin entender el problema, las soluciones de los próximos once módulos parecen complicaciones gratuitas.

1. Del contenedor suelto a la flota
2. El salto desde Docker y Docker Compose
3. Breve historia: de Borg a la CNCF
4. Qué aporta Kubernetes exactamente
5. Kubernetes frente a las alternativas
6. Cuándo NO conviene usar Kubernetes
7. El escenario del curso: Rutas Norte S.L.

Un contenedor resuelve un problema muy concreto: empaquetar una aplicación con sus dependencias para que se ejecute igual en cualquier máquina con un runtime de contenedores. Eso es enorme, pero es solo el envase.

En cuanto pasas a producción aparecen preguntas que el contenedor, por sí mismo, no responde:

• Ubicación: tengo 5 servidores y 40 contenedores. ¿Cuál va dónde? ¿Y cuando añada el sexto servidor?
• Supervivencia: el proceso ha muerto a las 03:14. ¿Quién lo vuelve a levantar? ¿Y si la máquina entera se ha apagado?
• Escalado: hoy necesito 3 réplicas de la API y el viernes de Semana Santa necesitaré 20. ¿Quién las arranca y quién las apaga después?
• Descubrimiento: la API se ha reiniciado y ahora tiene otra IP. ¿Cómo se entera el frontend?
• Reparto de carga: si hay 20 réplicas, ¿quién decide a cuál va cada petición?
• Despliegue sin corte: quiero publicar la versión 2.4.0 sin que ningún cliente vea un error 502.
• Configuración y secretos: la contraseña de la base de datos no puede estar en la imagen ni en el git log.
• Recursos: un contenedor que se vuelve loco no puede tumbar a los otros nueve de la misma máquina.

Cada una de esas preguntas, resuelta a mano, se convierte en un script. La suma de esos scripts, mantenida por una persona que se va de vacaciones, es la razón por la que existe la orquestación de contenedores.

Un orquestador es, en una frase: un sistema al que le describes el estado que quieres y que se encarga permanentemente de que la realidad se parezca a esa descripción. Tú dices "quiero 5 réplicas de la API en la versión 2.4.0, accesibles en api.rutasnorte.example"; el orquestador se encarga de decidir dónde caben, arrancarlas, vigilarlas, sustituir las que mueran y enrutar el tráfico.

Este es el concepto que más cuesta al principio y el que más rendimiento da después.

Docker es fundamentalmente imperativo (docker run). Kubernetes es fundamentalmente declarativo: escribes un fichero que describe lo que quieres, lo entregas al clúster, y a partir de ahí el clúster trabaja para ti de forma permanente. Si alguien borra un contenedor, vuelve. Si un servidor se cae, sus cargas reaparecen en otro. A este mecanismo se le llama bucle de reconciliación y lo estudiaremos a fondo en la lección Arquitectura de Kubernetes.

Conviene aclarar una confusión muy habitual: Kubernetes no sustituye a Docker, sustituye a lo que hacías alrededor de Docker.

• Docker (o cualquier herramienta compatible con OCI) sigue siendo lo que usas para construir imágenes.
• El registro de imágenes sigue existiendo.
• Lo que cambia es quién ejecuta y gobierna esos contenedores.

Docker Compose es el paso intermedio natural. Con un docker-compose.yml describes varios servicios, sus redes y volúmenes, y con un comando levantas todo el stack. Es declarativo... dentro de una sola máquina. Ahí está su techo:

Lo que este fichero no puede hacer:

1. Repartir esos servicios entre 5 máquinas.
2. Volver a arrancar el stack en otro servidor si el actual se apaga.
3. Escalar api-reservas a 20 réplicas repartidas y balanceadas.
4. Sustituir la imagen 2.3.1 por la 2.4.0 de forma progresiva y con vuelta atrás automática si falla.
5. Aislar entornos (dev, pre, pro) con permisos y cuotas distintos.

Kubernetes hace exactamente esas cinco cosas, y ese es el salto. El precio es una curva de aprendizaje y una capa de conceptos nuevos, que es justamente lo que este curso te va a dar.

Kubernetes no nació como un experimento. Es la tercera generación de una idea probada durante más de una década.

El dato relevante para ti como profesional: al estar bajo la CNCF con gobernanza neutral, Kubernetes es la única capa de orquestación que se ejecuta prácticamente igual en tu portátil, en un centro de datos propio y en AWS, Azure o Google Cloud. Esa portabilidad es un argumento de negocio, no solo técnico.

Vamos a concretar las capacidades, porque "orquestar" es demasiado vago.

Describes el resultado en un fichero YAML y el clúster lo mantiene. No ejecutas pasos: publicas intenciones. Todo lo demás de esta lista se deriva de aquí.

• Si un contenedor termina con error, se reinicia.
• Si un contenedor está vivo pero no responde (lo detectan las sondas, módulo 7), se reinicia.
• Si un nodo entero deja de responder, sus cargas se recrean en otros nodos.
• Si alguien borra una réplica a mano, vuelve a aparecer.

Puedes pasar de 3 a 20 réplicas con un comando, o dejar que el clúster lo haga solo según CPU, memoria o métricas de negocio (módulo 9). Para Rutas Norte, cuyos picos de tráfico se concentran en puentes y vacaciones, esto es directamente dinero: no se paga capacidad ociosa en febrero para sobrevivir a agosto.

Las réplicas nacen y mueren con IPs distintas. Kubernetes te da un nombre estable (api-reservas) que resuelve por DNS interno y reparte el tráfico entre las réplicas sanas. El frontend nunca conoce IPs. Lo verás en el módulo 4.

Cambias la versión de la imagen y el clúster sustituye las réplicas poco a poco, comprobando que las nuevas están sanas antes de retirar las viejas. Si algo va mal, rollback a la versión anterior. Módulo 2.

La configuración se separa de la imagen (ConfigMaps) y las credenciales se gestionan aparte, con control de acceso (Secrets). Como postgres-reservas guarda datos personales de clientes, esto no es opcional para Rutas Norte: es cumplimiento normativo. Módulo 3.

Los mismos manifiestos funcionan en minikube, en un clúster propio con kubeadm o en EKS/AKS/GKE. Cambian los detalles de infraestructura (tipo de almacenamiento, balanceador), no la descripción de la aplicación.

Puedes añadir tus propios tipos de objeto (CRDs) y tu propia lógica de reconciliación (operadores, módulo 6). Kubernetes no es solo un orquestador: es una plataforma para construir plataformas.

Ninguna herramienta es la mejor en abstracto. Esta tabla te sirve para justificar una decisión ante un equipo o un cliente.

Lecturas rápidas de la tabla:

• Docker Compose no compite con Kubernetes: convive. Seguirás usándolo en local.
• Swarm es más simple, pero su comunidad y su ecosistema se han reducido drásticamente; empezar un proyecto nuevo con Swarm hoy es asumir una deuda.
• Nomad es la alternativa seria si tienes cargas que no son contenedores.
• Un PaaS puede ser la respuesta correcta, y no es un fracaso admitirlo. Se paga más por unidad de cómputo, pero se ahorra en personas.

Un profesional se distingue por saber cuándo no aplicar la herramienta. Señales claras de que Kubernetes es excesivo:

1. Equipo pequeño sin perfil de plataforma. Kubernetes necesita alguien que lo cuide: actualizaciones cada pocos meses, certificados, monitorización, permisos. Si nadie tiene ese tiempo asignado, el clúster se degrada.
2. Una sola aplicación monolítica con tráfico estable. Si dos máquinas y un balanceador cubren tu carga todo el año, el clúster solo añade piezas que pueden fallar.
3. Cargas triviales o efímeras. Un cron diario que tarda 40 segundos no justifica un plano de control.
4. Necesidad de resultados inmediatos. La migración es un proyecto de semanas o meses. Si el negocio necesita entregar en dos semanas, un PaaS entrega antes.
5. Aplicaciones fuertemente ligadas a un servidor concreto (licencias por máquina, hardware especial, estado en disco local sin réplica). Se puede hacer, pero luchas contra el diseño.
6. Coste real mal calculado. Un clúster gestionado tiene coste de plano de control, nodos con capacidad reservada, tráfico y almacenamiento. Para tres contenedores, sale caro.

Regla práctica: Kubernetes empieza a rentar cuando tienes varios servicios, varios entornos y más de una persona desplegando. Antes de eso, suele ser una solución buscando un problema.

Todo el curso gira alrededor de una empresa ficticia: Rutas Norte S.L., que vende billetes de autobús por internet a través de la plataforma Rutas Norte. Aquí solo la presentamos; el detalle completo está en la lección El Proyecto del Curso: la Plataforma Rutas Norte.

Su situación de partida es la de muchísimas empresas reales:

• La plataforma corre con Docker Compose sobre dos máquinas alquiladas.
• Los despliegues son manuales: alguien entra por SSH, hace docker compose pull y up -d. Hay corte de servicio de uno o dos minutos, así que se despliega de noche.
• En puentes y vacaciones el tráfico se multiplica; la web se ralentiza y algunas reservas se pierden. La única respuesta es contratar una máquina más grande y dejarla ociosa el resto del año.
• Cuando un contenedor muere de madrugada, nadie lo levanta hasta la mañana siguiente.
• La contraseña de la base de datos está en un fichero .env que se ha copiado por correo más veces de las que nadie quiere admitir; y esa base de datos guarda datos personales de clientes.

La dirección técnica ha decidido migrar a Kubernetes por cuatro razones, que son exactamente las capacidades de la sección 4:

A partir de la próxima lección iremos construyendo esa plataforma pieza a pieza, y cada concepto nuevo se justificará con una necesidad concreta de Rutas Norte.

• "Kubernetes sustituye a Docker". No. Sigues construyendo imágenes igual. Lo que Kubernetes sustituye es docker run, los scripts de arranque y el balanceador manual. Desde la versión 1.24 el clúster habla con containerd o CRI-O a través de la interfaz CRI, no con el demonio de Docker: por eso desapareció dockershim.
• Traducir docker-compose.yml mecánicamente. Existen herramientas de conversión, pero el resultado suele ser un mal despliegue: no aprovecha sondas, ni límites de recursos, ni configuración externalizada. Conviene rediseñar, no traducir.
• Empezar por el clúster de producción. El orden correcto es: entorno local (módulo 1), entender objetos (módulos 2 y 3), y solo entonces plantear producción.
• Creer que Kubernetes te hace la aplicación resiliente. El clúster reinicia contenedores; no arregla una aplicación que pierde datos al reiniciarse o que no tolera tener varias instancias. Kubernetes premia las aplicaciones bien diseñadas y castiga las que no lo están.
• Ignorar el coste de las personas. El presupuesto de un clúster no es solo infraestructura: es formación, guardias y mantenimiento. Ponlo por escrito antes de proponer la migración.
• Consejo de vocabulario: acostúmbrate desde hoy a decir "estado deseado" y "reconciliación". Cuando algo no funcione en el clúster, la pregunta correcta casi siempre es: ¿qué estado he declarado y por qué el clúster no puede alcanzarlo?

Sin escribir ningún manifiesto, elabora una tabla con los cinco problemas operativos que sufre Rutas Norte hoy y, para cada uno, indica: (a) qué capacidad de Kubernetes lo resolvería, y (b) qué pasaría si la empresa decidiera no migrar y simplemente contratar servidores más grandes.

Para cada uno de estos tres casos, decide si recomendarías Kubernetes, un PaaS o Docker Compose, y justifica la decisión en tres líneas:

1. Una startup de dos personas con una aplicación web y una base de datos, que necesita salir al mercado en un mes.
2. Una aseguradora con 60 microservicios, tres entornos, requisitos de auditoría y equipos en dos países.
3. Un blog corporativo estático con 200 visitas al día.

Escribe un párrafo de un máximo de 150 palabras dirigido a la dirección no técnica de Rutas Norte explicando por qué migrar a Kubernetes, sin usar las palabras "pod", "contenedor" ni "clúster". Debe mencionar coste, disponibilidad y datos de clientes.

Solución 1

Solución 2

1. PaaS. Dos personas no pueden mantener un clúster y salir al mercado en un mes. La prioridad es entregar; la dependencia del proveedor es un problema aceptable que se resuelve más adelante si el producto funciona.
2. Kubernetes. 60 microservicios, tres entornos y auditoría son exactamente el punto donde el coste operativo se amortiza: RBAC, namespaces por entorno, políticas de red y despliegues homogéneos entre equipos y países.
3. Ninguno de los tres, o Docker Compose como mucho. 200 visitas al día en un sitio estático se sirven con alojamiento estático o una CDN. Cualquier orquestador es coste puro sin beneficio.

Solución 3 (ejemplo de respuesta válida)

Hoy la venta de billetes depende de dos máquinas que gestionamos a mano. Cuando algo falla de noche, no se recupera hasta la mañana siguiente, y en puentes y vacaciones —justo cuando más vendemos— la web se ralentiza y perdemos reservas. Además, pagamos todo el año una capacidad que solo necesitamos unas semanas. La nueva plataforma que proponemos vigila el servicio de forma continua y lo restablece sola si falla, amplía la capacidad automáticamente cuando sube la demanda y la reduce cuando baja, y permite publicar mejoras sin cerrar la web. También separa las claves de acceso a los datos de nuestros clientes del código y registra quién puede consultarlos, lo que refuerza nuestra posición ante una auditoría de protección de datos. El coste inicial es de formación y puesta en marcha; el ahorro está en capacidad no desperdiciada y en ventas que hoy se pierden.

Kubernetes es un orquestador de contenedores: un sistema al que declaras el estado que quieres y que trabaja de forma continua para mantenerlo, aportando autorreparación, escalado, descubrimiento de servicios, despliegues sin corte y portabilidad entre nubes. Nació de la experiencia de Google con Borg, es hoy un proyecto neutral de la CNCF y se ha convertido en el estándar de facto, pero tiene un coste operativo real que lo desaconseja para equipos pequeños y cargas triviales. Rutas Norte encaja de lleno en el perfil que sí lo justifica: varios servicios, varios entornos, picos de demanda pronunciados y datos personales que proteger.

Ya sabes qué hace Kubernetes. La siguiente pregunta es cómo lo hace: qué piezas componen un clúster, cuál es el bucle de reconciliación que sostiene todo el modelo declarativo y qué ocurre exactamente, paso a paso, desde que envías un manifiesto hasta que hay un contenedor corriendo en un nodo. Eso es lo que veremos en Arquitectura de Kubernetes.