Docker Compose vs Kubernetes: cuándo usar cada uno, diferencias y migración

Informatec Digital » Recursos » Docker Compose vs Kubernetes: cuándo usar cada uno, diferencias y migración

Si trabajas con contenedores, tarde o temprano llega la gran pregunta: ¿Docker Compose o Kubernetes? Ambas herramientas se usan en el ciclo de vida de aplicaciones en contenedores, pero no pretenden resolver exactamente lo mismo ni en el mismo contexto. En este artículo las comparamos a fondo, con ejemplos prácticos, escenarios reales y pistas para migrar de una a otra sin dramas.

Más allá del postureo tecnológico, la decisión impacta en el día a día: tiempos de despliegue, escalabilidad, resiliencia, seguridad y costes. También en los casos de uso típicos de data engineering —pipelines, bases de datos, streaming, batch, formatos y gobierno del dato— donde la orquestación marca la diferencia en productividad.

Qué son Docker y Docker Compose (y para qué sirven de verdad)

Cuando hablamos de Docker, en realidad hablamos de un ecosistema: Docker Engine, Docker Hub, Dockerfile, Docker Compose… El motor crea y ejecuta contenedores a partir de imágenes; el Hub facilita compartirlas; y Compose permite definir varias piezas del stack en un archivo YAML para levantarlas con un solo comando.

Compose nació para ahorrarnos scripts interminables y comandos sueltos. Con un único docker-compose.yml describes servicios, redes y volúmenes, y pones todo en marcha con un “docker compose up” (o “docker-compose up” en V1). Ideal para desarrollo local, tests integrados, demos o entornos de CI.

Un ejemplo canónico de Compose podría ser este, con una API y una base de datos Postgres. Observa cómo se declaran dependencias, variables y puertos en un bloque legible:

version: '3.8'
services:
  db:
    image: postgres:latest
    restart: always
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=postgres
    ports:
      - '5432:5432'
    volumes:
      - db:/var/lib/postgresql/data
    networks:
      - mynet

  my-api:
    container_name: my-api
    build:
      context: ./
    image: my-api
    depends_on:
      - db
    ports:
      - '8080:8080'
    environment:
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: postgres
      DB_PASSWORD: postgres
      DB_NAME: postgres
    networks:
      - mynet

networks:
  mynet:
    driver: bridge

volumes:
  db:
    driver: local

Para escalar manualmente en Compose, se puede usar la opción de escala del servicio. En Compose V2 es habitual hacerlo con up –scale (en V1 existía “docker-compose scale”):

docker compose up -d --scale my-api=3

Ojo con las limitaciones: Compose está pensado para un solo host, no hace balanceo entre nodos ni autoscaling, y las actualizaciones suelen ser recreaciones manuales de contenedores con “build” y “up -d”.

Qué es Kubernetes y qué aporta sobre Compose

Kubernetes (K8s) es una plataforma de orquestación distribuida de contenedores. Gestiona despliegues a escala en clústeres multi-nodo, con conceptos como Pods, Deployments y Services para operar cargas en producción.

En K8s no gestionas contenedores sueltos, gestionas Pods (que pueden tener uno o varios contenedores). El plano de control programa dónde corre cada Pod, expone servicios, reparte tráfico, escala horizontalmente y vigila la salud de las cargas de trabajo.

Un Deployment básico podría verse así, con 3 réplicas de un servicio web. Define plantillas, etiquetas y puertos expuestos:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: my-web-image
          ports:
            - containerPort: 8000

Para exponerlo con balanceo, un Service tipo LoadBalancer es lo típico en cloud. El selector casa con labels del Pod para enrutar tráfico:

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8000
  type: LoadBalancer

En producción, K8s brilla por capacidades como autoescalado (HPA), rolling updates y auto-recuperación. El HPA ajusta réplicas en función de métricas (p.ej., CPU):

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  minReplicas: 1
  maxReplicas: 10
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-deployment
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

La salud de contenedores se vigila con probes; si fallan, K8s reinicia el contenedor. Es la base del “self-healing”:

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
spec:
  containers:
    - name: web
      image: my-web-image
      ports:
        - containerPort: 8000
      livenessProbe:
        httpGet:
          path: /healthcheck
          port: 8000
        initialDelaySeconds: 15
        periodSeconds: 15

Similitudes y diferencias clave (lo esencial sin rodeos)

Lo que tienen en común: trabajan con contenedores y definen despliegues vía YAML. Ambas soluciones son útiles para desarrolladores y operadores, y se complementan muy bien en un flujo dev→prod.

La diferencia crucial está en el alcance: Compose está centrado en Docker y un único host; Kubernetes soporta múltiples runtimes y clústeres multi-nodo, con integración directa en nubes y servicios gestionados.

