Kubernetes တွင် ချိန်ခွင်လျှာညှိခြင်းနှင့် သက်တမ်းရှည်ချိတ်ဆက်မှုများကို ချဲ့ထွင်ပါ။

ဤဆောင်းပါးသည် Kubernetes တွင် load ချိန်ခွင်လျှာအလုပ်လုပ်ပုံ၊ ရေရှည်ချိတ်ဆက်မှုများကို ချဲ့ထွင်သောအခါ ဘာဖြစ်သွားသနည်း၊ HTTP/2၊ gRPC၊ RSockets၊ AMQP သို့မဟုတ် အခြားသက်တမ်းကြာရှည်သော ပရိုတိုကောများကို အသုံးပြုပါက client-side ချိန်ခွင်လျှာကို အဘယ်ကြောင့်စဉ်းစားသင့်သနည်း၊ . 

Kubernetes တွင် ယာဉ်အသွားအလာကို ပြန်လည်ဖြန့်ဝေပုံအကြောင်း အနည်းငယ် 

Kubernetes သည် အပလီကေးရှင်းများ ဖြန့်ကျက်ခြင်းအတွက် အဆင်ပြေသော abstraction နှစ်ခုကို ပံ့ပိုးပေးသည်- ဝန်ဆောင်မှုများနှင့် ဖြန့်ကျက်မှုများ။

ဖြန့်ကျက်မှုများသည် သတ်မှတ်အချိန်အတွင်း သင့်အက်ပ်လီကေးရှင်း၏ မည်မျှနှင့် မည်မျှလည်ပတ်သင့်သည်ကို ဖော်ပြသည်။ အပလီကေးရှင်းတစ်ခုစီကို Pod တစ်ခုအဖြစ် အသုံးပြုထားပြီး IP လိပ်စာတစ်ခု သတ်မှတ်ပေးထားသည်။

ဝန်ဆောင်မှုများသည် Load Balancer နှင့် ဆင်တူသည်။ ၎င်းတို့သည် pods အများအပြားတွင် traffic ကိုဖြန့်ဝေရန်ဒီဇိုင်းပြုလုပ်ထားသည်။

ဘယ်လိုပုံစံလဲဆိုတာ ကြည့်လိုက်ရအောင်.

1. အောက်ဖော်ပြပါ ပုံတွင် တူညီသော အပလီကေးရှင်းသုံးခုနှင့် load balancer ကို သင်တွေ့မြင်နိုင်သည်-

   

2. load balancer ကို Service ဟုခေါ်ပြီး IP လိပ်စာတစ်ခု သတ်မှတ်ပေးပါသည်။ အဝင်တောင်းဆိုမှုမှန်သမျှကို pods များထဲမှ တစ်ခုသို့ ပြန်ညွှန်းသည်-

   

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

   

4. pod တစ်ခုစီကို ၎င်း၏ IP လိပ်စာကို သတ်မှတ်ပေးထားသည်-

   

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

ဒီပုံပါပဲ။.

1. ဝန်ဆောင်မှုအတွက် curl 10.96.45.152 တောင်းဆိုချက်ကို လက်ခံရရှိသည်-

   

2. ဝန်ဆောင်မှုသည် ဦးတည်ရာအဖြစ် pod လိပ်စာသုံးခုထဲမှ တစ်ခုကို ရွေးချယ်သည်-

   

3. Traffic ကို သီးခြား pod တစ်ခုသို့ ပြန်ညွှန်းသည်-

   

သင့်အပလီကေးရှင်းတွင် frontend နှင့် backend ပါ၀င်ပါက၊ တစ်ခုစီအတွက် service တစ်ခုနှင့် deployment နှစ်ခုလုံးရှိမည်ဖြစ်သည်။

Frontend သည် backend သို့ တောင်းဆိုသောအခါ၊ backend သည် pods မည်မျှကို ဆောင်ရွက်ပေးသည်ကို အတိအကျ သိရှိရန် မလိုအပ်ပါ- တစ်ခု၊ ဆယ်ခု သို့မဟုတ် တစ်ရာ ဖြစ်နိုင်သည်။

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

Frontend သည် backend သို့ တောင်းဆိုသောအခါ၊ ၎င်းသည် ပြောင်းလဲခြင်းမရှိသည့် backend ဝန်ဆောင်မှု၏ IP လိပ်စာကို အသုံးပြုသည်။

ဒါကပုံပါပဲ.

1. 1 အောက်တွင် အတွင်းပိုင်း နောက်ခံအစိတ်အပိုင်းကို တောင်းဆိုပါသည်။ Backend အတွက် သီးခြားတစ်ခုကို ရွေးမည့်အစား၊ ၎င်းသည် ဝန်ဆောင်မှုအတွက် တောင်းဆိုချက်တစ်ခု ပြုလုပ်သည်-

   

