Istio နှင့် Kubernetes တို့ကို ထုတ်လုပ်နေသည်။ အပိုင်း ၂။ ခြေရာခံခြင်း။

နောက်ဆုံး၌ ဆောင်းပါး ကျွန်ုပ်တို့သည် Service Mesh Istio ၏ အခြေခံ အစိတ်အပိုင်းများကို ကြည့်ရှုခဲ့ပြီး၊ စနစ်နှင့် သိကျွမ်းခဲ့ပြီး Istio နှင့် စတင်လုပ်ဆောင်သောအခါတွင် ပေါ်ပေါက်လေ့ရှိသည့် အဓိကမေးခွန်းများကို ဖြေခဲ့သည်။ ဤအပိုင်းတွင် ကျွန်ုပ်တို့သည် ကွန်ရက်တစ်ခုပေါ်ရှိ ခြေရာခံအချက်အလက် စုဆောင်းပုံကို စုစည်းပုံကို ကြည့်ရှုပါမည်။

Service Mesh သည် ခြေရာခံခြင်းဟူသော စကားလုံးကို ကြားသောအခါတွင် developer များနှင့် system administrator အများအပြားအတွက် သတိပြုမိရမည့်အချက်မှာ ပထမဆုံးအချက်ဖြစ်သည်။ အမှန်မှာ၊ ကျွန်ုပ်တို့သည် TCP အသွားအလာအားလုံးကိုဖြတ်သန်းသော network node တစ်ခုစီသို့ အထူး proxy server တစ်ခုကို ပေါင်းထည့်ပါသည်။ ကွန်ရက်ပေါ်ရှိ ကွန်ရက် အပြန်အလှန်ဆက်သွယ်မှုများအားလုံးကို ယခု အလွယ်တကူ ပေးပို့နိုင်ပြီဟု ထင်ရသည်။ ကံမကောင်းစွာပဲ၊ လက်တွေ့တွင် ထည့်သွင်းစဉ်းစားရန် လိုအပ်သော nuances များစွာရှိသည်။ သူတို့ကိုကြည့်ရအောင်။

နံပါတ်တစ် အယူအဆမှား- အွန်လိုင်းတောင်တက်ခြင်းဒေတာကို အခမဲ့ရနိုင်သည် ။

တကယ်တော့၊ အခမဲ့ဖြစ်ပြီး၊ မြှားများဖြင့် ချိတ်ဆက်ထားသော ကျွန်ုပ်တို့၏စနစ်၏ node များနှင့် ဝန်ဆောင်မှုများကြားတွင်ဖြတ်သန်းသော ဒေတာနှုန်းထားများကိုသာ ရနိုင်သည် (တကယ်တော့ အချိန်တစ်ယူနစ်လျှင် bytes အရေအတွက်သာ)။ သို့သော်လည်း၊ ကိစ္စအများစုတွင်၊ ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများသည် HTTP၊ gRPC၊ Redis ကဲ့သို့သော အပလီကေးရှင်းအလွှာပရိုတိုကော အမျိုးအစားအချို့နှင့် ဆက်သွယ်သည်။ ထို့အပြင်၊ ကျွန်ုပ်တို့သည် ဤပရိုတိုကောများအတွက် အထူးခြေရာခံအချက်အလက်ကို မြင်လိုသည်၊ ကျွန်ုပ်တို့သည် တောင်းဆိုမှုနှုန်း၊ ဒေတာနှုန်းကို မကြည့်လိုပါ။ ကျွန်ုပ်တို့၏ ပရိုတိုကောကို အသုံးပြု၍ တောင်းဆိုမှုများ၏ ကြာမြင့်ချိန်ကို နားလည်လိုပါသည်။ နောက်ဆုံးတွင်၊ ကျွန်ုပ်တို့သည် သုံးစွဲသူထံမှ တုံ့ပြန်မှုကို လက်ခံရရှိရန် ကျွန်ုပ်တို့၏စနစ်သို့ ဝင်ရောက်ခြင်းမှ တောင်းဆိုချက်တစ်ခုရယူသည့် လမ်းကြောင်းအပြည့်အစုံကို ကျွန်ုပ်တို့ မြင်တွေ့လိုပါသည်။ ဒီပြဿနာက ဖြေရှင်းဖို့ သိပ်မလွယ်တော့ဘူး။

