Tandaan. transl.: Ang artikulong ito, na isinulat ng isang SRE engineer mula sa LinkedIn, ay nagdedetalye tungkol sa panloob na magic sa Kubernetes - mas tiyak, ang pakikipag-ugnayan ng CRI, CNI at kube-apiserver - na nangyayari kapag ang susunod na pod ay kailangang magtalaga ng IP address.
Isa sa mga pangunahing pangangailangan ay ang bawat pod ay dapat may sarili nitong IP address at anumang iba pang pod sa cluster ay dapat na makontak ito sa address na iyon. Maraming "provider" ng network (Flannel, Calico, Canal, atbp.) na tumutulong sa pagpapatupad ng modelong ito ng network.
Noong una akong nagsimulang magtrabaho sa Kubernetes, hindi lubos na malinaw sa akin kung paano eksaktong nakukuha ng mga pod ang kanilang mga IP address. Kahit na may pag-unawa sa kung paano gumagana ang mga indibidwal na bahagi, mahirap isipin na nagtutulungan ang mga ito. Halimbawa, alam ko kung para saan ang mga plugin ng CNI, ngunit wala akong ideya kung paano eksaktong tinawag ang mga ito. Samakatuwid, nagpasya akong isulat ang artikulong ito upang magbahagi ng kaalaman tungkol sa iba't ibang bahagi ng network at kung paano sila nagtutulungan sa isang Kubernetes cluster, na nagpapahintulot sa bawat pod na makakuha ng sarili nitong natatanging IP address.
Mayroong iba't ibang paraan upang ayusin ang networking sa Kubernetes, tulad ng iba't ibang mga opsyon sa runtime para sa mga container. Gagamitin ng publikasyong ito upang ayusin ang isang network sa isang kumpol, at bilang isang executable na kapaligiran - . I'm also making the assumption that you know how networking between containers works, so I'm just touch on it briefly, just for context.
Ang ilang mga pangunahing konsepto
Mga Container at ang Network: Isang Maikling Pangkalahatang-ideya
Maraming mahuhusay na publikasyon sa Internet na nagpapaliwanag kung paano nakikipag-ugnayan ang mga lalagyan sa isa't isa sa network. Samakatuwid, magbibigay lamang ako ng pangkalahatang pangkalahatang-ideya ng mga pangunahing konsepto at lilimitahan ang aking sarili sa isang diskarte, na kinabibilangan ng paglikha ng tulay ng Linux at mga encapsulating package. Ang mga detalye ay tinanggal, dahil ang paksa ng container networking mismo ay nararapat sa isang hiwalay na artikulo. Ang mga link sa ilang partikular na insightful at pang-edukasyon na mga publikasyon ay ibibigay sa ibaba.
Mga lalagyan sa isang host
Ang isang paraan upang ayusin ang komunikasyon sa pamamagitan ng mga IP address sa pagitan ng mga container na tumatakbo sa parehong host ay kinabibilangan ng paglikha ng tulay ng Linux. Para sa layuning ito, nilikha ang mga virtual na device sa Kubernetes (at Docker) . Ang isang dulo ng veth device ay kumokonekta sa namespace ng network ng container, ang isa naman sa sa host network.
Ang lahat ng mga container sa parehong host ay may isang dulo ng veth na konektado sa isang tulay kung saan maaari silang makipag-ugnayan sa isa't isa sa pamamagitan ng mga IP address. Ang tulay ng Linux ay mayroon ding IP address at nagsisilbing gateway para sa paglabas ng trapiko mula sa mga pod na nakalaan para sa iba pang mga node.
Mga lalagyan sa iba't ibang host
Ang packet encapsulation ay isang paraan na nagbibigay-daan sa mga container sa iba't ibang node na makipag-ugnayan sa isa't isa gamit ang mga IP address. Sa Flannel, responsibilidad ng teknolohiya ang pagkakataong ito. , na "nagpa-package" sa orihinal na packet sa isang UDP packet at pagkatapos ay ipinapadala ito sa destinasyon nito.
Sa isang Kubernetes cluster, ang Flannel ay gumagawa ng isang vxlan device at ina-update ang talahanayan ng ruta sa bawat node nang naaayon. Ang bawat packet na nakalaan para sa isang lalagyan sa ibang host ay dumadaan sa vxlan device at naka-encapsulate sa isang UDP packet. Sa destinasyon, ang nested packet ay kinukuha at ipapasa sa gustong pod.
Tandaan: Isa lang itong paraan para ayusin ang komunikasyon sa network sa pagitan ng mga container.
Ano ang CRI?
ay isang plugin na nagbibigay-daan sa kubelet na gumamit ng iba't ibang container runtime environment. Ang CRI API ay binuo sa iba't ibang mga runtime, kaya maaaring piliin ng mga user ang runtime na kanilang pinili.
Ano ang CNI?
ay isang upang ayusin ang isang unibersal na solusyon sa network para sa mga lalagyan ng Linux. Bilang karagdagan, kabilang dito , responsable para sa iba't ibang mga function kapag nagse-set up ng pod network. Ang CNI plugin ay isang executable file na sumusunod sa detalye (tatalakayin natin ang ilang plugin sa ibaba).
Paglalaan ng mga subnet sa mga node para sa pagtatalaga ng mga IP address sa mga pod
Dahil dapat may IP address ang bawat pod sa isang cluster, mahalagang tiyakin na kakaiba ang address na ito. Ito ay nakakamit sa pamamagitan ng pagtatalaga sa bawat node ng isang natatanging subnet, kung saan ang mga pod sa node na iyon ay pagkatapos ay itinalaga ang mga IP address.
Node IPAM Controller
Kapag nodeipam ipinasa bilang isang parameter ng bandila --controllers , naglalaan ito ng hiwalay na subnet (podCIDR) sa bawat node mula sa cluster CIDR (ibig sabihin, ang hanay ng mga IP address para sa cluster network). Dahil ang mga podCIDR na ito ay hindi nagsasapawan, nagiging posible para sa bawat pod na maglaan ng natatanging IP address.
Ang isang Kubernetes node ay itinalaga ng isang podCIDR kapag una itong nakarehistro sa cluster. Upang baguhin ang podCIDR ng mga node, kailangan mong alisin sa pagkakarehistro ang mga ito at pagkatapos ay muling irehistro ang mga ito, na gagawa ng mga naaangkop na pagbabago sa configuration ng control layer ng Kubernetes sa pagitan. Maaari mong ipakita ang podCIDR ng isang node gamit ang sumusunod na command:
$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24
Kubelet, container runtime at CNI plugins: kung paano gumagana ang lahat
Ang pag-iskedyul ng pod sa bawat node ay nagsasangkot ng maraming hakbang sa paghahanda. Sa seksyong ito, magtutuon lang ako ng pansin sa mga direktang nauugnay sa pag-set up ng pod network.
Ang pag-iskedyul ng pod sa isang partikular na node ay nagti-trigger sa sumusunod na hanay ng mga kaganapan:
FAQ: .
Pakikipag-ugnayan sa pagitan ng runtime ng container at mga plugin ng CNI
Ang bawat network provider ay may sariling CNI plugin. Pinapatakbo ito ng runtime ng container upang i-configure ang network para sa pod habang nagsisimula ito. Sa kaso ng containerd, ang CNI plugin ay inilunsad ng plugin .
Bukod dito, ang bawat provider ay may sariling ahente. Naka-install ito sa lahat ng Kubernetes node at responsable para sa configuration ng network ng mga pod. Ang ahente na ito ay maaaring kasama sa CNI config o independiyenteng gumagawa nito sa node. Tinutulungan ng config ang CRI plugin na itakda kung aling CNI plugin ang tatawagan.
Maaaring i-customize ang lokasyon ng CNI config; sa pamamagitan ng default ito ay nasa /etc/cni/net.d/<config-file>. Responsable din ang mga administrator ng cluster sa pag-install ng mga CNI plugin sa bawat cluster node. Nako-customize din ang kanilang lokasyon; default na direktoryo - /opt/cni/bin.
Kapag gumagamit ng containerd, ang mga path para sa plugin config at binary ay maaaring itakda sa seksyon [plugins.Β«io.containerd.grpc.v1.criΒ».cni] Π² .
Dahil ginagamit namin ang Flannel bilang aming network provider, pag-usapan natin ang tungkol sa pag-set up nito:
- Ang Flanneld (Flannel's daemon) ay karaniwang naka-install sa isang cluster bilang isang DaemonSet na may
install-cnibilang . Install-cnilumilikha (/etc/cni/net.d/10-flannel.conflist) sa bawat node.- Lumilikha si Flanneld ng vxlan device, kinukuha ang metadata ng network mula sa API server, at sinusubaybayan ang mga update sa pod. Habang ginagawa ang mga ito, namamahagi ito ng mga ruta sa lahat ng pod sa buong cluster.
- Ang mga rutang ito ay nagpapahintulot sa mga pod na makipag-ugnayan sa isa't isa sa pamamagitan ng mga IP address.
Para sa mas detalyadong impormasyon tungkol sa gawain ng Flannel, inirerekumenda ko ang paggamit ng mga link sa dulo ng artikulo.
Narito ang isang diagram ng pakikipag-ugnayan sa pagitan ng Containerd CRI plugin at ng CNI plugins:
Gaya ng nakikita mo sa itaas, tinatawagan ng kubelet ang Containerd CRI plugin upang gawin ang pod, na pagkatapos ay tatawagan ang CNI plugin upang i-configure ang network ng pod. Sa paggawa nito, ang CNI plugin ng network provider ay tumatawag sa iba pang mga pangunahing CNI plugin upang i-configure ang iba't ibang aspeto ng network.
Pakikipag-ugnayan sa pagitan ng mga plugin ng CNI
Mayroong iba't ibang mga plugin ng CNI na ang trabaho ay tumulong sa pag-set up ng komunikasyon sa network sa pagitan ng mga container sa host. Tatalakayin ng artikulong ito ang tatlo sa mga ito.
CNI plugin na Flannel
Kapag gumagamit ng Flannel bilang isang network provider, tumatawag ang Containerd CRI component gamit ang CNI configuration file /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
}
}
]
}
Gumagana ang Flannel CNI plugin kasabay ng Flanneld. Sa panahon ng pagsisimula, kinukuha ng Flanneld ang podCIDR at iba pang mga detalyeng nauugnay sa network mula sa API server at ini-save ang mga ito sa isang file /run/flannel/subnet.env.
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=false
Ang Flannel CNI plugin ay gumagamit ng data mula sa /run/flannel/subnet.env upang i-configure at tawagan ang CNI bridge plugin.
CNI plugin Bridge
Ang plugin na ito ay tinatawag na may sumusunod na configuration:
{
"name": "cni0",
"type": "bridge",
"mtu": 1450,
"ipMasq": false,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24"
}
}
Kapag tinawag sa unang pagkakataon, lumilikha ito ng tulay ng Linux na may Β«nameΒ»: Β«cni0Β», na ipinahiwatig sa config. Pagkatapos ang isang pares ng veth ay nilikha para sa bawat pod. Ang isang dulo nito ay konektado sa network namespace ng container, ang isa ay kasama sa Linux bridge sa host network. nagkokonekta sa lahat ng host container sa isang Linux bridge sa host network.
Kapag natapos na ang pag-set up ng veth pair, tinatawag ng Bridge plugin ang host-local na IPAM CNI plugin. Maaaring i-configure ang uri ng IPAM plugin sa CNI config na ginagamit ng CRI plugin para tawagan ang Flannel CNI plugin.
Host-local na IPAM CNI na mga plugin
Mga tawag sa Bridge CNI na may sumusunod na pagsasaayos:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Host-lokal na IPAM plugin (IP Address Mpamamahala - pamamahala ng IP address) ibinabalik ang IP address para sa lalagyan mula sa subnet at iniimbak ang inilalaang IP sa host sa direktoryo na tinukoy sa seksyon dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Ang file na ito ay naglalaman ng ID ng container kung saan nakatalaga ang IP address na ito.
Kapag tumatawag sa host-local na IPAM plugin, ibinabalik nito ang sumusunod na data:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Buod
Ang Kube-controller-manager ay nagtatalaga ng podCIDR sa bawat node. Ang mga pod ng bawat node ay tumatanggap ng mga IP address mula sa puwang ng address sa nakalaan na hanay ng podCIDR. Dahil ang mga podCIDR ng mga node ay hindi nagsasapawan, lahat ng mga pod ay tumatanggap ng mga natatanging IP address.
Kino-configure at ini-install ng Kubernetes cluster administrator ang kubelet, container runtime, network provider agent, at kinokopya ang mga CNI plugin sa bawat node. Sa panahon ng pagsisimula, ang ahente ng network provider ay bumubuo ng isang CNI config. Kapag ang isang pod ay naka-iskedyul sa isang node, ang kubelet ay tumatawag sa CRI plugin upang gawin ito. Susunod, kung ginamit ang containerd, tatawagin ng Containerd CRI plugin ang CNI plugin na tinukoy sa CNI config upang i-configure ang network ng pod. Bilang resulta, ang pod ay tumatanggap ng isang IP address.
Kinailangan ko ng ilang oras upang maunawaan ang lahat ng mga subtleties at nuances ng lahat ng mga pakikipag-ugnayang ito. Umaasa ako na ang karanasang ito ay makakatulong sa iyo na mas maunawaan kung paano gumagana ang Kubernetes. Kung mali ako tungkol sa anumang bagay, mangyaring makipag-ugnayan sa akin sa o sa address . Huwag mag-atubiling makipag-ugnayan kung gusto mong talakayin ang mga aspeto ng artikulong ito o anumang bagay. Gusto kong makipag-chat sa iyo!
sanggunian
Mga lalagyan at network
Paano gumagana ang Flannel?
CRI at CNI
PS mula sa tagasalin
Basahin din sa aming blog:
- Β«";
- "Isang Illustrated na Gabay sa Networking sa Kubernetes": , ;
- Β«'.
Pinagmulan: www.habr.com