ຝັກ Kubernetes ໄດ້ຮັບທີ່ຢູ່ IP ແນວໃດ?

ຫມາຍ​ເຫດ​. ແປ.: ບົດຄວາມນີ້, ຂຽນໂດຍວິສະວະກອນ SRE ຈາກ LinkedIn, ເຂົ້າໄປໃນລາຍລະອຽດກ່ຽວກັບ magic ພາຍໃນ Kubernetes - ຫຼາຍທີ່ຊັດເຈນ, ການໂຕ້ຕອບຂອງ CRI, CNI ແລະ kube-apiserver - ທີ່ເກີດຂື້ນໃນເວລາທີ່ pod ຕໍ່ໄປຕ້ອງໄດ້ຮັບການມອບຫມາຍທີ່ຢູ່ IP.

ຫນຶ່ງໃນຂໍ້ກໍານົດພື້ນຖານ ຮູບແບບເຄືອຂ່າຍ Kubernetes ແມ່ນວ່າແຕ່ລະຝັກຕ້ອງມີທີ່ຢູ່ IP ຂອງຕົນເອງ ແລະຝັກອື່ນໆໃນກຸ່ມຕ້ອງສາມາດຕິດຕໍ່ກັບທີ່ຢູ່ນັ້ນໄດ້. ມີຫຼາຍເຄືອຂ່າຍ "ຜູ້ໃຫ້ບໍລິການ" (Flannel, Calico, Canal, ແລະອື່ນໆ) ທີ່ຊ່ວຍປະຕິບັດຮູບແບບເຄືອຂ່າຍນີ້.

ເມື່ອຂ້ອຍເລີ່ມຕົ້ນເຮັດວຽກກັບ Kubernetes ທໍາອິດ, ມັນບໍ່ຊັດເຈນກັບຂ້ອຍວ່າ pods ໄດ້ຮັບທີ່ຢູ່ IP ຂອງພວກເຂົາໄດ້ແນວໃດ. ເຖິງແມ່ນວ່າມີຄວາມເຂົ້າໃຈກ່ຽວກັບວິທີການເຮັດວຽກຂອງອົງປະກອບແຕ່ລະຄົນ, ມັນເປັນການຍາກທີ່ຈະຈິນຕະນາການພວກມັນເຮັດວຽກຮ່ວມກັນ. ຕົວຢ່າງ, ຂ້ອຍຮູ້ວ່າ plugins CNI ແມ່ນຫຍັງ, ແຕ່ຂ້ອຍບໍ່ຮູ້ວ່າພວກມັນຖືກເອີ້ນແນວໃດ. ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈຂຽນບົດຄວາມນີ້ເພື່ອແບ່ງປັນຄວາມຮູ້ກ່ຽວກັບອົງປະກອບເຄືອຂ່າຍຕ່າງໆແລະວິທີການເຮັດວຽກຮ່ວມກັນໃນກຸ່ມ Kubernetes, ເຊິ່ງຊ່ວຍໃຫ້ແຕ່ລະຝັກໄດ້ຮັບທີ່ຢູ່ IP ຂອງຕົນເອງ.

ມີວິທີທີ່ແຕກຕ່າງກັນໃນການຈັດຕັ້ງເຄືອຂ່າຍໃນ Kubernetes, ຄືກັນກັບມີຕົວເລືອກ runtime ທີ່ແຕກຕ່າງກັນສໍາລັບບັນຈຸ. ສິ່ງພິມນີ້ຈະໃຊ້ Flannel ການ​ຈັດ​ຕັ້ງ​ເຄືອ​ຂ່າຍ​ໃນ​ກຸ່ມ​, ແລະ​ເປັນ​ສະ​ພາບ​ແວດ​ລ້ອມ​ການ​ປະ​ຕິ​ບັດ - ຕູ້ຄອນເທນເນີ. ຂ້າພະເຈົ້າຍັງເຮັດໃຫ້ສົມມຸດຕິຖານວ່າທ່ານຮູ້ຈັກວິທີການເຄືອຂ່າຍລະຫວ່າງ containers ເຮັດວຽກ, ສະນັ້ນຂ້າພະເຈົ້າພຽງແຕ່ຈະສໍາຜັດກັບມັນໂດຍຫຍໍ້, ພຽງແຕ່ສໍາລັບສະພາບການ.

