# Docker vs. Kubernetes: diferencias y cuándo utilizar cada uno

**Categoría:** DevOps y cloud · **Nivel:** Intermedio · **Lectura:** 13 min
**Publicada:** 2026-07-29 · **Actualizada:** 2026-07-29 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/devops-cloud/docker-vs-kubernetes-diferencias/

Por qué no son alternativas entre sí: uno empaqueta y ejecuta contenedores, el otro los orquesta a escala. Qué aporta cada capa, cuándo alcanza con Docker y cuándo se justifica Kubernetes.

## Respuesta rápida

> Docker y Kubernetes no son alternativas entre sí: resuelven problemas de dos capas distintas que en la práctica se usan juntas. Docker empaqueta una aplicación en una imagen y la ejecuta como contenedor en una máquina. Kubernetes orquesta muchos contenedores repartidos en varias máquinas —un clúster— para que sigan corriendo, se reinicien solos, escalen según la demanda y se actualicen sin cortar el servicio. La pregunta útil no es «¿cuál uso?» sino «¿mi proyecto ya justifica sumar la segunda capa?». Esta guía es un marco de decisión: qué aporta cada una y qué costo operativo real hay que asumir antes de sumar un clúster.

## Dos capas que se apoyan, no dos competidores

Buena parte de la confusión entre Docker y Kubernetes viene de tratarlos como si compitieran por el mismo lugar. No compiten: operan en capas distintas, y la de arriba depende de la de abajo. Si todavía no tenés claro qué es una imagen, un contenedor o un volumen, esta guía no es el lugar para aprenderlo: andá primero a [Docker desde cero: imágenes, contenedores y volúmenes](../docker-desde-cero-imagenes-contenedores-y-volumenes/index.md). Lo mismo si nunca escuchaste hablar de un pod, un deployment o un service: esos tres conceptos están explicados en detalle en [Kubernetes para principiantes: pods, deployments y services](../kubernetes-para-principiantes-pods-deployments-y-services/index.md), incluida la pregunta de por qué Kubernetes no reemplaza a Docker.

Acá no se repite esa explicación. El objetivo de esta guía es otro: es un marco de decisión para alguien que ya entiende las piezas sueltas y necesita resolver una pregunta distinta —¿qué tanto de esto necesita mi proyecto en este momento, y qué me cuesta cada nivel de complejidad que sumo?

![Diagrama de dos capas apiladas. Arriba, la capa de Kubernetes: un clúster con tres nodos, cada uno corriendo varios contenedores, con un texto que indica que Kubernetes distribuye, reinicia, escala y actualiza esos contenedores sin cortar el servicio. Una flecha hacia abajo indica que esta capa opera sobre contenedores compatibles con OCI. Abajo, la capa de Docker: una imagen construida con un Dockerfile se ejecuta como un contenedor individual en una sola máquina.](../../assets/img/guias/docker-kubernetes-capas.svg)

*Kubernetes no sustituye el bloque de abajo: lo repite en varias máquinas y lo mantiene coordinado.*

## Qué resuelve cada capa

La forma más rápida de ordenar la comparación es mirar qué problema resuelve cada herramienta, no qué funciones individuales tiene cada una.

| Aspecto | Docker | Kubernetes |
|---|---|---|
| Qué es | Un motor de contenedores: construye imágenes y ejecuta contenedores | Un orquestador: coordina muchos contenedores a través de un clúster de máquinas |
| Problema que resuelve | Empaquetar una aplicación con sus dependencias y ejecutarla igual en cualquier máquina | Mantener vivos, distribuidos, escalados y actualizados muchos contenedores en producción |
| Unidad básica | El contenedor, a partir de una imagen definida en un Dockerfile | El pod (uno o más contenedores), gestionado por objetos como el deployment |
| Alcance típico | Una máquina, o varias con Docker Compose, sin coordinación real entre ellas | Muchas máquinas (nodos) coordinadas como si fueran un solo clúster |
| Qué NO hace, según su propia documentación | No decide cómo repartir contenedores entre varias máquinas ni los reinicia automáticamente si el proceso principal muere | No construye ni despliega tu código fuente, y no es una plataforma PaaS (plataforma como servicio) monolítica todo en uno |
| Archivo de configuración típico | Dockerfile y, para varios servicios, compose.yaml | Manifiestos YAML: Deployment, Service, entre otros objetos |
| Cómo se opera | `docker run`, `docker compose up` | `kubectl apply -f`, o herramientas de instalación como kubeadm |

La fila que más se ignora es la de «qué no hace»: Kubernetes no construye ni despliega tu código, eso sigue siendo trabajo de un pipeline de integración continua aparte del clúster. El próximo apartado desarrolla esa lista con la fuente oficial.

