តើ Kubernetes pod ទទួលបានអាសយដ្ឋាន IP យ៉ាងដូចម្តេច?

ចំណាំ។ បកប្រែ៖ អត្ថបទនេះសរសេរដោយវិស្វករ SRE មកពី LinkedIn រៀបរាប់លម្អិតអំពីវេទមន្តខាងក្នុងនៅក្នុង Kubernetes - កាន់តែច្បាស់ជាងនេះទៅទៀត អន្តរកម្មរបស់ CRI, CNI និង kube-apiserver - ដែលកើតឡើងនៅពេលដែល pod បន្ទាប់ត្រូវការផ្តល់អាសយដ្ឋាន IP ។

មួយនៃតម្រូវការមូលដ្ឋាន ម៉ូដែលបណ្តាញ Kubernetes គឺថាផតនីមួយៗត្រូវតែមានអាសយដ្ឋាន IP ផ្ទាល់ខ្លួន ហើយផតផ្សេងទៀតនៅក្នុងចង្កោមត្រូវតែអាចទាក់ទងវាបានតាមអាសយដ្ឋាននោះ។ មានបណ្តាញ "អ្នកផ្តល់សេវា" ជាច្រើន (Flannel, Calico, Canal ។ល។) ដែលជួយអនុវត្តគំរូបណ្តាញនេះ។

នៅពេលខ្ញុំចាប់ផ្តើមធ្វើការជាមួយ Kubernetes ជាលើកដំបូង វាមិនច្បាស់សម្រាប់ខ្ញុំថាតើ pods ទទួលបានអាសយដ្ឋាន IP របស់ពួកគេយ៉ាងដូចម្តេចនោះទេ។ ទោះបីជាមានការយល់ដឹងអំពីរបៀបដែលសមាសធាតុនីមួយៗដំណើរការក៏ដោយ វាពិបាកក្នុងការស្រមៃថាពួកវាធ្វើការជាមួយគ្នា។ ជាឧទាហរណ៍ ខ្ញុំបានដឹងថាកម្មវិធីជំនួយ CNI សម្រាប់អ្វី ប៉ុន្តែខ្ញុំមិនដឹងថាតើពួកវាត្រូវបានហៅយ៉ាងដូចម្ដេចនោះទេ។ ដូច្នេះហើយ ខ្ញុំបានសម្រេចចិត្តសរសេរអត្ថបទនេះ ដើម្បីចែករំលែកចំណេះដឹងអំពីសមាសធាតុបណ្តាញផ្សេងៗ និងរបៀបដែលពួកវាធ្វើការជាមួយគ្នានៅក្នុងចង្កោម Kubernetes ដែលអនុញ្ញាតឱ្យផតនីមួយៗទទួលបានអាសយដ្ឋាន IP ផ្ទាល់ខ្លួនរបស់វា។

មានវិធីផ្សេងគ្នាក្នុងការរៀបចំបណ្តាញនៅក្នុង Kubernetes ដូចជាមានជម្រើសពេលដំណើរការផ្សេងគ្នាសម្រាប់កុងតឺន័រ។ ការបោះពុម្ពនេះនឹងប្រើប្រាស់ Flannel ដើម្បីរៀបចំបណ្តាញនៅក្នុងចង្កោមមួយ និងជាបរិយាកាសដែលអាចប្រតិបត្តិបាន - កុងតឺន័រ. ខ្ញុំក៏កំពុងធ្វើការសន្មត់ថាអ្នកដឹងពីរបៀបដែលបណ្តាញរវាងកុងតឺន័រដំណើរការ ដូច្នេះខ្ញុំនឹងប៉ះវាដោយសង្ខេប គ្រាន់តែសម្រាប់បរិបទប៉ុណ្ណោះ។

គំនិតជាមូលដ្ឋានមួយចំនួន

កុងតឺន័រ និងបណ្តាញ៖ ទិដ្ឋភាពសង្ខេប

