Kubernetes pod သည် IP လိပ်စာကို မည်သို့ရရှိသနည်း။

မှတ်ချက်။ ဘာသာပြန်− LinkedIn မှ SRE အင်ဂျင်နီယာတစ်ဦးမှ ရေးသားထားသော ဤဆောင်းပါးသည် Kubernetes ရှိ အတွင်းမှော်ပညာအကြောင်း အသေးစိတ်ဖော်ပြထားသည် - ပိုမိုတိကျစွာ၊ CRI၊ CNI နှင့် kube-apiserver တို့၏ အပြန်အလှန်ဆက်သွယ်မှု - နောက် pod ကို IP လိပ်စာတစ်ခုသတ်မှတ်ပေးရန်လိုအပ်သောအခါတွင် ဖြစ်ပေါ်လာသည်။

အခြေခံလိုအပ်ချက်များထဲမှ တစ်ခုဖြစ်သည်။ Kubernetes ကွန်ရက် မော်ဒယ် pod တစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင် IP လိပ်စာရှိရမည်ဖြစ်ပြီး၊ အစုအဝေးရှိ အခြား pod တစ်ခုခုသည် ထိုလိပ်စာတွင် ၎င်းကို ဆက်သွယ်နိုင်ရမည်ဖြစ်သည်။ ဤကွန်ရက်နမူနာကို အကောင်အထည်ဖေါ်ရာတွင် ကူညီပေးသော ကွန်ရက် “ပံ့ပိုးပေးသူ” (Flannel၊ Calico၊ Canal စသည်) များစွာရှိသည်။

Kubernetes နှင့် စတင်အလုပ်လုပ်စဉ်က pods များသည် ၎င်းတို့၏ IP လိပ်စာများကို အတိအကျမည်ကဲ့သို့ရရှိသည်ကို ကျွန်ုပ်အတွက် လုံး၀ရှင်းလင်းစွာမသိရပါ။ အစိတ်အပိုင်းတစ်ခုချင်းစီ၏ လုပ်ဆောင်ပုံကို နားလည်ထားသော်လည်း ၎င်းတို့ကို အတူတကွ လုပ်ဆောင်ရန် စိတ်ကူးရခက်ပါသည်။ ဥပမာအားဖြင့်၊ CNI ပလပ်အင်များသည် ဘာအတွက်ဖြစ်သည်ကို ကျွန်ုပ်သိသည်၊ သို့သော် ၎င်းတို့ကို မည်ကဲ့သို့ခေါ်ဆိုသည်ကို အတိအကျမသိပါ။ ထို့ကြောင့်၊ အမျိုးမျိုးသော ကွန်ရက်အစိတ်အပိုင်းများအကြောင်း အသိပညာမျှဝေရန်နှင့် pod တစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင် IP လိပ်စာကို ရရှိစေသည့် Kubernetes အစုအဝေးတစ်ခုတွင် ၎င်းတို့ အတူတကွလုပ်ဆောင်ပုံကို မျှဝေရန် ဤဆောင်းပါးကို ရေးသားရန် ဆုံးဖြတ်ခဲ့သည်။

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

အခြေခံသဘောတရားအချို့

ကွန်တိန်နာများနှင့် ကွန်ရက်- အကျဉ်းချုပ် သုံးသပ်ချက်

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

အိမ်ရှင်တစ်ဦးတွင် ကွန်တိန်နာများ

တူညီသောအိမ်ရှင်ပေါ်တွင်လည်ပတ်နေသောကွန်တိန်နာများကြား IP လိပ်စာများမှတဆင့်ဆက်သွယ်ရေးကိုစုစည်းရန်နည်းလမ်းတစ်ခုမှာ Linux တံတားတစ်ခုဖန်တီးခြင်းပါဝင်သည်။ ဤရည်ရွယ်ချက်အတွက်၊ စက်ပစ္စည်းများကို Kubernetes (နှင့် Docker) တွင် ဖန်တီးထားသည်။ veth (virtual Ethernet). veth စက်ပစ္စည်း၏ အဆုံးတစ်ခုသည် ကွန်တိန်နာ၏ ကွန်ရက် namespace သို့ ချိတ်ဆက်ပြီး၊ ကျန်တစ်ခုသည် Linux တံတား host network ပေါ်မှာ။