## Lo que Kubernetes explícitamente no es

La documentación oficial de Kubernetes dedica una sección entera, titulada «What Kubernetes is not», a dejar esto por escrito, y vale la pena traducirla porque corrige varias expectativas frecuentes de quien recién llega:

> **En palabras de la documentación oficial**
> - No limita qué tipo de aplicaciones podés correr: si algo funciona en un contenedor, corre en Kubernetes, con estado o sin él.
> - No despliega código fuente ni construye tu aplicación: eso depende de las prácticas de integración y entrega continuas de cada organización, no de Kubernetes.
> - No provee servicios de aplicación —bases de datos, colas de mensajes, cachés— como componentes propios: esos sistemas pueden correr sobre Kubernetes, pero no vienen incluidos.
> - No dicta ni impone una solución de logging, monitoreo o alertas: aporta mecanismos para exportar métricas, pero la herramienta concreta queda afuera de su alcance.
> - No es un sistema PaaS tradicional y monolítico: es modular y cada pieza es reemplazable por separado.

Esta lista importa para la decisión de fondo: adoptar Kubernetes no resuelve, por sí solo, el pipeline de despliegue ni la observabilidad de tu sistema. Esas piezas se siguen necesitando, con o sin clúster.

## Cuándo alcanza con Docker o Docker Compose

En la mayoría de los proyectos que arrancan, sumar Kubernetes es adelantarse a un problema que todavía no existe. Estos son los escenarios donde Docker solo, o [Docker Compose](../docker-compose-para-levantar-aplicaciones-completas/index.md) para levantar varios servicios relacionados con un solo comando, alcanzan de sobra:

- **Un servicio o una API en un solo servidor,** que no necesita tolerar la caída de esa máquina porque no hay una segunda a la que migrar.
- **Un side project, un dashboard interno o un sitio de bajo tráfico,** donde un reinicio manual ocasional no tiene un costo real.
- **Una aplicación con pocos servicios relacionados** —por ejemplo, una web, una base de datos y una caché— donde un solo archivo `compose.yaml` describe esa combinación y la levanta con un comando.
- **Un equipo de una o dos personas** sin un rol dedicado a operar infraestructura: cada pieza nueva de Kubernetes que se suma es una pieza más que alguien tiene que aprender a diagnosticar cuando falla de madrugada.

En estos casos, Kubernetes no aporta nada que no puedas lograr ya, y sí suma configuración y superficie de fallos que nadie del equipo tiene tiempo de sostener.

## Cuándo se justifica Kubernetes

El cálculo se invierte cuando el problema real ya no es hacer correr contenedores, sino gobernar muchos de ellos. Kubernetes se justifica cuando aparece alguna de estas condiciones, y sobre todo cuando aparecen combinadas:

- **Varios servicios independientes** (una arquitectura de microservicios) que necesitan desplegarse y escalarse por separado, no como un bloque único.
- **Alta disponibilidad real:** el sistema tiene que seguir respondiendo aunque una máquina completa se caiga, no solo aunque un proceso se cuelgue.
- **Tráfico variable** que exige escalar hacia arriba y hacia abajo según la demanda, sin que alguien ejecute un comando cada vez que cambia.
- **Actualizaciones frecuentes** que necesitan salir sin cortar el servicio de quien lo está usando en ese momento.
- **Un equipo, propio o del proveedor de nube, con capacidad real de operar el clúster:** parchear, monitorear y responder incidentes.

Si ya tenés varios servicios que necesitan hablar entre sí de forma segura y observable, el siguiente escalón —con Kubernetes ya en pie— suele ser un service mesh como Istio, explicado en [Qué es un Service Mesh y cómo funciona Istio](../que-es-un-service-mesh-y-como-funciona-istio/index.md). No es el primer paso, sino lo que sigue cuando la orquestación básica ya no alcanza para gobernar el tráfico entre servicios.

## El costo operativo real de un clúster

La razón más honesta para no elegir Kubernetes casi nunca es técnica: es operativa. La propia documentación de instalación de Kubernetes deja ver, con solo mirar el índice de temas que cubre, todo lo que hay que sostener para correr un clúster propio:

- **Levantar el plano de control.** Con una herramienta como kubeadm, y decidir si va a ser de alta disponibilidad.
- **Mantener etcd.** La base de datos donde vive el estado del clúster, incluida su propia alta disponibilidad.
- **Gestionar certificados PKI.** Emitirlos y renovarlos para autenticar la comunicación entre los componentes del clúster.
- **Diagnosticar fallos de pods.** Entender por qué un pod entra en CrashLoopBackOff, queda en Pending o es eliminado por falta de memoria.

