ထုတ်လုပ်မှုတွင် Kubernetes ကို အသုံးပြု၍ Istio ကို မည်သို့လုပ်ဆောင်မည်နည်း။ အပိုင်း 1

အဘယျသို့ Istio? ၎င်းသည် ကွန်ရက်ပေါ်တွင် အာရုံစူးစိုက်မှု အလွှာတစ်ခုကို ပေါင်းထည့်သည့် ဝန်ဆောင်မှု mesh ဟုခေါ်သော နည်းပညာဖြစ်သည်။ ကျွန်ုပ်တို့သည် အစုအဝေးရှိ အသွားအလာအားလုံး သို့မဟုတ် တစ်စိတ်တစ်ပိုင်းကို ကြားဖြတ်ပြီး ၎င်းနှင့်အတူ လုပ်ဆောင်ချက်အချို့ကို လုပ်ဆောင်ပါသည်။ ဘယ်တစ်ခုလဲ? ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် စမတ်ကျသောလမ်းကြောင်းကိုလုပ်ဆောင်သည်၊ သို့မဟုတ် circuit breaker ချဉ်းကပ်နည်းကိုအကောင်အထည်ဖော်သည်၊ ကျွန်ုပ်တို့သည် "canary deployment" ကိုစီစဉ်နိုင်ပြီး၊ ဝန်ဆောင်မှု၏ဗားရှင်းအသစ်သို့ တစ်စိတ်တစ်ပိုင်းအသွားအလာကို တစ်စိတ်တစ်ပိုင်းပြောင်းနိုင်သည် သို့မဟုတ် ပြင်ပအပြန်အလှန်ဆက်သွယ်မှုများကို ကန့်သတ်နိုင်ပြီး အစုအဝေးမှ ခရီးစဉ်အားလုံးကို ထိန်းချုပ်နိုင်သည်။ ပြင်ပကွန်ရက်။ မတူညီသော မိုက်ခရိုဝန်ဆောင်မှုများအကြား ခရီးစဉ်များကို ထိန်းချုပ်ရန် မူဝါဒစည်းမျဉ်းများ သတ်မှတ်ရန် ဖြစ်နိုင်သည်။ နောက်ဆုံးတွင်၊ ကျွန်ုပ်တို့သည် ကွန်ရက်အပြန်အလှန်ဆက်သွယ်မှုမြေပုံတစ်ခုလုံးကို ရယူနိုင်ပြီး စုစည်းထားသော မက်ထရစ်များစုစည်းမှုကို အပလီကေးရှင်းများထံ လုံးဝပွင့်လင်းမြင်သာအောင် ပြုလုပ်နိုင်မည်ဖြစ်သည်။

အလုပ်၏ယန္တရားအကြောင်း ဖတ်ရှုနိုင်ပါသည်။ တရားဝင်စာရွက်စာတမ်း. Istio သည် သင့်အား အလုပ်များနှင့် ပြဿနာများစွာကို ဖြေရှင်းပေးနိုင်သည့် အမှန်တကယ် အစွမ်းထက်သည့်ကိရိယာတစ်ခုဖြစ်သည်။ ဤဆောင်းပါးတွင်၊ Istio ကို စတင်သောအခါတွင် ပေါက်လေ့ရှိသော အဓိကမေးခွန်းများကို ကျွန်ုပ်ဖြေကြားလိုပါသည်။ ၎င်းသည် သင့်အား ကိုင်တွယ်ဖြေရှင်းရာတွင် ပိုမိုမြန်ဆန်စေရန် ကူညီပေးပါမည်။

ဘယ်လိုအလုပ်လုပ်တယ်