2. ဝန်ဆောင်မှုသည် ဦးတည်ရာလိပ်စာအဖြစ် backend pods များထဲမှ တစ်ခုကို ရွေးချယ်သည်-

   

3. ဝန်ဆောင်မှုမှရွေးချယ်ထားသော Pod 1 မှ Pod 5 သို့ လမ်းကြောင်းသွားသည်-

   

4. 1 နှစ်အောက် ဝန်ဆောင်မှုနောက်ကွယ်တွင် 5 နှစ်အောက်ကဲ့သို့ pod မည်မျှရှိသည်ကို အတိအကျမသိရပါ။

   

သို့သော် ဝန်ဆောင်မှုသည် တောင်းဆိုချက်များကို မည်ကဲ့သို့ အတိအကျဖြန့်ဝေသနည်း။ round-robin ချိန်ခွင်လျှာကို အသုံးပြုထားပုံရသည်။ အဖြေရှာကြည့်ရအောင်။ 

Kubernetes ဝန်ဆောင်မှုများတွင် ဟန်ချက်ညီခြင်း။

Kubernetes ဝန်ဆောင်မှုများ မရှိပါ။ IP လိပ်စာနှင့် ပို့တ်ကို သတ်မှတ်ပေးထားသည့် ဝန်ဆောင်မှုအတွက် လုပ်ငန်းစဉ်မရှိပါ။

အစုအဝေးရှိ မည်သည့် node သို့မဆို ဝင်ရောက်ပြီး netstat -ntlp အမိန့်ကို လုပ်ဆောင်ခြင်းဖြင့် ၎င်းကို အတည်ပြုနိုင်သည်။

ဝန်ဆောင်မှုအတွက် ခွဲဝေပေးထားသည့် IP လိပ်စာကိုပင် သင်ရှာတွေ့နိုင်မည် မဟုတ်ပါ။

ဝန်ဆောင်မှု၏ IP လိပ်စာသည် ထိန်းချုပ်မှုအလွှာ၊ ထိန်းချုပ်ကိရိယာတွင် တည်ရှိပြီး ဒေတာဘေ့စ်တွင် မှတ်တမ်းတင်ထားသည် - etcd။ တူညီသောလိပ်စာကို အခြားအစိတ်အပိုင်း - kube-proxy မှ အသုံးပြုပါသည်။
Kube-proxy သည် ဝန်ဆောင်မှုအားလုံးအတွက် IP လိပ်စာများစာရင်းကို လက်ခံရရှိပြီး အစုအဝေးရှိ node တစ်ခုစီရှိ iptables စည်းမျဉ်းများကို ထုတ်ပေးပါသည်။

ဤစည်းမျဉ်းများက "ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှု၏ IP လိပ်စာကို မြင်ပါက၊ တောင်းဆိုချက်၏ ဦးတည်ရာလိပ်စာကို ပြုပြင်ပြီး pods တစ်ခုသို့ ပေးပို့ရန် လိုအပ်ပါသည်။"

ဝန်ဆောင်မှု IP လိပ်စာကို ဝင်ခွင့်အမှတ်အဖြစ်သာ အသုံးပြုပြီး ၎င်း IP လိပ်စာနှင့် ပို့တ်ကို နားထောင်သည့် မည်သည့်လုပ်ငန်းစဉ်မှ ဆောင်ရွက်ပေးမည်မဟုတ်ပါ။

ဒါကိုကြည့်ရအောင်. 

1. node သုံးခု၏အစုအဝေးတစ်ခုကို သုံးသပ်ကြည့်ပါ။ node တစ်ခုစီတွင် pods များရှိသည်-

   

2. အဝါနုရောင်ခြယ်ထားသော ချည်ကြိုးများသည် ဝန်ဆောင်မှု၏ တစ်စိတ်တစ်ပိုင်းဖြစ်သည်။ ဝန်ဆောင်မှုသည် လုပ်ငန်းစဉ်တစ်ခုအဖြစ် မတည်ရှိသောကြောင့်၊ ၎င်းကို မီးခိုးရောင်ဖြင့် ပြသထားသည်-

   

3. ပထမ pod သည် ဝန်ဆောင်မှုတစ်ခုတောင်းဆိုပြီး သက်ဆိုင်ရာ pods များထဲမှ တစ်ခုကို သွားရပါမည်။

   

4. သို့သော် ဝန်ဆောင်မှုမရှိပါ၊ လုပ်ငန်းစဉ်မရှိပါ။ ဒါကဘယ်လိုမျိုးအလုပ်လုပ်သလဲ?

   