El último punto tiene su propio método detallado en [Cómo diagnosticar errores y reinicios de pods en Kubernetes](../como-diagnosticar-errores-y-reinicios-de-pods-en-kubernetes/index.md): si nadie del equipo puede darse el tiempo de aprenderlo, esa es información valiosa para esta decisión. Ninguno de estos puntos es imposible; son trabajo real y permanente, que alguien tiene que asumir, esté en tu equipo o en la cuenta de un servicio gestionado. Comparar Docker con Kubernetes sin poner este costo en la balanza es comparar a medias.

## La ruta de migración de Compose a Kubernetes

No hace falta tirar todo y empezar de cero: hay una ruta razonable para pasar de un `compose.yaml` a un clúster.

1. **Publicá cada imagen en un registro accesible.** Que cada servicio viva en una imagen versionada, alcanzable desde otras máquinas, no solo construida en tu equipo.
2. **Traducí cada servicio a un Deployment y un Service.** Cada servicio de `compose.yaml` se vuelve un Deployment; si recibe tráfico de red, sumale un Service.
3. **Reemplazá los volumes por PersistentVolumeClaim.** Necesario si los datos deben sobrevivir a que el pod se reinicie o cambie de máquina.
4. **Sacá los secretos del archivo de configuración.** Variables sensibles a un Secret, el resto a un ConfigMap, en lugar de dejarlos junto al despliegue.
5. **Probá en un clúster local antes que en producción.** Hay distribuciones pensadas para correr un clúster completo en tu propia máquina y validar ahí la migración.
6. **Recién ahí, definí quién opera el plano de control.** Un servicio gestionado por un proveedor de nube, o un clúster autoadministrado con las piezas de la sección anterior.

```yaml
# Fragmento de compose.yaml
services:
  api:
    image: registro.miempresa.com/api:1.4.0
    ports:
      - "8080:8080"

# Su equivalente como Deployment + Service en Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: registro.miempresa.com/api:1.4.0
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
    - port: 8080
      targetPort: 8080
```

El error más común en esta migración es saltear el primer paso: llevar a Kubernetes una imagen que todavía se construye a mano en la laptop de alguien, en lugar de una imagen versionada y reproducible.

## Errores frecuentes al decidir

- **Tratarlos como alternativas.** Preguntar «¿Docker o Kubernetes?» como si fuera una elección excluyente, cuando casi siempre se usan juntos.
- **Adoptar Kubernetes antes de entender los contenedores que va a orquestar.** La curva de aprendizaje se vuelve doblemente empinada, y los errores de una capa se confunden con los de la otra.
- **Confundir contenedor con pod,** como si fueran la misma unidad con dos nombres distintos.
- **Esperar que Kubernetes resuelva la escalabilidad por sí solo,** sin haber diseñado la aplicación para correr en varias copias a la vez.
- **Subestimar el costo de operar el propio clúster** y descubrir recién en producción todo lo que hay que sostener para mantenerlo sano.

## Preguntas frecuentes

**¿Kubernetes reemplaza a Docker?**
No. Kubernetes opera sobre contenedores compatibles con el estándar OCI (Open Container Initiative), el mismo formato que produce Docker al construir una imagen; desde la versión 1.24 ni siquiera depende de Docker Engine como motor interno, según documentó el propio proyecto al retirar el componente dockershim. Igual seguís necesitando construir una imagen antes de que Kubernetes tenga algo que orquestar: resuelve el problema que aparece después, cuando hay que mantener corriendo muchas copias de ese contenedor en varias máquinas sin intervención manual.

**¿Puedo usar Kubernetes sin haber usado Docker antes?**
Técnicamente sí: Kubernetes no exige Docker específicamente, sino cualquier motor compatible con la interfaz CRI (Container Runtime Interface). En la práctica no es un buen punto de partida. Qué es una imagen, por qué un contenedor es efímero o qué pasa si el proceso principal se cae se aprende mucho más rápido con Docker en una sola máquina, donde los errores son fáciles de reproducir. Saltar directo a un clúster suele terminar en depurar dos capas de complejidad a la vez, sin poder distinguir si el problema está en el contenedor o en la orquestación.

**¿Cuándo me conviene quedarme solo con Docker Compose?**
Mientras tu aplicación corra en una sola máquina y no necesites tolerar que esa máquina se caiga, autoescalar según demanda ni actualizar sin cortar el servicio. Docker Compose describe varios servicios relacionados en un solo archivo y los levanta con un comando, lo cual alcanza de sobra para un side project, una herramienta interna o un producto en sus primeras etapas. El límite aparece cuando alguna de esas tres condiciones deja de ser opcional: ahí conviene evaluar el salto a Kubernetes, no antes.