មានការបោះពុម្ពផ្សាយល្អៗជាច្រើននៅលើអ៊ីនធឺណិត ដែលពន្យល់ពីរបៀបដែលកុងតឺន័រទាក់ទងគ្នាទៅវិញទៅមកតាមបណ្តាញ។ ដូច្នេះហើយ ខ្ញុំនឹងផ្តល់តែទិដ្ឋភាពទូទៅនៃគោលគំនិតជាមូលដ្ឋាន ហើយដាក់កម្រិតខ្លួនខ្ញុំចំពោះវិធីសាស្រ្តមួយ ដែលពាក់ព័ន្ធនឹងការបង្កើតស្ពានលីនុច និងកញ្ចប់កញ្ចប់។ ព័ត៌មានលម្អិតត្រូវបានលុបចោល ដោយសារប្រធានបទនៃបណ្តាញកុងតឺន័រខ្លួនវាសមនឹងទទួលបានអត្ថបទដាច់ដោយឡែកមួយ។ តំណភ្ជាប់ទៅកាន់ការបោះពុម្ពផ្សាយប្រកបដោយការយល់ដឹង និងអប់រំមួយចំនួននឹងត្រូវបានផ្តល់ជូនខាងក្រោម។

ធុងនៅលើម៉ាស៊ីនតែមួយ

វិធីមួយដើម្បីរៀបចំទំនាក់ទំនងតាមរយៈអាសយដ្ឋាន IP រវាងកុងតឺន័រដែលដំណើរការលើម៉ាស៊ីនតែមួយពាក់ព័ន្ធនឹងការបង្កើតស្ពានលីនុច។ ចំពោះគោលបំណងនេះ ឧបករណ៍និម្មិតត្រូវបានបង្កើតនៅក្នុង Kubernetes (និង Docker) វ៉េត (អ៊ីសឺរណិតនិម្មិត). ចុងម្ខាងនៃឧបករណ៍ veth ភ្ជាប់ទៅបណ្តាញ namespace របស់កុងតឺន័រ ហើយមួយទៀតទៅ ស្ពានលីនុច នៅលើបណ្តាញម៉ាស៊ីន។

កុងតឺន័រទាំងអស់នៅលើម៉ាស៊ីនតែមួយមានចុងម្ខាងនៃ veth ភ្ជាប់ទៅនឹងស្ពានដែលពួកគេអាចទំនាក់ទំនងគ្នាទៅវិញទៅមកតាមរយៈអាសយដ្ឋាន IP ។ ស្ពានលីនុចក៏មានអាសយដ្ឋាន IP និងដើរតួនាទីជាច្រកផ្លូវសម្រាប់ចរាចរចេញពីផតដែលកំណត់សម្រាប់ថ្នាំងផ្សេងទៀត។

ធុងនៅលើម៉ាស៊ីនផ្សេងគ្នា

Packet encapsulation គឺជាវិធីសាស្រ្តមួយដែលអនុញ្ញាតឱ្យកុងតឺន័រនៅលើថ្នាំងផ្សេងៗគ្នាទំនាក់ទំនងគ្នាទៅវិញទៅមកដោយប្រើអាសយដ្ឋាន IP ។ នៅ Flannel បច្ចេកវិទ្យាទទួលខុសត្រូវចំពោះឱកាសនេះ។ vxlanដែល "កញ្ចប់" កញ្ចប់ដើមចូលទៅក្នុងកញ្ចប់ UDP ហើយបន្ទាប់មកផ្ញើវាទៅគោលដៅរបស់វា។

នៅក្នុងចង្កោម Kubernetes Flannel បង្កើតឧបករណ៍ vxlan និងធ្វើបច្ចុប្បន្នភាពតារាងផ្លូវនៅលើថ្នាំងនីមួយៗស្របតាម។ កញ្ចប់នីមួយៗដែលកំណត់សម្រាប់កុងតឺន័រនៅលើម៉ាស៊ីនផ្សេងគ្នាឆ្លងកាត់ឧបករណ៍ vxlan ហើយត្រូវបានរុំព័ទ្ធក្នុងកញ្ចប់ UDP ។ នៅ​គោលដៅ កញ្ចប់​ដែល​មាន​សំបុក​ត្រូវ​បាន​ស្រង់​ចេញ និង​បញ្ជូន​បន្ត​ទៅ​កាន់​ផត​ដែល​ចង់​បាន។

ចំណាំ៖ នេះគ្រាន់តែជាវិធីមួយក្នុងការរៀបចំទំនាក់ទំនងបណ្តាញរវាងកុងតឺន័រប៉ុណ្ណោះ។

តើ CRI ជាអ្វី?

CRI (ចំណុចប្រទាក់ពេលដំណើរការកុងតឺន័រ) គឺជាកម្មវិធីជំនួយដែលអនុញ្ញាតឱ្យ kubelet ប្រើបរិស្ថានពេលដំណើរការកុងតឺន័រផ្សេងៗគ្នា។ CRI API ត្រូវ​បាន​បង្កើត​ឡើង​ក្នុង​ពេល​រត់​ផ្សេងៗ ដូច្នេះ​អ្នក​ប្រើ​អាច​ជ្រើសរើស​ម៉ោង​រត់​តាម​ជម្រើស​របស់​ពួកគេ។