ဦးစွာ၊ Istio ရှိ ဗိသုကာလက်ရာရှုထောင့်မှ ပေးပို့သည့် ခြေရာခံအကွာအဝေးများကို ကြည့်ကြပါစို့။ ပထမအပိုင်းမှ မှတ်မိသည့်အတိုင်း Istio တွင် telemetry စုဆောင်းရန်အတွက် Mixer ဟုခေါ်သော သီးခြားအစိတ်အပိုင်းတစ်ခုရှိသည်။ သို့သော်လည်း လက်ရှိဗားရှင်း 1.0.* တွင်၊ ပေးပို့ခြင်းကို ပရောက်စီဆာဗာများမှ တိုက်ရိုက်လုပ်ဆောင်သည်၊ အတိအကျပြောရလျှင် envoy proxy မှဖြစ်သည်။ Envoy proxy သည် zipkin ပရိုတိုကောကို အသုံးပြု၍ ခြေရာခံခြင်းအပိုင်းများကို ဘောင်အတွင်းမှ ပေးပို့ခြင်းကို ပံ့ပိုးပေးပါသည်။ အခြားပရိုတိုကောများကို ချိတ်ဆက်နိုင်သော်လည်း plugin တစ်ခုမှသာလျှင် ချိတ်ဆက်နိုင်သည်။ Istio ဖြင့် ကျွန်ုပ်တို့သည် ဇစ်ကင်ပရိုတိုကောကိုသာ ပံ့ပိုးပေးသည့် စုဝေးပြီး ဖွဲ့စည်းထားသော အထူးကိုယ်စားလှယ် ပရောက်စီကို ချက်ချင်းရရှိသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် Jaeger ပရိုတိုကောကိုအသုံးပြုပြီး UDP မှတစ်ဆင့် ခြေရာခံခြင်းအပိုင်းများကို ပေးပို့လိုပါက၊ ကျွန်ုပ်တို့၏ကိုယ်ပိုင် istio-proxy ပုံကို တည်ဆောက်ရန် လိုအပ်ပါသည်။ istio-proxy အတွက် စိတ်ကြိုက် plugins များအတွက် ပံ့ပိုးမှု ရှိသော်လည်း ၎င်းသည် alpha ဗားရှင်းတွင် ရှိနေသေးသည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် စိတ်ကြိုက်ဆက်တင်အများအပြားမပါဘဲ လုပ်ဆောင်လိုပါက၊ သိမ်းဆည်းခြင်းနှင့် လက်ခံခြင်းအတွက် အသုံးပြုသည့်နည်းပညာအကွာအဝေးကို ခြေရာခံခြင်းအပိုင်းများကို လျှော့ချမည်ဖြစ်သည်။ ပင်မစနစ်များ၏ အမှန်တကယ်တွင်၊ ယခု သင်သည် Zipkin ကိုယ်တိုင် သို့မဟုတ် Jaeger ကို သုံးနိုင်သော်လည်း (အလွန်ထိရောက်မှုနည်းသည့် zipkin သဟဇာတဖြစ်မှု) ကို အသုံးပြု၍ ထိုအရာအားလုံးကို ပေးပို့ပါ။ zipkin ပရိုတိုကောကိုယ်တိုင်က HTTP ပရိုတိုကောမှတစ်ဆင့် စုဆောင်းသူများထံ ခြေရာခံအချက်အလက်အားလုံးကို ပေးပို့ခြင်းပါ၀င်ပြီး အလွန်စျေးကြီးသည်။

