Cloud

Ma is egy Kubernetes témájú cikket hoztam. Legutóbb a Kubernetes belső kommunikációját írtam le. Amikor belekezdtem a Kubernetesről szóló cikksorozatba, arra vállalkoztam, hogy lépésről lépésre mutatom be, miért olyan meghatározó ez a technológia a modern felhő– és konténer­világban. A korábbi cikkekben már kitértünk arra, hogy hogyan épül fel a fürt, mi a szerepe az ütemezőnek, és miként alakul át a régi monolitikus alkalmazásmodell a mikro­szolgáltatások felé.

Most eljutottunk ahhoz a ponthoz, ahol a technológia legapróbb, mégis kritikus részletei – a kapszulák közötti kommunikáció és a hálózati plugin-ek – kerülnek reflektorfénybe. Ebben a részben azt járjuk körül, hogyan jut el egy kapszula (Pod) egyik pontból a másikba – akár ugyanazon a gépen, akár másik node-on -, milyen feladatokat lát el ilyenkor a CNI (Container Network Interface), és milyen hálózati modellek, trükkök és kihívások vannak a háttérben.

1. A Kubernetes hálózati elvárások

Mielőtt belemerülnénk a technikai megvalósításba, nézzük meg, mit is ígér a Kubernetes hálózati modellje – ezeknek az elvárásoknak kell megfelelnie bármely gyakorlati rendszernek:

• Minden kapszulának egyedi, fürt­szintű IP-címe kell legyen. Nem privát, izolált cím, hanem olyan, amit a teljes fürtben használni tudunk.
• Kapszulák között nincs NAT (Network Address Translation) — minden forgalom „mezei” IP-címekkel zajlik.
• Kapszulák, akár ugyanazon a node-on vannak, akár különböző node-okon, közvetlenül elérhetik egymást.
• A node-ok (gépek, amelyeken futnak a kapszulák) elérik a rajtuk lévő kapszulákat, és szükség szerint a node-ok is kommunikálnak a kapszulákkal.
• A hálózati házirendek (NetworkPolicy) használata révén szabályozható, hogy melyik kapszula kit érhet el (ingress, egress) – de ez már „magasabb” réteg, amit a plugin-eknek is támogatniuk kell.

Természetesen a Kubernetes felhasználók nem akarnak mindentkézzel konfigurálni – a hálózatnak „láthatatlannak” kell lennie: működnie kell a háttérben, megbízhatóan és automatikusan.

2. Hol kapcsolódik be a CNI – és mit csinál pontosan?

A CNI (Container Network Interface) nem egy konkrét hálózati eszköz, hanem egy szabvány (interfész) és hozzá tartozó könyvtárkészlet, amely arra szolgál, hogy különféle plugin-ek révén a Kubernetes node-ok (és rajtuk futó konténer-rendszerek) dinamikusan konfigurálhassák a hálózati környezetet.

A Kubernetes komponensei – elsősorban a kubelet, a konténer runtime (például containerd vagy CRI-O) és maga a CNI plugin-ek kódja -együtt dolgoznak, hogy amikor egy Pod-ot elindítanak vagy leállítanak, a hálózati környezet is ennek megfelelően jöjjön létre, módosuljon, vagy takarításra kerüljön.

A tipikus folyamat (ADD / DEL / CHECK műveletek) így néz ki:

1. A kubelet jelzi a konténer runtime-nak, hogy el szeretne indítani egy Pod-ot.
2. A runtime elindítja a konténereket a Pod alá.
3. Amikor a futtató környezet képes hálózati feladatokra, a kubelet meghívja a CNI plugint ADD parancssal.
4. A CNI plugin-ek végrehajtják a hálózati konfigurációt: létrehozzák a hálózati névteret (network namespace), hozzáadják a hálózati interfészt (pl. veth párok), beállítják az IP-címet (IPAM segítségével), útvonalakat, DNS-t/stb.
5. Ha később a Pod megszűnik, a CNI DEL parancssal takarítja ki az eszközöket (interfészek, címek)

Fontos, hogy a CNI plugin-ek láncolhatók is – azaz lehet egy fő plugin (pl. Calico, Cilium) mellett kiegészítő plugin-ek is, mint bandwidth, portmap, stb.

Például, ha szeretnénk szabályozni, hogy egy Pod mennyi sávszélességet kapjon be- vagy kimenő forgalomra, hozzá lehet adni a bandwidth plugint a CNI konfigurációhoz.

3. A gyakori hálózati modellek és plugin-ek

Az interfész-réteg (CNI) mögött olyan plugin-ek állnak, amelyek különféle hálózati megközelítéseket valósítanak meg. Íme néhány általános modell és példa kiemelt plugin-ekre:

3.1 Bridge / VETH alapú modell (klasszikus „local” modell)

Ez a legegyszerűbb forma: a node-on belül egy „bridge” jön létre, és a Pod interfészei (veth pár) rá vannak kötve erre a hídra. Így az adott node-on belül a kapszulák kommunikálhatnak. IP-címeket pl. host-local IPAM plugin biztosít.
Előnye, hogy egyszerű és jól átlátható; hátránya, hogy ha több node van, szükség van valamilyen router-re vagy overlay technikára, hogy a forgalom átjusson node és node között. (Ez a „bridge + route” vagy „bridge + overlay” modell)

3.2 Overlay hálózat (VXLAN, IP-in-IP, GRE stb.)

Amikor két node közötti forgalomnak „alagutaznia” kell, gyakran használják az overlay technológiákat. Ilyenkor a Pod-ok IP-címe egy virtuális hálózaton belül van (a „virtuális kontinens”), és a fizikai hálózaton csomagokat kapszulázzák (encapsulate), hogy átjussanak node-ról node-ra.
A népszerű overlay technikák között van VXLAN, IP-in-IP, GRE.
Például a Flannel alapértelmezett módban VXLAN-t használ.

