La búsqueda de Docker vs Kubernetes sugiere que debe elegir uno, pero ese encuadre causa mucha confusión. Es un poco como comparar un contenedor marítimo con el puerto que organiza miles de ellos. Operan en diferentes niveles y, a menudo, se utilizan uno al lado del otro.

Esta guía explica qué hace cada uno, muestra la misma pequeña aplicación en ambos y finaliza con una forma práctica de decidir. Los comandos y archivos aquí son ejemplos estándar que no ejecutamos para este artículo, así que compruébelos con las versiones que instale.

La respuesta corta

Docker es una plataforma para empaquetar una aplicación y sus dependencias en una imagen y luego ejecutar esa imagen como un contenedor. Responde a la pregunta “¿cómo hago para que esta aplicación se ejecute de la misma manera en todas partes?”

Kubernetes, a menudo escrito como K8, es un orquestador de contenedores. Decide dónde se ejecutan los contenedores en muchas máquinas, los reinicia cuando fallan y los escala según la demanda. Responde a la pregunta “¿cómo puedo mantener cientos de contenedores funcionando de manera confiable?”

Docker vs Kubernetes uno al lado del otro

¿Qué hace Docker?

Antes de los contenedores, “funciona en mi máquina” era un problema diario, porque cada servidor tenía versiones diferentes de todo. Docker agrupa su código, tiempo de ejecución y bibliotecas en una imagen. Una copia en ejecución de esa imagen es un contenedor y comparte el kernel del host, por lo que se inicia más rápido y usa menos memoria que una máquina virtual completa.

El flujo de trabajo tiene tres pasos:

1. Construir: a Dockerfile describe cómo crear la imagen.
2. Enviar: enviar la imagen a un registro, como Docker Hub.
3. Ejecutar: inicia contenedores desde esa imagen en cualquier máquina compatible.

Para ponerse manos a la obra, comience con nuestro tutorial de Docker para principiantes y luego lea nuestras mejores prácticas de Dockerfile.

¿Qué hace Kubernetes?

Docker en un servidor funciona bien hasta que ese servidor falla, el tráfico lo supera o tienes docenas de servicios que coordinar. Kubernetes se encarga de estos trabajos operativos:

• Programación: colocación de contenedores en máquinas con suficiente capacidad libre.
• Autorreparación: reemplazar contenedores fallidos y alejar el trabajo de los nodos fallidos.
• Escalado: agregar o eliminar copias, manualmente o según métricas.
• Descubrimiento de servicios: dar un nombre estable a un grupo cambiante de contenedores.
• Actualizaciones continuas: lanzando nuevas versiones gradualmente, con una simple reversión.
• Configuración: administrar configuraciones y secretos por separado de las imágenes.

La idea central es estado deseado. Declaras que deberían existir tres copias y los controladores siguen comparando eso con la realidad y corrigiendo cualquier diferencia. Nuestro tutorial de Kubernetes para principiantes explica esto en un clúster local.

Cómo trabajan juntos Docker y Kubernetes

Una ruta típica desde la computadora portátil de un desarrollador hasta la producción se ve así:

1. Un desarrollador escribe un Dockerfile y prueba el contenedor localmente.
2. Una canalización de CI/CD crea la imagen y ejecuta las pruebas.
3. La canalización envía una imagen versionada a un registro.
4. Se actualiza un manifiesto de Kubernetes para usar esa versión de imagen.
5. Kubernetes extrae la imagen y la extiende por todo el clúster.

Por lo tanto, el trabajo de Docker prácticamente ha terminado antes de que comience Kubernetes. La imagen es el punto de entrega entre ellos.

Una aplicación, en ambos sentidos

Aquí hay un pequeño servicio web. La imagen se construye de la misma manera independientemente de la herramienta que la ejecute:

# Dockerfile
FROM python:3.13-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

Ejecutándolo con Docker

docker build -t shop-api:1.0 .
docker run -d --name shop -p 8080:8000 --restart unless-stopped shop-api:1.0

Dos comandos y se está ejecutando. Esto es simple y adecuado para muchos proyectos pequeños. Pero hay una copia en una máquina, y si la máquina falla, el servicio desaparece con ella.

Ejecutándolo con Kubernetes