ငါပြောပြီးသားအတိုင်း၊ ကျွန်ုပ်တို့သည် အပလီကေးရှင်းအဆင့် ပရိုတိုကောများကို ခြေရာခံလိုပါသည်။ ဆိုလိုသည်မှာ ဝန်ဆောင်မှုတစ်ခုစီ၏ဘေးတွင်ရှိသော ပရောက်စီဆာဗာများသည် ယခုဖြစ်ပျက်နေသည့် အပြန်အလှန်တုံ့ပြန်မှုမျိုးကို နားလည်ရမည်ဖြစ်သည်။ မူရင်းအားဖြင့် Istio သည် ဆိပ်ကမ်းအားလုံးကို ရိုးရိုး TCP အဖြစ် သတ်မှတ်ပေးသည်၊ ဆိုလိုသည်မှာ ခြေရာများကို ပို့မည်မဟုတ်ပါ။ သဲလွန်စများ ပေးပို့နိုင်ရန်၊ ပထမဦးစွာ သင်သည် ပင်မ mesh config တွင် ဤရွေးချယ်ခွင့်ကို ဖွင့်ထားရမည်ဖြစ်ပြီး၊ အလွန်အရေးကြီးသည်မှာ ဝန်ဆောင်မှုတွင် အသုံးပြုသည့် ပရိုတိုကောနှင့်အညီ kubernetes ဝန်ဆောင်မှု entities အားလုံးကို နာမည်ပေးရပါမည်။ ဥပမာအားဖြင့် ဤကဲ့သို့ဖြစ်သည်-

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

http-magic ကဲ့သို့သော ပေါင်းစပ်အမည်များကိုလည်း အသုံးပြုနိုင်ပါသည်။ ဖော်မတ်မှာ- ပရိုတို-အပို။

ပရိုတိုကောကို ဆုံးဖြတ်ရန် များပြားလှသော ဖွဲ့စည်းမှုပုံစံများကို ဖာထေးခြင်းမပြုရန်၊ ညစ်ပတ်သောဖြေရှင်းနည်းကို သင်အသုံးပြုနိုင်သည်- ၎င်းသည် ယခုအချိန်တွင် Pilot အစိတ်အပိုင်းကို ဖာထေးရန် ပရိုတိုကော အဓိပ္ပါယ် ယုတ္တိဗေဒကို လုပ်ဆောင်သည်။. အဆုံးတွင်၊ ဤယုတ္တိဗေဒကို စံအဖြစ်ပြောင်းရန်နှင့် ဆိပ်ကမ်းအားလုံးအတွက် အမည်ပေးသည့်ကွန်ဗင်းရှင်းတစ်ခုသို့ ပြောင်းရန် လိုအပ်မည်ဖြစ်သည်။

ပရိုတိုကောကို အမှန်တကယ် မှန်ကန်စွာ သတ်မှတ်ခြင်း ရှိ၊ မရှိ နားလည်နိုင်ရန်၊ သင်သည် အထူးပရောက်စီဖြင့် ဘေးတွဲကွန်တိန်နာ တစ်ခုခုသို့ သွားကာ တည်နေရာ /config_dump ဖြင့် တည်နေရာ/config_dump ၏ စီမံခန့်ခွဲသူ ဆိပ်ကမ်းသို့ တောင်းဆိုချက် ပြုလုပ်ရန် လိုအပ်ပါသည်။ ရလဒ် configuration တွင်၊ သင်အလိုရှိသောဝန်ဆောင်မှု၏လည်ပတ်မှုအကွက်ကိုကြည့်ရှုရန်လိုအပ်သည်။ တောင်းဆိုသည့်နေရာအတွက် Istio တွင် ၎င်းကို အသုံးပြုသည်။ Istio တွင် ဤပါရာမီတာ၏တန်ဖိုးကို စိတ်ကြိုက်ပြင်ဆင်ရန်အတွက် (ထို့နောက် ကျွန်ုပ်တို့၏ခြေရာခံစနစ်တွင် ၎င်းကိုတွေ့လိမ့်မည်)၊ ဘေးတွဲကွန်တိန်နာကို စတင်သည့်အဆင့်တွင် serviceCluster အလံကို သတ်မှတ်ရန် လိုအပ်ပါသည်။ ဥပမာအားဖြင့်၊ ၎င်းကို downward kubernetes API မှရရှိသော variable များမှ ဤကဲ့သို့ တွက်ချက်နိုင်သည်။

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

