Blue/Green деплоймент в Kubernetes

Решение

1. Blue/Green деплоймент в Kubernetes

Blue/Green — это стратегия развертывания, при которой две идентичные среды (Blue и Green) работают параллельно. Трафик направляется на одну среду, а вторая используется для тестирования новой версии.

2. Структура решения

Blue Deployment (текущая версия)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: myapp
        image: myapp:v1.0.0
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30

Green Deployment (новая версия)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
      - name: myapp
        image: myapp:v1.1.0
        ports:
        - containerPort: 8080

Service для маршрутизации

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
  namespace: default
spec:
  type: ClusterIP
  selector:
    app: myapp
    version: blue
  ports:
  - name: http
    port: 80
    targetPort: 8080

Ingress для внешнего доступа

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

3. Процедура переключения между версиями

Шаг 1: Развертывание Green версии

kubectl apply -f app-green-deployment.yaml

Green Deployment создается и запускается параллельно с Blue.

Шаг 2: Проверка здоровья Green

kubectl wait --for=condition=available --timeout=300s deployment/app-green
kubectl get pods -l version=green
kubectl logs -l version=green -f

Шаг 3: Тестирование Green версии

kubectl port-forward svc/app-green 8080:80 &
curl http://localhost:8080/health
curl http://localhost:8080/api/users
kill %1

Шаг 4: Переключение трафика

kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"green"}}}'

Шаг 5: Мониторинг после переключения

kubectl top pods -l version=green
kubectl logs -l version=green -f

4. Откат в случае проблем

Быстрый откат (за секунды)

kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"blue"}}}'
kubectl get service myapp-service -o jsonpath='{.spec.selector.version}'

Удаление Green Deployment

kubectl delete deployment app-green

5. Проверка работоспособности

Health Check эндпоинты

GET /health -> HTTP 200 {status: alive}
GET /ready -> HTTP 200 {status: ready, db: connected}

Комплексная проверка перед переключением

#!/bin/bash
GREEN_IP=$(kubectl get svc app-green -o jsonpath='{.spec.clusterIP}')
curl -f http://$GREEN_IP/health || exit 1
curl -f http://$GREEN_IP/ready || exit 1
curl -f http://$GREEN_IP/api/users || exit 1
echo "Готово к переключению!"

6. Blue/Green vs Rolling Update

Преимущества Blue/Green

• Мгновенное переключение: Трафик переключается за миллисекунды
• Полная изоляция: Blue остается полностью работоспособной
• Быстрый откат: Откатываемся за одно изменение Service
• Нулевой downtime гарантирован: Оба окружения работают параллельно

Недостатки Blue/Green

• Двойное потребление ресурсов: Нужно в два раза больше CPU/RAM
• Сложность синхронизации БД: Миграции должны быть backward compatible
• Повышенная стоимость: Удвоение инфраструктуры

Преимущества Rolling Update

• Экономия ресурсов: Старые поды удаляются по мере запуска новых
• Простота: Встроена в Kubernetes

Недостатки Rolling Update

• Медленный откат: Если проблема на 50%, откатываемся на 50%
• Downtime на обновления: Хотя обычно минимальное
• Сложность мониторинга: Нужно отслеживать метрики во время переката

7. Рекомендации

• Используйте Blue/Green для критичных сервисов (payments, auth)
• Используйте Rolling Update для менее критичных (UI, кэши)
• Комбинируйте стратегии: Blue/Green между версиями, Rolling Update внутри версии
• Автоматизируйте тестирование: Smoke tests перед переключением
• Настройте мониторинг: Алерты на ошибки и latency в течение 5 минут после переключения
• Используйте feature flags: Для постепенного roll-out функций внутри версии