Когда переходить на Kubernetes

Docker Compose отлично работает для разработки и небольших проектов. Но в какой-то момент его перестаёт хватать. Разберём, когда пора переходить на Kubernetes и что это даёт.

Эволюция: Compose → Swarm → K8s

Инструмент	Для чего	Ограничения
Docker Compose	Локальная разработка, простой деплой на один сервер	Один хост, нет автоскейлинга, ручной restart при падении
Docker Swarm	Простая оркестрация на несколько хостов	Ограниченная экосистема, меньше фич чем K8s, развивается значительно медленнее
Kubernetes	Production оркестрация любого масштаба	Сложность, требует обучения и поддержки

Когда нужен Kubernetes

Оставайтесь на Compose, если:

• Один сервер справляется с нагрузкой
• Downtime в несколько минут при деплое приемлем
• Команда маленькая, нет DevOps экспертизы
• Бюджет ограничен (K8s требует минимум 3 ноды для HA)

Переходите на Kubernetes, когда:

• Нужна высокая доступность — автоматический restart, распределение по нодам
• Горизонтальное масштабирование — автоскейлинг по CPU/memory/custom metrics
• Zero-downtime deployments — rolling updates, canary releases
• Несколько окружений — dev/staging/prod с одинаковой конфигурацией
• Микросервисы — service discovery, load balancing из коробки
• Команда растёт — нужны namespaces, RBAC, изоляция

Ключевые концепции

Kubernetes решает те же задачи, что и Compose, но с другими абстракциями:

Docker Compose	Kubernetes	Что добавляет K8s
services:	Deployment + Service	Реплики, rolling updates, health checks, load balancing
volumes:	PersistentVolumeClaim	Динамическое выделение, разные storage классы (SSD/HDD)
environment:	ConfigMap / Secret	Централизованное управление, hot reload
ports:	Service + Ingress	L4/L7 балансировка, TLS termination, routing по URL
depends_on:	Init containers / Probes	Readiness/liveness проверки, graceful shutdown
—	HorizontalPodAutoscaler	Автоматическое масштабирование по метрикам
—	Namespace + RBAC	Изоляция окружений, контроль доступа

Минимальный набор для старта

# deployment.yaml — описание приложения
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app:v1.0.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "500m"
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
---
# service.yaml — сетевой доступ
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080
---
# ingress.yaml — внешний доступ
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app
            port:
              number: 80

Как начать

Локальная разработка

Инструмент	Описание	Когда использовать
Docker Desktop	Встроенный K8s, один клик	Быстрый старт на Mac/Windows
minikube	Легковесный кластер в VM	Больше контроля, аддоны
kind	K8s в Docker контейнерах	CI/CD, тестирование
k3s	Облегчённый K8s	Edge, IoT, ограниченные ресурсы

# Быстрый старт с minikube
brew install minikube
minikube start

# Применить конфигурацию
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

# Проверить статус
kubectl get pods
kubectl get services

# Логи
kubectl logs -f deployment/my-app

Production

• Managed K8s: EKS (AWS), GKE (Google), AKS (Azure) — меньше операционной нагрузки
• Self-hosted: kubeadm, Rancher, OpenShift — полный контроль, больше работы

Миграция с Compose

Инструменты конвертации

# Kompose — конвертирует docker-compose.yml в K8s манифесты
brew install kompose
kompose convert -f docker-compose.yml

# Результат: deployment.yaml, service.yaml для каждого сервиса

Управление конфигурациями: Helm

По мере роста количества манифестов стоит рассмотреть Helm — пакетный менеджер для Kubernetes. Helm позволяет:

• Шаблонизировать манифесты — один chart для dev/staging/prod с разными values
• Версионировать конфигурации — откат к предыдущей версии одной командой
• Переиспользовать общие паттерны через публичные charts (PostgreSQL, Redis, Nginx)

# Установить PostgreSQL из публичного chart
helm install my-db bitnami/postgresql --set auth.postgresPassword=secret

# Обновить конфигурацию
helm upgrade my-db bitnami/postgresql --set primary.resources.limits.memory=1Gi

# Откатить к предыдущей версии
helm rollback my-db 1

Чеклист миграции

1. Health checks — добавьте readiness и liveness probes
2. Resource limits — без них один под может съесть все ресурсы ноды
3. Secrets — не храните в git, используйте Sealed Secrets или External Secrets
4. Persistent storage — убедитесь, что StorageClass поддерживает ваши требования
5. Logging — настройте централизованный сбор логов (stdout → Loki/ELK)
6. Monitoring — Prometheus + Grafana для метрик

Что оставить на Compose

Не всё нужно мигрировать. Compose по-прежнему хорош для:

• Локальной разработки (быстрее запустить, чем K8s)
• CI/CD для интеграционных тестов
• Простых внутренних инструментов