တူညီသောအိမ်ရှင်ရှိ ကွန်တိန်နာအားလုံးတွင် IP လိပ်စာများမှတစ်ဆင့် အချင်းချင်း ဆက်သွယ်နိုင်သည့် တံတားတစ်ခုနှင့် ချိတ်ဆက်ထားသည့် veth အဆုံးတစ်ခုရှိသည်။ Linux တံတားတွင် IP လိပ်စာလည်းရှိပြီး အခြား node များအတွက် ရည်ရွယ်ထားသော pods များမှ egress traffic အတွက် gateway တစ်ခုအနေဖြင့် လုပ်ဆောင်သည်။

မတူညီသောအိမ်ရှင်များတွင် ကွန်တိန်နာများ

Packet encapsulation သည် IP လိပ်စာများကို အသုံးပြု၍ မတူညီသော node များရှိ container များအချင်းချင်း ဆက်သွယ်နိုင်စေမည့် နည်းလမ်းတစ်ခုဖြစ်သည်။ Flannel တွင်၊ နည်းပညာသည် ဤအခွင့်အရေးအတွက် တာဝန်ရှိသည်။ vxlanမူရင်းပက်ကေ့ချ်ကို UDP ပက်ကေ့ခ်ျတစ်ခုသို့ “ပက်ကေ့ချ်များ” လုပ်ပြီး ၎င်း၏ဦးတည်ရာသို့ ပို့ပေးသည်။

Kubernetes အစုအဝေးတစ်ခုတွင်၊ Flannel သည် vxlan စက်တစ်ခုကို ဖန်တီးပြီး node တစ်ခုစီရှိ လမ်းကြောင်းဇယားကို အပ်ဒိတ်လုပ်သည်။ မတူညီသော host တစ်ခုပေါ်ရှိ ကွန်တိန်နာတစ်ခုအတွက် သတ်မှတ်ထားသော ပက်ကတ်တစ်ခုစီသည် vxlan စက်ပစ္စည်းကို ဖြတ်သန်းသွားကာ UDP ပက်ကတ်တွင် ဖုံးအုပ်ထားသည်။ ဦးတည်ရာတွင်၊ nested packet ကို ထုတ်ယူပြီး လိုချင်သော pod သို့ ထပ်ဆင့်ပို့သည်။

မှတ်ချက်- ဤသည်မှာ ကွန်တိန်နာများကြားတွင် ကွန်ရက်ဆက်သွယ်မှုကို စုစည်းရန် နည်းလမ်းတစ်ခုသာဖြစ်သည်။

CRI ဆိုတာဘာလဲ။

CRI (Container Runtime Interface) kubelet သည် မတူညီသော container runtime ပတ်ဝန်းကျင်များကို အသုံးပြုရန် ခွင့်ပြုသည့် plugin တစ်ခုဖြစ်သည်။ CRI API ကို အမျိုးမျိုးသော runtime များတွင်တည်ဆောက်ထားသောကြောင့် အသုံးပြုသူများသည် မိမိတို့နှစ်သက်ရာ runtime ကိုရွေးချယ်နိုင်သည်။

CNI ဆိုတာဘာလဲ။

ပရောဂျက် CNI ဒါဟာကိုယ်စားပြုတယ် သတ်မှတ်ချက် Linux containers အတွက် universal network solution တစ်ခုကို စုစည်းရန်။ ထို့အပြင် ၎င်းတွင် ပါဝင်သည်။ ပလပ်အင်များpod network တစ်ခုတည်ဆောက်ရာတွင် အမျိုးမျိုးသောလုပ်ဆောင်ချက်များအတွက် တာဝန်ရှိသည်။ CNI ပလပ်အင်သည် သတ်မှတ်ချက်များနှင့်အညီ လုပ်ဆောင်နိုင်သော ဖိုင်တစ်ခုဖြစ်သည် (ကျွန်ုပ်တို့ အောက်တွင် အချို့သော ပလပ်အင်များကို ဆွေးနွေးပါမည်)။

pods များသို့ IP လိပ်စာများသတ်မှတ်ခြင်းအတွက် subnets များခွဲဝေခြင်း။

အစုအဝေးတစ်ခုစီရှိ pod တစ်ခုစီတွင် IP လိပ်စာတစ်ခုရှိရမည်ဖြစ်သောကြောင့် ဤလိပ်စာသည် တစ်မူထူးခြားကြောင်း သေချာစေရန် အရေးကြီးသည်။ ၎င်းသည် node တစ်ခုစီကို သီးခြားခွဲနက်တစ်ခုအဖြစ် သတ်မှတ်ပေးခြင်းဖြင့် ၎င်းကို ရရှိပြီး ၎င်းသည် အဆိုပါ node ပေါ်ရှိ pods များကို IP လိပ်စာများအဖြစ် သတ်မှတ်ပေးခြင်းဖြင့် အောင်မြင်သည်။

