Docker Compose vs Kubernetes: cuándo usar cada uno en el homelab

Llevo varios años usando Docker Compose para casi todo, y hace un tiempo di el salto a Kubernetes en el homelab. Y voy a ser directo: los dos tienen su sitio. El problema es que mucha gente monta un cluster de K8s para correr Jellyfin en un solo servidor, lo mismo que otros siguen eternamente con Compose cuando ya tienen 5 máquinas y deberían haber migrado hace tiempo.

Así que te cuento mi experiencia real, sin idealismos, con lo que uso hoy mismo.

El punto de partida: ¿qué problema estás resolviendo?

#

Antes de hablar de tecnología, la pregunta es simple: ¿qué necesitas que haga tu infraestructura?

Si tienes un servidor y quieres correr Plex, Nextcloud y un par de cosas más, Docker Compose resuelve el problema en 20 minutos y te da años de paz. Si tienes varios nodos, quieres que los servicios migren automáticamente cuando un servidor cae, o manejas proyectos que necesitan rollback limpio y despliegues continuos, K8s empieza a tener sentido.

El error que veo más a menudo: gente que instala K3s en un Raspberry Pi 4 con 4GB de RAM para correr 3 contenedores. El overhead del propio plano de control ya te come una parte importante de los recursos disponibles.

Docker Compose: lo que de verdad es

#

Docker Compose no es “para principiantes”. Es una herramienta para gestionar stacks de contenedores en una sola máquina, o en pocas máquinas cuando usas Docker Swarm por encima. Su fortaleza es la simplicidad operativa.

Un archivo docker-compose.yml es legible por un humano en 5 minutos. Puedes levantar un stack entero con docker compose up -d y tumbarlo con docker compose down. Los logs son docker compose logs -f servicio. No hay abstracciones intermedias.

En mi caso, uso Compose para todo lo que corre en mi NAS (Synology DS1621+): Plex, las bases de datos que no necesitan alta disponibilidad, servicios de monitorización secundarios. El archivo está versionado en Gitea, así que si necesito restaurar el stack completo, es un git pull y un compose up.

Un stack típico de Compose en mi setup:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

version: "3.9"
services:
  app:
    image: aplicacion:latest
    restart: unless-stopped
    environment:
      - DB_HOST=postgres
      - DB_PASSWORD=${DB_PASSWORD}
    depends_on:
      - postgres
    networks:
      - backend

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=${DB_PASSWORD}
    networks:
      - backend

volumes:
  pgdata:

networks:
  backend:

Limpio, explícito, fácil de mantener. En Kubernetes, esto mismo serían 4-5 archivos YAML con más de 100 líneas en total.

Cuándo Compose empieza a doler

#

El límite real de Compose aparece cuando necesitas:

Alta disponibilidad: si el servidor donde corre Compose se cae, tus servicios se caen con él. Punto. No hay migración automática a otro nodo.

Gestión multi-nodo: con Compose, desplegar en varios servidores implica conectarte a cada uno por SSH, copiar los archivos, ejecutar los comandos. Docker Swarm ayuda algo, pero es una solución a medias que no ha tenido mucho amor en los últimos años.

Rollback limpio: con Compose, volver a la versión anterior significa editar el compose, hacer pull de la imagen anterior y relanzar. Funciona, pero no es elegante ni auditable.

Recursos compartidos entre proyectos: en Compose, cada stack es bastante independiente. En K8s puedes compartir configuraciones, secrets y recursos entre namespaces de forma mucho más controlada.

Kubernetes (K3s): qué cambia realmente

#

K3s es la distribución de Kubernetes que uso en el homelab. La razón es que el K8s oficial es demasiado pesado para nodos pequeños, y K3s recorta los componentes sin sacrificar la compatibilidad.

Lo que K8s añade sobre Compose, de forma concreta:

Scheduling automático: defines que quieres 2 réplicas de un servicio, y K8s decide en qué nodos corren. Si un nodo cae, las réplicas se redistribuyen solas en los nodos disponibles.

Health checks integrados: readiness y liveness probes. El tráfico no va a un pod hasta que está listo, y si un pod deja de responder correctamente, K8s lo mata y levanta uno nuevo.

Rolling updates: despliegas una nueva versión, K8s la va levantando gradualmente mientras mantiene instancias de la anterior. Si algo falla, haces rollback con un comando.

Namespaces: puedes aislar proyectos completamente, aplicar límites de recursos por namespace, y gestionar permisos de forma granular.

El manifiesto más básico en K8s (Deployment + Service) para lo mismo que antes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  namespace: mi-proyecto
spec:
  replicas: 2
  selector:
    matchLabels:
      app: mi-app
  template:
    metadata:
      labels:
        app: mi-app
    spec:
      containers:
      - name: app
        image: aplicacion:latest
        env:
        - name: DB_HOST
          value: postgres-svc
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: password
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: app-svc
  namespace: mi-proyecto
spec:
  selector:
    app: mi-app
  ports:
  - port: 80
    targetPort: 8080