3.3 Native routing / BGP alapú modell

Egy másik megközelítés az, hogy a pod IP-ket közvetlenül routoljuk a node-ok között, mint ha egy valódi IP-hálózat lenne, és nem használnánk kapszulázást. Ebben a modellben gyakran alkalmaznak BGP-t (Border Gateway Protocol) a route-propagációhoz.
A Calico például képes arra, hogy “unencapsulated” (vagy opcionálisan encapsulated) módon működjön BGP-vel — így a hálózat egyszerűbbé válhat, ha a fizikai hálózat is támogatja.

3.4 eBPF alapú megoldások

Az egyik legfrissebb trend, amelyet a Cilium képvisel, hogy a kernel mélyebb rétegeit használja (eBPF, XDP), és nagy sebességű, alacsony késleltetésű adatforgalmat tud nyújtani, miközben támogatja a hálózati szabályokat, L7-szűrést, szolgáltatásszintű policyket stb.
Érdekesség: Cilium képes akár helyettesíteni kube-proxy funkciókat is, hiszen a belső forgalom kezelését, load balancinget eBPF hash táblákkal végezheti.

3.5 Több CNI plugin együtt – Multus

Van helyzet, amikor egy kapszulának több hálózatra is szüksége van (például egy belső adatforgalmi háló és egy másik dedikált háló). Ezt teszi lehetővé a Multus, amellyel egy pod több hálózati interfésszel is rendelkezhet, és párhuzamos CNI plugin-eket lehet használni.

4. Gyakorlati példák és konfigurációk

Az előző cikkekhez mellékelt CNI konfigurációs fájl (bridge típusú) már bemutatott egy alapvető konfigurációt. Nézzünk most pár gyakorlati példát és jellemző paramétert:

{
 "cniVersion": "0.2.0",
 "name": "mynet",
 "type": "bridge",
 "bridge": "cni0",
 "isGateway": true,
 "ipMasq": true,
 "ipam": {
 "type": "host-local",
 "subnet": "10.22.0.0/16",
 "routes": [
 { "dst": "0.0.0.0/0" }
 ]
 }
}

Ebben:

• type: bridge → a hálózati modell híd alapú.
• bridge: cni0 → a híd nevét adjuk meg.
• isGateway: true → a híd viselkedhet úgy, hogy gateway funkciói is vannak (pl. forgalom továbbítása)
• ipMasq: true → IP-maszkálás engedélyezése
• Az ipam alatt a host-local plugin kiosztja a címet a megadott tartományból, és beállítja az útvonalakat.

Ha például szeretnénk porttérképezést (hostPort) – azaz, hogy a pod portjait a node portjaira visszük —, akkor a CNI konfigurációnak tartalmaznia kell egy portmap plugint és be kell állítani a capabilities: {"portMappings": true} mezőt.

Ugyanígy, a traffic shaping (sávszélesség-korlátozás) támogatásához hozzáadható a bandwidth plugin. Ezzel annotation-ökkel meg lehet mondani, hogy egy Pod mennyi be- és kimeneti sávszélességet használhat.

5. Kihívások és finomhangolási lehetőségek

Akár egy otthoni fejlesztői klasztert építesz, akár nagy méretű produkciós fürtöt, a hálózati re­szletek sokféle kihívást hoznak:

• Teljesítmény és overhead: Overlay technikák (kapszulázás) CPU- és hálózati overhead-et hoznak magukkal. Érdemes mérni, tesztelni, hogy az adott CNI plugin és beállítás hogyan viselkedik a tényleges terhelés alatt. (Egy friss tanulmány például különböző CNI-k teljesítményét vizsgálta edge környezetekben.)
• Skálázhatóság és routing: Nagy fürtökben a route-ok kezelése, a BGP vagy más dinamikus routing megoldások kezelése kritikus.
• Biztonság és izoláció: A hálózati pol­iciák (NetworkPolicy) biztosítják, hogy ne minden Pod hozzáférhető mindenhonnan. Ehhez a CNI pluginnak támogatnia kell a pol­iciarendszert.
• Plugin kompatibilitás és frissítések: Ha több plugin (pl. bandwidth, portmap) van láncban, gondoskodni kell arról, hogy verziók kompatibilisek legyenek, ne legyenek függőségi konfliktusok.
• IPv6 támogatás, dual-stack: Egyre több rendszer használ IPv6-ot, néha IPv4+IPv6 kombinációban. A CNI-nek és plugin-eknek is alkalmasnak kell lenniük erre.
• Szolgáltatások (Service) és load balancing integrációja: A Pod-Pod kommunikáció önmagában csak egy része az egész képnek — a szolgáltatásoknak stabil címet kell adni, belső load balancert kell biztosítani, és a node-port / ingress forgalmat is kezelni kell.

6. Összegzés és tanulságok

A Kubernetes hálózati alapjai, különösen a Pod-Pod kommunikáció és a CNI plugin-ek működése, kulcsfontosságúak ahhoz, hogy megbízható, skálázható és biztonságos fürtöket építsünk.

A CNI adott interfészeket biztosít ahhoz, hogy a Kubernetes komponensek (kubelet, runtime) együttműködhessenek a hálózati plugin-ekkel, és dinamikusan kezelhessék a hálózati erőforrásokat.

A hálózati plugin-ek (bridge, overlay, BGP / routing, eBPF) különféle kompromisszumokat kínálnak – választásuk függ a fürt méretétől, teljesítményigénytől, topológiától és a biztonsági elvárásoktól.