Nagyon sok cikken keresztül ismerkedtünk már meg a Kubernetes alapjaival, azzal, hogyan működik a fürt (cluster) és miként kommunikálnak egymással a kapszulák (pods).
Most azonban kicsit messzebbre tekintünk, a történelem és a technológia határára, ahol megszületett a modern konténeres világ egyik előfutára – az Apache Mesos.
Képzeljünk el egy korszakot, amikor a nagyvállalatok még kísérleteztek azzal, hogyan lehetne hatékonyan kihasználni a szervererőforrásokat, hogyan lehetne a számítási kapacitást „elosztani” több gép között. Ebben a világban született a Mesos – és ebből nőtt ki később a Kubernetes.
A Mesos nem volt más, mint egy korai próbálkozás arra, hogy egységes erőforrás-kezelést biztosítson több gép, több alkalmazás és több adatközpont között. A Kubernetes később hasonló célokat tűzött ki, de egészen más filozófiával.
Mi a közös a Mesos és a Kubernetes között?
Távolról nézve, a Kubernetes nem különbözik alapjaiban más klaszterkezelő rendszerektől. Mindkettőben megtaláljuk azokat az alapkomponenseket, amelyek nélkülözhetetlenek egy elosztott rendszerhez:
Központi vezérlő (control plane), amely API-n keresztül kommunikál és szabályozza a működést.
Ütemező (scheduler), amely meghatározza, hogy az egyes feladatok mely csomópontokon fussanak.
Tartós állapotkezelés (persistent state), amely megőrzi a klaszter konfigurációját és állapotát.
A különbségek azonban a részletekben rejlenek. A Mesos az állapot tárolására Apache ZooKeeper-t használ, míg a Kubernetes ugyanezt a szerepet az etcd nevű kulcs-érték alapú adatbázissal valósítja meg. Ez az apró különbség nagy hatással van a rendszer rugalmasságára és egyszerűségére.
Mesos architektúra röviden
A Mesos a Apache Software Foundation egyik korai projektje volt, amely a nagyvállalati adatközpontok hatékony kihasználására született. A rendszer két fő komponensre épül:
Mesos Master – a központi vezérlő egység, amely felügyeli a rendelkezésre álló erőforrásokat, kiosztja azokat, és kezeli az ütemezést.
Mesos Agent (korábban Slave) – a munkavégző csomópont, amely futtatja az alkalmazásokat vagy szolgáltatásokat.
A Mesos önmagában nem futtat alkalmazásokat, hanem más keretrendszereket (framework-eket) szolgál ki, mint például Marathon, Chronos vagy akár Hadoop. Ezek a keretrendszerek kommunikálnak a Mesos API-ján keresztül, és rajta keresztül ütemezik a feladatokat a klaszter gépeire.
Kubernetes: az új szemlélet
A Kubernetes ebből a modellből indult ki, de teljesen más irányba vitte tovább a koncepciót. Míg a Mesos inkább általános erőforrás-menedzsment rendszer volt, a Kubernetes alkalmazáscentrikus megközelítést választott. A célja az volt, hogy a fejlesztők és az üzemeltetők ne gépeket, hanem alkalmazásokat kezeljenek.
A Kubernetes minden eleme – a kapszulák (pods), szolgáltatások (services), vezérlők (controllers) – API-n keresztül vezérelhető, és ez a tiszta API-orientált szemlélet tette lehetővé az automatizálást, az önjavítást és a dinamikus skálázást.
Összegzés – két világ találkozása
Ha valaki ismeri az olyan rendszereket, mint az OpenStack vagy a CloudStack, az könnyen ráismer a közös vonásokra: mindegyik esetében van egy vezérlő komponens, vannak munkavégző egységek, és szükség van hálózatkezelésre, valamint állapotmegőrzésre. Ami igazán megkülönbözteti a Kubernetest a Mesostól, az a hibatűrés, az önfelfedezés, és a skálázhatóság természetes támogatása.
A Mesos megmutatta, hogyan lehet egy klaszter erőforrásait megosztani. A Kubernetes pedig megmutatta, hogyan lehet ugyanezt egyszerűen, biztonságosan és automatizáltan megvalósítani.
A technológiai fejlődés történetében ritkán látunk olyan folytonosságot, mint ami a Mesos és a Kubernetes között húzódik. Egyik a másik alapjait rakta le, és bár a Mesos ma már inkább a történelem része, hatása még mindig érezhető minden modern konténeres környezetben.
A Kubernetes nem forradalmat csinált – hanem evolúciót indított el.
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énervilá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 mikroszolgá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ürtszintű 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:
A kubelet jelzi a konténer runtime-nak, hogy el szeretne indítani egy Pod-ot.
A runtime elindítja a konténereket a Pod alá.
Amikor a futtató környezet képes hálózati feladatokra, a kubelet meghívja a CNI plugint ADD parancssal.
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.
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:
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 reszletek 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 policiák (NetworkPolicy) biztosítják, hogy ne minden Pod hozzáférhető mindenhonnan. Ehhez a CNI pluginnak támogatnia kell a policiarendszert.
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.
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:
Konténer-konténer kommunikáció ugyanazon kapszulán belül – ezt maga a kapszulázás oldja meg.
Kapszula-kapszula kommunikáció a fürt bármely csomópontján.
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.
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:
Ú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.
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.
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.
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.
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:
Kritikus komponensek migrálása
Tesztkörnyezetek kipróbálása
Monitorozás, visszajelzések gyűjtése
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.
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.
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.
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 Fargateegysé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!
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 MicrosoftAzure 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 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.
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),
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á.
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:
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.
Ú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.
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.
