🥇Canary Deployment Kuberneteses #1: Gitlab CI

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

Selle artikli seeria:

(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 peamiste ressursside loomise/muutmise. See artikkel on suunatud peamiselt selle tutvustamiseks, kuidas Kuberneteses Canary-deploy toimib, kuna on olemas tõhusamad automaatimise viisid, mida käsitleme järgmistes artiklites.

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

Canary juurutamine

Canary-strateegia puhul rakendatakse uuendused esmalt ainult osa kasutajatele. Jälgimise, logiandmete, käsitsi testimise või teiste tagasiside kanalite kaudu testitakse väljaanne 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 piltide versioonidega. Kui need loodi probleemideta, lõpetatakse vanade piltide pod'id ja uued pod'id luuakse paralleelselt.

GitOps

Kasutame GitOps'i selles näites, kuna me:

kasutame Git'i kui ainsat tõe allikat.
kasutame Git Operations'i ehitamiseks ja juurutamiseks (välja arvatud git tag/merge, pole muid käske vajalik)

Näide

Lähme head praktikat — omame ühte hoidlat rakenduste koodi jaoks ja ühte infrastruktuuri jaoks.

Rakenduste hoidla

See on väga lihtne API Python+Flask'il, mis tagastab vastuse JSON-vormingus. Me ehitame paketi läbi GitlabCI ja viime tulemuse Gitlabi registrisse. Registris on meil kaks erinevat versiooni väljalaskest:

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

Ainus erinevus nende vahel on muutus tagastatud JSON-failis. Kasutame seda rakendust maksimaalselt lihtsa visualiseerimise jaoks, et näha, millega versiooniga me suhtleme.

Infrastruktuuri register

Selles hoidlas viime juurutamise läbi GitlabCI Kubernetesesse, .gitlab-ci.yml see näeb välja järgmine:

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 käivitamiseks iseseisvalt vajate klastrit, võite kasutada Gcloudi:

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

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

Te peate tegema forki https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure ja looma muutuja KUBECONFIG GitlabCI-s, mis sisaldab konfiguraatiot juurdepääsu jaoks kubectl teie klastrile.

Kuidas saada klastrile (Gcloud) autentimist saate lugeda siit.

Infrastruktuuri Yaml

Meie infrastruktuuri hoidlas 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 juurutamine 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 on 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 praegu määratud replikate arvu.

Algse deploy käitamine

Algse deployment'i käivitamiseks saate käsitsi käivitada GitlabCI toru peaharus. Pärast seda kubectl see peaks väljundama järgmist:

Näeme app deployment't 10 replikaga ja app-canary't 0. Samuti on olemas 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

Näeme, et meie testrakendus tagastab ainult "v1".

Canary deployment'i teostamine

Samm 1: vabasta uus versioon osale kasutajatele

Oleme määranud replikate arvu 1 failis deploy-canary.yaml ja uus versioonipilt:

tüüp: Deployment
metainfo:
 nimi: app-canary
spetsifikatsioon:
 replikad: 1
 valija:
   vasteSildid:
     id: app
     tüüp: canary
 mall:
   metainfo:
     sildid:
       id: app
       tüüp: canary
   spetsifikatsioon:
     konteinerid:
     - pilt: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       nimi: app
       ressursid:
         piirangud:
           cpu: 100m
           mälu: 100Mi

Failis deploy.yaml me oleme muutnud replikate arvu 9-ks:

tüüp: Deployment
metainfo:
 nimi: app
spetsifikatsioon:
 replikad: 9
 valija:
   vasteSildid:
     id: app
...

Me viime need muudatused hoidlasse, kust käivitatakse deploy (GitlabCI kaudu) ja näeme lõpuks:

Meie teenus osutab mõlemale deploy-le, kuna mõlemal on id-aplikaator. Kuberneetilises süsteemis toimiva juhusliku jaotuse tõttu peaksime nägema erinevaid vastuseid umbes 10% päringutest:

Meie rakenduse praegune olek (GitOps, mis on saadud Gitist kui ainus tõeallikas) on kahe aktiivse replikaga deployment - iga versiooni jaoks üks.

~10% kasutajatest tutvuvad uue versiooniga ja testivad seda tahtmatult. On aeg kontrollida logides ja monitooringu andmetes vigu 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õigile kasutajatele installima. Selleks uuendame lihtsalt deploy.yaml seadmise uus versioon ja replikate arv on 10. V deploy-canary.yaml seame replikate arvu tagasi 0. Pärast juurutamist on tulemus järgmine:

Kokkuvõtteks

Minu jaoks aitab käsitsi juurutamine mõista, kui lihtsalt seda saab k8si abil seadistada. Kuna Kubernetes võimaldab kõike uuendada API kaudu, saab neid samme automatiseerida skriptide abil.

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

Järgmistes artiklites uurime muid automatiseeritud lahendusi, mis rakendavad enamikku meie tehtust.