Budeme používat Gitlab CI a manuální GitOps k zavedení a používání Canary nasazení v Kubernetes.
Články v této sérii:
- (tento článek)
- Canary nasazení pomocí Istio
- Canary nasazení pomocí Jenkins-X Istio Flagger
Canary nasazení provedeme ručně prostřednictvím GitOps a vytvořením/změnou základních zdrojů Kubernetes. Tento článek je určen především k seznámení s tím, jak funguje Canary nasazení v Kubernetes, protože existují efektivnější způsoby automatizace, které probereme v následujících článcích.
Canary Deployment
Při strategii Canary aktualizace jsou nejprve aplikovány změny pouze pro část uživatelů. Monitorováním, údaji z logů, manuálním testováním nebo jinými způsoby zpětné vazby se verze testuje před jejím nasazením pro všechny uživatele.
Kubernetes nasazení (rolling update)
Výchozí strategií pro Kubernetes nasazení je rolling-update, při kterém běží určité množství podů s novými verzemi obrazů. Pokud se vytvořily bez problémů, staré pody se ukončují a nové pody se vytvářejí paralelně.
GitOps
V tomto příkladu používáme GitOps, protože:
- používáme Git jako jediný zdroj pravdy
- používáme Git operace pro sestavení a nasazení (není třeba žádných příkazů kromě git tag/merge)
Příklad
Zavedeme dobrou praxi — mít jeden repozitář pro kód aplikací a jeden pro infrastrukturu.
Repozitář pro aplikace
Toto je velmi jednoduché API v Pythonu + Flask, které vrací odpověď ve formátu JSON. Sestavíme balíček prostřednictvím GitlabCI a nahrajeme výsledek do Gitlab Registry. V registru máme dvě různé verze vydání:
wuestkamp/k8s-deployment-example-app:v1wuestkamp/k8s-deployment-example-app:v2
Jediný rozdíl mezi nimi je změna vraceného JSON souboru. Používáme tuto aplikaci k maximálně jednoduché vizualizaci toho, s jakou verzí komunikujeme.
Infrastrukturní repozitář
V tomto repozitáři budeme nasazovat prostřednictvím GitlabCI do Kubernetes, .gitlab-ci.yml vypadat následovně:
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
Pro jeho spuštění samostatně 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:80Musíte si udělat fork a vytvořit proměnnou KUBECONFIG v GitlabCI, která bude obsahovat konfiguraci pro přístup kubectl k vašemu clusteru.
O tom, jak získat pověření pro cluster (Gcloud), si můžete přečíst .
Infrastrukturní Yaml
V infrastrukturním repozitáři 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 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: 100MiA 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: 100MiVšimněte si, že app-deploy zatím nemá definované repliky.
Provádění počátečního nasazení
Pro spuštění počátečního nasazení můžete ručně spustit GitlabCI pipeline v hlavní větvi. Poté kubectl by měl vydat následující:
Vidíme app nasazení s 10 replikami a app-canary s 0. Také je zde LoadBalancer, na který se můžeme obracet přes curl přes External 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”.
Provádění Canary nasazení
Krok 1: uvolnit novou verzi pro část uživatelů
Nastavili jsme počet replik na 1 v souboru deploy-canary.yaml a obraz 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: 100MiV 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 posíláme do repozitáře, ze kterého se spustí nasazení (přes GitlabCI) a vidíme nakonec:
Naše služba bude ukazovat na obě nasazení, protože obě mají selektor app. Vzhledem k náhodnému rozdělení ve výchozím nastavení v Kubernetes bychom měli vidět různé odpovědi na přibližně 10 % dotazů:
Aktuální stav naší aplikace (GitOps, brané z Git jako z jediné pravdy) je přítomnost dvou nasazení s aktivními replikami, po jedné pro každou verzi.
~10 % uživatelů se seznamují s novou verzí a nenáhodně ji testují. Nyní je čas zkontrolovat přítomnost chyb v logech a monitoringových datech, abychom našli problémy.
Krok 2: uvolnit novou verzi pro všechny uživatele
Rozhodli jsme se, že vše dopadlo dobře a nyní potřebujeme nasadit novou verzi pro všechny uživatele. K tomu jednoduše aktualizujeme deploy.yaml nainstalováním nové verze obrazu a počtem replik rovný 10. V deploy-canary.yaml Nastavujeme počet replik na zpětnou hodnotu 0. Po nasazení bude výsledek následující:
Shrnutí
Pro mě je spuštění nasazení tímto způsobem užitečné, protože ukazuje, jak snadno lze provést konfiguraci pomocí k8s. Kubernetes umožňuje aktualizace prostřednictvím API, a tyto kroky mohou být automatizovány skripty.
Další věcí, kterou je třeba implementovat, je vstupní bod testera (LoadBalancer nebo přes Ingress), skrze který je možné přistupovat pouze k nové verzi. Ten může být použit k manuálnímu sledování.
V následujících článcích prozkoumáme další automatizovaná řešení, která realizují většinu toho, co jsme udělali.
Také si přečtěte další články na našem blogu:
Zdroj: habr.com
