Menu

k8s

kubernetes-pod-communication

Hogyan kommunikálnak egymással a Kubernetes kapszulák

, , , , , , ,

| Olvasási idő: 6 perc |

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.

kubernetes-network-illustration

Szolgáltatások és hálózat: a Kubernetes belső kommunikációja

, , , , , ,

| Olvasási idő: 3 perc |

Több hónapja olvashattok cikkeket a Kubernetesről, ahol megismerkedtünk a fürt felépítésével, és láttuk, hogyan működik együtt a vezérlősík és a munkavégző csomópontok. Olyan ez, mint amikor egy várost építünk: először megteremtjük az alapokat, majd egyre több részletet adunk hozzá. Most viszont elérkeztünk ahhoz a ponthoz, amikor a város lakói – a kapszulák – nemcsak magukban léteznek, hanem beszélniük is kell egymással.

A történet tehát itt válik igazán emberközelivé: hiába áll minden készen, ha nincs út, amin eljutunk a szomszédhoz, és hiába van házunk, ha nem tudjuk becsengetni a barátainkhoz. A Kubernetes világában ezeket az „utakat” és „kapukat” a hálózati beállítások és a szolgáltatások biztosítják.

A hálózat szerepe a Kubernetesben

A Kubernetes egyik legfontosabb alapelve, hogy a kapszula (pod) az alap számítási egység. Egy kapszula több konténert is tartalmazhat, és ezek mind azonos IP-címet osztanak meg. Hálózati szempontból tehát egy kapszula úgy viselkedik, mint egy önálló virtuális gép vagy fizikai szerver.

Ez azonban három kihívást hoz magával, amelyeket minden fürtnek meg kell oldania:

  1. Konténer-konténer kommunikáció ugyanazon kapszulán belül – ezt maga a kapszulázás oldja meg.
  2. Kapszula-kapszula kommunikáció a fürt bármely csomópontján.
  3. Külső forrás-kapszula kommunikáció, amelyet a szolgáltatások (Services) biztosítanak.

Fontos tudni, hogy a Kubernetes önmagában nem konfigurál hálózatot. A fürt üzemeltetőinek kell olyan hálózati megoldást biztosítaniuk (például CNI pluginnal), amely lehetővé teszi a kapszulák közötti közvetlen kommunikációt.

Szolgáltatások (Services) a Kubernetesben

A szolgáltatások célja, hogy stabil hálózati elérhetőséget nyújtsanak a kapszulák számára. Mivel a kapszulák dinamikusan jönnek létre és tűnhetnek el, az IP-címük is változhat. Egy szolgáltatás viszont állandó végpontot ad, amely mögé a kapszulák rendeződnek.

A legfontosabb típusok:

  • ClusterIP – alapértelmezett típus, amely csak a fürtön belül érhető el. Ezzel kapszula–kapszula kommunikációt tudunk megvalósítani.
  • NodePort – fix portot nyit minden csomóponton, amelyen keresztül kívülről elérhető a szolgáltatás.
  • LoadBalancer – felhőszolgáltatóknál használatos, ahol a külső terheléselosztót integrálja.
  • ExternalName – DNS alapú átirányítás külső szolgáltatásra.

Ezek segítségével biztosítható, hogy az alkalmazások belső és külső kliensei mindig megtalálják a működő példányokat, függetlenül attól, hogy a kapszulák IP-címe változik.

A pause container szerepe

Érdemes megemlíteni a pause konténert is, amely minden kapszulában jelen van – bár a felhasználó ezt közvetlenül nem látja. Feladata, hogy lefoglalja az IP-címet és biztosítsa a hálózati névteret, mielőtt a többi konténer elindul. Ez egy technikai részlet, de nélkülözhetetlen a kapszulák stabil működéséhez.

Kapcsolódás a külvilághoz

Amikor egy szolgáltatásnak a fürtön kívülről is elérhetőnek kell lennie, több megoldás létezik:

  • NodePort a legegyszerűbb, de kevésbé rugalmas megoldás.
  • Ingress vagy IngressController, amely HTTP(S) szintű szabályozást tesz lehetővé, és tipikusan terheléselosztással együtt használjuk.
  • Proxy megoldások, amelyek szintén irányíthatják a forgalmat.

Így lesz teljes a kép: a kapszulák egymással és a külvilággal is kommunikálhatnak, stabil, jól szabályozott csatornákon keresztül.

Összegzés

A Kubernetes világában a hálózat és a szolgáltatások jelentik azt az „érrendszert”, amely összeköti az életet adó szerveket. A kapszulák önmagukban csak sejtek, de a hálózat biztosítja az összhangot, a szolgáltatások pedig a megbízható híd szerepét töltik be a belső és külső világ között.

bitnami_image

Vége a Bitnami ingyenes képeknek: mit tehetünk most

, , , , , , , , , , , ,

| Olvasási idő: 5 perc |

Az elmúlt időszak eseményei olyanok, mint egy mese, ami váratlanul rémálommá vált. Képzeld el, hogy van egy kis kikötő, ahol a hajók évek óta ugyanazt a megbízható szállítótól kapják az alkatrészeket, ráadásul ingyen. A kapitányok megszokták, hogy mindig időben érkezik az utánpótlás, és minden zökkenőmentesen működik. Egy nap azonban a kikötőt átveszi egy új tulajdonos, aki közli: a régi, készleten lévő alkatrészek ugyan még elérhetők, de újak már nem lesznek, legalábbis nem ingyen.

A kapitányok előtt három út marad: átállnak az új, drágább rendszerre, saját megoldást keresnek, vagy alternatív kikötőt választanak.

Technológiailag ez a helyzet tükrözi, amit néhány napja a Bitnami Docker image-k kapcsán bejelentettek. Sok fejlesztői közösség számára hirtelen egy új realitással kell szembenézni – és most megnézzük együtt, mit is jelent ez a változás, és milyen lehetőségeink vannak.

Mi az a Bitnami?

A Bitnami egy régóta ismert projekt, amely célul tűzte ki, hogy nyílt forrású szoftvereket (pl. adatbázisokat, webkiszolgálókat, cache-rendszereket) „do‐it‐yourself” egyszerűségű csomagként kínáljon: konténerképek, Helm chartok, könnyű telepíthetőség. Évtizedeken át sok Kubernetes-projekt, fejlesztő és üzemeltető használta ki előre konfigurált Bitnami image-eket és chartokat, mivel ezek stabilan, dokumentáltan és viszonylag kevés törés mellett működtek.