Istio တွင် အဓိက ဧရိယာ နှစ်ခု ပါ၀င်သည် - ထိန်းချုပ်ရေး လေယာဉ် နှင့် ဒေတာ လေယာဉ် ။ ထိန်းချုပ်ရေးလေယာဉ်တွင် ကျန်ရှိသည့် မှန်ကန်သောလည်ပတ်မှုကို သေချာစေမည့် အဓိကအစိတ်အပိုင်းများပါရှိသည်။ လက်ရှိဗားရှင်း (1.0) တွင် ထိန်းချုပ်ရေးလေယာဉ်တွင် အဓိက အစိတ်အပိုင်း သုံးခုပါရှိသည်- Pilot၊ Mixer၊ Citadel။ ကျွန်ုပ်တို့သည် Citadel ကို ထည့်သွင်းစဉ်းစားမည်မဟုတ်ပါ၊ ဝန်ဆောင်မှုများအကြား အပြန်အလှန် TLS ကိုသေချာစေရန် လက်မှတ်များထုတ်ပေးရန် လိုအပ်ပါသည်။ Pilot နှင့် Mixer ၏ စက်ပစ္စည်းနှင့် ရည်ရွယ်ချက်တို့ကို အနီးကပ် လေ့လာကြည့်ကြပါစို့။

Pilot သည် အစုအဝေးအတွင်း ကျွန်ုပ်တို့ရှိသောအရာများနှင့်ပတ်သက်သည့် အချက်အလက်အားလုံးကို ဖြန့်ဝေပေးသည့် အဓိကထိန်းချုပ်မှုအစိတ်အပိုင်းဖြစ်သည် - ဝန်ဆောင်မှုများ၊ ၎င်းတို့၏ အဆုံးမှတ်များနှင့် လမ်းပြခြင်းစည်းမျဉ်းများ (ဥပမာ၊ Canary ဖြန့်ကျက်မှုအတွက် စည်းမျဉ်းများ သို့မဟုတ် circuit breaker စည်းမျဉ်းများ)။

Mixer သည် မက်ထရစ်များ၊ မှတ်တမ်းများနှင့် ကွန်ရက် အပြန်အလှန်ဆက်သွယ်မှုဆိုင်ရာ အချက်အလက်များကို စုဆောင်းနိုင်စွမ်းကို ပံ့ပိုးပေးသည့် စိတ်ကြိုက်ထိန်းချုပ်မှု လေယာဉ်အစိတ်အပိုင်းတစ်ခုဖြစ်သည်။ စည်းမျဥ်းစည်းကမ်းများကို လိုက်နာမှုနှင့် နှုန်းထားကန့်သတ်ချက်များကို လိုက်နာခြင်းကိုလည်း စောင့်ကြည့်သည်။

ဒေတာလေယာဉ်ကို sidecar proxy ကွန်တိန်နာများသုံးပြီး အကောင်အထည်ဖော်သည်။ Powerful ကို မူရင်းအတိုင်း အသုံးပြုသည်။ အထူးကိုယ်စားလှယ် ပရောက်စီ. ၎င်းကို nginx (nginmesh) ကဲ့သို့သော အခြားအကောင်အထည်ဖော်မှုဖြင့် အစားထိုးနိုင်သည်။

Istio သည် အပလီကေးရှင်းများအတွက် လုံးလုံးလျားလျား ပွင့်လင်းမြင်သာစွာ အလုပ်လုပ်နိုင်စေရန်အတွက် အလိုအလျောက် ထိုးဆေးစနစ်တစ်ခု ရှိပါသည်။ နောက်ဆုံးအကောင်အထည်ဖော်မှုသည် Kubernetes 1.9+ ဗားရှင်းများ (mutational admission webhook) အတွက် သင့်လျော်သည်။ Kubernetes ဗားရှင်း 1.7၊ 1.8 အတွက် Initializer ကို သုံးနိုင်သည်။

Sidecar ကွန်တိန်နာများကို GRPC ပရိုတိုကောကို အသုံးပြု၍ Pilot နှင့် ချိတ်ဆက်ထားပြီး၊ ၎င်းသည် အစုအဝေးအတွင်း ဖြစ်ပေါ်နေသည့် အပြောင်းအလဲများအတွက် တွန်းအားပေးပုံစံကို အကောင်းဆုံးဖြစ်အောင် လုပ်ဆောင်နိုင်စေပါသည်။ GRPC ကို ဗားရှင်း 1.6 ကတည်းက Envoy တွင် အသုံးပြုခဲ့ပြီး Istio တွင် ၎င်းကို ဗားရှင်း 0.8 ကတည်းက အသုံးပြုထားပြီး လွှတ်တင်ခြင်းဆိုင်ရာ ရွေးချယ်မှုများကို စီစဉ်သတ်မှတ်ပေးသည့် အထူးကိုယ်စားလှယ်အဖြစ် golang wrapper တစ်ခုဖြစ်သည်။