**¿Qué tan grande tiene que ser un proyecto para justificar Kubernetes?**
No es una cuestión de tamaño, sino de qué garantías necesita el proyecto. Un sistema chico con un compromiso estricto de disponibilidad puede justificar Kubernetes antes que uno grande pero tolerante a caídas ocasionales. La pregunta útil no es «¿cuántos usuarios tengo?» sino «¿qué me cuesta un rato de caída, y tengo a alguien que sostenga la operación de un clúster?». Si nadie del equipo tiene tiempo para eso todavía, la conversación sobre el tamaño del proyecto es secundaria.

**¿Hay alternativas más simples para escalar sin llegar a Kubernetes?**
Sí: existe un terreno intermedio entre «un contenedor en un servidor» y «un clúster propio», con servicios de contenedores gestionados por proveedores de nube que abstraen buena parte de esa complejidad a cambio de menos control sobre los detalles. Esta guía no entra en el detalle de esas ofertas concretas porque cambian seguido y no se verificaron para esta revisión; lo que sí conviene tener claro es que Kubernetes no es la única forma de escalar contenedores, y que vale la pena comparar el costo operativo de cada opción antes de asumir que el clúster propio es obligatorio.

**¿Contenedor y pod son lo mismo?**
No, aunque en el caso más simple un pod suele envolver un solo contenedor y la diferencia parezca invisible. El contenedor es el concepto que maneja Docker: un proceso empaquetado con su entorno. El pod es el concepto que maneja Kubernetes: la unidad mínima que el clúster programa, y puede envolver más de un contenedor que comparten red y almacenamiento. La definición completa, con sus casos de uso, está en Kubernetes para principiantes; acá alcanza con remarcar que son capas de abstracción distintas, no sinónimos.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 29 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Contenedores Docker for dummies](https://underc0de.org/foro/gnulinux/contenedores-docker-for-dummies/), por *Cl0udswX*, 26 de mayo de 2016, sección GNU/Linux. Antecedente de que la comunidad discute contenedores desde 2016; usa un método de repositorio de paquetes ya deprecado, así que se cita solo como antecedente histórico, no como referencia técnica vigente.

### Documentación oficial

2. **Docker.** [Get started](https://docs.docker.com/get-started/). Base conceptual de imágenes y contenedores.
3. **Kubernetes.** [Overview](https://kubernetes.io/docs/concepts/overview/), incluida la sección «What Kubernetes is not». Fuente de la tabla comparativa y de los límites explícitos de Kubernetes.
4. **Kubernetes.** [Pods](https://kubernetes.io/docs/concepts/workloads/pods/). Definición de la unidad mínima que gestiona Kubernetes.
5. **Kubernetes.** [Setup](https://kubernetes.io/docs/setup/). Índice de herramientas y tareas para instalar y operar un clúster, base del argumento sobre el costo operativo real.
6. **Docker.** [Dockerfile reference](https://docs.docker.com/reference/dockerfile/). Referencia de la sintaxis usada en el ejemplo de migración.
7. **Kubernetes.** [Dockershim Removal FAQ](https://kubernetes.io/blog/2022/02/17/dockershim-faq/). Confirma que la versión 1.24 retiró dockershim y que Kubernetes ya no depende de Docker Engine como motor interno.

## Guías relacionadas

- [Docker desde cero: imágenes, contenedores y volúmenes](../docker-desde-cero-imagenes-contenedores-y-volumenes/index.md) — el requisito previo si todavía no manejás imágenes y contenedores.
- [Kubernetes para principiantes: pods, deployments y services](../kubernetes-para-principiantes-pods-deployments-y-services/index.md) — las tres piezas básicas del clúster, explicadas sin jerga.
- [Docker Compose para levantar aplicaciones completas](../docker-compose-para-levantar-aplicaciones-completas/index.md) — el siguiente paso práctico si el veredicto es que todavía no necesitás un clúster.
- [Cómo diagnosticar errores y reinicios de pods en Kubernetes](../como-diagnosticar-errores-y-reinicios-de-pods-en-kubernetes/index.md) — la habilidad operativa que vas a usar si el veredicto es que sí lo necesitás.
- [Qué es un Service Mesh y cómo funciona Istio](../que-es-un-service-mesh-y-como-funciona-istio/index.md) — el siguiente escalón una vez que Kubernetes ya está en pie.
- [Índice de guías de Underc0de](../../index.md)

---

Esta guía forma parte de un proyecto de la comunidad Underc0de para organizar conocimiento técnico en español. Fuente canónica: https://underc0de.org/guias/devops-cloud/docker-vs-kubernetes-diferencias/