
A kanári telepítés nagyon hatékony módja az új kód tesztelésének egy adott felhasználói részhalmazon. Nagy mértékben csökkenti a forgalmi terhelést, amely problémákat okozhat a telepítési folyamat során, mivel ez csak egy adott alcsoport keretein belül történik. Ez a megjegyzés a Kubernetes és a telepítési automatizálás segítségével történő ilyen telepítés megszervezésére összpontosít. Feltételezzük, hogy tud néhány dolgot a Helmről és a Kubernetes erőforrásokról..

Egy egyszerű kanári telepítés a Kubernetesben két kulcsfontosságú erőforrást foglal magában: a szolgáltatást magát és a telepítési eszközt. A kanári telepítés egy olyan szolgáltatáson keresztül működik, amely két különböző erőforrással lép kapcsolatba, amelyek a frissítési forgalmat kezelik. Az egyik ezen erőforrások közül a „kanári” verzióval, a másik pedig a stabil változattal foglalkozik. Ebben az esetben szabályozhatjuk a kanári verziók számát, hogy csökkentsük az elérhető forgalmat. Például, ha a Yaml-t kívánja használni, akkor a Kubernetesben a következőképpen fog kinézni:
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 # A kiválasztó forgalmat irányít mindkét telepítéshez.Egy még egyszerűbb változatot a kubectl-n lehet elképzelni, és még van egy teljes körű útmutató is erre a forgatókönyvre. De a bejegyzés fő kérdése az, hogy hogyan automatizáljuk ezt a folyamatot a Helm használatával.
A kanári telepítés automatizálása
Először is szükségünk lesz egy Helm chart térképre, amely már tartalmazza a fentebb tárgyalt erőforrásokat. Körülbelül így kell kinéznie:
~\/charts\/app
├── Chart.yaml
├── README.md
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ └── service.yaml
└── values.yamlA Helm koncepciójának alapja a több verziós kiadások kezelése. A stabil verzió a projekt fő stabil kódágát jelenti. De a Helm segítségével telepíthetünk kanári kiadást a kísérleti kódunkkal. A legfontosabb dolog, hogy fenntartsuk a forgalom cseréjét a stabil verzió és a kanári kiadás között. Mindezt egy speciális kiválasztó segítségével fogjuk kezelni:
selector:
app.kubernetes.io\/name: myappA kanáris és a stabil telepítési erőforrásaink mind ezt a címkét fogják megjeleníteni a modulokon. Ha minden beállítást helyesen végzünk el, akkor a kanári verzió telepítésekor azt fogjuk látni, hogy a forgalom az újonnan telepített modulokra irányul. A stabil verzió így néz ki:
helm upgrade
--install myapp
--namespace default
--set app.name=myapp # Az app.kubernetes.io/name-be kerül
--set app.version=v1 # Az app.kubernetes.io/version-be kerül
--set image.tag=stable
--set replicaCount=5Most nézzük meg a kanári kiadásunkat. A kanári verzió telepítéséhez két dolgot kell észben tartanunk. A kiadás neve eltérő kell, hogy legyen, hogy ne frissítsük a jelenlegi stabil verziót. A verzió és a címke szintén eltérő kell, hogy legyen, hogy más kódot tudjunk telepíteni, és az erőforrások címkéin meg tudjuk határozni a különbségeket.
helm upgrade
--install myapp-canary
--namespace default
--set app.name=myapp # Az app.kubernetes.io/name-be kerül
--set app.version=v2 # Az app.kubernetes.io/version-be kerül
--set image.tag=canary
--set replicaCount=1Ez is igazából minden! Ha pingeljük a szolgáltatást, láthatjuk, hogy a kanári frissítés csak az idő egy részében irányítja a forgalmat.
Ha olyan automatizálási eszközöket keresel, amelyek tartalmazzák a leírt logikát, nézd meg a és . A fenti módszer megvalósításához használt Helm diagramok a GitHubon találhatóak, . Ez alapvetően egy elméleti áttekintés volt arról, hogyan lehet gyakorlatilag megvalósítani a kanári verziók automatikus telepítését, konkrét koncepciókkal és példákkal.
Forrás: habr.com