Pilot နှင့် Mixer တို့သည် နိုင်ငံမဲ့ အစိတ်အပိုင်းများဖြစ်ပြီး ပြည်နယ်အားလုံးကို မှတ်ဉာဏ်တွင် သိမ်းဆည်းထားသည်။ ၎င်းတို့အတွက် ဖွဲ့စည်းမှုပုံစံကို etcd တွင် သိမ်းဆည်းထားသည့် Kubernetes စိတ်ကြိုက်အရင်းအမြစ်များပုံစံဖြင့် သတ်မှတ်ထားသည်။
Istio-agent သည် Pilot ၏လိပ်စာကိုရရှိပြီး ၎င်းထံသို့ GRPC stream တစ်ခုကိုဖွင့်သည်။

ငါပြောခဲ့သည့်အတိုင်း Istio သည် လုပ်ဆောင်ချက်အားလုံးကို အပလီကေးရှင်းများအတွက် လုံးဝပွင့်လင်းမြင်သာစွာ အကောင်အထည်ဖော်သည်။ ဘယ်လိုလဲ ကြည့်ရအောင်။ algorithm မှာ ဤသို့ဖြစ်သည်-

1. ဝန်ဆောင်မှု၏ ဗားရှင်းအသစ်ကို အသုံးပြုခြင်း။
2. ဘေးတွဲကွန်တိန်နာထိုးသွင်းခြင်းချဉ်းကပ်မှုအပေါ် မူတည်၍ istio-init ကွန်တိန်နာနှင့် istio-အေးဂျင့်ကွန်တိန်နာ (သံတမန်) ကို ဖွဲ့စည်းမှုပုံစံကိုအသုံးပြုသည့်အဆင့်တွင် ထည့်သွင်းထားသည် သို့မဟုတ် ၎င်းတို့ကို Kubernetes Pod ၏ဖော်ပြချက်တွင် ကိုယ်တိုင်ထည့်သွင်းပြီးဖြစ်သည်။
3. istio-init container သည် pod တွင် iptables စည်းမျဉ်းများကို အသုံးပြုသည့် script တစ်ခုဖြစ်သည်။ istio-agent ကွန်တိန်နာတွင် ပတ်ထားရမည့် အသွားအလာကို ပြင်ဆင်သတ်မှတ်ခြင်းအတွက် ရွေးချယ်စရာ နှစ်ခုရှိသည်- iptables စည်းမျဉ်းများကို အသုံးပြုပါ သို့မဟုတ်၊ TPROXY. စာရေးချိန်တွင်၊ ပုံသေချဉ်းကပ်ပုံမှာ ပြန်လည်ညွှန်းစည်းမျဉ်းများဖြစ်သည်။ istio-init တွင်၊ မည်သည့်အသွားအလာကို ကြားဖြတ်ဖြတ်တောက်ပြီး istio-agent သို့ ပေးပို့သင့်သည်ကို စီစဉ်သတ်မှတ်နိုင်သည်။ ဥပမာအားဖြင့်၊ အဝင်နှင့်အထွက်လမ်းကြောင်းအားလုံးကို ကြားဖြတ်နိုင်ရန်၊ သင်သည် ဘောင်များကို သတ်မှတ်ရန်လိုအပ်သည်။ -i и -b အဓိပ္ပါယ်သို့ *. ကြားဖြတ်ရန် သီးခြား port များကို သင် သတ်မှတ်နိုင်သည်။ သီးခြားကွန်ရက်တစ်ခုအား ကြားဖြတ်မတားဆီးနိုင်ရန်၊ ၎င်းကို အလံကို အသုံးပြု၍ သတ်မှတ်နိုင်သည်။ -x.
4. init containers များကို ကွပ်မျက်ပြီးနောက်၊ pilot-agent (သံတမန်) အပါအဝင် ပင်မပစ္စည်းများကို စတင်ထုတ်လုပ်လိုက်ပါသည်။ ၎င်းသည် GRPC မှတစ်ဆင့် အသုံးပြုထားပြီးသော Pilot နှင့် ချိတ်ဆက်ပြီး အစုအဝေးရှိ လက်ရှိဝန်ဆောင်မှုများနှင့် လမ်းကြောင်းသတ်မှတ်ခြင်းဆိုင်ရာ မူဝါဒများအားလုံးကို လက်ခံရရှိမည်ဖြစ်သည်။ လက်ခံရရှိသည့်ဒေတာအရ၊ သူက အစုအဝေးများကို စီစဉ်သတ်မှတ်ပြီး Kubernetes အစုအဝေးရှိ ကျွန်ုပ်တို့၏ အပလီကေးရှင်းများ၏ အဆုံးမှတ်များသို့ တိုက်ရိုက်တာဝန်ပေးသည်။ အရေးကြီးသောအချက်ကိုလည်း မှတ်သားထားရန် လိုအပ်ပါသည်- သံတမန်သည် နားထောင်ခြင်းစတင်သည့် နားဆင်သူများ (IP၊ ပို့တ်အတွဲများ) ကို အင်တိုက်အားတိုက် စီစဉ်ပေးပါသည်။ ထို့ကြောင့်၊ တောင်းဆိုမှုများသည် pod ထဲသို့ဝင်ရောက်သောအခါ၊ sidecar ရှိ iptables စည်းမျဉ်းများကို အသုံးပြု၍ ပြန်လည်ညွှန်းဆိုသည့်အခါ၊ အထူးကိုယ်စားလှယ်သည် အဆိုပါချိတ်ဆက်မှုများကို အောင်မြင်စွာလုပ်ဆောင်နိုင်ပြီး ယာဉ်အသွားအလာကို နောက်ထပ် proxy လုပ်ရမည့်နေရာကို နားလည်နေပြီဖြစ်သည်။ ဤအဆင့်တွင်၊ ကျွန်ုပ်တို့သည် နောက်မှကြည့်ရှုမည့် Mixer သို့ အချက်အလက်များကို ပေးပို့ပြီး ခြေရာခံခြင်းအပိုင်းများကို ပေးပို့ပါသည်။

ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် အမှတ် (Pilot) တစ်ခုမှ configure လုပ်နိုင်သော envoy proxy ဆာဗာများ၏ ကွန်ရက်တစ်ခုလုံးကို ရရှိပါသည်။ အဝင်နှင့်အထွက် တောင်းဆိုချက်အားလုံးသည် သံတမန်မှတစ်ဆင့် ဆောင်ရွက်ပေးသည်။ ထို့အပြင်၊ TCP အသွားအလာများကိုသာ ကြားဖြတ်ခံရသည်။ ဆိုလိုသည်မှာ Kubernetes ဝန်ဆောင်မှု IP ကို ​​ပြောင်းလဲခြင်းမရှိဘဲ UDP တွင် kube-dns ဖြင့် ဖြေရှင်းထားသည်။ ထို့နောက် ဖြေရှင်းပြီးနောက်၊ ထွက်လာသည့်တောင်းဆိုချက်ကို သံတမန်က ကြားဖြတ်ပြီး စီမံဆောင်ရွက်သည်၊ ၎င်းသည် တောင်းဆိုချက်အား မည်သည့် endpoint သို့ ပေးပို့သင့်သည် (သို့သော် ဝင်ရောက်ခွင့်မူဝါဒများ သို့မဟုတ် algorithm ၏ circuit breaker တွင်) ကို ဆုံးဖြတ်ပြီးဖြစ်သည်။