A Bitnami projekt most a Broadcom portfóliójába tartozik (Broadcom a VMware-t vásárolta fel), és ennek kapcsán stratégiai átalakítást hajt végre a konténerkép-disztribúciójában.

Miért fontos ez a változás?

A Bitnami eddig szerepelt sok Kubernetes infrastruktúra alapvető építőköveként: telepíthető komponensek, megbízható konténerképek, és helm chartok, amelyek akadálymentesítették az alkalmazások bevezetését. Amikor ez a támogatás visszavonul, többféle technikai és gyakorlati kockázat jelenik meg:

  • A docker.io/bitnami publikus regisztrációs hely (ahonnan sok image eddig szabadon letölthető volt) a változások hatására mérséklődik, és sok verziós címke eltűnik.
  • Az eddigi képek átkerültek egy Bitnami Legacy (bitnamilegacy) regiszterbe, ahol nem kapnak több kiadást, frissítést, biztonsági javítást.
  • Egy új, Bitnami Secure Images (bitnamisecure) hivatalosan nem „közösségi” szolgáltatás, hanem vállalati előfizetéshez kötött, fizetős kínálat.
  • A publikus Helm chartok (az OCI manifestjeik) frissítése is szünetel: a forráskód továbbra is elérhető marad GitHub-on, de az automatikus képek, verziófrissítések nem mindig jönnek majd.
  • A végleges “központi” publikus Bitnami regiszter törlése 2025. szeptember 29-én volt.
  • A Bitnami Secure Images vállalati előfizetésként érhető el, ára a források szerint több ezer dollár havonta, jellemzően 6 000 USD/hó körüli szinten indul.

Mindez azt jelenti, hogy ha nem léptünk időben, a Kubernetes klaszterekben, CI/CD folyamatokban, frissítési és automatikus skálázási műveletek során hirtelen hibaüzenetekkel (például ImagePullBackOff, ErrImagePull) találkozhatunk, amikor a rendszer nem tudja letölteni a szükséges képeket.

Mit okozhat a Kubernetes alapú rendszerekben?

Ha nem készültünk fel:

  1. Új podok nem indulnak el – amikor a fürt új csomópontot indít vagy új replika szükséges, a rendszer letöltené a Bitnami image-t, de ha az már nem elérhető, hibát kapunk: ErrImagePull vagy ImagePullBackOff.
  2. Frissítés vagy skálázás meghiúsul – ha egy alkalmazást új verzióra frissítenénk, de a chartban vagy a konfigurációban Bitnami image hivatkozás van, akkor az update művelet elbukhat.
  3. Biztonsági elmaradások halmozódnak – a bitnamilegacy képek fagyottak: nem kapnak további biztonsági frissítést, így elavult, sérülékeny komponensek maradhatnak használatban.
  4. Rejtett függőségek okozta meglepetések – nemcsak közvetlen alkalmazásaink használhatják Bitnami képeket, hanem alcsomagok, segédkonténerek, init container-ek is, amelyek rejtetten hivatkozhatnak a bitnami regiszterre.
  5. CI/CD pipeline-ok hibái – ha build vagy teszt folyamat során Bitnami képet húzunk be (pl. adatbázis konténer, migrációs konténer), akkor az egész pipeline leállhat.

Összességében tehát egy jól működő rendszerben sok esetben „hallgatólagos” függőségek fognak megbukni, és váratlan leállások vagy hibák léphetnek fel.

Milyen lehetőségeink vannak a problémák megoldására?

Ahogy a halász a történetben új kikötőt vagy hajót választhat, nekünk is több stratégiánk van:

1. Átirányítás a Bitnami Legacy Registry (bitnamilegacy)

Ez a legegyszerűbb ideiglenes megoldás: módosítjuk a konfigurációkat (helm values, deployment spec) úgy, hogy a repository: bitnamilegacy/… formát használjuk, és tartsuk meg a jelenlegi címkéket, amíg át tudunk térni.


Előny: viszonylag kevés munkával elérhető átmeneti működés. Hátrány: ezek az image-ek nem kapnak új frissítéseket vagy biztonsági javításokat — idővel elavultak lesznek.

Ha ezt választjuk, erősen ajánlott saját privát regiszterbe tükrözni (mirror), hogy legalább ne függjünk harmadik féltől.

2. Használjuk a Bitnami Secure Images (BSI) szolgáltatást

A Bitnami bejelentette, hogy új, „secure”, hardened képek és Helm chartok szolgáltatása indul, amely verziókezelést, SBOM-ot, CVE-transzparenciát, és egyéb vállalati tulajdonságokat ad.
Ez a megoldás azonban jellemzően fizetős, és inkább vállalati környezetekben lesz értelmes választás.
Ha előfizetünk, akkor a képek és chartok publikusan már nem a bitnami regiszteren lesznek, hanem automatikus privát vagy dedikált OCI regisztereken.
A Bitnami beígérte, hogy a Secure Images kínálat kisebb, de biztonságosabb verziókat fog tartalmazni (distroless képek, kisebb támadási felület).

3. Teljes elszakadás a Bitnami képektől – alternatívák és saját build

Ez a leginkább javasolt hosszú távon: magunknak választunk más képeket (például hivatalos Docker képeket, más közösségi projektek képeit), vagy akár a Bitnami számára elérhető open source konténerforrásokból saját képeket építünk és menedzselünk.

  • A Bitnami-forráskódok (Dockerfile-ok, Helm chartok) továbbra is elérhetők GitHubon Apache 2 licenccel — tehát jogilag megengedett saját építésre.
  • Kiválaszthatunk megbízható, aktív közösségű alternatívákat (pl. hivatalos image-ek, distro-specifikus build-ek).
  • Szükség lehet az értékek és beállítások átalakítására, mert nem minden image viselkedik ugyanúgy, mint a korábbi Bitnami verziók.
  • Célszerű bevezetni folyamatos integrációs (CI) pipeline-ban a képek tesztelését, vulnerability scan-t, hogy újabb függőségi hibák ne csússzanak be.
  • Lépésként részleges migráció is szóba jöhet: először a kritikus komponenseket „lecsupaszított”, alternatív képekkel cserélni, majd haladni tovább.

4. Audit és függőségek feltérképezése

Mielőtt döntenénk, célszerű átfogó auditot végezni:

  • Kikeresni az összes konténerkép-hivatkozást (pl. grep bitnami a manifestekben).
  • Megszámolni azokat a fürtön belüli podokat, amelyek Bitnami képet használnak (pl. kubectl get pods -A -o json | jq … | grep bitnami)
  • Felmérni, mely komponensek kritikusak, melyek kevésbé veszélyeztetettek, hogy prioritásokat állíthassunk.
  • Tesztelni a migrált konfigurációkat staging környezetben, hogy ne érjen minket meglepetés élesben.

