30.07.2020 10:03
alina_kocheva 0 542 Источник

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



https://unsplash.com/photos/V41PulGL1z0


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


  1. Canary Deployment в Kubernetes #1: Gitlab CI
  2. (Эта статья)
  3. Canary Deployment using Istio
  4. 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:


  1. 10% трафика на canary (wait for manual OK)
  2. 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?


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