🥇Hogyan kap IP-címet a pod a Kubernetes-ben

Megjegyzés fordítás.: Ez a LinkedIn által írt cikk részletesen bemutatja a Kubernetes-ben rejlő "belső varázslatot" — pontosabban a CRI, CNI és a kube-apiserver interakcióját — ami történik, amikor egy pod-nak IP-címre van szüksége.

Az egyik alapvető követelmény a Kubernetes hálózati modelljében az, hogy minden pod-nak saját IP-címe legyen, és a clusterben bármely másik podnak képesnek kell lennie kapcsolódni ehhez a címhez. 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 kezdtem el dolgozni a Kubernetes-szel, nem volt világos számomra, hogyan kapják meg a pod-ok az IP-címüket. Még ha értettem is az egyes komponensek működését, nehéz volt elképzelni a közös munkájukat. Például tudtam, mire valók a CNI bővítmények, de nem értettem, hogyan hívják meg őket. Ezért úgy döntöttem, hogy írok erről a cikkről, hogy megosszam az ismereteimet a különböző hálózati komponensekről és azok együttműködéséről a Kubernetes klaszterben, amelyek lehetővé teszik, hogy minden pod saját egyedi IP-címet kapjon.

Különféle módjai léteznek a hálózati interakció szervezésének a Kubernetes-ben — hasonlóan ahhoz, ahogy különféle végrehajtási környezetek (runtime) állnak rendelkezésre a konténerek számára. Ebben a publikációban Flannel kerül felhasználásra a hálózat kialakításához a klaszterben, míg végrehajtási környezetként — Containerd. Azt is feltételezem, hogy tisztában van a konténerek közötti hálózati interakció működésével, ezért csak röviden fogom érinteni, kizárólag a kontextus kedvéért.

Néhány alapvető fogalom

Konténerek és hálózat: rövid áttekintés

Az interneten rengeteg nagyszerű publikáció található, amelyek elmagyarázzák, hogyan kapcsolódnak a konténerek egymáshoz hálózaton keresztül. Ezért csak egy általános áttekintést adok az alapvető fogalmakról, és egy megközelítésre korlátozom magam, amely Linux-híd létrehozását és a csomagok kapszulázását jelenti. A részleteket kihagyom, mivel a konténerek hálózati interakciójának témája külön cikket érdemel. Néhány különösen tartalmas és tanulságos publikáció linkjeit alább találja.

Konténerek egy hoston

Az IP-címek közötti kapcsolatok szervezésének egyik módja a Linux-híd létrehozása olyan konténerek esetében, amelyek egyazon hoszton futnak. Ehhez Kubernetesben (és Dockerben) virtuális eszközöket hoznak létre. veth (virtuális ethernet). A veth-eszköz egyik végpontja a konténer hálózati névtérhez csatlakozik, a másik pedig a Linux-hídhoz a gazda hálózatában.

Minden konténer egy hoszton egy veth végpontja a hídban van, amelyen keresztül IP-címeiken keresztül kommunikálhatnak egymással. A Linux-hídnak is van IP-címe, és ez szolgál a kimenő (egress) forgalom átjárójaként a podok számára, amelyek más csomópontok felé irányulnak.

Konténerek különböző hosztokon

A csomagok enkapszulációja az IP-címek közötti kapcsolatok létrehozásának egyik módja a különböző csomópontokon lévő konténerek között. A Flannel esetében ezt a lehetőséget a vxlan, amely "becsomagolja" az eredeti csomagot egy UDP-csomagba, majd elküldi a rendeltetési helyére.

A Kubernetes klaszterben a Flannel létrehoz egy vxlan eszközt és ennek megfelelően kiegészíti az útválasztási táblázatot minden csomóponton. Minden csomag, amely egy másik hoszton lévő konténer számára van szánva, áthalad a vxlan eszközön, és enkapszulálódik egy UDP-csomagba. A célállomáson a beágyazott csomagot kinyerik, majd átirányítják a megfelelő podhoz.

Megjegyzés: Ez csupán az egyik módja a konténerek közötti hálózati interakció megszervezésének.

Mi az a CRI?

CRI (Container Runtime Interface) — ez egy plugin, amely lehetővé teszi a kubelet számára, hogy különböző konténer-végrehajtási környezeteket használjon. A CRI API integrálva van különböző végrehajtási környezetekbe, ezért a felhasználók az igényeik szerint választhatják a runtime-ot.