5. တောင်းဆိုချက်သည် node မှမထွက်ခွာမီ၊ ၎င်းသည် iptables စည်းမျဉ်းများမှတဆင့်လုပ်ဆောင်သည်-

   

6. iptables စည်းမျဉ်းများသည် ဝန်ဆောင်မှုမရှိသည်ကို သိရှိပြီး ၎င်းဝန်ဆောင်မှုနှင့် ဆက်စပ်နေသော pods များ၏ IP လိပ်စာများထဲမှ တစ်ခုဖြင့် ၎င်း၏ IP လိပ်စာကို အစားထိုးပါ-

   

7. တောင်းဆိုချက်သည် ဦးတည်ရာလိပ်စာအဖြစ် တရားဝင် IP လိပ်စာကို လက်ခံရရှိပြီး ပုံမှန်အတိုင်း လုပ်ဆောင်နေသည်-

   

8. ကွန်ရက် topology ပေါ်မူတည်၍ တောင်းဆိုချက်သည် နောက်ဆုံးတွင် pod သို့ရောက်ရှိသည်-

   

iptables သည် လက်ကျန်ငွေကို တင်နိုင်ပါသလား။

မဟုတ်ပါ၊ iptables များကို စစ်ထုတ်ရန်အတွက် အသုံးပြုထားပြီး ဟန်ချက်ညီရန်အတွက် ဒီဇိုင်းထုတ်ထားခြင်းမရှိပါ။

သို့သော် ၎င်းကဲ့သို့ လုပ်ဆောင်နိုင်သော စည်းမျဉ်းများကို ရေးနိုင်သည်။ pseudo-balancer.

ဤသည်မှာ Kubernetes တွင် အတိအကျ အကောင်အထည်ဖော်ထားသည်။

သင့်တွင် pod သုံးခုရှိပါက kube-proxy သည် အောက်ပါစည်းမျဉ်းများကို ရေးပေးလိမ့်မည်-

1. ဖြစ်နိုင်ခြေ 33% ဖြင့် ပထမအခွဲကို ရွေးပါ သို့မဟုတ် နောက်စည်းမျဉ်းသို့သွားပါ။
2. ဖြစ်နိုင်ခြေ 50% ရှိသော ဒုတိယတစ်ခုကို ရွေးပါ သို့မဟုတ် နောက်စည်းမျဉ်းသို့သွားပါ။
3. အောက်မှာ တတိယကို ရွေးပါ။

ဤစနစ်သည် pod တစ်ခုစီကို ဖြစ်နိုင်ခြေ 33% ဖြင့် ရွေးချယ်ခံရပါသည်။

ထို့အပြင် Pod 2 ပြီးနောက် Pod 1 ကို နောက်တစ်ကြိမ်ရွေးချယ်မည်ဟု အာမခံချက်မရှိပါ။

ပွောဆို: iptables သည် ကျပန်းဖြန့်ဝေမှုနှင့်အတူ ကိန်းဂဏန်းအချက်အလက်ကို အသုံးပြုသည်။ ထို့ကြောင့် ဟန်ချက်ညီသော အယ်လဂိုရီသမ်သည် ကျပန်းရွေးချယ်မှုအပေါ် အခြေခံသည်။

ဝန်ဆောင်မှုများ မည်သို့အလုပ်လုပ်သည်ကို ယခု သင်နားလည်ပြီး၊ ပိုမိုစိတ်ဝင်စားစရာကောင်းသော ဝန်ဆောင်မှုအခြေအနေများကို ကြည့်ကြပါစို့။

Kubernetes တွင် ကြာရှည်စွာ ချိတ်ဆက်မှုများသည် မူရင်းအတိုင်း အဆင့်မသတ်မှတ်ပါ။

ရှေ့တန်းမှ နောက်ကွယ်သို့ HTTP တောင်းဆိုမှုတစ်ခုစီကို အဖွင့်အပိတ်လုပ်သည့် သီးခြား TCP ချိတ်ဆက်မှုဖြင့် လုပ်ဆောင်သည်။

ရှေ့တန်းမှ နောက်ကွယ်သို့ တစ်စက္ကန့်လျှင် တောင်းဆိုချက် 100 ပို့ပါက၊ မတူညီသော TCP ချိတ်ဆက်မှု 100 ကို ဖွင့်ပြီး ပိတ်သည်။

TCP ချိတ်ဆက်မှုတစ်ခုဖွင့်ပြီး နောက်ဆက်တွဲ HTTP တောင်းဆိုမှုအားလုံးအတွက် ၎င်းကိုအသုံးပြုခြင်းဖြင့် တောင်းဆိုချက်လုပ်ဆောင်ချိန်နှင့် load ကို လျှော့ချနိုင်သည်။

