Kubernetes #3 တွင် Canary ဖြန့်ကျက်မှု- Istio

Canary ဖြန့်ကျက်မှုကို စတင်ရန်နှင့် မြင်ယောင်ရန် Istio+Kiali ကို အသုံးပြုခြင်း။

ဤစီးရီးရှိ ဆောင်းပါးများ

1. Kubernetes #1 တွင် Canary ဖြန့်ကျက်မှု- Gitlab CI
2. Kubernetes #2 တွင် Canary ဖြန့်ကျက်မှု- Argo ဖြန့်ချိမှုများ
3. (ဤဆောင်ပါး)
4. Jenkins-X Istio Flagger ကို အသုံးပြု၍ Canary ဖြန့်ကျက်ခြင်း။

Canary ဖြန့်ကျက်

သင်ဖတ်ဖို့မျှော်လင့်ပါတယ်။ ပထမပိုင်းCanary ဖြန့်ကျက်မှုများသည် အဘယ်အရာဖြစ်သည်ကို အတိုချုံးရှင်းပြပြီး စံ Kubernetes အရင်းအမြစ်များကို အသုံးပြု၍ ၎င်းတို့ကို အကောင်အထည်ဖော်နည်းကို ပြသခဲ့သည်။

Istio

ပြီးတော့ ဒီဆောင်းပါးကိုဖတ်ခြင်းအားဖြင့် Istio ဆိုတာကို သင်သိပြီးသားလို့ ယူဆတယ်။ မဟုတ်ရင် အဲဒီအကြောင်းကို ဖတ်နိုင်ပါတယ်။ ဒီမှာ.

စာမေးပွဲများအတွက်လျှောက်လွှာ

ဘူးတစ်ခုစီတွင် ကျွန်ုပ်တို့၏လျှောက်လွှာနှင့် istio-proxy ကွန်တိန်နာနှစ်ခုပါရှိသည်။

frontend-nginx နှင့် backend python pods များပါရှိသော ရိုးရှင်းသော စမ်းသပ်အက်ပ်ကို ကျွန်ုပ်တို့ အသုံးပြုပါမည်။ nginx pod သည် တောင်းဆိုမှုတစ်ခုစီကို backend pod သို့ ရိုးရှင်းစွာပြန်ညွှန်းပြီး proxy တစ်ခုအဖြစ် လုပ်ဆောင်မည်ဖြစ်သည်။ အသေးစိတ်အချက်အလက်များကို အောက်ပါပုံများတွင် ကြည့်ရှုနိုင်ပါသည်။

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

စမ်းသပ်လျှောက်လွှာကို ကိုယ်တိုင်လုပ်ဆောင်ပါ။

ငါ့နမူနာကို လိုက်နာပြီး ဒီစမ်းသပ်မှုအပလီကေးရှင်းကို ကိုယ်တိုင်အသုံးပြုချင်ရင် ကြည့်ပါ။ ပရောဂျက်ဖတ်ပါ။.

ကနဦး ဖြန့်ကျက်မှု

ကျွန်ုပ်တို့ ပထမဆုံး ဖြန့်ကျက်မှုကို စတင်သောအခါတွင်၊ ကျွန်ုပ်တို့၏ အပလီကေးရှင်း၏ pods များတွင် ကွန်တိန်နာ 2 ခုသာ ရှိသည်၊ ဆိုလိုသည်မှာ Istio sidecar ကို ယခုမှ အကောင်အထည် ဖော်နေခြင်းဖြစ်သည်-

နောက်ပြီး namespace ထဲမှာ Istio Gateway Loadbalancer ကိုလည်းတွေ့ရမှာပါ။ istio-system:

အသွားအလာမျိုးဆက်

frontend pods များမှ လက်ခံရရှိပြီး backend pods များသို့ ထပ်ဆင့်ပို့မည့် traffic ကို ဖန်တီးရန်အတွက် အောက်ပါ 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 ကျွန်ုပ်တို့၏ hosts ဖိုင်သို့

Kiali မှတဆင့် Mesh ကိုကြည့်ပါ။

ကျွန်ုပ်တို့သည် စမ်းသပ်ခြင်းအပလီကေးရှင်းနှင့် Istio ကို Tracing၊ Grafana၊ Prometheus နှင့် Kiali တို့နှင့်အတူ ထည့်သွင်းခဲ့သည် (အသေးစိတ်အချက်အလက်များအတွက် အောက်တွင်ကြည့်ပါ)။ ပရောဂျက်ဖတ်ပါ။) ထို့ကြောင့် ကျွန်ုပ်တို့သည် Kiali ကို အသုံးပြုနိုင်သည်။

istioctl dashboard kiali # admin:admin

Kiali သည် Mesh မှတဆင့် လက်ရှိအသွားအလာကို မြင်ယောင်သည်။

