Kubernetes Networking Plugin (CNI) Benchmark ရလဒ်များသည် 10 Gbps ကွန်ရက်ကျော် (ဧပြီ 2019 တွင် အပ်ဒိတ်လုပ်ထားသည်)

ဤသည်မှာ ကျွန်ုပ်၏ အပ်ဒိတ်ဖြစ်သည်။ ယခင်စံနှုန်းများ1.14 ခုနှစ် ဧပြီလအထိ နောက်ဆုံးထွက် CNI ဗားရှင်းဖြင့် Kubernetes 2019 တွင် အသုံးပြုထားသည်။

ပထမဆုံးအနေနဲ့၊ Cilium အဖွဲ့ကို ကျေးဇူးတင်ချင်ပါတယ်- ယောက်ျားတွေက ကျွန်တော့်ကို မက်ထရစ်စောင့်ကြည့်ရေး script တွေကို စစ်ဆေးပြီး ပြင်ပေးခဲ့တယ်။

2018 ခုနှစ် နိုဝင်ဘာလကတည်းက ဘာတွေပြောင်းလဲသွားလဲ။

ဤသည်မှာ ထိုအချိန်မှစ၍ ပြောင်းလဲသွားသည် (သင်စိတ်ဝင်စားပါက-)

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

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

ယခု WeaveNet သည် Ingress နှင့် Egress အတွက် ကွန်ရက်မူဝါဒများကို ပံ့ပိုးပေးပါသည်။ ဒါပေမယ့် ကုန်ထုတ်စွမ်းအား ကျဆင်းသွားတယ်။

Calico တွင်၊ အကောင်းဆုံးစွမ်းဆောင်ရည်အတွက် သင်သည် အများဆုံး packet အရွယ်အစား (MTU) ကို ကိုယ်တိုင် configure လုပ်ရန် လိုအပ်သေးသည်။ Calico သည် CNI တပ်ဆင်ခြင်းအတွက် ရွေးချယ်စရာနှစ်ခုကို ပေးဆောင်ထားသောကြောင့် သီးခြား ETCD repository မပါဘဲ သင်လုပ်ဆောင်နိုင်သည်-

• ဒေတာသိုလှောင်မှုအဖြစ် Kubernetes API တွင် အခြေအနေကို သိမ်းဆည်းခြင်း (အစုအဝေးအရွယ်အစား < 50 nodes);
• K8S API (အစုအဝေး အရွယ်အစား > 50 nodes) တွင် ဝန်အားလျော့ပါးစေရန် Typha proxy ဖြင့် ဒေတာသိုလှောင်မှုအဖြစ် Kubernetes API တွင် သိမ်းဆည်းခြင်း။

Calico က ထောက်ခံကြောင်း ကြေညာခဲ့သည်။ လျှောက်လွှာအဆင့်မူဝါဒများ အပလီကေးရှင်းအဆင့်လုံခြုံရေးအတွက် Istio ၏ထိပ်တွင်။

ယခု Cilium သည် ကုဒ်ဝှက်ခြင်းကို ပံ့ပိုးပေးပါသည်။ Cilium သည် IPSec ဥမင်လိုဏ်ခေါင်းများဖြင့် ကုဒ်ဝှက်ခြင်းကို ပံ့ပိုးပေးပြီး ကုဒ်ဝှက်ထားသော WeaveNet ကွန်ရက်အတွက် အခြားရွေးချယ်စရာတစ်ခုကို ပေးပါသည်။ သို့သော် WeaveNet သည် စာဝှက်စနစ်ဖွင့်ထားသည့် Cilium ထက် ပိုမြန်သည်။

Cilium သည် built-in ETCD အော်ပရေတာကြောင့် ယခုအခါတွင် ပိုမိုလွယ်ကူစွာ အသုံးပြုနိုင်ပါပြီ။

Cilium အဖွဲ့သည် မှတ်ဉာဏ်သုံးစွဲမှုနှင့် CPU ကုန်ကျစရိတ်များကို လျှော့ချခြင်းဖြင့် ၎င်း၏ CNI မှ အလေးချိန်အချို့ကို ချုံ့ရန် ကြိုးစားခဲ့သော်လည်း ၎င်း၏ပြိုင်ဘက်များသည် ပိုမိုပေါ့ပါးဆဲဖြစ်သည်။