HTTP ပရိုတိုကောတွင် HTTP Keep-alive သို့မဟုတ် ချိတ်ဆက်မှုကို ပြန်လည်အသုံးပြုခြင်းဟုခေါ်သည့် အင်္ဂါရပ်တစ်ခု ပါရှိသည်။ ဤကိစ္စတွင်၊ HTTP တောင်းဆိုချက်များနှင့် တုံ့ပြန်မှုများစွာကို ပေးပို့လက်ခံရန် TCP တစ်ခုတည်းချိတ်ဆက်မှုကို အသုံးပြုသည်-

ဤအင်္ဂါရပ်ကို ပုံသေအားဖြင့် ဖွင့်မထားပါ- ဆာဗာနှင့် ကလိုင်းယင့် နှစ်ခုလုံးကို လိုက်လျောညီထွေဖြစ်အောင် စီစဉ်ပေးရပါမည်။

စနစ်ထည့်သွင်းမှုကိုယ်တိုင်က ရိုးရှင်းပြီး ပရိုဂရမ်းမင်းဘာသာစကားများနှင့် ပတ်ဝန်းကျင်အများစုအတွက် အသုံးပြုနိုင်သည်။

ဤသည်မှာ ဘာသာစကားအမျိုးမျိုးဖြင့် နမူနာများသို့ လင့်ခ်အချို့ရှိပါသည်။

• Node.js တွင် ဆက်လက်ရှင်သန်ပါ။
• Spring boot မှာ ရှင်သန်ပါ။
• Python တွင် ဆက်လက်ရှင်သန်ပါ။
• .NET တွင် ဆက်လက်ရှင်သန်ပါ။

Kubernetes ဝန်ဆောင်မှုတွင် ကျွန်ုပ်တို့သည် ဆက်လက်ရှင်သန်နေပါက မည်သို့ဖြစ်မည်နည်း။
Frontend နှင့် Backend နှစ်ခုစလုံးသည် ဆက်လက်ရှင်သန်နေမည်ဟု ယူဆကြပါစို့။

ကျွန်ုပ်တို့တွင် ရှေ့တန်း၏မိတ္တူတစ်အုပ်နှင့် နောက်ကွယ်တွင် မိတ္တူသုံးအုပ်ရှိသည်။ Frontend သည် ပထမဆုံးတောင်းဆိုမှုကို ပြုလုပ်ပြီး နောက်ကွယ်သို့ TCP ချိတ်ဆက်မှုကို ဖွင့်ပေးသည်။ တောင်းဆိုချက်သည် ဝန်ဆောင်မှုသို့ရောက်ရှိသွားပြီး၊ နောက်ခံအပေါက်များထဲမှ တစ်ခုကို ဦးတည်ရာလိပ်စာအဖြစ် ရွေးချယ်ထားသည်။ နောက်ကွယ်မှ တုံ့ပြန်မှုတစ်ခု ပေးပို့ပြီး ရှေ့တန်းမှ လက်ခံသည်။

တုံ့ပြန်မှုရရှိပြီးနောက် TCP ချိတ်ဆက်မှုကို ပိတ်ထားသည့် ပုံမှန်အခြေအနေနှင့် မတူဘဲ၊ ၎င်းသည် နောက်ထပ် HTTP တောင်းဆိုမှုများကို ဆက်လက်ဖွင့်ထားသည်။

ရှေ့တန်းမှ နောက်ကွယ်သို့ နောက်ထပ် တောင်းဆိုမှုများ ပို့ပါက ဘာဖြစ်နိုင်မည်နည်း။

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

iptables သည် အသွားအလာကို ပြန်လည်ဖြန့်ဝေခြင်းမပြုသင့်ပါ။

ဒီကိစ္စမှာ မဟုတ်ပါဘူး။

TCP ချိတ်ဆက်မှုကို ဖန်တီးသောအခါ၊ ၎င်းသည် အသွားအလာများသွားမည့် တိကျသော နောက်ကွယ်မှတစ်ခုကို ရွေးချယ်ပေးသည့် iptables စည်းမျဉ်းများမှတစ်ဆင့် လုပ်ဆောင်သည်။

နောက်ဆက်တွဲတောင်းဆိုမှုများအားလုံးသည် ဖွင့်ပြီးသား TCP ချိတ်ဆက်မှုတွင် ရှိနေသောကြောင့် iptables စည်းမျဉ်းများကို မခေါ်တော့ပါ။

ဘယ်လိုပုံစံလဲဆိုတာ ကြည့်လိုက်ရအောင်.

1. ပထမ pod သည် ဝန်ဆောင်မှုထံသို့ တောင်းဆိုချက်တစ်ခု ပေးပို့သည်-

   

