Senki sem szereti a rendetlenséget. Akkor sem, ha nem vagyunk rendmániások. Valahol mindannyiunknak szüksége van arra a fajta belső nyugalomra, amit az ad, hogy a dolgok a helyükön vannak. Egy rendezett tér nem csak esztétikai kérdés: segít tisztábban gondolkodni, könnyebben eligazodni, és biztonságérzetet ad a mindennapokban.
Nincs ez másképp a Kubernetes cluster esetében sem. Amikor egyre több alkalmazást, podot, service-t és konfigurációt indítunk el, hamar rájövünk, hogy a rendszer saját “lakói” is igénylik a strukturáltságot. A Kubernetes pedig erre egy elegáns, mégis egyszerű megoldást kínál: a namespace-eket, amelyek láthatatlanul, de nagyon is hatékonyan teremtik meg azt a rendezettséget, amelyre egy növekvő clusternek szüksége van.
Mi az a namespace?
A Kubernetesben a namespace egy logikai szeparációs mechanizmus, amely csoportokra bontja a cluster erőforrásait. A fogalom eredetileg a Linux kernel világából származik: ott is az izoláció a cél, vagyis hogy különböző folyamatok saját, elkülönített erőforrás-nézetet kapjanak.
A Kubernetes ezt továbbgondolja: a namespace nem csupán technikai elszeparálás, hanem egy szervezési, erőforrás-kontroll és biztonsági keret is.
Lényeg:
Minden API-hívás egy namespace-en belül történik, hacsak nem adunk meg külön mást. Például: https://<api-server>/api/v1/namespaces/default/pods
A namespace lehetővé teszi a kvóták és limitációk alkalmazását egy adott csoport erőforrásaira.
Később az access control – például RBAC – is működhet namespace-szinten.
Ha csak néhány erőforrás van a clusterben, akkor a szükségessége nem mindig látszik. De nagyobb vállalati környezetben a namespace az egyik legfontosabb szervezési eszköz.
A Kubernetes alapértelmezett namespace-ei
Amikor egy új clustert létrehozunk, Kubernetes négy namespace-t hoz létre automatikusan. Ezek előre definiált szerepet töltenek be, és fontos, hogy ismerjük őket.
default
Az alapértelmezett namespace. Ha nem adunk meg explicit namespace-t egy API-hívásban vagy egy YAML-ben, minden ide kerül.
kube-system
Itt futnak a rendszer- és infrastruktúra szintű komponensek. Maga a Kubernetes működéséhez szükséges podok találhatók itt, például a DNS, a kontrollerek, scheduler stb.
kube-public
Ez egy mindenki számára olvasható namespace (még hitelesítetlen felhasználók számára is). Tipikusan olyan információkat tartalmaz, amelyeknek publikusnak kell lenniük.
kube-node-lease
Ez tárolja a node-ok „lease” objektumait. A control plane ezzel követi a node egészségi állapotát, gyorsabban és hatékonyabban, mint korábban.
Hogyan dolgozunk namespace-ekkel?
A namespace-ek egy része kimondottan szervezési célokat szolgál: a fejlesztői, tesztelési és éles környezet könnyen elkülöníthető, de akár csapatonként, projektenként vagy üzleti funkcióként is létrehozhatunk új namespace-eket.
A legfontosabb alapműveletek:
Meglévő namespace-ek listázása
kubectl get ns
Új namespace létrehozása
kubectl create ns sajat-projekt
Namespace részletes leírása
Megmutatja többek között a címkéket, annotációkat, kvótákat, limiteket.
kubectl describe ns sajat-projekt
Namespace tartalmának YAML formátumú lekérése
kubectl get ns/sajat-projekt -o yaml
Namespace törlése
kubectl delete ns sajat-projekt
Namespace használata YAML fájlokban
Ha egy erőforrást szeretnénk egy konkrét namespace-ben létrehozni, azt a metadata blokkban kell megadni:
apiVersion: v1
kind: Pod
metadata:
name: redis
namespace: sajat-projekt
Ez a mindennapi Kubernetes fejlesztés egyik alapja: a pod encapsulation, a resource isolation és a cluster szervezése így lesz konzisztens, rendezett és biztonságos.
pod encapsulation: A „pod-beágyazás” azt jelenti, hogy a Kubernetes egyetlen kezelhető egységbe, az úgynevezett Podba foglal egy vagy több szorosan együttműködő konténert, a közösen használt tárolót és hálózati erőforrásokat. Ez lehetővé teszi, hogy konténerek egységes egészként működjenek: közösen használják az olyan erőforrásokat, mint a tároló vagy a hálózat, miközben a rendszer egy csomóponton (node) együtt ütemezi és kezeli őket. Ez a megközelítés jelentősen leegyszerűsíti az alkalmazások telepítését és skálázását.
Mikor érdemes namespace-t használni?
A namespace akkor segít igazán, ha:
több csapat dolgozik ugyanabban a clusterben,
több környezetet szeretnénk egymástól elszeparálni (dev, test, staging, prod),
erőforráskvótákat kell alkalmazni (CPU, memória, storage),
korlátozni akarjuk az erőforrások láthatóságát vagy módosíthatóságát,
Kisebb clusterben nem mindig tűnik létkérdésnek, de hosszú távon a namespace az egyik legfontosabb szervezési eszköz, ami segít megelőzni a káoszt.
Összegzés
A namespace látszólag egy apró részlet a Kubernetesben, mégis az egész ökoszisztéma egyik legfontosabb alapköve. Rendet teremt, felelősségi köröket választ szét, erőforrásokat szabályoz, és előkészíti a terepet a biztonságos, skálázható működéshez.
Ahogy tovább haladunk a Kubernetes mélyebb rétegei felé, újabb olyan elemeket fogunk megismerni, amelyek pontosan ilyen csendben, mégis hatalmas erővel segítik a fejlesztőket, üzemeltetőket és szervezeteket abban, hogy a microservice-ek világában stabil rendszereket építsenek.
Amikor legutóbb a Kubernetes API-ról mint „a kommunikáció idegrendszeréről” írtam, sok visszajelzést kaptam arról, mennyire segített érthetővé tenni a fürt működését. Most innen folytatjuk a történetet. Az előző cikkben is sok mindent megmutattam, hogy érthetőbbé tegyem a cluster belső működését, és most megvizsgáljuk, hogyan zajlik valójában az információáramlás a Kubernetes belső világában.
Ennek a cikknek a célja, hogy az API működésének gyakorlati oldalát mutassa be: hogyan jelenik meg mindez a legegyszerűbb kapszula létrehozásánál, mit csinál a kubectl valójában a háttérben, hogyan lehet a klaszteren kívülről hozzáférni az API-szerverhez, és mire szolgál a mindenki által használt ~/.kube/config fájl.
A Kubernetesben minden objektum, minden módosítás, minden lekérdezés API-hívások sorozata. Ha értjük ezt a réteget, a rendszer teljes működése világossá válik.
1. A kapszula mint API-objektum: a legkisebb egység
Az előző cikkben már beszéltünk arról, hogy a kapszula a Kubernetes legkisebb futtatási egysége. Az alábbi példa egy minimális, mégis rendkívül tanulságos kapszula-definíciót mutat be:
Ez a néhány sor már minden lényeges elemet tartalmaz:
apiVersion – melyik API-csoportot használja az objektum;
kind – az erőforrás típusa (Pod);
metadata – az objektum azonosító adatai;
spec – a kapszulában futó konténerek és paramétereik.
A létrehozás és lekérdezés mind API-hívások sorozatán keresztül történik:
kubectl create -f elsopod.yaml
kubectl get pods
kubectl get pod elsopod -o yaml
kubectl get pod elsopod -o json
A külvilág számára ezek egyszerű parancsoknak tűnnek, de valójában a kubectl az API-szerverhez küld lekérdezéseket és módosítási kéréseket.
2. Hogyan kommunikál valójában a kubectl?
A Kubernetes minden erőforrást RESTful API-n keresztül kezel. Ez azt jelenti, hogy a kubectl működése valójában nem más, mint HTTP-hívások generálása az API-szerver felé – tipikusan JSON formátumú kommunikációval.
Ha szeretnénk még többet megtudni arról, mit csinál a kubectl a háttérben, akkor kapcsoljuk be a részletes – verbose – naplózást:
a két fél között TLS-sel védett HTTP-forgalom zajlik.
Ez a tudás fontos, mert így értjük meg igazán, mi történik akkor, amikor mi „csak” egy új kapszulát hozunk létre vagy lekérjük a futó erőforrásokat.
3. Hozzáférés a Kuberneteshez a klaszteren kívülről
A legtöbb adminisztrációs feladat a kubectl használatával történik, de akár közvetlenül curl-lel is kommunikálhatnánk a Kubernetes API-szerverével. A gond csak az, hogy ehhez hitelesített, TLS-sel védett kapcsolat kell. És mit kell tudni a klaszterhez tartozó API-król?
A klaszter API végpontjának adatai a kubectl config view kimenetében találhatók.
A kliens a hitelesítési adatokat a ~/.kube/config fájlból olvassa ki.
E nélkül a fájl nélkül a hozzáférés legfeljebb korlátozott, „insecure” módon lehetséges, amellyel a legtöbb művelet nem érhető el.
Ezért mondjuk, hogy a kubeconfig a hozzáférés kulcsa: nélküle a klaszter elérhetetlen lenne.
4. A kubeconfig felépítése és jelentése
A ~/.kube/config fájl a Kuberneteshez való hozzáférés központi eleme. A benne található adatok határozzák meg:
melyik klaszterhez csatlakozunk,
milyen felhasználó nevében tesszük ezt,
milyen hitelesítési adatokat használunk,
és milyen kontextusban fut a kubectl.
A kubeconfig több fő részből áll, amelyek együtt írják le a kapcsolat minden aspektusát. Egy alap struktúra így néz ki:
Ahogy minden Kubernetes-objektumnál, itt is meg kell határozni, hogy a fájl melyik API-verzió szerint értelmezendő. A kubeconfig esetében ez tipikusan v1.
clusters
A klaszter(ek) eléréséhez szükséges adatok:
server – az API-szerver címe, amelyhez a kubectl csatlakozik;
certificate-authority-data – a CA tanúsítvány, amely biztosítja, hogy a kliens a megfelelő API-szerverhez kapcsolódjon, és a kapcsolat hiteles legyen.
Ezek alapján a kubectl tudja, hová küldje a kéréseit.
users
Itt találhatók a kliens hitelesítési adatai. Tipikusan:
kliensoldali tanúsítvány,
privát kulcs,
vagy token.
A Kubernetes ebben a részben tárolja, hogy a felhasználó milyen módon igazolja magát a klaszter felé.
contexts
A context egy hármas kapcsolat:
melyik klasztert használjuk,
melyik felhasználó nevében,
és milyen alapbeállításokkal (pl. namespace).
Ez teszi lehetővé, hogy ugyanarról a gépről több klaszterrel is dolgozhassunk, akár eltérő jogosultságokkal.
current-context
Ez mondja meg, hogy a kubectl éppen melyik contextet használja alapértelmezésként. Ha nem adunk meg külön kapcsolót minden parancsnál, akkor ez a context érvényesül.
preferences
Ritkán használt beállítások, például megjelenítési opciók. A legtöbb esetben üres marad.
5. Miért fontos mindezt érteni?
A kubeconfig nem csupán technikai részlet: a Kubernetes működésének egyik kulcsdarabja. Ez határozza meg, hogy:
melyik klaszterrel kommunikálsz,
milyen jogosultsággal,
milyen biztonsági réteg alatt.
Ha a kubeconfigot érted, akkor magabiztosan tudsz klaszterek között váltani, hibákat diagnosztizálni, saját API-hívásokat küldeni, vagy akár több környezetet is kezelni ugyanazon a gépen.
A történet pedig itt még nem ér véget – a Kubernetes mélyebb rétegei csak most kezdenek igazán érdekessé válni.
A felhős monitoring az egyik legösszetettebb terület az Azure-ben. Rengeteg szolgáltatás, beállítás, rövidítés és „best practice” kering körülötte, miközben a legtöbb ember csak azt szeretné tudni: látom-e, mi történik a virtuális gépemen; és ha több virtuális gépem van, tudom-e azok naplóbejegyzéseit egy helyen kezelni.
Nemrég az egyik mentoráltammal belekóstoltunk ebbe a világba. Ő kifejezetten rákapott a monitoring ízére, ami jó jel, viszont közben számomra is világossá vált, hogy nem a tankönyv szerinti megoldás a legjobb megközelítés ahhoz, hogy valóban megértsük ennek a világnak a működését.
Miért mondom ezt? Mert sokan úgy gondolják – és én is így mutattam be korábban –, hogy akkor kell beállítani a naplófájlok gyűjtését, amikor a virtuális gépet létrehozzuk. Hiszen amikor összetett rendszerekkel dolgozunk, általában egy előre beállított, finomhangolt monitoring rendszerbe illesztjük be az új gépeket.
Ezzel azonban pont azt a logikus, jól követhető utat kerülöm el, amelyen keresztül az érdeklődők a legkönnyebben elérik a céljukat: hogy gyorsan átlássák ezt a komplex világot.
Mit javaslok tehát? Kövessük a józan észt, és gondoljuk végig, mi egy alkalmazás vagy rendszer természetes evolúciója. Hogyan történik ez a valóságban, amikor kicsiben kezdünk?
Először létrehozok egy vagy több virtuális gépet, alapbeállításokkal, majd telepítem rájuk az alkalmazásaimat. Jön még egy gép, aztán még egy. Egy idő után azt veszem észre, hogy egy nagy, összetett rendszerem van, viszont vak vagyok: nem látom, mi történik a virtuális gépeimen, és nem látom a gépek által létrehozott naplóbejegyzéseket sem.
Ekkor jön a következő lépés: beállítom az Azure Monitor megoldását, hogy legyen szemem és fülem. És innentől már értelmezhető adatokat kapok arról, mi történik a rendszeremben.
Ugye milyen egyszerű így?
Ebben a cikkben erről – pontosabban ennek egy pici, de nagyon fontos szeletéről – fogok egy alap konfigurációt bemutatni. A fókusz a naplóbejegyzések központi kezelése lesz az Azure Monitoron belül.
Ennek két legfontosabb komponense:
a Log Analytics Workspace
és a Data Collection Rules (DCR)
Ezek adják az egész VM-alapú naplózás és megfigyelés gerincét.
Később górcső alá vesszük az Azure Monitor további elemeit is, hogy jobban belelássatok ebbe a nagyon komplex, mégis rendkívül izgalmas világba.
Nem elméleti áttekintést szeretnék adni, és nem is egy „mindent bele” vállalati monitoring architektúrát bemutatni. A célom sokkal egyszerűbb és gyakorlatiasabb:
megérteni, mi a szerepe a Log Analytics Workspace-nek,
tisztázni, mire valók a Data Collection Rules,
és végigmenni egy egyszerű beállításon Linux és Windows Server virtuális gépek esetén is.
Alapfogalmak és szerepek
Log Analytics Workspace (LAW) a központi adattároló, ahová minden log és metrika beérkezik. Gyakorlatilag egy speciális adatbázis, amely KQL (Kusto Query Language) lekérdezéseket támogat. Egy workspace több száz VM-et is kiszolgálhat, de szervezeti vagy biztonsági okokból létrehozhatsz többet is.
Data Collection Rule (DCR) határozza meg, hogy mit gyűjtsünk, honnan és hová küldjük. Ez a „szabálykönyv”, ami összeköti a forrásokat (VM-ek) a célponttal (LAW). A DCR-ek rugalmasak: különböző szabályokat alkalmazhatsz különböző VM-csoportokra.
Azure Monitor Agent (AMA) a VM-eken futó agent, ami a DCR alapján gyűjti és továbbítja az adatokat. Ez váltotta le a régi Log Analytics Agent-et (MMA) és a Diagnostics Extension-t.
A terv
Az alábbi lépéseket fogjuk követni tehát:
Virtuális gépek (Linux, Windows) létrehozása (nagyon felületesen, mert tényleg alapbeállításokkal hozzuk létre)
Log Analytics Workspace létrehozás
Data Collection Rule létrehozás és beállítás
Azure Monitor Agent ellenőrzése a Virtuális gépeken
Naplóbejegyzések lekérdezése központilag
Öt egyszerű lépés, ami segít megérteni hogyan működik ez a szörnyeteg.
1. lépés: Virtuális gépek létrehozása
Amikor elindul a vállalkozásunk, először egy vagy tövv gépet hozunk létre. Tegyük ezt most is.
Minden lépést a Portálon fogunk elvégezni, az egyszerűség kedvéért.
A Marketplace-n keresd meg: „Ubuntu 24.04 LTS – all plans including Ubuntu Pro”
Ebből hozz létre egy „Ubuntu Server 24.04 LTS”
Gép neve legyen „linux-monitor”
Méret legyen egy kicsi, pl.: Standard_B1s
Hitelesítés típusa legyen Nyilvános SSH-kulcs
Lemez esetén elegendő egy Standard SSD
Hálózatnál létrehozhatunk egy monitor-vnet nevű hálózatot
A többi beállítást nem is módosítjuk, hanem hagyjuk úgy, ahogy az látjuk, tehát menjünk a Felülvizsgálat + létrehozás lapra
És hozzuk létre az első virtuális gépünket
Windows vm
A Marketplace-n keresd meg: „Windows Server”
Ebből hozz létre egy „Windows Server 2022 Datacenter”
Gép neve legyen „windows-monitor”
Méret legyen egy kicsi, pl.: Standard_B2s
Rendszergazdai fióknál állítsunk be egy felhasználónevet és a hozzátartozó jelszót
Lemez esetén elegendő egy Standard SSD
Hálózatnál válasszuk a linux-nál létrehozott monitor-vnet nevű hálózatot
A többi beállítást nem is módosítjuk, hanem hagyjuk úgy, ahogy az látjuk, tehát menjünk a Felülvizsgálat + létrehozás lapra
És hozzuk létre a második virtuális gépünket
2. lépés: Log Analytics Workspace létrehozása
Eljutottunk tehát oda, hogy megvannak a gépeink, de nem tudjuk mi is van velük, vagy mi történik az alkalmazásokkal. Kell nekünk egy központi tároló, ahová a gépeken keletkező naplóbejegyzések és/vagy metrikák beérkeznek. Most ezt hozzuk létre.
Felül a keresőben keresd meg: „Log Analytics-munkaterületek„, majd kattintsunk rá.
Kattints: „+ Létrehozás” gombra
Töltsd ki:
Előfizetés: válaszd ki
Erőforráscsoport: válaszd a korábban létrehozttat
Név: egyedi név (pl.: law-mentor)
Régió: válaszd azt amit az erőforráscsoportnál és a VM-eknél is használtál
Kattints: „Áttekintés és létrehozás”, majd hozd létre. 1-2 perc és létrejön.
Most már van egy adatbázisunk, ahová gyűjthetjük az adatokat.
3. lépés: Data Collection Rule létrehozás és beállítás
Egyre közelebb vagyunk a célunkhoz. Most hozzuk létre azt a szabályt, hogy a létező VM-ekről milyen adatokat szeretnénk látni a központi adatbázisban (Log Analytics Workspace)
Alap adatok
Felül a keresőben keresd meg: „Monitorozás”, majd kattintsunk rá.
A bal oldali panelon keressük meg a Beállítások > Adatgyűjtési szabályok elemet és kattintsunk rá
Kattints: „+ Létrehozás” gombra
Add meg a szabály alap adatait:
Szabály neve: pl: dcr-vm-logs-all
Előfizetés és erőforráscsoport: ugyanaz, mint a LAW
Platform típusa: válaszd „All” (Ha Windows és Linux is kell. Mi most ezt szeretnénk)
Adatgyűjtési végpont: Nekünk ez most nem szükséges, mert Azure-on belüli gépekhez hozzuk létre
Kattints: „Következő: Erőforrások >” gombra
Erőforrások fül: Itt adod hozzá a VM-eket, amikről gyűjteni szeretnél. Kattints „+ Erőforrások hozzáadása” gombra és válaszd ki a VM-eket amelyeket korábban létrehoztál. (Az AMA agent automatikusan települ, ha még nincs fent.)
Kattints: „Következő: Gyűjtés és küldés >” gombra
Gyűjtés és küldés fül: Itt definiálod az adatforrásokat (mit olvasson be a VM-ekről)
Windows adatforrás
Kattints „+ Adatforrás felvétele”
Adatforrás típusánál válaszd a „Windowsos eseménynaplók” elemet. Ezzel lehetőséged van beolvasni azokat az eseménynapló-bejegyzéseket, amelyekre szükséged van. Ezeket nagyon részletesen testre lehet szabni.
Mi most itt csak az Alapszintű elemeket fogjuk gyűjteni. Jelöld ki mindet.
Ebben az ablakban kattints „Következő: Cél >” gombra.
Ellenőrizd, hogy a megfelelelő LAW-ba mennek-e az adatok majd. Ha igen, kattints az Adatforrás felvétele gombra.
Ezzel a Windows naplóbejegyzések betöltése készen áll
Linux adatforrás
Kattints „+ Adatforrás felvétele”
Adatforrás típusánál válaszd a „Linux Syslog” elemet. Ezzel lehetőséged van beolvasni azokat az eseménynapló-bejegyzéseket, amelyekre szükséged van. Ezeket nagyon részletesen testre lehet szabni.
Ezután be kel állítanunk, hogy mi a minimális naplózási szint, amit szeretnénk beállítani. Alapvetően senkinek nem javaslom, hogy beállítsa az LOG_INFO szintet, de a példánk miatt, most ezt tesszük.
Majd, szintén a példa kedvéért, kiválasztjuk az összes szolgáltatást.
Ebben az ablakban kattints „Következő: Cél >” gombra.
Ellenőrizd, hogy a megelelelő LAW-ba mennek-e az adatok majd. Ha igen, kattints az Adatforrás felvétele gombra.
Ezzel a Linux naplóbejegyzések betöltése is készen áll.
Szabály véglegesítése
Megvan a két adatforrásunk. A többi beállítást nem is módosítjuk, hanem hagyjuk úgy, ahogy az látjuk, tehát menjünk a Felülvizsgálat + létrehozás lapra
És hozzuk létre a szabályt.
Most várnunk kell 5-10 percet, amíg elindul az adatok betöltése. Amíg ez megtörténik, ellenőrizzük le mindegyik VM-ünk esetén, hogy a monitor ügynők települt-e.
Megjegyzés: A teljesítmény metrikák beállítása is hasonlóan történik, ott az adatforrás típusa lesz más.
4. lépés: Azure Monitor Agent ellenőrzése a Virtuális gépeken
Ezt mindkét típusú (Linux, Windows) virtuális gépnél ugyanott tudjuk megtenni.
Keressük meg az erőforráscsoportban a virtuális gép erőforrást (linux-monitor vagy windows-monitor) és kattintsunk rá
A bal oldali panelon keressük meg a Beállítások > Alkalmazások és bővítmények elemet és kattintsunk rá
Itt kell látnunk az AMA elemet
Windows esetén: AzureMonitorWindowsAgent
Linux esetén: AzureMonitorLinuxAgent
Ha ez hiányzik, akkor nem fogjuk tudni gyűjteni a naplóbejegyzéseket és metrikákat.
Most pedig elérkezett a pillanat amire vártunk: központilag le tudjuk kérdezni a begyűjtött adatokat. Azokat tudjuk elemezni, vagy további feldolgozást végezhetünk rajuk. Nincs határ.
Elemzések áttekintése
Amint az adatok begyűjtése elindul, a LAW munkába lendül és rengeteg hasznos információt biztosít számunkra. Ebből jelenleg csak az alap elemzési diagrammot szeretném megmutatni.
Felül a keresőben keresd meg: „Monitorozás”, majd kattintsunk rá.
A bal oldali panelon keressük meg a Betekintések > Log Analytics-munkaterületek elemet és kattintsunk rá.
Felül válaszd ki a megfelelő Workspace-t
Majd kattints a nevére
Megnyílik az elemzési áttekintő ablak
Naplóbejegyzése a portálon
Most pedig megmutatom az ajtót a naplóbejegyzések keresésének végtelen univerzumába.
Felül a keresőben keresd meg: „Monitorozás”, majd kattintsunk rá.
A bal oldali panelon keressük meg a Betekintések > Log Analytics-munkaterületek elemet és kattintsunk rá.
Felül válaszd ki a megfelelő Workspace-t
Majd kattints a nevére
Megnyílik az elemzési áttekintő ablak
A bal oldali panelon keressük meg a Figyelés > Munküzetek elemet és kattintsunk rá.
Itt találsz előre elkészített elemet.
Mi most újat hozunk létre, mert az a legegyszerűbb. Kattints: „+ Új”
A megjelenő lapon a Log Analytics-munkaterület Naplók (Analytics) Lekérdezés rész a KQL query editor. Ide írhatod meg az egyedi lekérdezésedet, amit utána el is menthetsz.
Illeszd me az alábbit, majd kattints a Lekérdezés futtatása gombra
// Windows Információs bejegyzések az elmúlt 1 órából
Event
| where TimeGenerated > ago(1h)
| where EventLevelName in ("Information")
| project TimeGenerated, Computer, EventLog, EventLevelName, RenderedDescription
| order by TimeGenerated desc
Ezt is próbáld ki:
// Linux auth események (bejelentkezések)
Syslog
| where TimeGenerated > ago(3h)
| where Facility == "auth" or Facility == "authpriv"
| project TimeGenerated, Computer, SeverityLevel, SyslogMessage
| order by TimeGenerated desc
És egyéb példák:
// Összes Windows Event az elmúlt 24 órából
Event
| where TimeGenerated > ago(24h)
| summarize count() by EventLog, EventLevelName
| order by count_ desc
// Windows hibák és figyelmeztetések
Event
| where TimeGenerated > ago(1h)
| where EventLevelName in ("Error", "Warning")
| project TimeGenerated, Computer, EventLog, EventLevelName, RenderedDescription
| order by TimeGenerated desc
// Linux syslog események
Syslog
| where TimeGenerated > ago(24h)
| summarize count() by Facility, SeverityLevel
| order by count_ desc
// Linux auth események (bejelentkezések)
Syslog
| where TimeGenerated > ago(24h)
| where Facility == "auth" or Facility == "authpriv"
| project TimeGenerated, Computer, SeverityLevel, SyslogMessage
| order by TimeGenerated desc
// Adott VM összes logja
Event
| where Computer == "linux-monitor"
| where TimeGenerated > ago(1h)
| order by TimeGenerated desc
Tippek
Ezzel végeztünk is. Ugye, hogy milyen sima volt?
Fontos: A KQL lekérdezéseket érdemes tanulmányozni, hogy elérd a kívánt eredményt.
Problémák elkerülése:
Amikor eldöntjük, mit gyűjtünk, rengeteg lehetőség van. Én azt javaslom, hogy tudatosan tervezzük meg mire is van igazán szükségünk, mert könnyű elkövetni az alábbi hibákat:
túl sok adat gyűjtése feleslegesen,
nem egyértelmű, hogy egy VM miért nem küld naplót,
Linux és Windows eltérő logikájának keverése (ezért sem optimális a jelenlegi beállításunk),
vagy egyszerűen az, hogy nem világos, mi történik a háttérben.
Költségoptimalizálás tippek:
Ne gyűjts mindent „Information” szinten, csak Warning és felette
Állíts be data retention limitet (30 nap alap, növelhető)
Használj data collection rule transformations-t a felesleges adatok szűrésére
Összefoglalás
Együtt beállítottunk egy teljes körű log gyűjtési megoldást Azure Monitor segítségével. Létrehoztunk egy Log Analytics Workspace-t, ami központi tárolóként szolgál minden begyűjtött adatnak.
Konfiguráltunk egy Data Collection Rule-t, amely Windows Event Logs és Linux Syslog forrásokból gyűjti az eseményeket, és hozzárendeltük a monitorozni kívánt VM-ekhez.
Az Azure Monitor Agent automatikusan települt a gépekre, így azok azonnal elkezdték küldeni az adatokat. A begyűjtött logokat a Log Analytics Workspace Naplók menüpontjában KQL lekérdezésekkel tudjuk elemezni és keresni.
Ha most ismerkedsz az Azure Monitoring-al, vagy eddig csak „kattontgattad”, mert muszáj volt, akkor ez a cikk neked szólt.
Rövid gyakorlás után biztos vagyok benne, hogy hamar összeáll a kép.
Nem rég fejeztem be egy videós képzési anyagot a Mentor Klub részére, ahol a résztvevők megismerhették az Azure-on belül elérhető OpenAI megoldásokat. Ennek részeként bemutattam az Azure OpenAI Studio felületét is, ami valójában az Azure AI Foundry egyik funkcionális eleme. Mindkettőt elég gyakran használom, különböző projektekben és különböző célokra. Hogy éppen melyik a jobb egy adott feladathoz, azt többnyire az aktuális projekt igényei döntik el.
A Microsoft azonban az elmúlt hónapokban egy olyan változtatást indított el, amely alapjaiban alakítja át azt, ahogyan eddig AI-megoldásokat építettünk Azure-ban. A Foundry platform fokozatosan átveszi az Azure OpenAI Studio szerepét, kiszélesítve annak lehetőségeit és egységesítve az AI-fejlesztés teljes ökoszisztémáját.
Mi volt az Azure OpenAI Studio szerepe
A Microsoft az Azure OpenAI Studio felületet arra hozta létre, hogy egyszerű legyen kipróbálni és tesztelni az Azure által kínált OpenAI modelleket. A felület segítségével lehetett:
modelleket kipróbálni egy játszótérben
finomhangolt modelleket kezelni
API-végpontokat és kulcsokat elérni
kötegelt feldolgozást és tárolt befejezéseket használni
értékeléseket futtatni
és még sok hasznos AI programozást segítő funkciót.
Az Azure OpenAI Studio azonban alapvetően egy modelltípusra, az Azure által értékesített OpenAI modellekre épült. Ez a projektjeim során is érezhető volt: ha más modellgyártó megoldását szerettem volna használni, akkor azt külön kellett integrálni vagy külső szolgáltatásból kellett elérni.
Ez az a pont, ahol a Foundry teljesen más szemléletet hoz.
Mit kínál a Microsoft Foundry?
A Microsoft Foundry egy egységes AI-platform, amely több modellszolgáltatót, több szolgáltatást és teljes életciklus-kezelést egy felületre hoz. A Microsoft Learn dokumentum így fogalmaz: a Foundry egy nagyvállalati szintű platform, amely ügynököket, modelleket és fejlesztői eszközöket egy helyen kezel, kiegészítve beépített felügyeleti, monitorozási és értékelési képességekkel .
A legfontosabb különbségek a következők.
Széles modellkínálat
Az Azure OpenAI-val szemben a Foundry nem korlátozódik egyetlen gyártóra. Elérhetők többek között:
Azure OpenAI modellek
DeepSeek
Meta
Mistral
xAI
Black Forest Labs
Stability, Cohere és más közösségi modellek
És ez még csak a jéghegy csúcsa.
Ügynökszolgáltatás és többügynökös alkalmazások (AgenticAI)
A Foundry API kifejezetten ügynökalapú fejlesztéshez készült, ahol több modell és komponens együttműködésére van szükség.
Egységes API különböző modellekhez
A Foundry egységes API-t biztosít, így a fejlesztőnek nem kell minden gyártó logikáját külön megtanulnia.
Vállalati funkciók beépítve
A Foundry felületén eleve jelen vannak:
nyomkövetés
monitorozás
értékelések
integrált RBAC és szabályzatok
hálózati és biztonsági beállítások
Gyakorlatilag, minden ami a nagyvállalati és biztonságos működéshez elengedhetetlen.
Projektalapú működés
A Foundry projektek olyan elkülönített munkaterületek, amelyekhez külön hozzáférés, külön adatkészletek és külön tároló tartozik. Így egy projektben lehet modelleket, ügynököket, fájlokat és indexeket is kezelni anélkül, hogy más projektekhez keverednének.
Amikor még csak Azure OpenAI-val dolgoztam, előfordult, hogy egy ügyfél Meta vagy Mistral modellt szeretett volna kipróbálni összehasonlításként. Ezt külön rendszerben kellett megoldani. A Foundry megjelenésével ugyanabban a projektben elérhetővé vált:
GPT-típusú modell
Mistral
Meta
DeepSeek
és még sok más
Egy projekten belül egyszerre lehet kísérletezni, mérni és értékelni különböző modellek viselkedését.
Mit jelent ez a felhőben dolgozó szakembereknek
A Foundry nem egyszerűen egy új kezelőfelület. A gyakorlati előnyei:
Egységes platform, kevesebb különálló eszköz
Könnyebb modellválasztás és modellváltás
Átláthatóbb üzemeltetés, biztonság és hálózatkezelés
Bővíthető modellkínálat
Konszolidált fejlesztői élmény és API
A dokumentáció többször hangsúlyozza, hogy a Foundry nemcsak kísérletezésre, hanem üzleti szintű, gyártásra kész alkalmazásokra is alkalmas. Ez a mindennapi munkában is érezhető.
Miért előnyös ez a vállalatoknak
A vállalatok számára a Foundry több szempontból stratégiai előrelépés:
Egységes biztonsági és megfelelőségi keretrendszer
Több modellgyártó támogatása egy platformon
Könnyebb üzemeltetési kontroll
Gyorsabb AI-bevezetési ciklus
Rugalmasabb fejlesztési irányok
A Foundry megjelenésével a cégek már nem csak egyetlen modellre vagy ökoszisztémára építenek, hanem több szolgáltató képességét is bevonhatják anélkül, hogy töredezett lenne a rendszer.
Tulajdonság
Azure OpenAI
Foundry
Közvetlenül az Azure által értékesített modellek
Csak Azure OpenAI
Azure OpenAI, Black Forest Labs, DeepSeek, Meta, xAI, Mistral, Microsoft
Partner és Közösség modellek a Marketplace-en keresztül – Stability, Cohere stb.
✅
Azure OpenAI API (köteg, tárolt befejezések, finomhangolás, értékelés stb.)
Az Azure OpenAI Studio jó kiindulási pont volt az Azure AI-képességeinek megismerésére és modellek kipróbálására.
A Microsoft Foundry azonban túlnő ezen a szerepen: egységes platformot biztosít a teljes AI-fejlesztési életciklushoz, több modellgyártóval és kiterjesztett vállalati funkciókkal.
A Microsoft nem leváltja az Azure OpenAI-t, hanem beépíti egy nagyobb, átfogóbb rendszerbe. Ez a lépés hosszú távon kiszámíthatóbb, hatékonyabb és sokkal rugalmasabb AI-fejlesztést tesz lehetővé.
Ha elég időt töltünk Kubernetes környezetben, egy ponton elkerülhetetlenül rájövünk, hogy a sok látható elem – kapszulák, szolgáltatások, vezérlők, automatizmusok – mögött van valami közös, csendben működő hatalom. Valami, ami minden változtatást, minden lekérdezést, minden döntést összeköt. Ez az API.
Egy láthatatlan infrastruktúra-háló, amely összefogja a fürt egészét, irányítja az adatáramlást, és biztosítja, hogy a rendszer minden része ugyanazt a nyelvet beszélje. Amikor ezt megértjük, nem csak használjuk a Kubernetest – elkezdjük igazán érteni.
Az API a Kubernetes motorja
A Kubernetes teljes architektúrája API-alapú. A központi komponens, a kube-apiserver, felel azért, hogy a fürtben futó összes komponens — a vezérlősík elemei és a külső kliensek — megbízhatóan kommunikáljanak egymással. Minden, amit a kubectl paranccsal végzünk, valójában egy REST-alapú API hívás, amely HTTP metódusokat (GET, POST, DELETE stb.) használ.
Aki szeretne mélyebben belelátni a működésbe, kipróbálhatja a curl-alapú lekérdezéseket is. A megfelelő tanúsítványok birtokában például így kérhetjük le az aktuális kapszulák (Pods) listáját:
Ezek a hívások teszik lehetővé, hogy akár automatizált rendszerek, akár fejlesztői eszközök biztonságosan kapcsolódjanak a Kubernetes API-hoz.
A RESTful szemlélet ereje
A Kubernetes API RESTful, vagyis állapotmentes és erőforrás-orientált. Minden objektum – például egy kapszula vagy egy szolgáltatás – egy konkrét API-végpont (endpoint) mögött található. A /api/v1/pods például a kapszulákhoz tartozó végpont, ahol a GET lekérdezés listát ad, a POST pedig új kapszulát hoz létre. Ez a megközelítés lehetővé teszi, hogy a Kubernetes könnyen integrálható legyen bármely modern fejlesztési vagy üzemeltetési eszközzel.
Jogosultságok és hozzáférés-ellenőrzés
A Kubernetes egyik legfontosabb biztonsági alapelve, hogy minden felhasználó csak azt tehessen meg, amire jogosultsága van. Ezt az RBAC (Role-Based Access Control) rendszer szabályozza, de már a gyakorlati munkához is jól jön, ha gyorsan ellenőrizni tudjuk, mire van engedélyünk.
A kubectl auth can-i parancs pontosan erre való:
kubectl auth can-i create deployments
yes
kubectl auth can-i create deployments --as robert
no
kubectl auth can-i create deployments --as robert --namespace developer
yes
A fenti példában látható, hogy a „robert” nevű felhasználó csak a developer névtérben (namespace) hozhat létre új Deployment objektumokat.
A Kubernetes három fő API-t biztosít az engedélyek ellenőrzésére:
API típus
Funkció
SelfSubjectAccessReview
Ellenőrzi, hogy az aktuális felhasználó végrehajthat-e egy adott műveletet.
LocalSubjectAccessReview
Ugyanez, de egy konkrét névtérre korlátozva.
SelfSubjectRulesReview
Megmutatja, milyen műveleteket hajthat végre a felhasználó egy névtérben.
Ez a felépítés biztosítja, hogy a jogosultságok átláthatóak és ellenőrizhetőek legyenek, ami különösen fontos nagyvállalati környezetben.
Optimista konkurencia – amikor több kéz nyúl ugyanahhoz az objektumhoz
A Kubernetes nem zárja le az erőforrásokat szerkesztés közben. Ehelyett az úgynevezett optimista konkurenciakezelést (Optimistic Concurrency) használja, amely a resourceVersion értékre támaszkodik.
Amikor valaki módosít egy objektumot, a rendszer ellenőrzi, hogy a resourceVersion azóta megváltozott-e. Ha igen, 409 CONFLICT hibát kapunk, ami jelzi, hogy az objektumot időközben más is frissítette. Ez a módszer különösen fontos nagy fürtök esetén, ahol több automatizált folyamat és emberi adminisztrátor is dolgozik egyszerre ugyanazokon az erőforrásokon.
A resourceVersion értéket az etcd adatbázis kezeli, és egyedileg azonosítja az adott objektumot a névtér és a típus alapján. A lekérdezések (GET, WATCH) nem változtatják ezt az értéket, csak a módosítások (UPDATE, PATCH, DELETE).
Annotációk – amikor a metaadat többet mond, mint ezer címke
A Kubernetes-ben a címkék (labels) segítségével szűrhetünk és csoportosíthatunk objektumokat. Az annotációk (annotations) viszont nem keresésre, hanem metaadatok tárolására szolgálnak. Ezek lehetnek időbélyegek, kapcsolódó objektumokra mutató hivatkozások, vagy akár az adott erőforrásért felelős fejlesztő e-mail-címe.
Az annotációk kulcs–érték párok formájában tárolódnak, és ember számára is olvashatóak. Ez különösen hasznos lehet integrációs vagy üzemeltetési eszközök számára, mivel így minden releváns információ közvetlenül az objektumhoz kapcsolható.
Példa annotációk létrehozására és módosítására:
kubectl annotate pods --all description='Production Pods' -n prod
kubectl annotate --overwrite pod webpod description='Old Production Pod' -n prod
kubectl annotate -n prod pod webpod description-
Az annotációk segítségével tehát kontextust adhatunk az erőforrásainkhoz – anélkül, hogy az API működését befolyásolnánk.
Összegzés
A Kubernetes API nem csupán egy technikai interfész, hanem a platform idegrendszere. A RESTful megközelítés, a precíz hozzáférés-kezelés, az optimista konkurencia és a rugalmas annotációk mind azt a célt szolgálják, hogy a rendszergazdák és fejlesztők hatékonyan, biztonságosan és átláthatóan kezeljék a komplex felhős környezeteket.
Aki megérti az API működését, valójában a Kubernetes egészét érti meg. És bár a kapszulák futtatása látványosabbnak tűnhet, az igazi varázslat mégis itt, az API hívások szintjén történik.
Több tucat cikket olvashattatok tőlem a felhőszolgáltatások alapfogalmairól, és arról is, hogyan kommunikálnak egymással a különböző rendszerek. Ebben a cikkben egy olyan területet hozok közelebb, amely látszólag egyszerűnek tűnik, mégis meglepően sok félreértés forrása.
Egy saját történettel kezdem: amikor először készítettem több rétegű felhős alkalmazást, órákon át kerestem, miért nem érhető el a szolgáltatásom. A hiba mindössze annyi volt, hogy egy helytelenül megadott URL miatt teljesen más címre irányítottam a kéréseket. Ez volt az első alkalom, amikor igazán megértettem, mennyire fontos a pontos URL-használat.
A felhőben dolgozó szakemberek nap mint nap találkoznak API-végpontokkal, szolgáltatási URL-ekkel, konténerek belső hivatkozásaival és különböző load balancer címsémákkal. Ezek mind egy közös alapelvre épülnek: az URL szerkezetére. Ahhoz, hogy valaki magabiztosan mozogjon bármelyik felhős platformon, elengedhetetlen, hogy pontosan értse, mit is jelent egy URL, és hogyan működik.
Mi az az URL és miért létezik?
Az URL (Uniform Resource Locator) egy szabványos formátum, amely meghatározza, hogy az interneten vagy egy privát hálózaton belül hol található egy erőforrás, és milyen protokollon keresztül lehet elérni. A weboldalak címe, egy API végpontja, egy belső szolgáltatás címe: mind URL.
Példa: https://api.evolvia.hu/gyakorlat/42
Ez nem egy véletlenszerű karakterhalmaz, hanem precízen meghatározott elemekből áll.
Egy URL szerkezete
Egy tipikus URL több kötelező és opcionális részből épül fel:
https://cloudmentor.hu:443/eleresi/ut/?lekerdezes=ertek#szekcio
└───┬──┘└─────┬──────┘└─┬─┘└────┬────┘└───────┬───────┘└──┬───┘
Protokoll Domain Port Útvonal Query Fragment
Az egyes részek szerepe:
Protokoll Meghatározza, milyen szabályrendszerrel történik a kommunikáció. Leggyakoribb: http, https
Domain vagy IP-cím A cím, amelyhez a kérés érkezik. Példák: example.com 192.168.1.10 localhost – saját gépre mutat
Port A szerveren futó adott szolgáltatás eléréséhez szükséges. HTTP: 80 HTTPS: 443 API-k esetén gyakran egyedi, például: http://localhost:8080
Útvonal (Path) Az erőforrás helye a szerveren belül. Példa: /api/v1/orders
Query paraméterek Opcionális adatok a kéréshez kapcsolódóan. Példa: ?sort=asc&page=2
Fragment Oldalon belüli hivatkozás, például egy szakaszra ugráshoz.
Gyakori URL-típusok és példák
1. Helyi fejlesztés: localhost http://localhost:3000/api/test Ez a saját gépre mutat, amit fejlesztők naponta használnak alkalmazások és API-k tesztelésére.
2. IP-cím alapú elérés http://10.0.0.5:8080/health Jellemző konténerek, virtuális gépek vagy belső hálózati szolgáltatások esetén.
3. Felhős API-végpontok https://myapp.azurewebsites.net/api/login https://abc123.execute-api.eu-west-1.amazonaws.com/prod/items Ezek minden felhőszolgáltató esetén hasonló logikát követnek.
4. Belső szolgáltatás hivatkozása Kubernetesben http://redis-master.default.svc.cluster.local:6379 Ez jól mutatja, hogy az URL nem csak internetes cím lehet, hanem klaszteren belüli erőforrás is.
Miért fontos ez a felhőben dolgozó szakemberek számára?
Egy felhőmérnök, DevOps vagy SRE munkája szinte minden nap érinti az URL-eket. API-k hívása, szolgáltatások összekapcsolása, webhookok beállítása, konténerek közötti kommunikáció, gateway routerek konfigurálása: mind olyan feladat, ahol egy hibás karakter is működésképtelenné tehet rendszereket.
Pontosan értve az URL szerkezetét:
gyorsabban lehet hibát keresni
megbízhatóbban lehet szolgáltatásokat összekötni
tisztábban értelmezhetők logok és monitoring adatok
könnyebbé válik a skálázható rendszertervezés
A felhőben minden kommunikáció URL-ekre épül. Aki érti az alapokat, stabil alapot kap a magasabb szintű architektúrákhoz.
Leggyakoribb hibák kezdők körében
Rosszul megadott protokoll: http helyett https
Port kihagyása olyan szolgáltatásnál, ahol nem alapértelmezett (alapértelmezett portok például: 80 – HTTP, 443 – HTTPS)
Query paraméterek helytelen formázása
Localhost és külső elérési címek összekeverése
Privát IP és publikus IP nem megfelelő használata
Ezek mind egyszerű hibák, mégis órákat vehetnek el a hibakeresésből.
HTTP és HTTPS közötti különbség
A webes kommunikáció két leggyakrabban használt protokollja a HTTP és a HTTPS. Bár a két rövidítés csak egyetlen betűben tér el, a mögöttük lévő technológiai különbség alapvetően meghatározza a biztonságot, a hitelesítést és az adatok védelmét. Felhőben dolgozó szakembereknek ez kiemelten fontos, hiszen az alkalmazások, API-k és háttérszolgáltatások nagy része érzékeny adatokat kezel.
HTTP – titkosítás nélküli kommunikáció
A HTTP (Hypertext Transfer Protocol) az alapvető webes protokoll, amely szabályozza, hogyan kommunikál a kliens és a szerver. A HTTP-ben az adatok titkosítatlan formában utaznak, vagyis bárki, aki valamilyen módon hozzáfér a hálózati forgalomhoz, elméletben képes lehet kiolvasni a küldött vagy fogadott tartalmakat. Ez ma már csak fejlesztési, belső hálózati vagy nagyon specifikus esetekben elfogadható.
HTTPS – titkosított és hitelesített kapcsolat
A HTTPS (HTTP Secure) ugyanezt a kommunikációs modellt használja, de kiegészül TLS-alapú titkosítással. A TLS (Transport Layer Security) gondoskodik arról, hogy a kliens és a szerver között áthaladó adatok ne legyenek olvashatók harmadik fél számára. Emellett a szerver hitelesítése is megtörténik tanúsítványok segítségével.
Ez azt jelenti, hogy:
a forgalom titkosított
a kliens meggyőződik arról, hogy valóban a megfelelő szerverhez csatlakozik
az adatok nem módosíthatók észrevétlenül útközben
Miért számít ez a felhőben?
A modern felhőalapú rendszerekben elképzelhetetlen HTTPS nélkül dolgozni. API-k, belső menedzsment felületek, mikroszolgáltatások közötti kommunikáció: mind olyan elemek, ahol a biztonság és az integritás prioritás.
A HTTPS használata azért kritikus:
védi a hitelesítési adatokat
megakadályozza az adatok lehallgatását
biztosítja, hogy a kliens valós szolgáltatással kommunikál
megfelel biztonsági előírásoknak és iparági szabványoknak
Gyakorlati különbségek a fejlesztő szemszögéből
A HTTPS URL-ek https:// előtaggal kezdődnek, a HTTP pedig http:// formát használ
A HTTPS alapértelmezett portja 443, míg a HTTP-é 80
HTTPS esetén szükség van tanúsítványra, amely lehet publikusan hitelesített vagy saját aláírású
Összefoglalás
Az URL nem pusztán egy webcím. Ez a modern internet egyik legfontosabb építőköve. A felhőben dolgozó szakemberek számára pedig különösen lényeges alapelem, hiszen minden szolgáltatás, API, konténer és infrastruktúra modul ezen keresztül kommunikál. Aki tisztában van az URL felépítésével és működésével, sokkal tudatosabban és gyorsabban fogja megérteni a felhős rendszerek belső működését.
Amikor először léptél be a felhő világába – akár csak kísérletezőként –, elképzelted talán, hogy a virtuális gépeken minden „mindent a semmiből” kezdünk, és amikor ez a gép eltűnik, minden adat is vele. Nos, az Amazon Elastic Compute Cloud (EC2) kezdeti időszakában ez így is volt sokszor: az „instance store” típusú tárolók a virtuális gép életciklusához kötődtek.
Ha korábban már foglalkoztál azzal, hogy naplókat, metrikákat vagy adatokat felhőben kell megőrizni, akkor az EBS adja ehhez az alapot: megbízható, gyors és rugalmas tároló-eszköz. Most nézzük meg részletesen – kezdők számára is – mit jelent az EBS volume, mik az előnyei, mire használható és milyen korlátai vannak.
Mi az EBS Volume?
Az EBS volume egy virtuális blokkszintű tárolóegység, amelyet az Amazon EBS-en belül hozol létre, és amelyet egy EC2 példányhoz csatolhatsz, mintha egy fizikai merevlemezt adnál hozzá. Fő jellemzői:
Az EBS volume az EC2 példánytól függetlenül is megőrzi az adatokat – tehát a tárolt információ nem vész el, ha a gépet leállítod vagy újraindítod.
Minden volume egy adott Availability Zone-hoz tartozik, és csak ott használható.
A felhasználó formázhatja, mountolhatja, olvashat és írhat rá, ugyanúgy, mint egy helyi meghajtóra.
Virtuális blokkszintű tárolóegység
Olyan felhőben létrehozott háttértár, amely az operációs rendszer számára úgy viselkedik, mint egy hagyományos merevlemez. Az adatokat blokkokra osztva tárolja és kezeli, így az alkalmazások közvetlenül olvashatják vagy írhatják ezeket a blokkokat. A „virtuális” jelző azt jelenti, hogy nem egy konkrét fizikai lemezen, hanem a szolgáltató (például az AWS) elosztott tárolórendszerében található az adat — a felhasználó számára mégis egyetlen logikai meghajtónak látszik.
Hogyan működik a háttérben?
Bár az EBS-t úgy látjuk, mintha egy „saját” merevlemezünk lenne a felhőben, valójában nem egyetlen fizikai lemezről van szó. Az EBS mögött az Amazon belső, elosztott tárolórendszere dolgozik, amely több fizikai háttértáron, különböző szervereken tárolja és replikálja az adatokat. Ez a felhasználó számára átlátszó: a blokkeszköz úgy viselkedik, mint egy hagyományos disk, de a valóságban több háttértár és redundáns adatmásolat biztosítja az állandóságot és a teljesítményt. Ez a megoldás teszi lehetővé, hogy:
az adatok automatikusan védve legyenek hardverhiba esetén,
egyetlen lemezhiba ne okozzon adatvesztést,
az EBS skálázni tudja a háttérkapacitást emberi beavatkozás nélkül.
Tehát az EBS nem egy konkrét „disk”, hanem egy blokkszintű, hálózaton keresztül elérhető tárolószolgáltatás, amelyet az AWS menedzsel helyetted.
Erősségek és lehetőségek
Megbízhatóság és tartósság
Az EBS automatikusan több alrendszer között replikálja az adatokat, így egy hardverhiba sem okoz adatvesztést. Ha az EC2 példány leáll, az EBS adatai akkor is megmaradnak (amennyiben a beállítás ezt engedi).
Skálázhatóság és rugalmasság
Ennek egyik legnagyobb előnye, hogy a méretét, típusát vagy IOPS-értékét akár működés közben is módosíthatod. Az AWS több típusú EBS volument kínál: SSD-alapú (pl. gp2, gp3, io1, io2) és HDD-alapú (pl. st1, sc1) változatokat. Az előbbiek gyors, tranzakciós feladatokra, az utóbbiak nagy adatátviteli igényű munkákra ideálisak.
Biztonság és mentés
Az EBS snapshot segítségével pillanatképet készíthetsz a volume-ról, amelyet később visszaállíthatsz, vagy akár más régióba is átmásolhatsz. Támogatja a titkosítást is: a KMS-kulcsokkal titkosíthatók a volume-ok és snapshotok, így az adatok védettek mind tárolás, mind átvitel közben.
Típusok
Az Amazon EBS (Elastic Block Store) többféle volume típust kínál, amelyek különböző teljesítmény- és költségigényekhez igazodnak. Ezeket alapvetően két fő kategóriába soroljuk: SSD-alapú (alacsony késleltetésű, tranzakciós műveletekre) és HDD-alapú (nagy áteresztésű, szekvenciális feldolgozásra) kötetekre.
SSD-alapú volume-ok (alacsony késleltetésű, gyors műveletekhez)
Ezek ideálisak operációs rendszerekhez, adatbázisokhoz, webalkalmazásokhoz és más tranzakciós jellegű munkákhoz.
Típus
Jellemző
Ideális felhasználás
Teljesítmény / IOPS
Árszint
gp3(General Purpose SSD, új generáció)
Alapértelmezett típus. Fix áron magasabb teljesítményt ad, mint a gp2.
Általános célú alkalmazások, web- és adatbázisszerverek.
Olyan rendszerek, ahol nem kritikus a skálázhatóság.
3 IOPS / GB (max 16 000 IOPS)
Közepes
io1(Provisioned IOPS SSD)
Nagy teljesítmény, garantált IOPS.
Kritikus adatbázisok, pl. Oracle, SAP HANA.
100 – 64 000 IOPS
Magas
io2(Provisioned IOPS SSD, új generáció)
Jobb tartósság (99,999%) és magasabb IOPS-arány.
Nagyvállalati adatbázisok, alacsony késleltetést igénylő alkalmazások.
100 – 256 000 IOPS
Magas
HDD-alapú volume-ok (nagy adatátvitel, olcsóbb)
Ezeket főként nagy mennyiségű, szekvenciális adat feldolgozására használják, például logok, biztonsági mentések, adatarchívumok esetén.
Típus
Jellemző
Ideális felhasználás
Átviteli sebesség
Árszint
st1(Throughput Optimized HDD)
Nagy áteresztés, költséghatékony tárolás.
Nagy adatfolyamot kezelő rendszerek (pl. log-elemzés, Big Data).
Max 500 MB/s
Alacsony
sc1(Cold HDD)
Archív, ritkán elérhető adatokhoz.
Biztonsági mentések, ritka hozzáférésű adatok.
Max 250 MB/s
Legolcsóbb
Összehasonlítás röviden
Kategória
Típusok
Teljesítmény
Költség
Tartósság
Fő cél
SSD
gp3, gp2, io1, io2
Nagyon gyors
Közepes–magas
99,8–99,999%
Adatbázis, OS, tranzakciók
HDD
st1, sc1
Mérsékelt
Alacsony
99,8%
Archívum, log, backup
Egyszerű példák
Webalkalmazás: van egy EC2-n futó weboldalad, amely adatbázist használ. Külön EBS volument csatolsz az adatbázishoz, így az adatok nem vesznek el akkor sem, ha a példányt újratelepíted.
Adatfeldolgozás: egy log-gyűjtő rendszer nagy mennyiségű adatot olvas és ír. Ilyenkor érdemes nagy áteresztésű, HDD-alapú (pl. st1) EBS-t választani.
Szolgáltatási szint (SLA)
Az AWS az EBS-re 99,999%-os tartóssági és 99,99%-os rendelkezésre állási szintet vállal. Ez a gyakorlatban azt jelenti, hogy évente mindössze néhány percnyi szolgáltatáskiesés valószínű. A tartóssági garancia kifejezetten magas: az AWS belső infrastruktúrája több adatmásolatot tart, így az adatok elvesztésének esélye rendkívül alacsony.
Ugyanakkor ez nem jelenti azt, hogy nincs szükség mentésre – az AWS maga is javasolja a rendszeres snapshot-készítést, hiszen az SLA csak a szolgáltatás elérhetőségére és megbízhatóságára, nem pedig az emberi hibákból eredő adatvesztésre vonatkozik.
Hogyan segíti a cégeket és felhasználókat
Gyorsan növekvő szoftvercég az EBS-t használhatja skálázható háttértárként: ha nő az ügyfélbázis, a volume-ot egyszerűen bővíthetik vagy nagyobb teljesítményűre cserélhetik, leállás nélkül.
Egy startup az alacsonyabb árú, gp3 típusú volume-val indíthatja el alkalmazását, így kezdetben nem kell túlfizetnie a tárolásért.
Kisvállalkozás, amely webáruházat működtet az AWS-en, EBS-t használhat a vásárlói adatok és képek biztonságos, tartós tárolására.
Korlátok és megfontolások
Egy EBS volume csak abban az Availability Zone-ban használható, ahol létrejött.
A díjazás méret- és típusfüggő, és a lefoglalt kapacitás után fizetsz, nem a tényleges használat után.
A teljesítményt a választott volume-típus és az EC2 példány típusa együtt határozza meg.
Az EBS általában csak egy példányhoz csatolható; több géphez csak speciális beállításokkal.
Az adott régió kiesése esetén a volume is elérhetetlenné válhat, ezért érdemes snapshotokkal biztonsági mentést készíteni.
Összegzés
Az AWS EBS volume egy megbízható, tartós és skálázható blokktárolási megoldás, amely ideális választás virtuális gépekhez. Segítségével az adatok függetlenek maradnak az EC2 példány életciklusától, könnyen bővíthetők, és egyszerűen menthetők snapshotokkal.
Erősségei közé tartozik a stabilitás, a gyors adatkezelés, a rugalmas méretezhetőség és a titkosítási lehetőség. Ugyanakkor érdemes figyelni az elérhetőségi zónák korlátaira és a költségek optimalizálására. Ha a felhőben adatbázist, webalkalmazást vagy akár nagy adatfeldolgozó rendszert építesz, az EBS az egyik legfontosabb építőkockád lesz – megbízható, mint egy jó merevlemez, csak épp a felhőben.
Amikor fejlesztőként program csomagokat publikálunk vagy automatizálunk, a biztonság mindig kulcskérdés. A szoftverellátási lánc támadásai egyre gyakoribbak, ezért a GitHub most javította a hitelesítést és a token-kezelést. Az egész folyamat középpontjában a Personal Access Token (PAT) áll — ez az a digitális kulcs, ami a fejlesztők mindennapjait biztonságosabbá és szabályozottabbá teszi.
Mi az a PAT, és miért fontos?
A Personal Access Token (PAT) egy digitális azonosító, amellyel hitelesítem magam a GitHub-on vagy az npm-en anélkül, hogy jelszót kellene megadnom. Olyan, mint egy személyre szabott kulcs, amivel belépek egy zárt rendszerbe – de csak azokhoz az ajtókhoz, amelyekhez ténylegesen van jogosultságom.
A PAT azért fontos, mert:
Biztonságosabb, mint a jelszó, nem kerül közvetlenül a kódba vagy pipeline-ba.
Automatizált folyamatokhoz (CI/CD, build, deploy) elengedhetetlen, mivel emberi beavatkozás nélkül hitelesít.
Korlátozható és forgatható, így ha kiszivárog, a kár minimalizálható.
Más szóval: minden, amit a fejlesztői rendszerekben „tokenk-ént” használunk — legyen az npm, GitHub vagy API — valójában egy Personal Access Token, csak más néven vagy kontextusban jelenik meg.
A token típusok közötti különbségek
A GitHub háromféle token-mechanizmust használ — ezek közül az első volt a klasszikus PAT, a második a továbbfejlesztett granularis verzió, a harmadik pedig már a PAT nélküli jövő.
1. Klasszikus PAT (Classic Token) – a régi hozzáférés
A klasszikus PAT hatókörös, tehát megadható, milyen tág jogosultságokkal rendelkezik (pl. repo). Ugyanakkor a hatóköre nem elég finom (jellemzően minden repo, amihez a felhasználónak hozzáférése van), és a lejárat nem volt kötelező – emiatt nagyobb a kockázat, ha kiszivárog.
2. Granularis PAT (Fine-grained Access Token) – a finomítás
A granularis PAT bevezetésével a GitHub sokkal precízebb jogosultságkezelést adott a kezünkbe. Beállíthatom, hogy:
pontosan mely repository-hoz fér hozzá,
milyen műveletekre jogosít (pl. olvasás, írás, admin),
és meddig érvényes legyen (alapértelmezés szerint 7 nap, maximum 90).
Ez csökkenti a támadási felületet, és jobban illeszkedik a vállalati biztonsági irányelvekhez is.
A Trusted Publishing nem azt jelenti, hogy megszűnnek a Personal Access Token-ek (PAT) – sok esetben továbbra is szükség van rájuk – hanem azt, hogy egy biztonságosabb alternatívát kínál az automatizált csomag-kezeléshez. Ebben a megközelítésben a CI/CD rendszer (például GitHub Actions vagy GitLab CI/CD) az OpenID Connect (OIDC) protokollt használja, és rövid életű hitelesítést kap az adott csomag-registry (pl. npm) felé. Így a folyamat során nem kell előre létrehozott vagy tárolt PAT-et használnom, mert a futás idejére automatikusan generálódik a jogosultság.
Ez a megközelítés jelentősen csökkenti a token-kezelés kockázatát – nincs olyan hosszú életű kulcs, amit elfelejtek forgatni vagy ami kiszivároghat –, de nem helyettesíti a PAT-eket más típusú műveletekhez vagy API-hívásokhoz. A Trusted Publishing jelenleg támogatott a GitHub Actions és GitLab CI/CD környezetben, és egyre több CI-platform fogja követni ezt az irányt.
Mi változik most konkrétan?
A GitHub az npm ökoszisztémán keresztül vezeti be a PAT-kezelés első nagy változását. A mostani frissítés három fő területet érint, és minden esetben jól látszik, hogyan változik a korábbi működés.
Terület
Korábbi állapot
Új szabály
PAT élettartam
A tokenek alapértelmezett lejárata 30 nap volt, a klasszikus PAT akár korlátlanul is élt.
Az új granularis PAT alapértelmezett lejárata 7 nap, maximum 90 nap.
Klasszikus PAT-ek
Továbbra is használhatók voltak, teljes hozzáféréssel.
Teljes kivezetés: 2025 november közepétől minden klasszikus PAT érvénytelen lesz.
WebAuthn/passkey alapú 2FA váltja, ami ellenáll a phishing-támadásoknak.
Ezek a változások október közepétől indulnak, és november közepéig minden klasszikus token megszűnik.
Példák, ahol PAT-et használunk
CI/CD pipeline-ban: amikor a GitHub Actions új verziót publikál npm-re, PAT segítségével hitelesít.
Helyi fejlesztéskor: a git push vagy npm publish művelet PAT alapján engedélyezett.
Integrációs eszközöknél: például a Dependabot vagy a Renovate PAT-tel fér hozzá a repo-hoz, hogy automatikus frissítéseket küldjön.
Hogyan készülj fel?
Új granularis PAT-eket hozol létre, és minden pipeline-ban lecseréled a régieket.
Áttérsz az OIDC-alapú Trusted Publishing használatára, ahol lehetséges.
Rendszeresen rotálod a még meglévő PAT-eket.
Bevezeted a WebAuthn alapú 2FA-t, hogy megerősítsed a fiókom védelmét.
Összegzés
A Personal Access Token-ek (PAT) a modern fejlesztői hitelesítés alapját jelentik.
Különösen fontos felhő megoldásokkal való integrálásnál (pl. Azure DevOps Pipelines vagy AWS CodePipeline), mert így biztosíthatjuk, hogy csak a szükséges műveletekhez kapunk hozzáférést, és a felhőerőforrásokat is biztonságosan kezelhetjük.
A GitHub most azért változtat, hogy ezek a tokenek rövidebb életűek, korlátozottabb hatókörűek és biztonságosabbak legyenek. Ez az átmenet az automatizált, tokenmentes jövő felé vezet — ahol az azonosítás már teljesen automatizált és emberi beavatkozás nélküli.
Én személy szerint támogatom ezt az irányt. Ez a változás nemcsak engem véd, hanem mindenkit, aki a GitHub-ra és az npm-re épít.
A felhőalapú technológiák rohamos terjedésével egyre nagyobb hangsúlyt kap az erőforrásokhoz való hozzáférés kezelése. Az elmúlt hónapokban már több cikkben is körbejártuk, hogyan épülnek fel a modern felhőarchitektúrák, és milyen eszközökkel tarthatók átláthatóan karban. Most azonban elérkeztünk egy olyan témához, ami nélkül minden korábbi tudás bizonytalan lábakon állna: a hozzáférés-kezeléshez. Ennek egyik legfontosabb pillére az RBAC, vagyis a Role-Based Access Control – magyarul szerepkör-alapú hozzáférés-vezérlés.
Képzeljünk el egy nagyvállalatot, ahol több száz vagy több ezer ember dolgozik különböző projekteken. Nem mindenki férhet hozzá mindenhez – a fejlesztők nem módosíthatják a pénzügyi adatokat, az adminisztrátor viszont nem feltétlenül lát bele az alkalmazás kódjába. Az RBAC éppen ezt a problémát oldja meg: egyértelműen meghatározza, ki mit tehet és mit nem.
Mi az RBAC lényege?
Az RBAC alapelve, hogy a hozzáférési jogokat nem közvetlenül a felhasználókhoz, hanem szerepkörökhöz rendeljük. Ezek a szerepkörök előre definiált engedélyeket tartalmaznak, amelyek meghatározzák, milyen műveletek hajthatók végre adott erőforrásokon. A felhasználók ezután egy vagy több szerepkört kaphatnak – így az engedélyezés egyszerre lesz átlátható, rugalmas és könnyen kezelhető.
A koncepció három alapeleme:
Felhasználók (Users) – azok a személyek vagy szolgáltatások, akik hozzáférnek az erőforrásokhoz.
Szerepkörök (Roles) – engedélyek gyűjteménye, például „Reader”, „Contributor” vagy „Owner”.
Hozzárendelések (Role Assignments) – ezek kapcsolják össze a felhasználót, a szerepkört és az adott erőforrást.
Hogyan működik az RBAC az Azure-ban?
Az Azure RBAC az Azure Resource Manager (ARM) modellre épül, és segítségével szabályozható, hogy ki milyen műveleteket végezhet el Azure-erőforrásokon – például virtuális gépeken, tárfiókokon, adatbázisokon vagy hálózati elemekben.
Az Azure-ban minden erőforrás hierarchikus struktúrában helyezkedik el:
Management Group (Felügyeleti csoport) – a legfelső szint, amely több előfizetést is összefoghat.
Subscription (Előfizetés) – az erőforrások logikai egysége, ahol a számlázás és az erőforrás-kvóták kezelése történik.
Resource Group (Erőforráscsoport) – az erőforrások rendezésére szolgáló konténer, például egy adott projekt vagy alkalmazás elemei számára.
Resource (Erőforrás) – az egyes Azure-szolgáltatások, például virtuális gépek, tárfiókok, adatbázisok vagy hálózati elemek.
Egy szerepkör-hozzárendelés bármelyik szinten megadható, és öröklődik a hierarchia alatti szintekre. Ha például valaki Reader jogot kap egy teljes előfizetés szinten, akkor automatikusan olvashatja az összes erőforráscsoport és erőforrás tartalmát abban az előfizetésben.
RBAC a gyakorlatban (példa)
Képzeljük el, hogy egy fejlesztőcsapat három szereplőből áll:
Attila, a vezető fejlesztő
Péter, az infrastruktúra adminisztrátor
Zoli, a tesztelő
Az IT biztonsági elv szerint mindenkinek csak a munkájához szükséges jogokat adjuk meg.
Attila (Contributor) – létrehozhat, módosíthat és törölhet erőforrásokat a fejlesztői Resource Group-ban, de nem kezelheti a hozzáféréseket.
Péter (Owner) – teljes körű hozzáféréssel rendelkezik, így módosíthatja a szerepköröket és erőforrásokat is.
Zoli (Reader) – csak megtekintheti a fejlesztési környezetben található erőforrásokat, de nem módosíthat semmit.
Ez a megközelítés egyszerre biztonságos és hatékony, hiszen mindenki csak azt látja és azt kezeli, ami a feladata ellátásához szükséges.
RBAC szerepkörök az Azure-ban
Az Azure több mint 120 beépített szerepkört kínál, de a leggyakoribbak közé tartozik:
Owner – teljes hozzáférés mindenhez, beleértve a hozzáférés-kezelést is.
Contributor – minden erőforrást módosíthat, de nem kezelheti a jogosultságokat.
Reader – csak olvasási hozzáféréssel rendelkezik.
User Access Administrator – mások jogosultságait kezelheti, de magukat az erőforrásokat nem módosíthatja.
Ezen felül lehetőség van egyedi szerepkörök létrehozására is, ha a beépített szerepkörök nem fedik le pontosan a szervezet igényeit. Egyedi szerepkörök JSON formátumban definiálhatók, és pontosan meghatározható bennük, milyen műveletek engedélyezettek vagy tiltottak.
Az RBAC előnyei
Biztonság – Csökkenti a túlzott jogosultságok kockázatát, így kevesebb az emberi hiba vagy jogosulatlan hozzáférés.
Átláthatóság – Könnyen ellenőrizhető, ki milyen jogokkal rendelkezik.
Skálázhatóság – Nagyvállalati környezetben is egyszerűen kezelhető a jogosultságok bővülése.
Automatizálhatóság – A szerepkörök hozzárendelhetők automatizált szkriptekkel vagy Terraform kódokkal is.
Az RBAC korlátai
Bár az RBAC rendkívül hasznos, nem minden esetben elégséges.
Nem tudja kezelni az adatszintű hozzáféréseket (például egy SQL tábla soraira vonatkozó jogosultságokat).
A komplex szervezeti hierarchiákban a szerepkörök öröklődése nehezen átláthatóvá válhat.
Túl sok egyedi szerepkör esetén nő az adminisztrációs teher és a hibalehetőség.
A cégek számára az RBAC legnagyobb előnye a kontroll és a biztonság egyensúlya. Ahelyett, hogy mindenki korlátlanul hozzáférne mindenhez, az RBAC lehetővé teszi, hogy a hozzáférés csak a szükséges mértékben legyen biztosítva.
A felhasználók számára ez azt jelenti, hogy egyértelműen látják, mire jogosultak, és nem kell aggódniuk a véletlen hibák miatt. Egy fejlesztő például nyugodtan dolgozhat a saját projektjén anélkül, hogy kockáztatná más rendszerek működését. A rendszergazdák pedig gyorsabban és pontosabban tudják kiosztani az engedélyeket, akár automatizált folyamatokon keresztül is.
Összegzés
A Role-Based Access Control az egyik legfontosabb biztonsági és hatékonysági alapelv a felhőben. Az Azure RBAC egy kifinomult, de logikusan felépített rendszer, amely segít abban, hogy a szervezetek biztonságosan, mégis rugalmasan kezeljék a hozzáféréseket.
Az alapelve egyszerű: mindenkinek csak annyi jogot adjunk, amennyire valóban szüksége van.
Ez a szemlélet nemcsak az Azure-ban, hanem bármely modern informatikai környezetben elengedhetetlen, ahol a bizalom és az ellenőrzés kéz a kézben jár.
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.