ບາງແນວຄວາມຄິດພື້ນຖານ

ຕູ້ຄອນເທນເນີ ແລະເຄືອຂ່າຍ: ພາບລວມໂດຍຫຍໍ້

ມີຫຼາຍສິ່ງພິມທີ່ດີເລີດໃນອິນເຕີເນັດທີ່ອະທິບາຍວິທີການບັນຈຸຕິດຕໍ່ສື່ສານກັບກັນແລະກັນຜ່ານເຄືອຂ່າຍ. ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າພຽງແຕ່ຈະໃຫ້ພາບລວມທົ່ວໄປຂອງແນວຄວາມຄິດພື້ນຖານແລະຈໍາກັດຕົວເອງກັບວິທີການຫນຶ່ງ, ເຊິ່ງກ່ຽວຂ້ອງກັບການສ້າງຂົວ Linux ແລະຫຸ້ມຫໍ່ຫຸ້ມຫໍ່. ລາຍລະອຽດຖືກລະເວັ້ນ, ນັບຕັ້ງແຕ່ຫົວຂໍ້ຂອງເຄືອຂ່າຍຕູ້ຄອນເທນເນີມັນສົມຄວນໄດ້ຮັບບົດຄວາມແຍກຕ່າງຫາກ. ລິ້ງຄ໌ໄປຫາບາງສິ່ງພິມທີ່ມີຄວາມເຂົ້າໃຈໂດຍສະເພາະ ແລະການສຶກສາຈະຖືກສະໜອງໃຫ້ຂ້າງລຸ່ມນີ້.

ບັນຈຸຢູ່ໃນຫນຶ່ງເຈົ້າພາບ

ວິທີໜຶ່ງໃນການຈັດການສື່ສານຜ່ານທີ່ຢູ່ IP ລະຫວ່າງກ່ອງບັນຈຸທີ່ເຮັດວຽກຢູ່ໃນໂຮດດຽວກັນກ່ຽວຂ້ອງກັບການສ້າງຂົວ Linux. ສໍາລັບຈຸດປະສົງນີ້, ອຸປະກອນ virtual ຖືກສ້າງຂຶ້ນໃນ Kubernetes (ແລະ Docker) veth (ອີເທີເນັດ virtual). ປາຍຫນຶ່ງຂອງອຸປະກອນ veth ເຊື່ອມຕໍ່ກັບ namespace ເຄືອຂ່າຍຂອງບັນຈຸ, ອື່ນເພື່ອ ຂົວ Linux ໃນເຄືອຂ່າຍເຈົ້າພາບ.

ຕູ້ຄອນເທນເນີທັງໝົດຢູ່ໃນໂຮດດຽວກັນມີສົ້ນໜຶ່ງຂອງ veth ເຊື່ອມຕໍ່ກັບຂົວທີ່ເຂົາເຈົ້າສາມາດສື່ສານກັບກັນໄດ້ຜ່ານທີ່ຢູ່ IP. ຂົວ Linux ຍັງມີທີ່ຢູ່ IP ແລະເຮັດຫນ້າທີ່ເປັນປະຕູສໍາລັບການຈາລະຈອນ egress ຈາກ pods ປາຍທາງສໍາລັບ nodes ອື່ນໆ.

ບັນຈຸຢູ່ໃນເຈົ້າພາບທີ່ແຕກຕ່າງກັນ

