🥇Canary Deployment в Kubernetes #2: Argo Rollouts

Ще използваме k8s-родния контролер за разгръщане Argo Rollouts и GitlabCI за стартиране на Canary разгръщане в Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Статии от този цикъл

Canary Deployment в Kubernetes #1: Gitlab CI
(Тази статия)
Canary разгръщане с Istio
Canary разгръщане с Jenkins-X Istio Flagger

Canary разгръщане

Надяваме се, че сте прочели първата част, където накратко обяснихме какво са Canary разгръщания. Също така показахме как да го реализираме, използвайки стандартните ресурси на Kubernetes.

Argo Rollouts

Argo Rollouts е Kubernetes-роден контролер за разгръщане. Той предлага CRD (Custom Resource Definition) за Kubernetes. С негова помощ можем да използваме нова същност: Rollout, която управлява blue-green и canary разгръщания с различни опции за конфигурация.

Контролерът Argo Rollouts, използван с персонализирания ресурс Rollout, позволява използването на допълнителни стратегии за разгръщане, като blue-green и canary за Kubernetes. Ресурсът Rollout предоставя функционалност, равносилна на Deployment, само с допълнителни стратегии за разгръщане.
Ресурсът Разгръщанията имат две стратегии за разгръщане: RollingUpdate и Recreate. Въпреки че тези стратегии са подходящи за повечето случаи, за разгръщането на сървъри в много голям мащаб се използват допълнителни стратегии, като blue-green или canary, които не са в контролера за Разгръщане. За да използват тези стратегии в Kubernetes, потребителите трябваше да пишат скриптове над своите Разгръщания. Контролерът Argo Rollouts предоставя тези стратегии под формата на прости декларативни настраиваеми параметри.
https://argoproj.github.io/argo-rollouts

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

Инсталиране на Argo Rollouts

На сървърната страна

kubectl create namespace argo-rollouts kubectl 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 плъгин)

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 (чакаме за ръчно ОК)
50% трафик на canary (чакаме 2 минути и след това продължаваме до 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 да извърши деплой и да видим промените:

Сега, ако се обърнем към услугата:

Отлично! Ние сме в средата на нашето canary развертание. Можем да видим напредъка, като стартираме:

kubectl argo rollouts get rollout rollout-canary

Стъпка 2: 50% от трафика:

Сега продължаваме с следващата стъпка: пренасочване на 50% от трафика. Настроили сме този етап да стартира ръчно:

kubectl argo rollouts promote rollout-canary # продължете към стъпка 2

И нашето приложение е върнало 50% отговори от новите версии:

И преглед на разгръщането:

Прекрасно.

Стъпка 3: 100% от трафика:

Настроили сме така, че след 2 минути стъпката с 50% да завърши автоматично и да стартира стъпката със 100%:

И изходът на приложението:

И преглед на разгръщането:

Canary разгръщането е завършено.

Още примери с Argo Rollouts

Тук има още примери, например, как да настроите преглед на средата и сравнения, базирани на canary:

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

Видео за Argo Rollouts и Argo CI

Наистина препоръчвам това видео, в него се показва как Argo Rollouts и Argo CI работят заедно:

Резюме

Много ми харесва идеята за използване на CRD, които управляват създаването на допълнителни типове разгръщания или replica sets, пренасочват трафика и т.н. Работата с тях е гладка. Следващото ми желание е да тествам интеграцията с Argo CI.

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

Имате ли опит с Argo Rollouts или Argo CI?

Също така прочетете и други статии в нашия блог:

Източник: habr.com