Docker vs Kubernetes: cuándo me alcanza con uno y cuándo necesito el otro

Me pidieron «alta disponibilidad» para un sistema crítico. Tenía Docker Compose funcionando perfecto en un solo nodo. Pensé: «con –scale lo resuelvo». Hasta que entendí que escalar horizontalmente en múltiples nodos con Compose no es trivial. Ese fue el momento en que Kubernetes dejó de ser «esa tecnología complicada» y se convirtió en la herramienta correcta para el trabajo.

Docker standalone: cuándo alcanza

No todo necesita Kubernetes. Docker solo, o Docker Compose, es perfecto para muchos casos de uso:

• Aplicaciones en un solo servidor
• Entornos de desarrollo local
• Proyectos personales o startups en etapa temprana
• Workloads que no requieren alta disponibilidad real
• Pipelines de CI/CD

La tabla que lo resume todo

Característica	Docker solo	Docker Swarm	Kubernetes
Complejidad	Baja	Media	Alta
HA multi-nodo	No	Sí (básico)	Sí (avanzado)
Auto-scaling	Manual	Básico	HPA / VPA automático
Self-healing	restart policy	Sí	Sí (avanzado)
Rolling updates	Manual	Sí	Sí (con control fino)
Secrets	Env vars / archivos	Docker Secrets	Kubernetes Secrets + Vault
Networking	Bridge / overlay básico	Overlay	CNI (Calico, Flannel, etc.)
Observabilidad	docker logs / stats	Básica	Prometheus, Grafana, Jaeger
Curva de aprendizaje	Días	Semanas	Meses

Docker Swarm: el punto medio

Swarm es el orquestador nativo de Docker. Más simple que Kubernetes, soporta multi-nodo y HA básica. Si necesitás distribuir contenedores en 2-5 nodos sin la complejidad de K8s, Swarm es una opción válida.

# Inicializar un swarm
docker swarm init --advertise-addr 192.168.1.10

# Agregar un nodo worker
docker swarm join --token SWMTKN-1-xxx 192.168.1.10:2377

# Desplegar un stack (similar a docker compose)
docker stack deploy -c docker-compose.yml mi-app

# Ver servicios del stack
docker service ls
docker service ps mi-app_api

# Escalar un servicio
docker service scale mi-app_api=3

Kubernetes: cuándo lo necesitás de verdad

En mi cluster SUSE Linux HA con dos nodos, Swarm funcionaba. Pero cuando los requisitos crecieron — deploys sin downtime garantizado, auto-scaling basado en métricas, gestión de secretos centralizada, rollbacks automáticos — Kubernetes fue la respuesta correcta.

La diferencia fundamental: Docker (y Swarm) son herramientas para correr contenedores. Kubernetes es una plataforma para gestionar aplicaciones. La distinción importa cuando tu aplicación crece.

# El mismo concepto en Docker Compose vs Kubernetes

# docker-compose.yml
services:
  api:
    image: mi-api:1.4.2
    replicas: 3
    restart: unless-stopped

# ─────────────────────────────────────────────
# En Kubernetes (deployment.yaml)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1    # nunca baja de 2 replicas durante update
      maxSurge: 1          # puede tener 4 temporalmente
  selector:
    matchLabels:
      app: api
  template:
    spec:
      containers:
      - name: api
        image: mi-api:1.4.2
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 80
          initialDelaySeconds: 30
        readinessProbe:
          httpGet:
            path: /ready
            port: 80

El camino natural: Docker → Compose → Kubernetes

No es un salto, es una progresión. Empecé con docker run, pasé a Compose para gestionar múltiples servicios, y cuando los requisitos de producción superaron lo que Compose podía manejar cómodamente, migramos a Kubernetes. Los conceptos son los mismos — imágenes, contenedores, redes, volúmenes — pero Kubernetes agrega la capa de orquestación inteligente que necesitás a escala.

El conocimiento de Docker no se descarta al llegar a Kubernetes: es el prerequisito. Todo pod de Kubernetes corre contenedores Docker. Los Dockerfiles que aprendiste a escribir son exactamente los mismos. La diferencia está en quién los gestiona y con qué nivel de sofisticación.

Mi setup actual

Hoy corro Kubernetes en mi cluster on-premise SUSE con dos nodos en HA. Docker sigue presente — lo uso en CI/CD para buildear imágenes y en desarrollo local. Compose lo uso para levantar entornos de desarrollo con múltiples servicios. Kubernetes gestiona producción. Cada herramienta en su lugar.

---

← Artículo anterior: Seguridad en Docker | Fin de la Serie Docker Completo

Esta fue la serie completa sobre Docker. Si llegaste hasta acá, tenés las bases para trabajar con contenedores en entornos reales. El siguiente paso natural es Kubernetes — cubriremos eso en una serie dedicada.

---

← Artículo anterior: Seguridad en Docker: errores que cometí y cómo los corregí | Fin de la Serie Docker Completo