Istio+Kiali izmantoÅ”ana kanÄru izvietoÅ”anas palaiÅ”anai un vizualizÄÅ”anai
Å Ä« cikla raksti
- (Ŕis raksts)
- KanÄru izvietoÅ”ana, izmantojot Jenkins-X Istio Flagger
KanÄru izvietoÅ”ana
Ceram, ka jÅ«s lasÄ«jÄt , kurÄ mÄs Ä«si izskaidrojÄm, kas ir kanÄru izvietojumi un parÄdÄ«jÄm, kÄ to Ä«stenot ar standarta Kubernetes resursiem.
Istio
Un mÄs pieÅemam, ka, lasot Å”o rakstu, jÅ«s jau zinÄt, kas ir Istio. Ja nÄ, varat par to izlasÄ«t .
TestÄÅ”anas lietotne
Katrs pods satur divus konteinerus: mūsu lietotne un istio-proxy.
MÄs izmantosim vienkÄrÅ”u testÄÅ”anas lietotni ar pods frontend-nginx un backend uz python. Pods ar nginx vienkÄrÅ”i pÄradresÄs katru pieprasÄ«jumu uz podu ar backend un darbosies kÄ proxy. SÄ«kÄku informÄciju varat skatÄ«t nÄkamajos yaml failos:
TestÄÅ”anas lietotnes palaiÅ”ana patstÄvÄ«gi
Ja vÄlaties sekot manam piemÄram un izmantot Å”o testÄÅ”anas lietotni patstÄvÄ«gi, skatiet .
SÄkotnÄjÄ izvietoÅ”ana
Palaižot pirmo izvietoÅ”anu, mÄs redzam, ka mÅ«su lietotnes podiem ir tikai 2 konteineri, tÄtad Istio sidecar vÄl tikai tiek iekļauts:
Un mÄs arÄ« redzam Istio Gateway Loadbalancer telpÄ istio-system:
Satiksmes izveide
MÄs izmantosim nÄkamo IP, lai Ä£enerÄtu satiksmi, kuru frontend podi pieÅems un novirzÄ«s uz backend podiem:
while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done
MÄs arÄ« pievienosim frontend.istio-test mÅ«su hosts failam.
Mreža skatīŔana caur Kiali
MÄs esam uzstÄdÄ«juÅ”i testÄÅ”anas lietotni un Istio kopÄ ar Tracing, Grafana, Prometheus un Kiali (sÄ«kÄk skat. ). TÄpÄc mÄs varam izmantot Kiali caur:
istioctl dashboard kiali # admin:admin
Kiali vizualizÄ paÅ”reizÄjo satiksmi caur Mrežu
KÄ redzam, 100% satiksmes nonÄk frontend pakalpojumÄ, pÄc tam uz frontend podu ar etiketÄm v1, jo mÄs izmantojam vienkÄrÅ”u nginx proxy, kas novirza pieprasÄ«jumus uz backend pakalpojumu, kas savukÄrt novirza tos uz backend podiem ar etiketÄm v1.
Kiali lieliski darbojas kopÄ ar Istio un nodroÅ”ina ÄrkÄrtÄ«gi labu risinÄjumu Mrežas vizualizÄÅ”anai. VienkÄrÅ”i lieliski.
KanÄru izvietoÅ”ana
MÅ«su backend jau satur divus k8s izvietojumus, vienu v1 un vienu v2. Tagad mums vienkÄrÅ”i jÄsaka Istio novirzÄ«t noteiktu procentu pieprasÄ«jumu uz v2.
Solījums 1: 10%
Un viss, kas mums jÄdara, ir pielÄgot VirtualService svarus. :
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 
Redzam, ka 10% pieprasījumu tiek novirzīti uz v2.
2. solis: 50%
Un tagad pietiekami vienkÄrÅ”i palielinÄt to lÄ«dz 50%:
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. solis: 100%
Tagad Canary izvietojums var tikt uzskatīts par pabeigtu un viss satiksme tiek novirzīta uz v2:
Canary testÄÅ”ana manuÄli
PieÅemsim, ka mÄs tagad uz aizmuguri v2 nosÅ«tÄm 10% no visiem pieprasÄ«jumiem. Ko darÄ«t, ja vÄlamies manuÄli pÄrbaudÄ«t v2, lai pÄrliecinÄtos, ka viss darbojas kÄ gaidÄ«ts?
MÄs varam pievienot Ä«paÅ”u atbilstoÅ”u noteikumu, kas balstÄ«ts uz HTTP virsrakstiem:
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: 10Tagad, izmantojot curl, mÄs varam piespiest pieprasÄ«t v2, nosÅ«tot virsrakstu:
PieprasÄ«jumi bez virsraksta joprojÄm tiks pÄrvaldÄ«ti ar attiecÄ«bu 1/10:
Canary divÄm atkarÄ«gÄm versijÄm
Tagad mÄs aplÅ«kosim gadÄ«jumu, kad mums ir versija v2 gan priekÅ”Äjai, gan aizmugures daļai. Abiem mÄs norÄdÄ«jÄm, ka 10% satiksmes jÄiet v2:
Redzam, ka priekÅ”ÄjÄ versija v1 un v2 abi pÄrsÅ«ta satiksmi attiecÄ«bÄ 1/10 uz aizmugurÄjo v1 un v2.
Un ko darÄ«t, ja mums vajadzÄtu pÄrsÅ«tÄ«t satiksmi no frontend-v2 tikai uz backend-v2, jo tas nav savietojams ar v1? TÄdÄļ mÄs iestatÄ«sim attiecÄ«bu 1/10 priekÅ”Äjai daļai, kas kontrolÄ, kÄda satiksme nonÄk backend-v2, izmantojot saskaÅoÅ”anu pÄc 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: 100RezultÄtÄ mÄs iegÅ«stam to, kas nepiecieÅ”ams:
AtŔķirÄ«bas no manuÄlÄ Canary pieejas
No pirmajÄ daÄ¼Ä mÄs manuÄli veicÄm Canary izvietojumu, izmantojot divas k8s izvietojumus. Tur mÄs pÄrvaldÄ«jÄm pieprasÄ«jumu attiecÄ«bu, mainot repliku skaitu. Å Ä« pieeja darbojas, taÄu tai ir nopietnas trÅ«kumus.
Istio ļauj noteikt pieprasÄ«jumu attiecÄ«bu neatkarÄ«gi no repliku skaita. Tas nozÄ«mÄ, piemÄram, ka mÄs varam izmantot HPA (Horizontal Pod Autoscalers ā horizontÄlo podu automÄtisko mÄrogoÅ”anu) un to nav nepiecieÅ”ams konfigurÄt atbilstoÅ”i paÅ”reizÄjai Canary izvietojuma stÄvoklim.
RezultÄts
Istio darbojas lieliski, un, izmantojot to kopÄ ar Kiali, iegÅ«stam ļoti jaudÄ«gu kombinÄciju. NÄkamais manÄ intereÅ”u sarakstÄ ir kombinÄcija Spinnaker ar Istio automatizÄcijas un Canary analÄ«zei.
Avots: habr.com
