🥇Canary Deployment in Kubernetes #2: Argo Rollouts

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

https://unsplash.com/photos/V41PulGL1z0

Articoli di questo ciclo

Canary Deployment in Kubernetes #1: Gitlab CI
(Questo articolo)
Distribuzione Canary utilizzando Istio
Distribuzione Canary utilizzando Jenkins-X Istio Flagger

Distribuzione Canary

Speriamo che tu abbia letto la prima parte, dove abbiamo brevemente spiegato cosa sono le distribuzioni Canary. Abbiamo anche mostrato come implementarlo utilizzando le risorse standard di Kubernetes.

Argo Rollouts

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

Il controller Argo Rollouts, utilizzando la risorsa personalizzata Rollout, consente di utilizzare strategie di distribuzione aggiuntive, come blue-green e canary per Kubernetes. La risorsa Rollout fornisce funzionalità equivalenti a Deployment, ma con strategie di distribuzione aggiuntive.
La risorsa Deployments ha due strategie per la distribuzione: RollingUpdate e Recreate. Anche se queste strategie si adattano alla maggior parte dei casi, per le distribuzioni su server su larga scala si utilizzano strategie aggiuntive, come blue-green o canary, che non sono presenti nel controller Deployment. Per utilizzare queste strategie in Kubernetes, gli utenti dovevano scrivere script sopra i loro Deployments. Il controller Argo Rollouts offre queste strategie come semplici parametri configurabili dichiarativi.
https://argoproj.github.io/argo-rollouts

Esiste anche Argo CI, che fornisce un'interfaccia web conveniente da utilizzare insieme ai Rollouts, daremo un'occhiata in dettaglio nel prossimo articolo.

Installazione di Argo Rollouts

Dalla parte del server

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

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

Dalla parte del 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

Si tratta di una semplice API in Python+Flask che restituisce una risposta in formato JSON. Creeremo un pacchetto utilizzando GitlabCI e caricheremo il risultato nel Gitlab Registry. Nel registro abbiamo due diverse versioni di rilascio:

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 il più semplice possibile di quale versione stiamo comunicando.

Repository infrastrutturale

In questo repository utilizzeremo GitlabCI per il deployment in Kubernetes, .gitlab-ci.yml appare 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 avviarlo da solo avrete bisogno di un cluster, potete utilizzare Gcloud:

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

Dovete 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 vostro cluster.

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

Yaml infrastrutturale

All'interno del repository infrastrutturale abbiamo un servizio:

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

Rollout funziona proprio come un Deployment. Se non specifichiamo una strategia di aggiornamento (come canary qui) si comporterà come il Default rolling-update Deployment.

Definiamo due passaggi in yaml per il canary deployment:

10% di traffico su canary (attendere l'ok manuale)
50% di traffico su canary (attendere 2 minuti e poi continuare al 100%)

Esecuzione del deployment iniziale

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

E riceviamo una risposta solo dalla prima versione dell'applicazione:

Eseguiamo il Canary Deployment

Passo 1: 10% di 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 pushando le modifiche, quindi Gitlab CI esegue il deployment 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: reindirizzare il 50% del traffico. Abbiamo configurato questo passo 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 panoramica del rollout:

Perfetto.

Passo 3: 100% del traffico:

Abbiamo configurato affinché dopo 2 minuti il passo con il 50% si concluda automaticamente e inizi il passo con il 100%:

E l'output dell'applicazione:

E panoramica del rollout:

Il deployment Canary è completato.

Altri esempi con Argo Rollouts

Ecco altri esempi, come configurare l'anteprima dell'ambiente e i confronti basati su canary:

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

Video su Argo Rollouts e Argo CI

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

Risultato

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

Tuttavia, a quanto pare, è in arrivo una grande fusione tra Argo CI e Flux CI, quindi potrei aspettare che esca una nuova versione: Argo Flux.

Hai avuto esperienze con Argo Rollouts o Argo CI?