🥇Distribuzione di Canary in Kubernetes #2: implementazioni di Argo

Utilizzeremo il controller di distribuzione Argo Rollouts nativo di k8s e GitlabCI per eseguire distribuzioni Canary su Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Articoli di questa serie

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

Distribuzione Canarie

Speriamo che tu legga la prima parte, dove abbiamo spiegato brevemente cosa sono i Canary Deployments. Abbiamo anche mostrato come implementarlo utilizzando le risorse Kubernetes standard.

Presentazioni di Argo

Argo Rollouts è un controller di distribuzione nativo di Kubernetes. Fornisce una CRD (Custom Resource Definition) per Kubernetes. Grazie ad esso, possiamo utilizzare una nuova entità: Rollout, che gestisce le distribuzioni blu-verde e canary con varie opzioni di configurazione.

Controller Argo Rollouts utilizzato da una risorsa personalizzata Rollout, Consente strategie di distribuzione aggiuntive come blu-verde e canarino per Kubernetes. Risorsa Rollout fornisce funzionalità equivalenti Deployment, solo con strategie di distribuzione aggiuntive.
risorsa Deployments ha due strategie di distribuzione: RollingUpdate и Recreate. Sebbene queste strategie siano adatte per la maggior parte dei casi, per la distribuzione su server su larga scala vengono utilizzate strategie aggiuntive, ad esempio blu-verde o canarino, che non sono disponibili nel controller di distribuzione. Per utilizzare queste strategie in Kubernetes, gli utenti dovevano scrivere script sopra le loro distribuzioni. Argo Rollouts Controller espone queste strategie come parametri semplici, dichiarativi e configurabili.
https://argoproj.github.io/argo-rollouts

C'è anche Argo CI, che fornisce una comoda interfaccia web da utilizzare con Rollouts, ne parleremo nel prossimo articolo.

Installazione delle implementazioni Argo

Lato server

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

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

Lato client (plug-in kubectl)

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

Applicazione di esempio

È buona norma disporre di repository separati per il codice e l'infrastruttura dell'applicazione.

Repository per l'applicazione

Kim Wuestkamp/k8s-deployment-example-app

Questa è un'API Python+Flask molto semplice che restituisce una risposta come JSON. Costruiremo il pacchetto utilizzando GitlabCI e invieremo il risultato al registro Gitlab. Nel registro abbiamo due diverse versioni di rilascio:

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

L'unica differenza tra loro è il file JSON restituito. Utilizziamo questa applicazione per visualizzare nel modo più semplice possibile con quale versione stiamo comunicando.

Archivio dell'infrastruttura

In questo repository utilizzeremo GitlabCI per la distribuzione su Kubernetes, .gitlab-ci.yml si presenta così:

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 usare Gcloud:

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

Devi biforcare 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 come ottenere le credenziali per un cluster (Gcloud).

Yaml dell'infrastruttura

All'interno del repository dell'infrastruttura abbiamo il 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
     # Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # two minutes

Rollout funziona allo stesso modo della distribuzione. Se non impostiamo una strategia di aggiornamento (come Canary qui) si comporterà come la distribuzione predefinita degli aggiornamenti in sequenza.

Definiamo due passaggi in yaml per la distribuzione canary:

10% del traffico verso Canary (attendere l'OK manuale)
Traffico del 50% verso Canary (attendi 2 minuti e poi prosegui fino al 100%)

Esecuzione della distribuzione iniziale

Dopo la distribuzione iniziale, le nostre risorse appariranno così:

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

Esecuzione della distribuzione Canary

Passaggio 1: 10% di traffico

Per avviare una distribuzione Canary, dobbiamo solo modificare la versione dell'immagine come facciamo di solito con le distribuzioni:

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 promuoviamo le modifiche, quindi Gitlab CI viene distribuito e vediamo le modifiche:

Ora se accediamo al servizio:

Grande! Siamo nel bel mezzo del nostro dispiegamento nelle Canarie. Possiamo vedere i progressi eseguendo:

kubectl argo rollouts get rollout rollout-canary

Passaggio 2: traffico al 50%:

Passiamo ora al passaggio successivo: reindirizzare il 50% del traffico. Abbiamo configurato questo passaggio per essere eseguito manualmente:

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

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

E revisione del lancio:

Belle.

Passaggio 3: traffico al 100%:

Lo impostiamo in modo che dopo 2 minuti il passaggio del 50% termini automaticamente e inizi il passaggio del 100%:

E l'output dell'applicazione:

E revisione del lancio:

La distribuzione di Canary è completa.

Altri esempi con Argo Rollouts

Ci sono altri esempi qui, ad esempio come impostare anteprime e confronti dell'ambiente basati su Canary:

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

Video sulle implementazioni di Argo e Argo CI

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

risultato

Mi piace molto l'idea di utilizzare CRD che gestiscano la creazione di ulteriori tipi di distribuzioni o replicaset, reindirizzare il traffico, ecc. Lavorare con loro procede senza intoppi. Successivamente vorrei testare l'integrazione con Argo CI.

Tuttavia, sembra che sia in arrivo una grande fusione tra Argo CI e Flux CI, quindi potrei aspettare fino all'uscita della nuova versione: Flusso Argo.

Hai avuto esperienza con Argo Rollouts o Argo CI?

Distribuzione di Canary in Kubernetes #2: implementazioni di Argo