Jednostavan i siguran način za automatizaciju implementacije kanarinca pomoću Helm-a

Canary implementacija je vrlo efikasan način testiranja novog koda na podskupu korisnika. Značajno smanjuje prometno opterećenje koje može biti problematično tokom implementacije jer se javlja samo unutar određenog podskupa. Ova napomena je posvećena tome kako organizirati takvu implementaciju koristeći Kubernetes i automatizaciju implementacije. Pretpostavljamo da znate nešto o Helm i Kubernetes resursima.



Jednostavna kanarinska implementacija u Kubernetes uključuje dva ključna resursa: samu uslugu i alat za implementaciju. Canary implementacija radi kroz jednu uslugu koja je u interakciji s dva različita resursa koji opslužuju promet ažuriranja. Jedan od ovih resursa će raditi sa verzijom "kanarinca", a drugi sa stabilnom verzijom. U ovoj situaciji možemo regulirati broj verzija kanarinca kako bismo smanjili količinu prometa potrebnog za opsluživanje. Ako, na primjer, više volite koristiti Yaml, to će izgledati ovako u Kubernetesu:

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.

Još je lakše zamisliti ovu opciju koristeći kubectl i in Kubernetes dokumentacija Postoji čak i kompletan vodič o ovom scenariju. Ali glavno pitanje ovog posta je kako ćemo automatizirati ovaj proces koristeći Helm.

Automatizacija postavljanja kanarinca

Prije svega, potrebna nam je Helmova karta, koja već uključuje resurse o kojima smo gore govorili. Trebalo bi izgledati otprilike ovako:

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

Osnova Helm koncepta je upravljanje viševerzijskim izdanjima. Stabilna verzija je naša glavna stabilna grana koda projekta. Ali s Helmom možemo implementirati kanarinac s našim eksperimentalnim kodom. Glavna stvar je održavati razmjenu prometa između stabilne verzije i izdanja Canary. Sve ovo ćemo upravljati pomoću posebnog selektora:

selector:
  app.kubernetes.io/name: myapp

Naši "kanarinci" i stabilni resursi za implementaciju će označiti ovu oznaku na modulima. Ako je sve ispravno konfigurisano, tada ćemo tokom implementacije canary verzije naše Helm chart mape vidjeti da će promet biti usmjeren na novopostavljene module. Stabilna verzija ove naredbe će izgledati ovako:

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

Sada provjerimo naše izdanje kanarinca. Da bismo implementirali verziju Canary, moramo zapamtiti dvije stvari. Ime izdanja mora biti drugačije kako ne bismo izbacili ažuriranje na trenutnu stabilnu verziju. Verzija i oznaka također moraju biti različite kako bismo mogli primijeniti drugi kod i identificirati razlike prema oznakama resursa.

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 sve! Ako pingujete uslugu, možete vidjeti da canary update usmjerava promet samo dio vremena.

Ako tražite alate za automatizaciju implementacije koji uključuju opisanu logiku, obratite pažnju na Deliverybot i dalje Alati za automatizaciju Helm-a na GitHubu. Helmove karte koje se koriste za implementaciju gore opisane metode nalaze se na Githubu, ovde. Generalno, ovo je bio teorijski pregled kako implementirati automatizaciju implementacije canary verzija u praksi, sa konkretnim konceptima i primjerima.

izvor: www.habr.com