Pilot ကို ကျွန်ုပ်တို့ ရှာဖွေတွေ့ရှိခဲ့ပြီး ယခုအခါ Mixer အလုပ်လုပ်ပုံနှင့် အဘယ်ကြောင့် လိုအပ်ကြောင်း နားလည်ရန် လိုအပ်ပါသည်။ ၎င်းအတွက်တရားဝင်စာရွက်စာတမ်းများကိုသင်ဖတ်နိုင်သည်။ ဒီမှာ.

၎င်း၏လက်ရှိပုံစံတွင် ရောနှောခြင်းတွင် အစိတ်အပိုင်းနှစ်ခုပါဝင်သည်- istio-telemetry၊ istio-policy (ဗားရှင်း 0.8 မတိုင်မီ ၎င်းသည် istio-mixer အစိတ်အပိုင်းတစ်ခုဖြစ်သည်)။ ၎င်းတို့နှစ်ဦးစလုံးသည် ရောနှောပါဝင်သူများဖြစ်ပြီး ၎င်းတို့တစ်ဦးစီသည် ၎င်း၏ကိုယ်ပိုင်တာဝန်အတွက် တာဝန်ရှိသည်။ Istio telemetry သည် GRPC မှတဆင့် မည်သည့်နေရာသို့သွားသည်နှင့် ဘေးတွဲအစီရင်ခံခြင်းကွန်တိန်နာများမှ မည်ကဲ့သို့ ကန့်သတ်ချက်များဖြင့် သတင်းအချက်အလက်ကို လက်ခံရရှိသည် ။ Istio-policy သည် စည်းမျဥ်းစည်းကမ်းများ ကျေနပ်မှုရှိမရှိ စစ်ဆေးရန် တောင်းဆိုချက်များကို လက်ခံပါသည်။ Poilicy checks များသည် တောင်းဆိုမှုတိုင်းအတွက် လုပ်ဆောင်ခြင်းမဟုတ်ဘဲ client (ဆိုက်ကားပေါ်တွင်) အချိန်အတိုင်းအတာတစ်ခုအထိ သိမ်းဆည်းထားသည်။ အစီရင်ခံချက်စစ်ဆေးမှုများကို အစုလိုက်တောင်းဆိုမှုများအဖြစ် ပေးပို့သည်။ ဘယ်လို configure လုပ်ပြီး ဘယ် parameters တွေကို ပို့သင့်တယ်ဆိုတာ နည်းနည်းကြာမှ ကြည့်ရအောင်။

