Docker Compose vs Kubernetes: где проходит граница

«Нам нужен Kubernetes» — фраза, которую я слышу от команд с пятью микросервисами на одном сервере. И «Docker Compose нам хватит» — от компаний, у которых реально нужна отказоустойчивость. Разберёмся, где проходит реальная граница.

Docker Compose — инструмент для запуска многоконтейнерных приложений на одном хосте. Файл docker-compose.yml описывает все сервисы, сети и тома. Это просто, понятно и работает.

# docker-compose.yml
version: '3.8'
services:
  app:
    image: myapp:latest
    environment:
      - DATABASE_URL=postgresql://db/myapp
    depends_on:
      - db
    restart: unless-stopped

  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=myapp
      - POSTGRES_PASSWORD=secret
    restart: unless-stopped

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    depends_on:
      - app

volumes:
  pgdata:

Запуск: docker compose up -d. Обновление: docker compose pull && docker compose up -d. Всё.

Docker Compose — правильный выбор когда:

• До 10−15 сервисов
• Один сервер
• Нет требований к zero-downtime deployment
• Команда небольшая, DevOps-экспертизы мало
• Пет-проекты, стартапы на ранней стадии, внутренние инструменты

Kubernetes решает задачи, которые Compose не умеет в принципе:

• Multi-node: поды распределяются по нескольким узлам
• Self-healing: упавший под перезапускается автоматически, на живом узле
• Auto-scaling: HPA масштабирует деплойменты по CPU/RAM/custom metrics
• Rolling updates: обновление без даунтайма по умолчанию
• Service discovery и load balancing из коробки

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myapp:latest
          resources:
            requests:
              memory: "256Mi"
              cpu: "250m"
            limits:
              memory: "512Mi"
              cpu: "500m"

Kubernetes нужен когда:

• Несколько серверов (от 3 узлов)
• Требуется HA: недопустимо падение при выходе из строя одного хоста
• Нужен auto-scaling по нагрузке
• Команда растёт и нужна стандартизация деплоев

Если K8s нужен, но полноценный кластер избыточен — смотрите на K3s от Rancher. Это сертифицированный дистрибутив Kubernetes, урезанный до ~70 МБ бинарника.

# Установка K3s за одну команду
curl -sfL https://get.k3s.io | sh -

# Проверка
kubectl get nodes
k3s kubectl get pods --all-namespaces

K3s отлично работает на трёх нодах с 2 ГБ RAM каждая. Встроенный Traefik как ingress controller, встроенный Helm. Хороший вариант для небольших production-кластеров без overhead полноценного kubeadm.

Если вы начали с Compose и выросли до K8s, kompose конвертирует docker-compose.yml в манифесты Kubernetes:

# Установка
curl -L https://github.com/kubernetes/kompose/releases/download/v1.32.0/kompose-linux-amd64 -o kompose
chmod +x kompose

# Конвертация
kompose convert -f docker-compose.yml

# Получим deployment.yaml, service.yaml и т.д.
kubectl apply -f .

Результат kompose — отправная точка, не production-ready манифесты. Нужно добавить resource limits, liveness/readiness probes, настроить ingress. Но базовую работу kompose делает хорошо.

Следующий шаг — Helm charts для параметризации и переиспользования конфигураций.

Видел проекты, где один разработчик тратил две недели на настройку кластера K8s с 3 нодами, ingress, cert-manager, ArgoCD, Vault… для сайта с 50 посетителями в день. Это классический over-engineering.

Kubernetes добавляет реальную сложность: нужно понимать etcd, сетевые плагины (Calico, Flannel), хранилище (CSI драйверы), RBAC, операторы. Для команды из одного человека это overhead, не ценность.

Правило большого пальца: если ваш сервис помещается в docker-compose.yml на 50 строк и у вас нет требований к HA — не трогайте K8s. Добавляйте сложность только под реальную потребность.

Начинайте с Compose. Переходите на K3s когда нужна HA. Переходите на полноценный K8s когда команда и нагрузка оправдывают операционные затраты.