Na implementáciu a používanie nasadenia Canary v Kubernetes použijeme Gitlab CI a manuálne GitOps
Články z tejto série:
- (Tento článok)
- Canary Deployment pomocou Istio
- Canary Deployment pomocou Jenkins-X Istio Flagger
Nasadenie Canary vykonáme manuálne cez GitOps a vytvorenie/úpravu hlavných zdrojov Kubernetes. Tento článok je určený predovšetkým na úvod s tým, ako funguje nasadenie v Kubernetes Canary, pretože existujú efektívnejšie metódy automatizácie, ktoré zvážime v nasledujúcich článkoch.
Kanárske nasadenie
Pri stratégii Canary sa aktualizácie najskôr aplikujú iba na podmnožinu používateľov. Prostredníctvom monitorovania, údajov denníka, manuálneho testovania alebo iných kanálov spätnej väzby sa vydanie testuje predtým, ako bude uvoľnené pre všetkých používateľov.
Nasadenie Kubernetes (priebežná aktualizácia)
Predvolenou stratégiou pre Kubernetes Deployment je priebežná aktualizácia, pri ktorej sa spúšťa určitý počet modulov s novými verziami obrázkov. Ak boli vytvorené bez problémov, pody so starými verziami obrázkov sa ukončia a paralelne sa vytvoria nové pody.
GitOps
V tomto príklade používame GitOps, pretože:
- pomocou Gitu ako jediného zdroja pravdy
- na zostavenie a nasadenie používame operácie Git (nie sú potrebné žiadne iné príkazy ako git tag/merge)
Príklad
Vezmime si dobrú prax – mať jedno úložisko pre aplikačný kód a jedno pre infraštruktúru.
Úložisko aplikácií
Toto je veľmi jednoduché Python+Flask API, ktoré vracia odpoveď ako JSON. Balík vytvoríme cez GitlabCI a výsledok vložíme do registra Gitlab. V registri máme dve rôzne verzie vydania:
wuestkamp/k8s-deployment-example-app:v1wuestkamp/k8s-deployment-example-app:v2
Jediný rozdiel medzi nimi je zmena vo vrátenom súbore JSON. Túto aplikáciu používame na čo najjednoduchšiu vizualizáciu, s ktorou verziou komunikujeme.
Úložisko infraštruktúry
V tejto repe nasadíme cez GitlabCI do Kubernetes, .gitlab-ci.yml je nasledovné:
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
Ak ho chcete spustiť sami, budete potrebovať 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:80Potrebujete vidličku a vytvorte premennú KUBECONFIG v GitlabCI, ktorý bude obsahovať konfiguráciu pre prístup kubectl do vášho klastra.
Môžete si prečítať o tom, ako získať poverenia pre klaster (Gcloud) .
Infraštruktúra Yaml
V úložisku infraštruktúry máme službu:
apiVersion: v1
kind: Service
metadata:
labels:
id: app
name: app
spec:
ports:
- port: 80
protocol: TCP
targetPort: 5000
selector:
id: app
type: LoadBalancerA nasadenie 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: 100MiA ďalšie nasadenie 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: 100MiVšimnite si, že app-deploy ešte nemá definované žiadne repliky.
Vykonávanie počiatočného nasadenia
Ak chcete spustiť počiatočné nasadenie, môžete spustiť kanál GitlabCI manuálne na hlavnej vetve. Potom kubectl by mal vydávať nasledovné:
Vidíme app nasadenie s 10 replikami a app-canary s 0. Existuje aj LoadBalancer, z ktorého môžeme pristupovať cez curl cez externú 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“.
Prebieha nasadenie Canary
Krok 1: Uvoľnite novú verziu pre niektorých používateľov
Počet replík sme nastavili na 1 v súbore deploy-canary.yaml a na obrázku 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: 100MiV súbore deploy.yaml zmenili sme počet replík na 9:
kind: Deployment
metadata:
name: app
spec:
replicas: 9
selector:
matchLabels:
id: app
...Tieto zmeny presunieme do úložiska, z ktorého sa začne nasadenie (cez GitlabCI) a ako výsledok vidíme:
Naša služba bude ukazovať na obe nasadenia, pretože obe majú výber aplikácií. Kvôli predvolenej randomizácii Kubernetes by sme mali vidieť rôzne odpovede na ~ 10 % žiadostí:
Aktuálny stav našej aplikácie (GitOps, prevzatý z Git ako Single Source Of Truth) je prítomnosť dvoch nasadení s aktívnymi replikami, jedno pre každú verziu.
~10 % používateľov sa zoznámi s novou verziou a neúmyselne ju otestuje. Teraz je čas skontrolovať chyby v protokoloch a monitorovacích údajoch, aby ste našli problémy.
Krok 2: Uvoľnite novú verziu pre všetkých používateľov
Rozhodli sme sa, že všetko prebehlo v poriadku a teraz musíme sprístupniť novú verziu všetkým používateľom. Za týmto účelom jednoducho aktualizujeme deploy.yaml inštalácia novej verzie obrazu a počet replík rovný 10. In deploy-canary.yaml nastavíme počet replík späť na 0. Po nasadení bude výsledok nasledovný:
Sčítanie
Manuálne spustenie nasadenia týmto spôsobom mi pomáha pochopiť, ako ľahko sa dá nakonfigurovať pomocou k8s. Keďže Kubernetes umožňuje aktualizovať všetko cez API, tieto kroky je možné automatizovať pomocou skriptov.
Ďalšou vecou, ktorú je potrebné implementovať, je vstupný bod testera (LoadBalancer alebo cez Ingress), cez ktorý je možné pristupovať iba k novej verzii. Dá sa použiť na manuálne prehliadanie.
V budúcich článkoch sa pozrieme na ďalšie automatizované riešenia, ktoré implementujú väčšinu toho, čo sme urobili.
Prečítajte si aj ďalšie články na našom blogu:
Zdroj: hab.com