តើ CNI ជាអ្វី?

គម្រោង CNI គឺជា ការបញ្ជាក់ ដើម្បីរៀបចំដំណោះស្រាយបណ្តាញសកលសម្រាប់ធុងលីនុច។ លើសពីនេះទៀតវារួមបញ្ចូល កម្មវិធីជំនួយទទួលខុសត្រូវចំពោះមុខងារផ្សេងៗនៅពេលរៀបចំបណ្តាញផត។ កម្មវិធីជំនួយ CNI គឺជាឯកសារដែលអាចប្រតិបត្តិបានដែលស្របតាមការបញ្ជាក់ (យើងនឹងពិភាក្សាអំពីកម្មវិធីជំនួយមួយចំនួនខាងក្រោម)។

ការបែងចែកបណ្តាញរងទៅថ្នាំងសម្រាប់កំណត់អាសយដ្ឋាន IP ទៅកាន់ផត

ដោយសារផតនីមួយៗនៅក្នុងចង្កោមត្រូវតែមានអាសយដ្ឋាន IP វាជាការសំខាន់ណាស់ក្នុងការធានាថាអាសយដ្ឋាននេះមានតែមួយ។ នេះត្រូវបានសម្រេចដោយការផ្ដល់ឱ្យ node នីមួយៗនូវ subnet តែមួយគត់ ដែល pods នៅលើ node នោះត្រូវបានផ្តល់អាសយដ្ឋាន IP ។

ឧបករណ៍បញ្ជា Node IPAM

នៅពេល nodeipam បានឆ្លងកាត់ជាប៉ារ៉ាម៉ែត្រទង់ --controllers kube-controller-managerវាបែងចែកបណ្តាញរងដាច់ដោយឡែក (podCIDR) ទៅកាន់ថ្នាំងនីមួយៗពីចង្កោម CIDR (ឧ. ជួរនៃអាសយដ្ឋាន IP សម្រាប់បណ្តាញចង្កោម)។ ដោយសារ podCIDRs ទាំងនេះមិនត្រួតលើគ្នា វាអាចទៅរួចសម្រាប់ផតនីមួយៗត្រូវបានបែងចែកអាសយដ្ឋាន IP តែមួយគត់។

ថ្នាំង Kubernetes ត្រូវបានផ្តល់ podCIDR នៅពេលដែលវាត្រូវបានចុះឈ្មោះដំបូងជាមួយចង្កោម។ ដើម្បីផ្លាស់ប្តូរ podCIDR នៃថ្នាំង អ្នកត្រូវលុបឈ្មោះពួកវា ហើយបន្ទាប់មកចុះឈ្មោះវាឡើងវិញ ដោយធ្វើការផ្លាស់ប្តូរសមស្របទៅនឹងការកំណត់រចនាសម្ព័ន្ធស្រទាប់គ្រប់គ្រង Kubernetes នៅចន្លោះ។ អ្នកអាចបង្ហាញ podCIDR នៃ node ដោយប្រើពាក្យបញ្ជាខាងក្រោម៖

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

Kubelet, container runtime និងកម្មវិធីជំនួយ CNI៖ របៀបដែលវាដំណើរការទាំងអស់។

ការកំណត់កាលវិភាគ pod ក្នុងមួយ node ពាក់ព័ន្ធនឹងជំហានរៀបចំជាច្រើន។ នៅក្នុងផ្នែកនេះ ខ្ញុំនឹងផ្តោតតែលើផ្នែកដែលទាក់ទងដោយផ្ទាល់ទៅនឹងការដំឡើងបណ្តាញ pod ប៉ុណ្ណោះ។

ការ​កំណត់​ពេល​វេលា​មួយ​ទៅ​ថ្នាំង​ជាក់លាក់​មួយ​បង្ក​ឱ្យ​មាន​សង្វាក់​នៃ​ព្រឹត្តិការណ៍​ដូច​ខាង​ក្រោម៖

ជំនួយ: ស្ថាបត្យកម្មនៃកម្មវិធីជំនួយ CRI កុងតឺន័រ.

អន្តរកម្មរវាងកុងតឺន័រដំណើរការ និងកម្មវិធីជំនួយ CNI

