alina_kocheva 30 июл 2020 в 13:03

Canary Deployment в Kubernetes #2: Argo Rollouts

5 мин

4.7K

Блог компании NixysСистемное администрирование*Тестирование веб-сервисов*DevOps*Kubernetes*

Туториал

Перевод

Автор оригинала: Kim Wuestkamp

Мы будем использовать k8s-нативный контроллер развертывания Argo Rollouts и GitlabCI для запуска Canary деплоя в Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Статьи этого цикла

Canary Deployment в Kubernetes #1: Gitlab CI
(Эта статья)
Canary Deployment using Istio
Canary Deployment с Jenkins-X, Istio и Flagger

Canary Deployment

Надеемся, что Вы читали первую часть, где мы кратко объясняли что такое Canary Deployments. Мы так же показывали как его реализовать используя стандартные ресурсы Kubernetes.

Argo Rollouts

Argo Rollouts — это Kubernetes-нативный контроллер развертывания. Он предоставляет CRD (Custom Resource Definition) для Kubernetes. Благодаря ему, мы можем использовать новую сущность: Rollout, которая управляет blue-green и сanary deployments с различными вариантами настройки.

Контроллер Argo Rollouts, используемый кастомным ресурсом Rollout, позволяет использовать дополнительные стратегии развертывания, такие как blue-green и сanary для Kubernetes. Ресурс Rollout предоставляет функционал равнозначный Deployment, только с дополнительными стратегиями развертывания.
Ресурс Deployments имеет две стратегии для развертывания: RollingUpdate и Recreate. Несмотря на то, что эти стратегии подходят для большинства случаев, для деплоя на сервера в очень большом масштабе используют дополнительные стратегии, такие как blue-green или canary, которых нет в Deployment контроллере. Чтобы использовать эти стратегии в Kubernetes, пользователям приходилось писать скрипты поверх своих Deployments. Контроллер Argo Rollouts предоставляет эти стратегии в виде простых декларативных настраиваемых параметров.
https://argoproj.github.io/argo-rollouts

Существует также Argo CI, который предоставляет удобный веб-интерфейс для использования вместе с Rollouts, мы взглянем на него в следующей статье.

Установка Argo Rollouts

На стороне сервера

kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

В нашей инфраструктурной репе (см. ниже) мы уже добавили install.yaml как i/k8s/argo-rollouts/install.yaml. Таким образом GitlabCI установит его в кластер.

На стороне клиента (kubectl plugin)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

Приложение для примера

Хорошей практикой является наличие отдельных репозиториев для кода приложения и для инфраструктуры.

Репозиторий для приложения

Kim Wuestkamp / k8s-deployment-example-app

Это очень простая API на Python+Flask, возвращающая ответ в виде JSON. Мы соберем пакет, используя GitlabCI и запушим результат в Gitlab Registry. В регистри у нас есть две разные версии релизов:

wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2

Единственная разница между ними это возвращаемый JSON-файл. Мы используем это приложение для максимально простой визуализации того, с какой версией мы общаемся.

Инфраструктурный репозиторий

В этом репозитории мы будем использовать GitlabCI для деплоя в Kubernetes, .gitlab-ci.yml выглядит следующим образом:

image: traherom/kustomize-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s    only:
     - master

Для его запуска самостоятельно вам понадобится кластер, можно использовать Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80

Вам нужно сделать форк https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure и создать переменную KUBECONFIG в GitlabCI, которая будет содержать конфиг для доступа kubectl к вашему кластеру.

Здесь можно почитать о том, как получить учетные данные для кластера (Gcloud).

Инфраструктурный Yaml

Внутри инфраструктурного репозитория у нас есть service:

apiVersion: v1
kind: Service
metadata:
 labels:
   id: rollout-canary
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

и rollout.yaml :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # two minutes

Rollout работает так же как и Deployment. Если мы не зададим стратегию обновления (как canary здесь) он будет вести себя как дефолтный rolling-update Deployment.

Мы определяем два шага в yaml для canary deployment:

10% трафика на canary (wait for manual OK)
50% трафика на canary (wait 2 minutes then continue to 100%)

Выполнение начального деплоя

После начального деплоя наши ресурсы будут выглядеть так:

И получаем ответ только от первой версии приложения:

Выполняем Canary Deployment

Шаг 1: 10% трафика

Чтобы начать canary развертывание, нам просто нужно изменить версию образа, как мы обычно делаем с развертываниями:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

И мы пушим изменения, поэтому Gitlab CI делает deploy и мы видим изменения:

Сейчас если мы обратимся к сервису:

Отлично! Мы в середине нашего canary deployment. Мы можем увидеть прогресс, запустив:

kubectl argo rollouts get rollout rollout-canary

Шаг 2: 50% трафика:

Теперь приступаем к следующему шагу: перенаправление 50% трафика. Мы настроили так, чтобы этот шаг был запущен вручную:

kubectl argo rollouts promote rollout-canary # continue to step 2

И наше приложение вернуло 50% ответов от новых версий:

И обзор rollout:

Прекрасно.

Шаг 3: 100% трафика:

Мы настроили так, чтобы спустя 2 минуты шаг с 50% завершался автоматически и запускался шаг со 100%:

И вывод приложения:

И обзор rollout:

Canary деплой завершен.

Ещё примеры с Argo Rollouts

Здесь есть ещё примеры, например, как настроить предварительный просмотр окружения и сравнения, основанные на canary:

https://github.com/argoproj/argo-rollouts/tree/master/examples

Видео об Argo Rollouts и Argo CI

Я действительно рекомендую это видео, в нем показывается как Argo Rollouts и Argo CI работают вместе:

Итог

Мне очень нравится идея использования CRDs, которые управляют созданием дополнительных типов deployments или replicasets, перенаправляют трафик итд. Работа с ними проходит гладко. Далее мне бы хотелось протестировать интеграцию с Argo CI.

Однако, судя по всему, грядет большое слияние Argo CI и Flux CI, так что я мог бы подождать, пока не выйдет новый релиз: Argo Flux.

А был ли у Вас опыт с Argo Rollouts или Argo CI?

Также читайте другие статьи в нашем блоге:

Теги:

Хабы: