Canary Deployment v Kubernetes #1: Gitlab CI

Uporabljali bomo Gitlab CI in ročni GitOps za uvedbo in uporabo Canary-deplojanja v Kubernetesu

Članki iz te serije:

• (ta članek)
• Canary Deployment z ArgoCI
• Canary Deployment z Istio
• Canary Deployment z Jenkins-X Istio Flagger

Canary-deploy bomo izvedli ročno preko GitOps in ustvarjanjem/spremembo osnovnih virov Kubernetes. Ta članek je namenjen predvsem spoznavanju s tem, kako deluje Canary deployment v Kubernetesu, saj obstajajo učinkovitejši načini avtomatizacije, o katerih bomo govorili v naslednjih člankih.

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

Canary Deployment

Pri strategiji Canary posodobitev se najprej uvedejo samo za del uporabnikov. Z nadzorom, podatki iz dnevnikov, ročnim testiranjem ali drugimi kanali povratnih informacij se različica preizkuša pred njeno uporabo za vse uporabnike.

Kubernetes Deployment (rolling update)

Privzeta strategija za Kubernetes Deployment je rolling-update, kjer se zažene določeno število podov z novimi različicami slik. Če so bile ustvarjene brez težav, se podi s starejšimi različicami slik zaključijo, nove podi pa se ustvarjajo vzporedno.

GitOps

V tem primeru uporabljamo GitOps, saj:

• uporabljamo Git kot edini vir resnice
• uporabljamo Git operacije za gradnjo in deploy (nobene ukaze, razen git tag/merge, ni potrebno)

Primer

Vzemimo dobro prakso — imeti en repozitorij za kodo aplikacij in enega za infrastrukturo.

Repozitorij za aplikacije

To je zelo preprost API na Pythonu+Flask, ki vrača odgovor v obliki JSON. Paket bomo zgradili preko GitlabCI in naložili rezultat v Gitlab Registry. V registru imamo dve različni različici izdaj:

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

Edina razlika med njima je sprememba vračanega JSON-datoteke. To aplikacijo uporabljamo za čim enostavnejšo vizualizacijo, s katero različico komuniciramo.

Infrastrukturnyy repozytoriy

V tem repozitoriju bomo izvajali deploy preko GitlabCI v Kubernetes, .gitlab-ci.yml looks as follows:

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

Dlya ego zapuska samostoyatel'no vam poyavitsya klaster, mozhno ispol'zovat' Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b

gcloud compute firewall-rules create incoming-80 --allow tcp:80

Vam nuzhno sdelat' fork https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure i sozdanie peremennoy KUBECONFIG v GitlabCI, kotoraya budet soderzhat' konfih dlya dostupa kubectl k vashim klasteru.

O tem, kako pridobiti poverilnice za klaster (Gcloud) si lahko preberete here.

Infrastrukturnyy Yaml

V infrastrukturnem repozitoriju imamo service:

apiVersion: v1
kind: Service
metadata:
 labels:
   id: app
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

In deployment 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

In drugi deployment 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

Opazite, da app-deploy zaenkrat nima določenih replik.

Vypolnenie nachal'nogo depleya

Za zagon začetnega deploymenta lahko ročno zaženete GitlabCI pipeline v master veji. Po tem kubectl mora izpisati naslednje:

Vidimo app deployment s 10 replikami in app-canary s 0. Prav tako imamo LoadBalancer, preko katerega lahko dostopamo prek curl z zunanjim IP-jem:

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

Vidimo, da naša testna aplikacija vrača samo "v1".

Izvedba Canary deploya

Korak 1: izdati novo različico za del uporabnikov

Določili smo število replik na 1 v datoteki deploy-canary.yaml in sliko nove različice:

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 datoteki deploy.yaml smo spremenili število replik na 9:

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

Te spremembe potisnemo v repozitorij, iz katerega bo zagnana deploy (prek GitlabCI) in vidimo na koncu:

Naša storitev bo usmerjala na oba deploya, saj imata oba selektor app. Zaradi naključnega razporejanja po privzetku v Kubernetesu bi morali videti različne odgovore na ~ 10% zahtevkov:

Trenutno stanje naše aplikacije (GitOps, prevzeto iz Gita kot enotna vir resnice) je obstoj dveh deploymentov z aktivnimi replikami, po enega za vsako različico.

~10% uporabnikov se srečuje z novo različico in nehote jo testira. Zdaj je čas, da preverimo napake v zapisih in podatki monitoring za iskanje težav.

Korak 2: izdati novo različico za vse uporabnike

Odločili smo se, da vse poteka dobro in zdaj moramo razširiti novo različico za vse uporabnike. To storimo preprosto z deploy.yaml posodobitvijo nove različice slike in številom replik, enakim 10. V deploy-canary.yaml Nastavimo število replik na nič. Po izvajanju bo rezultat naslednji:

Na koncu

Zame ročno zagon izvajanja na ta način pomaga razumeti, kako enostavno je to mogoče nastaviti s pomočjo k8s. Ker Kubernetes omogoča posodabljanje vsega preko API, je mogoče te korake avtomatizirati preko skriptov.

Še ena stvar, ki jo je treba uresničiti, je vhodna točka testerja (LoadBalancer ali preko Ingress), preko katere lahko dostopate le do nove različice. Uporabljena je lahko za ročno ogledovanje.

V naslednjih člankih bomo preverili druge avtomatizirane rešitve, ki uresničujejo večino tega, kar smo naredili.

Preberite tudi druge članke v našem blogu:

• Kaj je privedlo do migracije iz ClickHouse brez avtorizacije na ClickHouse z avtorizacijo
• Zbira dinamičnih modulov za Nginx
• Posodobitev nxs-build-tools — pomočnika pri gradnji deb in rpm paketov.
• Uvod u autorizaciju Hashicorp Consul-a za Kubernetes
• S čim smo se morali soočiti pri uporabi orodja Csync2.
• Telegram bot za Redmine. Kako poenostaviti življenje sebi in drugim

Izvor: habr.com