Mixer သည် တယ်လီမီတာဒေတာ တပ်ဆင်ခြင်းနှင့် ချိတ်ဆက်ခြင်းတွင် အနှောက်အယှက်ကင်းကင်းသော လုပ်ဆောင်မှုများကို သေချာစေသည့် မြင့်မားစွာရရှိနိုင်သော အစိတ်အပိုင်းတစ်ခု ဖြစ်သင့်သည်။ စနစ်အား အဆင့်ပေါင်းများစွာ ကြားခံအဖြစ် ရလဒ်အဖြစ် ရယူသည်။ အစပိုင်းတွင်၊ ကွန်တိန်နာ၏ sidecar side တွင် data ကို buffered ဖြစ်ပြီး၊ ထို့နောက် mixer side တွင်၊ ထို့နောက် mixer backends ဟုခေါ်တွင်သည်။ ရလဒ်အနေဖြင့်၊ စနစ်အစိတ်အပိုင်းများ ပျက်ကွက်ပါက၊ စနစ်အား ပြန်လည်ရယူပြီးနောက် ကြားခံကြီးထွားလာပြီး နီမြန်းသွားမည်ဖြစ်သည်။ Mixer နောက်ခံများသည် တယ်လီမီတာဒေတာပေးပို့ရန်အတွက် အဆုံးမှတ်များဖြစ်သည်- statsd၊ newrelic စသည်တို့ဖြစ်သည်။ သင်သည်သင်၏ကိုယ်ပိုင်နောက်ခံကိုရေးနိုင်သည်၊ ၎င်းသည်အတော်လေးရိုးရှင်းသည်၊ ၎င်းကိုပြုလုပ်ပုံကိုကျွန်ုပ်တို့မြင်လိမ့်မည်။

အနှစ်ချုပ်ရလျှင် istio-telemetry နှင့် လုပ်ဆောင်ရန် အစီအစဉ်မှာ အောက်ပါအတိုင်းဖြစ်သည်။

