Знакомство с Kubernetes. Часть 5: Развертывания (Deployments)
May 28, 2018 07:33 · 1495 words · 8 minute read kubernetes deployments
Контроллер развертывания (Deployment controller) предоставляет возможность декларативного обновления для объектов типа поды ( Pods ) и наборы реплик ( ReplicaSets ). Давайте разберемся!
При стратегии обновления RollingUpdate поды будут обновляться плавно, по очереди (дополнительно контролировать этот процесс можно с помощью параметров maxUnavailable и maxSurge ).
Ниже представлен пример развертывания ( Deployment ):
Сохраним данный манифест в файл nginx-deployment.yaml и запустим его в кластере Kubernetes с помощью команды:
Когда вы с помощью данной команды хотите получить состояние развертываний ( Deployments ) в кластере, вам доступны следующие поля:
Через несколько секунд (нужно ведь подождать, пока скачается docker-образ) еще раз проверяем состояние развертываний в кластере с помощью kubectl get deployments :
Для обновления развертывания (например, изменения версии docker-образа на 1.9.1) можно воспользоваться такой командой:
Как видим, новый (ориентируемся по времени) набор реплик ( ReplicaSet ) находится в желаемом состоянии, в то время как в старом наборе количество экземпляров пода равно нулю.
Детальное описание развертывания получаем командой kubectl describe deployments :
Обновление застопорится (ожидаемо, ведь такого docker-образа нет):
Состояние набора реплик будет выглядеть примерно так:
Состояние подов будет таким:
Для возврата на предыдущую (работоспособную) версию развертывания необходимо сначала проверить историю изменений (узнать номер ревизии):
Для отката на предыдущую ревизию достаточно выполнить такую команду:
Для масштабирования (увеличения/уменьшения количества подов) можно использовать команду:
На этом все, еще больше информации можно найти в официальной документации по Kubernetes, а в следующей статье мы поговорим об уборке мусора.
Руководство по Kubernetes, часть 2: создание кластера и работа с ним
В прошлый раз мы рассмотрели два подхода к работе с микросервисами. В частности, один из них подразумевает применение контейнеров Docker, в которых можно выполнять код микросервисов и вспомогательных программ. Сегодня же мы, используя уже имеющиеся у нас образы контейнеров, займёмся работой с Kubernetes.
Знакомство с Kubernetes
Я обещаю, и при этом ничуть не преувеличиваю, что вы, когда дочитаете эту статью, спросите себя: «А почему Kubernetes не называют Supernetes?».
Если вы читали предыдущую часть этого материала, то вы знаете, что там мы разобрали множество вещей, касающихся подготовки приложений к контейнеризации и работы с контейнерами Docker. Вам может показаться, что сейчас вас ждёт самое сложное, но, на самом деле, то, о чём мы будем здесь говорить, гораздо проще того, с чем мы уже разобрались. Единственной причиной, по которой изучение Kubernetes может показаться кому-то весьма сложной задачей, заключается в том объёме дополнительных сведений, которым нужно обладать для понимания Kubernetes и для эффективного использования этой системы. Мы же все необходимые для успешного освоения Kubernetes «дополнительные сведения» уже обсудили.
▍Что такое Kubernetes?
В первой части этого материала, после запуска микросервисов в контейнерах, вам было предложено подумать над вопросом о масштабировании контейнеризированных приложений.
Предлагаю поразмышлять над ним вместе, в формате вопросов и ответов:
Вопрос: Как масштабируют контейнеризированные приложения?
Ответ: Запускают дополнительные контейнеры.
Вопрос: А как между ними распределяют нагрузку? Что если некий сервер уже используется по максимуму, и контейнер нужно развернуть на другом сервере? Как найти наиболее эффективный способ использования аппаратного обеспечения?
Ответ: Так… Поищу-ка в интернете…
Вопрос: Как обновлять программы не нарушая работоспособность системы? И, если обновление содержит ошибку, как вернуться к рабочей версии приложения?
На самом деле, достойные ответы на эти и на многие другие вопросы позволяет дать именно технология Kubernetes. Попытаюсь ужать определение Kubernetes до одного предложения: «Kubernetes — это система управления контейнерами, которая абстрагирует базовую инфраструктуру (среду, в которой выполняются контейнеры)».
Полагаю, что сейчас вы не особенно ясно представляете себе понятие «управление контейнерами», хотя об этом мы уже упоминали. Ниже мы рассмотрим эту технологию на практике. Однако понятие «абстрагирование базовой инфраструктуры» нам встречается впервые. Поэтому сейчас мы рассмотрим именно его.
▍Абстрагирование базовой инфраструктуры
Kubernetes позволяет приложениям абстрагироваться от инфраструктуры, давая нам простое API, к которому можно отправлять запросы. Эти запросы Kubernetes старается выполнить, используя все свои возможности. Например, на обычном языке подобный запрос можно описать так: «Kubernetes, разверни 4 контейнера образа X». Получив команду, Kubernetes найдёт не слишком загруженные узлы (их ещё называют «нодами» — от английского «node»), на которых можно развернуть новые контейнеры.
Запрос к API-серверу
Что это означает для разработчика? Это означает, что ему не нужно заботиться о количестве узлов, о том, где именно запускаются контейнеры, о том, как они взаимодействуют. Ему не приходится иметь дело с оптимизацией аппаратного обеспечения или беспокоиться об узлах, работа которых может быть нарушена (а нечто подобное, согласно закону Мёрфи, обязательно произойдёт), так как, при необходимости, в кластер Kubernetes можно добавлять новые узлы. Если с некими существующими узлами что-то не так, Kubernetes развернёт контейнеры на тех узлах, которые ещё находятся в работоспособном состоянии.
Многое из того, что изображено на предыдущем рисунке, вам уже знакомо. Но есть там и кое-что новое:
Мы пока на этом остановимся, так как обо всём этом мы можем поговорить и далее, и, к тому же, есть множество хороших материалов, касающихся теории Kubernetes. Например, это официальная документация, хотя читать её и непросто, или книги, наподобие этой.
▍Стандартизация работы с провайдерами облачных услуг
Ещё одна сильная сторона Kubernetes заключается в том, что эта технология способствует стандартизации работы с провайдерами облачных услуг (Cloud Service Provider, CSP). Это — смелое заявление. Рассмотрим следующий пример. Специалисту, хорошо знающему Azure или Google Cloud Platform, приходится работать над проектом, рассчитанным на совершенно новую для него облачную среду, с которой он незнаком. В такой ситуации многое может пойти не так. Например, могут быть сорваны сроки сдачи проекта, компании-заказчику проекта может понадобиться арендовать больше облачных ресурсов, чем планировалось, и так далее.
При использовании Kubernetes подобная проблема возникнуть просто не может, так как, вне зависимости от того, о каком именно провайдере облачных услуг идёт речь, работа с Kubernetes всегда выглядит одинаково. Разработчик, в декларативном стиле, сообщает API-серверу о том, что ему нужно, а Kubernetes работает с ресурсами системы, позволяя разработчику абстрагироваться от деталей реализации этой системы.
Задержитесь немного на этой идее, так как это — очень сильная возможность Kubernetes. Для компаний это означает, что их решения не привязываются к конкретному CSP. Если компания находит на рынке облачных услуг более выгодное предложение, она свободно может этим предложением воспользоваться, перейдя к новому провайдеру. При этом опыт, наработанный специалистами компании, никуда не теряется.
Теперь поговорим о практическом использовании Kubernetes
Практика работы с Kubernetes: поды
Мы настроили запуск микросервисов в контейнерах, процесс настройки был довольно-таки утомительным, но нам удалось выйти на работающую систему. Кроме того, как уже говорилось, наше решение плохо масштабируется и не отличается устойчивостью к сбоям. Эти проблемы мы решим с помощью Kubernetes. Далее мы приведём нашу систему к виду, соответствующему следующей схеме. А именно, контейнерами будет управлять Kubernetes.
Микросервисы работаю в кластере, управляемом Kubernetes
Здесь мы, для локального развёртывания кластера и для испытания возможностей Kubernetes, будем использовать Minikube, хотя всё то, чем мы тут будем заниматься, можно сделать и средствами облачных платформ, таких, как Azure или Google Cloud Platform.
▍Установка и запуск Minikube
Для установки Minikube следуйте указаниям, которые можно найти в документации. В процессе установки Minikube вы также установите Kubectl. Это — клиент, который позволяет выполнять запросы к API-серверу Kubernetes.
Minikube даёт в наше распоряжение кластер, который состоит лишь из одного узла. Правда, нас это вполне устраивает. Тому, кто работает с Kubernetes, не нужно заботиться о том, сколько именно узлов присутствует в кластере, так как Kubernetes позволяет абстрагироваться от подобных деталей.
Теперь поговорим о подах.
Мне очень нравятся контейнеры, и вам они тоже теперь, наверняка, нравятся. Почему же Kubernetes предлагает нам пользоваться подами, сущностями, являющимися в этой системе минимальными развёртываемыми вычислительными единицами? Какие именно функции выполняет под? Дело в том, что в состав пода могут входить один или несколько контейнеров, которые совместно используют одну и ту же среду выполнения.
Но обязательно ли выполнять, например, два контейнера в одном поде? Как сказать… Обычно на один под приходится лишь один контейнер, и именно так собираемся поступать и мы. Но для тех случаев, когда, например, двум контейнерам нужен общий доступ к одному и тому же хранилищу данных, или если между ними налажена связь с использованием техники межпроцессного взаимодействия, или если они тесно связаны по какой-то другой причине, всё это можно реализовать, запустив их в одном поде. Ещё одна возможность, которой отличаются поды, заключается в том, что в них необязательно использовать контейнеры Docker. Если нужно, тут можно применить и другие технологии контейнеризации приложений, например — Rkt.
На следующей схеме показаны пронумерованные свойства подов.
Рассмотрим эти свойства.
Нам того, что уже сказано о подах, достаточно для того, чтобы продолжать осваивать Kubernetes. Подробнее почитать о них можно здесь.
▍Описание пода
Поясним некоторые заданные в нём параметры.
▍Создание пода SA-Frontend
Для того чтобы выяснить, работает ли под, выполните следующую команду:
▍Доступ к приложению извне
▍Неправильный подход к масштабированию
Создадим новый под:
Убедимся в том, что он запущен:
Теперь у нас два пода! Правда, радоваться тут особо нечему. Обратите внимание на то, что в показанном здесь решении задачи масштабирования приложения множество недостатков. О том, как это сделать правильно, мы поговорим в разделе, посвящённом ещё одному ресурсу Kubernetes, который называется Deployment (развёртывание).
Рассмотрим теперь то, что у нас получилось после запуска двух одинаковых подов. А именно, веб-сервер Nginx теперь выполняется в двух разных подах. В этой связи мы можем задаться двумя вопросами:
Неправильный подход к масштабированию
Среди средств Kubernetes есть ресурсы вида Service (сервис). Поговорим о них.
Практика работы с Kubernetes: сервисы
Сервисы Kubernetes играют роль точек доступа к наборам подов, которые предоставляют тот же функционал, что и эти поды. Сервисы выполняют решение непростых задач по работе с подами и по балансировке нагрузки между ними.
Сервис Kubernetes обслуживает IP-адреса
В нашем кластере Kubernetes будут поды, реализующие разные функции. Это — фронтенд-приложение, веб-приложение Spring и Flask-приложение, написанное на Python. Тут возникает вопрос о том, как сервису понять, с какими именно подами ему нужно работать, то есть — как узнать о том, на основе каких сведений система должна генерировать список конечных точек для подов.
Делается это с помощью ещё одной абстракции Kubernetes, которая называется Label (метка). Работа с метками состоит из двух этапов:
Поды с метками и их файлы-манифесты
Мы видим тут два пода, которым, с использованием конструкции app: sa-frontend назначены одинаковые метки. Сервис интересуют поды именно с такими метками.
▍Метки
Метки дают разработчику простой способ организации ресурсов Kubernetes. Они представляют собой пары вида ключ-значение, назначать их можно любым ресурсам. Модифицируйте файлы описания подов фронтенд-приложения и приведите их к виду, показанному на предыдущем рисунке. После этого сохраните эти файлы и выполните следующие команды:
Балансировка нагрузки с помощью сервиса типа LoadBalancer
▍Описание сервиса
Вот YAML-описание сервиса типа LoadBalancer :
Поясним этот текст:
Проверить состояние сервиса можно так:
Тут можно заметить, что свойство EXTERNAL-IP находится в состоянии
, при этом можно не ждать его изменения. Происходит это из-за того, что мы используем Minikube. Если бы мы создали подобный сервис, работая с неким провайдером облачных услуг, вроде Azure или Google Cloud Platform, тогда у сервиса был бы общедоступный IP-адрес, который дал бы возможность обращаться к нему из интернета.
Несмотря на это Minikube не позволит нам бездельничать, давая в наше распоряжение полезную команду для локальной отладки системы:
Благодаря этой команде будет запущен браузер, который обратится к сервису. После того, как сервис получит запрос, он перенаправит его к одному из подов (при этом неважно — какой именно это будет под). Эта абстракция позволяет нам воспринимать группу подов как единую сущность и работать с ними, используя сервис как единую точку доступа к ним.
Практика работы с Kubernetes: развёртывания
Развёртывание (Deployment) — это абстракция Kubernetes, которая позволяют нам управлять тем, что всегда присутствует в жизненном цикле приложения. Речь идёт об управлении изменениями приложений. Приложения, которые не изменяются, это, так сказать, «мёртвые» приложения. Если же приложение «живёт», то можно столкнуться с тем, что периодически изменяются требования к нему, расширяется его код, этот код упаковывается и разворачивается. При этом на каждом шаге данного процесса могут совершаться ошибки.
Ресурс вида Deployment позволяет автоматизировать процесс перехода от одной версии приложения к другой. Это делается без прерывания работы системы, а если в ходе этого процесса произойдёт ошибка, у нас будет возможность быстро вернуться к предыдущей, рабочей версии приложения.
▍Использование развёртываний
Сейчас в кластере имеется два пода и сервис, дающий доступ к ним извне и балансирующий нагрузку на них.
Текущее состояние кластера
Мы говорили о том, что запуск двух разных подов с одинаковым функционалом — это не лучшая идея. При использовании такой схемы нам приходится работать с каждым подом в индивидуальном порядке, создавая, обновляя, удаляя каждый конкретный под, наблюдая за его состоянием. При таком подходе не приходится говорить о быстром обновлении системы или об оперативном откате неудачного обновления. Нас такое положение дел не устраивает, поэтому мы собираемся прибегнуть к возможность ресурса Deployment, который направлен на решение вышеозначенных проблем.
Прежде чем мы продолжим работу, давайте сформулируем её цели, что даст нам ориентиры, которые пригодятся при разборе файла-манифеста развёртывания. Итак, вот что нам нужно:
▍Описание развёртывания
Вот YAML-описание ресурса вида Deployment, которое создано с учётом вышеописанных требований к системе:
Разберём это описание:
Проверим состояние системы:
Как видно, теперь у нас есть 4 пода. Два из них созданы с помощью ресурса Deployment, ещё два — это те, которые мы создавали самостоятельно. Теперь можно удалить те поды, что мы создавали сами, воспользовавшись командами следующего вида:
Кстати, вот вам задание для самостоятельной работы. Удалите один из подов, созданных с помощью ресурса Deployment, и понаблюдайте за системой. Подумайте о причинах происходящего прежде чем читать дальше.
При удалении одного пода ресурс Deployment узнаёт о том, что текущее состояние системы (1 под) отличается от желаемого (2 пода), поэтому производится запуск ещё одного пода.
В чём же заключается польза ресурсов Deployment, помимо того, что при их использовании система поддерживается в нужном состоянии? Рассмотрим сильные стороны этих ресурсов.
▍Выполнение развёртываний с нулевым временем простоя системы
Проверим состояние системы следующей командой:
В соответствии с данными, выведенными в ответ на эту команду, мы можем сделать вывод о том, что развёртывание обновления прошло успешно. В ходе обновления старые реплики, по одной, заменялись на новые. Это означает, что наше приложение, в ходе процесса обновления, всегда было доступно. Прежде чем мы продолжим работу, давайте убедимся в том, что приложений действительно обновилось.
Проверка развёртывания
Для того чтобы взглянуть на то, как приложение выглядит в браузере, воспользуемся уже известной вам командой:
В ответ на неё будет запущен браузер, а в нём откроется страница приложения.
Как видно, кнопка и правда стала зелёной, значит — обновление системы действительно удалось.
Закулисье обновления системы по схеме RollingUpdate
Замена подов в ходе обновления системы
Теперь поговорим об ещё одной сильной стороне ресурсов Deployment. Для того чтобы было интересней, добавим повествованию драматизма. Вот рассказ про ошибку в продакшне.
▍Откат к предыдущему состоянию системы
Менеджер по продукту, сгорая от волнения, влетает в офис. «Баг! В продакшне! Верните всё как было!», — кричит он. Но его беспокойство не заражает вас нездоровым энтузиазмом. Вы, не теряя хладнокровия, открываете терминал и вводите следующую команду:
Вы смотрите на ранее выполненные развёртывания и спрашиваете у менеджера: «Так, свежая версия даёт сбои, но предыдущая работала отлично?».
«Да. Вы что, меня не слышали?», — продолжает надрываться менеджер.
Вы же, не обращая внимания на очередную его попытку вас растревожить, просто вводите в терминале следующее:
После этого вы открываете страницу приложения. Зелёная кнопка исчезла, а вместе с ней и ошибки.
Менеджер застывает с отвисшей от удивления челюстью.
Вы только что спасли компанию от катастрофы.
На самом деле, скучновато получилось. До существования Kubernetes в подобных рассказах было куда больше неожиданных поворотов сюжета, больше действия, и они так быстро не заканчивались. Эх, старые добрые времена!
В следующем разделе мы воспользуемся всем тем, что уже изучили, для того, чтобы выйти на полноценно работающее приложение.
Практика работы с Kubernetes: совместное использование изученных механизмов
Мы уже разобрались с ресурсами Kubernetes, необходимыми нам для того, чтобы построить полноценное кластерное приложение. На следующем рисунке выделено всё то, что нам ещё нужно сделать.
Текущее состояние приложение
Начнём работу с нижней части этой схемы.
▍Развёртывание подов sa-logic
Перейдите с помощью терминала в папку проекта resource-manifests и выполните следующую команду:
▍Сервис sa-logic
Выполним следующую команду:
Теперь посмотрим на то, как изменилось состояние приложения после выполнения этой команды.
Изменённое состояние приложения
▍Развёртывание подов sa-webapp
Для того чтобы ответить на этот вопрос нам нужно познакомиться с концепцией kube-dns.
▍DNS-сервер кластера Kubernetes
▍Развёртывание подов sa-webapp
Выполните следующую команду:
▍Сервис sa-webapp
Исправление этого недостатка даст нам возможность быстро пробежаться по всему тому, изучением чего мы тут занимались. Кстати, если хотите извлечь из проработки этого материала максимум эффективности — вы можете, не читая пока дальше, попытаться исправить этот недостаток самостоятельно.
Собственно говоря, вот как выглядит пошаговое решение данной проблемы:
Готовое кластерное приложение
Итоги
Использование технологии Kubernetes способно принести пользу командам разработчиков, это благотворно сказывается на работе над различными проектами, упрощает развёртывание приложений, помогает их масштабировать, делает их устойчивыми к сбоям. Благодаря Kubernetes можно пользоваться ресурсами, предоставляемыми самыми разными облачными провайдерами, и при этом не зависеть от решений конкретных поставщиков облачных услуг. Поэтому предлагаю переименовать Kubernetes в Supernetes.
Вот что вы узнали, освоив этот материал:
Уважаемые читатели! Пользуетесь ли вы Kubernetes?
Стратегии деплоя в Kubernetes: rolling, recreate, blue/green, canary, dark (A/B-тестирование)
Прим. перев.: Этот обзорный материал от Weaveworks знакомит с наиболее популярными стратегиями выката приложений и рассказывает о возможности реализации наиболее продвинутых из них с помощью Kubernetes-оператора Flagger. Он написан простым языком и содержит наглядные схемы, позволяющие разобраться в вопросе даже начинающим инженерам.
Схема взята из другого обзора стратегий выката, сделанного в Container Solutions
Одной из самых больших проблем при разработке cloud native-приложений сегодня является ускорение деплоя. При микросервисном подходе разработчики уже работают с полностью модульными приложениями и проектируют их, позволяя различным командам одновременно писать код и вносить изменения в приложение.
Более короткие и частые развертывания имеют следующие преимущества:
В этой публикации мы обсудим различные стратегии деплоя в Kubernetes, в том числе rolling-развертывания и более продвинутые методы, такие как канареечные (canary) выкаты и их разновидности.
Стратегии деплоя
Существует несколько различных типов стратегий развертывания, коими можно воспользоваться в зависимости от цели. Например, вам может потребоваться внести изменения в некое окружение для дальнейшего тестирования, или в подмножество пользователей/клиентов, или возникнет необходимость провести ограниченное тестирование на пользователях, прежде чем сделать некую функцию общедоступной.
Rolling (постепенный, «накатываемый» деплой)
Это стандартная стратегия развертывания в Kubernetes. Она постепенно, один за другим, заменяет pod’ы со старой версией приложения на pod’ы с новой версией — без простоя кластера.
Kubernetes дожидается готовности новых pod’ов к работе (проверяя их с помощью readiness-тестов), прежде чем приступить к сворачиванию старых. Если возникает проблема, подобное накатываемое обновление можно прервать, не останавливая всего кластера. В YAML-файле с описанием типа deployment’а новый образ заменяет собой старый образ:
Параметры накатываемого обновления можно уточнить в файле манифеста:
Recreate (повторное создание)
В этом простейшем типе развертывания старые pod’ы убиваются все разом и заменяются новыми:
Соответствующий манифест выглядит примерно так:
Blue/Green (сине-зеленые развертывания)
Стратегия сине-зеленого развертывания (иногда ее ещё называют red/black, т.е. красно-чёрной) предусматривает одновременное развертывание старой (зеленой) и новой (синей) версий приложения. После размещения обеих версий обычные пользователи получают доступ к зеленой, в то время как синяя доступна для QA-команды для автоматизации тестов через отдельный сервис или прямой проброс портов:
После того, как синяя (новая) версия была протестирована и был одобрен ее релиз, сервис переключается на неё, а зеленая (старая) сворачивается:
Canary (канареечные развертывания)
Канареечные выкаты похожи на сине-зеленые, но лучше управляются и используют прогрессивный поэтапный подход. К этому типу относятся несколько различных стратегий, включая «скрытые» запуски и А/В-тестирование.
Эта стратегия применяется, когда необходимо испытать некую новую функциональность, как правило, в бэкенде приложения. Суть подхода в том, чтобы создать два практически одинаковых сервера: один обслуживает почти всех пользователей, а другой, с новыми функциями, обслуживает лишь небольшую подгруппу пользователей, после чего результаты их работы сравниваются. Если все проходит без ошибок, новая версия постепенно выкатывается на всю инфраструктуру.
Хотя данную стратегию можно реализовать исключительно средствами Kubernetes, заменяя старые pod’ы на новые, гораздо удобнее и проще использовать service mesh вроде Istio.
Например, у вас может быть два различных манифеста в Git: обычный с тегом 0.1.0 и «канареечный» с тегом 0.2.0. Изменяя веса в манифесте виртуального шлюза Istio, можно управлять распределением трафика между этими двумя deployment’ами:
Пошаговое руководство по реализации канареечных развертываний с помощью Istio можно найти в материале GitOps Workflows with Istio. (Прим. перев.: Мы также переводили материал про канареечные выкаты в Istio здесь.)
Канареечные развертывания с Weaveworks Flagger
Weaveworks Flagger позволяет легко и эффективно управлять канареечными выкатами.
Flagger автоматизирует работу с ними. Он использует Istio или AWS App Mesh для маршрутизации и переключения трафика, а также метрики Prometheus для анализа результатов. Кроме того, анализ канареечных развертываний можно дополнить вебхуками для проведения приемочных (acceptance) тестов, нагрузочных и любых других типов проверок.
На основе deployment’а Kubernetes и, при необходимости, горизонтального масштабирования pod’ов (HPA), Flagger создает наборы из объектов (deployment’ы Kubernetes, сервисы ClusterIP и виртуальные сервисы Istio или App Mesh) для проведения анализа и реализации канареечных развертываний:
Реализуя контур управления (control loop), Flagger постепенно переключает трафик на канареечный сервер, параллельно измеряя ключевые показатели производительности, такие как доля успешных HTTP-запросов, средняя продолжительность запроса и здоровье pod’ов. Основываясь на анализе KPI (ключевых показателей эффективности), канареечная часть либо растет, либо сворачивается, и результаты анализа публикуются в Slack. Описание и демонстрацию этого процесса можно найти в материале Progressive Delivery for App Mesh.
Dark (скрытые) или А/В-развертывания
Скрытое развертывание — еще одна вариация канареечной стратегии (с ней, кстати, Flagger тоже может работать). Разница между скрытым и канареечным развертыванием состоит в том, что скрытые развертывания имеют дело с фронтендом, а не с бэкендом, как канареечные.
Другое название этих развертываний — А/В-тестирование. Вместо того, чтобы открыть доступ к новой функции всем пользователям, ее предлагают лишь ограниченной их части. Обычно эти пользователи не знают, что выступают тестерами-первопроходцами (отсюда и термин «скрытое развертывание»).
С помощью переключателей функциональности (feature toggles) и других инструментов можно следить за тем, как пользователи взаимодействуют с новой функцией, увлекает ли она их или они считают новый пользовательский интерфейс запутанным, и другими типами метрик.
Flagger и A/B-развертывания
Помимо маршрутизации с учётом весов, Flagger также может направлять на канареечный сервер трафик в зависимости от параметров HTTP. При А/В-тестировании можно использовать заголовки HTTP или файлы cookie для перенаправления определенного сегмента пользователей. Это особенно эффективно в случае frontend-приложений, требующих привязки сессии к серверу (session affinity). Дополнительную информацию можно найти в документации Flagger.
Автор выражает благодарность Stefan Prodan, инженеру Weaveworks (и создателю Flagger), за все эти потрясающие схемы деплоя.
