🥇Nasazení Canary v Kubernetes #1: Gitlab CI

K implementaci a používání nasazení Canary v Kubernetes použijeme Gitlab CI a manuální GitOps

Články z této série:

(Tento článek)
Canary Deployment pomocí ArgoCI
Canary Deployment pomocí Istio
Canary Deployment pomocí Jenkins-X Istio Flagger

Nasazení Canary provedeme ručně přes GitOps a vytvoření/úpravu hlavních zdrojů Kubernetes. Tento článek je určen především pro úvod s tím, jak funguje nasazení v Kubernetes Canary, protože existují efektivnější metody automatizace, které budeme zvažovat v následujících článcích.

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

Kanárské nasazení

Se strategií Canary jsou aktualizace nejprve aplikovány pouze na podmnožinu uživatelů. Prostřednictvím monitorování, protokolových dat, ručního testování nebo jiných kanálů zpětné vazby je verze testována předtím, než je vydána všem uživatelům.

Kubernetes Deployment (průběžná aktualizace)

Výchozí strategií pro nasazení Kubernetes je průběžná aktualizace, kdy se spouští určitý počet modulů s novými verzemi obrázků. Pokud byly vytvořeny bez problémů, pody se starými verzemi obrázků se ukončí a paralelně se vytvoří nové pody.

GitOps

V tomto příkladu používáme GitOps, protože:

používat Git jako jediný zdroj pravdy
pro sestavení a nasazení používáme operace Git (nejsou potřeba žádné jiné příkazy než git tag/merge)

příklad

Vezměme si dobrou praxi – mít jedno úložiště pro kód aplikace a jedno pro infrastrukturu.

Úložiště aplikací

Toto je velmi jednoduché Python+Flask API, které vrací odpověď jako JSON. Balíček sestavíme přes GitlabCI a výsledek pošleme do registru Gitlab. V registru máme dvě různé verze vydání:

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

Jediný rozdíl mezi nimi je změna ve vráceném souboru JSON. Tuto aplikaci používáme k co nejjednodušší vizualizaci, se kterou verzí komunikujeme.

Infrastrukturní úložiště

V tomto tuřínu nasadíme přes GitlabCI do Kubernetes, .gitlab-ci.yml je následující:

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

Chcete-li jej spustit sami, budete potřebovat cluster, můžete použít 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 se rozdělit https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure a vytvořit proměnnou KUBECONFIG v GitlabCI, který bude obsahovat konfiguraci pro přístup kubectl do vašeho clusteru.

Můžete si přečíst o tom, jak získat přihlašovací údaje pro cluster (Gcloud) zde.

Infrastruktura Yaml

V úložišti infrastruktury 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: LoadBalancer

A nasazení 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 další nasazení 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šimněte si, že app-deploy zatím nemá definované žádné repliky.

Provádění počátečního nasazení

Chcete-li zahájit počáteční nasazení, můžete kanál GitlabCI spustit ručně na hlavní větvi. Potom kubectl by měl vypsat následující:

Vidíme app nasazení s 10 replikami a app-canary s 0. Existuje také LoadBalancer, ze kterého můžeme přistupovat přes curl přes externí IP:

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

Vidíme, že naše testovací aplikace vrací pouze „v1“.

Probíhá nasazení Canary

Krok 1: Uvolněte novou verzi pro některé uživatele

Nastavili jsme počet replik na 1 v souboru deploy-canary.yaml a obrazu nové verze:

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 souboru deploy.yaml změnili jsme počet replik na 9:

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

Tyto změny doručíme do úložiště, ze kterého bude nasazení spuštěno (prostřednictvím GitlabCI) a jako výsledek uvidíme:

Naše služba bude ukazovat na obě nasazení, protože obě mají výběr aplikací. Kvůli výchozí randomizaci Kubernetes bychom měli vidět různé odpovědi pro ~ 10 % požadavků:

Současný stav naší aplikace (GitOps, převzato z Git jako Single Source Of Truth) je přítomnost dvou nasazení s aktivními replikami, jedno pro každou verzi.

~ 10 % uživatelů se seznámí s novou verzí a neúmyslně ji otestuje. Nyní je čas zkontrolovat chyby v protokolech a monitorovacích datech, abyste našli problémy.

Krok 2: Uvolněte novou verzi všem uživatelům

Rozhodli jsme se, že vše proběhlo v pořádku a nyní musíme novou verzi zpřístupnit všem uživatelům. K tomu jednoduše aktualizujeme deploy.yaml instalace nové verze obrazu a počet replik rovný 10. In deploy-canary.yaml nastavíme počet replik zpět na 0. Po nasazení bude výsledek následující:

Sčítání

Ruční spuštění nasazení tímto způsobem mi pomáhá pochopit, jak snadno jej lze nakonfigurovat pomocí k8s. Vzhledem k tomu, že Kubernetes umožňuje vše aktualizovat přes API, lze tyto kroky automatizovat pomocí skriptů.

Další věc, kterou je třeba implementovat, je vstupní bod testeru (LoadBalancer nebo přes Ingress), přes který je možné přistupovat pouze k nové verzi. Lze jej použít pro ruční procházení.

V budoucích článcích se podíváme na další automatizovaná řešení, která implementují většinu toho, co jsme udělali.