2. နောက်ဘာဆက်ဖြစ်မယ်ဆိုတာ သိပြီးသားပါ။ ဝန်ဆောင်မှုမရှိသော်လည်း တောင်းဆိုချက်ကို လုပ်ဆောင်ပေးမည့် iptables စည်းမျဉ်းများ ရှိပါသည်။

   

3. Backend pods များထဲမှ တစ်ခုကို ဦးတည်ရာလိပ်စာအဖြစ် ရွေးချယ်ပါမည်-

   

4. တောင်းဆိုချက်က စပါးခင်းထဲ ရောက်သွားတယ်။ ဤအချိန်တွင် pods နှစ်ခုကြားတွင် အမြဲရှိနေသော TCP ချိတ်ဆက်မှုကို တည်ထောင်ပါမည်-

   

5. ပထမ pod မှနောက်ဆက်တွဲတောင်းဆိုမှုမှန်သမျှသည် သတ်မှတ်ပြီးသားချိတ်ဆက်မှုမှတဆင့်သွားပါမည်-

   

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

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

ဒါကိုပြင်နိုင်သလား။

Kubernetes သည် အမြဲမပြတ်ချိတ်ဆက်မှုများကို ဟန်ချက်ညီအောင် မည်သို့ထိန်းရမည်ကို မသိသောကြောင့်၊ ဤတာဝန်သည် သင့်အတွက်ဖြစ်သည်။

ဝန်ဆောင်မှုများသည် endpoints ဟုခေါ်သော IP လိပ်စာများနှင့် port များစုစည်းမှုဖြစ်သည်။

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

သို့မဟုတ် ပိုမိုလျှောက်ထားပါ။ ရှုပ်ထွေးသော ဟန်ချက်ညီသော အယ်ဂိုရီသမ်များ.

ဟန်ချက်ညီမှုအတွက် တာဝန်ရှိသော client-side code သည် ဤယုတ္တိဗေဒနှင့် ကိုက်ညီသင့်သည်-

1. ဝန်ဆောင်မှုမှ အဆုံးမှတ်များစာရင်းကို ရယူပါ။
2. အဆုံးမှတ်တစ်ခုစီအတွက် အမြဲမပြတ်ချိတ်ဆက်မှုကို ဖွင့်ပါ။
3. တောင်းဆိုမှုတစ်ခုပြုလုပ်ရန်လိုအပ်သည့်အခါတွင် ဖွင့်ထားသောချိတ်ဆက်မှုများကို အသုံးပြုပါ။
4. အဆုံးမှတ်များစာရင်းကို ပုံမှန်မွမ်းမံပါ၊ အသစ်များဖန်တီးပါ သို့မဟုတ် စာရင်းပြောင်းလဲပါက ဆက်တိုက်ချိတ်ဆက်မှုဟောင်းများကို ပိတ်ပါ။

ဒါက ဘယ်လိုပုံစံပါလိမ့်.

1. ဝန်ဆောင်မှုထံ တောင်းဆိုချက်ကို ပထမဆုံး pod ပေးပို့မည့်အစား၊ သင်သည် တောင်းဆိုချက်များကို ဖောက်သည်ဘက်မှ ချိန်ခွင်လျှာညှိနိုင်သည်-

   

2. မည်သည့် pods များသည် ဝန်ဆောင်မှု၏ အစိတ်အပိုင်းဖြစ်သနည်းဟု မေးသော ကုဒ်ကို ရေးရန် လိုအပ်သည်-

   

3. သင့်တွင်စာရင်းရှိသည်နှင့်တစ်ပြိုင်နက်၊ ၎င်းကို client ဘက်တွင်သိမ်းဆည်းပြီး pods များနှင့်ချိတ်ဆက်ရန်၎င်းကိုအသုံးပြုပါ။

   

4. Load Balancing algorithm အတွက် သင်သည် တာဝန်ရှိသည်-

   

ယခုမေးခွန်းပေါ်လာသည်- ဤပြဿနာသည် HTTP Keep-alive နှင့်သာသက်ဆိုင်ပါသလား။

Client-side load balancing

HTTP သည် အမြဲတမ်း TCP ချိတ်ဆက်မှုများကို အသုံးပြုနိုင်သည့် တစ်ခုတည်းသော ပရိုတိုကောမဟုတ်ပါ။

အကယ်၍ သင့်အပလီကေးရှင်းသည် ဒေတာဘေ့စ်ကို အသုံးပြုပါက၊ သင်တောင်းဆိုမှုပြုလုပ်ရန် သို့မဟုတ် ဒေတာဘေ့စ်မှ စာရွက်စာတမ်းကို ရယူလိုသည့်အခါတိုင်း TCP ချိတ်ဆက်မှုကို ဖွင့်မည်မဟုတ်ပါ။ 

ယင်းအစား၊ ဒေတာဘေ့စ်သို့ မြဲမြံသော TCP ချိတ်ဆက်မှုကို ဖွင့်ပြီး အသုံးပြုသည်။

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

ဒေတာဘေ့စ်ပုံတူတစ်ခုသည် အခြားအရာများထက် ပိုမိုတင်ဆောင်မည်ဖြစ်သည်။ Kube-proxy နှင့် Kubernetes တို့သည် ချိတ်ဆက်မှုများကို ဟန်ချက်ညီအောင် ကူညီပေးမည်မဟုတ်ပါ။ သင့်ဒေတာဘေ့စ်တွင် မေးမြန်းချက်များကို ဟန်ချက်ညီစေရန် ဂရုစိုက်ရမည်။

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

အောက်တွင် Node.js မှ MySQL database အစုအဝေးကို ဝင်ရောက်ခြင်း၏ ဥပမာတစ်ခုဖြစ်သည်။

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

ဆက်တိုက် TCP ချိတ်ဆက်မှုများကို အသုံးပြုသည့် အခြားသော ပရိုတိုကောများစွာ ရှိပါသည်။

• WebSockets နှင့် လုံခြုံသော WebSockets
• သည် HTTP / 2
• gRPC
• RSockets များ
• AMQP

သင်သည် ဤပရိုတိုကောအများစုနှင့် ရင်းနှီးပြီးသားဖြစ်သင့်သည်။

သို့သော် ဤပရိုတိုကောများသည် အလွန်ရေပန်းစားပါက၊ အဘယ်ကြောင့် စံချိန်စံညွှန်းချိန်ခွင်လျှာညှိဖြေရှင်းချက်မရှိသနည်း။ client logic ကို ဘာကြောင့် ပြောင်းလဲဖို့ လိုအပ်တာလဲ။ မူရင်း Kubernetes ဖြေရှင်းချက် ရှိပါသလား။

Kubernetes တွင် အသုံးပြုသောအခါတွင် အသုံးများသော အသုံးအများဆုံးကိစ္စများကို ကာမိစေရန် Kube-proxy နှင့် iptables များကို ဒီဇိုင်းထုတ်ထားပါသည်။ ဒါက အဆင်ပြေဖို့ပါ။

အကယ်၍ သင်သည် REST API ကို ဖော်ထုတ်သည့် ဝဘ်ဝန်ဆောင်မှုကို အသုံးပြုနေပါက သင်သည် ကံကောင်းခြင်းဖြစ်သည် - ဤအခြေအနေတွင်၊ ဆက်တိုက် TCP ချိတ်ဆက်မှုများကို အသုံးမပြုပါ၊ မည်သည့် Kubernetes ဝန်ဆောင်မှုကိုမဆို သင်အသုံးပြုနိုင်ပါသည်။

သို့သော် သင်သည် အမြဲတစေ TCP ချိတ်ဆက်မှုများကို စတင်အသုံးပြုသည်နှင့် တပြိုင်နက်၊ backends တစ်လျှောက် ဝန်ကို အညီအမျှ ဖြန့်ဝေနည်းကို သင်ရှာဖွေရမည်ဖြစ်ပါသည်။ Kubernetes တွင် ဤကိစ္စအတွက် အဆင်သင့်လုပ်ထားသော ဖြေရှင်းချက်များ မပါဝင်ပါ။

သို့သော်၊ ကူညီပေးနိုင်သည့် ရွေးချယ်စရာများ သေချာပေါက်ရှိပါသည်။

Kubernetes ရှိ ရေရှည်ချိတ်ဆက်မှုများကို ဟန်ချက်ညီစေခြင်း။

Kubernetes တွင် ဝန်ဆောင်မှု လေးမျိုး ရှိပါသည်။

1. ClusterIP
2. NodePort
3. LoadBalancer
4. ခေါင်းစဉ်

ပထမဝန်ဆောင်မှုသုံးခုသည် iptables စည်းမျဉ်းများတည်ဆောက်ရန်အတွက် kube-proxy မှအသုံးပြုသည့် virtual IP လိပ်စာကိုအခြေခံ၍ လုပ်ဆောင်သည်။ ဒါပေမယ့် ဝန်ဆောင်မှုအားလုံးရဲ့ အခြေခံကတော့ ခေါင်းမပါတဲ့ ဝန်ဆောင်မှုတစ်ခုပါပဲ။

