---
title: "Kubernetes y Docker: diferencias y cómo trabajan juntos"
description: "No son alternativas: uno crea y ejecuta contenedores, el otro los coordina. Descubre qué hace cada uno y cuándo necesitas realmente Kubernetes."
url: "https://www.alemasone.com/es/diferencias-kubernetes-y-docker/"
language: "es"
published: 2026-04-04
updated: 2026-09-20
categories: ["Programación Y Desarrollo"]
translations:
  it: "https://www.alemasone.com/it/kubernetes-e-docker-differenze/"
  en: "https://www.alemasone.com/en/kubernetes-vs-docker-differences-how-they-work/"
  fr: "https://www.alemasone.com/fr/difference-kubernetes-docker-orchestration/"
  pt: "https://www.alemasone.com/pt/diferencas-kubernetes-e-docker-como-funciona/"
  de: "https://www.alemasone.com/de/kubernetes-vs-docker-unterschiede-zusammenarbeit/"
---

# Kubernetes y Docker: diferencias y cómo trabajan juntos

Preguntarse si usar [Kubernetes](https://kubernetes.io/) o [Docker](https://www.docker.com/) es un poco como preguntarse si comprar un camión o construir un puerto. **Docker crea y hace funcionar los contenedores. Kubernetes coordina cientos de contenedores en decenas de máquinas.** Trabajan a dos niveles distintos y a menudo se usan juntos. O bien puedes usar solo Docker, porque muchos proyectos no tienen el problema que resuelve Kubernetes.

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](https://hub.docker.com/)**, el registro público más utilizado.

![Esquema que compara máquinas virtuales con sistema operativo completo y contenedores apoyados en un solo kernel](architettura-container-e-virtuali-kubernetes-docker.png "El contenedor comparte el kernel: esto es lo que lo hace ligero")

**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.

![Esquema de un clúster Kubernetes con el control plane y los nodos worker que alojan pods y contenedores](architettura-kubernetes-e-docker.png "El control plane decide, los nodos ejecutan")

## 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](https://docs.docker.com/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](/es/mejores-alternativas-xampp-desarrollo-local/) 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](https://k3s.io/)** 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.

> **Aprende en este orden.** Primero a construir una imagen y hacerla funcionar; luego Compose para algunos servicios en una máquina; solo después Kubernetes, de forma local con [minikube](https://minikube.sigs.k8s.io/), [kind](https://kind.sigs.k8s.io/) o el clúster integrado en Docker Desktop. Quien se salta los dos primeros pasos acaba copiando archivos YAML que no entiende, y de ahí nace la fama de herramienta incomprensible.

## 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](https://podman.io/), 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.

> **¿Quién lo levanta a las tres de la mañana?** Cuenta cuántas personas del equipo sabrían hacerlo. Si la respuesta es «una», una infraestructura compleja es un riesgo adicional. La alta disponibilidad se consigue con herramientas que el equipo conozca bien, aunque sean menos potentes.

## 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](/es/mejores-software-virtualizacion-guia-comparativa/) 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](/es/virtualizacion-mac-apple-silicon-windows-linux/) 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.