5. Fokozatos átállás, párhuzamos környezetek

Nem feltétlenül kell mindent egyszerre lecserélni. Lehet fokozatosan:

  1. Kritikus komponensek migrálása
  2. Tesztkörnyezetek kipróbálása
  3. Monitorozás, visszajelzések gyűjtése
  4. Végleges átállás

Ez csökkentheti a kockázatot, és lehetőséget ad arra, hogy közbe avatkozzunk, ha valami nem működik.

Összegzés

Ez jelentős változás a konténeres és Kubernetes-alapú rendszerek világában. Ha nem készültünk fel, akkor ImagePull hibák, skálázási problémák és biztonsági elmaradások várnak ránk.

A legbiztosabb megoldás hosszú távon az, ha függetlenedünk a Bitnami-tól: alternatív képeket használunk, saját építésű konténereket alkalmazunk, és megfelelő folyamatokat építünk be (audit, tesztelés, scanning). Addig is átmeneti megoldásként a Bitnami Legacy regiszter használata segíthet.

kubernetes_pod_network

Egy IP minden kapszulának – a Kubernetes hálózat

, , , , , ,

| Olvasási idő: 3 perc |

Korábbi cikkeimben már felépítettük a Kubernetes világának alapjait: beszéltünk a szerepéről a modern szoftverfejlesztésben, arról, hogyan támogatja a mikroszolgáltatásokat, és miként erősíti a digitális jelenlétet.

Most képzeld el, hogy ebben a világban sétálsz egy városban, ahol minden háznak (a kapszulának) van saját, egyedi címe (IP-je). Ezzel a címmel bárki rátalálhat, és eljuthat a megfelelő ajtóhoz. Olyan mint egy házszám, vagy GPS koordináta.

Hogyan működik ez a címkiosztás, és hogyan kapcsolódnak a kapszulák a külvilághoz? Erről szeretnék neked írni néhány gondolatot.

Kapszula és hálózati névtér

Egy Kubernetes kapszula (Pod) olyan, mintha több szoba lenne egy közös lakásban: minden konténer külön szobát kap, de ugyanazt a hálózati névteret (network namespace) osztják meg. Ez azt jelenti, hogy a kapszula minden konténere ugyanazzal az IP-címmel rendelkezik.

A háttérben egy különleges szereplő, a pause konténer gondoskodik arról, hogy a kapszula egy IP-címet kapjon.

  • A pause konténer önmagában nem futtat alkalmazást, de létrehozza a hálózati környezetet.
  • A kapszula többi konténere ebbe a környezetbe csatlakozik, így osztoznak az IP-címen és a hálózati interfészen.

Ez a megoldás egyszerűsíti a fejlesztők életét: nincs szükség külön IP-címek kiosztására minden konténerhez, és a belső kommunikáció is egyszerűbb.

Konténerek közti kommunikáció

Ha a kapszulán belüli konténerek egymással akarnak kommunikálni, több lehetőségük van:

  • használhatják a loopback interfészt (localhost),
  • írhatnak és olvashatnak közös fájlrendszerből,
  • vagy folyamatközi kommunikációval (IPC) üzenhetnek egymásnak.

Ez olyan, mintha egy lakásban élő családtagok néha egymáshoz szólnak, néha pedig egyszerűen cetlit hagynak a hűtőn.

A kapszulától a külvilágig: Service és NodePort

A fürtön belül minden kapszula elérhető a saját IP-címén, de a külvilág számára ez nem elegendő. Ahhoz, hogy egy külső felhasználó vagy rendszer is elérje a kapszulát, szükség van egy Service objektumra.

A legegyszerűbb típus a NodePort:

  • a Kubernetes egy magas sorszámú portot nyit meg a node-on (például 30000-32767 tartományban),
  • ezen a porton keresztül érkezik a forgalom a kapszulába,
  • a Service egy endpointot hoz létre, amely összeköti a kapszula IP-címét és a portját.

Ez biztosítja, hogy a hálózati csomagok a megfelelő konténerhez jussanak.

A hálózati forgalom útja

A NodePort és más szolgáltatások működésében kulcsszereplők a Kubernetes hálózati komponensei:

  • A kube-proxy figyeli a szolgáltatásokat, és gondoskodik arról, hogy a forgalom a megfelelő kapszulába jusson. Ehhez iptables vagy ipvs szabályokat használ.
  • Az iptables a Linux kernel beépített tűzfal- és forgalomirányító eszköze, amely szabályokkal határozza meg, hogyan kell kezelni a csomagokat.
  • Az ipvs (IP Virtual Server) modernebb, nagy teljesítményű forgalomirányítási megoldás, amely hatékonyabb load balancingot biztosít.
  • A kube-controller-manager pedig állandóan figyel (ún. watch loop-okkal), hogy ha változás történik – például új kapszula indul, vagy egy régi törlődik – a szolgáltatások és az endpointok mindig naprakészek legyenek.

Ez a háttérmunka szinte láthatatlan, de garantálja, hogy a felhasználó mindig eléri a szolgáltatást.

Miért fontos ez a modell?

Az „egy IP minden kapszulának” megközelítés egyszerre biztosít egyszerűséget és kiszámíthatóságot:

  • a fejlesztőknek nem kell bonyolult port mappingot kezelniük,
  • a hálózat minden kapszula esetében azonos módon viselkedik,
  • a skálázás, frissítés és hibaelhárítás is könnyebb.

Nem véletlen, hogy ez a modell vált iparági szabvánnyá: a Kubernetes a világ legnagyobb rendszereiben is megbízhatóan működik ezen az alapokon.

kubernetes-node

Csomópontok (node) szerepe a Kubernetes világában

, , , , , ,

| Olvasási idő: 2 perc |

Az elmúlt hónapokban többször írtam már a Kubernetes fejlődéséről, arról, hogyan vált a modern alkalmazásfejlesztés egyik legfontosabb alapkövévé. Szó esett a fürtök (cluster) működéséről, a kapszulák (pod) rugalmasságáról és arról, miként segíti a technológia a cégeket digitális jelenlétük megerősítésében. Most elérkeztünk egy újabb fejezethez: nézzük meg közelebbről, mi is az a csomópont (node), amely nélkül egy Kubernetes környezet nem létezhetne.

