Jegyzet. ford.: Ez a cikk, amelyet a LinkedIn SRE mérnöke írt, részletesen bemutatja a Kubernetes belső varázslatát - pontosabban a CRI, a CNI és a kube-apiserver interakcióját -, amely akkor történik, amikor a következő podhoz IP-címet kell hozzárendelni.
Az egyik alapkövetelmény az, hogy minden podnak saját IP-címmel kell rendelkeznie, és a fürt bármely más podjának képesnek kell lennie arra, hogy ezen a címen kapcsolatba lépjen vele. Számos hálózati „szolgáltató” (Flannel, Calico, Canal stb.) segíti ennek a hálózati modellnek a megvalósítását.
Amikor először elkezdtem dolgozni a Kubernetes-szel, nem volt teljesen világos számomra, hogy a podok pontosan hogyan kapják meg az IP-címüket. Még az egyes összetevők működésének megértése ellenére is nehéz volt elképzelni, hogy együtt dolgoznak. Például tudtam, hogy mire valók a CNI-bővítmények, de fogalmam sem volt, hogy pontosan hogyan hívják őket. Ezért úgy döntöttem, hogy megírom ezt a cikket, hogy megosszam a tudást a különböző hálózati összetevőkről és arról, hogyan működnek együtt egy Kubernetes-fürtben, amely lehetővé teszi, hogy minden egyes pod saját egyedi IP-címet kapjon.
A Kubernetesben különböző módokon szervezheti meg a hálózatépítést, csakúgy, mint a konténereknél különböző futásidejű beállításokat. Ez a kiadvány fogja használni hálózatot fürtbe szervezni és végrehajtható környezetként - . Azt is feltételezem, hogy tudja, hogyan működik a konténerek közötti hálózatépítés, ezért csak röviden érintem, csak a kontextus kedvéért.
Néhány alapfogalom
A konténerek és a hálózat: rövid áttekintés
Rengeteg kiváló publikáció található az interneten, amelyek elmagyarázzák, hogyan kommunikálnak egymással a konténerek a hálózaton keresztül. Ezért csak általános áttekintést adok az alapfogalmakról, és egy megközelítésre szorítkozom, amely magában foglalja a Linux-híd létrehozását és a csomagok beágyazását. A részletek kimaradnak, hiszen maga a konténerhálózat témája külön cikket érdemel. Az alábbiakban néhány különösen tanulságos és tanulságos kiadvány linkjei találhatók.
Konténerek egy gépen
Az ugyanazon a gazdagépen futó konténerek közötti IP-címeken keresztüli kommunikáció megszervezésének egyik módja egy Linux-híd létrehozása. Ebből a célból virtuális eszközöket hoznak létre a Kubernetesben (és a Dockerben) . A veth-eszköz egyik vége a tároló hálózati névteréhez csatlakozik, a másik vége pedig a tároló hálózati névteréhez a gazdagép hálózaton.
Az ugyanazon a gazdagépen lévő összes konténernek az egyik vége egy hídhoz kapcsolódik, amelyen keresztül IP-címeken keresztül kommunikálhatnak egymással. A Linux-hídnak IP-címe is van, és átjáróként működik a többi csomópontnak szánt podokból érkező kimenő forgalom számára.
Konténerek különböző hostokon
A csomagcsomagolás az egyik olyan módszer, amely lehetővé teszi, hogy a különböző csomópontokon lévő konténerek IP-címek használatával kommunikáljanak egymással. A Flanelnél a technológia a felelős ezért a lehetőségért. , amely az eredeti csomagot egy UDP-csomagba „csomagolja”, majd elküldi a rendeltetési helyére.
A Kubernetes-fürtben a Flannel létrehoz egy vxlan-eszközt, és ennek megfelelően frissíti az útvonaltáblázatot az egyes csomópontokon. Minden egyes csomag, amelyet egy másik gazdagépen lévő tárolóhoz rendelt, áthalad a vxlan eszközön, és egy UDP-csomagba van beépítve. A célhelyen a beágyazott csomagot kibontják és továbbítják a kívánt podba.
Megjegyzés: Ez csak az egyik módja a tárolók közötti hálózati kommunikáció megszervezésének.
Mi az a CRI?
egy bővítmény, amely lehetővé teszi a kubelet számára, hogy különböző konténer-futási környezeteket használjon. A CRI API különböző futási időkbe van beépítve, így a felhasználók kiválaszthatják a tetszőleges futási időt.
Mi az a CNI?
a hogy univerzális hálózati megoldást szervezzenek Linux konténerekhez. Ezen kívül tartalmazza , különböző funkciókért felelős a pod hálózat beállításakor. A CNI beépülő modul egy futtatható fájl, amely megfelel a specifikációnak (a továbbiakban néhány beépülő modult tárgyalunk).
Alhálózatok csomópontokhoz való hozzárendelése IP-címek podokhoz való hozzárendeléséhez
Mivel a fürt minden egyes podjának rendelkeznie kell IP-címmel, fontos, hogy ez a cím egyedi legyen. Ez úgy érhető el, hogy minden csomóponthoz egyedi alhálózatot rendelnek, amelyből az adott csomóponton lévő pod-ok IP-címeket kapnak.
Node IPAM vezérlő
Mikor nodeipam zászlóparaméterként átadva --controllers , külön alhálózatot (podCIDR) rendel a fürt CIDR minden egyes csomópontjához (azaz a fürthálózat IP-címeinek tartományához). Mivel ezek a podCIDR-ek nem fedik át egymást, lehetővé válik, hogy minden pod egyedi IP-címet kapjon.
Egy Kubernetes-csomópont hozzá van rendelve egy podCIDR-hez, amikor először regisztrálják a fürtben. A csomópontok podCIDR-jének módosításához törölnie kell a regisztrációjukat, majd újra kell regisztrálnia őket, és közben végre kell hajtania a megfelelő módosításokat a Kubernetes vezérlőréteg konfigurációjában. Egy csomópont podCIDR-jét a következő paranccsal jelenítheti meg:
$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24
Kubelet, konténer futtatókörnyezet és CNI-bővítmények: mindez hogyan működik
A pod csomópontonkénti ütemezése sok előkészítő lépést tartalmaz. Ebben a részben csak azokra koncentrálok, amelyek közvetlenül kapcsolódnak a pod hálózat beállításához.
Egy pod ütemezése egy bizonyos csomóponthoz a következő eseményláncot váltja ki:
FAQ: .
Interakció a tároló futásidejű és a CNI beépülő modulok között
Minden hálózati szolgáltatónak saját CNI-bővítménye van. A tároló futtatókörnyezete futtatja, hogy konfigurálja a hálózatot a podhoz az induláskor. Containd esetén a CNI plugint a plugin indítja el .
Ezenkívül minden szolgáltatónak saját ügynöke van. Az összes Kubernetes-csomópontra telepítve van, és felelős a podok hálózati konfigurációjáért. Ez az ügynök vagy benne van a CNI-konfigurációban, vagy önállóan hozza létre a csomóponton. A konfiguráció segít a CRI beépülő modulnak beállítani, hogy melyik CNI beépülő modult hívja meg.
A CNI konfiguráció helye testreszabható; alapértelmezés szerint benne van /etc/cni/net.d/<config-file>. A fürtrendszergazdák felelősek a CNI-bővítmények telepítéséért is az egyes fürtcsomópontokon. Helyük is személyre szabható; alapértelmezett könyvtár - /opt/cni/bin.
A konténer használatakor a beépülő modul konfigurációjának és a bináris fájloknak az elérési útjait a szakaszban lehet beállítani [plugins.«io.containerd.grpc.v1.cri».cni] в .
Mivel a Flannelt használjuk hálózati szolgáltatóként, beszéljünk egy kicsit a beállításáról:
- A Flaneld (Flannel démonja) általában egy fürtbe telepítve DaemonSet-ként
install-cnimint . Install-cniteremt (/etc/cni/net.d/10-flannel.conflist) minden csomóponton.- Flaneld létrehoz egy vxlan eszközt, lekéri a hálózati metaadatokat az API szerverről, és figyeli a pod frissítéseket. Létrehozásukkor az útvonalakat szétosztja a fürt összes podjához.
- Ezek az útvonalak lehetővé teszik, hogy a pod-ok IP-címeken keresztül kommunikáljanak egymással.
A Flanel munkájával kapcsolatos részletesebb információkért javaslom a cikk végén található hivatkozások használatát.
Íme egy diagram a Containerd CRI beépülő modul és a CNI beépülő modulok közötti interakcióról:
Mint fentebb látható, a kubelet meghívja a Containerd CRI beépülő modult a pod létrehozásához, amely ezután meghívja a CNI beépülő modult a pod hálózatának konfigurálásához. Ennek során a hálózati szolgáltató CNI-bővítménye más alapvető CNI-bővítményeket hív meg a hálózat különböző aspektusainak konfigurálásához.
Kölcsönhatás a CNI-bővítmények között
Különféle CNI-bővítmények vannak, amelyek feladata, hogy segítsenek beállítani a hálózati kommunikációt a gazdagépen lévő tárolók között. Ez a cikk három közülük lesz szó.
CNI plugin Flanel
Ha a Flannelt hálózati szolgáltatóként használja, a Containerd CRI komponens hív a CNI konfigurációs fájl használatával /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
}
}
]
}
A Flanel CNI beépülő modul a Flanelddel együtt működik. Indítás közben a Flaneld lekéri a podCIDR-t és más hálózattal kapcsolatos részleteket az API-kiszolgálóról, és elmenti őket egy fájlba. /run/flannel/subnet.env.
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=false
A Flanel CNI beépülő modul a következőtől származó adatokat használja fel /run/flannel/subnet.env a CNI bridge beépülő modul konfigurálásához és meghívásához.
CNI plugin Bridge
Ezt a bővítményt a következő konfigurációval hívják meg:
{
"name": "cni0",
"type": "bridge",
"mtu": 1450,
"ipMasq": false,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24"
}
}
Amikor először hívják, Linux hidat hoz létre «name»: «cni0», amely a konfigurációban látható. Ezután minden hüvelyhez létrejön egy veth pár. Az egyik vége a konténer hálózati névteréhez csatlakozik, a másik a gazdahálózat Linux-hídjában található. az összes gazdagép-tárolót egy Linux-hídhoz köti a gazdagép hálózaton.
A veth pár beállítását követően a Bridge beépülő modul meghívja a host-local IPAM CNI beépülő modult. Az IPAM beépülő modul típusa konfigurálható abban a CNI konfigurációban, amelyet a CRI beépülő modul a Flanel CNI beépülő modul meghívására használ.
Host-helyi IPAM CNI beépülő modulok
Bridge CNI hívások a következő konfigurációval:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Host-local IPAM beépülő modul (IP AC í m Management - IP-címkezelés) visszaadja a konténer IP-címét az alhálózatról, és eltárolja a lefoglalt IP-t a gazdagépen a szakaszban megadott könyvtárban dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Ez a fájl tartalmazza annak a tárolónak az azonosítóját, amelyhez ez az IP-cím hozzá van rendelve.
A host-local IPAM beépülő modul meghívásakor a következő adatokat adja vissza:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Összegzés
A Kube-controller-manager minden csomóponthoz egy podCIDR-t rendel. Az egyes csomópontok IP-címeket kapnak a lefoglalt podCIDR-tartomány címteréből. Mivel a csomópontok podCIDR-jei nem fedik át egymást, minden pod egyedi IP-címet kap.
A Kubernetes-fürt adminisztrátora konfigurálja és telepíti a kubeletet, a tároló futtatókörnyezetét, a hálózati szolgáltatói ügynököt, és minden csomópontra másolja a CNI-bővítményeket. Az indítás során a hálózati szolgáltató ügynöke létrehoz egy CNI-konfigurációt. Amikor egy pod egy csomóponthoz van ütemezve, a kubelet meghívja a CRI beépülő modult a létrehozásához. Ezután a Containerd CRI beépülő modul meghívja a CNI-konfigurációban megadott CNI-bővítményt, ha a konténer használatát használja, hogy konfigurálja a pod hálózatát. Ennek eredményeként a pod kap egy IP-címet.
Kellett egy kis idő, hogy megértsem az összes kölcsönhatás finomságát és árnyalatait. Remélem, ez a tapasztalat segít jobban megérteni a Kubernetes működését. Ha bármiben tévedek, kérem, vegye fel velem a kapcsolatot a telefonszámon vagy a címen . Nyugodtan forduljon hozzánk, ha szeretné megvitatni a cikk szempontjait vagy bármi mást. Szívesen csevegnék veled!
referenciák
Konténerek és hálózat
Hogyan működik a flanel?
CRI és CNI
PS a fordítótól
Olvassa el blogunkon is:
- «";
- "Illusztrált útmutató a Kubernetes hálózatépítéshez": , ;
- «".
Forrás: will.com