🥇Canary Deployment in Kubernetes #2: Argo Rollouts

Utilizzeremo il controller di deployment Argo Rollouts nativo di k8s e GitlabCI per avviare il deployment Canary in Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Articoli di questo ciclo

Canary Deployment in Kubernetes #1: Gitlab CI
(Quest'articolo)
Deployment Canary usando Istio
Deployment Canary usando Jenkins-X Istio Flagger

Deployment Canary

Ci auguriamo che abbiate letto la prima parte, dove abbiamo spiegato brevemente cosa sono i Deployment Canary. Abbiamo anche mostrato come implementarli utilizzando le risorse standard di Kubernetes.

Argo Rollouts

Argo Rollouts è un controller di deployment nativo di Kubernetes. Fornisce un CRD (Custom Resource Definition) per Kubernetes. Grazie a ciò, possiamo utilizzare una nuova entità: Rollout, che gestisce i deployment blue-green e canary con diverse opzioni di configurazione.

Il controller Argo Rollouts, utilizzato con la risorsa personalizzata Rollout, permette di utilizzare strategie di deployment aggiuntive, come blue-green e canary per Kubernetes. La risorsa Rollout offre funzionalità equivalenti Deployment, con solo strategie di deployment aggiuntive.
Risorsa Deployments ha due strategie per il deployment: RollingUpdate e Recreate. Sebbene queste strategie siano adatte per la maggior parte dei casi, per il deployment su server su larga scala si utilizzano strategie aggiuntive, come blue-green o canary, che non sono presenti nel Deployment controller. Per utilizzare queste strategie in Kubernetes, gli utenti devono scrivere script sopra i propri Deployments. Il controller Argo Rollouts fornisce queste strategie come semplici parametri configurabili e dichiarativi.
https://argoproj.github.io/argo-rollouts

Esiste anche Argo CI, che offre un'interfaccia web intuitiva da utilizzare insieme a Rollouts, di cui parleremo nel prossimo articolo.

Installazione di Argo Rollouts

Lato server

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

Nella nostra repository infrastrutturale (vedi sotto) abbiamo già aggiunto install.yaml come i/k8s/argo-rollouts/install.yaml. In questo modo, GitLab CI lo installerà nel cluster.

Lato client (plugin kubectl)

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

Applicazione di esempio

È una buona pratica avere repository separati per il codice dell'applicazione e per l'infrastruttura.

Repository per l'applicazione

Kim Wuestkamp / k8s-deployment-example-app

Questa è un'API molto semplice in Python+Flask, che restituisce una risposta in formato JSON. Creeremo un pacchetto utilizzando GitlabCI e caricheremo il risultato nel Gitlab Registry. Nel registry abbiamo due versioni diverse delle release:

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

L'unica differenza tra di loro è il file JSON restituito. Utilizziamo questa applicazione per una visualizzazione estremamente semplice della versione con cui stiamo interagendo.

Repository infrastrutturale

In questo repository utilizzeremo GitlabCI per il deploy in Kubernetes, il file .gitlab-ci.yml è strutturato come segue:

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 eseguirlo da solo avrai bisogno di un cluster, puoi utilizzare Gcloud:

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

È necessario fare un fork https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure e creare una variabile KUBECONFIG in GitlabCI che conterrà la configurazione per l'accesso kubectl al tuo cluster.

Qui puoi leggere su come ottenere le credenziali per il cluster (Gcloud).

Yaml infrastrutturale

All'interno del repository infrastrutturale abbiamo 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

e 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
     # Le rollout possono essere ripresi manualmente eseguendo `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # due minuti

Rollout funziona esattamente come un Deployment. Se non definiamo una strategia di aggiornamento (come canary qui), si comporterà come un Deployment rolling-update predefinito.

Definiamo due passaggi in yaml per il canary deployment:

10% del traffico sul canary (attendere conferma manuale)
50% del traffico sul canary (attendere 2 minuti e poi continuare fino al 100%)

Esecuzione del deployment iniziale

Dopo il deployment iniziale, le nostre risorse appariranno così:

E otteniamo risposta solo dalla prima versione dell'applicazione:

Eseguire il Canary Deployment

Passo 1: 10% del traffico

Per iniziare il deployment canary, dobbiamo semplicemente modificare la versione dell'immagine, come facciamo di solito con i deployment:

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 stiamo inviando le modifiche, quindi Gitlab CI esegue il deploy e vediamo le modifiche:

Ora, se ci rivolgiamo al servizio:

Ottimo! Siamo a metà del nostro canary deployment. Possiamo vedere i progressi eseguendo:

kubectl argo rollouts get rollout rollout-canary

Passo 2: 50% del traffico:

Ora passiamo al passo successivo: indirizzamento del 50% del traffico. Abbiamo impostato questo passaggio per essere avviato manualmente:

kubectl argo rollouts promote rollout-canary # continua al passo 2

E la nostra applicazione ha restituito il 50% delle risposte dalle nuove versioni:

E una panoramica del rollout:

Perfetto.

Passo 3: 100% del traffico:

Abbiamo impostato affinché, dopo 2 minuti, il passaggio con il 50% si concluda automaticamente e venga avviato il passaggio con il 100%:

E l'output dell'applicazione:

E una panoramica del rollout:

Il canary deployment è completato.

Altri esempi con Argo Rollouts

Qui ci sono altri esempi, ad esempio, come configurare un'anteprima dell'ambiente e confronti basati su canary:

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

Video su Argo Rollouts e Argo CI

Raccomando vivamente questo video, in cui si mostra come Argo Rollouts e Argo CI lavorano insieme:

Risultato

Mi piace molto l'idea di utilizzare i CRD che gestiscono la creazione di ulteriori tipi di deployments o replicasets, reindirizzando il traffico, ecc. Lavorare con essi è fluido. Inoltre, vorrei testare l'integrazione con Argo CI.

Tuttavia, sembra che ci sia una grande fusione in arrivo tra Argo CI e Flux CI, quindi potrei aspettare che venga rilasciata una nuova versione: Argo Flux.

Hai avuto esperienza con Argo Rollouts o Argo CI?