1. ဝန်ဆောင်မှု 1 သည် ဝန်ဆောင်မှု 2 သို့ တောင်းဆိုချက် ပေးပို့သည်။
2. ဝန်ဆောင်မှု 1 မှထွက်ခွာသောအခါ၊ တောင်းဆိုချက်ကို ၎င်း၏ကိုယ်ပိုင်ဆိုက်ကားထဲတွင် ထည့်သွင်းထားသည်။
3. ဆိုက်ကားသံတမန်သည် ဝန်ဆောင်မှု 2 သို့ တောင်းဆိုချက် မည်ကဲ့သို့ ရောက်ရှိလာသည်ကို စောင့်ကြည့်ပြီး လိုအပ်သော အချက်အလက်များကို ပြင်ဆင်ပေးသည်။
4. ထို့နောက် အစီရင်ခံစာတောင်းဆိုမှုကို အသုံးပြု၍ ၎င်းကို istio-telemetry သို့ ပေးပို့ပါ။
5. Istio-telemetry သည် ဤအစီရင်ခံစာကို နောက်ခံများထံ ပေးပို့သင့်သည်၊ မည်သည့်ဒေတာကို ပေးပို့သင့်သည်ကို ဆုံးဖြတ်သည်။
6. Istio-telemetry သည် လိုအပ်ပါက backend သို့ အစီရင်ခံစာဒေတာကို ပေးပို့သည်။

ယခုအခါတွင် အဓိကအစိတ်အပိုင်းများ (Pilot နှင့် sidecar envoy) များသာပါဝင်သော Istio ကို မည်သို့အသုံးပြုရမည်ကို ကြည့်ကြပါစို့။

ပထမဦးစွာ Pilot မှဖတ်သော ပင်မဖွဲ့စည်းပုံ (mesh) ကို ကြည့်ကြပါစို့။

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio
  namespace: istio-system
  labels:
    app: istio
    service: istio
data:
  mesh: |-

    # пока что не включаем отправку tracing информации (pilot настроит envoy’и таким образом, что отправка не будет происходить)
    enableTracing: false

    # пока что не указываем mixer endpoint’ы, чтобы sidecar контейнеры не отправляли информацию туда
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # ставим временной промежуток, с которым будет envoy переспрашивать Pilot (это для старой версии envoy proxy)
    rdsRefreshDelay: 5s

    # default конфигурация для envoy sidecar
    defaultConfig:
      # аналогично как rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # оставляем по умолчанию (путь к конфигурации и бинарю envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # дефолтное имя запущенного sidecar контейнера (используется, например, в именах сервиса при отправке tracing span’ов)
      serviceCluster: istio-proxy

      # время, которое будет ждать envoy до того, как он принудительно завершит все установленные соединения
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # по умолчанию используются REDIRECT правила iptables. Можно изменить на TPROXY.
      #interceptionMode: REDIRECT

      # Порт, на котором будет запущена admin панель каждого sidecar контейнера (envoy)
      proxyAdminPort: 15000

      # адрес, по которому будут отправляться trace’ы по zipkin протоколу (в начале мы отключили саму отправку, поэтому это поле сейчас не будет использоваться)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd адрес для отправки метрик envoy контейнеров (отключаем)
      # statsdUdpAddress: aggregator:8126

      # выключаем поддержку опции Mutual TLS
      controlPlaneAuthPolicy: NONE

      # адрес, на котором будет слушать istio-pilot для того, чтобы сообщать информацию о service discovery всем sidecar контейнерам
      discoveryAddress: istio-pilot.istio-system:15007

အဓိက ထိန်းချုပ်မှု အစိတ်အပိုင်းများ (ထိန်းချုပ်ရေး လေယာဉ်) အားလုံးကို Kubernetes ရှိ namespace istio-system တွင် ထားရှိပါမည်။

အနည်းဆုံးတော့ Pilot ကို အသုံးချဖို့ပဲ လိုပါတယ်။ ဒီအတွက် ကျွန်တော်တို့ သုံးပါတယ်။ ထိုသို့သောဖွဲ့စည်းမှု။

ပြီးတော့ ကွန်တိန်နာရဲ့ ထိုးသွင်း sidecar ကို ကိုယ်တိုင် configure လုပ်ပါမယ်။

Init container-