Más contrastes importantes: Kubernetes ofrece autoescalado, rolling updates y autoreparación; Compose no. Kubernetes abstrae con Pods; Compose interactúa directamente con contenedores Docker.

Además, K8s incluye Jobs y CronJobs para tareas puntuales o programadas. Esto evita “cron” del sistema y procesos extra en contenedores, manteniendo la plataforma como el lugar natural donde definir automatizaciones.

En local, Compose gana por rapidez y sencillez. Para escalar a cientos de nodos o a multi-cloud, K8s es lo lógico. Compose puede aprovechar Docker Swarm para multi-host, pero su adopción y capacidades no compiten con el ecosistema y la madurez de Kubernetes.

Por qué necesitas orquestación (y cuándo cada una encaja mejor)

Un buen orquestador te da: provisionamiento y despliegue unificados, arranques programados, comunicación entre servicios, balanceo, y un plus de seguridad por gobierno adicional sobre cada servicio.

Compose cubre lo básico de forma ágil y legible, lo que lo hace un chollo para desarrollo, pruebas y demos. Pero sus límites aparecen en cuanto necesitas varios nodos, balanceo nativo y autoscaling, o despliegues progresivos sin caída.

Kubernetes, en cambio, es “la plataforma” cuando la carga crece: multi-nodo, autoscaling, alta disponibilidad y ecosistema gigantesco, con soporte nativo en AWS, Azure, GCP y opciones gestionadas.

Casos de uso reales (dev, data y más)

Compose brilla en: entornos locales reproducibles, pruebas E2E, CI/CD y formación. Definir el stack completo en YAML y levantarlo en un comando te quita mucho ruido.

Kubernetes es ideal para: aplicaciones en producción, IoT y edge, big data y machine learning, y entornos multi/híbrido cloud. Gestiona cargas distribuidas donde la latencia, la resiliencia y la observabilidad importan.

En data engineering, K8s es perfecto para pipelines de streaming y batch, bases de datos, colas y motores analíticos, con control de recursos por Pod y escalado automático en picos.

Si tu proyecto es pequeño y cabe en un host, Compose te hará feliz sin complicarte. Cuando tu base de usuarios crece y necesitas tolerancia a fallos y balanceo serio, es momento de pensar en Kubernetes.

Redes, escalado y actualizaciones: comparación práctica

Compose crea una red por proyecto y resuelve nombres por servicio. Comunicar contenedores es trivial y seguro dentro del proyecto, pero el balanceo externo y el multi-host no son nativos.

En Kubernetes, los Services ofrecen descubrimiento DNS y balanceo dentro del clúster; hacia fuera puedes usar LoadBalancer, NodePort o Ingress para enrutar tráfico HTTP/S.

Escalado: Compose escala manualmente y solo en un host. K8s escala horizontalmente con HPA, y de forma programática con métricas y/o eventos. Además, puede crecer a más nodos si el clúster lo permite.

Actualizaciones: en Compose suelen ser recreaciones manuales. K8s hace rolling updates con control de progreso (kubectl rollout) y vuelta atrás si algo sale mal, minimizando impactos.

Auto-recuperación: Compose puede reiniciar contenedores, pero no resuelve caídas del host o del runtime. Kubernetes recoloca Pods en nodos sanos, de forma transparente para usuarios.

Productividad del desarrollador y experiencia de operación

Compose es una capa fina encima de Docker. Aprenderlo es rápido y su feedback loop es inmediato, perfecto para iterar.

Kubernetes añade conceptos (Pods, Deployments, Services, Ingress, ConfigMaps, PVCs…). La curva de aprendizaje existe, pero a cambio obtienes control fino de despliegues, seguridad, observabilidad y escalado.

En cuanto a compatibilidad, Compose es “Docker-first”. K8s soporta varios runtimes y se integra con proveedores cloud, algo clave para empresas con estrategias multicloud o híbridas.

Migrar de Docker Compose a Kubernetes sin volverte loco

¿Cuándo migrar? Cuando tu aplicación deja de ser “pequeñita”, necesitas multi-nodo, observabilidad, escalado y alta disponibilidad, o te piden despliegues canarios y blue/green.

Retos típicos: mapear la red de servicios, diseñar Storage con PV/PVC, separar configuración en ConfigMaps/Secrets y revisar los patrones de salud y readiness de cada contenedor.

También hay que reconsiderar la arquitectura: el Pod como unidad de despliegue, servicios para exponer endpoints y recursos por contenedor (CPU/Mem) para que el scheduler haga su trabajo.

Kompose: de Compose a K8s en pocos pasos