ကျွန်ုပ်တို့မြင်နိုင်သည်အတိုင်း၊ လမ်းကြောင်း၏ 100% သည် frontend ဝန်ဆောင်မှုသို့သွားသည်၊ ထို့နောက်တွင်၊ ကျွန်ုပ်တို့သည် backend ဝန်ဆောင်မှုထံသို့ တောင်းဆိုချက်များကို ပြန်လည်ညွှန်းပေးသည့် ရိုးရှင်းသော nginx proxy ကိုအသုံးပြုနေသောကြောင့်၊ ၎င်းတို့ကို backend pods များသို့ ပြန်ညွှန်းပေးသည့် ရိုးရှင်းသော nginx proxy ကိုအသုံးပြုနေသောကြောင့်ဖြစ်သည်။ အညွှန်း v1 ဖြင့်

Kiali သည် Istio နှင့် ကောင်းမွန်စွာလုပ်ဆောင်နိုင်ပြီး ထုပ်ပိုးထားသော Mesh rendering solution ကို ပံ့ပိုးပေးပါသည်။ အရမ်းကောင်းတယ်။

Canary ဖြန့်ကျက်

ကျွန်ုပ်တို့၏နောက်ကွယ်တွင် k8s ဖြန့်ကျက်မှုနှစ်ခုရှိပြီး၊ တစ်ခုသည် v1 အတွက်တစ်ခုနှင့် v2 အတွက်တစ်ခုရှိသည်။ ယခုကျွန်ုပ်တို့သည် v2 သို့တောင်းဆိုမှုအချို့ရာခိုင်နှုန်းကိုပေးပို့ရန် Istio ကိုပြောရန်လိုသည်။

အဆင့် 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 နောက်ခံသို့ ပို့သည်ဆိုပါစို့။ ကျွန်ုပ်တို့ မျှော်လင့်ထားသည့်အတိုင်း အရာအားလုံး အဆင်ပြေကြောင်း သေချာစေရန် 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 အချိုးဖြင့် မောင်းနှင်နေဆဲဖြစ်သည်-

ကိန္နရီသည် မှီခိုဗားရှင်းနှစ်မျိုး

ယခုကျွန်ုပ်တို့သည် frontend နှင့် backend နှစ်ခုလုံးအတွက်ဗားရှင်း v2 ရှိသည့်ရွေးချယ်မှုကိုကျွန်ုပ်တို့စဉ်းစားပါမည်။ နှစ်ခုစလုံးအတွက်၊ အသွားအလာ၏ 10% သည် v2 သို့သွားသင့်သည်ဟု ကျွန်ုပ်တို့သတ်မှတ်ထားသည်-

ထို frontend v1 နှင့် v2 နှစ်ခုစလုံးသည် ရှေ့သွားလမ်းကြောင်းကို 1/10 နှင့် backend v1 နှင့် v2 ၏ အချိုးအတိုင်းမြင်ရသည်။

၎င်းသည် v2 နှင့် တွဲဖက်၍မရသောကြောင့် အသွားအလာများကို frontend-v2 မှ backend-v1 သို့သာပေးပို့ရန် လိုအပ်ပါက၊ ထိုသို့လုပ်ဆောင်ရန်၊ ညှိနှိုင်းမှုကို အသုံးပြု၍ backend-v1 သို့ အသွားအလာများကို ထိန်းချုပ်သည့် frontend အတွက် 10/2 အချိုးကို သတ်မှတ်ပါမည်။ 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 ဖြန့်ကျက်မှုကို ကိုယ်တိုင်လုပ်ဆောင်ခဲ့ပြီး k8s ဖြန့်ကျက်မှုနှစ်ခုကိုလည်း အသုံးပြုခဲ့သည်။ ပုံတူအရေအတွက်ကို ပြောင်းလဲခြင်းဖြင့် တောင်းဆိုမှုအချိုးအစားကို ကျွန်ုပ်တို့ ထိန်းချုပ်ထားပါသည်။ ဤနည်းလမ်းသည် အလုပ်လုပ်သော်လည်း ပြင်းထန်သော အားနည်းချက်များရှိသည်။

ပုံတူအရေအတွက်မခွဲခြားဘဲ တောင်းဆိုမှုအချိုးကို Istio က ဆုံးဖြတ်နိုင်စေသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် HPAs (Horizontal Pod Autoscalers) ကို အသုံးပြုနိုင်ပြီး Canary ဖြန့်ကျက်မှု၏ လက်ရှိအခြေအနေအရ ပြင်ဆင်သတ်မှတ်ရန် မလိုအပ်ပါ။

ရလဒ်

Istio သည် အလွန်ကောင်းမွန်ပြီး ၎င်းကို Kiali နှင့် တွဲသုံးခြင်းဖြင့် အလွန်အစွမ်းထက်သော ပေါင်းစပ်မှုကို ဖြစ်စေသည်။ ကျွန်ုပ်၏စိတ်ဝင်စားမှုများစာရင်းတွင် နောက်တစ်ခုမှာ အလိုအလျောက်စနစ်နှင့် Canary ခွဲခြမ်းစိတ်ဖြာမှုအတွက် Spinnaker နှင့် Istio ပေါင်းစပ်ထားသည်။

source: www.habr.com