🥇Canary Deployment Kubernetes-ben #1: Gitlab CI

Gitlab CI-t és manuális GitOps-t fogunk használni a Canary-deploy alkalmazásához és használatához a Kubernetesben.

Cikkek ebből a ciklusból:

(ez a cikk)
Canary Deployment ArgoCI segítségével
Canary Deployment Istio alkalmazásával
Canary Deployment Jenkins-X Istio Flaggerrel

A Canary-deploy-t kézi beavatkozással fogjuk végrehajtani a GitOps és a Kubernetes alapvető erőforrásainak létrehozásával/módosításával. Ez a cikk elsősorban arra szolgál, hogy megismerkedjünk a Kubernetesben működő Canary deploy működésével, mivel léteznek hatékonyabb automatizálási módszerek, amelyekről a következő cikkekben fogunk beszélni.

https://www.norberteder.com/canary-deployment/

Canary Deployment

A Canary-frissítési stratégia esetében először csak a felhasználók egy részére vonatkoznak a frissítések. A megfigyelés, a naplókból származó adatok, a kézi tesztelés vagy más visszajelzési csatornák segítségével a kiadást teszteljük, mielőtt azt minden felhasználóra alkalmaznánk.

Kubernetes Deployment (rolling update)

A Kubernetes Deployment alapértelmezett stratégiája a rolling-update, amelynél egy adott számú pod új verziójú képekkel indul el. Ha ezek problémamentesen létrejönnek, az új podok párhuzamosan jönnek létre, míg a régi verziójú podok leállnak.

GitOps

Ebben a példában GitOps-ot használunk, mivel:

a Git-et használjuk egyetlen igazságforrásként
Git Operations segítségével végezzük a buildelést és a deploy-t (nem szükségesek más parancsok, csak git tag/merge)

támadásra

Hozzunk létre egy jó gyakorlatot — egyetlen tárolót a kódokhoz és egyet az infrastruktúrához.

Alkalmazási tároló

Ez egy nagyon egyszerű API Python+Flask segítségével, amely JSON formátumban tér vissza válasszal. A csomagot GitlabCI-n keresztül fogjuk összeállítani és az eredményt a Gitlab Registry-be push-olni. 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öztük a visszaadott JSON-fájl módosítása. Ezt az alkalmazást a verzió vizualizálásának maximális egyszerűsítésére használjuk.

Infrastruktúra tároló

Ebben a repóban a GitlabCI-n keresztül fogunk deploy-olni a Kubernetesbe, .gitlab-ci.yml a következőképpen néz ki:

image: traherom/kustomize-docker

before_script:
   - printenv
   - kubectl version

stages:
 - deploy

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

A klaszterhez (Gcloud) szükséges hitelesítő adatok megszerzéséről itt olvashat. itt található.

Infrastruktúra Yaml

Az infrastruktúra tárolójában a következő található:

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

és a deployment a deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app
spec:
 replicas: 10
 selector:
   matchLabels:
     id: app
     type: main
 template:
   metadata:
     labels:
       id: app
       type: main
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

és egy másik deployment a deploy-canary.yaml:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 0
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

Vedd észre, hogy az app-deploy még nem rendelkezik meghatározott replikákkal.

A kezdeti deploy végrehajtása

A kezdeti deployment elindításához manuálisan futtathatja a GitlabCI pipeline-t a master ágon. Ezt követően kubectl ez a következőt kell, hogy megjelenítse:

Látjuk app deployment 10 replikával és app-canary 0-val. Van egy LoadBalancer is, amivel a következő címen keresztül érhetjük el: curl External IP-n:

while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done

Látjuk, hogy a tesztalkalmazásunk csak a 'v1'-et adja vissza.

A Canary deploy végrehajtása

1. lépés: új verzió kiadása egy részhalmaz számára

A deploy-canary.yaml fájlban az replikák számát 1-re állítottuk, és az új verzió képe:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 1
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

A fájlban deploy.yaml megnöveltük a replikák számát 9-re:

kind: Deployment
metadata:
 name: app
spec:
 replicas: 9
 selector:
   matchLabels:
     id: app
...

Ezeket a változtatásokat a tárolóba toljuk, ahonnan a deploy elindul (GitlabCI-n keresztül), és végül ezt látjuk:

A szolgáltatásunk mindkét deploymentre mutatni fog, mivel mindkettőnek van app szelektora. Az alapértelmezett Kubernetes véletlenszerű elosztása miatt körülbelül 10%-os lekérdezéseknél különböző válaszokat kell látnunk:

A jelenlegi állapota az alkalmazásunknak (GitOps, amely a Gitet használja egyetlen igaz forrásként) az, hogy két deployment aktív replikákkal létezik, egyik minden verzióhoz.

~10% felhasználó ismerkedik meg az új verzióval és akaratlanul is teszteli azt. Most elérkezett az idő, hogy ellenőrizzük a naplókat és a monitoring adatait a problémák felkutatására.

2. lépés: új verzió kiadása minden felhasználónak

Úgy döntöttünk, hogy minden jól ment, és most el kell indítanunk az új verziót minden felhasználónál. Ehhez egyszerűen frissítjük deploy.yaml az új verziót telepítve és a replikák számát 10-re állítva. Az deploy-canary.yaml replikák számát visszaállítjuk 0-ra. A telepítés után az eredmény a következő lesz:

Összefoglalva

Számomra a telepítés kézi indítása segít megérteni, mennyire könnyen beállítható a k8s segítségével. Mivel a Kubernetes lehetővé teszi, hogy minden az API-n keresztül frissüljön, ezeket a lépéseket automatizálni lehet skriptek segítségével.

Még egy dolog, amit meg kell valósítani – ez a tesztelő belépési pont (LoadBalancer vagy Ingress-en keresztül), amelyen keresztül csak az új verzió hozható el. Ezt manuálisan is meg lehet tekinteni.

A következő cikkekben más automatizált megoldásokat fogunk megvizsgálni, amelyek megvalósítják a legtöbb folytatott lépést.