🥇Canary Deployment Kuberneteses #1: Gitlab CI

Me kasutame Gitlab CI ja käsitsi GitOps'i, et rakendada ja kasutada Canary-deployd Kubernetesis.

Selle tsükli artiklid:

(see artikkel)
Canary Deployment ArgoCI abil
Canary Deployment Istio abil
Canary Deployment Jenkins-X Istio Flagger abil

Canary-deployd teeme käsitsi läbi GitOps'i ja Kubernetes'i põhivormide loomise/muutmise. See artikkel on mõeldud esmalt tutvumiseks sellega, kuidas Kubernetesis Canary-deploy toimib, kuna on olemas tõhusamaid automatiseerimise viise, millega tutvume järgmistes Artiklites.

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

Canary deploy

Canary-strateegia uuendamisel rakendatakse esmalt muudatused vaid osale kasutajatest. Jälgimise, logide andmete, käsitsi testimise või muude tagasisidekanalite kaudu testitakse vabanemist enne selle rakendamist kõigile kasutajatele.

Kubernetes Deployment (rolling update)

Kubernetes Deployment'i vaikestrateegia on rolling-update, kus käivitatakse kindel arv pod'e uute versioonide piltidega. Kui need luuakse ilma probleemideta, lõpetatakse vanade versioonide pod'id ning uued pod'id luuakse paralleelselt.

GitOps

Kasutame selles näites GitOps'i, kuna:

kasutame Git'i ainusena tõena
kasutame Git Operations'i koostamiseks ja deploy'imiseks (muid käske, välja arvatud git tag/merge, ei ole vaja)

Näide

Võtame hea praktikana ühe repozitooriumi rakenduste koodi ja ühe infrastruktuuri jaoks.

Rakenduste repozitoorium

See on väga lihtne API Python+Flaski peal, mis tagastab vastuse JSON-vormingus. Me koostame paketi läbi GitlabCI ja lükkame tulemuse Gitlab Registry'sse. Meie registris on kaks erinevat versiooni:

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

Ainuke erinevus nende vahel on muutus tagastatavas JSON-failis. Kasutame seda rakendust võimalikult lihtsa visualiseerimise jaoks, millise versiooniga me suhtleme.

Infrastruktuuri hoidla

Selles repozitooriumis deploy'ime läbi GitlabCI Kubernetesisse, .gitlab-ci.yml on järgmisel kujul:

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

Selle iseseisvaks käitamiseks vajate klastri, saate kasutada Gcloudi:

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

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

Peate tegema forki https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure ja looma muutujat KUBECONFIG GitlabCI-s, mis sisaldab konfi ligipääsuks kubectl teie klastrile.

Kuidas saada Gcloud'i jaoks mingeid andmeid klastrile, saab lugeda siit.

Infrastruktuuri Yaml

Infrastruktuuri repozitooriumis on meil teenus:

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

Ja deployment failis 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

Ja teine deployment 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

Pange tähele, et app-deploy'il ei ole veel määratletud replikate.

Esialgse deployimise teostamine

Esialgse deployment’i käivitamiseks võite käsitleda GitlabCI toru manuaalselt master haru. Pärast seda kubectl peab see вывoda järgmist:

Me näeme app deployment 10 replikaga ja app-canary 0-ga. Samuti on LoadBalancer, mille kaudu saame pöörduda curl External IP kaudu:

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

Me näeme, et meie testrakendus tagastab ainult "v1".

Canary deploy'i teostamine

Samm 1: vabastada uus versioon osa kasutajatele

Oleme seadnud replikate arvu 1 failis deploy-canary.yaml ja uue versiooni kujundi:

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

Failis deploy.yaml me muutsime replikate arvu 9-ni:

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

Me pushime need muudatused reposse, millest käivitub deploy (läbi GitlabCI) ja näeme tulemuseks:

Meie teenus osutab mõlemale deployment'ile, kuna kummalgi on selektor app. Juhusliku jaotuse tõttu Kubernetes'is peaksime nägema erinevaid vastuseid umbes 10% päringutest:

Praegune seis meie rakendusest (GitOps, mis on võetud Git’ist kui Ainsast Tõesusallikast) on kahe deployment'i olemasolu aktiivsete replikatega, üks iga versiooni jaoks.

~10% kasutajatest tutvuvad uue versiooniga ja testivad seda tahtmatult. Nüüd on aeg kontrollida vigade olemasolu logides ja jälgimisandmetes probleemide leidmiseks.

Samm 2: vabastada uus versioon kõigile kasutajatele

Oleme otsustanud, et kõik läks hästi ja nüüd peame uue versiooni kõikidele kasutajatele välja laskma. Selleks uuendame lihtsalt deploy.yaml uust versiooni kujundi ja replikate arvu, mis on 10. Järgmine deploy-canary.yaml me seadistame koopia arvu 0-le. Pärast juurutamist on tulemus järgmine:

Kokkuvõtteks

Minu jaoks aitab käsitsi juurutuse käivitamine selliselt mõista, kui lihtsalt saab seda k8s-i kaudu seadistada. Kuna Kubernetes võimaldab kõike API kaudu uuendada, saab neid samme automatiseerida skriptide kaudu.

Veel üks asi, mida on vaja ellu viia — testija sisenemispunkt (LoadBalancer või Ingress kaudu), mille kaudu pääseb juurde ainult uuele versioonile. Seda saab kasutada käsitsi vaatamiseks.

Järgmistes artiklites vaatame üle teised automatiseeritud lahendused, mis rakendavad enamiku sellest, mida me tegime.