Canary Deployment Kuberneteses #2: Argo Rollouts

Kasutame k8s-põhist Argo Rolloutsi ja GitlabCI, et käivitada Canary juurutamine Kuberneteses.

Canary Deployment Kuberneteses #2: Argo Rollouts

https://unsplash.com/photos/V41PulGL1z0

Selle tsükli artiklid

Canary juurutamine

Loodame, et olete lugenud esimest osa, kus selgitasime lühidalt, mis on Canary juurutamised. Näitasime ka, kuidas seda rakendada Kubernetesese standardseteressursside abil.

Argo Rollouts

Argo Rollouts on Kubernetes-põhine juurutuskontroller. See pakub CRD (Custom Resource Definition) Kubernetesese jaoks. Tänu sellele saame kasutada uut üksust: Rollout, mis haldab blue-green ja canary juurutamisi erinevate seadistuste variantidega.

Argo Rolloutsi kontroller, mida kasutatakse kohandatud ressursi Rollout, lubab kasutada täiendavaid juurutamisstrateegiaid, nagu blue-green ja canary Kuberneteses. Ressurss Rollout pakub funktsiooni, mis on võrdne Deployment, kuid koos täiendavate juurutamisstrateegiatega.
Ressurss Deployments on kaks juurutamisstrateegiat: RollingUpdate ja Recreate. Kuigi need strateegiad sobivad enamiku juhtumite jaoks, kasutatakse väga suures ulatuses serverite juurutamiseks täiendavaid strateegiaid, nagu blue-green või canary, mida Deploymenti kontrolleris ei ole. Kuberneteses nende strateegiate kasutamiseks pidid kasutajad kirjutama skripte oma Deployments'i peale. Argo Rollouts kontroller pakub neid strateegiaid lihtsate deklareerimisvõimaluste kaudu.
https://argoproj.github.io/argo-rollouts

On olemas ka Argo CI, mis pakub mugavat veebiliidest Rollouts'i koos kasutamiseks, sellele heidame järgmises artiklis pilgu.

Argo Rollouts'i installimine

Serveri küljes

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

Meie infrastruktuuri reposes (vt allpool) oleme juba lisanud install.yaml failina i/k8s/argo-rollouts/install.yaml. Seega installib GitlabCI selle klastrisse.

Kliendi küljes (kubectl plugin)

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

Näidisrakendus

Hea tava on omada eraldi repositooriume rakenduskoodile ja infrastruktuurile.

Rakenduse repositoorium

Kim Wuestkamp / k8s-deployment-example-app

See on väga lihtne API Python+Flaski peal, mis tagastab vastuse JSON-vormingus. Me koostame paketi, kasutades GitlabCI ja avaldame tulemuse Gitlabi registrisse. Registris on meil kaks erinevat versiooni väljalasketest:

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

Ainuke erinevus nende vahel on tagastatav JSON-fail. Me kasutame seda rakendust, et maksimaalselt lihtsalt visualiseerida, millise versiooniga me suhtleme.

Infrastruktuuri register

Selles registris kasutame GitlabCI-d Kubernetesesse juurutamiseks, .gitlab-ci.yml 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.

Siit saate lugeda sellest, kuidas saada klassriigi (Gcloud) mandaate.

Infrastruktuuri Yaml

Infrastruktuuri registris on meil service:

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

ja 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 } # two minutes

Rollout käitub sama moodi nagu Deployment. Kui me ei defineeri värskenduse strateegiat (nagu canary siin), siis käitub see kui vaikimisi rolling-update Deployment.

Määratleme kaks sammu yaml-is canary deployment'i jaoks:

  1. 10% liiklusest canary jaoks (ootame manualset heakskiitu)
  2. 50% liiklusest canary jaoks (ootame 2 minutit ja siis jätkame 100% peale)

Algse deploy käitamine

Pärast algset deploy'd näevad meie ressursid välja nii:

Canary Deployment Kuberneteses #2: Argo Rollouts

Ja saame vastuse ainult rakenduse esimeselt versioonilt:

Canary Deployment Kuberneteses #2: Argo Rollouts

Teeme Canary Deployment'i

Samm 1: 10% liiklusest

Canary deploy’d käivitamiseks peame lihtsalt muutma pildi versiooni, nagu me tavaliselt deploy’de puhul teeme:

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
...

Ja me teeme muudatusi, seega GitLab CI teeb rakenduse juurutamise ja me näeme muudatusi:

Canary Deployment Kuberneteses #2: Argo Rollouts

Praegu, kui me pöördume teenuse poole:

Canary Deployment Kuberneteses #2: Argo Rollouts

Suurepärane! Oleme meie canary juurutamise keskel. Saame näha, kuidas see edeneb, käivitades:

kubectl argo rollouts get rollout rollout-canary

Canary Deployment Kuberneteses #2: Argo Rollouts

Samm 2: 50% liiklus:

Nüüd liigume järgmise sammu juurde: suunamine 50% liiklusest. Oleme seadistanud nii, et see samm käivitub käsitsi:

kubectl argo rollouts promote rollout-canary # jätka sammu 2

Canary Deployment Kuberneteses #2: Argo Rollouts

Ja meie rakendus tagastas 50% vastustest uutelt versioonidelt:

Canary Deployment Kuberneteses #2: Argo Rollouts

Ja ülevaade juurutamisest:

Canary Deployment Kuberneteses #2: Argo Rollouts

Suurepärane.

Samm 3: 100% liiklus:

Oleme seadistanud nii, et kahe minuti pärast lõpetatakse 50% samm automaatselt ja käivitatakse 100% samm:

Canary Deployment Kuberneteses #2: Argo Rollouts

Ja rakenduse väljund:

Canary Deployment Kuberneteses #2: Argo Rollouts

Ja ülevaade juurutamisest:

Canary Deployment Kuberneteses #2: Argo Rollouts

Canary juurutamine on lõpetatud.

Veel näiteid Argo Rollouts'ist

Siin on veel näiteid, näiteks kuidas seadistada keskkonna eelvaateid ja võrdlusi, mis põhinevad canary:

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

Video Argo Rollouts'ist ja Argo CI-st

Soovitan seda videot, kus näidatakse, kuidas Argo Rollouts ja Argo CI töötavad koos:

Vaata videot

Kokkuvõte

Mulle meeldib väga idee kasutada CRDe, mis haldavad uute tüüpi väljalaskmise või replikaatide loomist, suunavad liiklust jne. Töö nende kallal sujub hästi. Jätkuks sooviksin testida integreerimist Argo CI-ga.

Siiski tundub, et toimub suur ühinemine Argo CI ja Flux CI vahel, seega võiksin oodata, kuni uus versioon välja tuleb: Argo Flux.

Kas teil on kogemusi Argo Rollouts või Argo CI-ga?

Vaata ka teisi artikleid meie blogis:

Allikas: habr.com

Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster