Wy sille Gitlab CI en hantlieding GitOps brûke om Kanaryske ynset yn Kubernetes te ymplementearjen en te brûken
Artikels út dizze searje:
- (Dit artikel)
- Canary Deployment mei Istio
- Kanaryske ynset mei Jenkins-X Istio Flagger
Wy sille de Kanaryske ynset manuell útfiere fia GitOps en de wichtichste Kubernetes-boarnen oanmeitsje / wizigje. Dit artikel is benammen bedoeld foar ynlieding mei hoe't ynset wurket yn Kubernetes Canary, om't d'r effektiver metoaden binne foar automatisearring, dy't wy sille beskôgje yn 'e folgjende artikels.
Kanaryske ynset
Mei de Kanaryske strategy wurde updates earst tapast op mar in subset fan brûkers. Troch tafersjoch, loggegevens, manuele testen, of oare feedbackkanalen, wurdt de frijlitting hifke foardat it wurdt frijjûn oan alle brûkers.
Kubernetes Deployment (rôljende update)
De standertstrategy foar Kubernetes Deployment is rolling-update, wêrby't in bepaald oantal pods wurde lansearre mei nije ferzjes fan 'e ôfbyldings. As se sûnder problemen binne makke, wurde pods mei âlde ferzjes fan ôfbyldings beëinige, en nije pods wurde parallel oanmakke.
GitOps
Wy brûke GitOps yn dit foarbyld om't wy:
- Git brûke as ienige boarne fan wierheid
- wy brûke Git Operations foar bouwen en ynset (gjin oare kommando's dan git tag / merge binne nedich)
Foarbyld:
Litte wy in goede praktyk nimme - ien repository hawwe foar applikaasjekoade en ien foar ynfrastruktuer.
Applikaasje repository
Dit is in heul ienfâldige Python + Flask API dy't in antwurd as JSON weromjout. Wy sille it pakket bouwe fia GitlabCI en triuwe it resultaat nei de Gitlab Registry. Yn it register hawwe wy twa ferskillende release ferzjes:
wuestkamp/k8s-deployment-example-app:v1wuestkamp/k8s-deployment-example-app:v2
It ienige ferskil tusken har is de feroaring yn it weromjûne JSON-bestân. Wy brûke dizze applikaasje om sa maklik mooglik te visualisearjen mei hokker ferzje wy kommunisearje.
Ynfrastruktuer repository
Yn dizze raap sille wy fia GitlabCI ynsette nei Kubernetes, .gitlab-ci.yml sjocht dit sa:
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
Om it sels út te fieren hawwe jo in kluster nedich, jo kinne Gcloud brûke:
gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80Jo moatte forke en meitsje in fariabele KUBECONFIG yn GitlabCI, dy't in konfiguraasje sil befetsje foar tagong kubectl nei jo kluster.
Jo kinne lêze oer hoe't jo referinsjes krije foar in kluster (Gcloud) .
Ynfrastruktuer Yaml
Yn de ynfrastruktuer repository hawwe wy tsjinst:
apiVersion: v1
kind: Service
metadata:
labels:
id: app
name: app
spec:
ports:
- port: 80
protocol: TCP
targetPort: 5000
selector:
id: app
type: LoadBalancerEn ynset yn 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: 100MiEn in oare ynset yn 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: 100MiTink derom dat app-deploy noch gjin replika's definieare hat.
It útfieren fan inisjele ynset
Om de earste ynset te begjinnen, kinne jo de GitlabCI-pipeline manuell begjinne op 'e mastertûke. Dêrnei kubectl moat it folgjende útfiere:
Wy sjogge app ynset mei 10 replika's en app-kanaryske mei 0. Der is ek in LoadBalancer wêrfan wy tagong kinne fia curl fia eksterne IP:
while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done
Wy sjogge dat ús testapplikaasje allinich "v1" werombringt.
It útfieren fan Kanaryske ynset
Stap 1: frijlitte in nije ferzje foar guon brûkers
Wy sette it oantal replika's op 1 yn it deploy-canary.yaml-bestân en de nije ferzjeôfbylding:
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: 100MiYn triem deploy.yaml wy hawwe it oantal replika's feroare yn 9:
kind: Deployment
metadata:
name: app
spec:
replicas: 9
selector:
matchLabels:
id: app
...Wy drukke dizze wizigingen nei it repository wêrfan de ynset sil begjinne (fia GitlabCI) en sjogge as gefolch:
Us tsjinst sil ferwize nei beide ynset, om't beide de app-selektor hawwe. Fanwegen de standert randomisaasje fan Kubernetes moatte wy ferskate antwurden sjen foar ~10% fan oanfragen:
De hjoeddeistige tastân fan ús applikaasje (GitOps, nommen út Git as in Single Source Of Truth) is de oanwêzigens fan twa ynset mei aktive replika's, ien foar elke ferzje.
~ 10% fan brûkers wurde bekend mei in nije ferzje en test it ûnbedoeld. No is it tiid om te kontrolearjen op flaters yn 'e logs en tafersjochgegevens om problemen te finen.
Stap 2: Release de nije ferzje foar alle brûkers
Wy besletten dat alles goed gie en no moatte wy de nije ferzje útrolje foar alle brûkers. Om dit te dwaan, aktualisearje wy gewoan deploy.yaml it ynstallearjen fan in nije ferzje fan de ôfbylding en it oantal replika's gelyk oan 10. In deploy-canary.yaml wy sette it oantal replika's werom op 0. Nei ynset sil it resultaat as folgjend wêze:
To summarize
Foar my helpt it útfieren fan de ynset op dizze manier om te begripen hoe maklik it kin wurde konfigureare mei k8s. Sûnt Kubernetes kinne jo alles bywurkje fia in API, dizze stappen kinne wurde automatisearre troch skripts.
In oar ding dat moat wurde ymplementearre is in tester yngongspunt (LoadBalancer of fia Ingress) troch dêr't allinnich de nije ferzje kin wurde tagong. It kin brûkt wurde foar hânmjittich blêdzjen.
Yn takomstige artikels sille wy oare automatisearre oplossingen kontrolearje dy't it measte fan wat wy hawwe dien ymplementearje.
Lês ek oare artikels op ús blog:
Boarne: www.habr.com