కుబెర్నెట్స్ #3లో కానరీ విస్తరణ: ఇస్టియో

కానరీ విస్తరణను ప్రారంభించడానికి మరియు దృశ్యమానం చేయడానికి Istio+Kialiని ఉపయోగించడం

కుబెర్నెట్స్ #3లో కానరీ విస్తరణ: ఇస్టియో

ఈ సిరీస్‌లోని కథనాలు

  1. కుబెర్నెట్స్ #1లో కానరీ విస్తరణ: గిట్లాబ్ CI
  2. కుబెర్నెటెస్ #2లో కానరీ విస్తరణ: అర్గో రోల్‌అవుట్‌లు
  3. (ఈ వ్యాసం)
  4. జెంకిన్స్-ఎక్స్ ఇస్టియో ఫ్లాగర్ ఉపయోగించి కానరీ విస్తరణ

కానరీ విస్తరణ

మీరు చదివారని ఆశిస్తున్నాము మొదటి భాగం, ఇక్కడ మేము కానరీ విస్తరణలు ఏమిటో క్లుప్తంగా వివరించాము మరియు ప్రామాణిక కుబెర్నెట్స్ వనరులను ఉపయోగించి వాటిని ఎలా అమలు చేయాలో చూపించాము.

ఇస్టియో

మరియు ఈ కథనాన్ని చదవడం ద్వారా మీకు ఇప్పటికే ఇస్టియో అంటే ఏమిటో తెలుసని మేము అనుకుంటాము. కాకపోతే, మీరు దాని గురించి చదువుకోవచ్చు ఇక్కడ.

పరీక్షల కోసం దరఖాస్తు

కుబెర్నెట్స్ #3లో కానరీ విస్తరణ: ఇస్టియో

ప్రతి పాడ్‌లో రెండు కంటైనర్‌లు ఉంటాయి: మా అప్లికేషన్ మరియు ఇస్టియో-ప్రాక్సీ.

మేము ఫ్రంటెండ్-nginx మరియు బ్యాకెండ్ పైథాన్ పాడ్‌లతో ఒక సాధారణ పరీక్ష అప్లికేషన్‌ను ఉపయోగిస్తాము. nginx పాడ్ ప్రతి అభ్యర్థనను బ్యాకెండ్ పాడ్‌కి మళ్లిస్తుంది మరియు ప్రాక్సీగా పని చేస్తుంది. వివరాలను క్రింది యమల్లో చూడవచ్చు:

పరీక్ష అప్లికేషన్‌ను మీరే అమలు చేస్తున్నారు

మీరు నా ఉదాహరణను అనుసరించాలనుకుంటే మరియు ఈ పరీక్ష అప్లికేషన్‌ను మీరే ఉపయోగించాలనుకుంటే, చూడండి ప్రాజెక్ట్ చదవండి.

ప్రారంభ విస్తరణ

మేము మొదటి విస్తరణను ప్రారంభించినప్పుడు, మా అప్లికేషన్ యొక్క పాడ్‌లు కేవలం 2 కంటైనర్‌లను మాత్రమే కలిగి ఉన్నాయని మేము చూస్తాము, అంటే, ఇస్టియో సైడ్‌కార్ ఇప్పుడే అమలు చేయబడుతోంది:

కుబెర్నెట్స్ #3లో కానరీ విస్తరణ: ఇస్టియో

మరియు మేము నేమ్‌స్పేస్‌లో ఇస్టియో గేట్‌వే లోడ్‌బ్యాలన్సర్‌ని కూడా చూస్తాము istio-system:

కుబెర్నెట్స్ #3లో కానరీ విస్తరణ: ఇస్టియో

ట్రాఫిక్ జనరేషన్

ఫ్రంటెండ్ పాడ్‌ల ద్వారా స్వీకరించబడే మరియు బ్యాకెండ్ పాడ్‌లకు ఫార్వార్డ్ చేయబడే ట్రాఫిక్‌ను రూపొందించడానికి మేము క్రింది IPని ఉపయోగిస్తాము:

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

