Правильный подход к Progressive Delivery

Команда Argo с гордостью представляет Argo Rollouts v1.0! Узнайте, зачем был запущен этот проект и как мы работали над ним. Инструкции по установке см. на странице релизов.

В конце 2019 года в Intuit продолжался процесс перемещения сотен сервисов из традиционных виртуальных машин в Kubernetes. Больше всего в Kubernetes разработчикам не хватало сложных стратегий деплоймента, вроде blue-green и canary, которые были доступны в нашем прежнем инструменте — Spinnaker. Многие из прежних сервисов требовали одновременного обновления всех подов, чтобы гарантировать согласованность версии API для повторных запросов. Стандартная стратегия Rolling update просто не срабатывала для этих сервисов. Некоторые разработчики использовали для тестирования новой версии окружение staging preview, и при успехе переключали трафик на него. Другие выбирали Kayenta, в которой есть встроенный инструмент канареечного тестирования, напрямую работающий со Spinnaker.

Вскоре мы поняли необходимость реализации более совершенного deployment controller для Kubernetes, поскольку нуждались в продвинутых стратегиях обновления, которые были доступны нам на традиционной инфраструктуре. Так появился Argo Rollouts, заполнивший пробел в blue-green и canary-стратегиях развертывания приложений в Kubernetes.

Новые стратегии деплоя сделали процесс развертывания безопаснее, но автоматизации все еще не хватало. Мы по-прежнему вручную выкатывали сервисы в продакшен и анализировали метрики. Так мы пришли к новой фазе Rollouts — progressive delivery.

Progressive delivery — это метод, при котором мы предоставляем новые версии приложения сначала небольшой группе пользователей, а затем постепенно расширяем эту группу, чтобы снизить риски негативных последствий (например, багов).

Такой метод идеально сочетается с анализом ключевых бизнес-метрик (например, четыре золотых сигнала), так что накаты и откаты полностью автоматизированы. Больше о progressive delivery и нашем подходе мы рассказываем в выступлении на KubeCon.

Работая над функциями progressive delivery в Rollouts, мы понимали, как важно обеспечить расширяемость и гибкость. У Intuit тысячи сервисов, а если считать с сообществом, еще больше, так что невозможно создать универсальное решение в плане метрик и паттернов шейпинга трафика. Поэтому в Argo Rollouts разработчики могут сами выбирать метрики для анализа, кастомные этапы canary и даже провайдера ingress или service mesh. Такая гибкость полностью окупилась. Нам самим и нашему сообществу удалось реализовать ключевые точки интеграции, например Prometheus, DataDog, NewRelic, Wavefront, Kayenta, Job и провайдеры кастомных веб-метрик:

В плане ingress и service mesh Rollouts сейчас поддерживает разных провайдеров, включая Linkerd (SMI), Istio, AWS LoadBalancer, Ambassador и NGINX Ingress Controller.

Два года и две конференции KubeCon спустя (1, 2) команда Argo с гордостью представляет Argo Rollouts v1.0! Rollouts уже пару лет используется в продакшене многими нашими пользователями и даже в таких популярных сервисах, как Intuit QuickBooks и TurboTax, но в этом релизе проект достиг нового уровня зрелости. Вот какие фичи ждут вас в v1.0.

Дашборд Rollouts

При использовании сложных схем деплоймента, вроде canary и progressive delivery, возникает много трудностей с наблюдаемостью для мониторинга и понимания того, что происходит во время апдейта. Чтобы внести больше ясности, в плагине kubectl argo rollouts доступен новый дашборд развертывания. Чтобы его запустить, выполните команду dashboard и откройте интерфейс по адресу http://localhost:3100/:

$ kubectl argo rollouts dashboard

Здесь мы сразу видим разные развертывания в неймспейсе и статус обновления и можем выполнять задачи администрирования, например перезапуск и перевод на следующий этап.

Можно изучить конкретное развертывание, в том числе предыдущие версии и этапы canary, и выполнять больше задач— откат, отмена, обновление образов и т. д.

Дашбордом удобно пользоваться в таком виде, если у вас есть локальный доступ к неймспейсу, но можно смотреть его и через Service/Ingress (скоро будут манифесты). Теперь мы думаем, как сделать так, чтобы можно было просматривать эти данные в интерфейсе Argo CD через расширения.

Больше событий Kubernetes и статистики Prometheus

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