Kompose convierte archivos docker-compose.yml a manifiestos de Kubernetes u OpenShift. Es la forma más directa de arrancar una migración sin ponerse a reescribir a mano todos los YAML.

Antes de empezar necesitas un clúster K8s y kubectl configurado. Se recomienda al menos dos nodos de trabajo (no control plane) si vas a probar algo con estado. Comprueba tu versión con “kubectl version”.

Instalación: el método recomendado es descargar el binario de la última release de GitHub. También puedes usar tarball, Homebrew en macOS o “go get” (esta última opción tira del master con cambios en desarrollo).

Conversión básica: sitúate en el directorio del docker-compose.yml y ejecuta:

kompose convert
kubectl apply -f <archivos-generados>

Kompose genera Deployments y Services por defecto. El log suele listar cada archivo creado y, una vez aplicado, verás Deployments y Services “created” en el clúster.

Acceso: si usas minikube, puedes exponer o consultar servicios fácilmente. En cloud, revisa “LoadBalancer Ingress” para obtener la IP pública del Service tipo LoadBalancer; con NodePort, tendrás un puerto abierto en los nodos.

Limpieza: cuando termines la prueba, elimina los recursos aplicados. Mantén tu clúster limpio para evitar conflictos entre iteraciones.

Opciones avanzadas de Kompose (proveedores, objetos y etiquetas)

Kompose soporta Kubernetes y OpenShift. Si no indicas “–provider”, usa Kubernetes por defecto. Con OpenShift, puede generar DeploymentConfigs e ImageStreams, e incluso BuildConfigs si usas directivas de build.

También admite varias salidas: JSON con “-j”, ReplicationControllers, DaemonSets o Charts de Helm. La bandera “–replicas” te deja cambiar el número de réplicas en RCs; para Helm, genera la estructura base del chart.

Las etiquetas específicas de Kompose dentro del compose influyen en la conversión. Por ejemplo, puedes definir el tipo de Service o si exponer un endpoint a través de un Ingress/Route.

Etiqueta	Valores
kompose.service.type	nodeport / clusterip / loadbalancer
kompose.service.expose	true / hostname

Detalles a tener en cuenta: los nombres con “_” se convierten a “-” (K8s no permite guiones bajos) y, si un servicio usa volúmenes, la estrategia de despliegue cambia a “Recreate” para evitar conflictos con escritor múltiple.

Soporte de versiones y ficheros múltiples en Kompose

Kompose soporta Compose V1, V2 y V3 (con soporte limitado para 2.1 y 3.2 por su carácter experimental). Si pasas varios archivos docker-compose a la vez, se fusionan y lo común se sobreescribe por el último, igual que harías en un override.

En la conversión a Kubernetes verás mensajes tipo “WARN Unsupported key build – ignoring” si hay claves no compatibles. No te asustes, la herramienta sigue con lo que entiende y te deja el resto para un ajuste manual posterior.

Más allá de Kompose: Move2Kube y migración manual

Si necesitas más control, existen herramientas como Move2Kube que analizan tu compose y generan artefactos K8s con mayor fine-tuning. Son útiles cuando quieres adaptar patrones empresariales o plantillas de tu plataforma.

La migración manual es perfectamente válida, y casi siempre recomendable tras el “primer pase”. Pasos típicos: convertir servicios a Deployments/StatefulSets, redes a Services/Ingress y volúmenes a PV/PVC con clases de almacenamiento.

Un ejemplo mínimo de conversión de un servicio de Compose a Deployment podría ser así: traslada puertos, imagen y labels a la plantilla del Pod:

# docker-compose.yml
version: '3'
services:
  web:
    build: .
    ports:
      - '8000:8000'
    depends_on:
      - db

# Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: my-web-image
          ports:
            - containerPort: 8000

Para estado (bases de datos, colas), plantéate StatefulSets y PersistentVolumes. No todo lo que iba “junto” en Compose debería ir en el mismo Pod; separa responsabilidades y usa Services para comunicar componentes.

Escenarios de datos: streaming, batch y gobierno

En data pipelines complejos, K8s encaja como anillo al dedo: Jobs para procesos batch, CronJobs para ventanas temporales, Deployments para APIs y operadores para sistemas como Kafka, Spark o Flink.

Para streaming y bases, los operadores y charts comunitarios facilitan el despegue. La red de Service Mesh y el control de recursos garantizan latencias y SLOs más predecibles frente a una solución de un solo host.

En gobierno y seguridad del dato, K8s ofrece namespaces, policies y control de RBAC para auditar y separar entornos. Es una diferencia práctica frente al enfoque local de Compose.

Buenas prácticas y pequeños trucos operativos

