Kanarídreifing í Kubernetes #3: Istio

Notkun Istio+Kiali til að ræsa og sjá uppsetningu á Kanarí

Greinar í þessari röð

1. Kanarídreifing í Kubernetes #1: Gitlab CI
2. Kanarídreifing í Kubernetes #2: Argo útfærslur
3. (Þessi grein)
4. Canary Deployment með Jenkins-X Istio Flagger

Kanaríútsetning

Við vonum að þú lesir fyrri hluti, þar sem við útskýrðum stuttlega hvað Canary dreifing er og sýndum hvernig á að innleiða þær með því að nota staðlaða Kubernetes tilföng.

Sama

Og við gerum ráð fyrir að með því að lesa þessa grein veistu nú þegar hvað Istio er. Ef ekki, þá geturðu lesið um það hér.

Umsókn um próf

Hver belg inniheldur tvö ílát: forritið okkar og istio-proxy.

Við munum nota einfalt prófunarforrit með frontend-nginx og backend python belg. Nginx belgurinn mun einfaldlega beina hverri beiðni til bakenda belgsins og virka sem umboð. Upplýsingar er að finna í eftirfarandi yamls:

• frontend.yaml
• bakenda.yaml
• istio.yaml

Að keyra prófunarforritið sjálfur

Ef þú vilt fylgja fordæmi mínu og nota þetta prófunarforrit sjálfur, sjáðu verkefni readme.

Upphafleg dreifing

Þegar við ræsum fyrstu dreifinguna sjáum við að belg forritsins okkar eru aðeins með 2 ílát, það er að Istio hliðarvagninn er nýbúinn að innleiða:

Og við sjáum líka Istio Gateway Loadbalancer í nafnarýminu istio-system:

Umferðarsköpun

Við munum nota eftirfarandi IP til að búa til umferð sem verður móttekin af framendabelgunum og áframsend til bakendabelganna:

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

Við munum einnig bæta við frontend.istio-test í hýsingarskrána okkar.

Skoða Mesh í gegnum Kiali

Við settum upp prófunarforritið og Istio ásamt Tracing, Grafana, Prometheus og Kiali (sjá nánar hér að neðan). verkefni readme). Þess vegna getum við notað Kiali með:

istioctl dashboard kiali # admin:admin

Kiali sér fyrir núverandi umferð í gegnum Mesh

Eins og við sjáum fer 100% af umferðinni í framendaþjónustuna, síðan í framendabelg með merkinu v1, þar sem við erum að nota einfaldan nginx umboð sem vísar beiðnum yfir á bakendaþjónustuna, sem aftur vísar þeim yfir á bakendabelgina. með merki v1.

Kiali virkar frábærlega með Istio og býður upp á möskva flutningslausn. Bara frábært.

Kanaríútsetning

Bakendinn okkar hefur nú þegar tvær k8s dreifingar, eina fyrir v1 og eina fyrir v2. Nú þurfum við bara að segja Istio að framsenda ákveðið hlutfall af beiðnum til v2.

Skref 1: 10%

Og allt sem við þurfum að gera er að stilla þyngd VirtualService inn 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

Við sjáum að 10% beiðna er vísað til v2.

Skref 2: 50%

Og nú er nóg að hækka það í 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

Skref 3: 100%

Nú getur Canary dreifing talist lokið og allri umferð er vísað á v2:

Prófa Canary handvirkt

Segjum að við sendum núna 2% af öllum beiðnum til v10 bakenda. Hvað ef við viljum handvirkt prófa v2 til að ganga úr skugga um að allt virki eins og við búumst við?

Við getum bætt við sérstakri samsvörunarreglu byggða á HTTP hausum:

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

Nú þegar við notum krulla getum við þvingað fram v2 beiðni með því að senda hausinn:

Beiðnir án haus verða áfram knúnar áfram af 1/10 hlutfallinu:

Kanarí fyrir tvær háðar útgáfur

Nú munum við íhuga möguleikann þar sem við höfum útgáfu v2 fyrir bæði framenda og bakenda. Fyrir báða tilgreindum við að 10% af umferðinni ætti að fara í v2:

Við sjáum að framenda v1 og v2 báðir áfram umferð í hlutfallinu 1/10 til bakenda v1 og v2.

Hvað ef við þyrftum að senda umferð frá frontend-v2 aðeins yfir í backend-v2 vegna þess að það er ekki samhæft við v1? Til að gera þetta munum við setja 1/10 hlutfall fyrir framenda, sem stjórnar því hvaða umferð kemst í bakenda-v2 með samningaviðræðum 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

Fyrir vikið fáum við það sem við þurfum:

Mismunur frá handvirku Kanarí-aðferðinni

В fyrsti hluti Við framkvæmdum Canary dreifingu handvirkt, einnig með tveimur k8s dreifingum. Þar stjórnuðum við hlutfalli beiðna með því að breyta fjölda eftirmynda. Þessi aðferð virkar, en hefur alvarlega galla.

Istio gerir það mögulegt að ákvarða hlutfall beiðna óháð fjölda eftirmynda. Þetta þýðir til dæmis að við getum notað HPA (Horizontal Pod Autoscalers) og þurfum ekki að vera stillt í samræmi við núverandi stöðu Canary dreifingarinnar.

Samtals

Istio virkar frábærlega og að nota það ásamt Kiali skapar mjög öfluga samsetningu. Næst á listanum mínum yfir áhugamál er að sameina Spinnaker með Istio fyrir sjálfvirkni og greiningu á Kanarí.

Heimild: www.habr.com