Képzeljünk el egy várost, ahol minden ház más-más feladatot lát el. Van, amelyikben ételt főznek, másutt ruhát készítenek, máshol pedig tudást gyűjtenek. A város lakói a központi tér körül gyűlnek össze, ahol szabályok szerint szervezik a közös életet. A Kubernetes világában ez a „város” a fürt, a „házak” pedig a csomópontok – mindegyikük a maga erőforrásaival és feladataival járul hozzá a közösség működéséhez.

Mi az a csomópont?

A csomópont (node) egy olyan API objektum, amely a fürt részeként jelenik meg. Gyakorlatilag egy gépet jelent – lehet fizikai szerver vagy virtuális gép –, amely futtatja a kapszulákat. A vezérlő sík (control plane) mindig Linux alapú, a munkavégző (worker) csomópontok azonban lehetnek akár Microsoft Windows Server rendszeren is.

Minden csomópontot csak akkor lehet bevonni a fürtbe, ha a szükséges szoftverek telepítve vannak rá, és képes kommunikálni az API szerverrel. Új csomópont hozzáadására például a kubeadm join parancs szolgál, míg a vezérlő síkot a kubeadm init segítségével hozhatjuk létre.

Mi történik, ha egy csomópont „eltűnik”?

A Kubernetes folyamatosan figyeli, hogy a csomópontok rendben működnek-e. Ha az API szerver öt percen át nem tud kommunikálni a csomóponton futó kubelet-tel, a rendszer automatikusan „nem elérhetőnek” jelöli azt. Ilyenkor a kapszulák kényszerített törlése helyett azok evakuálása történik, majd később, a kapcsolat helyreállásakor újra elérhetővé válnak.

Minden csomópont objektum a kube-node-lease névtérben található. Ha teljesen el akarunk távolítani egy csomópontot a fürtből, a folyamat kétlépcsős: először a kubectl delete node <node-név> paranccsal töröljük az API szerverből, majd a kubeadm reset segítségével kitisztítjuk a fürtspecifikus adatokat. Újrafelhasználás esetén még az iptables szabályokat is érdemes eltávolítani.

Hogyan figyelhetjük az erőforrásokat?

A kubectl describe node parancs részletes képet ad a csomópont aktuális állapotáról: láthatjuk a CPU és memória kapacitást, a futó kapszulákat, valamint a kért és limitált erőforrásokat. Ez a mindennapi üzemeltetés egyik kulcseszköze, hiszen segít a tervezésben és a problémák gyors diagnosztizálásában.

Összegzés
A csomópontok a Kubernetes fürt alapvető építőkövei. Nélkülük nem tudnának futni a kapszulák, és nem lenne értelmezhető maga a rendszer. A csomópontok biztosítják az erőforrásokat, és a vezérlő sík által meghatározott szabályok szerint működnek. Megértésük nélkülözhetetlen a Kubernetes működésének átlátásához.

kubernetes_architecture_teal

Kubernetes architektúra: egy kis ismétlés a továbbiak előtt

, , , , , ,

| Olvasási idő: 2 perc |

Sokat tudunk már a Kubernetes-ről a korábbi cikkek alapján. A következő cikkekben egy egész más világba szeretnélek elkaluzolni Titeket. És mielőtt ezt megtenném, ismételjünk kicsit. Ahhoz, hogy még jobban megértsük, hogyan működik ez a konténer-orchesztrációs rendszer, érdemes újra áttekinteni a legfontosabb építőelemeket.

Alapvető felépítés

Egy Kubernetes klaszter két fő részből áll:

  • vezérlősík (control plane): itt találhatók azok a komponensek, amelyek a teljes klasztert irányítják és a döntéseket hozzák.
  • munkacsomópontok (worker nodes): itt futnak ténylegesen a kapszulák, vagyis a felhasználói alkalmazások és szolgáltatások.

Egy kis ismétlés

Kube-apiserver

A kube-apiserver a központi kommunikációs csatorna. Minden komponens ezen keresztül lép kapcsolatba egymással. Ez biztosítja az API felületet, amelyen keresztül a felhasználók, az adminisztrátorok és a klaszteren belüli szolgáltatások utasításokat adhatnak.

etcd

A Kubernetes állapotát és konfigurációs adatait az etcd adatbázis tárolja. Ez egy kulcs-érték alapú, nagy megbízhatóságú adattár, amely csak a kube-apiserveren keresztül érhető el. Így garantált, hogy minden állapotváltozás központilag kerül kezelésre.

  • Az etcdctl parancssori eszközzel lehet közvetlenül lekérdezni az adatbázist, például a fürt aktuális állapotának ellenőrzésére.

Hálózat és cilium

A Kubernetes egyik kulcskérdése a hálózat. Minden kapszulának stabil hálózati azonosítóval kell rendelkeznie, és kommunikálnia kell más kapszulákkal vagy szolgáltatásokkal.

A cilium egy hálózati plugin, amely fejlett megoldásokat kínál a hálózati forgalom irányítására, szűrésére és megfigyelésére. Segítségével jobban átláthatóvá válik, hogyan működik a kapszulák közötti hálózati kapcsolat.

Miért fontos a komponensek megértése?

A Kubernetes erőssége abban rejlik, hogy a komplex rendszert modulokra bontja. A vezérlősík komponensei biztosítják a stabilitást, a munkacsomópontok pedig a kapszulák futtatásáért felelősek. A két réteg között a kube-apiserver a „híd”, amely mindent összeköt.

Aki megérti ezeket az alapokat, sokkal könnyebben tud:

  • hibát keresni és elhárítani,
  • teljesítményt optimalizálni,
  • új szolgáltatásokat telepíteni,
  • vagy akár saját kiegészítőket fejleszteni.

Összegzés

A Kubernetes architektúra központi eleme a kube-apiserver, amely minden kommunikációt koordinál, és az etcd, amely az állapot tárolását biztosítja. Ezek köré épül a teljes rendszer, amely kapszulák futtatására, skálázására és kezelésére szolgál. A komponensek megismerése nélkülözhetetlen ahhoz, hogy magabiztosan dolgozhassunk Kubernetes környezetben.

amazon-eks-featured-final

Kubernetes az AWS-ben? Ismerd meg az Amazon EKS erejét

, , , , , , , , , , , ,

| Olvasási idő: 4 perc |
  • Erőforrás típus: IaaS
  • Felhő szolgáltató: Amazon Web Services
  • Angol név: Elastic Kubernetes Service
  • Magyar név: Elastic Kubernetes Service
  • Rövidített név (ha van ilyen): EKS