TYPE      REASON                 OBJECT               MESSAGE
Normal    RolloutUpdated         rollout/guestbook    Rollout updated to revision 1
Normal    NewReplicaSetCreated   rollout/guestbook    Created ReplicaSet guestbook-698fbfb9dc (revision 1) with size 1
Normal    RolloutCompleted       rollout/guestbook    Rollout completed update to revision 1 (698fbfb9dc): Initial deploy
Normal    RolloutUpdated         rollout/guestbook    Rollout updated to revision 2
Normal    NewReplicaSetCreated   rollout/guestbook    Created ReplicaSet guestbook-644bd86dd8 (revision 2) with size 1
Normal    ScalingReplicaSet      rollout/guestbook    Scaled down ReplicaSet guestbook-644bd86dd8 (revision 2) from 1 to 0
Warning   RolloutAborted         rollout/guestbook    Rollout aborted update to revision 2
Normal    ScalingReplicaSet      rollout/guestbook    Scaled up ReplicaSet guestbook-644bd86dd8 (revision 2) from 0 to 1
Normal    RolloutStepCompleted   rollout/guestbook    Rollout step 1/2 completed (setWeight: 50)
Normal    RolloutPaused          rollout/guestbook    Rollout is paused (CanaryPauseStep)
Normal    RolloutStepCompleted   rollout/guestbook    Rollout step 2/2 completed (pause: 3s)
Normal    RolloutResumed         rollout/guestbook    Rollout is resumed
Normal    ScalingReplicaSet      rollout/guestbook    Scaled down ReplicaSet guestbook-698fbfb9dc (revision 1) from 1 to 0
Normal    RolloutCompleted       rollout/guestbook    Rollout completed update to revision 2 (644bd86dd8): Completed all 2 canary steps

Кроме того, все события создаются как метрики Prometheus, поэтому все их можно собрать в одном месте и визуализировать на дашбордах Prometheus:

# HELP rollout_events_total Count of rollout events
# TYPE rollout_events_total counter
rollout_events_total{name="guestbook",namespace="default",reason="NewReplicaSetCreated",type="Normal"} 4
rollout_events_total{name="guestbook",namespace="default",reason="RolloutAborted",type="Warning"} 2
rollout_events_total{name="guestbook",namespace="default",reason="RolloutCompleted",type="Normal"} 4
rollout_events_total{name="guestbook",namespace="default",reason="RolloutPaused",type="Normal"} 4
rollout_events_total{name="guestbook",namespace="default",reason="RolloutResumed",type="Normal"} 2
rollout_events_total{name="guestbook",namespace="default",reason="RolloutStepCompleted",type="Normal"} 6
rollout_events_total{name="guestbook",namespace="default",reason="RolloutUpdated",type="Normal"} 4
rollout_events_total{name="guestbook",namespace="default",reason="ScalingReplicaSet",type="Normal"} 6

Подробности о событиях Rollout — это только начало. Дальше мы планируем реализовать поддержку уведомлений о Rollout. В следующем релизе можно будет получать уведомления (Slack, PagerDuty и т. д.) о приостановке, отмене, выполнении развертывания, завершении этапа canary и многих других событиях.

Ссылка на рабочие нагрузки

Мы позиционируем Argo Rollouts как готовую замену Deployment. Запустить совершенно новый сервис с помощью объекта Rollout легко, но при миграции в Rollouts приходится дублировать всю спецификацию шаблона пода из Deployment в Rollout. В версии v1.0 можно использовать альтернативный способ миграции — ссылки на рабочие нагрузки (workload referencing).

Вместо того, чтобы копипастить spec.template из Deployment в Rollout во время миграции, просто сошлитесь на существующий объект Deployment:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: guestbook-rollout
spec:
  replicas: 5
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: guestbook-deploy
  strategy:
    canary:
      steps:
        - setWeight: 20
        - pause: {duration: 10s}

Таким образом у вас останется привычное место для размещения темплейта подов — в манифесте Deployment. А новые стратегии деплоя подов будут указаны в манифесте Rollouts. В этом случае процесс миграции на использование Rollouts выглядит очень просто:

• добавляем Rollouts
• ждем, пока запустятся поды, созданные из Rollouts
• устанавливаем replias: 0 в манифесте Deployment.

И теперь созданием подов управляет контроллер ArgoRollouts, а не kubernetes deployment controller.

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

Другие улучшения

Другие примечательные фичи и исправления (полный список см. в заметках к релизу):

• Поддержка управления трафиком Ambassador Edge Stack.
• Больше вариантов для canary-развертываний с Istio, использования DestinationRules и использования VirtualService в нескольких неймспейсах.
• Улучшения плагина Kubectl (линтинг, ожидание статуса Rollout и условия).
• Улучшения, которые сокращают риск ошибок перенаправления с кодом 500.

Благодарность

Очень много людей и компаний не пожалели времени и ресурсов для этого релиза. У нас бы ничего не получилось без поддержки потрясающего и быстро растущего сообщества Argo Rollouts! Выражаем особую благодарность следующим компаниям: Bilibili, Bucketplace, CodeFresh, DataDog, Datawire, Dynatrace, Intuit, NewRelic, Onfido, Paypal, Quizlet, Salesforce, Shipt, Skillz и Spotify.

Планы на будущее

Надеемся, вам было интересно читать про релиз v1.0. Будущие релизы будут поддерживать больше контроллеров ingress и провайдеров метрик и использовать еще больше продвинутых методов управления трафиком, например маршрутизация на основе заголовков и копирование запросов пользователей в stage окружение. Узнать больше о наших планах на развитие проекта можно здесь.