អ្នកផ្តល់បណ្តាញនីមួយៗមានកម្មវិធីជំនួយ CNI ផ្ទាល់ខ្លួន។ រយៈពេលដំណើរការរបស់កុងតឺន័រដំណើរការវាដើម្បីកំណត់រចនាសម្ព័ន្ធបណ្តាញសម្រាប់ផតនៅពេលវាចាប់ផ្តើម។ ក្នុងករណីកុងតឺន័រ កម្មវិធីជំនួយ CNI ត្រូវបានបើកដំណើរការដោយកម្មវិធីជំនួយ កុងតឺន័រ CRI.

លើសពីនេះទៅទៀត អ្នកផ្តល់សេវានីមួយៗមានភ្នាក់ងារផ្ទាល់ខ្លួន។ វាត្រូវបានដំឡើងនៅលើថ្នាំង Kubernetes ទាំងអស់ ហើយទទួលខុសត្រូវចំពោះការកំណត់រចនាសម្ព័ន្ធបណ្តាញរបស់ផត។ ភ្នាក់ងារនេះត្រូវបានរួមបញ្ចូលជាមួយការកំណត់រចនាសម្ព័ន្ធ CNI ឬបង្កើតវាដោយឯករាជ្យនៅលើថ្នាំង។ ការកំណត់រចនាសម្ព័ន្ធជួយកម្មវិធីជំនួយ CRI កំណត់កម្មវិធីជំនួយ CNI ដែលត្រូវហៅ។

ទីតាំងនៃការកំណត់រចនាសម្ព័ន្ធ CNI អាចត្រូវបានប្ដូរតាមបំណង។ តាមលំនាំដើមវាស្ថិតនៅក្នុង /etc/cni/net.d/<config-file>. អ្នកគ្រប់គ្រងចង្កោមក៏ទទួលខុសត្រូវក្នុងការដំឡើងកម្មវិធីជំនួយ CNI នៅលើថ្នាំងចង្កោមនីមួយៗផងដែរ។ ទីតាំងរបស់ពួកគេក៏អាចប្ដូរតាមបំណងបានផងដែរ។ ថត​លំនាំដើម - /opt/cni/bin.

នៅពេលប្រើកុងតឺន័រ ផ្លូវសម្រាប់ការកំណត់រចនាសម្ព័ន្ធកម្មវិធីជំនួយ និងប្រព័ន្ធគោលពីរអាចត្រូវបានកំណត់នៅក្នុងផ្នែក [plugins.«io.containerd.grpc.v1.cri».cni] в ឯកសារកំណត់រចនាសម្ព័ន្ធធុង.

ដោយសារយើងកំពុងប្រើ Flannel ជាអ្នកផ្តល់បណ្តាញរបស់យើង សូមនិយាយបន្តិចអំពីការដំឡើងវា៖

• Flanneld (ដេមិនរបស់ Flannel) ជាធម្មតាត្រូវបានដំឡើងនៅក្នុងចង្កោមជា DaemonSet ជាមួយ install-cni as កុងតឺន័រ.
• Install-cni បង្កើត ឯកសារកំណត់រចនាសម្ព័ន្ធ CNI (/etc/cni/net.d/10-flannel.conflist) នៅលើថ្នាំងនីមួយៗ។
• Flanneld បង្កើតឧបករណ៍ vxlan ទាញយកទិន្នន័យមេតាបណ្តាញពីម៉ាស៊ីនមេ API និងតាមដានការអាប់ដេតផត។ ដូចដែលពួកវាត្រូវបានបង្កើត វាចែកចាយផ្លូវទៅកាន់ផតទាំងអស់នៅទូទាំងចង្កោម។
• ផ្លូវទាំងនេះអនុញ្ញាតឱ្យ pods ទាក់ទងគ្នាទៅវិញទៅមកតាមរយៈអាសយដ្ឋាន IP ។

សម្រាប់ព័ត៌មានលម្អិតបន្ថែមអំពីការងាររបស់ Flannel ខ្ញុំសូមណែនាំឱ្យប្រើតំណភ្ជាប់នៅចុងបញ្ចប់នៃអត្ថបទ។

នេះគឺជាដ្យាក្រាមនៃអន្តរកម្មរវាងកម្មវិធីជំនួយ Containerd CRI និងកម្មវិធីជំនួយ CNI៖