စံညွှန်းဆက်စပ်မှု

စံသတ်မှတ်ချက်ကို 10 Gb Supermicro ခလုတ်ဖြင့် အတုမဟုတ်သော Supermicro ဆာဗာသုံးခုတွင် လုပ်ဆောင်သည်။ ဆာဗာများကို passive DAC SFP+ ကြိုးများမှတဆင့် switch သို့ တိုက်ရိုက်ချိတ်ဆက်ထားပြီး jumbo frames (MTU 9000) နှင့်တူညီသော VLAN ပေါ်တွင် configure လုပ်ထားသည်။

Kubernetes 1.14.0 ကို Docker 18.04 ဖြင့် Ubuntu 18.09.2 LTS တွင် ထည့်သွင်းထားသည် (ဤထုတ်ဝေမှုတွင် မူရင်း Docker ဗားရှင်း)။

မျိုးပွားနိုင်မှုကို မြှင့်တင်ရန်၊ ကျွန်ုပ်တို့သည် မာစတာကို ပထမ node တွင် အမြဲတမ်း configure လုပ်ရန်၊ ဒုတိယ server တွင် benchmark ၏ server အစိတ်အပိုင်းနှင့် client part ကို တတိယတွင် ထားရှိရန် ဆုံးဖြတ်ခဲ့သည်။ ဒါကိုလုပ်ဖို့၊ Kubernetes ဖြန့်ကျက်မှုမှာ NodeSelector ကို အသုံးပြုပါတယ်။

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

စံညွှန်းတစ်ခုအတွက် CNI ကို ရွေးချယ်ခြင်း။

၎င်းသည် ကဏ္ဍရှိစာရင်းမှ CNI အတွက်သာ စံသတ်မှတ်ချက်တစ်ခုဖြစ်သည်။ kubeadm ဖြင့် master cluster တစ်ခုဖန်တီးခြင်းအကြောင်း တရားဝင် Kubernetes စာရွက်စာတမ်းကို ကြည့်ပါ။ CNI 9 ခုတွင်၊ ကျွန်ုပ်တို့သည် 6 ခုသာ ယူပါမည်- စာရွက်စာတမ်းများ (Romana၊ Contiv-VPP နှင့် JuniperContrail/TungstenFabric) အရ တပ်ဆင်ရန် ခက်ခဲသော နှင့်/သို့မဟုတ် မလုပ်ဆောင်နိုင်သော အရာများကို ဖယ်ထုတ်ပါမည်။

အောက်ပါ CNI များကို နှိုင်းယှဉ်ပါမည်။

• Calico v3.6
• Canal v3.6 (ကွန်ရက်ချိတ်ဆက်မှုအတွက် အဓိကအားဖြင့် Flannel + Calico ကို firewall အဖြစ်)
• Cilium 1.4.2
• ဖလန်နယ် 0.11.0
• Kube-router 0.2.5
• WeaveNet 2.5.1

ustanovka

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

ကျွန်ုပ်တို့ပြောခဲ့သည့်အတိုင်း၊ ဆာဗာများနှင့် ခလုတ်များကို jumbo frames များဖြင့် configure လုပ်ထားပါသည် (ကျွန်ုပ်တို့သည် MTU ကို 9000 သို့ သတ်မှတ်သည်)။ အဒက်တာများ၏ဖွဲ့စည်းပုံအပေါ်အခြေခံ၍ CNI မှ MTU ကိုအလိုအလျောက်ဆုံးဖြတ်ပါကကျွန်ုပ်တို့ပျော်ရွှင်ပါမည်။ သို့သော်၊ Cilium နှင့် Flannel ကသာ ၎င်းကို စီမံခန့်ခွဲသည်။ ကျန် CNI များသည် အလိုအလျောက် MTU ရှာဖွေတွေ့ရှိမှုကို ထည့်သွင်းရန် GitHub တွင် တောင်းဆိုမှုများရှိသော်လည်း Calico၊ Canal နှင့် Kube-router အတွက် ConfigMap ကိုပြောင်းလဲခြင်း သို့မဟုတ် WeaveNet အတွက် ပတ်ဝန်းကျင်ပြောင်းလဲမှုတစ်ခုအား ဖြတ်သန်းခြင်းဖြင့် ၎င်းကို ကိုယ်တိုင်စီစဉ်ပေးပါမည်။