Packet encapsulation ແມ່ນວິທີການຫນຶ່ງທີ່ອະນຸຍາດໃຫ້ containers ໃນ nodes ທີ່ແຕກຕ່າງກັນຕິດຕໍ່ສື່ສານກັບກັນແລະກັນໂດຍໃຊ້ທີ່ຢູ່ IP. ຢູ່ Flannel, ເຕັກໂນໂລຢີແມ່ນຮັບຜິດຊອບສໍາລັບໂອກາດນີ້. vxlan, ເຊິ່ງ "ຊຸດ" ຊຸດຕົ້ນສະບັບເຂົ້າໄປໃນຊຸດ UDP ແລະຫຼັງຈາກນັ້ນສົ່ງມັນໄປຫາປາຍທາງຂອງມັນ.

ໃນກຸ່ມ Kubernetes, Flannel ສ້າງອຸປະກອນ vxlan ແລະປັບປຸງຕາຕະລາງເສັ້ນທາງໃນແຕ່ລະ node ຕາມຄວາມເຫມາະສົມ. ແຕ່ລະແພັກເກັດທີ່ຕັ້ງໄວ້ສໍາລັບບັນຈຸຢູ່ໃນໂຮດທີ່ແຕກຕ່າງກັນຈະຜ່ານອຸປະກອນ vxlan ແລະຖືກຫຸ້ມຢູ່ໃນຊຸດ UDP. ຢູ່ທີ່ຈຸດຫມາຍປາຍທາງ, ແພັກເກັດທີ່ຕິດຢູ່ໄດ້ຖືກສະກັດແລະສົ່ງຕໍ່ໄປຫາຝັກທີ່ຕ້ອງການ.

ຫມາຍ​ເຫດ​: ນີ້​ເປັນ​ພຽງ​ແຕ່​ຫນຶ່ງ​ໃນ​ການ​ຈັດ​ຕັ້ງ​ການ​ສື່​ສານ​ເຄືອ​ຂ່າຍ​ລະ​ຫວ່າງ​ພາ​ຊະ​ນະ​.

CRI ແມ່ນຫຍັງ?

CRI (ການໂຕ້ຕອບການແລ່ນເຄື່ອງບັນຈຸ) ເປັນ plugin ທີ່ອະນຸຍາດໃຫ້ kubelet ໃຊ້ສະພາບແວດລ້ອມ runtime ບັນຈຸທີ່ແຕກຕ່າງກັນ. CRI API ຖືກສ້າງຂຶ້ນໃນ runtimes ຕ່າງໆ, ດັ່ງນັ້ນຜູ້ໃຊ້ສາມາດເລືອກເວລາແລ່ນຕາມການເລືອກຂອງພວກເຂົາ.

CNI ແມ່ນຫຍັງ?

ໂຄງການ CNI ແມ່ນຫນຶ່ງ ສະເພາະ ເພື່ອຈັດຕັ້ງການແກ້ໄຂເຄືອຂ່າຍທົ່ວໄປສໍາລັບກ່ອງບັນຈຸ Linux. ນອກຈາກນັ້ນ, ມັນປະກອບມີ ປລັກອິນ, ຮັບຜິດຊອບຫນ້າທີ່ຕ່າງໆໃນເວລາທີ່ຕັ້ງເຄືອຂ່າຍຝັກ. ປັ໊ກອິນ CNI ເປັນໄຟລ໌ທີ່ສາມາດປະຕິບັດໄດ້ທີ່ສອດຄ່ອງກັບຂໍ້ກໍານົດ (ພວກເຮົາຈະປຶກສາຫາລືບາງ plugins ຂ້າງລຸ່ມນີ້).

ການຈັດສັນ subnets ໃຫ້ກັບ nodes ສໍາລັບການກໍານົດທີ່ຢູ່ IP ໃຫ້ກັບ pods

ເນື່ອງຈາກແຕ່ລະຝັກໃນກຸ່ມຕ້ອງມີທີ່ຢູ່ IP, ມັນເປັນສິ່ງສໍາຄັນເພື່ອໃຫ້ແນ່ໃຈວ່າທີ່ຢູ່ນີ້ເປັນເອກະລັກ. ນີ້ແມ່ນບັນລຸໄດ້ໂດຍການມອບຫມາຍແຕ່ລະ node ເປັນ subnet ເປັນເອກະລັກ, ຈາກ pods ໃນ node ດັ່ງກ່າວໄດ້ຖືກມອບຫມາຍທີ່ຢູ່ IP.