Mi az a CNI?

A CNI projekt jelentése a specifikációt egy általános hálózati megoldás létrehozására Linux-conténerekhez. Ezenkívül magában foglalja a bővítmények, amelyek különböző funkciókért felelősek a pod hálózatának beállítása során. A CNI plugin egy végrehajtható fájl, amely megfelel a specifikációnak (néhány plugint alább megvitatunk).

Alhálózatok kiosztása a csomópontoknak a podok IP-címeinek hozzárendelésére

Mivel a klaszter minden podjának egyedi IP-címmel kell rendelkeznie, fontos megbizonyosodni arról, hogy ez a cím egyedi legyen. Ezt úgy érik el, hogy minden csomópontnak egyedi alhálózatot rendelnek, amelyből aztán a podok IP-címeit hozzárendelik.

A csomópont IPAM vezérlője

Amikor nodeipam paraméterként a --controllers kube-controller-managerhez kerül., minden egyes csomópont számára egy külön alhálózatot (podCIDR) rendel a klaszter CIDR-jéből (azaz a klaszter hálózatához tartozó IP-címek tartományából). Mivel ezek a podCIDR-ek nem fedik át egymást, lehetővé válik, hogy minden pod számára egyedi IP-címet rendeljünk.

A Kubernetes csomópont a podCIDR-t a klaszterbe való elsődleges regisztrációjának pillanatában kapja meg. A csomópontok podCIDR-jének megváltoztatásához le kell őket regisztrálni, majd újra regisztrálni, addig módosítva a Kubernetes vezérlő réteg konfigurációját. A csomópont podCIDR-jének lekérdezéséhez az alábbi parancs használható:

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

Kubelet, konténer-futtatási környezet és CNI pluginek: hogyan működik mindez?

A pod-nak egy csomópontra való ütemezése számos előkészítő lépéssel jár. Ebben a szakaszban csak azokra fogok összpontosítani, amelyek közvetlenül kapcsolódnak a pod hálózati beállításához.

A pod ütemezése egy adott csomópontra a következő eseményláncot indítja el:

Súgó: CRI plugin architektúra Containerd-hez.

A konténer-futtatási környezet és a CNI pluginek kölcsönhatása

Minden hálózati szolgáltatónak saját CNI pluginnal rendelkezik. A konténer-futtatási környezet elindítja ezt, hogy konfigurálja a hálózatot a pod számára annak indításakor. A containerd esetében a CNI plugin indulását a plugin kezeli. Containerd CRI.

Emellett minden szolgáltatónak van egy ügynöke. Ez minden Kubernetes csomóponton telepítve van, és felelős a podok hálózati beállításáért. Ez az ügynök vagy a CNI konfigurációval együtt érkezik, vagy egyedül létrehozza azt a csomóponton. A konfiguráció segít a CRI pluginnek meghatározni, hogy melyik CNI plugint kell meghívni.

A CNI konfiguráció elhelyezkedése beállítható; alapértelmezetten itt található: /etc/cni/net.d/<config-file>. A klaszter adminisztrátorai szintén felelősek a CNI pluginek telepítéséért a klaszter minden csomópontjára. Az elhelyezkedésük is beállítható; az alapértelmezett könyvtár: /opt/cni/bin.

A containerd használatakor a konfigurációs és bináris plugin elérési útját a [plugins."io.containerd.grpc.v1.cri".cni] be. containerd konfigurációs fájljában.

Mivel a Flannel-t használjuk hálózati szolgáltatóként, beszéljünk egy kicsit a beállításáról:

A Flanneld (a Flannel démonja) általában DaemonSet-ként kerül telepítésre a klaszterbe a install-cni mint init-konténerben.
Install-cni létrehozza a CNI konfigurációs fájlt (/etc/cni/net.d/10-flannel.conflist) minden csomóponton.
A Flanneld létrehozza az vxlan eszközt, kinyeri a hálózati metaadatokat az API szerverrel, és figyelemmel kíséri a podok frissítéseit. Ahogy új podok jönnek létre, terjeszti az útvonalakat az összes pod számára a klaszterben.
Ezek az útvonalak lehetővé teszik a podok közötti IP-cím szerinti kommunikációt.