Node IPAM Controller

ရသောအခါ nodeipam အလံဘောင်တစ်ခုအဖြစ် ကျော်သွားခဲ့သည်။ --controllers kube-controller-မန်နေဂျာ၊ ၎င်းသည် သီးခြားခွဲကွန်ရက် (podCIDR) ကို အစုအစည်း CIDR မှ node တစ်ခုစီသို့ ခွဲဝေပေးသည် (ဆိုလိုသည်မှာ အစုအဝေးကွန်ရက်အတွက် IP လိပ်စာများ၏ အကွာအဝေး)။ ဤ podCIDR များသည် ထပ်မထပ်သောကြောင့်၊ pod တစ်ခုစီအတွက် သီးခြား IP လိပ်စာကို ခွဲဝေပေးရန် ဖြစ်နိုင်သည်။

အစုအဝေးတွင် ကနဦးမှတ်ပုံတင်သည့်အခါ Kubernetes node ကို podCIDR တစ်ခု သတ်မှတ်ပေးသည်။ node များ၏ podCIDR ကိုပြောင်းလဲရန်၊ ၎င်းတို့ကို မှတ်ပုံတင်ရန် လိုအပ်ပြီး ၎င်းတို့ကို ပြန်လည်မှတ်ပုံတင်ရန် လိုအပ်ပြီး ၎င်းတို့အကြားရှိ Kubernetes ထိန်းချုပ်မှု အလွှာဖွဲ့စည်းပုံအတွက် သင့်လျော်သောပြောင်းလဲမှုများ ပြုလုပ်ပါ။ အောက်ပါ command ကို အသုံးပြု၍ node တစ်ခု၏ podCIDR ကို သင်ပြသနိုင်သည်-

$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24

Kubelet၊ container runtime နှင့် CNI plugins- အားလုံးအလုပ်လုပ်ပုံ

node တစ်ခုစီအတွက် pod တစ်ခုကို စီစဉ်ရာတွင် ကြိုတင်ပြင်ဆင်မှု အဆင့်များစွာ ပါဝင်ပါသည်။ ဤကဏ္ဍတွင်၊ ကျွန်ုပ်သည် pod network တစ်ခုတည်ဆောက်ခြင်းနှင့် တိုက်ရိုက်သက်ဆိုင်သည့်အရာများကိုသာ အာရုံစိုက်ပါမည်။

pod တစ်ခုအား အချို့သော node တစ်ခုသို့ အချိန်ဇယားဆွဲခြင်းသည် အောက်ပါဖြစ်ရပ်များ၏ ကွင်းဆက်ကို အစပျိုးစေသည်-

မေးလေ့ရှိသောမေးခွန်းများ: Containerd CRI ပလပ်အင်များ၏ဗိသုကာ.

ကွန်တိန်နာ runtime နှင့် CNI ပလပ်အင်များအကြား အပြန်အလှန်အကျိုးသက်ရောက်မှု

ကွန်ရက်ပံ့ပိုးပေးသူတိုင်းတွင် ၎င်း၏ကိုယ်ပိုင် CNI ပလပ်အင်ပါရှိသည်။ စတင်ချိန်တွင် ကွန်တိန်နာ၏ runtime သည် pod အတွက် network ကို configure ပြုလုပ်ရန် ၎င်းကို run သည်။ containerd တွင်၊ CNI plugin ကို plugin မှစတင်သည်။ CRI ကွန်တိန်နာ.

ထို့အပြင်၊ ဝန်ဆောင်မှုပေးသူတိုင်းတွင် ၎င်း၏ကိုယ်ပိုင်အေးဂျင့်ရှိသည်။ ၎င်းကို Kubernetes node များအားလုံးတွင် ထည့်သွင်းထားပြီး pods များ၏ ကွန်ရက်ဖွဲ့စည်းပုံအတွက် တာဝန်ရှိသည်။ ဤအေးဂျင့်သည် CNI config တွင် ပါဝင်သည် သို့မဟုတ် ၎င်းကို node တွင် လွတ်လပ်စွာ ဖန်တီးသည်။ config သည် CNI ပလပ်အင်ကိုခေါ်ဆိုရန်သတ်မှတ်ထားသည့် CRI ပလပ်အင်ကိုကူညီပေးသည်။

