Canary implementacija je vrlo učinkovit način testiranja novog koda na podskupu korisnika. Značajno smanjuje prometno opterećenje koje može biti problematično tijekom procesa implementacije jer se događa samo unutar određenog podskupa. Ova je bilješka posvećena tome kako organizirati takvu implementaciju pomoću Kubernetesa i automatizacije implementacije. Pretpostavljamo da znate nešto o resursima Helma i Kubernetesa.
Jednostavna Canary implementacija na Kubernetes uključuje dva ključna resursa: samu uslugu i alat za implementaciju. Canary implementacija funkcionira putem jedne usluge koja komunicira s dva različita resursa koji opslužuju promet ažuriranja. Jedan od ovih resursa radit će s verzijom "canary", a drugi će raditi sa stabilnom verzijom. U ovoj situaciji možemo regulirati broj canary verzija kako bismo smanjili količinu prometa potrebnog za posluživanje. Ako, na primjer, više volite koristiti Yaml, onda će to 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
Automatizacija postavljanja kanarčića
Prije svega, potrebna nam je karta karte Helm, 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 koncepta Helm je upravljanje izdanjima s više verzija. Stabilna verzija je naša glavna stabilna grana koda projekta. Ali s Helmom možemo implementirati Canary izdanje s našim eksperimentalnim kodom. Glavna stvar je održavati razmjenu prometa između stabilne verzije i izdanja Canary. Sve to ćemo upravljati pomoću posebnog selektora:
selector:
app.kubernetes.io/name: myapp
Naši "kanarinac" i resursi za stabilnu implementaciju će naznačiti ovu oznaku na modulima. Ako je sve ispravno konfigurirano, tada ćemo tijekom implementacije canary verzije naše Helm karte karte vidjeti da će promet biti usmjeren na novo postavljene module. Stabilna verzija ove naredbe izgledat će 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. Naziv izdanja mora biti drugačiji kako ne bismo pokrenuli ažuriranje na trenutnu stabilnu verziju. Verzija i oznaka također moraju biti različite kako bismo mogli implementirati drugi kod i identificirati razlike pomoću oznaka 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 pingate 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 pozornost na
Izvor: www.habr.com