Usambazaji wa Canary katika Kubernetes #3: Istio

Kwa kutumia Istio+Kiali kuzindua na kuibua taswira ya usambazaji wa Canary

Makala katika mfululizo huu

1. Usambazaji wa Canary katika Kubernetes #1: Gitlab CI
2. Usambazaji wa Canary katika Kubernetes #2: Utoaji wa Argo
3. (Makala hii)
4. Usambazaji wa Canary kwa kutumia Bendera ya Jenkins-X Istio

Usambazaji wa Canary

Tunatumai umesoma sehemu ya kwanza, ambapo tulielezea kwa ufupi upelekaji wa Canary ni nini na tukaonyesha jinsi ya kutekeleza kwa kutumia rasilimali za Kubernetes za kawaida.

Istio

Na tunadhani kwamba kwa kusoma makala hii tayari unajua Istio ni nini. Ikiwa sio, basi unaweza kusoma juu yake hapa.

Maombi ya vipimo

Kila ganda lina vyombo viwili: maombi yetu na istio-proksi.

Tutatumia programu rahisi ya majaribio na frontend-nginx na maganda ya python ya nyuma. Seti ya nginx itaelekeza upya kila ombi kwa ganda la nyuma na kufanya kazi kama proksi. Maelezo yanaweza kupatikana katika viazi vikuu vifuatavyo:

• mbele.yaml
• backend.yaml
• istio.yaml

Kuendesha maombi ya mtihani mwenyewe

Ikiwa unataka kufuata mfano wangu na utumie programu tumizi hii mwenyewe, ona soma mradi.

Usambazaji wa Awali

Tunapozindua Usambazaji wa kwanza, tunaona kwamba maganda ya programu yetu yana kontena 2 pekee, yaani, Istio sidecar inatekelezwa hivi punde:

Na pia tunaona Istio Gateway Loadbalancer kwenye nafasi ya majina istio-system:

Kizazi cha trafiki

Tutatumia IP ifuatayo kuzalisha trafiki ambayo itapokelewa na maganda ya mbele na kutumwa kwa maganda ya nyuma:

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

Pia tutaongeza frontend.istio-test kwa faili ya mwenyeji wetu.

Tazama Mesh kupitia Kiali

Tulisakinisha programu ya majaribio na Istio pamoja na Tracing, Grafana, Prometheus na Kiali (tazama hapa chini kwa maelezo zaidi). soma mradi) Kwa hivyo tunaweza kutumia Kiali kupitia:

istioctl dashboard kiali # admin:admin

Kiali anaonyesha trafiki ya sasa kupitia Mesh

Kama tunavyoona, 100% ya trafiki huenda kwa huduma ya mbele, kisha kwa maganda ya mbele na lebo v1, kwa kuwa tunatumia proksi rahisi ya nginx ambayo inaelekeza maombi kwa huduma ya nyuma, ambayo nayo inawaelekeza kwenye maganda ya nyuma. yenye lebo v1.

Kiali hufanya kazi vizuri na Istio na hutoa suluhisho la utoaji la Mesh lililowekwa sanduku. Kubwa tu.

Usambazaji wa Canary

Backend yetu tayari ina uwekaji wa k8s mbili, moja kwa v1 na moja kwa v2. Sasa tunahitaji tu kumwambia Istio kusambaza asilimia fulani ya maombi kwa v2.

Hatua ya 1: 10%

Na tunachohitaji kufanya ni kurekebisha uzito wa VirtualService in 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

Tunaona kwamba 10% ya maombi yanaelekezwa kwenye v2.

Hatua ya 2: 50%

Na sasa inatosha tu kuiongeza hadi 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

Hatua ya 3: 100%

Sasa uwekaji wa Canary unaweza kuchukuliwa kuwa kamili na trafiki yote inaelekezwa kwa v2:

Kujaribu Canary manually

Hebu tuseme sasa tunatuma 2% ya maombi yote kwa v10 backend. Je, ikiwa tunataka kujaribu v2 mwenyewe ili kuhakikisha kuwa kila kitu kinafanya kazi kama tunavyotarajia?

Tunaweza kuongeza sheria maalum ya kulinganisha kulingana na vichwa vya 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

Sasa kwa kutumia curl tunaweza kulazimisha ombi la v2 kwa kutuma kichwa:

Maombi yasiyo na kichwa bado yataendeshwa na uwiano wa 1/10:

Canary kwa matoleo mawili tegemezi

Sasa tutazingatia chaguo ambapo tuna toleo la v2 kwa mandhari ya mbele na ya nyuma. Kwa zote mbili, tulibainisha kuwa 10% ya trafiki inapaswa kwenda kwa v2:

Tunaona kwamba mandhari ya mbele v1 na v2 zote zinasambaza trafiki kwa uwiano wa 1/10 kwa v1 na v2.

А что если бы мы нам было нужно пересылать трафик с frontend-v2 только на backend-v2, потому что он не совместим с v1? Для этого мы установим 1/10 соотношение для frontend, который контролирует какой трафик попадает на backend-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

Kama matokeo, tunapata kile tunachohitaji:

Tofauti kutoka kwa njia ya mwongozo ya Canary

В sehemu ya kwanza Tulifanya uwekaji wa Canary kwa mikono, pia kwa kutumia uwekaji wa k8 mbili. Hapo tulidhibiti uwiano wa maombi kwa kubadilisha idadi ya nakala. Njia hii inafanya kazi, lakini ina mapungufu makubwa.

Istio inafanya uwezekano wa kuamua uwiano wa maombi bila kujali idadi ya nakala. Hii inamaanisha, kwa mfano, kwamba tunaweza kutumia HPAs (Horizontal Pod Autoscalers) na hatuhitaji kusanidiwa kulingana na hali ya sasa ya uwekaji wa Canary.

Jumla ya

Istio inafanya kazi vizuri na kuitumia pamoja na Kiali hutengeneza mchanganyiko wenye nguvu sana. Inayofuata kwenye orodha yangu ya masilahi ni kuchanganya Spinnaker na Istio kwa otomatiki na uchanganuzi wa Canary.

Chanzo: mapenzi.com