Ma is egy Kubernetes-el foglalkozó cikket hoztam nektek. És ma is egy olyan Kubernetes szolgáltatást nézünk meg közelebbről, amely közben felhőszolgáltató specifikus is.

Azt már többször többféle módon is elmondtam, hogy a konténertechnológia forradalmasította a modern alkalmazásfejlesztést (a legismertebb konténertechnológiai megoldás a Docker): egyszerűbbé vált az alkalmazások csomagolása, szállítása és futtatása különböző környezetekben. Az Azure Kubernetes Service (AKS) ebbe a világba nyújt belépőt, méghozzá teljes mértékben menedzselt formában. A kezdők számára különösen előnyös, mert elrejti a komplexitás nagy részét, miközben erős kontrollt és rugalmasságot biztosít.

Az Amazon Elastic Kubernetes Service (EKS) egy menedzselt Kubernetes-szolgáltatás az AWS-en, amely lehetővé teszi a konténeres alkalmazások egyszerű futtatását, skálázását és biztonságos üzemeltetését. Ha modern alkalmazásokkal dolgozol, és szeretnéd kihasználni a Kubernetes nyújtotta rugalmasságot anélkül, hogy a fürtkezelés technikai részleteivel kellene foglalkoznod, az EKS ideális választás lehet.

Mi az Amazon EKS?

Az Amazon EKS a Kubernetes nyílt forráskódú rendszerét kínálja menedzselt formában. Ez azt jelenti, hogy az AWS üzemelteti a Kubernetes vezérlősíkját, így neked nem kell bajlódnod a vezérlősík (control plane) telepítésével, frissítésével, vagy a rendelkezésre állás biztosításával. Az EKS lehetővé teszi, hogy a megszokott kubectl parancsokkal és deklaratív YAML-fájlokkal dolgozz, miközben kihasználod az AWS infrastruktúra erejét.

EKS felépítése

Az EKS-ben két fő összetevővel találkozol:

  • Vezérlősík (control plane): Teljes mértékben az AWS kezeli. Automatikusan elérhető és hibatűrő.
  • Munkacsomópontok (worker nodes): Ezek az EC2 példányok (vagy Fargate egységek), amelyeken a kapszulák (pods) ténylegesen futnak.

Az EKS támogatja az EC2 alapú, Fargate alapú, vagy ezek kombinációjából álló fürtöket is, így választhatsz a teljes kontroll (EC2) vagy a szerver nélküli működés (Fargate) között.

EKS erősségei

  • Felügyelt Kubernetes: Nem kell telepítened vagy karbantartanod a Kubernetes vezérlő komponenseit.
  • Biztonság: Az AWS integráció lehetővé teszi az IAM-alapú hitelesítést és az egyéb biztonsági eszközök (pl. Secrets Manager, KMS) használatát.
  • Integráció más AWS szolgáltatásokkal: Könnyen összeköthető például az ELB-vel, CloudWatch-csal, vagy az IAM-mel.
  • Skálázhatóság: Használhatsz automatikus skálázást az EC2 Auto Scaling Group-ok vagy a Kubernetes Horizontal Pod Autoscaler révén.
  • Sztenderd Kubernetes: A nyílt forráskódú Kubernetes-t használja, így hordozhatóságot biztosít más környezetek felé is (pl. on-premise vagy más felhők).

EKS korlátai

  • Összetettebb kezdeti beállítás: A konfigurálás komplexebb lehet, mint más, egyszerűbb konténeres szolgáltatásoknál (pl. App Runner).
  • Költségek: Az EKS control plane külön díjat számol fel (ez nagyjából 70 EUR havonta), az EC2 példányok vagy Fargate egységek díján felül.
  • Tanulási idő: A Kubernetes alapjainak elsajátítása időt igényel, főként azok számára, akik most ismerkednek vele.

Mikor érdemes EKS-t használni?

Az EKS különösen akkor hasznos, ha:

  • Már Kubernetes-t használsz helyben vagy más felhőben, és szeretnél migrálni AWS-re.
  • Mikroszolgáltatás-alapú, skálázható és konténeresített alkalmazásokat futtatsz.
  • Fontos számodra a rugalmas, nyílt szabványokon alapuló infrastruktúra.
  • Nagyobb cégek számára, ahol a felhő más szolgáltatásait is ki tudja használni.

Felhasználási esetek

Tegyük fel, hogy egy SaaS alkalmazást építesz (egy több ezer felhasználót kiszolgáló webshop ahol blog is található), amelyet folyamatosan frissítened kell. Több mikroszolgáltatásból áll, ekkor az alábbiakat fogod mindenképpen használni: hitelesítés (felhasználói bejelentkezések), termékkatalógus, rendeléskezelés, hírlevelek, stb. Az EKS lehetővé teszi, hogy ezeket elkülönítve futtasd kapszulákban, frissítsd őket „rolling deployment”-el, és automatikusan skálázd a forgalom (terhelés) alapján. Közben mindezt úgy, hogy nem kell a Kubernetes fürtöd vezérlősíkját manuálisan karbantartanod.

Emellett azért is hasznos az EKS, mert az AWS többi szolgáltatásával együtt, bármilyen komplex és biztonságilag kifogástalan megoldást meg lehet vele valósítani. Például lehetővé válik az EKS integrálása a VMware Cloud on AWS-sel. Ezzel együtt használjuk az AWS DevOps eszközöket az alkalmazások modernizálásának felgyorsításához.

Ezzel csupán azt szerettem volna szemléltetni, hogy „felhőben bármi lehetséges”.

Milyen más Docker-alapú szolgáltatások érhetők el az AWS-ben?

Az AWS több más konténeres szolgáltatást is kínál, amelyekről részletesen külön cikkekben is olvashatsz:

  • Amazon ECS (Elastic Container Service): AWS-specifikus konténerorchesztrátor, egyszerűbb, mint Kubernetes.
  • AWS Fargate: Szerver nélküli konténer futtatási lehetőség, amelyet EKS-szel vagy ECS-sel kombinálhatsz.
  • Amazon App Runner: Egyszerű konténer-alapú webalkalmazás telepítés.
  • AWS Lambda (konténer támogatással): Rövid ideig futó funkciók konténer image-ből.
  • AWS Batch: Nagy számítási igényű kötegfeldolgozás konténerek segítségével.
  • Amazon Lightsail (konténer támogatással): Egyszerű, kezdőknek szánt konténeres alkalmazás hosztolás.

Összefoglalás

