Az Istio+Kiali használata Canary telepítés indításához és vizualizálásához
Ezek a ciklus cikkek
- (ez a cikk)
- Canary telepítés Jenkins-X Istio Flagger segítségével
Canary Deployment
Reméljük, hogy olvastad , ahol röviden elmagyaráztuk, mi az a Canary telepítés és bemutattuk, hogyan valósítható meg a Kubernetes alapértelmezett erőforrásaival.
Istio
Feltételezzük, hogy a cikk olvasásakor már tudod, mi az az Istio. Ha nem, akkor olvashatsz róla .
Tesztelési alkalmazás
Minden pod két konténert tartalmaz: a mi alkalmazásunkat és az istio-proxy-t.
Egyszerű tesztelő alkalmazást fogunk használni frontend-nginx és python háttér podokkal. Az nginx pod egyszerűen átirányít minden kérést a háttér podra, és proxyként működik. A részletek a következő yamlekben találhatók:
A tesztelő alkalmazás önálló indítása
Ha követni szeretnéd a példámat, és önállóan szeretnéd használni ezt a tesztelő alkalmazást, lásd a .
Kezdeti Deployment
Amikor az első Deploymentet elindítjuk, látjuk, hogy az alkalmazásunk podjai mindössze 2 konténert tartalmaznak, tehát az Istio sidecar még csak most kezd el integrálódni:
És azt is látjuk, hogy Istio Gateway Loadbalancer található a namespace-ben istio-system:
Forgalom létrehozása
A következő IP-t fogjuk használni forgalom generálására, amelyet a frontend podok fognak fogadni és a háttér podokra irányítani:
while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done
Hozzáadunk még frontend.istio-test a hosts fájlunkhoz.
A Mesh megtekintése a Kiali-n keresztül
Telepítettük a tesztelő alkalmazást és az Istio-t a Tracing, Grafana, Prometheus és Kiali segítségével (további részletekért lásd: ). Tehát használhatjuk a Kiali-t a következőképpen:
istioctl dashboard kiali # admin:admin
A Kiali vizualizálja a jelenlegi forgalmat a Mesh-en
Ahogy látjuk, a forgalom 100%-a a frontend szolgáltatásra jut, majd a frontend podra v1 labellel, mivel egyszerű nginx proxy-t használunk, amely a kérdéseket a háttér szolgáltatásra irányítja, amely viszont a v1 labellel rendelkező háttér podokra irányítja azokat.
A Kiali remekül működik az Istio-val együtt, és dobozból kapható megoldást nyújt a Mesh vizualizálásához. Egyszerűen nagyszerű.
Canary Deployment
A háttér már két k8s deploymenttel rendelkezik, egy a v1-hez és egy a v2-höz. Most csak annyit kell tennünk, hogy megmondjuk az Istio-nak, hogy a kérések egy adott százalékát irányítsa a v2-re.
1. lépés: 10%
És mindössze annyit kell tennünk, hogy beállítjuk a VirtualService súlyát a :
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: backend
namespace: default
spec:
gateways: []
hosts:
- "backend.default.svc.cluster.local"
http:
- match:
- {}
route:
- destination:
host: backend.default.svc.cluster.local
subset: v1
port:
number: 80
weight: 90
- destination:
host: backend.default.svc.cluster.local
subset: v2
port:
number: 80
weight: 10 
Látjuk, hogy a kérések 10%-a átirányítva van a v2-re.
2. lépés: 50%
Most pedig elegendő egyszerűen 50%-ra emelni:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: backend
namespace: default
spec:
...
- destination:
host: backend.default.svc.cluster.local
subset: v1
port:
number: 80
weight: 50
- destination:
host: backend.default.svc.cluster.local
subset: v2
port:
number: 80
weight: 50 
3. lépés: 100%
Most a Canary telepítést befejezettnek tekinthetjük, és az összes forgalom a v2-re irányul:
Manuális Canary tesztelés
Tegyük fel, hogy most a v2 backendre a kérések 10%-át küldjük. Mi van, ha manuálisan szeretnénk tesztelni a v2-t, hogy megbizonyosodjunk róla, minden úgy működik, ahogy elvárjuk?
Hozzáadhatunk egy speciális szabályt, amely az HTTP fejléceken alapul:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: backend
namespace: default
spec:
gateways: []
hosts:
- "backend.default.svc.cluster.local"
http:
- match:
- headers:
canary:
exact: "canary-tester"
route:
- destination:
host: backend.default.svc.cluster.local
subset: v2
port:
number: 80
weight: 100
- match:
- {}
route:
- destination:
host: backend.default.svc.cluster.local
subset: v1
port:
number: 80
weight: 90
- destination:
host: backend.default.svc.cluster.local
subset: v2
port:
number: 80
weight: 10Most a curl használatával kényszerített kérés küldhetünk a v2-re, elküldve a fejet:
A fejléc nélküli kérések továbbra is az 1/10 arányban lesznek kezelve:
Canary a két függő verzióhoz
Most nézzünk meg egy olyan helyzetet, ahol van v2 verziónk mind a frontend, mind a backend számára. Mindkét esetben megadtuk, hogy a forgalom 10%-ának a v2-re kell mennie:
Látjuk, hogy a frontend v1 és v2 egyaránt 1/10 arányban irányít forgalmat a backend v1 és v2 felé.
Mi van, ha a forgalmat a frontend-v2-ről csak a backend-v2-re akarjuk irányítani, mert az nem kompatibilis a v1-el? Ehhez 1/10 arányt állítunk be a frontend számára, ami meghatározza, hogy melyik forgalom jut a backend-v2-re, az egyesítés segítségével: sourceLabels :
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: backend
namespace: default
spec:
gateways: []
hosts:
- "backend.default.svc.cluster.local"
http:
...
- match:
- sourceLabels:
app: frontend
version: v2
route:
- destination:
host: backend.default.svc.cluster.local
subset: v2
port:
number: 80
weight: 100Így elérjük, amire szükség van:
Különbségek a kézi Canary megközelítéstől
A első részben Manuálisan hajtottuk végre a Canary telepítést, szintén két k8s telepítést használva. Ott a kérések arányát kezeltük a replikák számának módosításával. Ez a megközelítés működik, de komoly hátrányokkal bír.
Az Istio lehetővé teszi a kérések arányának meghatározását a replikák számától függetlenül. Ez azt jelenti, például, hogy használhatjuk a HPAs-t (Horizontal Pod Autoscalers — vízszintes pod skálázás) és nem szükséges a beállítását a Canary telepítés aktuális állapotához igazítani.
Result
Az Istio remekül működik, és a Kialival együtt egy nagyon erőteljes kombinációt kapunk. A következő érdeklődési területem az Istio és a Spinnaker kombinációja az automatizálás és a Canary elemzés érdekében.
Forrás: habr.com
