Стратегии развертывания Kubernetes

Одной из самых больших проблем при разработке собственных облачных приложений сегодня является ускорение числа ваших развертываний. Используя микросервисный подход, разработчики уже работают и разрабатывают полностью модульные приложения, которые позволяют нескольким группам одновременно писать и развертывать изменения в приложении.

Более короткие и частые развертывания предлагают следующие преимущества:

Сокращение времени выхода на рынок.
Клиенты могут воспользоваться функциями быстрее.
Отзывы клиентов быстрее возвращаются в группу разработчиков продукта, а это означает, что группа может быстрее перебирать функции и исправлять проблемы.
Более высокий моральный дух разработчика с большим количеством функций в продакшн среде.

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

В этом посте мы обсудим стратегии развертывания Kubernetes, в том числе раскатываемые развертывания (rolling deployments) и более продвинутые методы, такие как canary и его варианты.

Стратегии развертывания

Существует несколько различных типов стратегий развертывания, которые вы можете использовать в зависимости от своей цели. Например, вам может потребоваться развернуть изменения в конкретной среде для дополнительного тестирования или подмножества пользователей/клиентов, или вы можете провести некоторое пользовательское тестирование, прежде чем делать функцию "Общедоступной".

Раскатываемое развертывание (Rolling Deployment)

Раскатываемое развертывание является стандартным развертыванием по умолчанию в Kubernetes. Оно работает медленно, заменяя pod'ы предыдущей версии приложения pod'ами новой версии, один за другим, без какого-либо простоя кластера.

Раскатываемое обновление ожидает готовности новых pod'ов с помощью вашей пробы готовности, прежде чем оно начнет сокращать старые. Если есть проблема, обновление или развертывание может быть прервано без остановки всего кластера. В файле определения YAML для этого типа развертывания новый образ заменяет старый образ.

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
        metadata:
           labels:
             app: awesomeapp
        spec:
          containers:
            - name: awesomeapp
              image: imagerepo-user/awesomeapp:new
              ports:
                - containerPort: 8080

Раскатываемые обновления могут быть дополнительно уточнены путем настройки параметров в файле манифеста:

spec:
  replicas: 3
  strategy:
        type: RollingUpdate
        rollingUpdate:
           maxSurge: 25%
           maxUnavailable: 25%  
  template:
  ...

Пересоздание (Recreate)

В этом типе очень простого развертывания все старые pod'ы уничтожаются одновременно и заменяются новыми сразу.

Манифест выглядит примерно так:

spec:
  replicas: 3
  strategy:
        type: Recreate
  template:
  ...

Синий/Зеленый (Blue/Green) (или Красный/Черный (Red/Black)) развертывания

В стратегии сине-зеленого развертывания (иногда называемого красным/черным) старая версия приложения (зеленая) и новая (синяя) развертываются одновременно. Когда оба они развернуты, пользователи имеют доступ только к зеленому цвету; тогда как синий цвет доступен вашей команде QA для автоматизации тестирования в отдельной службе или через прямую переадресацию портов.

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
        metadata:
           labels:
             app: awesomeapp
             version: "02"

После того, как новая версия была протестирована и готова для релиза, сервис переключается на синюю версию со свертыванием старой зеленой версии:

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

Canary

Canary развертывания похожи на сине-зеленые развертывания, но они более управляемы и используют поэтапный подход "более прогрессивной доставки". Существует ряд стратегий, которые подпадают под действие Canary, включая: темные запуски (dark launches) или A/B-тестирование.

Canary используется, когда вы хотите протестировать некоторые новые функциональные возможности, обычно на бэкэнде вашего приложения. Традиционно у вас могло быть два почти идентичных сервера: один, предназначенный для всех пользователей, и другой, обладающий новыми функциями, которые передаются подгруппе пользователей, а затем сравниваются. Если об ошибках не сообщается, новая версия может постепенно распространяться на остальную часть инфраструктуры.

Хотя эту стратегию можно реализовать, просто используя ресурсы Kubernetes путем замены старых и новых pod'ов, гораздо удобнее и проще реализовать эту стратегию с помощью сервисной сетки, такой как Istio.

Например, вы можете иметь два различных манифеста, отмеченных в Git: GA с тегом 0.1.0 и canary с тегом 0.2.0. Изменяя веса в манифесте виртуального шлюза Istio, можно управлять процентом трафика для обоих этих развертываний.

Темные развертывания (Dark deployments) или A/B развертывания

Темное развертывание - это еще одна разновидность canary. Разница между темным развертыванием и canary заключается в том, что темные развертывания имеют дело с функциями на фронтенде, а не с бэкендом, как в случае с canary.

Другое название для темного развертывания - A/B-тестирование. Вместо того, чтобы запускать новую функцию для всех пользователей, вы можете предоставить ее небольшому кругу пользователей. Пользователи обычно не знают, что их используют в качестве тестеров для новой функции, отсюда и термин "темное" развертывание.

С помощью переключателей функций и других инструментов вы можете отслеживать, как ваш пользователь взаимодействует с новой функцией, и конвертирует ли он ваших пользователей, или они находят новый пользовательский интерфейс непонятным и другие типы метрик.

Поиск по этому блогу

Kubernetes блог