Что использовал для оркестрации контейнеров?

Оркестрация контейнеров: мой опыт

Оркестрация контейнеров — это управление развёртыванием, масштабированием и обновлением контейнеризированных приложений. Я работал с несколькими решениями, каждое со своими плюсами и минусами.

Docker Swarm (простое начало)

Мой первый опыт с оркестрацией был с Docker Swarm — встроённым инструментом Docker для простого управления несколькими машинами.

Когда использовал: На стартапе с малым числом серверов (3-4 машины), где нужна была простая оркестрация без больших затрат на обучение.

Плюсы:

• Встроен в Docker (простая установка)
• Меньше ресурсов чем Kubernetes
• Быстро разбираются junior разработчики
• Достаточный синтаксис (похож на docker-compose)

# docker-compose для Swarm
version: '3.8'
services:
  web:
    image: myapp:latest
    ports:
      - "80:8000"
    deploy:
      replicas: 3          # Три копии
      placement:
        constraints:
          - node.role == worker  # Только на worker нодах
      update_config:
        parallelism: 1
        delay: 10s
        failure_action: rollback  # Откатываемся при ошибке
      restart_policy:
        condition: on-failure
        max_attempts: 3
    environment:
      - DATABASE_URL=postgresql://db:5432/myapp
  
  db:
    image: postgres:15
    volumes:
      - db_data:/var/lib/postgresql/data
    deploy:
      placement:
        constraints:
          - node.labels.db == true  # На специальных нодах для БД

volumes:
  db_data:
    driver: local

Минусы:

• Не очень масштабируется (> 100 машин problematic)
• Ограниченные возможности сеты (networking)
• Меньше features чем Kubernetes

Когда перешёл дальше: Когда начали расти (15+ серверов) и нужны были более продвинутые фичи.

Kubernetes (production scale)

Это мой основной инструмент на последних двух проектах. Kubernetes — это стандарт де-факто для production оркестрации.

Архитектура Kubernetes:

Kubernetes Cluster
├── Master Nodes (Control Plane)
│   ├── API Server        # REST API для управления
│   ├── Scheduler         # Распределение подов на ноды
│   ├── Controller Manager # Отслеживание состояния
│   └── etcd              # БД для конфигурации
└── Worker Nodes
    ├── kubelet           # Агент на каждой ноде
    ├── kube-proxy        # Сетевой proxy
    └── Container Runtime # Docker, containerd, etc.

Основной ресурс: Pod (не контейнер!)

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
spec:
  containers:
  - name: web
    image: myapp:latest
    ports:
    - containerPort: 8000
    env:
    - name: DATABASE_URL
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: url
    resources:
      requests:
        memory: "256Mi"
        cpu: "100m"
      limits:
        memory: "512Mi"
        cpu: "500m"

Deployment (управление подами):

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: myapp:v1.2.3
        ports:
        - containerPort: 8000
        livenessProbe:          # Жив ли контейнер?
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:         # Готов ли получать трафик?
          httpGet:
            path: /ready
            port: 8000
          initialDelaySeconds: 10
          periodSeconds: 5
        volumeMounts:
        - name: config
          mountPath: /etc/config
      volumes:
      - name: config
        configMap:
          name: app-config
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # На 1 пода больше во время обновления
      maxUnavailable: 0  # Всегда доступны все поды

Service (как найти поды внутри кластера):

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: LoadBalancer  # Или ClusterIP, NodePort
  selector:
    app: web
  ports:
  - protocol: TCP
    port: 80          # Порт сервиса
    targetPort: 8000  # Порт контейнера

ConfigMap и Secrets (для конфигурации):

# ConfigMap для некритичных данных
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_HOST: "db-postgres"
  LOG_LEVEL: "info"
  FEATURE_FLAGS: |
    new_payment_method: true
    beta_feature: false

---
# Secret для чувствительных данных
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:
  url: "postgresql://user:password@db:5432/myapp"