Node IPAM Controller

ໃນເວລາທີ່ nodeipam ຜ່ານເປັນພາລາມິເຕີທຸງ --controllers kube-controller-manager, ມັນຈັດສັນ subnet ແຍກຕ່າງຫາກ (podCIDR) ໃຫ້ກັບແຕ່ລະ node ຈາກ cluster CIDR (i.e., the range of IP addresses for the cluster network). ເນື່ອງຈາກ podCIDR ເຫຼົ່ານີ້ບໍ່ທັບຊ້ອນກັນ, ມັນເປັນໄປໄດ້ສໍາລັບແຕ່ລະຝັກທີ່ຈະໄດ້ຮັບການຈັດສັນທີ່ຢູ່ IP ທີ່ເປັນເອກະລັກ.

ໂນດ Kubernetes ຖືກມອບໝາຍໃຫ້ podCIDR ເມື່ອມັນຖືກລົງທະບຽນໃນເບື້ອງຕົ້ນກັບກຸ່ມ. ເພື່ອປ່ຽນ podCIDR ຂອງ nodes, ທ່ານຈໍາເປັນຕ້ອງຍົກເລີກການລົງທະບຽນພວກມັນແລະຫຼັງຈາກນັ້ນລົງທະບຽນພວກມັນໃຫມ່, ເຮັດການປ່ຽນແປງທີ່ເຫມາະສົມກັບການຕັ້ງຄ່າຊັ້ນຄວບຄຸມ Kubernetes ໃນລະຫວ່າງ. ທ່ານສາມາດສະແດງ podCIDR ຂອງ node ໂດຍໃຊ້ຄໍາສັ່ງຕໍ່ໄປນີ້:

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

Kubelet, container runtime ແລະ CNI plugins: ມັນເຮັດວຽກແນວໃດ

ການຈັດຕາຕະລາງ pod ຕໍ່ node ກ່ຽວຂ້ອງກັບຂັ້ນຕອນການກະກຽມຫຼາຍ. ໃນພາກນີ້, ຂ້າພະເຈົ້າຈະສຸມໃສ່ພຽງແຕ່ກ່ຽວກັບສິ່ງທີ່ກ່ຽວຂ້ອງໂດຍກົງກັບການຕັ້ງຄ່າເຄືອຂ່າຍຝັກ.

ການຈັດຕາຕະລາງ pod ໄປຫາ node ໃດນຶ່ງເຮັດໃຫ້ເກີດຕ່ອງໂສ້ຂອງເຫດການຕໍ່ໄປນີ້:

ຊ່ວຍເຫຼືອ: ສະຖາປັດຕະຍະກໍາຂອງ Containerd CRI plugins.

ການໂຕ້ຕອບລະຫວ່າງ container runtime ແລະ plugins CNI

ຜູ້ໃຫ້ບໍລິການເຄືອຂ່າຍແຕ່ລະຄົນມີ plugin CNI ຂອງຕົນເອງ. runtime ຂອງ container ແລ່ນມັນເພື່ອ configure ເຄືອຂ່າຍສໍາລັບ pod ໄດ້ຍ້ອນວ່າມັນເລີ່ມຕົ້ນຂຶ້ນ. ໃນກໍລະນີຂອງບັນຈຸ, plugin CNI ຖືກເປີດຕົວໂດຍ plugin ສະຖານີ CRI.

ຍິ່ງໄປກວ່ານັ້ນ, ຜູ້ໃຫ້ບໍລິການແຕ່ລະຄົນມີຕົວແທນຂອງຕົນເອງ. ມັນໄດ້ຖືກຕິດຕັ້ງຢູ່ໃນທຸກ nodes Kubernetes ແລະຮັບຜິດຊອບສໍາລັບການຕັ້ງຄ່າເຄືອຂ່າຍຂອງ pods. ຕົວແທນນີ້ຖືກລວມເຂົ້າກັບການຕັ້ງຄ່າ CNI ຫຼືສ້າງມັນຢ່າງເປັນເອກະລາດຢູ່ໃນ node. config ຊ່ວຍໃຫ້ plugin CRI ກໍານົດ plugin CNI ທີ່ຈະໂທຫາ.