Y esto es solo el Deployment y el Service. Falta el Secret para la contraseña, el Deployment de postgres, su Service, el PersistentVolumeClaim para los datos… La verbosidad es real.

El coste real de K8s

#

No me gusta cuando la gente presenta K8s como la solución obvia para todo, porque hay costes concretos:

Curva de aprendizaje: llevar a producción un stack en Compose tarda minutos si sabes Docker. Hacer lo mismo en K8s correctamente (con limits, probes, secrets bien gestionados) lleva horas si estás aprendiendo.

Overhead de recursos: K3s en un nodo solo consume en torno a 500MB de RAM para el plano de control. No es nada en un servidor con 32GB, pero sí importa en un mini PC con 8GB donde cada gigabyte cuenta.

Debugging más complejo: cuando algo falla en K8s, el camino de diagnóstico es más largo. kubectl describe pod, kubectl logs, eventos del namespace, estado del scheduling… hay más capas que atravesar.

Almacenamiento: en Compose, un volumen es una carpeta en el disco del servidor. En K8s, si quieres que los datos persistan y sean accesibles desde cualquier nodo, necesitas un sistema de almacenamiento distribuido como Longhorn o NFS. Otro componente que mantener.

Mi setup actual: los dos coexistiendo

#

En el homelab tengo un cluster K3s con 14 nodos (3 control plane + 11 workers). Pero también uso Compose en el NAS y en el Mac mini para servicios que no necesitan alta disponibilidad.

La línea que sigo es esta:

En K8s: servicios que necesitan HA (la instancia de n8n de automatizaciones, servicios de agentes, stacks de monitorización con Prometheus y Grafana), proyectos en desarrollo activo donde hago despliegues frecuentes, y cualquier cosa donde un downtime de 30 minutos sea un problema real.

En Compose: el stack de medios (Plex y sus sidecars), bases de datos de archivo que solo restauro en caso de necesidad, servicios de soporte que solo yo uso y donde una hora de downtime no es el fin del mundo.

No hay una respuesta única. La gente que te dice “K8s siempre” probablemente trabaja en una empresa con un equipo de plataforma. La que te dice “Compose siempre” probablemente nunca ha tenido que migrar servicios entre nodos a las 3 de la mañana porque un servidor falló.

Herramientas que hacen Kubernetes más manejable

#

Si decides ir por el camino de K8s en el homelab, hay herramientas que reducen la fricción considerablemente:

Helm: gestiona aplicaciones en K8s con charts. En lugar de escribir 10 manifiestos YAML, instalas helm install nombre chart/app con los valores que necesitas. La curva de aprendizaje existe, pero la reutilización de charts de la comunidad ahorra mucho trabajo.

Lens / OpenLens: cliente de escritorio para gestionar clusters. Visualiza pods, logs, métricas, y permite ejecutar comandos sin salir de la interfaz. Para gente que empieza, reduce mucho la frustración inicial.

k9s: interfaz de terminal para Kubernetes. Más ágil que la web UI, y una vez que la conoces es la forma más rápida de navegar el cluster.

Rancher: si tienes varios clusters o varios administradores, Rancher añade una capa de gestión multi-cluster. Yo lo uso en el homelab, aunque reconozco que para uso personal es quizás más de lo necesario.

La transición práctica

#

Si estás en Compose y quieres empezar con K8s sin abandonar lo que tienes, el camino menos doloroso es empezar con K3s en una VM de pruebas, sin tocar producción.

Instalar K3s en una sola máquina lleva 5 minutos:

1

curl -sfL https://get.k3s.io | sh -

Después, usa Kompose para convertir tus docker-compose.yml a manifiestos de K8s como punto de partida:

1
2
3
4
5

# Instalar kompose
brew install kompose

# Convertir compose a manifiestos K8s
kompose convert -f docker-compose.yml -o manifiestos/

Los manifiestos generados no serán perfectos (Kompose no añade probes, limits ni recursos), pero son un esqueleto razonable para empezar a aprender sin escribir todo desde cero.

Mi recomendación final

#

Si tienes un servidor, empieza con Compose y no lo cambies hasta que tengas un problema concreto que K8s resuelva. La complejidad tiene que justificarse.

Si tienes dos o más servidores y quieres que funcionen como una unidad, K3s merece la pena. El salto de uno a muchos nodos es donde Kubernetes brilla de verdad.

Y si ya tienes un cluster K8s montado pero la mitad de tus servicios son de “un solo contenedor sin dependencias”, tampoco es obligatorio migrarlo todo. Compose en un servidor secundario para los servicios simples es una solución perfectamente válida.

Lo importante es que la infraestructura te sirva a ti, no al revés. Montar K8s para aprender está bien. Montarlo porque “toca hacerlo” y luego estar batallando con YAML a las 2 de la mañana para levantar Jellyfin, ya no lo está tanto.

¿Tienes dudas sobre si tu setup actual justifica el salto a K8s? Cuéntame en los comentarios cómo tienes montado el homelab y te digo lo que haría yo.