మేము కూడా జోడిస్తాము frontend.istio-test మా హోస్ట్ ఫైల్‌కి.

కియాలీ ద్వారా మెష్‌ని వీక్షించండి

మేము ట్రేసింగ్, గ్రాఫానా, ప్రోమేథియస్ మరియు కియాలీతో పాటు టెస్ట్ అప్లికేషన్ మరియు ఇస్టియోను ఇన్‌స్టాల్ చేసాము (వివరాల కోసం క్రింద చూడండి). ప్రాజెక్ట్ చదవండి) కాబట్టి మనం కియాలీని దీని ద్వారా ఉపయోగించవచ్చు:

istioctl dashboard kiali # admin:admin

కుబెర్నెట్స్ #3లో కానరీ విస్తరణ: ఇస్టియో

కియాలీ మెష్ ద్వారా ప్రస్తుత ట్రాఫిక్‌ని దృశ్యమానం చేస్తుంది

మేము చూడగలిగినట్లుగా, 100% ట్రాఫిక్ ఫ్రంటెండ్ సేవకు వెళుతుంది, ఆపై v1 లేబుల్‌తో ఫ్రంటెండ్ పాడ్‌లకు వెళుతుంది, ఎందుకంటే మేము సాధారణ nginx ప్రాక్సీని ఉపయోగిస్తున్నాము, ఇది అభ్యర్థనలను బ్యాకెండ్ సేవకు దారి మళ్లిస్తుంది, ఇది వాటిని బ్యాకెండ్ పాడ్‌లకు దారి మళ్లిస్తుంది. లేబుల్ v1 తో.

కియాలీ ఇస్టియోతో అద్భుతంగా పనిచేస్తుంది మరియు బాక్స్‌డ్ మెష్ రెండరింగ్ సొల్యూషన్‌ను అందిస్తుంది. కేవలం గొప్ప.

కానరీ విస్తరణ

మా బ్యాకెండ్‌లో ఇప్పటికే రెండు k8s విస్తరణలు ఉన్నాయి, ఒకటి v1 కోసం మరియు ఒకటి v2 కోసం. ఇప్పుడు మనం కొంత శాతం అభ్యర్థనలను v2కి ఫార్వార్డ్ చేయమని ఇస్టియోకి చెప్పాలి.

దశ 1: 10%

మరియు మనం చేయాల్సిందల్లా వర్చువల్ సర్వీస్ యొక్క బరువును సర్దుబాటు చేయడం istio.yaml:

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

కుబెర్నెట్స్ #3లో కానరీ విస్తరణ: ఇస్టియో

10% అభ్యర్థనలు v2కి దారి మళ్లించబడినట్లు మేము చూస్తున్నాము.

దశ 2: 50%

మరియు ఇప్పుడు దానిని 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లో కానరీ విస్తరణ: ఇస్టియో

దశ 3: 100%

ఇప్పుడు కానరీ విస్తరణ పూర్తయినట్లుగా పరిగణించబడుతుంది మరియు మొత్తం ట్రాఫిక్ v2కి మళ్లించబడుతుంది:

కుబెర్నెట్స్ #3లో కానరీ విస్తరణ: ఇస్టియో

కానరీని మాన్యువల్‌గా పరీక్షిస్తోంది

మేము ఇప్పుడు అన్ని అభ్యర్థనలలో 2% v10 బ్యాకెండ్‌కి పంపుతామని అనుకుందాం. మనం ఆశించిన విధంగా ప్రతిదీ పని చేస్తుందని నిర్ధారించుకోవడానికి v2ని మాన్యువల్‌గా పరీక్షించాలనుకుంటే ఏమి చేయాలి?

మేము HTTP హెడర్‌ల ఆధారంగా ప్రత్యేక మ్యాచింగ్ నియమాన్ని జోడించవచ్చు:

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: 10

