Un modo semplice e sicuro per automatizzare i deploy canary con Helm

Il deployment canarino è un modo molto efficace per testare nuovo codice su un sottoinsieme di utenti. Riduce significativamente il carico di traffico, che potrebbe causare problemi durante il processo di distribuzione, poiché avviene solo all'interno di un gruppo specifico. Questo documento è dedicato a come organizzare un simile deployment utilizzando Kubernetes e strumenti di automazione del deployment. Si presume che tu sappia già qualcosa su Helm e sulle risorse Kubernetes.



Un semplice deployment canarino in Kubernetes include due risorse chiave: il servizio stesso e lo strumento di distribuzione. Il deployment canarino funziona tramite un singolo servizio che interagisce con due diverse risorse che gestiscono il traffico di aggiornamento. Una di queste risorse gestirà la versione 'canarino', mentre l'altra sarà quella stabile. In questa situazione, possiamo regolare il numero di versioni canarino per ridurre la quantità di traffico da gestire. Se, ad esempio, preferisci utilizzare Yaml, apparirà in Kubernetes come segue:

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 # Il selettore indirizzerà il traffico a entrambe le distribuzioni.

È ancora più semplice rappresentare questa opzione su kubectl, e nella documentazione di Kubernetes c'è anche un tutorial completo su questo scenario. Ma la principale questione di questo post è come intendiamo automatizzare questo processo utilizzando Helm.

Automazione del deployment canarino

Prima di tutto, avremo bisogno di una mappa dei chart Helm, che include già le risorse di cui abbiamo parlato sopra. Dovrebbe apparire più o meno così:

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

Il fulcro del concetto di Helm è la gestione di release multi-versione. La versione stabile è il nostro ramo principale stabile del progetto. Ma con Helm possiamo distribuire una release canarino con il nostro codice sperimentale. L'importante è mantenere la condivisione del traffico tra la versione stabile e la release canarino. Gestiremo tutto ciò attraverso un selettore speciale:

selector:
  app.kubernetes.io\/name: myapp

Le nostre risorse di deploy, sia "canary" che stable, indicheranno questo tag nei moduli. Se tutto viene configurato correttamente, durante il deploy della versione canary della nostra mappa dei chart Helm vedremo che il traffico sarà indirizzato verso i moduli appena distribuiti. La versione stabile di questa chiamata apparirà così:

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

Ora verifichiamo il nostro rilascio canary. Per deployare la versione canary, dobbiamo tenere a mente due cose. Il nome del rilascio deve essere diverso, per evitare di sovrascrivere l'aggiornamento della versione stabile attuale. Anche la versione e il tag devono differire, per consentirci di distribuire codice diverso e identificare le differenze nei tag delle risorse.

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

Ecco, sostanzialmente, è tutto! Se pinghi il servizio, puoi vedere che l'aggiornamento canary instrada il traffico solo per una parte del tempo.

Se stai cercando strumenti di automazione per il deploy che includano la logica descritta, fai riferimento a Deliverybot e su strumenti di automazione Helm su GitHub. I chart Helm utilizzati per implementare il metodo descritto sopra si trovano su Github, qui. In generale, questa è stata una panoramica teorica su come realizzare l'automazione del deploy delle versioni canary nella pratica, con concetti e esempi specifici.

Fonte: habr.com