🥇Implementare Canary în Kubernetes #2: Lansări Argo

Vom folosi controlerul de implementare Argo Rollouts nativ k8s și GitlabCI pentru a rula implementări Canary în Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Articole din această serie

Implementarea Canary în Kubernetes #1: Gitlab CI
(Acest articol)
Implementarea Canary folosind Istio
Implementarea Canary folosind Jenkins-X Istio Flagger

Desfăşurare Canary

Sperăm să citiți Prima parte, unde am explicat pe scurt ce sunt implementările Canary. De asemenea, am arătat cum să-l implementăm folosind resurse standard Kubernetes.

Lansări Argo

Argo Rollouts este un controler de implementare nativ Kubernetes. Oferă un CRD (Custom Resource Definition) pentru Kubernetes. Datorită acesteia, putem folosi o nouă entitate: Rollout, care gestionează implementările albastru-verde și canar cu diverse opțiuni de configurare.

Controlerul Argo Rollouts folosit de o resursă personalizată Rollout, Permite strategii suplimentare de implementare, cum ar fi albastru-verde și canary pentru Kubernetes. Resursă Rollout oferă funcționalitate echivalentă Deployment, doar cu strategii suplimentare de implementare.
resursă Deployments are două strategii de implementare: RollingUpdate и Recreate. Deși aceste strategii sunt potrivite pentru majoritatea cazurilor, pentru implementarea pe servere la scară foarte mare, sunt folosite strategii suplimentare, cum ar fi albastru-verde sau canary, care nu sunt disponibile în controlerul de implementare. Pentru a folosi aceste strategii în Kubernetes, utilizatorii au trebuit să scrie scripturi peste implementările lor. Argo Rollouts Controller expune aceste strategii ca parametri simpli, declarativi, configurabili.
https://argoproj.github.io/argo-rollouts

Există și Argo CI, care oferă o interfață web convenabilă pentru utilizare cu lansări, vom arunca o privire la asta în articolul următor.

Instalarea Argo Rollouts

Partea de server

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

În infrastructura noastră (vezi mai jos) am adăugat deja install.yaml ca i/k8s/argo-rollouts/install.yaml. În acest fel, GitlabCI îl va instala în cluster.

Partea client (plugin kubectl)

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

Exemplu de aplicație

Este o practică bună să aveți depozite separate pentru codul aplicației și infrastructură.

Depozitul pentru aplicație

Kim Wuestkamp/k8s-deployment-example-app

Acesta este un API Python+Flask foarte simplu, care returnează un răspuns ca JSON. Vom construi pachetul folosind GitlabCI și vom împinge rezultatul în Registrul Gitlab. În registru avem două versiuni de lansare diferite:

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 ușor cu ce versiune comunicăm.

Depozitul de infrastructură

În acest depozit vom folosi GitlabCI pentru implementarea în Kubernetes, .gitlab-ci.yml arată astfel:

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

Pentru a-l rula singur, veți avea nevoie de un cluster, puteți utiliza 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ă bifurcați https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure și creați o variabilă KUBECONFIG în GitlabCI, care va conține configurația pentru acces kubectl către clusterul tău.

Aici Puteți citi despre cum să obțineți acreditări pentru un cluster (Gcloud).

Infrastructură Yaml

În interiorul depozitului de infrastructură avem serviciul:

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 can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # two minutes

Rollout funcționează la fel ca Deployment. Dacă nu setăm o strategie de actualizare (cum ar fi Canary aici), aceasta se va comporta ca implementarea implicită de actualizare rulantă.

Definim doi pași în yaml pentru implementarea Canary:

10% din trafic către Canary (așteptați OK manualul)
50% trafic către Canary (așteptați 2 minute apoi continuați până la 100%)

Efectuarea implementării inițiale

După implementarea inițială, resursele noastre vor arăta astfel:

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

Efectuarea desfășurării Canary

Pasul 1: 10% trafic

Pentru a începe o implementare Canary, trebuie doar să schimbăm versiunea imaginii așa cum facem de obicei cu implementă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 împingem modificări, așa că Gitlab CI se implementează și vedem modificările:

Acum, dacă accesăm serviciul:

Grozav! Suntem în mijlocul desfășurării noastre canare. Putem vedea progresul rulând:

kubectl argo rollouts get rollout rollout-canary

Pasul 2: 50% trafic:

Acum să trecem la pasul următor: redirecționarea a 50% din trafic. Am configurat acest pas pentru a fi rulat manual:

kubectl argo rollouts promote rollout-canary # continue to step 2

Și aplicația noastră a returnat 50% din răspunsurile de la noile versiuni:

Și revizuirea lansării:

Minunat.

Pasul 3: 100% trafic:

L-am configurat astfel încât după 2 minute pasul de 50% să se termine automat și să înceapă pasul de 100%:

Și rezultatul aplicației:

Și revizuirea lansării:

Implementarea Canary este finalizată.

Mai multe exemple cu Argo Rollouts

Există mai multe exemple aici, cum ar fi cum să configurați previzualizări de mediu și comparații bazate pe Canary:

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

Videoclip despre Argo Rollouts și Argo CI

Recomand cu adevărat acest videoclip, care arată modul în care Argo Rollouts și Argo CI lucrează împreună:

Total

Îmi place foarte mult ideea de a folosi CRD-uri care gestionează crearea de tipuri suplimentare de implementări sau replicaset-uri, redirecționează traficul etc. Lucrul cu ei decurge fără probleme. În continuare, aș dori să testez integrarea cu Argo CI.

Cu toate acestea, se pare că urmează o mare fuziune a Argo CI și Flux CI, așa că aș putea aștepta până când apare noua versiune: Argo Flux.

Ai avut vreo experiență cu Argo Rollouts sau Argo CI?

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

Sursa: www.habr.com

Implementare Canary în Kubernetes #2: Lansări Argo