Какие стратегии обновления приложений в Kubernetes ты знаешь?

В Kubernetes существует несколько стратегий развертывания (Deployment Strategies), каждая из которых решает разные задачи по доступности, скорости и безопасности релиза.

1. Rolling Update (Постепенное обновление) — стратегия по умолчанию. Новые Pod'ы постепенно заменяют старые. Кластер гарантирует, что определенное количество Pod'ов всегда доступно. Управляется параметрами maxUnavailable и maxSurge.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%  # Максимум 25% Pod'ов могут быть недоступны во время обновления
      maxSurge: 1          # Допустимо на 1 Pod больше желаемого количества

Плюсы: Минимальный даунтайм, простота использования. Минусы: Нет контроля над версиями, одновременно работают две версии приложения.

2. Recreate (Пересоздание). Все Pod'ы старой версии убиваются, затем создаются Pod'ы новой версии.

spec:
  strategy:
    type: Recreate

Плюсы: Простота, гарантирует работу только одной версии приложения (нет конфликтов схем БД и т.п.). Минусы: Приложение полностью недоступно на время перезапуска.

3. Blue-Green (Сине-зеленое развертывание). Разворачиваются две идентичные среды: "синяя" (текущая, production) и "зеленая" (новая версия). После тестирования "зеленой" среды весь трафик переключается на нее (обычно через Service или Ingress). "Синяя" среда остается на случай быстрого отката (rollback). Реализация в k8s: Два разных Deployment с уникальными лейблами и переключение селектора Service. Плюсы: Мгновенное переключение, простой и быстрый откат. Минусы: Требует двойных ресурсов на время развертывания.

4. Canary (Канареечное развертывание). Новая версия развертывается для небольшого процента пользователей или трафика. Если метрики (латентность, ошибки) в норме, версия постепенно масштабируется на всех. Реализация в k8s: Через два Deployment с разными версиями и весами в Service Mesh (Istio, Linkerd) или с помощью инструментов вроде Flagger и Argo Rollouts.

# Пример с Istio VirtualService (упрощенно)
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  hosts:
  - myapp
  http:
  - route:
    - destination:
        host: myapp
        subset: v1
      weight: 90  # 90% трафика на старую версию
    - destination:
        host: myapp
        subset: v2
      weight: 10  # 10% трафика на новую версию

Плюсы: Минимизация риска, возможность тестирования в production. Минусы: Более сложная настройка и мониторинг.

Выбор стратегии зависит от требований к доступности (SLA), необходимости тестирования в production и сложности инфраструктуры. В моей практике для критичных сервисов мы используем Canary-развертывания с Argo Rollouts, а для внутренних — Rolling Update.