Una manera senzilla i segura d'automatitzar els desplegaments canaris amb Helm

El desplegament de Canary és una manera molt eficaç de provar codi nou en un subconjunt d'usuaris. Redueix significativament la càrrega de trànsit que pot ser problemàtica durant el procés de desplegament, ja que només es produeix dins d'un subconjunt específic. Aquesta nota està dedicada a com organitzar aquest desplegament mitjançant Kubernetes i l'automatització del desplegament. Suposem que sabeu alguna cosa sobre els recursos de Helm i Kubernetes.



Un simple desplegament canari a Kubernetes inclou dos recursos clau: el propi servei i l'eina de desplegament. El desplegament de Canary funciona mitjançant un únic servei que interactua amb dos recursos diferents que serveixen el trànsit d'actualització. Un d'aquests recursos funcionarà amb la versió "canària", i el segon funcionarà amb la versió estable. En aquesta situació, podem regular el nombre de versions canàries per tal de reduir el trànsit necessari per servir. Si, per exemple, preferiu utilitzar Yaml, a Kubernetes es veurà així:

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.

És encara més fàcil imaginar aquesta opció utilitzant kubectl i en Documentació de Kubernetes Fins i tot hi ha un tutorial complet sobre aquest escenari. Però la pregunta principal d'aquesta publicació és com automatitzarem aquest procés amb Helm.

Automatització del desplegament canari

En primer lloc, necessitem un mapa de gràfics Helm, que ja inclou els recursos que hem comentat anteriorment. Hauria de semblar una cosa així:

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

La base del concepte Helm és la gestió de llançaments multiversió. La versió estable és la nostra branca estable principal del codi del projecte. Però amb Helm podem implementar una versió canària amb el nostre codi experimental. El més important és mantenir l'intercanvi de trànsit entre la versió estable i la versió canària. Tot això ho gestionarem mitjançant un selector especial:

selector:
  app.kubernetes.io/name: myapp

Els nostres recursos de desplegament "canaris" i estables indicaran aquesta etiqueta als mòduls. Si tot està configurat correctament, durant el desplegament de la versió canària del nostre mapa gràfic Helm veurem que el trànsit es dirigirà als mòduls recentment desplegats. La versió estable d'aquesta ordre tindrà aquest aspecte:

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

Ara comprovem el nostre llançament canari. Per desplegar la versió canària, hem de recordar dues coses. El nom de la versió ha de ser diferent perquè no puguem llançar una actualització a la versió estable actual. La versió i l'etiqueta també han de ser diferents perquè puguem desplegar un altre codi i identificar diferències per etiquetes de recursos.

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

Això és tot! Si feu ping al servei, podreu veure que l'actualització canària encamina el trànsit només una part del temps.

Si busqueu eines d'automatització de desplegament que incloguin la lògica descrita, presteu atenció a Deliverybot i Eines d'automatització de Helm a GitHub. Els gràfics Helm utilitzats per implementar el mètode descrit anteriorment es troben a Github, aquí. En general, es tractava d'una visió general teòrica de com implementar a la pràctica l'automatització del desplegament de versions canàries, amb conceptes i exemples específics.

Font: www.habr.com