🥇Canary Deployment në Kubernetes #1: Gitlab CI

Ne do t’i përdorim Gitlab CI dhe GitOps manual për të implementuar dhe përdorur Canary-deploy në Kubernetes

Artikujt nga ky cikël:

(ky artikull)
Canary Deployment me ArgoCI
Canary Deployment me Istio
Canary Deployment me Jenkins-X Istio Flagger

Do ta realizojmë Canary-deploy manualisht përmes GitOps dhe krijimin/modifikimin e burimeve kryesore të Kubernetes. Ky artikull është në radhë të parë për t’u njohur me mënyrën se si funksionon Canary deploy në Kubernetes, pasi ka mënyra më efikase për automatizim që do të shikojmë në artikujt e ardhshëm.

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

Canary Deployment

Me strategjinë Canary të përditësimit, fillimisht aplikimet bëhen vetëm për një pjesë të përdoruesve. Nëpërmjet monitorimit, të dhënave nga log-et, testimi manual ose kanaleve të tjera të feedback-ut, lëshimi testohet para se të aplikohet për të gjithë përdoruesit.

Kubernetes Deployment (rolling update)

Strategjia e paracaktuar për Kubernetes Deployment është rolling-update, ku një numër i caktuar pods me versione të reja të imazheve started. Nëse ato krijohen pa probleme, pods me versione të vjetra të imazheve përfundojnë dhe pods të reja krijohen paralelisht.

GitOps

Ne përdorim GitOps në këtë shembull, pasi ne:

përdorim Git si burim të vetëm të së vërtetës
përdorim Git Operations për ndërtimin dhe shpërndarjen (nuk nevojiten komanda të tjera përveç git tag/merge)

Shembuj

Të marrim një praktikë të mirë — të kemi një depo për kodin e aplikacioneve dhe një për infrastrukturën.

Depoja për aplikacione

Ky është një API shumë e thjeshtë në Python+Flask, e cila kthehet me një përgjigje në formatin JSON. Ne do të ndërtomë paketën përmes GitlabCI dhe do ta shtyjmë rezultatin në Gitlab Registry. Në regjistrin tonë kemi dy versione të ndryshme të lëshimeve:

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

Dallimi i vetëm ndërmjet tyre është ndryshimi i dokumentit JSON që kthehet. Ne përdorim këtë aplikacion për një vizualizim shumë të thjeshtë të versionit me të cilin po punojmë.

Repozitori infrastrukturor

Në këtë depo ne do të shpërndajmë përmes GitlabCI në Kubernetes, .gitlab-ci.yml duket si më poshtë:

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

Për ta ekzekutuar vetë, do t'ju nevojitet një klastri, mund të përdorni Gcloud:

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

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

Ju nevojitet të bëni një fork https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure dhe të krijoni një variabël KUBECONFIG në GitlabCI, e cila do të përmbajë konfigurimin për qasje kubectl në klastri tuaj.

Për mënyrën se si të merrni kredencialet për klasterin (Gcloud) mund të lexoni këtu.

Yaml infrastrukturor

Në repository-infrastruktore kemi service:

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

Dhe deployment-in në 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

Dhe një tjetër deployment në 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

Vini re se app-deploy për momentin nuk ka replika të caktuara.

Kryerja e deploy-it fillestar

Për të nisur deployment-in fillestar, mund të filloni pipeline-in GitlabCI manualisht në degën master. Pas kësaj kubectl duhet të dalë e mëposhtme:

Ne shohim app deployment me 10 replika dhe app-canary me 0. Po ashtu ka LoadBalancer nga i cili mund të qasemi përmes curl në IP të Jashtme:

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

Ne e shembulli jonë i testit që aplikacioni ynë kthen vetëm "v1".

Kryerja e deploy-it Canary

Hapi 1: lëshoni një version të ri për një pjesë të përdoruesve

Ne e kemi caktuar numrin e kopjeve në 1 në skedarin deploy-canary.yaml dhe imazhin e versionit të ri:

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

Në skedar deploy.yaml ne e ndryshuam numrin e kopjeve në 9:

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

Ne po e dërgojmë këtë ndryshim në repository, nga e cila do të startohet deploy-i (përmes GitlabCI) dhe shohim në fund:

Shërbimi ynë do të tregojë për të dy deploy-t, pasi të dy kanë selektorin app. Për shkak të shpërndarjes së rastësishme sipas të dhënave në Kubernetes, ne duhet të shohim përgjigje të ndryshme në ~ 10% të kërkesave:

Shteti aktual i aplikacionit tonë (GitOps, marrë nga Git si Burimi i Vetëm të Vërtetë) është që ka dy deploymente me kopje aktive, një për çdo version.

~10% e përdoruesve njohin versionin e ri dhe pa dashje e testojnë atë. Tani është koha për të kontrolluar për gabime në logjet dhe të dhënat e monitorimit për të gjetur probleme.

Hapi 2: lëshoni versionin e ri për të gjithë përdoruesit

Ne vendosëm se gjithçka shkoi mirë dhe tani na nevojitet të implementojmë versionin e ri për të gjithë përdoruesit. Për këtë, thjesht përditësojmë deploy.yaml duke instaluar versionin e ri të imazhit dhe numrin e replicave, i barabartë me 10. Në deploy-canary.yaml ne vendosim numrin e replicave të rikthehet në 0. Pas implementimit, rezultati do të jetë si në vijim:

Në përfundim

Për mua, nisja e implementimit manualisht në këtë mënyrë ndihmon në kuptimin e lehtësisë së konfigurimit të tij përmes k8s. Duke qenë se Kubernetes lejon përditësimin e gjithçkaje përmes API, këto hapa mund të automatizohen përmes skriptesh.

Një gjë tjetër që duhet të realizohet është pikëprerja e testuesit (LoadBalancer ose përmes Ingress), përmes së cilës mund të aksesoni vetëm versionin e ri. Ajo mund të përdoret për të parë manualisht.

Në artikujt e ardhshëm do të shqyrtojmë zgjidhje të tjera të automatizuara që realizojnë shumicën e asaj që kemi bërë.

Shihni gjithashtu artikuj të tjerë në blogun tonë:

Burimi: habr.com