CNI config ၏တည်နေရာကိုစိတ်ကြိုက်ပြင်ဆင်နိုင်သည်။ ပုံမှန်အားဖြင့် ၎င်းသည် တွင်ရှိသည်။ /etc/cni/net.d/<config-file>. Cluster စီမံခန့်ခွဲသူများသည် အစုအဝေးတစ်ခုစီတွင် CNI ပလပ်အင်များကို ထည့်သွင်းရန်အတွက်လည်း တာဝန်ရှိပါသည်။ ၎င်းတို့၏တည်နေရာကိုလည်း စိတ်ကြိုက်ပြင်ဆင်နိုင်သည်။ မူရင်းလမ်းညွှန် - /opt/cni/bin.

containerd ကိုအသုံးပြုသောအခါ၊ plugin config နှင့် binaries အတွက်လမ်းကြောင်းများကိုအပိုင်းတွင်သတ်မှတ်နိုင်သည်။ [plugins.«io.containerd.grpc.v1.cri».cni] в containerd configuration ဖိုင်.

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကွန်ရက်ပံ့ပိုးပေးသူအဖြစ် Flannel ကိုအသုံးပြုနေသောကြောင့်၊ ၎င်းကိုစတင်သတ်မှတ်ခြင်းအကြောင်း အနည်းငယ်ပြောဆိုကြပါစို့။

• Flannel (Flannel's daemon) ကို DaemonSet အဖြစ် အစုအဝေးတစ်ခုတွင် ထည့်သွင်းလေ့ရှိသည်။ install-cni အဖြစ် init container.
• Install-cni ဖန်တီးသည် CNI ဖွဲ့စည်းမှုဖိုင် (/etc/cni/net.d/10-flannel.conflistnode တစ်ခုစီတွင်)
• Flanneld သည် vxlan စက်ပစ္စည်းကို ဖန်တီးကာ API ဆာဗာမှ ကွန်ရက်မက်တာဒေတာကို ရယူကာ ပေါ့ဒ်အပ်ဒိတ်များကို စောင့်ကြည့်သည်။ ၎င်းတို့ကို ဖန်တီးလိုက်သည်နှင့်အမျှ၊ ၎င်းသည် အစုအဝေးတစ်လျှောက်ရှိ pods များအားလုံးသို့ လမ်းကြောင်းများကို ဖြန့်ဝေပေးသည်။
• ဤလမ်းကြောင်းများသည် pod များကို IP လိပ်စာများမှတဆင့် အချင်းချင်း ဆက်သွယ်နိုင်စေပါသည်။

Flannel ၏အလုပ်နှင့်ပတ်သက်သောအသေးစိတ်အချက်အလက်များအတွက်၊ ဆောင်းပါး၏အဆုံးတွင် links များကိုအသုံးပြုရန်အကြံပြုပါသည်။

ဤသည်မှာ Containerd CRI ပလပ်အင်နှင့် CNI ပလပ်အင်များအကြား အပြန်အလှန်အကျိုးသက်ရောက်မှု၏ ပုံကြမ်းဖြစ်သည်။

အထက်တွင်တွေ့မြင်ရသည့်အတိုင်း၊ kubelet သည် Pod ၏ကွန်ရက်ကို configure လုပ်ရန် CNI ပလပ်အင်ကိုခေါ်ပြီး pod ကိုဖန်တီးရန် Containerd CRI ပလပ်အင်ကိုခေါ်သည်။ ထိုသို့လုပ်ဆောင်ရာတွင်၊ ကွန်ရက်ပံ့ပိုးပေးသူ၏ CNI ပလပ်အင်သည် ကွန်ရက်၏ ရှုထောင့်အမျိုးမျိုးကို စီစဉ်သတ်မှတ်ရန် အခြား core CNI ပလပ်အင်များကို ခေါ်သည်။

CNI ပလပ်အင်များအကြား အပြန်အလှန်တုံ့ပြန်မှု

host ပေါ်ရှိ containers များကြားတွင် network communication ကို set up လုပ်ရန်မှာ CNI plugin အမျိုးမျိုးရှိသည်။ ဤဆောင်းပါးတွင် ၎င်းတို့သုံးဦးကို ဆွေးနွေးပါမည်။

CNI ပလပ်အင် Flannel

Flannel ကို ကွန်ရက်ပံ့ပိုးပေးသူအဖြစ် အသုံးပြုသောအခါ၊ Containerd CRI အစိတ်အပိုင်းမှ ဖုန်းခေါ်ဆိုသည်။ CNI ပလပ်အင် FlannelCNI configuration ဖိုင်ကို အသုံးပြု /etc/cni/net.d/10-flannel.conflist.

$ cat /etc/cni/net.d/10-flannel.conflist
{
  "name": "cni0",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
         "ipMasq": false,
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    }
  ]
}

