🥇Canary Deployment v Kubernetes #1: Gitlab CI

Na implementáciu a používanie Canary nasadenia v Kubernetes budeme používať Gitlab CI a manuálny GitOps.

Články z tejto série:

(tento článok)
Canary nasadenie pomocou ArgoCI
Canary nasadenie pomocou Istio
Canary nasadenie pomocou Jenkins-X Istio Flagger

Canary nasadenie budeme vykonávať ručne prostredníctvom GitOps a vytvorením/zmenou základných zdrojov Kubernetes. Tento článok je primárne určený na zoznámenie s tým, ako funguje Canary nasadenie v Kubernetes, pretože existujú efektívnejšie spôsoby automatizácie, ktoré si prejdeme v ďalších článkoch.

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

Canary nasadenie

Pri stratégii Canary aktualizácie sa najprv aplikujú iba na časť používateľov. Prostredníctvom monitorovania, údajov z logov, manuálneho testovania alebo iných kanálov spätnej väzby sa vydanie testuje pred jeho aplikovaním pre všetkých používateľov.

Kubernetes Deployment (rolling update)

Predvolená stratégia pre Kubernetes Deployment je rolling-update, kde sa spúšťa určité množstvo podov s novými verziami obrazov. Ak sa vytvoria bez problémov, pody so starými verzami obrazov sa ukončia a nové pody sa vytvoria paralelne.

GitOps

V tomto príklade používame GitOps, pretože:

používame Git ako jediný zdroj pravdy
používame Git operácie na zostavenie a nasadenie (nie sú potrebné žiadne príkazy okrem git tag/merge)

Príklad

Pre dobrú prax si zoberieme, že máme jeden repozitár pre kód aplikácií a jeden pre infraštruktúru.

Repozitár pre aplikácie

Toto je veľmi jednoduché API na Python+Flask, ktoré vracia odpoveď vo formáte JSON. Zostavíme balík prostredníctvom GitlabCI a výsledok nahodíme do Gitlab Registry. V registri máme dve rôzne verzie vydaní:

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

Jediný rozdiel medzi nimi je zmena vracajúceho JSON súboru. Používame túto aplikáciu na maximálne jednoduchú vizualizáciu toho, s ktorou verziou komunikujeme.

Infraštruktúrny repozitár

V tomto repozitári budeme nasadzovať prostredníctvom GitlabCI do Kubernetes, .gitlab-ci.yml vyzerá nasledovne:

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

Na jeho spustenie potrebujete klaster, môžete použiť Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b

gcloud compute firewall-rules create incoming-80 --allow tcp:80

Musíte si urobiť fork https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure a vytvoriť premennú KUBECONFIG v GitlabCI, ktorá bude obsahovať konfiguráciu na prístup kubectl k vášmu klastru.

O tom, ako získať poverenia pre klaster (Gcloud) sa môžete dočítať tu.

Informačný Yaml

V infraštruktúrnom repozitári máme service:

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

A deployment v 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

A ďalší deployment v 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

Všimnite si, že app-deploy zatiaľ nemá určené repliky.

Realizácia počiatočného depozitu

Pre spustenie počiatočného deploymentu môžete spustiť pipeline GitlabCI manuálne v hlavnej branchi. Potom kubectl by mal vykázať nasledujúce:

Vidíme app deployment s 10 replikami a app-canary s 0. Tak isto je tu LoadBalancer, cez ktorý môžeme pristupovať cez curl po External IP:

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

Vidíme, že naša testovacia aplikácia vracia iba “v1”.

Realizácia Canary depozitu

Krok 1: uvoľniť novú verziu pre časť používateľov

Nastavili sme počet replik na 1 v súbore deploy-canary.yaml a obraz novej verzie:

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

V súbore deploy.yaml zmenili sme počet replik na 9:

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

Túto zmenu posielame do repozitára, z ktorého sa spustí deployment (cez GitlabCI) a nakoniec vidíme:

Naša služba bude ukazovať na oba deploy, pretože obe majú selektor app. V dôsledku náhodného rozdelenia podľa predvoleného nastavenia v Kubernetes by sme mali vidieť rôzne odpovede na približne 10 % požiadaviek:

Aktuálny stav našej aplikácie (GitOps, brané z Git ako z Jediného zdroja pravdy) je prítomnosť dvoch deploymentov s aktívnymi replikami, po jednom pre každú verziu.

~10 % používateľov sa oboznamuje s novou verziou a neúmyselne ju testujú. Teraz je čas skontrolovať prítomnosť chýb v logoch a monitorovacích dátach na identifikáciu problémov.

Krok 2: uvoľniť novú verziu pre všetkých používateľov

Rozhodli sme sa, že všetko prebehlo dobre a teraz musíme rozšíriť novú verziu na všetkých používateľov. Na to jednoducho aktualizujeme deploy.yaml nainštalovaním novej verzie obrazu a počet replik je nastavený na 10. V deploy-canary.yaml nastavujeme počet replik späť na 0. Po nasadení bude výsledok nasledujúci:

Na záver

Pre mňa spustenie nasadenia ručne takto pomáha pochopiť, ako ľahko môže byť nakonfigurované pomocou k8s. Pretože Kubernetes umožňuje aktualizovať všetko cez API, tieto kroky je možné automatizovať pomocou skriptov.

Ďalšia vec, ktorú je potrebné implementovať, je vstupná bod testera (LoadBalancer alebo cez Ingress), cez ktorý sa dá získať prístup iba k novej verzii. Môže byť použitá na manuálny prehľad.

V nasledujúcich článkoch preskúmame ďalšie automatizované riešenia, ktoré implementujú väčšinu z toho, čo sme urobili.