သံတမန်တွင် ခြေရာခံခြင်း မည်သို့လုပ်ဆောင်သည်ကို နားလည်ရန် ဥပမာကောင်းတစ်ခုဖြစ်သည်။ ဒီမှာ.

ခြေရာခံ အပိုင်းများ ပေးပို့ခြင်းအတွက် အဆုံးမှတ်ကို သံတမန် ပရောက်စီ လွှင့်တင်မှု အလံများတွင်လည်း သတ်မှတ်ပေးရမည်၊ ဥပမာ- --zipkinAddress tracing-collector.tracing:9411

နံပါတ်နှစ် အထင်အမြင်လွဲမှားမှု- ကျွန်ုပ်တို့သည် စနစ်ဘောင်မှနေ၍ တောင်းဆိုချက်များ၏ သဲလွန်စများကို စျေးပေါပေါဖြင့် ရယူနိုင်ပါသည်။

ကံမကောင်းစွာပဲ၊ အကောင်အထည်ဖော်မှု၏ ရှုပ်ထွေးမှုသည် ဝန်ဆောင်မှုများ၏ အပြန်အလှန်အကျိုးသက်ရောက်မှုကို သင်မည်ကဲ့သို့ အကောင်အထည်ဖော်ထားပြီးသားအပေါ် မူတည်ပါသည်။ အဲဒီလို့ဘာဖြစ်လို့?

အမှန်မှာ ဝန်ဆောင်မှုတစ်ခုတည်းမှ ထွက်ခွာသွားသော ဝန်ဆောင်မှုတစ်ခုထံ ဝင်လာသော တောင်းဆိုမှုများ၏ စာပေးစာယူကို istio-proxy နားလည်နိုင်စေရန်အတွက် လမ်းကြောင်းအားလုံးကို ရိုးရှင်းစွာ ကြားဖြတ်ရန် မလုံလောက်ပါ။ သင့်တွင် ဆက်သွယ်မှုအမှတ်အသားတစ်မျိုးရှိရန် လိုအပ်သည်။ HTTP envoy proxy သည် အထူးခေါင်းစီးများကို အသုံးပြုသည်၊ ၎င်းသည် ဝန်ဆောင်မှုအတွက် သီးခြားတောင်းဆိုချက်များအား အခြားဝန်ဆောင်မှုများသို့ သီးခြားတောင်းဆိုမှုများကို ထုတ်ပေးကြောင်း အထူးကိုယ်စားလှယ်မှ နားလည်ပါသည်။ ထိုကဲ့သို့သော ခေါင်းစီးများစာရင်း-

• x-request-id၊
• x-b3-traceid၊
• x-b3-စပိန်၊
• x-b3-parentspanid၊
• x-b3-နမူနာ၊
• x-b3-အလံများ၊
• x-ot-span-context။

