Kubernetes y Docker: diferencias y cómo trabajan juntos
No son alternativas: uno crea y ejecuta contenedores, el otro los coordina. Descubre qué hace cada uno y cuándo necesitas realmente Kubernetes.
En esta página
Para entender la diferencia ayuda la comparación con el transporte de mercancías, de donde estas herramientas han tomado prestados sus nombres y logotipos: la ballena de Docker carga contenedores; el timón de Kubernetes (en griego kubernetes significa precisamente «timonel») los guía.
El contenedor y el puerto #
El contenedor es una caja estándar. Dentro metes la aplicación, sus librerías y la versión exacta del lenguaje que necesita. Por fuera siempre es la misma caja, con los mismos enganches: quien la mueva no tiene por qué saber qué hay dentro. Así desaparece el clásico «en mi ordenador funciona».
A diferencia de una máquina virtual, un contenedor no arrastra consigo un sistema operativo completo: utiliza el kernel del sistema que lo aloja. Por eso arranca en un segundo y pesa decenas de megabytes en lugar de gigabytes. A cambio, está menos aislado que una VM, y un contenedor Linux necesita un kernel Linux.
Docker es el taller que construye la caja y la grúa que la carga en el camión. Escribes las instrucciones en un Dockerfile, Docker produce una imagen y la hace funcionar con Docker Engine. Las imágenes ya preparadas las encuentras en Docker Hub, el registro público más utilizado.
Kubernetes es el puerto. No construye cajas ni las abre: decide en qué barco va cada una, cuántas copias de la misma carga mantener repartidas, qué hacer cuando un barco se hunde y cómo derivar los camiones que llegan al muelle correcto. Si una caja cae al mar, carga inmediatamente otra idéntica y nadie se da cuenta.
En la práctica, un clúster de Kubernetes tiene un control plane, que es el que toma las decisiones, y unos nodos (las máquinas) que ejecutan el trabajo. Los contenedores se ejecutan dentro de los pods, la unidad más pequeña que gestiona Kubernetes: normalmente un pod contiene un contenedor, aunque a veces son dos o tres que deben ir juntos.
Un puerto con tres contenedores es un recinto con tres cajas: organizarlo cuesta más que el problema que resuelve. Por eso muchos proyectos funcionan perfectamente solo con Docker.
Qué hace cada uno #
| Docker | Kubernetes | |
|---|---|---|
| Ámbito | Una máquina | Muchas máquinas juntas |
| Tarea | Construir y ejecutar contenedores | Distribuirlos, supervisarlos, sustituirlos |
| Problema que resuelve | «Funciona en cualquier sitio de la misma forma» | «Se mantiene en pie y aguanta la carga» |
| Dificultad | Lo esencial lo aprendes en una tarde | Semanas, y nunca terminas de aprenderlo |
| Cuándo es necesario | En casi todos los proyectos | Cuando la escala lo requiere |
Kubernetes se justifica con cinco funciones. Si no necesitas ninguna de ellas, no necesitas Kubernetes:
- Reinicio automático de aquello que deja de funcionar (self-healing).
- Escalabilidad: aumenta y reduce las copias según la carga.
- Distribución del tráfico entre las copias activas.
- Actualizaciones graduales, que sustituyen las copias poco a poco sin interrupciones, con posibilidad de volver a la versión anterior si algo sale mal.
- Configuración declarativa: escribes en un archivo YAML el estado que deseas y el sistema trabaja para mantenerlo, en lugar de ejecutar comandos uno por uno.
«Kubernetes ha abandonado Docker»: qué ha pasado #
Esta noticia vuelve a salir de vez en cuando y, por lo general, se cuenta mal.
En la versión 1.24, lanzada en mayo de 2022, Kubernetes eliminó el dockershim, la pieza que le permitía usar el motor de Docker para ejecutar los contenedores. Hoy utiliza runtimes más ligeros que cumplen con el estándar CRI, como containerd (que, por cierto, es el mismo motor que Docker usa internamente) y CRI-O.
Las imágenes no tienen nada que ver: las creadas con Docker siguen el estándar abierto OCI y funcionan exactamente igual en Kubernetes. Para quien desarrolla, no ha cambiado nada: construyes con Docker y ejecutas en Kubernetes como antes. El cambio solo afecta a quienes administran los clústeres.
Qué usar, según dónde te encuentres #
Una sola aplicación en un servidor. Solo Docker: una imagen, un comando para arrancarla y la opción --restart unless-stopped para que se reinicie sola. Añadir un orquestador aquí significa tener un segundo sistema que mantener para gestionar una sola cosa.
Varios servicios conectados en una máquina, por ejemplo aplicación, base de datos y caché. Aquí necesitas Docker Compose: un archivo compose.yaml describe todos los servicios y cómo se comunican entre ellos, y docker compose up los arranca juntos. Cubre el entorno de desarrollo de casi cualquier proyecto y muchas instalaciones en producción de tamaño reducido.
Varias máquinas, carga variable, ninguna interrupción permitida. Aquí es donde Kubernetes empieza a amortizarse. El criterio: si un servicio debe seguir funcionando mientras una máquina se rompe, y el número de copias debe cambiar automáticamente según el tráfico, estás en el lugar adecuado.
Los puntos medios. k3s es un Kubernetes ligero que ofrece las funciones esenciales con mucha menos complejidad, ideal para un par de máquinas o una Raspberry Pi. Docker Swarm, incluido en Docker, une varias máquinas con comandos que ya conoces. Y los servicios gestionados de los grandes proveedores, Amazon EKS, Google GKE y Azure AKS, se encargan del control plane por ti, aunque tendrás que aprender el modelo de Kubernetes de todos modos. En AWS también está ECS, que ejecuta contenedores sin necesidad de Kubernetes.
Los costes ocultos #
Quien implementa Kubernetes en un proyecto pequeño descubre pronto que la factura no es solo técnica:
- Las máquinas del clúster consumen incluso sin tráfico, porque los componentes del sistema siguen funcionando.
- Requiere competencia continua: red interna, volúmenes persistentes, gestión de credenciales, actualizaciones de versión. Kubernetes lanza tres versiones al año y cada una tiene soporte durante unos catorce meses, así que no lo instalas y te olvidas.
- El depurado se alarga: entre tu código y la petición del usuario hay más capas, y aprender a leerlas requiere tiempo.
- Docker Desktop es de pago para las grandes empresas: gratuito para uso personal, estudio y empresas con menos de 250 empleados y 10 millones de dólares de facturación; de lo contrario, necesitas una suscripción. Si buscas una alternativa abierta, tienes Podman, Rancher Desktop y, en Mac, OrbStack o Colima.
Son excelentes motivos para no usarlo cuando no es necesario, y ninguno de ellos es razón suficiente para evitarlo cuando sí se necesita.
Preguntas frecuentes #
¿Tengo que aprender Docker antes que Kubernetes? #
Sí, y te ahorrará tiempo. Kubernetes coordina contenedores: si no sabes qué es una imagen, cómo se construye y cómo se ejecuta, acabarás copiando configuraciones sin saber realmente qué hacen.
¿Puede funcionar Kubernetes sin Docker? #
Sí, y es lo normal: desde 2022, los clústeres utilizan containerd o CRI-O para ejecutar los contenedores. Sin embargo, Docker sigue siendo la herramienta más cómoda para construir las imágenes que luego ejecutará Kubernetes.
¿Cuál es la diferencia entre un contenedor y una máquina virtual? #
La máquina virtual contiene un sistema operativo completo, pesa gigabytes y tarda un poco en arrancar. El contenedor utiliza el kernel del sistema que lo aloja, pesa mucho menos y arranca en un segundo. A cambio, está menos aislado, y para ejecutar contenedores de Linux en Windows o Mac se necesita, de todos modos, una pequeña máquina virtual, algo que Docker Desktop gestiona automáticamente.
¿Sustituye Kubernetes a Docker Compose? #
En una sola máquina no, y muchos proyectos se quedan con Compose para siempre. Compose describe varios servicios en un mismo equipo, y es perfecto para desarrollo e instalaciones pequeñas. Kubernetes describe esos mismos servicios distribuidos en varias máquinas, con reglas para resistir fallos.
¿Es necesario para un sitio web o un blog? #
No, en la gran mayoría de los casos. Un sitio estático, un blog o una aplicación con unos cientos de visitas al día funcionan perfectamente en un servidor con Docker, o incluso sin él. La orquestación empieza a amortizarse cuando la escala y los requisitos de disponibilidad así lo exigen.
¿Cuándo elegir Docker Swarm en lugar de Kubernetes? #
Cuando tienes pocas máquinas, un equipo pequeño y quieres empezar rápido: Swarm se activa con docker swarm init y utiliza archivos similares a los de Compose. Sin embargo, es mucho menos extendido y tiene un ecosistema reducido. Si prevés que vas a crecer, lo mejor es invertir directamente en Kubernetes, quizás empezando por k3s.
¿Cuánto cuesta un clúster gestionado? #
Depende del proveedor y del tamaño. El gasto principal suele ser el de las máquinas que lo componen (que están siempre encendidas), más una pequeña tarifa por hora por el control plane en algunos servicios. Un entorno mínimo con redundancia cuesta, de todos modos, más que un servidor único: haz cuentas antes de lanzarte.
