Preprost in varen način za avtomatizacijo uvajanja Canary z uporabo Helma

Uvajanje Canary je zelo učinkovit način za preizkušanje nove kode na podskupini uporabnikov. Znatno zmanjša prometno obremenitev, ki je lahko problematična med postopkom uvajanja, saj se pojavi samo znotraj določenega podnabora. Ta opomba je namenjena temu, kako organizirati takšno uvajanje z uporabo Kubernetesa in avtomatizacije uvajanja. Predvidevamo, da veste nekaj o virih Helm in Kubernetes.



Preprosta uvedba Canary v Kubernetes vključuje dva ključna vira: samo storitev in orodje za uvajanje. Uvedba Canary deluje prek ene same storitve, ki sodeluje z dvema različnima viroma, ki služita prometu posodobitev. Eden od teh virov bo deloval z različico »kanarčka«, drugi pa s stabilno različico. V tej situaciji lahko reguliramo število kanarčkov, da zmanjšamo količino prometa, ki je potreben za storitev. Če na primer raje uporabljate Yaml, bo v Kubernetesu videti takole:

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.

Še lažje si je predstavljati to možnost z uporabo kubectl in v Dokumentacija Kubernetes Obstaja celo celotna vadnica o tem scenariju. Toda glavno vprašanje te objave je, kako bomo avtomatizirali ta proces s Helmom.

Avtomatizacija uvajanja kanarčkov

Najprej potrebujemo zemljevid karte Helm, ki že vključuje vire, o katerih smo govorili zgoraj. Videti bi moralo nekako takole:

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

Osnova koncepta Helm je upravljanje izdaj z več različicami. Stabilna različica je naša glavna stabilna veja kode projekta. Toda s Helmom lahko uvedemo kanarčkovo izdajo z našo eksperimentalno kodo. Glavna stvar je ohraniti izmenjavo prometa med stabilno različico in izdajo Canary. Vse to bomo upravljali s posebnim izbirnikom:

selector:
  app.kubernetes.io/name: myapp

Naši »kanarčki« in viri za stabilno uvajanje bodo na modulih označevali to oznako. Če je vse pravilno konfigurirano, bomo med uvajanjem kanarske različice našega zemljevida karte Helm videli, da bo promet usmerjen na novo nameščene module. Stabilna različica tega ukaza bo videti takole:

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

Zdaj pa preverimo našo izdajo kanarčka. Za uvedbo različice Canary se moramo spomniti dveh stvari. Ime izdaje mora biti drugačno, da ne uvedemo posodobitve na trenutno stabilno različico. Različica in oznaka morata biti tudi drugačna, da lahko uvedemo drugo kodo in prepoznamo razlike z oznakami virov.

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

To je vse! Če pingate storitev, lahko vidite, da kanarček posodablja promet le del časa.

Če iščete orodja za avtomatizacijo uvajanja, ki vključujejo opisano logiko, bodite pozorni na Deliverybot in Orodja za avtomatizacijo Helm na GitHubu. Helmovi grafikoni, uporabljeni za izvedbo zgoraj opisane metode, so na Githubu, tukaj. Na splošno je bil to teoretični pregled, kako v praksi implementirati avtomatizacijo uvajanja različic canary s konkretnimi koncepti in primeri.

Vir: www.habr.com