Что знаешь про стратегии обновлений в Kubernetes?

В Kubernetes я применяю различные стратегии развертывания, чтобы обеспечить бесперебойную работу сервисов во время обновлений. Выбор стратегии зависит от требований к доступности и допустимого риска.

Основные стратегии, которые я использовал:

1. RollingUpdate (Стандартная в Deployment): Kubernetes постепенно обновляет поды новыми, пока старые не будут заменены. Я настраиваю параметры maxUnavailable и maxSurge для контроля скорости и доступности.

   apiVersion: apps/v1
   kind: Deployment
   spec:
     strategy:
       type: RollingUpdate
       rollingUpdate:
         maxUnavailable: 25%  # Допустимо недоступно 25% подов
         maxSurge: 1          # Одновременно может быть на 1 под больше желаемого количества

2. Blue-Green: Разворачиваю новую версию (Green) параллельно со старой (Blue) в отдельном Deployment или с новыми метками. После тестирования переключаю трафик, обновляя селектор сервиса (Service selector). Это позволяет мгновенному откату.

3. Canary: Разворачиваю новую версию для небольшого процента пользователей. В Kubernetes это можно реализовать, направив часть трафика через манифест Service с несколькими селекторами или используя Ingress-контроллеры с аннотациями весов (например, NGINX Ingress). После успешной проверки метрик постепенно увеличиваю долю трафика.

4. Recreate: Использую стратегию type: Recreate в Deployment, когда приложение не поддерживает работу двух версий одновременно (например, из-за миграций схемы БД). Все старые поды убиваются перед созданием новых, что приводит к простою, но гарантирует целостность.