Az Istio+Kiali használata a Canary telepítés elindításához és megjelenítéséhez
Cikkek ebben a sorozatban
- (Ez a cikk)
- Kanári bevetés a Jenkins-X Istio Flagger használatával
Kanári bevetés
Reméljük, olvassa , ahol röviden elmagyaráztuk, hogy mik azok a Canary-telepítések, és bemutattuk, hogyan lehet ezeket szabványos Kubernetes-erőforrásokkal megvalósítani.
Azonos
És feltételezzük, hogy ennek a cikknek az elolvasásával már tudod, mi az Istio. Ha nem, akkor olvashatsz róla .
Jelentkezés tesztekre
Minden pod két tárolót tartalmaz: az alkalmazásunkat és az istio-proxyt.
Egy egyszerű tesztalkalmazást fogunk használni frontend-nginx és backend python podokkal. Az nginx pod egyszerűen átirányít minden kérést a háttér-podra, és proxyként működik. Részletek a következő yamlokban találhatók:
A tesztalkalmazás futtatása saját maga
Ha követni szeretné a példámat, és saját maga szeretné használni ezt a tesztalkalmazást, lásd .
Kezdeti üzembe helyezés
Amikor elindítjuk az első telepítést, azt látjuk, hogy az alkalmazásunk podjaiban csak 2 konténer van, vagyis az Istio oldalkocsi még csak megvalósítás alatt áll:
És látjuk az Istio Gateway Loadbalancert is a névtérben istio-system:
Forgalomgenerálás
A következő IP-címet használjuk a forgalom generálására, amelyet a frontend pod-ok fogadnak és továbbítanak a háttér-pod-okba:
while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done
Mi is hozzátesszük frontend.istio-test a hosts fájlunkba.
Tekintse meg a hálót a Kiali-n keresztül
Telepítettük a tesztalkalmazást és az Istio-t a Tracing, a Grafana, a Prometheus és a Kiali mellett (a részleteket lásd alább). ). Ezért a Kiali-t a következőn keresztül használhatjuk:
istioctl dashboard kiali # admin:admin
A Kiali megjeleníti az aktuális forgalmat a Mesh-en keresztül
Amint látjuk, a forgalom 100%-a a frontend szolgáltatásra irányul, majd a v1 címkével ellátott frontend podokra, mivel egy egyszerű nginx proxyt használunk, amely átirányítja a kéréseket a háttérszolgáltatáshoz, amely viszont a backend podokhoz irányítja át azokat. v1 címkével.
A Kiali remekül működik az Istio-val, és dobozos hálós renderelő megoldást kínál. Szuper.
Kanári bevetés
A háttérrendszerünk már rendelkezik két k8s-telepítéssel, egy a v1-hez és egy a v2-höz. Most már csak azt kell mondanunk az Istiónak, hogy a kérelmek bizonyos százalékát továbbítsa a v2-nek.
1. lépés: 10%
És csak annyit kell tennünk, hogy beállítjuk a VirtualService súlyát :
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
Azt látjuk, hogy a kérelmek 10%-a át van irányítva a 2-es verzióra.
2. lépés: 50%
És most elég csak 50%-ra növelni:
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%
Mostantól a Canary telepítése befejezettnek tekinthető, és az összes forgalom a v2-re van átirányítva:
A Canary manuális tesztelése
Tegyük fel, hogy most az összes kérés 2%-át a v10-es háttérrendszerre küldjük. Mi a teendő, ha manuálisan szeretnénk tesztelni a v2-t, hogy megbizonyosodjunk arról, hogy minden a várt módon működik?
Hozzáadhatunk egy speciális egyezési szabályt a HTTP-fejlécek alapján:
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íthetünk egy v2 kérést a fejléc elküldésével:
A fejléc nélküli kéréseket továbbra is az 1/10 arány határozza meg:
Kanári két függő változathoz
Most megfontoljuk azt a lehetőséget, ahol van v2-es verzió az előtérhez és a háttérhez egyaránt. Mindkettőnél megadtuk, hogy a forgalom 10%-ának a v2-re kell irányulnia:
Azt látjuk, hogy a frontend v1 és v2 egyaránt 1/10 arányban továbbítja a forgalmat a backend v1 és v2 felé.
Mi van akkor, ha a forgalmat a frontend-v2-ről csak a backend-v2-re kell továbbítanunk, mert az nem kompatibilis a v1-el? Ehhez beállítunk egy 1/10 arányt a frontend számára, amely egyeztetés segítségével szabályozza, hogy milyen forgalom jusson a backend-v2-re. 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: 100Ennek eredményeként azt kapjuk, amire szükségünk van:
Különbségek a manuális kanári megközelítéstől
В az első rész A Canary telepítését manuálisan hajtottuk végre, két k8s telepítéssel is. Ott szabályoztuk a kérések arányát a replikák számának változtatásával. Ez a megközelítés működik, de komoly hátrányai vannak.
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 például azt jelenti, hogy használhatunk HPA-kat (Horizontal Pod Autoscalers), és nem kell őket a Canary telepítésének aktuális állapota szerint konfigurálni.
Teljes
Az Istio nagyszerűen működik, és a Kiali-val együtt használva nagyon erőteljes kombinációt eredményez. A következő érdeklődési köröm a Spinnaker és az Istio kombinálása az automatizálás és a Canary elemzés érdekében.
Forrás: will.com