🥇Canary Deployment në Kubernetes #2: Argo Rollouts

Ne përdorim kontrolluesin Argo Rollouts të natyrshëm për k8s dhe GitlabCI për të realizuar një Canary deployment në Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Artikujt e këtij cikli

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

Canary Deployment

Shpresojmë që keni lexuar pjesën e parë, ku ne shpjeguam shkurtimisht se çfarë janë Canary Deployments. Ne gjithashtu treguam se si ta realizoni duke përdorur burime standarde të Kubernetes.

Argo Rollouts

Argo Rollouts është një kontrollues i natyrshëm për Kubernetes. Ai ofron CRD (Definicioni i Burimeve të Personalizuara) për Kubernetes. Falë tij, ne mund të përdorim një entitet të ri: Rollout, i cili menaxhon blue-green dhe canary deployments me mundësi të ndryshme konfigurimi.

Kontrolluesi Argo Rollouts, që përdor burimin e personalizuar Rollout, lejon përdorimin e strategjive të tjera të deployimit, si blue-green dhe canary për Kubernetes. Burimi Rollout ofron funksionalitet të barabartë Deployment, vetëm me strategji të tjera të deployimit.
Burimi Deployments ka dy strategji për deployim: RollingUpdate dhe Recreate. Megjithëse këto strategji janë të përshtatshme për shumicën e rasteve, për deploy-n në servera në një shkallë shumë të madhe përdoren strategji shtesë, si blue-green ose canary, të cilat nuk janë në kontrollorin e Deployment. Për të përdorur këto strategji në Kubernetes, përdoruesit ishin të detyruar të shkruanin skripte mbi Deployments e tyre. Kontrollori Argo Rollouts ofron këto strategji në forma parametrash të thjeshtë dhe të deklarueshëm.
https://argoproj.github.io/argo-rollouts

Ekziston gjithashtu Argo CI, i cili ofron një ndërfaqe të lehtë për t'u përdorur së bashku me Rollouts, për të cilin do të flasim në artikullin e ardhshëm.

Instalimi i Argo Rollouts

Nga ana 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ë repin tonë të infrastrukturës (shih më poshtë) ne tashmë e kemi shtuar install.yaml si i/k8s/argo-rollouts/install.yaml. Kështu, GitlabCI do ta instalojë në klaster.

Nga ana e klientit (kubectl plugin)

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

Aplikacioni për shembull

Një praktikë e mirë është të kesh repozita të ndara për kodin e aplikacionit dhe për infrastrukturën.

Repoja për aplikacionin

Kim Wuestkamp / k8s-deployment-example-app

Ky është një API shumë e thjeshtë në Python+Flask, e cila kthen një përgjigje në formatin JSON. Ne do të krijojmë një paketë duke përdorur GitlabCI dhe do ta dërgojmë 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 midis tyre është skedari JSON i kthyer. Ne përdorim këtë aplikacion për të vizualizuar në mënyrë tejet të thjeshtë se me cilën version po komunikojmë.

Repozitori infrastrukturor

Në këtë repozitor, ne do të përdorim GitlabCI për të realizuar deploy në Kubernetes, .gitlab-ci.yml është 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 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.

Këtu mund të lexoni rreth mënyrës si të merrni kredencialet për klastrin (Gcloud).

Yaml infrastrukturor

Brenda repozitorit infrastrukturor 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 po ashtu si Deployment. Nëse ne nuk caktuar një strategji për përditësim (si canary këtu) ai do të sillet si default rolling-update Deployment.

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

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

Kryerja e deploy-it fillestar

Pas deploy-it fillestar, burimet tona do të duket kështu:

Dhe marrim përgjigje vetëm nga versioni i parë të aplikacionit:

Kryejmë Canary Deployment

Hapi 1: 10% e trafikut

Për të filluar canary deploy-in, na nevojitet vetëm të ndryshojmë versionin e imazhit, ashtu siç bëjmë zakonisht me deploy-të:

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 jemi duke shtypur ndryshimet, prandaj Gitlab CI bën deploy dhe ne shohim ndryshimet:

Tani, nëse i drejtohemi shërbimit:

Shkëlqyeshëm! Jemi në mes të canary deployment-it tonë. Mund të shohim përparimin duke ekzekutuar:

kubectl argo rollouts get rollout rollout-canary

Hapi 2: 50% e trafikut:

Tani kalojmë në hapin tjetër: redirektimi i 50% të trafikut. E kemi konfiguruar që ky hap të nisë manualisht:

kubectl argo rollouts promote rollout-canary # vazhdo me hapin 2

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

Dhe përmbledhja e rollout-it:

Mrekulli.

Hapi 3: 100% e trafikut:

E kemi konfiguruar që pas 2 minutash hapi me 50% të përfundojë automatikisht dhe të nisë hapi me 100%:

Dhe dalja e aplikacionit:

Dhe përmbledhja e rollout-it:

Canary deploy është përfunduar.

Shembuj të tjerë me Argo Rollouts

Këtu ka disa shembuj të tjerë, siç është si të konfigurojmë pamjen e madhe të mjedisit dhe krahasimet të bazuara në canary:

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

Video mbi Argo Rollouts dhe Argo CI

Vërtet e rekomandoj këtë video, ku tregohet 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 llojeve të tjera të deployments ose replicasets, që redirection trafik etj. Puna me to shkon shkëlqyer. Më pas, do doja të testoja integrimin me Argo CI.

Megjithatë, duket se ka një bashkim të madh në rrugë mes Argo CI dhe Flux CI, kështu që mund të pres derisa të dalë një version i ri: Argo Flux.

A keni pasur ndonjë përvojë me Argo Rollouts ose Argo CI?

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

Burimi: habr.com