Az Amazon EKS azok számára ideális, akik Kubernetes-t szeretnének használni az AWS környezetében anélkül, hogy a vezérlősík üzemeltetésével bajlódnának. Robusztus, skálázható és integrálható megoldás, ugyanakkor komplexebb bevezetést igényel, mint más konténeres szolgáltatások. Ha hosszú távú, mikroszolgáltatás-alapú stratégiában gondolkodsz, az EKS megbízható alap lehet.

Ha most ismerkedsz a Kubernetes világával, az EKS tökéletes kiindulópont. Ne csak olvass róla – gyakorolj, építs, és lépj egy szinttel feljebb a felhőben!

A költségekkel okosan. 🙂

azure_aks_highlight

Konténerek kezelése egyszerűen: Bevezetés az Azure AKS-be

, , , , , , , , , , , ,

| Olvasási idő: 3 perc |
  • Erőforrás típus: IaaS
  • Felhő szolgáltató: Microsoft Azure
  • Angol név: Azure Kubernetes Service
  • Magyar név: Azure Kubernetes Service
  • Rövidített név (ha van ilyen): AKS

Az elmúlt hetekben rengeteg Kubernetes-el foglalkozó cikket zúdítottam már rátok. Ez nem fog változni a közeljövőben sem, azonban ma egy olyan Kubernetes szolgáltatást nézünk meg közelebbről, amely közben felhőszolgáltató specifikus is.

Azt már többször többféle módon is elmondtam, hogy a konténertechnológia forradalmasította a modern alkalmazásfejlesztést (a legismertebb konténertechnológiai megoldás a Docker): egyszerűbbé vált az alkalmazások csomagolása, szállítása és futtatása különböző környezetekben. Az Azure Kubernetes Service (AKS) ebbe a világba nyújt belépőt, méghozzá teljes mértékben menedzselt formában. A kezdők számára különösen előnyös, mert elrejti a komplexitás nagy részét, miközben erős kontrollt és rugalmasságot biztosít.

Mi az az Azure AKS?
Az Azure Kubernetes Service (AKS) a Microsoft Azure felhőplatformjának menedzselt Kubernetes-szolgáltatása. Lehetővé teszi konténerizált alkalmazások automatikus üzembe helyezését, kezelését, skálázását és monitorozását anélkül, hogy külön kellene gondoskodni a Kubernetes-fürt (cluster) telepítéséről és karbantartásáról.

Miért előnyös az AKS használata?

  • Menedzselt vezérlőréteg
    A Kubernetes vezérlőelemeit (control plane) teljesen menedzseli az Azure – így ezek frissítése, méretezése és biztonsági javítása nem a fejlesztőcsapat feladata.
  • Automatikus skálázás
    Támogatja a vízszintes pod-autoskalázást (HPA), node pool szintű autoskalázást, valamint a manualis skálázást is.
  • Integráció az Azure ökoszisztémával
    Könnyen integrálható más Azure szolgáltatásokkal, például Azure Monitor, Log Analytics, Key Vault, EntraID (Azure AD), vagy az Application Gateway-vel.
  • Támogatás Windows és Linux node poolokra
    Lehetőség van hibrid környezetek létrehozására is, ahol egyes szolgáltatások Windows, mások Linux konténerként futnak.
  • RBAC és identitáskezelés
    Az Azure AD integráció segítségével szabályozhatjuk, ki mit tehet a fürtben (Role-Based Access Control).
  • Frissítési stratégia testreszabása
    A cluster frissítések tervezetten, lépésenként is végrehajthatók, hogy minimalizáljuk a leállást.

Korlátok, amikkel érdemes számolni

  • Control Plane testreszabhatósága korlátozott
    Mivel menedzselt szolgáltatás, bizonyos alacsony szintű beállításokhoz nincs hozzáférés.
  • Sokféle beállítási lehetőség, ami összezavarhatja a kezdőket
    Bár a vezérlőréteg menedzselt, a node poolok, hálózatkezelés, tárolók és jogosultságok konfigurálása összetett lehet.
  • Hosszabb indulási idő
    A node poolok indulása néhány perctől akár 10-15 percig is eltarthat, főleg ha új skálázást kérünk.

Mikor érdemes az AKS-t választani?
Az AKS ideális választás, ha:

  • Több mikroalkalmazást futtatnál egységes környezetben
  • DevOps pipeline-t szeretnél kiépíteni CI/CD-vel
  • Folyamatosan skálázódó alkalmazásokat futtatsz
  • Hosszú távon Kubernetes-es megközelítést szeretnél alkalmazni

Felhasználási példa: Webalkalmazás CI/CD pipeline-nal
Egy több részből álló webalkalmazás (pl. frontend, backend, adatbázis) konténerizált formában van tárolva. Az alkalmazás képfájlai pedig az Azure Container Registry-ben (ACR).

Az AKS lehetővé teszi ezen konténerek fürtbe szervezését. GitHub Actions vagy Azure DevOps használatával CI/CD pipeline-t építhetünk, amely automatikusan telepíti és frissíti az alkalmazás egyes komponenseit a Kubernetes-fürtbe.

A forgalmat Azure Application Gateway vagy Ingress Controller segítségével lehet terelni, míg a logokat Azure Monitorban gyűjthetjük.

Milyen más Azure szolgáltatások támogatják még a Docker-konténereket?
Bár az AKS a legteljesebb konténerkezelési megoldás, az Azure több más konténeres megoldást is kínál, amelyekről külön cikkekben olvashatsz:

  • Azure Container Instances (ACI): Egyszerűbb, rövid életű konténerekhez ideális
  • Azure Container Apps: Serverless konténer platform KEDA és Dapr támogatással
  • Azure App Service for Containers: Webalkalmazások konténerizált verziója
  • Azure Functions with custom containers: Egyedi konténeres serverless megoldások
  • Azure Spring Apps: Spring Boot alkalmazások futtatása konténerekben
  • Azure Dev Spaces (megszűnt): Fejlesztői környezet AKS-en belül
  • Azure Arc-enabled Kubernetes: Saját Kubernetes-fürtök Azure-ból való menedzsmentje

Összefoglalás
Az Azure Kubernetes Service (AKS) ideális választás azok számára, akik szeretnének skálázható, rugalmas, mikroszolgáltatás-alapú architektúrát kialakítani konténerek használatával, anélkül hogy a Kubernetes teljes komplexitásával kellene nap mint nap megküzdeniük. Az AKS lehetőséget ad a fejlődésre: kezdőként is elkezdhetjük, de haladó szintig is skálázhatjuk tudásunkat benne.