ដូចដែលអ្នកអាចឃើញខាងលើ kubelet ហៅកម្មវិធីជំនួយ Containerd CRI ដើម្បីបង្កើត pod ដែលបន្ទាប់មកហៅកម្មវិធីជំនួយ CNI ដើម្បីកំណត់រចនាសម្ព័ន្ធបណ្តាញរបស់ pod ។ ក្នុងការធ្វើដូច្នេះ កម្មវិធីជំនួយ CNI របស់អ្នកផ្តល់សេវាបណ្តាញហៅកម្មវិធីជំនួយ CNI ស្នូលផ្សេងទៀតដើម្បីកំណត់រចនាសម្ព័ន្ធទិដ្ឋភាពផ្សេងៗនៃបណ្តាញ។

អន្តរកម្មរវាងកម្មវិធីជំនួយ CNI

មានកម្មវិធីជំនួយ CNI ជាច្រើនដែលការងាររបស់ពួកគេគឺដើម្បីជួយរៀបចំទំនាក់ទំនងបណ្តាញរវាងកុងតឺន័រនៅលើម៉ាស៊ីន។ អត្ថបទនេះនឹងពិភាក្សាបីក្នុងចំណោមពួកគេ។

កម្មវិធីជំនួយ CNI Flannel

នៅពេលប្រើ Flannel ជាអ្នកផ្តល់បណ្តាញ សមាសភាគ Containerd CRI ហៅទូរសព្ទ កម្មវិធីជំនួយ CNI Flannelដោយប្រើឯកសារកំណត់រចនាសម្ព័ន្ធ CNI /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 ដំណើរការដោយភ្ជាប់ជាមួយ Flannel ។ ក្នុងអំឡុងពេលចាប់ផ្តើម 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 ដើម្បីកំណត់រចនាសម្ព័ន្ធ និងហៅកម្មវិធីជំនួយស្ពាន CNI ។

ស្ពានកម្មវិធីជំនួយ CNI

កម្មវិធីជំនួយនេះត្រូវបានហៅដោយការកំណត់រចនាសម្ព័ន្ធដូចខាងក្រោមៈ

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

នៅពេលគេហៅជាលើកដំបូង វាបង្កើតស្ពានលីនុចជាមួយ «name»: «cni0»ដែលត្រូវបានចង្អុលបង្ហាញនៅក្នុង config ។ បន្ទាប់មកគូ veth ត្រូវបានបង្កើតឡើងសម្រាប់ pod នីមួយៗ។ ចុងម្ខាងរបស់វាត្រូវបានភ្ជាប់ទៅបណ្តាញ namespace របស់កុងតឺន័រ ហើយមួយទៀតត្រូវបានបញ្ចូលក្នុងស្ពានលីនុចនៅលើបណ្តាញម៉ាស៊ីន។ ស្ពានកម្មវិធីជំនួយ CNI ភ្ជាប់កុងតឺន័រម៉ាស៊ីនទាំងអស់ទៅស្ពានលីនុចនៅលើបណ្តាញម៉ាស៊ីន។

ដោយបានបញ្ចប់ការដំឡើង veth pair កម្មវិធីជំនួយ Bridge ហៅកម្មវិធីជំនួយ IPAM CNI ក្នុងស្រុករបស់ម៉ាស៊ីន។ ប្រភេទកម្មវិធីជំនួយ IPAM អាចត្រូវបានកំណត់រចនាសម្ព័ន្ធនៅក្នុង CNI config ដែលកម្មវិធីជំនួយ CRI ប្រើដើម្បីហៅកម្មវិធីជំនួយ Flannel CNI ។

កម្មវិធីជំនួយ IPAM CNI ក្នុងស្រុករបស់ម្ចាស់ផ្ទះ

ស្ពាន CNI ហៅ កម្មវិធីជំនួយ IPAM ក្នុងស្រុករបស់ម្ចាស់ផ្ទះ CNI ជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធដូចខាងក្រោមៈ

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

កម្មវិធីជំនួយ IPAM ក្នុងស្រុករបស់ម៉ាស៊ីន (IP Address ។ Mការគ្រប់គ្រង - ការគ្រប់គ្រងអាសយដ្ឋាន IP) ត្រឡប់អាសយដ្ឋាន IP សម្រាប់កុងតឺន័រពីបណ្តាញរង ហើយរក្សាទុក IP ដែលបានបែងចែកនៅលើម៉ាស៊ីននៅក្នុងថតដែលបានបញ្ជាក់នៅក្នុងផ្នែក dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. ឯកសារនេះមានលេខសម្គាល់កុងតឺន័រដែលអាសយដ្ឋាន IP នេះត្រូវបានចាត់តាំង។

