🥇Canary Telepítés a Kubernetes #2: Argo Rollouts

A k8s-native deployment controller, Argo Rollouts, and GitlabCI will be used to launch a Canary deployment in Kubernetes.

https://unsplash.com/photos/V41PulGL1z0

Ezek a ciklus cikkek

Canary Deployment a Kubernetes #1: Gitlab CI
(Ez a cikk)
Canary Deployment Istio használatával
Canary Deployment Jenkins-X Istio Flagger használatával

Canary Deployment

Reméljük, hogy olvastad az első részt, ahol röviden elmagyaráztuk, mi az a Canary Deployments. Azt is bemutattuk, hogyan lehet megvalósítani a Kubernetes alapvető erőforrásainak használatával.

Argo Rollouts

Az Argo Rollouts egy Kubernetes-alapú telepítési vezérlő. Egyedi erőforrás definíciót (CRD) biztosít a Kubernetes számára. Ennek segítségével egy új entitást használhatunk: Rollout, amely kezeli a blue-green és a canary deploy-okat különböző beállítási lehetőségekkel.

Az Argo Rollouts vezérlő, amelyet a testreszabott erőforrás használ, Rollout, lehetővé teszi kiegészítő telepítési stratégiák használatát, például blue-green és canary Kubernetes számára. Az erőforrás Rollout a funkciókat biztosít, amelyek egyenértékűek Deployment, csak kiegészítő telepítési stratégiákkal.
Az erőforrás Deployments két telepítési stratégiát kínál: RollingUpdate és Recreate. Bár ezek a stratégiák a legtöbb esetben megfelelőek, a nagyon nagy léptékű szerverekre való telepítéshez kiegészítő stratégiákat, például blue-green vagy canary, használnak, amelyek nem találhatók meg a Deployment vezérlőben. Ahhoz, hogy ezeket a stratégiákat használják a Kubernetesben, a felhasználóknak korábban szkripteket kellett írniuk a Deployments fölé. Az Argo Rollouts vezérlő ezeket a stratégiákat egyszerű, deklaratív, testreszabható paraméterek formájában biztosít.
https://argoproj.github.io/argo-rollouts

Van még Argo CI is, amely kényelmes webes felületet biztosít a Rollouts-szal együtt, amire a következő cikkben tekintünk.

Argo Rollouts telepítése

A szerveroldalon

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

Az infrastruktúra repónkban (lásd alább) már hozzáadtuk az install.yaml-t, mint i/k8s/argo-rollouts/install.yaml. Így a GitlabCI telepíti azt a klaszterbe.

A kliensoldalon (kubectl plugin)

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

Példaalkalmazás

Jó gyakorlat, ha az alkalmazáskódnak és az infrastruktúrának külön repói vannak.

Az alkalmazás repója

Kim Wuestkamp / k8s-deployment-example-app

Ez egy nagyon egyszerű Python+Flask API, amely JSON formátumban ad vissza választ. A csomagot a GitlabCI segítségével építjük fel, és az eredményt feltöltjük a Gitlab Registry-be. A registry-ben két különböző verziójú kiadásunk van:

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

Az egyetlen különbség közöttük a visszaadott JSON-fájl. Ezt az alkalmazást a lehető legegyszerűbb vizualizációhoz használjuk, hogy lássuk, melyik verzióval kommunikálunk.

Infrastruktúra tároló

Ebben a repóban a GitlabCI-t fogjuk használni a Kubernetes-be való telepítéshez, a .gitlab-ci.yml a következőképpen néz ki:

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

A saját indításához szüksége lesz egy klaszterre, használhatja a Gcloud-ot:

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

Forkot kell készítenie https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure és létre kell hoznia egy változót KUBECONFIG a GitlabCI-ben, amely tartalmazni fogja a hozzáférési konfigurációt kubectl a klaszteréhez.

Itt Olvashatunk arról, hogyan szerezzük meg a klaszterhez szükséges hitelesítő adatokat (Gcloud).

Infrastruktúra Yaml

Az infrastruktúra repó belsejében van egy szolgáltatásunk:

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

és 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
     # A rollouts kézzel is folytathatók a `kubectl argo rollouts promote ROLLOUT` parancs végrehajtásával
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # két perc

Rollout ugyanúgy működik, mint a Deployment. Ha nem állítunk be frissítési stratégiát (mint a canary itt), akkor alapértelmezett rolling-update Deploymentként fog viselkedni.

Két lépést definiálunk a yaml fájlban a canary deploymenthez:

10% forgalom a canaryre (várakozás manuális OK-ra)
50% forgalom a canaryre (várakozás 2 percet, majd folytatás 100%-ig)

A kezdeti deploy végrehajtása

A kezdeti telepítés után az erőforrásaink így néznek ki:

És csak az alkalmazás első verziójától kapunk választ:

Canary Deployment végrehajtása

1. lépés: 10% forgalom

A canary telepítés indításához egyszerűen csak módosítanunk kell a kép verzióját, ahogyan azt általában a telepítéseknél szoktuk:

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
...

És feltöltjük a változtatásokat, így a Gitlab CI végrehajtja a telepítést, és láthatjuk a módosításokat:

Most, ha hivatkozunk a szolgáltatásra:

Kiváló! Középen vagyunk a canary deploymentünknél. Láthattuk a haladást az alábbi parancs végrehajtásával:

kubectl argo rollouts get rollout rollout-canary

2. lépés: 50% forgalom:

Most átmegyünk a következő lépésre: 50% forgalom átirányítása. Ezt a lépést manuálisan állítottuk be a végrehajtáshoz:

kubectl argo rollouts promote rollout-canary # folytatás a 2. lépésre

És az alkalmazásunk 50%-os visszajelzést adott az új verziókból:

És a rollout áttekintése:

Kiváló.

3. lépés: 100% forgalom:

Két perc elteltével a 50%-os lépés automatikusan befejeződik, és a 100%-os lépés elindul:

És az alkalmazás kimenete:

És a rollout áttekintése:

A Canary telepítés befejeződött.

További példák az Argo Rollouts-ról

Itt még több példa található, például arra, hogyan állíthatók be a környezeti előnézetek és a canary-alapú összehasonlítások:

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

Videó az Argo Rollouts-ról és az Argo CI-ról

Jó szívvel ajánlom ezt a videót, amely bemutatja, hogyan működik együtt az Argo Rollouts és az Argo CI:

Result

Nagyon tetszik az ötlet, hogy CRD-ket használunk, amelyek irányítják más típusú telepítések vagy replikasettek létrehozását, forgalom átirányítását stb. Az együttműködés zökkenőmentes. Szeretnék tesztelni az Argo CI-vel való integrációt is.

Ugyanakkor úgy tűnik, hogy egy jelentős összeolvadás készül az Argo CI és a Flux CI között, így megválok a következő kiadástól: Argo Flux.

Volt tapasztalata az Argo Rollouts-szal vagy az Argo CI-vel?