MTU မမှန်ခြင်း ပြဿနာက ဘာလဲ။ ဤပုံကြမ်းသည် ပုံသေ MTU နှင့် jumbo frames များဖြင့် WeaveNet အကြား ခြားနားချက်ကို ပြသည်-

MTU သည် throughput ကိုမည်သို့အကျိုးသက်ရောက်သနည်း။

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

CNI သည် MTU ကို အလိုအလျောက် သိရှိသည်။

အကောင်းဆုံးစွမ်းဆောင်ရည်အတွက် Calico၊ Canal၊ Kube-router နှင့် WeaveNet အတွက် MTU ကို သတ်မှတ်ရန် လိုအပ်ကြောင်း ဂရပ်က ဖော်ပြသည်။ Cilium နှင့် Flannel တို့သည် မည်သည့်ဆက်တင်များမပါဘဲ MTU ကို မှန်ကန်စွာ ဆုံးဖြတ်နိုင်ခဲ့ကြသည်။

လုံခွုံမှု

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

ဒေတာကို CNI နှစ်ခုသာ ကုဒ်ဝှက်ထားသည်- Cilium နှင့် WeaveNet။ ကုဒ်ဝှက်ခြင်း WeaveNet ကုဒ်ဝှက်ခြင်း စကားဝှက်ကို CNI ပတ်၀န်းကျင် ပြောင်းလဲမှုအဖြစ် သတ်မှတ်ခြင်းဖြင့် ဖွင့်ထားသည်။ IN စာရွက်စာတမ်း WeaveNet သည် ၎င်းအား ရှုပ်ထွေးသောနည်းလမ်းဖြင့် ဖော်ပြသော်လည်း အရာအားလုံးသည် ရိုးရှင်းစွာလုပ်ဆောင်ပါသည်။ ကုဒ်ဝှက်ခြင်း cilium Kubernetes လျှို့ဝှက်ချက်များကို ဖန်တီးပြီး daemonSet ကို ပြုပြင်မွမ်းမံခြင်းဖြင့် ညွှန်ကြားချက်များဖြင့် ပြင်ဆင်သတ်မှတ်ထားသည် (WeaveNet ထက် အနည်းငယ် ပိုရှုပ်ထွေးသော်လည်း Cilium တွင် အဆင့်ဆင့် ရှိပါသည်။ ညွှန်ကြားချက်).

ကွန်ရက်ပေါ်လစီကို အကောင်အထည်ဖော်ရာတွင် အောင်မြင်ခဲ့သည်။ Calico၊ Canal၊ Cilium နှင့် WeaveNetIngress နှင့် Egress စည်းမျဉ်းများကို သင် configure လုပ်နိုင်သော၊ ဘို့ Kube-router Ingress အတွက်သာ စည်းမျဉ်းတွေ ရှိတယ်။ Flannel ကွန်ရက်မူဝါဒများ လုံးဝမရှိပါ။

ဤသည်မှာ စုစုပေါင်းရလဒ်များဖြစ်သည်-

ဘေးကင်းရေး စွမ်းဆောင်ရည် စံညွှန်းရလဒ်များ

ထွက်နိုင်ရေး

