Хабрахабр

[Перевод] Стратегии деплоя в Kubernetes: rolling, recreate, blue/green, canary, dark (A/B-тестирование)

Прим. перев.: Этот обзорный материал от Weaveworks знакомит с наиболее популярными стратегиями выката приложений и рассказывает о возможности реализации наиболее продвинутых из них с помощью Kubernetes-оператора Flagger. Он написан простым языком и содержит наглядные схемы, позволяющие разобраться в вопросе даже начинающим инженерам.


Схема взята из другого обзора стратегий выката, сделанного в Container Solutions

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

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

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

Но с увеличением частоты релизов также повышаются шансы негативно повлиять на надежность приложения или пользовательский опыт. Именно поэтому командам эксплуатации и DevOps важно строить процессы и управлять стратегиями развертывания таким образом, чтобы минимизировать риск для продукта и пользователей. (Узнать больше об автоматизации CI/CD-пайплайна можно здесь.)

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

Стратегии деплоя

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

Rolling (постепенный, «накатываемый» деплой)

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

Если возникает проблема, подобное накатываемое обновление можно прервать, не останавливая всего кластера. Kubernetes дожидается готовности новых pod'ов к работе (проверяя их с помощью readiness-тестов), прежде чем приступить к сворачиванию старых. В YAML-файле с описанием типа deployment'а новый образ заменяет собой старый образ:

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 (канареечные развертывания)

Канареечные выкаты похожи на сине-зеленые, но лучше управляются и используют прогрессивный поэтапный подход. К этому типу относятся несколько различных стратегий, включая «скрытые» запуски и А/В-тестирование.

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

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

1. Например, у вас может быть два различных манифеста в Git: обычный с тегом 0. 2. 0 и «канареечный» с тегом 0. Изменяя веса в манифесте виртуального шлюза Istio, можно управлять распределением трафика между этими двумя deployment'ами: 0.

(Прим. Пошаговое руководство по реализации канареечных развертываний с помощью Istio можно найти в материале GitOps Workflows with Istio. перев.: Мы также переводили материал про канареечные выкаты в Istio здесь.)

Канареечные развертывания с Weaveworks Flagger

Weaveworks Flagger позволяет легко и эффективно управлять канареечными выкатами.

Он использует Istio или AWS App Mesh для маршрутизации и переключения трафика, а также метрики Prometheus для анализа результатов. Flagger автоматизирует работу с ними. Кроме того, анализ канареечных развертываний можно дополнить вебхуками для проведения приемочных (acceptance) тестов, нагрузочных и любых других типов проверок.

На основе deployment'а Kubernetes и, при необходимости, горизонтального масштабирования pod'ов (HPA), Flagger создает наборы из объектов (deployment'ы Kubernetes, сервисы ClusterIP и виртуальные сервисы Istio или App Mesh) для проведения анализа и реализации канареечных развертываний:

Основываясь на анализе KPI (ключевых показателей эффективности), канареечная часть либо растет, либо сворачивается, и результаты анализа публикуются в Slack. Реализуя контур управления (control loop), Flagger постепенно переключает трафик на канареечный сервер, параллельно измеряя ключевые показатели производительности, такие как доля успешных HTTP-запросов, средняя продолжительность запроса и здоровье pod'ов. Описание и демонстрацию этого процесса можно найти в материале Progressive Delivery for App Mesh.

Dark (скрытые) или А/В-развертывания

Скрытое развертывание — еще одна вариация канареечной стратегии (с ней, кстати, Flagger тоже может работать). Разница между скрытым и канареечным развертыванием состоит в том, что скрытые развертывания имеют дело с фронтендом, а не с бэкендом, как канареечные.

Вместо того, чтобы открыть доступ к новой функции всем пользователям, ее предлагают лишь ограниченной их части. Другое название этих развертываний — А/В-тестирование. Обычно эти пользователи не знают, что выступают тестерами-первопроходцами (отсюда и термин «скрытое развертывание»).

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

Flagger и A/B-развертывания

Помимо маршрутизации с учётом весов, Flagger также может направлять на канареечный сервер трафик в зависимости от параметров HTTP. При А/В-тестировании можно использовать заголовки HTTP или файлы cookie для перенаправления определенного сегмента пользователей. Это особенно эффективно в случае frontend-приложений, требующих привязки сессии к серверу (session affinity). Дополнительную информацию можно найти в документации Flagger.

Автор выражает благодарность Stefan Prodan, инженеру Weaveworks (и создателю Flagger), за все эти потрясающие схемы деплоя.

P.S. от переводчика

Читайте также в нашем блоге:

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть