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.
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
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
Fonte: habr.com