🥇Canary Deployment în Kubernetes #2: Argo Rollouts

Vom utiliza un controller nativ k8s pentru implementare Argo Rollouts și GitlabCI pentru a lansa Canary deployment în Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Articolele acestui ciclu

Canary Deployment în Kubernetes #1: Gitlab CI
(Această articol)
Canary Deployment folosind Istio
Canary Deployment folosind Jenkins-X Istio Flagger

Canary Deployment

Sperăm că ați citit prima parte, unde am explicat pe scurt ce sunt Canary Deployments. De asemenea, am arătat cum să le implementăm folosind resursele standard Kubernetes.

Argo Rollouts

Argo Rollouts este un controller de implementare nativ Kubernetes. Oferă CRD (Custom Resource Definition) pentru Kubernetes. Grație lui, putem utiliza o nouă entitate: Rollout, care gestionează deployments blue-green și canary cu diverse opțiuni de configurare.

Controllerul Argo Rollouts, utilizat cu resursa personalizată Rollout, permite utilizarea unor strategii suplimentare de implementare, cum ar fi blue-green și canary pentru Kubernetes. Resursa Rollout oferă funcționalitate echivalentă Deployment, doar cu strategii suplimentare de implementare.
Resursă Deployments are două strategii pentru implementare: RollingUpdate și Recreate. Deși aceste strategii sunt potrivite pentru cele mai multe cazuri, pentru implementări pe servere la scară foarte mare se folosesc strategii suplimentare, cum ar fi blue-green sau canary, care nu sunt disponibile în controllerul Deployment. Pentru a utiliza aceste strategii în Kubernetes, utilizatorii erau nevoiți să scrie scripturi peste Deployments-urile lor. Controllerul Argo Rollouts oferă aceste strategii sub forma unor parametrii declarați personalizabili.
https://argoproj.github.io/argo-rollouts

Există, de asemenea, Argo CI, care oferă o interfață web convenabilă pentru utilizare împreună cu Rollouts, ne vom uita la ea în articolul următor.

Instalarea Argo Rollouts

Pe partea serverului

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

În repository-ul nostru de infrastructură (vezi mai jos) am adăugat deja install.yaml ca i/k8s/argo-rollouts/install.yaml. Astfel, GitlabCI îl va instala în cluster.

Pe partea clientului (plugin kubectl)

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

Aplicația de exemplu

O practică bună este să existe repository-uri separate pentru codul aplicației și pentru infrastructură.

Repository-ul pentru aplicație

Kim Wuestkamp / k8s-deployment-example-app

Aceasta este o API foarte simplă pe Python+Flask, returnând un răspuns sub formă de JSON. Vom construi pachetul folosind GitlabCI și vom împinge rezultatul în Gitlab Registry. În registry avem două versiuni diferite ale lansărilor:

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

Singura diferență dintre ele este fișierul JSON returnat. Folosim această aplicație pentru a vizualiza cât mai simplu versiunea cu care interacționăm.

Repozitoriu de infrastructură

În acest repository, vom folosi GitlabCI pentru a desfășura în Kubernetes, fișierul .gitlab-ci.yml arată astfel:

imagine: traherom/kustomize-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - desfășuraredeploy test:
   stage: desfășurare
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s    only:
     - master

Pentru a-l rula local, aveți nevoie de un cluster, puteți folosi Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80

Trebuie să faceți un fork https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure și să creați o variabilă KUBECONFIG în GitlabCI, care va conține configurația de acces kubectl la clusterul dvs.

Aici poți citi despre cum să obții acreditivele pentru cluster (Gcloud).

Yaml de infrastructură

În interiorul repository-ului de infrastructură avem 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

și 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 pot fi reluate manual prin rularea `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # două minute

Rollout funcționează la fel ca un Deployment. Dacă nu definim o strategie de actualizare (ca canary aici), se va comporta ca un deployment rolling-update implicit.

Definim două etape în yaml pentru canary deployment:

10% din trafic pe canary (întreținere manuală OK)
50% din trafic pe canary (așteaptă 2 minute, apoi continuă la 100%)

Executarea deployment-ului inițial

După desfășurarea inițială, resursele noastre vor arăta astfel:

Și primim răspuns doar de la prima versiune a aplicației:

Executăm Canary Deployment

Pasul 1: 10% din trafic

Pentru a începe desfășurarea canary, trebuie doar să schimbăm versiunea imaginii, așa cum facem de obicei cu desfășurările:

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

Și trimitem modificările, astfel încât Gitlab CI să facă desfășurarea și vedem schimbările:

Acum, dacă ne adresăm serviciului:

Excelent! Suntem în mijlocul desfășurării canary. Putem vedea progresul pentru rulând:

kubectl argo rollouts get rollout rollout-canary

Pasul 2: 50% din trafic:

Acum trecem la pasul următor: redirecționarea a 50% din trafic. Am configurat astfel încât acest pas să fie declanșat manual:

kubectl argo rollouts promote rollout-canary # continuă la pasul 2

Și aplicația noastră a întors 50% din răspunsuri de la versiunile noi:

Și un rezumat al desfășurării:

Minunat.

Pasul 3: 100% din trafic:

Am configurat astfel încât, după 2 minute, pasul cu 50% să se finalizeze automat și să se lanseze pasul cu 100%:

Și ieșirea aplicației:

Și un rezumat al desfășurării:

Desfășurarea Canary s-a încheiat.

Încă exemple cu Argo Rollouts

Aici sunt și alte exemple, cum ar fi configurarea previzualizării mediului și a comparațiilor bazate pe canary:

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

Video despre Argo Rollouts și Argo CI

Îți recomand cu căldură acest video, deoarece arată cum funcționează împreună Argo Rollouts și Argo CI:

Rezultatul

Îmi place foarte mult ideea de a folosi CRD-uri care gestionează crearea de tipuri suplimentare de deploymente sau replicasets, redirecționând traficul etc. Lucrul cu ele decurge fără probleme. În continuare, aș dori să testez integrarea cu Argo CI.

Totuși, se pare că va avea loc o fuzionare importantă între Argo CI și Flux CI, așa că aș putea aștepta până la lansarea noului release: Argo Flux.

Ați avut experiențe cu Argo Rollouts sau Argo CI?

Citiți și alte articole de pe blogul nostru:

Sursa: habr.com