initContainers:
 - name: istio-init
   args:
   - -p
   - "15001"
   - -u
   - "1337"
   - -m
   - REDIRECT
   - -i
   - '*'
   - -b
   - '*'
   - -d
   - ""
   image: istio/proxy_init:1.0.0
   imagePullPolicy: IfNotPresent
   resources:
     limits:
       memory: 128Mi
   securityContext:
     capabilities:
       add:
       - NET_ADMIN

နှင့် ဘေးတွဲ-

       name: istio-proxy
       args:
         - "bash"
         - "-c"
         - |
           exec /usr/local/bin/pilot-agent proxy sidecar 
           --configPath 
           /etc/istio/proxy 
           --binaryPath 
           /usr/local/bin/envoy 
           --serviceCluster 
           service-name 
           --drainDuration 
           45s 
           --parentShutdownDuration 
           1m0s 
           --discoveryAddress 
           istio-pilot.istio-system:15007 
           --discoveryRefreshDelay 
           1s 
           --connectTimeout 
           10s 
           --proxyAdminPort 
           "15000" 
           --controlPlaneAuthPolicy 
           NONE
         env:
         - name: POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: POD_NAMESPACE
           valueFrom:
             fieldRef:
               fieldPath: metadata.namespace
         - name: INSTANCE_IP
           valueFrom:
             fieldRef:
               fieldPath: status.podIP
         - name: ISTIO_META_POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: ISTIO_META_INTERCEPTION_MODE
           value: REDIRECT
         image: istio/proxyv2:1.0.0
         imagePullPolicy: IfNotPresent
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             memory: 2048Mi
         securityContext:
           privileged: false
           readOnlyRootFilesystem: true
           runAsUser: 1337
         volumeMounts:
         - mountPath: /etc/istio/proxy
           name: istio-envoy

အရာအားလုံးကို အောင်မြင်စွာစတင်နိုင်ရန်၊ သင်သည် ServiceAccount၊ ClusterRole၊ ClusterRoleBinding၊ CRD for Pilot၊ တွေ့ရှိနိုင်သည့်ဖော်ပြချက်များကို ဖန်တီးရန်လိုအပ်ပါသည်။ ဒီမှာ.

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

ထိန်းချုပ်ရေးလေယာဉ်အစိတ်အပိုင်းများအားလုံးသည် နိုင်ငံမဲ့အသုံးချပရိုဂရမ်များဖြစ်ကြပြီး ပြဿနာမရှိဘဲ အလျားလိုက် အတိုင်းအတာကို နားလည်ရန် အရေးကြီးပါသည်။ ဒေတာအားလုံးကို Kubernetes အရင်းအမြစ်များ၏ စိတ်ကြိုက်ဖော်ပြချက်ပုံစံဖြင့် etcd တွင် သိမ်းဆည်းထားသည်။

ထို့အပြင်၊ Istio (စမ်းသပ်ဆဲ) သည် အစုအဝေးပြင်ပတွင်လည်ပတ်နိုင်စွမ်းရှိပြီး Kubernetes အစုအဝေးများစွာကြားရှိ ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိမှုကို ကြည့်ရှုခြင်းနှင့် ရှုပ်ယှက်ခတ်နေသော ဝန်ဆောင်မှုကို ရှာဖွေနိုင်စွမ်းရှိသည်။ ဤအကြောင်းပိုမိုဖတ်ရှုနိုင်ပါသည်။ ဒီမှာ.

Multi-cluster တပ်ဆင်မှုအတွက်၊ အောက်ပါကန့်သတ်ချက်များကို သတိပြုပါ-

1. Pod CIDR နှင့် ဝန်ဆောင်မှု CIDR သည် အစုအဝေးအားလုံးတွင် သီးသန့်ဖြစ်ရမည် ဖြစ်ပြီး ထပ်မထပ်ရပါ။
2. CIDR Pods အားလုံးသည် အစုအဝေးများကြားရှိ CIDR Pods များမှ ဝင်ရောက်နိုင်ရပါမည်။
3. Kubernetes API ဆာဗာများအားလုံးသည် တစ်ဦးနှင့်တစ်ဦး ဝင်ရောက်နိုင်ရပါမည်။

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

source: www.habr.com