Flannel CNI ပလပ်အင်သည် Flanneld နှင့် တွဲဖက်အလုပ်လုပ်သည်။ စတင်စဉ်အတွင်း၊ Flanneld သည် podCIDR နှင့် အခြားကွန်ရက်ဆိုင်ရာအသေးစိတ်အချက်အလက်များကို API ဆာဗာမှ ရယူပြီး ဖိုင်တစ်ခုတွင် သိမ်းဆည်းသည် /run/flannel/subnet.env.

FLANNEL_NETWORK=10.244.0.0/16 
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450 
FLANNEL_IPMASQ=false

Flannel CNI ပလပ်အင်သည် ဒေတာကို အသုံးပြုသည်။ /run/flannel/subnet.env Configure လုပ်ပြီး CNI Bridge plugin ကို ခေါ်ပါ။

CNI ပလပ်အင်တံတား

ဤပလပ်အင်ကို အောက်ပါဖွဲ့စည်းပုံဖြင့် ခေါ်သည်-

{
  "name": "cni0",
  "type": "bridge",
  "mtu": 1450,
  "ipMasq": false,
  "isGateway": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24"
  }
}

ပထမအကြိမ်ခေါ်သောအခါ၊ ၎င်းသည် Linux တံတားကိုဖန်တီးသည်။ «name»: «cni0»config တွင်ဖော်ပြထားသော၊ ထို့နောက် pod တစ်ခုစီအတွက် veth pair တစ်ခုကို ဖန်တီးသည်။ ၎င်း၏ အဆုံးတစ်ဖက်သည် ကွန်တိန်နာ၏ ကွန်ရက်အမည်နေရာနှင့် ချိတ်ဆက်ထားပြီး ကျန်တစ်ဖက်ကို လက်ခံကွန်ရက်ရှိ Linux တံတားတွင် ထည့်သွင်းထားသည်။ CNI ပလပ်အင်တံတား လက်ခံသူကွန်တိန်နာအားလုံးကို host network ရှိ Linux တံတားတစ်ခုသို့ ချိတ်ဆက်သည်။

veth pair ကို စနစ်ထည့်သွင်းခြင်း ပြီးသွားသောအခါ Bridge plugin သည် host-local IPAM CNI plugin ကို ခေါ်သည်။ Flannel CNI ပလပ်အင်ကိုခေါ်ရန် CRI ပလပ်အင်ကအသုံးပြုသော IPAM ပလပ်အင်အမျိုးအစားကို CNI config တွင် configure လုပ်နိုင်ပါသည်။

လက်ခံသူ-ပြည်တွင်း IPAM CNI ပလပ်အင်များ

တံတား CNI ခေါ်ဆိုမှုများ host-local IPAM ပလပ်အင် CNI အောက်ပါဖွဲ့စည်းပုံနှင့်အတူ

{
  "name": "cni0",
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24",
    "dataDir": "/var/lib/cni/networks"
  }
}

လက်ခံသူ-ပြည်တွင်း IPAM ပလပ်အင် (IP Aရက် Mစီမံခန့်ခွဲမှု - IP လိပ်စာစီမံခန့်ခွဲမှု) subnet မှ ကွန်တိန်နာအတွက် IP လိပ်စာကို ပြန်ပေးကာ အပိုင်းရှိ သတ်မှတ်ထားသည့် လမ်းညွှန်တွင် လက်ခံဆောင်ရွက်ပေးသော IP ပေါ်တွင် ခွဲဝေချထားပေးသည် dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. ဤဖိုင်တွင် ဤ IP လိပ်စာကို သတ်မှတ်ပေးထားသည့် ကွန်တိန်နာ ID ပါရှိသည်။

host-local IPAM ပလပ်အင်ကို ခေါ်သောအခါ၊ ၎င်းသည် အောက်ပါဒေတာကို ပြန်ပေးသည်-

{
  "ip4": {
    "ip": "10.244.4.2",
    "gateway": "10.244.4.3"
  },
  "dns": {}
}

အကျဉ်းချုပ်