ఇప్పుడు కర్ల్‌ని ఉపయోగించి మనం హెడర్‌ని పంపడం ద్వారా v2 అభ్యర్థనను బలవంతం చేయవచ్చు:

కుబెర్నెట్స్ #3లో కానరీ విస్తరణ: ఇస్టియో

హెడర్ లేని అభ్యర్థనలు ఇప్పటికీ 1/10 నిష్పత్తితో నడపబడతాయి:

కుబెర్నెట్స్ #3లో కానరీ విస్తరణ: ఇస్టియో

రెండు డిపెండెంట్ వెర్షన్‌ల కోసం కానరీ

ఇప్పుడు మనం ఫ్రంటెండ్ మరియు బ్యాకెండ్ రెండింటికీ వెర్షన్ v2 ఉన్న ఎంపికను పరిశీలిస్తాము. రెండింటికీ, ట్రాఫిక్‌లో 10% v2కి వెళ్లాలని మేము పేర్కొన్నాము:

కుబెర్నెట్స్ #3లో కానరీ విస్తరణ: ఇస్టియో

మేము ఆ ఫ్రంటెండ్ v1 మరియు v2 రెండూ 1/10 బ్యాకెండ్ v1 మరియు v2 నిష్పత్తిలో ఫార్వర్డ్ ట్రాఫిక్‌ని చూస్తాము.

మేము ట్రాఫిక్‌ను ఫ్రంటెండ్-v2 నుండి బ్యాకెండ్-v2కి మాత్రమే ఫార్వార్డ్ చేయవలసి వస్తే, అది v1కి అనుకూలంగా లేదు? దీన్ని చేయడానికి, మేము ఫ్రంటెండ్ కోసం 1/10 నిష్పత్తిని సెట్ చేస్తాము, ఇది సంధిని ఉపయోగించి బ్యాకెండ్-v2కి వచ్చే ట్రాఫిక్‌ని నియంత్రిస్తుంది 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

ఫలితంగా, మనకు అవసరమైన వాటిని పొందుతాము:

కుబెర్నెట్స్ #3లో కానరీ విస్తరణ: ఇస్టియో

మాన్యువల్ కానరీ విధానం నుండి తేడాలు

В మొదటి భాగం మేము కానరీ విస్తరణను మాన్యువల్‌గా చేసాము, రెండు k8s విస్తరణలను కూడా ఉపయోగిస్తాము. అక్కడ మేము ప్రతిరూపాల సంఖ్యను మార్చడం ద్వారా అభ్యర్థనల నిష్పత్తిని నియంత్రించాము. ఈ విధానం పనిచేస్తుంది, కానీ తీవ్రమైన లోపాలు ఉన్నాయి.

ప్రతిరూపాల సంఖ్యతో సంబంధం లేకుండా అభ్యర్థనల నిష్పత్తిని గుర్తించడాన్ని ఇస్టియో సాధ్యం చేస్తుంది. దీని అర్థం, ఉదాహరణకు, మేము HPAలను (క్షితిజసమాంతర పాడ్ ఆటోస్కేలర్లు) ఉపయోగించవచ్చు మరియు కానరీ విస్తరణ యొక్క ప్రస్తుత స్థితికి అనుగుణంగా కాన్ఫిగర్ చేయవలసిన అవసరం లేదు.

ఫలితం

ఇస్టియో అద్భుతంగా పని చేస్తుంది మరియు కియాలీతో కలిపి ఉపయోగించడం చాలా శక్తివంతమైన కలయికగా మారుతుంది. నా ఆసక్తుల జాబితాలో తదుపరిది ఆటోమేషన్ మరియు కానరీ అనలిటిక్స్ కోసం స్పిన్నకర్‌ని ఇస్టియోతో కలపడం.

మూలం: www.habr.com

ఒక వ్యాఖ్యను జోడించండి