En Compose: mantén el YAML pequeño y modular; usa variables de entorno y archivos .env; documenta puertos y dependencias; y refleja en CI lo que corres en local.

En Kubernetes: define requests/limits de CPU y memoria, usa Readiness/Liveness probes, separa configuración en ConfigMaps/Secrets, y aplica estrategias de despliegue adecuadas a cada servicio.

Para actualizaciones en K8s: usa kubectl set image y kubectl rollout status para monitorizar progresos y revertir si algo falla. Evitarás tiempos muertos en producción.

Si necesitas jobs puntuales en Compose, puedes simularlos, pero en Kubernetes es más limpio con CronJobs/Jobs; no ensucias contenedores con procesos extra ni crons del host.

FAQ rápida para no liarse

¿Compose sustituye a Kubernetes? No. Compose simplifica stacks multi-contenedor en un host; K8s orquesta a escala en clúster con alta disponibilidad.

¿Se sigue usando Compose? Sí, muchísimo. Es la herramienta ideal de desarrollo y pruebas para levantar entornos completos con un par de comandos.

¿Es “mejor” Kubernetes que Docker? Son cosas distintas: Docker es la plataforma de contenedores; K8s los orquesta en clúster y añade operativa avanzada.

¿Puedo llevar mi Compose a K8s sin reescribirlo a mano? Sí, con Kompose o con la integración de Docker Desktop. Te da un primer paso rápido que luego puedes pulir.

Detalles finos: programación, OpenShift y conversiones alternativas

K8s no es sólo despliegue continuo: Jobs y CronJobs cubren tareas puntuales o planificadas sin que tengas que gestionar crons del sistema.

En OpenShift, Kompose puede generar DeploymentConfigs e ImageStreams, e incluso BuildConfigs si en Compose tenías build asociado a un repositorio Git. Las banderas “–build-repo” y “–build-branch” sirven para ajustar el origen.

Si quieres otra salida, Kompose permite DaemonSets, ReplicationControllers o Charts de Helm en vez de Deployments y Services por defecto. También puede generar JSON y no sólo YAML.

Compatibilidades, advertencias y pequeños gotchas

Compose V1/V2/V3 están soportadas por Kompose (con límites en 2.1 y 3.2). Las claves no soportadas se ignoran con WARN, dejándote hueco para ajustes manuales.

Si tu servicio tiene volúmenes, Kompose cambia la estrategia a “Recreate” para evitar concurrencia sobre el mismo volumen. Es normal en servicios con estado.

Los guiones bajos en nombres se transforman a guiones. Es una restricción de Kubernetes sobre los nombres de objetos, así que procura ya nombrar “bien” en Compose para no sorprenderte al convertir.

Para acceder desde fuera, revisa el tipo de Service: ClusterIP (interno), NodePort (puerto en nodos) o LoadBalancer (IP pública en cloud). Con Ingress tendrás rutas HTTP/S limpias y TLS centralizado.

Si pruebas en minikube, comandos como “minikube service <svc> –url” te devuelven una URL rápida. En cloud, mira el campo “LoadBalancer Ingress” al describir el Service.

Un apunte curioso: en la comunidad vas a encontrar referencias a salarios de perfiles Kubernetes y a tasas de adopción cercanas al 88% en entornos productivos. Nada raro: es el estándar de facto.

Para cerrar el círculo, hay vida más allá de HTTP: Service Mesh, operadores y CRDs amplían el alcance de K8s. Si vienes de Compose, es normal que al principio abrume, pero ese poder extra se traduce en operaciones más sólidas.

Políticas de reinicio: equivalencias útiles

Compose permite “restart: always/on-failure/no”. En K8s, según el caso, tendrás Pods sueltos o controladores (Deployments o RC) con restartPolicy apropiadas.

docker-compose restart	Objeto en K8s	restartPolicy
«» / always	Controlador (Deployment/RC)	Always
on-failure	Pod	OnFailure
no	Pod	Never

Si en Compose tenías contenedores “de cálculo” o tareas efímeras (como un “pi” rápido), plásmalo en K8s como Job o CronJob con la política adecuada y listo.

Elige Compose para mover rápido en local y Kubernetes cuando el entorno te pida músculo: multinodo, autoscaling, despliegues sin cortes y resiliencia real. Con Kompose, Move2Kube y un poco de mimo, la transición es muy llevadera.

Al final la elección depende de escala y complejidad: Compose encaja de lujo para desarrollo, pruebas y stacks de un solo host; Kubernetes es el camino para despliegues empresariales, multi-cloud y equipos que necesitan automatización avanzada, alta disponibilidad y un ecosistema con miles de integraciones.