🥇Canary Deployment në Kubernetes #2: Argo Rollouts

Do të përdorim kontrolluesin e shpërndarjes Argo Rollouts që është natyror për k8s dhe GitlabCI për të nisur një shpërndarje Canary në Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Artikujt e këtij cikli

Shpërndarja Canary në Kubernetes #1: Gitlab CI
(Ky artikull)
Shpërndarja Canary duke përdorur Istio
Shpërndarja Canary duke përdorur Jenkins-X Istio Flagger

Shpërndarja Canary

Shpresojmë që keni lexuar pjesën e parë, ku shpjeguam shkurtimisht çfarë janë shpërndarjet Canary. Ne gjithashtu treguam si mund të realizohet duke përdorur burimet standarde të Kubernetes.

Argo Rollouts

Argo Rollouts është një kontrollues shpërndarjeje natyror për Kubernetes. Ai ofron CRD (Definicion i Burimit të Personalizuar) për Kubernetes. Falë këtij, ne mund të përdorim një njësi të re: Rollout, e cila menaxhon shpërndarjet blue-green dhe canary me mundësi të ndryshme konfigurimi.

Kontrolluesi Argo Rollouts, që përdoret nga burimi i personalizuar Rollout, lejon përdorimin e strategjive të tjera të shpërndarjes, si blue-green dhe canary për Kubernetes. Burimi Rollout ofron funksionalitet të barabartë Zhvillimi, vetëm me strategji shtesë shpërndarjeje.
Burimi Shpërndarjet kanë dy strategji për shpërndarjen: RollingUpdate dhe Rikrijo. Pavarësisht se këto strategji janë të përshtatshme për shumicën e rasteve, për shpërndarjen në serverë me përmasa shumë të mëdha, përdoren strategji shtesë, si blue-green ose canary, që nuk i ka kontrolluesi i Shpërndarjes. Për të përdorur këto strategji në Kubernetes, përdoruesit duhej të shkruanin skripte mbi Shpërndarjet e tyre. Kontrolluesi Argo Rollouts ofron këto strategji në formën e parametrave të thjeshtë të deklarueshëm të konfigurueshëm.
https://argoproj.github.io/argo-rollouts

Ka gjithashtu Argo CI, që ofron një ndërfaqe të leverdishme për t'u përdorur së bashku me Rollouts, do të shohim atë në artikullin e ardhshëm.

Instalimi i Argo Rollouts

Në anën e serverit

kubectl create namespace argo-rollouts kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

Në repositorin tonë të infrastrukturës (shiko më poshtë) ne tashmë e kemi shtuar install.yaml si i/k8s/argo-rollouts/install.yaml. Kështu që GitlabCI do ta instalojë atë në klaster.

Në anën e klientit (kubectl plugin)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

Aplikacioni për shembull

Një praktikë e mirë është të kemi repositorë të veçantë për kodin e aplikacionit dhe për infrastrukturën.

Repositori për aplikacionin

Kim Wuestkamp / k8s-deployment-example-app

Ky është një API shumë i thjeshtë në Python+Flask, që kthen një përgjigje në formën e JSON-it. Do ta ndërtosh paketën duke përdorur GitlabCI dhe do ta dërgosh rezultatin në Regjistrin e Gitlab. Në regjistrin tonë kemi dy versione të ndryshme të lëshimeve:

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

E vetmja e vetme midis tyre është skedari JSON që kthehet. Ne e përdorim këtë aplikacion për një vizualizim sa më të thjeshtë të versionit me të cilin po komunikojmë.

Repozitori infrastruktural

Në këtë repo ne do të përdorim GitlabCI për deployment në Kubernetes, .gitlab-ci.yml duket si më poshtë:

image: traherom/kustomize-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s    only:
     - master

Për ta nisur vetë, do t'ju nevojitet një klasër, 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 fork https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure dhe të krijoni një variablë KUBECONFIG në GitlabCI, e cila do të përmbajë konfigurimin për qasje kubectl në klasrin tuaj.

Këtu mund të lexoni për si të merrni kredencialet për klasrin (Gcloud).

Yaml-infrastrukturor

Brenda repo-s infrastrukturore kemi shërbimin:

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

dhe rollout.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # dy minuta

Rollout funksionon ashtu si edhe Deployment. Nëse nuk e caktojmë strategjinë e përditësimit (si canary këtu), ai do të sillet si një rrjedhë e zakonshme përditësimi.

Ne përcaktojmë dy hapa në yaml për canary deployment:

10% e trafikut për canary (prisni OK manual)
50% e trafikut për canary (prisni 2 minuta pastaj vazhdoni në 100%)

Ekzekutimi i përllogaritjes fillestare

Pas përllogaritjes fillestare, burimet tona do të duken kështu:

Dhe marrim përgjigje vetëm nga versi e parë e aplikacionit:

Ekzekutojmë Canary Deployment

Hapi 1: 10% e trafikut

Për të filluar përllogaritjen canary, thjesht na nevojitet të ndryshojmë versionin e figurës, ashtu siç e bëjmë zakonisht me përllogaritjet:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

Dhe ne shtyjmë ndryshimet, kështu që Gitlab CI bën përllogaritjen dhe ne shohim ndryshimet:

Tani nëse i drejtohemi shërbimit:

Shkëlqyer! Ne jemi në mes të përllogaritjes sonë canary. Mund të shohim progresin duke ekzekutuar:

kubectl argo rollouts get rollout rollout-canary

Hapi 2: 50% e trafikut:

Tani kalojmë në hapin tjetër: përcjellja e 50% e trafikut. E kemi vendosur që ky hap të niset manualisht:

kubectl argo rollouts promote rollout-canary # vazhdo në hapin 2

Dhe aplikacioni ynë ktheu 50% të përgjigjeve nga versionet e reja:

Dhe një përmbledhje e rollout-it:

Shumë mirë.

Hapi 3: 100% e trafikut:

Kemi vendosur që pas 2 minutash hapi me 50% të përfundojë automatikisht dhe të niset hapi me 100%:

Dhe përgjigja e aplikacionit:

Dhe një përmbledhje e rollout-it:

Canary deployment përfundoi.

Shembuj të tjerë me Argo Rollouts

Këtu ka edhe disa shembuj, si për shembull si të konfigurosh një paraqitje të ambientit dhe krahasimet të bazuara në canary:

https://github.com/argoproj/argo-rollouts/tree/master/examples

Video mbi Argo Rollouts dhe Argo CI

Unë vërtet e rekomandoj këtë video, ajo tregon si funksionojnë së bashku Argo Rollouts dhe Argo CI:

Përfundimi

Më pëlqen shumë ideja e përdorimit të CRD-ve që menaxhojnë krijimin e tipeve shtesë të deployments ose replicasets, përcjellin trafikun etj. Punimi me to është i lehtë. Më pas do të doja të testoja integrimin me Argo CI.

Megjithatë, duket se ka një bashkim të madh midis Argo CI dhe Flux CI, kështu që ndoshta mund të pres derisa të dalë versioni i ri: Argo Flux.

Keni pasur ndonjë përvojë me Argo Rollouts apo Argo CI?