Azt azért megjegyezném, hogy egy AKS cluster fenntartása és üzemeltetése nem olcsó mulattság. Mielőtt kipróbálod, – márpedig ki kell próbálnod – ellenőrizd a díjkalkulátor segítségével, hogy mennyibe kerülne.

kubernetes-pod-concept

Kapszulák, konténerek és indulási sorrend a Kubernetes-ben

, , , , , , , ,

| Olvasási idő: 4 perc |

A Kubernetes az egyik legnépszerűbb konténer-orchesztrációs megoldás, amelyet világszerte alkalmaznak modern, skálázható és megbízható rendszerek építéséhez. A Kubernetes működésének alapját a kapszula (angolul: Pod) fogalma adja. Ez a legkisebb olyan egység, amelyet a Kubernetes kezelni tud.

Habár, mielőtt a K8s világába csöppennénk először a konténerek világával szoktunk megismerkedni. Ezen belül is a Docker szokott az első lépés lenni. Ha Te ez neked is ismerős, akkor furcsa lehet, hogy ott konténereket (angolul: container) kezelünk. Itt mégis a kapszulákat említünk.

Tehát itt nem magával a konténerrel dolgozunk közvetlenül, hanem ezzel a „kapszulázott” egységgel. Ma arról szeretnék nektek írni, hogyan működnek a kapszulák, hogyan épülnek fel, hogyan indulnak el, és hogyan segítik az init konténerek és a sidecar minták a stabil működést.

Mi az a kapszula (Pod)?

A kapszula egy vagy több konténerből áll, amelyeket egy logikai egységként kezelünk. Ezek a konténerek:

  • osztoznak ugyanazon IP-címen, amit a Kubernetes hozzárendelt a kapszulához,
  • közös tárolókat használhatnak (pl. emptyDir típusú ideiglenes fájlrendszer),
  • együtt futnak ugyanazon a csomóponton (node-on).

A kapszula úgy képzelhető el, mint egy konténercsoport, amely egy folyamat (pl. webalkalmazás) futtatására jött létre, és amelynek egyes részei (pl. naplózó eszköz) ugyanabban a környezetben futnak.

Egy vagy több konténer egy kapszulában?

A legtöbb esetben egy kapszula = egy alkalmazáskonténer. Ez a tiszta és egyszerű megközelítés jól működik. Azonban vannak olyan helyzetek, amikor egy kapszulán belül több konténerre van szükség:

  • Segédkonténer (sidecar): naplózáshoz vagy proxy-záshoz
  • Adapter konténer: régi interfészek kiszolgálására
  • Ambassador konténer: más szolgáltatások eléréséhez

Ezek a konténerek együttesen működnek, megosztják az erőforrásokat, és logikailag egy egységet képeznek. Fontos: nem különleges típusú konténerek ezek – a “sidecar” vagy “adapter” kifejezés csak szerepet jelöl, nem technikai különbséget. Tehát minden konténer ugyanúgy épül fel, csupán más szerepkört szánunk neki.

Indítási sorrend és problémák

A Kubernetes úgy lett tervezve, hogy a kapszulán belüli konténereket párhuzamosan indítsa el. Ez teljesen rendben van, ha az egyes konténerek nem függenek egymástól. De mi történik, ha egyik konténernek előbb készen kell állnia a másik előtt?

Példa:

  • Egy adatbázist csak akkor akarunk használni, ha már elérhető és inicializálva van.
  • Egy webalkalmazás csak akkor indulhat, ha a konfigurációs fájlok már betöltődtek.

Erre nyújt megoldást az init konténer.

Init konténerek: előkészítés garantált sorrenddel

Az init konténer egy olyan konténer, amely a fő alkalmazáskonténerek előtt indul el, és csak akkor indul tovább a többi konténer, ha az init konténer sikeresen befejezte a feladatát.

Tulajdonságai:

  • Teljesen független a fő konténerektől
  • Saját képpel és jogosultságokkal rendelkezhet
  • Ha hibásan fut, a fő konténerek nem indulnak el
  • Addig ismétlődik az indítás, amíg sikeresen le nem fut

Ez lehetővé teszi például, hogy:

  • megvárjuk egy adatbázis elérhetőségét,
  • végrehajtsunk fájlműveleteket vagy jogosultság-módosításokat, amelyekhez az alkalmazáskonténer nem fér hozzá.

Példa YAML definíció:

 containers:
 - name: main-app
 image: databaseD
 initContainers:
 - name: wait-database
 image: busybox
 command: ['sh', '-c', 'until ls /db/dir ; do sleep 5; done;']

Ebben az esetben a fő alkalmazáskonténer csak akkor indul el, ha a /db/dir mappa elérhető. Ugye milyen hasznos ez?

Erőforrás-korlátozás kapszulán belül

A Kubernetes lehetőséget ad arra, hogy minden konténer számára meghatározzuk, mekkora erőforrást kérhet és használhat:

resources:
 limits:
 cpu: "1"
 memory: "4Gi"
 requests:
 cpu: "0.5"
 memory: "500Mi"
  • A requests érték az a minimális erőforrás, amit a konténer igényel.
  • A limits érték az a maximum, amit a konténer fogyaszthat.

Ezeket az értékeket a kapszula leírásánál kell megadni, és a Kubernetes ennek megfelelően ütemezi be a kapszulát a fürt egyik csomópontjára.

ResourceQuota: névtér szintű korlátok

Ha azt szeretnénk, hogy a különböző felhasználók vagy csapatok ne lépjék túl az erőforráskeretüket, használhatunk ResourceQuota objektumokat:

  • Korlátozható a CPU, memória, podok, szolgáltatások, tárolók száma stb.
  • A scopeSelector mezővel például prioritás alapján is szabályozhatjuk a pod futtatását

Ez segít a fürt egészének stabil működésében, és megelőzi, hogy valaki túl sok erőforrást foglaljon le véletlenül vagy szándékosan.

Mit kezdjünk régi, monolitikus alkalmazásokkal?

Sok szervezetnél felmerül a kérdés: hogyan helyezzük át a régi (monolitikus) alkalmazásokat Kubernetes környezetbe?

Két megközelítés van:

  1. Konténerizálás, ahogy van – az alkalmazás teljes egészében bekerül egy kapszulába, minimális módosítással. Gyorsabb és olcsóbb megoldás, de korlátozott rugalmasságot ad.
  2. Újratervezés mikroszolgáltatásként – az alkalmazás komponenseit különálló kapszulákba és szolgáltatásokba bontjuk, hogy teljes mértékben kihasználjuk a Kubernetes előnyeit. Idő- és erőforrás-igényesebb, de jövőállóbb.