headless ဝန်ဆောင်မှုတွင် ၎င်းနှင့် ဆက်စပ်နေသည့် မည်သည့် IP လိပ်စာမျှ မပါရှိဘဲ ၎င်းနှင့် ဆက်စပ်နေသည့် pods (endpoints) များ၏ IP လိပ်စာများစာရင်းနှင့် ports များကို ပြန်လည်ရယူရန်အတွက် ယန္တရားတစ်ခုသာ ပံ့ပိုးပေးပါသည်။

ဝန်ဆောင်မှုအားလုံးသည် headless ဝန်ဆောင်မှုအပေါ်အခြေခံသည်။

ClusterIP ဝန်ဆောင်မှုသည် အချို့သော အပိုဆောင်းမှုများပါရှိသော ခေါင်းမပါသော ဝန်ဆောင်မှုတစ်ခုဖြစ်သည်။ 

1. စီမံခန့်ခွဲမှုအလွှာသည် ၎င်းအား IP လိပ်စာတစ်ခုသတ်မှတ်ပေးသည်။
2. Kube-proxy သည် လိုအပ်သော iptables စည်းမျဉ်းများကို ထုတ်ပေးသည်။

ဤနည်းဖြင့် သင်သည် kube-proxy ကို လျစ်လျူရှုပြီး သင့်အပလီကေးရှင်းလက်ကျန်ငွေကိုရယူရန် headless ဝန်ဆောင်မှုမှရရှိသော အဆုံးမှတ်များစာရင်းကို တိုက်ရိုက်အသုံးပြုနိုင်ပါသည်။

သို့သော် အစုအဝေးတွင် ထည့်သွင်းထားသော အပလီကေးရှင်းများအားလုံးတွင် ဆင်တူသောယုတ္တိကို ကျွန်ုပ်တို့ မည်သို့ထည့်နိုင်မည်နည်း။

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

Service Mesh က သင့်ကို ကူညီပါလိမ့်မယ်။

client-side load balancing strategy သည် အတော်လေး standard ဖြစ်သည်ကို သင် သတိပြုမိပြီးသား ဖြစ်ကောင်းဖြစ်နိုင်ပါသည်။

လျှောက်လွှာစတင်သောအခါ၊

1. ဝန်ဆောင်မှုမှ IP လိပ်စာများစာရင်းကို ရယူပါ။
2. ချိတ်ဆက်မှုရေကန်ကို ဖွင့်ပြီး ထိန်းသိမ်းထားသည်။
3. အဆုံးမှတ်များကို ပေါင်းထည့်ခြင်း သို့မဟုတ် ဖယ်ရှားခြင်းဖြင့် ရေကူးကန်ကို အခါအားလျော်စွာ အပ်ဒိတ်လုပ်ပါ။

အပလီကေးရှင်းသည် တောင်းဆိုချက်တစ်ခုပြုလုပ်လိုပါက၊

1. ယုတ္တိဗေဒအချို့ (ဥပမာ- round-robin) ကို အသုံးပြု၍ ရနိုင်သောချိတ်ဆက်မှုတစ်ခုကို ရွေးပါ။
2. တောင်းဆိုချက်ကို အကောင်အထည်ဖော်သည်။

ဤအဆင့်များသည် WebSockets၊ gRPC နှင့် AMQP ချိတ်ဆက်မှုများ နှစ်ခုလုံးအတွက် အလုပ်လုပ်ပါသည်။

သင်သည် ဤယုတ္တိကို သီးခြားစာကြည့်တိုက်တစ်ခုအဖြစ် ခွဲခြားနိုင်ပြီး သင်၏အက်ပ်လီကေးရှင်းများတွင် အသုံးပြုနိုင်သည်။

သို့သော် Istio သို့မဟုတ် Linkerd ကဲ့သို့သော ဝန်ဆောင်မှု meshes များကို သင်အသုံးပြုနိုင်ပါသည်။

Service Mesh သည် သင့်လျှောက်လွှာကို မြှင့်တင်ပေးသည့် လုပ်ငန်းစဉ်တစ်ခုဖြစ်သည်-

1. ဝန်ဆောင်မှု IP လိပ်စာများကို အလိုအလျောက် ရှာဖွေသည်။
2. WebSockets နှင့် gRPC ကဲ့သို့သော ချိတ်ဆက်မှုများကို စမ်းသပ်သည်။
3. မှန်ကန်သော ပရိုတိုကောကို အသုံးပြု၍ တောင်းဆိုမှုများကို ချိန်ခွင်လျှာညှိပေးသည်။

Service Mesh သည် အစုအဝေးအတွင်း အသွားအလာကို စီမံခန့်ခွဲရာတွင် ကူညီပေးသည်၊ သို့သော် ၎င်းသည် အရင်းအမြစ်-အသုံးများသည်။ အခြားရွေးချယ်စရာများမှာ Netflix Ribbon ကဲ့သို့သော ပြင်ပအဖွဲ့အစည်း စာကြည့်တိုက်များ သို့မဟုတ် Envoy ကဲ့သို့ ပရိုဂရမ်ထုတ်နိုင်သော ပရိုစီများကို အသုံးပြုပါသည်။