# shop.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop
spec:
  replicas: 3
  selector:
    matchLabels:
      app: shop
  template:
    metadata:
      labels:
        app: shop
    spec:
      containers:
        - name: api
          image: registry.example.com/shop-api:1.0
          ports:
            - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
  ports:
    - port: 80
      targetPort: 8000

kubectl apply -f shop.yaml
kubectl get pods -l app=shop

Hay mucho más que escribir y necesitas un clúster para ejecutarlo. A cambio, obtienes tres copias, una dirección interna estable y reemplazo automático. Esa compensación es toda la decisión en miniatura: más complejidad a cambio de más resiliencia.

¿Qué sucede cuando falla un contenedor?

La confusión de Dockershim

Es posible que haya leído que “Kubernetes eliminó Docker”. Esto es cierto en un sentido estricto y asustó a mucha gente innecesariamente. Kubernetes ejecuta contenedores a través de un estándar llamado Container Runtime Interface. Docker Engine no lo implementó directamente, por lo que Kubernetes incluyó un adaptador llamado dockershim. Ese adaptador se eliminó en la versión 1.24.

Los clústeres ahora suelen utilizar tiempos de ejecución como contenedores o CRI-O. Las imágenes creadas con Docker aún funcionan porque siguen el estándar de imágenes Open Container Initiative (OCI). De modo que puede seguir compilando con Docker y su clúster ejecuta el resultado con un tiempo de ejecución diferente.

Docker Compose frente a Swarm frente a Kubernetes

La comparación más significativa es entre herramientas que coordinan contenedores:

Docker Compose inicia varios contenedores relacionados desde un archivo y es excelente para una aplicación web y una base de datos en una computadora portátil. Swarm está integrado en Docker y es mucho más fácil de aprender que Kubernetes, pero tiene un ecosistema mucho más pequeño. Kubernetes tiene la comunidad y las herramientas más grandes, lo que explica en gran medida por qué se convirtió en el sistema predeterminado para grandes implementaciones.

¿Cuál necesitas?

Docker solo suele ser suficiente cuando:

• Está desarrollando localmente o ejecutando una pequeña aplicación en un servidor.
• Tiene un equipo pequeño y no hay personal de operaciones dedicado.
• Es aceptable un breve tiempo de inactividad ocasional.

Kubernetes empieza a tener sentido cuando:

• Ejecuta muchos servicios que diferentes equipos implementan por su cuenta.
• Necesita alta disponibilidad en varias máquinas o zonas.
• El tráfico varía lo suficiente como para que el escalado automático ahorre dinero real.
• Tiene las habilidades o el presupuesto para operarlo.

También hay un término medio. Las plataformas de contenedores administradas, como AWS Fargate, Google Cloud Run o PaaS, ejecutan su imagen de Docker sin un clúster que mantener. Para muchas empresas en crecimiento, ese es el siguiente paso correcto, en lugar de saltar directamente a Kubernetes.

Si desea aprender ambos por motivos profesionales, el orden es claro: primero Docker y luego Kubernetes. No puedes depurar un Pod cómodamente sin comprender primero las imágenes, los puertos y los registros de contenedores.

Errores comunes

• Adoptar Kubernetes demasiado pronto. Copiar la arquitectura de una empresa gigante puede hundir a un pequeño equipo en el trabajo operativo.
• Usando la etiqueta latest en producción. No se puede saber qué se está ejecutando o revertir de manera confiable. Utilice etiquetas de versión específicas.
• Almacenar datos dentro de contenedores. Los contenedores son desechables, así que use volúmenes o una base de datos administrada.
• Omitir controles de estado. Sin pruebas de preparación y actividad, Kubernetes no puede tomar buenas decisiones sobre su aplicación.
• Olvidar los límites de recursos. Un contenedor codicioso puede matar de hambre a todo lo demás en un nodo.

Conclusión

Docker empaqueta su software y Kubernetes lo ejecuta a escala. En lugar de preguntar cuál es mejor, pregunta qué problema tienes hoy. Si dice “mi aplicación es difícil de instalar”, use Docker. Si “mis 40 servicios necesitan sobrevivir a fallas del servidor”, mire Kubernetes. Comience con la herramienta más simple que resuelva su problema real y avance cuando vea la necesidad.

Preguntas frecuentes

sigue aprendiendo