Egy egyszerű hasonlat:

  • A monolitikus alkalmazás olyan, mint egy városi busz: mindent egyszerre visz, de nem túl rugalmas.
  • A mikroszolgáltatás-alapú rendszer olyan, mint egy robogóflotta (pl.: Lime): kicsi, gyors, önállóan mozog, de jól kell koordinálni.

Összefoglalás

A Kubernetes kapszulái olyan, mint a konténerek futtatásának biztonságos és jól szabályozható “csomagolása”. Az init konténerek lehetőséget adnak a folyamatok sorrendjének kézben tartására, a sidecar konténerek pedig kiterjesztik az alkalmazás funkcionalitását. A precíz erőforráskezelés (limits, quota) elengedhetetlen a fürt stabil működéséhez.

Végezetül: ha régi alkalmazást szeretnél Kubernetes-be hozni, gondold át, mit nyersz a mikroszolgáltatás-alapú újratervezéssel, és hol elég a meglévő alkalmazás konténerizálása.

Ha elakadsz, akkor keress engem és segítek.

kubernetes-kubelet-operators-service

A K8s kulcsszereplői: Kubelet, Operátorok és Szolgáltatások

, , , , , , , , ,

| Olvasási idő: 3 perc |

Az elmúlt néhány alkalommal a Kubernetes architekturális felépítéséről olvashattál. Beszéltünk a Contol Plane-ről és a Worker Node-okról. Most tovább folytatjuk utazásunkat ezen a területen.

A Kubernetes működésének megértéséhez fontos, hogy ismerjük azokat az alapvető komponenseket, amelyek a rendszer „láthatatlan motorjai”. Ebben a cikkben három ilyen kulcsszereplőt mutatok be: a kubeletet, az operátorokat és a szolgáltatásokat. Ezek együttműködése biztosítja, hogy a konténeralapú alkalmazások megbízhatóan és skálázhatóan fussanak a fürtben (cluster).

Kubelet: a node-ok gondnoka

A kubelet a worker node-okon futó ügynök, amelynek feladata, hogy végrehajtsa a fürt vezérlőkomponenseitől érkező utasításokat. Minden egyes node-on található egy példány belőle.

A kubelet főbb feladatai:

  • PodSpec értelmezése: Minden kapszula (pod) egy specifikáció (PodSpec) alapján jön létre. A kubelet ezt dolgozza fel, és biztosítja, hogy a node elérje a kívánt állapotot.
  • Hozzáférés biztosítása a kötetekhez, titkokhoz és konfigurációkhoz: Ha a kapszula igényel persistent storage-ot, Secret-et vagy ConfigMap-et, a kubelet intézi ezek elérhetőségét.
  • Konténer indítás: Az utasításokat továbbítja a helyi konténerfuttató motor (pl. containerd vagy CRI-O) felé.
  • Állapotjelentés: Folyamatosan visszajelzést küld a kube-apiservernek a kapszulák és a node állapotáról.
  • Erőforrás-kezelés: Egyes fejlettebb funkciók, mint például a NUMA-topológiára érzékeny CPU vagy gyorsító hardver hozzárendelés, a Topology Manager segítségével történik.

Operátorok: az automatizált felügyelők

Az operátorok – más néven kontrollerek vagy figyelő ciklusok (watch-loops) – a Kubernetes szíve-lelke. Ezek felelősek azért, hogy a fürt állapota megfeleljen a kívánt állapotnak. Minden operátor egy adott erőforrást (például Pod, Namespace, ServiceAccount) kezel.

Hogyan működnek?

  • Informer és cache: Az operátor egy úgynevezett Informer komponensen keresztül kérdezi le az API szervertől az erőforrás aktuális állapotát. Az adatokat cache-eli, hogy minimalizálja az API hívások számát.
  • DeltaFIFO: A módosításokat egy DeltaFIFO nevű sorban kezeli, és a változások (delták) alapján dönt, hogy mi a teendő.
  • Feldolgozás: Az operátor logikája alapján végrehajtja a szükséges lépéseket (például új kapszula létrehozása vagy meglévő módosítása).
  • Workqueue: A különböző feladatokat munkamenet-sorokon keresztül osztja szét a háttérfolyamatok között, amelyek kezelik az eseményeket.

Példák beépített operátorokra:

  • Endpoints operator: Kezeli a kapszulák elérési pontjait.
  • Deployments: A replikakészleteket (ReplicaSet) vezérli, amelyek azonos PodSpec alapján több kapszulát indítanak.

Szolgáltatás operátor: a hálózati kapcsolatok kapuőre

A Kubernetesben a kapszulák IP címei múlékonyak, így egy állandó elérési mód biztosítására van szükség. Ezt a szolgáltatások (Services) biztosítják, amelyek mögött egy speciális operátor – a szolgáltatás operátor – áll.

Feladatai:

  • Tartós IP-cím biztosítása: A szolgáltatás egy stabil IP-címet biztosít a mögöttes kapszulákhoz, még akkor is, ha a kapszulák újraindulnak vagy kicserélődnek.
  • Kapszulák összekapcsolása: A szolgáltatás operátor figyeli az endpoint operátort, hogy naprakész legyen abban, mely kapszulák tartoznak a szolgáltatáshoz.
  • Kommunikáció a hálózattal: Az operátor a kube-apiserveren keresztül eljuttatja a szükséges beállításokat a kube-proxy-nak és a használt hálózati pluginnak (pl. Cilium).
  • Hozzáférési szabályok kezelése: Meghatározza, hogy kik és milyen módon érhetik el a szolgáltatás mögött álló kapszulákat. Ez nemcsak a forgalomirányítás, hanem a biztonság szempontjából is fontos.

Összegzés

A Kubernetes belső működése több komponens összehangolt munkáján alapul. A kubelet biztosítja, hogy a node-ok megfeleljenek az elvárt állapotnak. Az operátorok figyelik a rendszer változásait, és aktívan fenntartják az erőforrások kívánt konfigurációját. A szolgáltatás operátor pedig lehetővé teszi, hogy a kapszulák hálózaton keresztül is stabilan és biztonságosan elérhetők legyenek.

E három komponens együttműködése biztosítja a Kubernetes megbízhatóságát, rugalmasságát és önjavító képességét – ezek teszik lehetővé, hogy a modern felhőalapú alkalmazások skálázhatóan és hibatűrő módon működjenek.

Load More