ညီမျှခြင်းပြဿနာများကို လျစ်လျူရှုပါက မည်သို့ဖြစ်မည်နည်း။

load ချိန်ခွင်လျှာကို အသုံးမပြုရန် သင်ရွေးချယ်နိုင်ပြီး မည်သည့်ပြောင်းလဲမှုကိုမျှ သတိမထားမိသေးပါ။ အလုပ်အခြေအနေအချို့ကို ကြည့်ကြပါစို့။

သင့်တွင် ဆာဗာများထက် ဖောက်သည်များ ပိုများနေပါက၊ ဤမျှ ကြီးမားသော ပြဿနာ မဟုတ်ပါ။

ဆာဗာနှစ်ခုသို့ချိတ်ဆက်သော client ငါးခုရှိသည်ဆိုကြပါစို့။ ဟန်ချက်ညီခြင်း မရှိသော်လည်း၊ ဆာဗာနှစ်ခုလုံးကို အသုံးပြုပါမည်-

ချိတ်ဆက်မှုများကို အညီအမျှ ဖြန့်ဝေနိုင်မည်မဟုတ်ပါ- တူညီသောဆာဗာသို့ ချိတ်ဆက်ထားသော client လေးခုဖြစ်ကောင်းဖြစ်နိုင်သော်လည်း ဆာဗာနှစ်ခုလုံးကို အသုံးပြုရန် အခွင့်အလမ်းကောင်းရှိပါသည်။

ပို၍ ပြဿနာမှာ ဆန့်ကျင်ဘက် မြင်ကွင်းဖြစ်သည်။

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

client နှစ်ခုနှင့် server ငါးခုရှိသည်ဆိုပါစို့။ အကောင်းဆုံးအခြေအနေတွင်၊ ငါးခုတွင် ဆာဗာနှစ်ခုသို့ အမြဲတမ်းချိတ်ဆက်မှုနှစ်ခုရှိမည်ဖြစ်သည်။

ကျန်ဆာဗာများသည် idle ဖြစ်နေလိမ့်မည်-

အကယ်၍ ဤဆာဗာနှစ်ခုသည် ကလိုင်းယင့်တောင်းဆိုမှုများကို မကိုင်တွယ်နိုင်ပါက၊ အလျားလိုက် အတိုင်းအတာဖြင့် ကူညီမည်မဟုတ်ပါ။

ကောက်ချက်

Kubernetes ဝန်ဆောင်မှုများသည် ပုံမှန်ဝဘ်အက်ပလီကေးရှင်းအခြေအနေအများစုတွင် အလုပ်လုပ်ရန် ဒီဇိုင်းထုတ်ထားသည်။

သို့သော်၊ ဒေတာဘေ့စ်များ၊ gRPC သို့မဟုတ် WebSockets များကဲ့သို့ ဆက်တိုက် TCP ချိတ်ဆက်မှုများကို အသုံးပြုသည့် အပလီကေးရှင်းပရိုတိုကောများနှင့် စတင်လုပ်ဆောင်သောအခါ၊ ဝန်ဆောင်မှုများသည် သင့်လျော်တော့မည်မဟုတ်ပါ။ Kubernetes သည် အမြဲမပြတ် TCP ချိတ်ဆက်မှုများကို ချိန်ခွင်လျှာညှိရန်အတွက် အတွင်းပိုင်းယန္တရားများကို ပံ့ပိုးမပေးပေ။

ဆိုလိုသည်မှာ သင်သည် client-side balancing ကိုစိတ်ထဲရှိအပလီကေးရှင်းများရေးသားရမည်ဟုဆိုလိုသည်။

ဘာသာပြန်အဖွဲ့မှ ပြင်ဆင်သည်။ Mail.ru မှ Kubernetes aaS.

နောက်ထပ် ဘာအကြောင်းအရာတွေ ဆက်ဖတ်ရမလဲ:

1. Kubernetes တွင် အော်တိုစကေးချဲ့ခြင်း အဆင့်သုံးဆင့်နှင့် ၎င်းတို့ကို ထိရောက်စွာ အသုံးပြုနည်း. 
2. အကောင်အထည်ဖော်ရန်အတွက် နမူနာပုံစံဖြင့် ခိုးကူးမှုသဘောဖြင့် Kubernetes.
3. ဒစ်ဂျစ်တယ်အသွင်ပြောင်းခြင်းအကြောင်း ကျွန်ုပ်တို့၏ Telegram ချန်နယ်.

source: www.habr.com