Stateful приложения (например, БД):

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres-service
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15
        env:
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: password
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 100Gi

Как я использовал Kubernetes

1. Развёртывание приложения:

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

# Проверяем статус
kubectl get pods
kubectl describe pod web-pod-xyz

# Смотрим логи
kubectl logs web-pod-xyz
kubectl logs -f web-pod-xyz  # Follow (реал-тайм)

# Заходим в контейнер
kubectl exec -it web-pod-xyz -- bash

2. Обновление приложения (zero-downtime):

# Обновляем image в Deployment
kubectl set image deployment/web-deployment \
  web=myapp:v1.2.4 \
  --record

# Kubernetes автоматически:
# 1. Создаёт новый под с новой версией
# 2. Ждёт readiness probe
# 3. Переводит трафик на новый под
# 4. Убивает старый под
# Всё это без downtime!

# Откатываемся если что-то не так
kubectl rollout undo deployment/web-deployment

3. Масштабирование:

# Manual scaling
kubectl scale deployment web-deployment --replicas=5

# Autoscaling (на основе CPU/Memory)
kubectl autoscale deployment web-deployment \
  --min=2 \
  --max=10 \
  --cpu-percent=80

4. Ingress (как маршрутизировать трафик):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80
  - host: api.myapp.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8000

Мониторинг в Kubernetes

Prometheus + Grafana для метрик:

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app
    image: myapp:latest
    ports:
    - name: metrics
      containerPort: 9090  # Prometheus metrics

ELK Stack для логов:

# Все логи контейнера автоматически собираются через:
kubectl logs pod-name

# Но в production используем ELK:
# - Filebeat собирает логи с каждой ноды
# - Отправляет в Elasticsearch
# - Kibana показывает красивый интерфейс

Сравнение: Docker Swarm vs Kubernetes

Облачные варианты (которые я использовал)

1. AWS EKS (Elastic Kubernetes Service)

# Создание кластера
eksctl create cluster --name my-cluster --region us-east-1 --nodegroup-name standard-nodes --node-type t3.medium --nodes 3

# Развёртывание
kubectl apply -f deployment.yaml

# Автоматический scaling группы нод
kubectl autoscale deployment web --min=2 --max=10

2. Google Cloud GKE (Google Kubernetes Engine)

# Очень удобный managed Kubernetes
gcloud container clusters create my-cluster --zone us-central1-a --num-nodes=3

kubectl apply -f deployment.yaml

3. DigitalOcean DOKS (Kubernetes Service)

Hороший баланс между простотой и ценой.

Альтернативы

Nomad (от HashiCorp) — можно управлять и контейнерами и VM, более гибкий чем Kubernetes

Cloud-specific:

• AWS: ECS (дешевле чем EKS, но less powerful)
• Azure: AKS
• Google Cloud: GKE, Cloud Run (serverless контейнеры)
• Heroku: Для простых приложений без оркестрации

Мой процесс выбора

1. Размер команды:

   • 1-3 разработчика → Docker Compose локально + простой хост (VPS)
   • 4-10 разработчиков → Docker Swarm или managed Kubernetes
   • 10+ разработчиков → Kubernetes (самостоятельный или managed)

2. Сложность приложения:

   • Монолит → Docker Compose достаточно
   • Микросервисы → Kubernetes нужен

3. Требования:

   • High availability → Kubernetes
   • Zero-downtime updates → Kubernetes
   • Простота → Docker Swarm

Вывод

Для production приложений я рекомендую managed Kubernetes (EKS, GKE, AKS) потому что:

• Вы не управляете control plane
• Автоматические обновления
• Интеграция с другими сервисами облака
• Масштабируемость на миллионы запросов

Для разработки и staging достаточно Docker Compose.

Для production самостоятельного Kubernetes нужна специальная команда DevOps инженеров, иначе станет просто болезненно.