Правильный подход к 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 в 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.
При использовании сложных схем деплоймента, вроде canary и progressive delivery, возникает много трудностей с наблюдаемостью для мониторинга и понимания того, что происходит во время апдейта. Чтобы внести больше ясности, в плагине kubectl argo rollouts доступен новый дашборд развертывания. Чтобы его запустить, выполните команду dashboard и откройте интерфейс по адресу http://localhost:3100/:
$ kubectl argo rollouts dashboard
Здесь мы сразу видим разные развертывания в неймспейсе и статус обновления и можем выполнять задачи администрирования, например перезапуск и перевод на следующий этап.
Можно изучить конкретное развертывание, в том числе предыдущие версии и этапы canary, и выполнять больше задач— откат, отмена, обновление образов и т. д.
Дашбордом удобно пользоваться в таком виде, если у вас есть локальный доступ к неймспейсу, но можно смотреть его и через Service/Ingress (скоро будут манифесты). Теперь мы думаем, как сделать так, чтобы можно было просматривать эти данные в интерфейсе Argo CD через расширения.
В продолжение темы улучшенной юзабилити: события 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 выглядит очень просто:
И теперь созданием подов управляет контроллер ArgoRollouts, а не kubernetes deployment controller.
Если вы используете kustomize, наверное, вас очень раздражало, что до недавнего времени инструмент не применял патчи к кастомным ресурсам, как ожидалось. Ссылка на рабочие нагрузки поможет решить эту проблему — вы можете и дальше как обычно управлять патчами для спецификаций подов существующих объектов Deployment, а Rollout будет содержать только информацию о стратегии апдейтов.
Другие примечательные фичи и исправления (полный список см. в заметках к релизу):
Очень много людей и компаний не пожалели времени и ресурсов для этого релиза. У нас бы ничего не получилось без поддержки потрясающего и быстро растущего сообщества Argo Rollouts! Выражаем особую благодарность следующим компаниям: Bilibili, Bucketplace, CodeFresh, DataDog, Datawire, Dynatrace, Intuit, NewRelic, Onfido, Paypal, Quizlet, Salesforce, Shipt, Skillz и Spotify.
Источник статьи: https://habr.com/ru/company/southbridge/blog/562288/
Команда 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 и нашем подходе мы рассказываем в выступлении на 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.
Источник статьи: https://habr.com/ru/company/southbridge/blog/562288/