🥇Canary Deployment у Kubernetes #2: Argo Rollouts

Мы будзем выкарыстоўваць k8s-натыўны кантролер разгортвання Argo Rollouts і GitlabCI для запуску Canary дэплою ў Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Артыкулы гэтага цыклу

Canary Deployment у Kubernetes #1: Gitlab CI
(Гэты артыкул)
Canary Deployment using Istio
Canary Deployment using Jenkins-X Istio Flagger

Канарскае разгортванне

Спадзяемся, што Вы чыталі першую частку, дзе мы коратка тлумачылі што такое 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?

Таксама чытайце іншыя артыкулы ў нашым блогу:

Крыніца: habr.com

Canary Deployment у Kubernetes #2: Argo Rollouts