ສະຖານທີ່ຂອງ CNI config ສາມາດປັບແຕ່ງໄດ້; ໂດຍຄ່າເລີ່ມຕົ້ນມັນຢູ່ໃນ /etc/cni/net.d/<config-file>. ຜູ້ບໍລິຫານກຸ່ມຍັງຮັບຜິດຊອບການຕິດຕັ້ງ plugins CNI ໃນແຕ່ລະ node ຂອງ cluster. ສະຖານທີ່ຂອງພວກເຂົາແມ່ນສາມາດປັບແຕ່ງໄດ້; ໄດເລກະທໍລີເລີ່ມຕົ້ນ - /opt/cni/bin.

ເມື່ອໃຊ້ containerd, ເສັ້ນທາງສໍາລັບ plugin config ແລະ binaries ສາມາດຖືກກໍານົດຢູ່ໃນພາກ [plugins.«io.containerd.grpc.v1.cri».cni] в ໄຟລ໌ການຕັ້ງຄ່າບັນຈຸ.

ເນື່ອງຈາກພວກເຮົາກໍາລັງໃຊ້ Flannel ເປັນຜູ້ໃຫ້ບໍລິການເຄືອຂ່າຍຂອງພວກເຮົາ, ໃຫ້ເວົ້າເລັກນ້ອຍກ່ຽວກັບການຕັ້ງຄ່າມັນ:

