Canary տեղակայում Kubernetes #3. Istio

Օգտագործելով Istio+Kiali-ն՝ Canary-ի տեղակայումը գործարկելու և պատկերացնելու համար

Այս շարքի հոդվածները

1. Canary-ի տեղակայումը Kubernetes #1-ում. Gitlab CI
2. Canary-ի տեղակայում Kubernetes #2-ում. Argo Rollouts
3. (Այս հոդվածը)
4. Canary տեղակայում Jenkins-X Istio Flagger-ի միջոցով

Canary տեղակայում

Հուսով ենք, որ դուք կարդաք առաջին մաս, որտեղ մենք հակիրճ բացատրեցինք, թե ինչ են Canary-ի տեղակայումները և ցույց տվեցինք, թե ինչպես դրանք իրականացնել՝ օգտագործելով ստանդարտ Kubernetes ռեսուրսները:

Իստիո

Եվ մենք ենթադրում ենք, որ կարդալով այս հոդվածը, դուք արդեն գիտեք, թե ինչ է Իստիոն: Եթե ​​ոչ, ապա կարող եք կարդալ այդ մասին այստեղ.

Դիմում թեստերի համար

Յուրաքանչյուր պատիճ պարունակում է երկու կոնտեյներ՝ մեր հավելվածը և istio-proxy-ը:

Մենք կօգտագործենք պարզ թեստային հավելված՝ frontend-nginx և backend python pods-ով: Nginx pod-ը պարզապես վերահղելու է յուրաքանչյուր հարցումը backend pod և կաշխատի որպես վստահված անձ: Մանրամասները կարելի է գտնել հետևյալ յամլերում.

• frontend.yaml
• backend.yaml
• istio.yaml

Ինքներդ գործարկեք թեստային հավելվածը

Եթե ​​ցանկանում եք հետևել իմ օրինակին և ինքներդ օգտագործել այս թեստային հավելվածը, տես project readme.

Նախնական տեղակայում

Երբ մենք գործարկում ենք առաջին տեղակայումը, մենք տեսնում ենք, որ մեր հավելվածի պատիճներն ունեն ընդամենը 2 կոնտեյներ, այսինքն՝ Istio sidecar-ը նոր է իրականացվում.

Եվ մենք նաև տեսնում ենք Istio Gateway Loadbalancer անվանումների տարածքում istio-system:

Երթևեկության սերունդ

Մենք կօգտագործենք հետևյալ 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 մեր հյուրընկալող ֆայլին:

Դիտեք ցանցը Kiali-ի միջոցով

Մենք տեղադրեցինք թեստային հավելվածը և Istio-ն Tracing-ի, Grafana-ի, Prometheus-ի և Kiali-ի հետ միասին (մանրամասների համար տե՛ս ստորև): project readme) Այսպիսով, մենք կարող ենք օգտագործել Kiali-ն հետևյալի միջոցով.

istioctl dashboard kiali # admin:admin

Kiali-ն պատկերացնում է ընթացիկ երթևեկությունը ցանցի միջոցով

Ինչպես տեսնում ենք, թրաֆիկի 100%-ը գնում է դեպի ճակատային ծառայություն, այնուհետև՝ v1 պիտակով ֆրոնտենդ փոդեր, քանի որ մենք օգտագործում ենք պարզ nginx պրոքսի, որը վերահղում է հարցումները հետնախորշի ծառայությանը, որն էլ իր հերթին դրանք վերահղում է դեպի հետնախորշի պատյաններ: v1 պիտակով.

Kiali-ն հիանալի է աշխատում Istio-ի հետ և ապահովում է տուփով Mesh-ի մատուցման լուծում: Պարզապես հիանալի:

Canary տեղակայում

Մեր backend-ն արդեն ունի երկու k8s տեղակայում, մեկը v1-ի և մեկը v2-ի համար: Այժմ մենք պարզապես պետք է ասենք Istio-ին, որ հարցումների որոշակի տոկոս փոխանցի v2:

Քայլ 1: 10%

Եվ մեզ անհրաժեշտ է միայն կարգավորել VirtualService-ի քաշը 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

Մենք տեսնում ենք, որ հարցումների 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: 100%

Այժմ Canary-ի տեղակայումը կարելի է համարել ավարտված, և ամբողջ երթևեկությունը վերահղված է դեպի v2:

Canary-ի ձեռքով փորձարկում

Ենթադրենք, մենք այժմ ուղարկում ենք բոլոր հարցումների 2%-ը v10 backend-ին: Իսկ եթե մենք ցանկանում ենք ձեռքով փորձարկել 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

Այժմ, օգտագործելով curl-ը, մենք կարող ենք պարտադրել v2 հարցում՝ ուղարկելով վերնագիրը.

Առանց վերնագրի հարցումները դեռևս կառաջարկվեն 1/10 հարաբերակցությամբ.

Canary երկու կախյալ տարբերակների համար

Այժմ մենք կքննարկենք այն տարբերակը, որտեղ մենք ունենք v2 տարբերակը և՛ frontend-ի, և՛ backend-ի համար: Երկուսի համար էլ մենք նշել ենք, որ տրաֆիկի 10%-ը պետք է գնա v2.

Մենք տեսնում ենք, որ frontend v1 և v2 երկուսն էլ առաջադիմական երթևեկությունը 1/10 հարաբերակցությամբ դեպի backend v1 և v2:

Ի՞նչ կլիներ, եթե մեզ անհրաժեշտ լիներ թրաֆիկը փոխանցել frontend-v2-ից միայն backend-v2, քանի որ այն համատեղելի չէ v1-ի հետ: Դա անելու համար մենք կսահմանենք 1/10 հարաբերակցություն ճակատային մասի համար, որը վերահսկում է, թե ինչ երթևեկություն է հասնում 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

Արդյունքում մենք ստանում ենք այն, ինչ մեզ անհրաժեշտ է.

Տարբերությունները ձեռքով Canary մոտեցման

В առաջին մասը Մենք իրականացրել ենք Canary-ի տեղակայումը ձեռքով` օգտագործելով նաև k8s երկու տեղակայում: Այնտեղ մենք վերահսկում էինք հարցումների հարաբերակցությունը՝ փոխելով կրկնօրինակների քանակը։ Այս մոտեցումն աշխատում է, բայց ունի լուրջ թերություններ.

Istio-ն հնարավորություն է տալիս որոշել հարցումների հարաբերակցությունը՝ անկախ կրկնօրինակների քանակից։ Սա նշանակում է, օրինակ, որ մենք կարող ենք օգտագործել HPA-ներ (Horizontal Pod Autoscalers) և կարիք չկա այն կարգավորել ըստ Canary-ի տեղակայման ներկա վիճակի:

Լրիվ

Istio-ն հիանալի է աշխատում, և այն Kiali-ի հետ միասին օգտագործելը շատ հզոր համադրություն է ստեղծում: Հետաքրքրություններիս ցանկում հաջորդը Spinnaker-ի համատեղումն է Istio-ի հետ ավտոմատացման և Canary analytics-ի համար:

Source: www.habr.com