Noat. transl.: Dit artikel, skreaun troch in SRE-yngenieur fan LinkedIn, giet yn detail yn oer de ynderlike magy yn Kubernetes - krekter, de ynteraksje fan CRI, CNI en kube-apiserver - dat bart as de folgjende pod in IP-adres moat wurde tawiisd.
Ien fan 'e basis easken is dat elke pod in eigen IP-adres moat hawwe en elke oare pod yn it kluster moat it op dat adres kinne kontakt opnimme. D'r binne in protte netwurk "oanbieders" (Flannel, Calico, Canal, ensfh.) dy't helpe by it útfieren fan dit netwurkmodel.
Doe't ik foar it earst mei Kubernetes begon te wurkjen, wie it my net hielendal dúdlik hoe't pods krekt har IP-adressen krije. Sels mei in begryp fan hoe't de yndividuele komponinten funksjonearren, wie it dreech foar te stellen dat se gearwurkje. Bygelyks, ik wist wat CNI plugins wiene foar, mar ik hie gjin idee hoe krekt se waarden neamd. Dêrom besleat ik dit artikel te skriuwen om kennis te dielen oer de ferskate netwurkkomponinten en hoe't se gearwurkje yn in Kubernetes-kluster, wêrtroch elke pod syn eigen unike IP-adres kin krije.
D'r binne ferskate manieren om netwurken te organisearjen yn Kubernetes, krekt lykas d'r ferskate runtime-opsjes binne foar konteners. Dizze publikaasje sil brûke om in netwurk te organisearjen yn in kluster, en as in útfierbere omjouwing - . Ik nim ek de oanname dat jo witte hoe't netwurking tusken konteners wurket, dus ik sil it gewoan koart oanreitsje, allinich foar kontekst.
Guon basisbegripen
Containers en it netwurk: in koart oersjoch
D'r binne genôch treflike publikaasjes op it ynternet dy't útlizze hoe't konteners mei-inoar kommunisearje oer it netwurk. Dêrom sil ik allinich in algemien oersjoch jaan fan 'e basisbegripen en my beheine ta ien oanpak, wêrby't it meitsjen fan in Linux-brêge en it ynkapseljen fan pakketten giet. Details wurde weilitten, om't it ûnderwerp fan kontenernetwurk sels in apart artikel fertsjinnet. Links nei guon benammen ynsjochsume en edukative publikaasjes sille hjirûnder wurde levere.
Containers op ien host
Ien manier om kommunikaasje te organisearjen fia IP-adressen tusken konteners dy't op deselde host rinne omfetsje it meitsjen fan in Linux-brêge. Foar dit doel wurde firtuele apparaten makke yn Kubernetes (en Docker) . Ien ein fan de veth apparaat ferbynt mei de container syn netwurk nammeromte, de oare oan op it hostnetwurk.
Alle konteners op deselde host hawwe ien ein fan 'e veth ferbûn mei in brêge dêr't se kinne kommunisearje mei elkoar fia IP-adressen. De Linux-brêge hat ek in IP-adres en fungearret as in poarte foar útgongsferkear fan 'e pods dy't ornearre binne foar oare knopen.
Containers op ferskate hosts
Pakketkapsulaasje is ien metoade wêrmei konteners op ferskate knopen mei-inoar kinne kommunisearje mei IP-adressen. By Flannel is technology ferantwurdlik foar dizze kâns. , dy't it orizjinele pakket "pakket" yn in UDP-pakket en dan stjoert it nei syn bestimming.
Yn in Kubernetes-kluster makket Flannel in vxlan-apparaat en fernijt de rûtetabel op elke knooppunt neffens. Elk pakket dat is ornearre foar in kontener op in oare host giet troch it vxlan-apparaat en wurdt ynkapsele yn in UDP-pakket. Op de bestimming wurdt it nestele pakket ekstrahearre en trochstjoerd nei de winske pod.
Opmerking: dit is mar ien manier om netwurkkommunikaasje tusken konteners te organisearjen.
Wat is CRI?
is in plugin wêrmei kubelet ferskate kontener-runtime-omjouwings brûke kin. De CRI API is ynboud yn ferskate runtimes, sadat brûkers de runtime fan har kar kinne kieze.
Wat is CNI?
is in a om in universele netwurkoplossing te organisearjen foar Linux-konteners. Dêrneist befettet it , ferantwurdlik foar ferskate funksjes by it opsetten fan in podnetwurk. De CNI-plugin is in útfierber bestân dat foldocht oan de spesifikaasje (wy sille hjirûnder wat plugins beprate).
Tawizing fan subnetten oan knopen foar it tawizen fan IP-adressen oan pods
Om't elke pod yn in kluster in IP-adres moat hawwe, is it wichtich om te soargjen dat dit adres unyk is. Dit wurdt berikt troch it tawizen fan elk knooppunt in unyk subnet, wêrfan de pods op dat knooppunt dan IP-adressen wurde tawiisd.
Knooppunt IPAM Controller
Wannear nodeipam trochjûn as flaggeparameter --controllers , it allocates in apart subnet (podCIDR) oan elke knooppunt út it kluster CIDR (dat wol sizze, it berik fan IP-adressen foar it kluster netwurk). Sûnt dizze podCIDR's net oerlappe, wurdt it mooglik dat elke pod in unyk IP-adres wurdt tawiisd.
In Kubernetes-knooppunt wurdt in podCIDR tawiisd as it yn earste ynstânsje registrearre is by it kluster. Om de podCIDR fan knooppunten te feroarjen, moatte jo se deregistrearje en se dan opnij registrearje, wêrtroch passende feroarings yn 'e Kubernetes-kontrôlelaachkonfiguraasje tuskentroch meitsje. Jo kinne de podCIDR fan in knooppunt werjaan mei it folgjende kommando:
$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24
Kubelet, container runtime en CNI plugins: hoe't it allegear wurket
It plannen fan in pod per knooppunt omfettet in protte tariedende stappen. Yn dizze seksje sil ik my allinich rjochtsje op dyjingen dy't direkt relatearre binne oan it opsetten fan in podnetwurk.
It plannen fan in pod nei in bepaalde knooppunt triggert de folgjende keatling fan eveneminten:
Help: .
Ynteraksje tusken container runtime en CNI plugins
Elke netwurkprovider hat syn eigen CNI-plugin. De runtime fan 'e kontener rint it om it netwurk foar de pod te konfigurearjen as it opstart. Yn it gefal fan containerd wurdt de CNI-plugin lansearre troch de plugin .
Boppedat hat elke provider syn eigen agent. It is ynstalleare op alle Kubernetes-knooppunten en is ferantwurdlik foar de netwurkkonfiguraasje fan pods. Dizze agint is of opnommen mei de CNI-konfiguraasje of makket it selsstannich op it knooppunt. De konfiguraasje helpt it CRI-plugin yn te stellen hokker CNI-plugin te neamen.
De lokaasje fan 'e CNI-konfiguraasje kin oanpast wurde; standert is it yn /etc/cni/net.d/<config-file>. Klusterbehearders binne ek ferantwurdlik foar it ynstallearjen fan CNI-plugins op elke klusterknooppunt. Har lokaasje is ek oanpasber; standert map - /opt/cni/bin.
By it brûken fan containerd kinne de paden foar de plugin-konfiguraasje en binaries ynsteld wurde yn 'e seksje [plugins.«io.containerd.grpc.v1.cri».cni] в .
Om't wy Flannel brûke as ús netwurkprovider, litte wy in bytsje prate oer it ynstellen:
- Flanneld (Flannel's daemon) wurdt normaal ynstalleare yn in kluster as in DaemonSet mei
install-cnilykas . Install-cniskept (/etc/cni/net.d/10-flannel.conflist) op elke knooppunt.- Flanneld makket in vxlan-apparaat, hellet netwurkmetadata fan 'e API-tsjinner, en kontrolearret pod-updates. As se wurde makke, distribearret it rûtes nei alle pods troch it heule kluster.
- Dizze rûtes kinne pods mei-inoar kommunisearje fia IP-adressen.
Foar mear detaillearre ynformaasje oer it wurk fan Flannel advisearje ik de keppelings oan 'e ein fan it artikel te brûken.
Hjir is in diagram fan 'e ynteraksje tusken de Containerd CRI-plugin en de CNI-plugins:
Lykas jo hjirboppe kinne sjen, neamt de kubelet de Containerd CRI-plugin om de pod te meitsjen, dy't dan de CNI-plugin neamt om it netwurk fan 'e pod te konfigurearjen. Dêrby ropt de CNI-plugin fan 'e netwurkprovider oare kearn CNI-plugins op om ferskate aspekten fan it netwurk te konfigurearjen.
Ynteraksje tusken CNI plugins
D'r binne ferskate CNI-plugins waans taak is om te helpen netwurkkommunikaasje yn te stellen tusken konteners op 'e host. Dit artikel sil beprate trije fan harren.
CNI plugin Flanell
By it brûken fan Flannel as netwurkprovider ropt de Containerd CRI-komponint mei help fan de CNI konfiguraasje triem /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
}
}
]
}
De Flannel CNI plugin wurket yn gearhing mei Flanneld. Tidens it opstarten hellet Flanneld podCIDR en oare netwurk-relatearre details op fan 'e API-tsjinner en bewarret se yn in bestân /run/flannel/subnet.env.
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=false
De Flannel CNI-plugin brûkt gegevens fan /run/flannel/subnet.env om de CNI-brêgeplugin te konfigurearjen en te neamen.
CNI plugin Bridge
Dizze plugin wurdt neamd mei de folgjende konfiguraasje:
{
"name": "cni0",
"type": "bridge",
"mtu": 1450,
"ipMasq": false,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24"
}
}
Wannear't neamd foar de earste kear, it makket in Linux brêge mei «name»: «cni0», dat wurdt oanjûn yn de konfiguraasje. Dan wurdt in veth-paar makke foar elke pod. Ien ein dêrfan is ferbûn mei de netwurknammeromte fan 'e kontener, de oare is opnommen yn' e Linux-brêge op it hostnetwurk. ferbynt alle hostkonteners mei in Linux-brêge op it hostnetwurk.
Nei it ynstellen fan it veth-pear, neamt de Bridge-plugin de host-lokale IPAM CNI-plugin. It IPAM-plugintype kin konfigureare wurde yn 'e CNI-konfiguraasje dy't de CRI-plugin brûkt om de Flannel CNI-plugin te neamen.
Host-lokale IPAM CNI-plugins
Bridge CNI calls mei de folgjende konfiguraasje:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Host-lokale IPAM-plugin (IP Address Management - IP-adresbehear) jout it IP-adres foar de kontener werom fan it subnet en bewarret de tawiisde IP op 'e host yn' e map spesifisearre yn 'e seksje dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Dit bestân befettet de ID fan de kontener dêr't dit IP-adres oan is tawiisd.
By it oproppen fan de host-lokale IPAM-plugin, jout it de folgjende gegevens werom:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Gearfetting
Kube-controller-manager jout in podCIDR oan elke node. De pods fan elke node ûntfange IP-adressen fan 'e adresromte yn it tawiisde podCIDR-berik. Sûnt de podCIDR's fan 'e knopen net oerlappe, krije alle pods unike IP-adressen.
De Kubernetes-klusterbehearder konfigurearret en ynstallearret de kubelet, container runtime, netwurkprovider-agent, en kopiearret de CNI-plugins nei elke knooppunt. By it opstarten genereart de agint fan 'e netwurkprovider in CNI-konfiguraasje. As in pod is pland foar in knooppunt, ropt de kubelet de CRI-plugin op om it te meitsjen. Folgjende, as containerd wurdt brûkt, ropt de Containerd CRI-plugin de CNI-plugin op dy't spesifisearre is yn 'e CNI-konfiguraasje om it netwurk fan 'e pod te konfigurearjen. As resultaat krijt de pod in IP-adres.
It duorre my wat tiid om alle subtiliteiten en nuânses fan al dizze ynteraksjes te begripen. Ik hoopje dat dizze ûnderfining jo sil helpe better te begripen hoe't Kubernetes wurket. As ik bin ferkeard oer wat, nim dan kontakt mei my op of op it adres . Fiel jo frij om te berikken as jo aspekten fan dit artikel of wat oars wolle beprate. Ik soe graach petear mei dy!
referinsjes
Containers en netwurk
Hoe wurket Flannel?
CRI en CNI
PS fan oersetter
Lês ek op ús blog:
- «";
- "In yllustrearre gids foar netwurken yn Kubernetes": , ;
- «".
Boarne: www.habr.com