A Flannel működésével kapcsolatos részletesebb információkért javaslom, hogy nézze meg a cikk végén található linkeket.

Íme a kapcsolatábra a Containerd CRI és a CNI pluginek között:

Amint azt a fentiekben látható, a kubelet meghívja a Containerd CRI plugint, hogy létrehozzon egy podot, ami már a CNI plugint hívja a pod hálózatának beállításához. E közben a CNI hálózati szolgáltató plugin más alapvető CNI pluginokat is hív, hogy beállítsa a hálózat különböző aspektusait.

Kölcsönhatás a CNI pluginek között

Különböző CNI pluginek léteznek, amelyek célja, hogy segítsenek beállítani a hálózati kommunikációt a konténerek között a gazdagépen. Ebben a cikkben háromról lesz szó.

CNI plugin Flannel

Ha Flannel-t használják mint hálózati szolgáltatót, a Containerd CRI összetevője meghívja CNI plugin Flannel, 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 CNI plugin Flannel együttműködik a Flannel-lel. A Flanneld indításakor kinyeri a podCIDR és más, a hálózathoz kapcsolódó részleteket az API szerverből, és azokat egy fájlba menti /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 CNI plugin Flannel az /run/flannel/subnet.env adatokat használja a bridge CNI plugin beállításához és meghívásához.

CNI plugin Bridge

Ezt a plugint 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"
  }
}

Első hívásakor létrehoz egy Linux hidat a „name”: „cni0”, amely a konfigurációban szerepel. Ezután minden egyes podhoz létrehoznak egy pár veth-t. Ezek egyik végén a konténer névtérbe csatlakozik, a másik végén a Linux híd a gazdagép hálózatában. CNI plugin Bridge összekapcsol minden konténert a gazdagép Linux hídjához a gazdagép hálózatában.

Miután befejeződött a veth pár beállítása, a Bridge plugin meghívja a gazdagéphez helyi (host-local) CNI plugin IPAM-ot. Az IPAM plugin típusát a CNI konfigurációban lehet beállítani, amelyet a CRI plugin használ a Flannel CNI plugin meghívásához.

Helyi, gazdagépre vonatkozó IPAM pluginek CNI

A Bridge CNI meghívja a gazdagéphez helyi IPAM CNI plugint 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 bővítmény (IP Acím Mkezelés — IP-címek kezelése) visszaadja az IP-címet a konténer számára a hálózati tartományból, és megőrzi a kiosztott IP-t a gazdagépen az alábbi szakaszban megadott könyvtárban dataDir — /var/lib/cni/networks/<network-name=cni0>/<ip>. Ebben a fájlban található a konténer azonosítója, amelyhez ez az IP-cím volt hozzárendelve.

A host-local IPAM bővítmény hívásakor a következő adatokat adja vissza:

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

Összefoglaló

A kube-controller-manager minden csomópontnak podCIDR-t rendel. A csomópontok pod-jai az IP-címeket a kijelölt podCIDR tartományból kapják. Mivel a podCIDR-ek a csomópontoknál nem fedik egymást, minden pod egyedi IP-címet kap.

A Kubernetes klaszter adminisztrátora beállítja és telepíti a kubelet-et, a konténer futtatási környezetét, a hálózati szolgáltató ügynökét, és másolja a CNI bővítményeket minden csomópont képernyőjére. Az ügynök indulásakor generálja a CNI konfigurációt. Amikor egy pod-ot terveznek egy csomópontra, a kubelet hívja a CRI bővítményt a létrehozásához. Ezután, ha a containerd-t használják, a Containerd CRI bővítmény hívja a CNI bővítményt, amely a CNI konfigurációban van megadva, a pod hálózatának beállításához. Ennek eredményeként a pod IP-címet kap.

Kicsit időt vett igénybe, hogy átlássam az összes interakció finomságait és árnyalatait. Remélem, hogy az így szerzett tapasztalat segít Önnek is jobban megérteni, hogyan működik a Kubernetes. Ha valamiben tévedek, kérjük, lépjen kapcsolatba velem a vagy a vagy az alábbi címen hello@ronaknathani.com. Ne habozzon kapcsolatba lépni, ha szeretné megbeszélni ennek a cikknek az aspektusait vagy bármi mást. Örömmel beszélgetek Önnel!