Un modo semplice e sicuro per automatizzare le distribuzioni canary con Helm

Un modo semplice e sicuro per automatizzare le distribuzioni canary con Helm

La distribuzione Canary è un modo molto efficace per testare il nuovo codice su un sottoinsieme di utenti. Riduce significativamente il carico di traffico che può essere problematico durante il processo di distribuzione, poiché si verifica solo all'interno di un sottoinsieme specifico. Questa nota è dedicata a come organizzare tale distribuzione utilizzando Kubernetes e l'automazione della distribuzione. Presumiamo che tu sappia qualcosa sulle risorse Helm e Kubernetes.

Un modo semplice e sicuro per automatizzare le distribuzioni canary con Helm

Una semplice distribuzione canary su Kubernetes include due risorse chiave: il servizio stesso e lo strumento di distribuzione. La distribuzione Canary funziona tramite un singolo servizio che interagisce con due diverse risorse che servono il traffico di aggiornamento. Una di queste risorse funzionerà con la versione “canary” e la seconda funzionerà con la versione stabile. In questa situazione, possiamo regolare il numero di versioni canary al fine di ridurre la quantità di traffico necessaria per servire. Se, ad esempio, preferisci utilizzare Yaml, in Kubernetes apparirà così:

kind: Deployment
metadata:
  name: app-canary
  labels:
    app: app
spec:
  replicas: 1
  ...
    image: myapp:canary
---
kind: Deployment
metadata:
  name: app
  labels:
    app: app
spec:
  replicas: 5
  ...
    image: myapp:stable
---
kind: Service
selector:
  app: app # Selector will route traffic to both deployments.

È ancora più semplice immaginare questa opzione utilizzando kubectl e in Documentazione Kubernetes C'è anche un tutorial completo su questo scenario. Ma la domanda principale di questo post è come automatizzeremo questo processo utilizzando Helm.

Automazione della distribuzione Canary

Prima di tutto, abbiamo bisogno di una mappa grafica Helm, che includa già le risorse di cui abbiamo discusso sopra. Dovrebbe assomigliare a qualcosa di simile a questo:

~/charts/app
├── Chart.yaml
├── README.md
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

La base del concetto di Helm è la gestione dei rilasci multiversione. La versione stabile è il nostro principale ramo stabile del codice del progetto. Ma con Helm possiamo distribuire una versione Canary con il nostro codice sperimentale. La cosa principale è mantenere lo scambio di traffico tra la versione stabile e la versione canary. Gestiremo tutto questo utilizzando un apposito selettore:

selector:
  app.kubernetes.io/name: myapp

Le nostre risorse “canarini” e di distribuzione stabile indicheranno questa etichetta sui moduli. Se tutto è configurato correttamente, durante la distribuzione della versione canary della nostra mappa grafica Helm vedremo che il traffico verrà indirizzato ai moduli appena distribuiti. La versione stabile di questo comando sarà simile alla seguente:

helm upgrade
  --install myapp 
  --namespace default 
  --set app.name=myapp       # Goes into app.kubernetes.io/name
  --set app.version=v1       # Goes into app.kubernetes.io/version
  --set image.tag=stable 
  --set replicaCount=5

Ora controlliamo la nostra versione canary. Per implementare la versione Canary, dobbiamo ricordare due cose. Il nome della versione deve essere diverso in modo da non implementare un aggiornamento all'attuale versione stabile. Anche la versione e il tag devono essere diversi in modo da poter distribuire altro codice e identificare le differenze in base ai tag delle risorse.

helm upgrade
  --install myapp-canary 
  --namespace default 
  --set app.name=myapp       # Goes into app.kubernetes.io/name
  --set app.version=v2       # Goes into app.kubernetes.io/version
  --set image.tag=canary 
  --set replicaCount=1

È tutto! Se esegui il ping del servizio, puoi vedere che l'aggiornamento Canary instrada il traffico solo una parte del tempo.

Se stai cercando strumenti di automazione della distribuzione che includano la logica descritta, presta attenzione a Bot di consegna e Strumenti di automazione del timone su GitHub. I grafici Helm utilizzati per implementare il metodo sopra descritto sono su Github, qui. In generale, si trattava di una panoramica teorica su come implementare nella pratica l'automazione della distribuzione delle versioni Canary, con concetti ed esempi specifici.

Fonte: habr.com

Aggiungi un commento