នៅពេលហៅកម្មវិធីជំនួយ IPAM ក្នុងស្រុករបស់ម្ចាស់ផ្ទះ វាត្រឡប់ទិន្នន័យខាងក្រោម៖

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

សង្ខេប

Kube-controller-manager ផ្តល់ podCIDR ដល់ថ្នាំងនីមួយៗ។ ផតផតរបស់ថ្នាំងនីមួយៗទទួលបានអាសយដ្ឋាន IP ពីចន្លោះអាសយដ្ឋាននៅក្នុងជួរ podCIDR ដែលបានបែងចែក។ ដោយសារ podCIDR របស់ថ្នាំងមិនត្រួតលើគ្នា ផតទាំងអស់ទទួលបានអាសយដ្ឋាន IP តែមួយគត់។

អ្នកគ្រប់គ្រងចង្កោម Kubernetes កំណត់រចនាសម្ព័ន្ធ និងដំឡើង kubelet រយៈពេលដំណើរការកុងតឺន័រ ភ្នាក់ងារផ្តល់បណ្តាញ និងចម្លងកម្មវិធីជំនួយ CNI ទៅថ្នាំងនីមួយៗ។ កំឡុងពេលចាប់ផ្តើម ភ្នាក់ងារផ្តល់សេវាបណ្តាញបង្កើតការកំណត់រចនាសម្ព័ន្ធ CNI ។ នៅពេលដែលផតត្រូវបានកំណត់ពេលទៅថ្នាំង kubelet ហៅកម្មវិធីជំនួយ CRI ដើម្បីបង្កើតវា។ បន្ទាប់មក ប្រសិនបើកុងតឺន័រត្រូវបានប្រើប្រាស់ កម្មវិធីជំនួយ Containerd CRI ហៅកម្មវិធីជំនួយ CNI ដែលបានបញ្ជាក់នៅក្នុង CNI config ដើម្បីកំណត់រចនាសម្ព័ន្ធបណ្តាញរបស់ pod ។ ជាលទ្ធផល pod ទទួលបានអាសយដ្ឋាន IP ។

ខ្ញុំបានចំណាយពេលខ្លះដើម្បីយល់ពី subtleties និង nuances នៃអន្តរកម្មទាំងអស់នេះ។ ខ្ញុំសង្ឃឹមថាបទពិសោធន៍នេះនឹងជួយអ្នកឱ្យយល់កាន់តែច្បាស់អំពីរបៀបដែល Kubernetes ដំណើរការ។ បើខ្ញុំខុសត្រង់ណា សូមទាក់ទងមកខ្ញុំ Twitter ឬនៅអាសយដ្ឋាន [អ៊ីមែលការពារ]. មានអារម្មណ៍សេរីក្នុងការទាក់ទង ប្រសិនបើអ្នកចង់ពិភាក្សាអំពីទិដ្ឋភាពនៃអត្ថបទនេះ ឬអ្វីផ្សេងទៀត។ ខ្ញុំ​ចង់​ជជែក​ជាមួយ​អ្នក!

សេចក្តីយោង

ធុងនិងបណ្តាញ

• ទិដ្ឋភាពទូទៅនៃបណ្តាញកុងតឺន័រ
• Demystifying បណ្តាញកុងតឺន័រ

តើ Flannel ដំណើរការយ៉ាងដូចម្តេច?

• បណ្តាញ Flannel Demystify
• Kubernetes ជាមួយ Flannel - ការយល់ដឹងអំពីបណ្តាញ

CRI និង CNI

• ស្ថាបត្យកម្មកម្មវិធីជំនួយ CRI
• លក្ខណៈ​ពិសេស CNI
• កម្មវិធីជំនួយ CNI

PS ពីអ្នកបកប្រែ

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• «Calico សម្រាប់បណ្តាញនៅក្នុង Kubernetes៖ ការណែនាំ និងបទពិសោធន៍តិចតួច»
• "មគ្គុទ្ទេសក៍គំនូរលើបណ្តាញនៅក្នុង Kubernetes"៖ ផ្នែកទី 1 និងទី 2 (គំរូបណ្តាញ បណ្តាញត្រួតលើគ្នា), ផ្នែកទី 3 (សេវាកម្ម និងដំណើរការចរាចរណ៍);
• «ចំណុចប្រទាក់បណ្តាញកុងតឺន័រ (CNI) - ចំណុចប្រទាក់បណ្តាញនិងស្តង់ដារសម្រាប់ធុងលីនុច"។

ប្រភព: www.habr.com