ဤစံနှုန်းသည် စမ်းသပ်မှုတစ်ခုစီ၏ အနည်းဆုံးသုံးကြိမ်ကျော် ပျမ်းမျှဖြတ်သန်းမှုကို ပြသသည်။ ကျွန်ုပ်တို့သည် TCP နှင့် UDP (iperf3 ကိုအသုံးပြု၍)၊ HTTP (Nginx နှင့် curl) ကဲ့သို့ တကယ့်အပလီကေးရှင်းများ သို့မဟုတ် FTP (vsftpd နှင့် curl) နှင့် နောက်ဆုံးတွင် SCP-based encryption (ကလိုင်းယင့်နှင့်ဆာဗာ OpenSSH ကိုအသုံးပြု၍ အပလီကေးရှင်းစွမ်းဆောင်ရည်ကို စမ်းသပ်ပါသည်။

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

• အဝါရောင် = အလွန်ကောင်းသည်။
• လိမ္မော် = ကောင်းသည်။
• အပြာ = ဒါပေ့ါ
• အနီ = မကောင်း

ကျွန်ုပ်တို့သည် မှားယွင်းစွာပြင်ဆင်ထားသော CNI များကို မယူဘဲ မှန်ကန်သော MTU များဖြင့် CNI များအတွက် ရလဒ်များကိုသာ ပြသပါမည်။ (မှတ်ချက်- Cilium သည် ကုဒ်ဝှက်ခြင်းကို ဖွင့်ထားလျှင် MTU ကို မှန်ကန်စွာ မတွက်ချက်နိုင်သောကြောင့် ဗားရှင်း 8900 တွင် MTU ကို 1.4 သို့ ကိုယ်တိုင်လျှော့ချရမည်ဖြစ်ပါသည်။ နောက်ဗားရှင်း 1.5 သည် ၎င်းကို အလိုအလျောက် လုပ်ဆောင်ပါသည်။)

ဤသည်မှာ ရလဒ်များဖြစ်သည်-

TCP စွမ်းဆောင်ရည်

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

UDP စွမ်းဆောင်ရည်

ဤတွင်လည်း CNI များအားလုံး ကောင်းမွန်စွာ လုပ်ဆောင်နေပါသည်။ စာဝှက်စနစ်ဖြင့် CNI သည် တူညီသောရလဒ်ကို ပြသခဲ့သည်။ Cilium သည် ပြိုင်ဆိုင်မှုနောက်တွင် အနည်းငယ်သာရှိသော်လည်း ၎င်းသည် သတ္တုဗလာ၏ 2,3% သာဖြစ်သောကြောင့် ရလဒ်မကောင်းပါ။ Cilium နှင့် Flannel သာလျှင် MTU ကို ၎င်းတို့ကိုယ်တိုင် မှန်ကန်စွာ ဆုံးဖြတ်ခဲ့ပြီး ၎င်းတို့သည် အပိုဖွဲ့စည်းမှုတစ်ခုမျှမပါဘဲ ၎င်းတို့၏ရလဒ်များဖြစ်ကြောင်း မမေ့ပါနှင့်။

တကယ့် application ကကော? သင်တွေ့မြင်ရသည့်အတိုင်း HTTP အတွက် အလုံးစုံစွမ်းဆောင်ရည်သည် TCP ထက် အနည်းငယ်နိမ့်သည်။ HTTP ဖြင့် သင် TCP ကို ​​အသုံးပြုလျှင်ပင် HTTP စံညွှန်းကို ထိခိုက်စေမည့် နှေးကွေးသော အစပြုခြင်းကို ရှောင်ရှားရန် ကျွန်ုပ်တို့သည် TCP စံညွှန်းတွင် iperf3 ကို ပြင်ဆင်သတ်မှတ်ထားပါသည်။ လူတိုင်းက ဒီမှာ အလုပ်ကောင်းကောင်းလုပ်ခဲ့တယ်။ Kube-router တွင် ရှင်းရှင်းလင်းလင်း အားသာချက် ရှိသည်၊ သို့သော် WeaveNet သည် ကောင်းစွာ မစွမ်းဆောင်နိုင်ခဲ့ပါ- သတ္တုမပါသော သတ္တုထက် 20% ခန့် ပိုဆိုးသည်။ ကုဒ်ဝှက်ခြင်းပါရှိသော Cilium နှင့် WeaveNet သည် အမှန်တကယ်ပင် ဝမ်းနည်းဖွယ်ကောင်းသည်။

FTP၊ အခြားသော TCP-based protocol ဖြင့် ရလဒ်များ ကွဲပြားသည်။ Flannel နှင့် Kube-router သည် အလုပ်ဖြစ်သည်၊ သို့သော် Calico၊ Canal နှင့် Cilium သည် အနည်းငယ်နောက်ကျနေပြီး သတ္တုဗလာထက် 10% ခန့်နှေးကွေးပါသည်။ WeaveNet သည် 17% ထက်များစွာနောက်ကျနေသော်လည်း encrypt လုပ်ထားသော WeaveNet သည် encrypt လုပ်ထားသော Cilium ထက် 40% ထက်သာလွန်သည်။

SCP ဖြင့် SSH encryption မည်မျှကုန်ကျသည်ကို ကျွန်ုပ်တို့ချက်ချင်းမြင်နိုင်သည်။ CNIs အားလုံးနီးပါးသည် ကောင်းမွန်သော်လည်း WeaveNet သည် နောက်ကျန်နေပြန်သည်။ စာဝှက်စနစ်ပါရှိသော Cilium နှင့် WeaveNet တို့သည် နှစ်ထပ်ကုဒ်ဝှက်စနစ် (SSH + CNI) ကြောင့် အဆိုးဆုံးဟု မျှော်လင့်ရသည်။

ဤသည်မှာ ရလဒ်များနှင့်အတူ အကျဉ်းချုပ်ဇယားဖြစ်သည်

သယံဇာတ သုံးစွဲမှု

ယခု CNI သည် ကြီးမားသောဝန်ထုပ်ဝန်ပိုးများအောက်တွင် အရင်းအမြစ်များကို မည်ကဲ့သို့သုံးစွဲသည် (TCP လွှဲပြောင်းမှုအတွင်း၊ 10 Gbps) ကို နှိုင်းယှဉ်ကြည့်ကြပါစို့။ စွမ်းဆောင်ရည်စမ်းသပ်မှုများတွင် ကျွန်ုပ်တို့သည် CNI ကို သတ္တုအလွတ် (အစိမ်းရောင်လိုင်း) နှင့် နှိုင်းယှဉ်ပါသည်။ အရင်းအမြစ်သုံးစွဲမှုအတွက်၊ CNI မပါဘဲ သန့်စင်သော Kubernetes (ခရမ်းရောင်လိုင်း) ကိုပြသပြီး အပိုအရင်းအမြစ် CNI မည်မျှသုံးစွဲသည်ကို ကြည့်ကြပါစို့။

Memory နဲ့ စလိုက်ရအောင်။ ဤသည်မှာ လွှဲပြောင်းစဉ် MB ရှိ node များ၏ RAM (buffers နှင့် cache များ အပါအဝင်) အတွက် ပျမ်းမျှတန်ဖိုးဖြစ်သည်။

မှတ်ဉာဏ်သုံးစွဲမှု

Flannel နှင့် Kube-router သည် ကောင်းမွန်သောရလဒ်များကိုပြသခဲ့သည် - 50 MB သာရှိသည်။ Calico နှင့် Canal တစ်ခုစီတွင် 70 ရှိသည်။ WeaveNet သည် အခြားသူများထက် 130 MB ပိုများပြီး Cilium သည် 400 အထိ အသုံးပြုသည်။
အခု CPU အချိန်သုံးစွဲမှုကို စစ်ဆေးကြည့်ရအောင်။ မှတ်သားဖွယ်ပုံကြမ်းတွင် ရာခိုင်နှုန်းများကို မပြသော်လည်း ppm ဆိုသည်မှာ "သံဗလာ" အတွက် 38 ppm သည် 3,8% ဖြစ်သည်။ ဤသည်မှာ ရလဒ်များဖြစ်သည်-

CPU သုံးစွဲမှု

Calico၊ Canal၊ Flannel နှင့် Kube-router တို့သည် CNI မပါဘဲ Kubernetes ထက် 2% သာလွန်သော CPU ထိရောက်သည်။ WeaveNet သည် အပို 5% နှင့်နောက်တွင် Cilium 7% ဖြင့် နောက်ကျကျန်နေပါသည်။

ဤသည်မှာ အရင်းအမြစ် သုံးစွဲမှု၏ အကျဉ်းချုပ် ဖြစ်ပါသည်။

ရလဒ်များကို

ရလဒ်အားလုံးပါသော ဇယား-

ယေဘုယျစံနှုန်းရလဒ်များ

ကောက်ချက်

နောက်ဆုံးအပိုင်းမှာ ရလဒ်အပေါ် ကျွန်တော့်ရဲ့ ပုဂ္ဂလအမြင်ကို ဖော်ပြပါမယ်။ ဤစံနှုန်းသည် အလွန်သေးငယ်သော အစုအဝေး (3 nodes) ပေါ်တွင် ချိတ်ဆက်မှုတစ်ခု၏ ဖြတ်သန်းမှုကိုသာ စမ်းသပ်ကြောင်း သတိရပါ။ ၎င်းသည် ကြီးမားသော အစုအဝေးများ (<50 nodes) သို့မဟုတ် အပြိုင်ချိတ်ဆက်မှုများနှင့် မသက်ဆိုင်ပါ။

အခြေအနေပေါ်မူတည်၍ အောက်ပါ CNI များကို အသုံးပြုရန် အကြံပြုလိုပါသည်-

• သင့်အစုအဝေးတွင် ရှိပါသလား။ အရင်းအမြစ်အနည်းငယ်ရှိသော node များ (RAM အများအပြား GB၊ core အများအပြား) နှင့်သင်လုံခြုံရေးအင်္ဂါရပ်များမလိုအပ်ပါ - ရွေးချယ်ပါ။ Flannel. ၎င်းသည် ကုန်ကျစရိတ်အသက်သာဆုံး CNI များထဲမှ တစ်ခုဖြစ်သည်။ ၎င်းသည် ဗိသုကာလက်ရာမြောက်များစွာ (amd64၊ လက်မောင်း၊ arm64 စသည်ဖြင့်) နှင့် တွဲဖက်အသုံးပြုနိုင်ပါသည်။ ထို့အပြင်၊ ၎င်းသည် MTU ကိုအလိုအလျောက်ဆုံးဖြတ်နိုင်သော CNI နှစ်ခုအနက်မှတစ်ခုဖြစ်သည် (အခြားတစ်ခုသည် Cilium) ဖြစ်သည်၊ ထို့ကြောင့်သင်ဘာမှ configure လုပ်ရန်မလိုအပ်ပါ။ Kube-router သည် သင့်လျော်သော်လည်း ၎င်းသည် စံနှုန်းအတိုင်းမဟုတ်သောကြောင့် MTU ကို ကိုယ်တိုင် configure လုပ်ရန် လိုအပ်ပါသည်။
• လိုအပ်လျှင် ကွန်ရက်ကို စာဝှက်ပါ။ လုံခြုံရေးအတွက်၊ ယူပါ။ WeaveNet. သင်သည် jumbo frames များကိုအသုံးပြုနေပါက MTU အရွယ်အစားကို သတ်မှတ်ရန် မမေ့ပါနှင့်၊ ပတ်၀န်းကျင် ပြောင်းလဲမှုတစ်ခုမှတစ်ဆင့် စကားဝှက်ကို သတ်မှတ်ခြင်းဖြင့် ကုဒ်ဝှက်ခြင်းကို ဖွင့်ပါ။ ဒါပေမယ့် စွမ်းဆောင်ရည်ကို မေ့သွားတာက ပိုကောင်းပါတယ် - အဲဒါက ကုဒ်ဝှက်ခြင်းရဲ့ ကုန်ကျစရိတ်ပါ။
• အတွက် ပုံမှန်အသုံးပြုမှု ငါအကြံပေး Calico. ဤ CNI ကို Kubernetes ဖြန့်ကျက်ရေးကိရိယာအမျိုးမျိုး (Kops၊ Kubespray၊ Rancher စသည်ဖြင့်) တွင်တွင်ကျယ်စွာအသုံးပြုပါသည်။ WeaveNet ကဲ့သို့ပင် jumbo frames ကိုအသုံးပြုပါက ConfigMap တွင် MTU ကို configure လုပ်ရန်သေချာပါစေ။ ၎င်းသည် အရင်းအမြစ်သုံးစွဲမှု၊ စွမ်းဆောင်ရည်နှင့် လုံခြုံရေးအတွက် ထိရောက်မှုရှိသော ဘက်စုံသုံးကိရိယာတစ်ခုဖြစ်သည်။

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

CNI ရွေးချယ်မှုအတွက် Visual Diagram

source: www.habr.com