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í 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.
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:v1wuestkamp/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:80Musíte se rozdělit 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) .
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: 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é žá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: 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 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.
Přečtěte si také další články na našem blogu:
Zdroj: www.habr.com