• Flanneld (Flannel's daemon) ມັກຈະຖືກຕິດຕັ້ງຢູ່ໃນກຸ່ມເປັນ DaemonSet ທີ່ມີ install-cni ເປັນ ບັນຈຸ init.
• Install-cni ສ້າງ ໄຟລ໌ການຕັ້ງຄ່າ CNI (/etc/cni/net.d/10-flannel.conflist) ໃນແຕ່ລະ node.
• Flanneld ສ້າງອຸປະກອນ vxlan, ດຶງຂໍ້ມູນ metadata ເຄືອຂ່າຍຈາກເຄື່ອງແມ່ຂ່າຍ API, ແລະຕິດຕາມກວດກາການປັບປຸງ pod. ເມື່ອພວກມັນຖືກສ້າງຂື້ນ, ມັນແຈກຢາຍເສັ້ນທາງໄປຫາຝັກທັງຫມົດໃນທົ່ວກຸ່ມ.
• ເສັ້ນທາງເຫຼົ່ານີ້ອະນຸຍາດໃຫ້ pods ສາມາດສື່ສານກັບກັນແລະກັນໂດຍຜ່ານທີ່ຢູ່ IP.

ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບການເຮັດວຽກຂອງ Flannel, ຂ້າພະເຈົ້າແນະນໍາໃຫ້ໃຊ້ການເຊື່ອມຕໍ່ໃນຕອນທ້າຍຂອງບົດຄວາມ.

ນີ້ແມ່ນແຜນວາດຂອງການໂຕ້ຕອບລະຫວ່າງປລັກອິນ Containerd CRI ແລະ plugins CNI:

ດັ່ງທີ່ເຈົ້າເຫັນຂ້າງເທິງ, kubelet ໂທຫາ Containerd CRI plugin ເພື່ອສ້າງ pod, ເຊິ່ງຫຼັງຈາກນັ້ນໂທຫາ plugin CNI ເພື່ອ configure ເຄືອຂ່າຍຂອງ pod. ໃນການເຮັດດັ່ງນັ້ນ, plugin CNI ຂອງຜູ້ໃຫ້ບໍລິການເຄືອຂ່າຍໂທຫາ plugins CNI ຫຼັກອື່ນໆເພື່ອກໍານົດລັກສະນະຕ່າງໆຂອງເຄືອຂ່າຍ.

ການໂຕ້ຕອບລະຫວ່າງ plugins CNI

ມີ plugins CNI ຕ່າງໆທີ່ມີຫນ້າທີ່ຊ່ວຍຕັ້ງການສື່ສານເຄືອຂ່າຍລະຫວ່າງ containers ຢູ່ໃນເຈົ້າພາບ. ບົດຄວາມນີ້ຈະສົນທະນາສາມຂອງພວກເຂົາ.

CNI plugin Flannel

ເມື່ອໃຊ້ Flannel ເປັນຜູ້ໃຫ້ບໍລິການເຄືອຂ່າຍ, ອົງປະກອບ Containerd CRI ໂທ CNI plugin 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 ເພື່ອຕັ້ງຄ່າແລະໂທຫາ plugin ຂົວ CNI.

CNI plugin Bridge

ປັ໊ກອິນນີ້ຖືກເອີ້ນດ້ວຍການຕັ້ງຄ່າຕໍ່ໄປນີ້:

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

ໃນເວລາທີ່ເອີ້ນວ່າຄັ້ງທໍາອິດ, ມັນສ້າງຂົວ Linux ກັບ «name»: «cni0», ເຊິ່ງລະບຸໄວ້ໃນ config. ຫຼັງຈາກນັ້ນ, ຄູ່ veth ແມ່ນຖືກສ້າງຂຶ້ນສໍາລັບແຕ່ລະຝັກ. ປາຍຫນຶ່ງຂອງມັນເຊື່ອມຕໍ່ກັບ namespace ເຄືອຂ່າຍຂອງ container, ອີກອັນຫນຶ່ງແມ່ນລວມຢູ່ໃນຂົວ Linux ໃນເຄືອຂ່າຍເຈົ້າພາບ. CNI plugin Bridge ເຊື່ອມຕໍ່ host containers ທັງໝົດກັບຂົວ Linux ໃນເຄືອຂ່າຍແມ່ຂ່າຍ.

ຫຼັງຈາກສໍາເລັດການຕັ້ງຄ່າຄູ່ veth, ປັ໊ກອິນ Bridge ໂທຫາ plugin IPAM CNI ທ້ອງຖິ່ນຂອງເຈົ້າພາບ. ປະເພດຂອງປລັກອິນ IPAM ສາມາດຖືກຕັ້ງຄ່າໃນການຕັ້ງຄ່າ CNI ທີ່ plugin CRI ໃຊ້ເພື່ອໂທຫາ plugin Flannel CNI.

ປລັກອິນ IPAM CNI ຂອງເຈົ້າພາບ-ທ້ອງຖິ່ນ

ຂົວ CNI ໂທ host-local IPAM plugin CNI ດ້ວຍ​ການ​ຕັ້ງ​ຄ່າ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

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

ປລັກອິນ IPAM ຂອງເຈົ້າພາບ-ທ້ອງຖິ່ນ (IP Address Mການ​ຄຸ້ມ​ຄອງ​ທີ່​ຢູ່ IP​) ສົ່ງຄືນທີ່ຢູ່ IP ສໍາລັບ container ຈາກ subnet ແລະເກັບຮັກສາ IP ທີ່ຈັດສັນໄວ້ໃນໂຮດໃນໄດເລກະທໍລີທີ່ລະບຸໄວ້ໃນພາກ dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. ໄຟລ໌ນີ້ມີ ID ຂອງບັນຈຸທີ່ທີ່ຢູ່ IP ນີ້ຖືກມອບຫມາຍ.

ເມື່ອໂທຫາ plugin IPAM ທ້ອງຖິ່ນຂອງເຈົ້າພາບ, ມັນຈະສົ່ງຄືນຂໍ້ມູນຕໍ່ໄປນີ້:

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

Summary

Kube-controller-manager ມອບໝາຍ podCIDR ໃຫ້ກັບແຕ່ລະ node. pods ຂອງແຕ່ລະ node ໄດ້ຮັບທີ່ຢູ່ IP ຈາກພື້ນທີ່ທີ່ຢູ່ໃນຊ່ວງ podCIDR ທີ່ຈັດສັນ. ເນື່ອງຈາກ podCIDRs ຂອງ nodes ບໍ່ທັບຊ້ອນກັນ, pods ທັງຫມົດໄດ້ຮັບທີ່ຢູ່ IP ທີ່ເປັນເອກະລັກ.

ຜູ້ເບິ່ງແຍງກຸ່ມ Kubernetes ກຳນົດຄ່າ ແລະຕິດຕັ້ງ kubelet, container runtime, network provider agents, ແລະ copy the CNI plugins to each node. ໃນລະຫວ່າງການເລີ່ມຕົ້ນ, ຕົວແທນຜູ້ໃຫ້ບໍລິການເຄືອຂ່າຍຈະສ້າງການຕັ້ງຄ່າ CNI. ເມື່ອຝັກຖືກກຳນົດໃຫ້ກັບໂຫນດ, kubelet ໂທຫາ plugin CRI ເພື່ອສ້າງມັນ. ຕໍ່ໄປ, ຖ້າໃຊ້ containerd, Containerd CRI plugin ເອີ້ນ plugin CNI ທີ່ລະບຸໄວ້ໃນ CNI config ເພື່ອ configure ເຄືອຂ່າຍຂອງ pod. ດັ່ງນັ້ນ, ຝັກໄດ້ຮັບທີ່ຢູ່ IP.

ມັນໃຊ້ເວລາຂ້າພະເຈົ້າໃຊ້ເວລາບາງເພື່ອເຂົ້າໃຈ subtleties ທັງຫມົດແລະ nuances ຂອງການໂຕ້ຕອບທັງຫມົດເຫຼົ່ານີ້. ຂ້ອຍຫວັງວ່າປະສົບການນີ້ຈະຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈດີຂຶ້ນວ່າ Kubernetes ເຮັດວຽກແນວໃດ. ຖ້າຂ້ອຍຜິດພາດຫຍັງ, ກະລຸນາຕິດຕໍ່ຂ້ອຍທີ່ Twitter ຫຼືຢູ່ໃນທີ່ຢູ່ [email protected]. ກະລຸນາຕິດຕໍ່ຫາທ່ານຖ້າທ່ານຕ້ອງການປຶກສາຫາລືກ່ຽວກັບລັກສະນະຂອງບົດຄວາມນີ້ຫຼືສິ່ງອື່ນໃດ. ຂ້ອຍຢາກລົມກັບເຈົ້າ!

ເອກະສານ

ຕູ້ຄອນເທນເນີແລະເຄືອຂ່າຍ

• ພາບລວມເຄືອຂ່າຍຕູ້ຄອນເທນເນີ
• Demystifying ເຄືອຂ່າຍ container

Flannel ເຮັດວຽກແນວໃດ?

• Flannel Networking Demystify
• Kubernetes ກັບ Flannel - ຄວາມເຂົ້າໃຈກ່ຽວກັບເຄືອຂ່າຍ

CRI ແລະ CNI

• CRI Plugin ສະຖາປັດຕະຍະກໍາ
• CNI Spec
• CNI Plugins

PS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «Calico ສໍາລັບເຄືອຂ່າຍໃນ Kubernetes: ການແນະນໍາແລະປະສົບການເລັກນ້ອຍ"
• "ຄູ່ມືຮູບພາບກ່ຽວກັບເຄືອຂ່າຍໃນ Kubernetes": ພາກທີ 1 ແລະ 2 (ຕົວແບບເຄືອຂ່າຍ, ເຄືອຂ່າຍຊ້ອນກັນ), ພາກ​ທີ 3 (ການ​ບໍ​ລິ​ການ​ແລະ​ການ​ປຸງ​ແຕ່ງ​ຈະ​ລາ​ຈອນ​);
• «Container Networking Interface (CNI) - ການໂຕ້ຕອບເຄືອຂ່າຍ ແລະມາດຕະຖານສໍາລັບກ່ອງບັນຈຸ Linux".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com