🥇Deployment Canary in Kubernetes #2: Argo Rollouts

Useremu u controller di implementazione Argo Rollouts nativu k8s è GitlabCI per eseguisce implementazioni di Canary à Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Articuli in questa serie

Implementazione di Canary in Kubernetes #1: Gitlab CI
(Stu articulu)
Implementazione Canaria cù Istio
Implementazione di Canary cù Jenkins-X Istio Flagger

Impiegazione Canaria

Speremu chì leghjite prima parte, induve avemu spiegatu brevemente ciò chì i Deployments Canary sò. Avemu ancu dimustratu cumu implementà cù risorse standard Kubernetes.

Argo Rollouts

Argo Rollouts hè un controller di implementazione nativa di Kubernetes. Fornisce un CRD (Custom Resource Definition) per Kubernetes. Grazie à questu, pudemu usà una nova entità: Rollout, chì gestisce implementazioni blu-verde è canarinu cù diverse opzioni di cunfigurazione.

Controller Argo Rollouts utilizatu da una risorsa persunalizata Rollout, Permette strategie di implementazione supplementari cum'è blu-verde è canarinu per Kubernetes. Risorsa Rollout furnisce funziunalità equivalente Deployment, solu cù strategie di implementazione supplementari.
risorsa Deployments hà duie strategie di implementazione: RollingUpdate и Recreate. Ancu s'è sti stratèggi sò adattati per a maiò parte di i casi, per a implementazione à i servitori in una scala assai grande, strategie supplementari sò aduprate, cum'è blu-verde o canarinu, chì ùn sò micca dispunibili in u controller di Deployment. Per utilizà queste strategie in Kubernetes, l'utilizatori anu da scrive script in cima à e so Impiegazioni. L'Argo Rollouts Controller espone queste strategie cum'è paràmetri simplici, dichjarativi, configurabili.
https://argoproj.github.io/argo-rollouts

Ci hè ancu Argo CI, chì furnisce una interfaccia web còmuda per l'usu cù Rollouts, avemu da piglià un ochju à questu in u prossimu articulu.

Installazione di Argo Rollouts

Latu Server

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

In a nostra infrastruttura turnip (vede sottu) avemu digià aghjuntu install.yaml cum'è i/k8s/argo-rollouts/install.yaml. Questu modu GitlabCI l'installarà in u cluster.

Latu client (plugin kubectl)

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

Esempiu Applicazione

Hè una bona pratica per avè repositori separati per u codice di l'applicazione è l'infrastruttura.

Repository per l'applicazione

Kim Wuestkamp/k8s-deployment-example-app

Questa hè una API Python + Flask assai simplice chì torna una risposta cum'è JSON. Custruiremu u pacchettu usendu GitlabCI è spingemu u risultatu à u Registru Gitlab. In u registru avemu duie versioni di liberazione diverse:

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

L'unica diferenza trà elli hè u schedariu JSON restituitu. Utilizemu sta applicazione per visualizà u più faciule pussibule cù quale versione avemu cumunicatu.

Repositoriu di l'infrastruttura

In questu repository useremu GitlabCI per a distribuzione à Kubernetes, .gitlab-ci.yml s'assumiglia cusì:

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

Per eseguisce sè stessu, avete bisognu di un cluster, pudete aduprà Gcloud:

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

Avete bisognu di furchetta https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure è crea una variabile KUBECONFIG in GitlabCI, chì cuntene a cunfigurazione per l'accessu kubectl à u vostru cluster.

hè Pudete leghje cumu uttene credenziali per un cluster (Gcloud).

Infrastruttura Yaml

Dentru u repositoriu di l'infrastruttura avemu u serviziu:

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

è 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 funziona u listessu cum'è Deployment. Se ùn avemu micca stabilitu una strategia d'aghjurnamentu (cum'è canarinu quì) si cumportarà cum'è u Deployment rolling-update predeterminatu.

Definimu dui passi in yaml per l'implementazione canaria:

10% di u trafficu à i canari (aspittà u manuale OK)
50% di u trafficu à i canari (aspittà 2 minuti poi cuntinuà à 100%)

Esecuzione di implementazione iniziale

Dopu a implementazione iniziale, i nostri risorse seranu cusì:

È avemu una risposta solu da a prima versione di l'applicazione:

Eseguisce l'implementazione di Canary

Passu 1: 10% trafficu

Per inizià una implementazione canaria, avemu solu bisognu di cambià a versione di l'imaghjini cum'è di solitu facemu cù implementazioni:

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

E spingemu cambiamenti, cusì Gitlab CI implementa è vedemu i cambiamenti:

Avà si accede à u serviziu:

Perfettu! Semu à mezu à a nostra implementazione canaria. Pudemu vede u prugressu currendu:

kubectl argo rollouts get rollout rollout-canary

Passu 2: 50% trafficu:

Avà andemu à u passu prossimu: redirezzione di u 50% di u trafficu. Avemu cunfiguratu stu passu per esse eseguitu manualmente:

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

È a nostra applicazione hà tornatu 50% di e risposte da e novi versioni:

E rivista di rollout:

Meravigliosa.

Passu 3: 100% trafficu:

Avemu stallatu cusì chì dopu à 2 minuti u passu 50% finisci automaticamente è u passu 100% cumencia:

È u risultatu di l'applicazione:

E rivista di rollout:

A implementazione di Canary hè cumpleta.

Più esempii cù Argo Rollouts

Ci sò più esempii quì, cum'è cumu per stabilisce previsioni di l'ambienti è paraguni basati nantu à canarini:

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

Video nantu à Argo Rollouts è Argo CI

Aghju veramente cunsigliatu stu video, mostra cumu Argo Rollouts è Argo CI travaglianu inseme:

U risultatu

Mi piace assai l'idea d'utilizà CRDs chì gestiscenu a creazione di tipi supplementari di implementazioni o replicasets, redirect trafficu, etc. Travaglià cun elli va bè. In seguitu vogliu pruvà l'integrazione cù Argo CI.

Tuttavia, pare chì ci sia una grande fusione di Argo CI è Flux CI chì vene, cusì puderia aspittà finu à chì a nova versione esce: Argo Flux.

Avete avutu una sperienza cù Argo Rollouts o Argo CI?

Leghjite ancu altri articuli nantu à u nostru blog:

Source: www.habr.com

Implementazione di Canary in Kubernetes #2: Argo Rollouts