[Системное администрирование, Серверное администрирование, DevOps, Kubernetes] Знакомьтесь: Argo Rollouts v1.0 (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Правильный подход к 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 окружение. Узнать больше о наших планах на развитие проекта можно здесь.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Jesse Suen
===========Похожие новости:
- [Разработка веб-сайтов, Работа с видео, DevOps, Видеоконференцсвязь] Automatize it, or Docker container delivery for WebRTC
- [Микросервисы] Использование микросервисов в работе с Kubernetes и GitOps (перевод)
- [Хостинг, Разработка веб-сайтов, Системное администрирование, Серверное администрирование] ISPmanager 6. Что нового?
- [Программирование, Kubernetes] Построение кластеров Kubernetes средствами самого Kubernetes (перевод)
- [Информационная безопасность, Open source, Виртуализация, Kubernetes] Представляем Red Hat Advanced Cluster Security for Kubernetes
- [Системное администрирование, Серверное администрирование, DevOps] Аварии как опыт #3. Как мы спасали свой мониторинг во время аварии в OVH
- [DevOps, Разработка под Windows] Запускаем Homebrew на Windows 10
- [Системное администрирование, Серверное администрирование, Резервное копирование, Карьера в IT-индустрии] Инженеры technical support и места, где они обитают
- [Информационная безопасность, Программирование, DevOps] Dockle — Диагностика безопасности контейнеров (перевод)
- [Системное администрирование, Серверное администрирование, DevOps] Big Monitoring Meetup состоится в этот четверг, 10.06.2021 в Санкт-Петербурге в привычном формате — оффлайн
Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_servernoe_administrirovanie (Серверное администрирование), #_devops, #_kubernetes, #_argo, #_argo_rollouts, #_kubernetes, #_progressive_delivery, #_blog_kompanii_southbridge (
Блог компании Southbridge
), #_sistemnoe_administrirovanie (
Системное администрирование
), #_servernoe_administrirovanie (
Серверное администрирование
), #_devops, #_kubernetes
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:50
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Правильный подход к 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 в 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 выглядит очень просто:
И теперь созданием подов управляет контроллер ArgoRollouts, а не kubernetes deployment controller. Если вы используете kustomize, наверное, вас очень раздражало, что до недавнего времени инструмент не применял патчи к кастомным ресурсам, как ожидалось. Ссылка на рабочие нагрузки поможет решить эту проблему — вы можете и дальше как обычно управлять патчами для спецификаций подов существующих объектов Deployment, а Rollout будет содержать только информацию о стратегии апдейтов. Другие улучшения Другие примечательные фичи и исправления (полный список см. в заметках к релизу):
Благодарность Очень много людей и компаний не пожалели времени и ресурсов для этого релиза. У нас бы ничего не получилось без поддержки потрясающего и быстро растущего сообщества Argo Rollouts! Выражаем особую благодарность следующим компаниям: Bilibili, Bucketplace, CodeFresh, DataDog, Datawire, Dynatrace, Intuit, NewRelic, Onfido, Paypal, Quizlet, Salesforce, Shipt, Skillz и Spotify. Планы на будущее Надеемся, вам было интересно читать про релиз v1.0. Будущие релизы будут поддерживать больше контроллеров ingress и провайдеров метрик и использовать еще больше продвинутых методов управления трафиком, например маршрутизация на основе заголовков и копирование запросов пользователей в stage окружение. Узнать больше о наших планах на развитие проекта можно здесь. =========== Источник: habr.com =========== =========== Автор оригинала: Jesse Suen ===========Похожие новости:
Блог компании Southbridge ), #_sistemnoe_administrirovanie ( Системное администрирование ), #_servernoe_administrirovanie ( Серверное администрирование ), #_devops, #_kubernetes |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:50
Часовой пояс: UTC + 5