ဥပမာအားဖြင့်၊ သင်သည်ထိုကဲ့သို့သောယုတ္တိဗေဒကိုထည့်သွင်းနိုင်သည့်အခြေခံ client တစ်ခုရှိလျှင်၊ အရာအားလုံးအဆင်ပြေသည်၊ ဤစာကြည့်တိုက်ကို client အားလုံးအတွက်မွမ်းမံရန်စောင့်ဆိုင်းရန်သာလိုအပ်သည်။ သို့သော် သင့်တွင် အလွန်ကွဲပြားသော စနစ်တစ်ခုရှိပြီး ဝန်ဆောင်မှုမှ ဝန်ဆောင်မှုတစ်ခုသို့ ကွန်ရက်တစ်ခုသို့ ပြောင်းရွှေ့ရာတွင် ပေါင်းစည်းမှုမရှိပါက၊ ၎င်းသည် ပြဿနာကြီးတစ်ခုဖြစ်နိုင်သည်။ ယင်းကဲ့သို့ ယုတ္တိဗေဒကို မထည့်ဘဲ၊ ခြေရာခံအချက်အလက်အားလုံးသည် "အဆင့်တစ်ခုတည်း" သာဖြစ်ပါမည်။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုအချင်းချင်း အပြန်အလှန်ဆက်သွယ်မှုများအားလုံးကို လက်ခံရရှိလိမ့်မည်၊ သို့သော် ၎င်းတို့အား ကွန်ရက်မှတစ်ဆင့် လမ်းကြောင်းတစ်ခုထဲသို့ ချိတ်ဆက်သွားမည်မဟုတ်ပါ။

ကောက်ချက်

Istio သည် ကွန်ရက်တစ်ခုပေါ်ရှိ ခြေရာခံအချက်အလက်များကို စုဆောင်းရန်အတွက် အဆင်ပြေသောကိရိယာကို ပံ့ပိုးပေးသည်၊ သို့သော် အကောင်အထည်ဖော်ရန်အတွက် သင်သည် သင်၏စနစ်အား လိုက်လျောညီထွေဖြစ်အောင်လုပ်ဆောင်ပြီး Istio အကောင်အထည်ဖော်မှု၏အင်္ဂါရပ်များကို ထည့်သွင်းစဉ်းစားရန် လိုအပ်ကြောင်း သင်နားလည်ထားရပါမည်။ ရလဒ်အနေဖြင့် အဓိကအချက်နှစ်ချက်ကို ဖြေရှင်းရန် လိုအပ်သည်- အပလီကေးရှင်းအဆင့်ပရိုတိုကောကို သတ်မှတ်ခြင်း (သံတမန် proxy မှ ပံ့ပိုးပေးရမည်) နှင့် ဝန်ဆောင်မှုမှ တောင်းဆိုချက်များမှ ဝန်ဆောင်မှုသို့ တောင်းဆိုချက်များနှင့် ချိတ်ဆက်မှုဆိုင်ရာ အချက်အလက်များ ထပ်ဆင့်ပေးပို့ခြင်းတို့ကို သတ်မှတ်ခြင်း (ခေါင်းစီးများကို အသုံးပြုခြင်း။ HTTP ပရိုတိုကော) တွင်၊ ဤပြဿနာများကိုဖြေရှင်းပြီးသောအခါ၊ ကျွန်ုပ်တို့တွင် မတူညီသောဘာသာစကားများနှင့် မူဘောင်များစွာဖြင့် ရေးသားထားသော အလွန်ကွဲပြားသောကွဲပြားသည့်စနစ်များတွင်ပင် ကွန်ရက်မှသတင်းအချက်အလက်များကို ပွင့်လင်းမြင်သာစွာစုဆောင်းနိုင်စေမည့် အစွမ်းထက်သောကိရိယာတစ်ခုရှိသည်။

Service Mesh နှင့်ပတ်သက်သော နောက်ဆောင်းပါးတွင်၊ Istio ၏ အကြီးမားဆုံး ပြဿနာများထဲမှ တစ်ခုကို လေ့လာကြည့်ပါမည် - sidecar proxy container တစ်ခုစီမှ RAM သုံးစွဲမှု များပြားပြီး ၎င်းကို မည်သို့ကိုင်တွယ်ဖြေရှင်းနိုင်သည်ကို ဆွေးနွေးပါမည်။

source: www.habr.com