Kube-controller-manager သည် node တစ်ခုစီတွင် podCIDR တစ်ခုကို သတ်မှတ်ပေးသည်။ node တစ်ခုစီ၏ pods များသည် ခွဲဝေချထားပေးထားသော podCIDR အပိုင်းအခြားရှိ လိပ်စာနေရာမှ IP လိပ်စာများကို လက်ခံရရှိသည် ။ node များ၏ podCIDR များသည် ထပ်မထပ်သောကြောင့်၊ pod များအားလုံးသည် ထူးခြားသော IP လိပ်စာများကို ရရှိကြသည်။

Kubernetes အစုအဝေး စီမံခန့်ခွဲသူသည် kubelet၊ ကွန်တိန်နာဖွင့်ချိန်၊ ကွန်ရက်ပံ့ပိုးပေးသူ အေးဂျင့်ကို စီစဉ်ပြီး ထည့်သွင်းကာ node တစ်ခုစီသို့ CNI ပလပ်အင်များကို ကူးယူသည်။ စတင်ချိန်တွင်၊ ကွန်ရက်ပံ့ပိုးပေးသူ အေးဂျင့်သည် CNI config တစ်ခုကို ထုတ်ပေးသည်။ pod တစ်ခုသည် node တစ်ခုသို့စီစဉ်သောအခါ၊ kubelet သည် ၎င်းကိုဖန်တီးရန် CRI plugin ကိုခေါ်ဆိုသည်။ ထို့နောက်၊ containerd ကိုအသုံးပြုပါက၊ Containerd CRI plugin သည် pod ၏ network ကို configure လုပ်ရန်အတွက် CNI config တွင်သတ်မှတ်ထားသော CNI plugin ကိုခေါ်ဆိုပါသည်။ ရလဒ်အနေဖြင့် pod သည် IP လိပ်စာကိုလက်ခံရရှိသည်။

ဤအရာအားလုံး၏ သိမ်မွေ့မှုနှင့် ကွဲလွဲချက်များကို နားလည်ရန် အချိန်အနည်းငယ်ယူခဲ့ရသည်။ ဤအတွေ့အကြုံသည် Kubernetes အလုပ်လုပ်ပုံကို ပိုမိုနားလည်နိုင်စေရန် ကူညီပေးလိမ့်မည်ဟု မျှော်လင့်ပါသည်။ တစ်ခုခုမှားတာရှိရင် ကျေးဇူးပြုပြီး ကျွန်တော့်ကို ဆက်သွယ်ပေးပါ။ တွစ်တာ သို့မဟုတ် လိပ်စာတွင် [အီးမေးလ်ကိုကာကွယ်ထားသည်]. ဤဆောင်းပါး၏ ကဏ္ဍများ သို့မဟုတ် အခြားအရာများကို ဆွေးနွေးလိုပါက လွတ်လပ်စွာ ဆက်သွယ်နိုင်ပါသည်။ ငါ မင်းနဲ့ စကားပြောချင်တယ်!

ကိုးကား

ကွန်တိန်နာများနှင့်ကွန်ရက်

• ကွန်တိန်နာကွန်ရက် ခြုံငုံသုံးသပ်ချက်
• Demystifying container networking

Flannel ဘယ်လိုအလုပ်လုပ်သလဲ။

• Flannel Networking Demystify
• Flannel ပါရှိသော Kubernetes - ကွန်ရက်ချိတ်ဆက်ခြင်းကို နားလည်ခြင်း။

CRI နှင့် CNI တို့ဖြစ်သည်။

• CRI Plugin ဗိသုကာ
• CNI Spec
• CNI ပလပ်အင်များ

PS ဘာသာပြန်မှ

ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ

• «Kubernetes ရှိ ကွန်ရက်ချိတ်ဆက်မှုအတွက် Calico- မိတ်ဆက်ခြင်းနှင့် အတွေ့အကြုံအနည်းငယ်";
• " Kubernetes တွင် ကွန်ရက်ချိတ်ဆက်ခြင်းဆိုင်ရာ ရုပ်ပြလမ်းညွှန်"- အပိုင်း ၁ နှင့် ၂ (ကွန်ရက်ပုံစံ၊ ထပ်ဆင့်ကွန်ရက်များ), အပိုင်း 3 (ဝန်ဆောင်မှုများနှင့် ယာဉ်အသွားအလာ လုပ်ဆောင်ခြင်း);
• «Container Networking Interface (CNI) - Linux ကွန်တိန်နာများအတွက် ကွန်ရက်ချိတ်ဆက်မှု နှင့် စံနှုန်း"။

source: www.habr.com