cloudservices

2026 01 12

Cloud 2026: hol járunk most, és merre tart a felhő

AWS, Azure, Cloud, GCP, Mesterséges Intelligencia ai, aws, azure, cloud, cloudservices, gcp

| Olvasási idő: 5 perc |

Amikor több mint egy évtizeddel ezelőtt először dolgoztam felhővel, még egészen más kérdések foglalkoztatták a cégeket. Mekkora szervert vegyünk? Elég lesz-e két év múlva is? Mikor kell új vasat rendelni, és mennyi idő alatt ér ide? A döntések hónapokra, vagy évekre előre szóltak, és minden hibának ára volt.

Ma, 2026 elején, egészen másról beszélünk. A kérdés már nem az, hogy „használjunk-e felhőt”, hanem az, hogy hogyan használjuk jól.

Ez a cikk nem arról szól, hogyan kell kattintgatni a konzolon, inkább egy helyzetkép: hol tart most a cloud, mit tanultunk az elmúlt években, és mire érdemes készülni rövid távon.

Mi a cloud computing ma, röviden és érthetően

A cloud computing nem egy konkrét technológia, hanem egy működési modell. A lényege egyszerű: erőforrásokat használsz akkor, amikor kell, és csak addig fizetsz értük, amíg valóban szükséged van rájuk. Nem te vásárolsz szervert, nem te cseréled a meghibásodott alkatrészt, és nem neked kell minden részletet kézben tartani.

Fontos kimondani azt is, ami sokszor kimarad: a cloud nem ingyenes, és nem varázslat. Nem lesz tőle automatikusan gyorsabb vagy jobb egy alkalmazás. Viszont ad egy rugalmasságot, amit korábban csak nagyvállalatok tudtak megfizetni.

Egy egyszerű példa: egy webalkalmazás elindítása saját szerverrel ma is működik. Viszont ha hirtelen tízszer annyi felhasználó kezdi el használni, a cloud adja azt a mozgásteret, amivel ezt különösebb kapkodás és túlterhelés miatti leállás nélkül le lehet kezelni.

Mi változott az elmúlt években, és miért fontos ez 2026-ban

Néhány évvel ezelőtt sok helyen uralkodó gondolat volt, hogy „mindent vigyünk fel a felhőbe”. Ez azonban hibás gondolat, úgy ahogy a Scrum sem való minden projekthez. Emiatt ez a hozzáállás ma már egyértelműen kiforrottabb lett. A cégek megtanulták, hogy a cloud nem automatikusan olcsóbb, és a rosszul megtervezett rendszerek itt is gyorsan drágává és átláthatatlanná válhatnak.

2026-ra a cloud érett technológiává vált. Nem a kísérletezésről szól, hanem a tudatos döntésekről. Egyre több szervezet ismeri fel, hogy kevesebb szolgáltatás, egyszerűbb architektúra és átgondolt működés sokszor többet ér, mint a legújabb megoldások halmozása. Annak ellenére, hogy a felhőszolgáltatók sokszor mást sugallnak.

A cloud nem lett rosszabb. Mi lettünk tapasztaltabbak. És elkezdtük hatékonyabban használni.

Mire használják a cégek a felhőt 2026-ban valójában

A legtöbb vállalat ma nem csupán „innovációs lehetőségként” tekint a felhőre. Sokkal inkább stabil alapként. Tipikus felhasználási területek:

üzleti webalkalmazások futtatása
belső rendszerek és API-k
adatfeldolgozás és jelentéskészítés
fejlesztői és tesztkörnyezetek gyors létrehozása

Ezekben a felhasználási esetekben a cloud legnagyobb értéke a gyors indulás és a skálázhatóság. Nem kell mindent előre megtervezni évekre. Lehet kipróbálni, tapasztalni, majd dönteni.

Itt jelenik meg egyre természetesebben az AI is. Nem külön projektként, hanem funkcióként. Keresésben, ügyfélszolgálati automatizmusokban, vagy éppen adatok értelmezésében. A cloud biztosítja azt az alapot, amely nélkül ezek a megoldások nem lennének gazdaságosan működtethetők.

Hogyan indul ma egy kis cég?

Vegyünk egy mai, valós helyzetet. Egy kisebb cég szeretne egy webes alkalmazást indítani, aminek eleinte csak néhány száz felhasználója van, de nem tudják, fél év múlva mi lesz belőle.

2026-ban ilyenkor már ritkán merül fel az, hogy saját szervert vegyenek. Ehelyett:

elindítanak egy felhőben futó alkalmazást,
használnak egy felügyelt adatbázist,
és tárolják az adatokat egy felhőalapú storage-ban.

Ha az alkalmazás sikeres lesz, a rendszer skálázható. Ha nem válik be, egyszerűen leállítható, nagy veszteség nélkül.

Ez a cloud egyik legnagyobb ereje: nem kell előre mindent tudni, mégis van mozgástér. Ez üzleti oldalról legalább akkora előny, mint technikai szempontból.

Hol találkozol a felhővel a gyakorlatban?

Sokan úgy gondolnak a felhőre, mint valami elvont, „nagyvállalati” dologra, pedig a legtöbben már most is naponta használják – csak nem így hívják. Ha azt mondom: Instagram, TikTok, Gmail, OneDrive és Netflix, akkor azoknak a szolgáltatásoknak a nevét sorolom, ahol naponta találkozol Te is a felhővel.

Amikor egy webalkalmazás gyorsan betölt, amikor egy online rendszer gond nélkül kiszolgál sok felhasználót egyszerre, vagy amikor egy szolgáltatás mögött nincs látható leállás, ott nagyon gyakran „cloud fut a háttérben”.

A felhő a nagy szolgáltatóknál nagyon hasonló alapokra épül.

Például:

Microsoft Azure esetén tipikusan virtuális gépek, menedzselt adatbázisok és tárolószolgáltatások adják az alapot.
Amazon Web Services ugyanezt az elvet követi, csak más elnevezésekkel, megközelítéssel és hangsúlyokkal.
Google Cloud Platform pedig különösen erős adatfeldolgozási és analitikai irányban.

A lényeg nem az, hogy melyik platformon vagy, hanem az, hogy nem nulláról építkezel, hanem kész, kipróbált építőelemekből dolgozol.

Mit jelent a cloud a felhasználók számára

A legtöbb végfelhasználó nem gondolkodik cloudban. Nem is kell. Ők gyors, megbízható szolgáltatásokat várnak el, lehetőség szerint zéró leállással és elfogadható válaszidőkkel. Ha egy alkalmazás lassú vagy elérhetetlen, nem az érdekli őket, hogy hol fut, hanem az, hogy miért nem működik.

2026-ra a cloud ebből a szempontból láthatatlanná vált. Ott van minden mögött, de csak akkor kerül szóba, ha valami nem úgy működik, ahogy kellene. Ez önmagában jelzi az érettségét. Pontosan olyan alapszolgáltatásként tekintünk rá, mint a vezetékes vízre vagy az áramra.

Mit jelent a cloud a karrierváltóknak és pályakezdőknek

Sokan kérdezik tőlem, hogy érdemes-e ma még cloud irányba indulni. A válaszom röviden: igen, de másképp, mint pár éve. Nem az számít, hogy hány szolgáltatás nevét ismered, hanem az, hogy érted-e az alapokat.

2026-ban a cloud jó belépési pont az IT világába azoknak is, akik nem szeretnének mélyen programozni. A rendszerszemlélet, az alap biztonsági gondolkodás és az üzleti igények megértése sokkal fontosabb lett, mint a konkrét implementációs részletek.

Az AI ebben a tanulási folyamatban segíthet, magyarázhat és irányt mutathat, de nem veszi le a döntés terhét a válladról.

A cloud szakember nem attól lesz jó, hogy mindent automatizál vagy mindent tud, hanem attól, hogy felelősséget vállal a döntéseiért és tanul a hibáiból.

Az AI szerepe röviden

Talán észrevetted az AI itt nem főszereplő még, de nem lehet megkerülni. 2026-ban egyértelműen látszik, hogy az AI felerősíti a cloud jelentőségét. Skálázás, költségoptimalizálás, automatizált elemzés mind olyan területek, ahol a kettő együtt ad valódi értéket.

Ugyanakkor fontos határt húzni. A cloud itt még az alap, az infrastruktúra és a platform. Az igazi változás ott kezdődik, amikor az AI már nem csak használja a felhőt, hanem formálja is. Erről szól majd a következő cikkem.

Korlátok, amik 2026-ban is megmaradnak

A cloud nem old meg rossz döntéseket. Nem helyettesíti a gondolkodást, és nem javítja ki a szervezeti problémákat. Rosszul használva továbbra is drága, és könnyen átláthatatlanná válik.

Ez AI-val együtt sincs másképp. Ha nincs világos cél, nincs felelősség és nincs kontroll, akkor a legmodernebb technológia is csak gyorsabban visz rossz irányba.

Útravaló

2026-ban a cloud nem trend, hanem alap. Nem cél, hanem eszköz. Azok a csapatok és szakemberek járnak jól, akik nem csodát várnak tőle, hanem tudatosan használják. A következő lépés viszont már nem csak erről szól. Az AI és a cloud együtt új kérdéseket vet fel, és új válaszokat kényszerít ki.

Erről fog szólni a folytatás…

Ha érdekel, merre halad ez az irány, és hogyan érdemes rá felkészülni, akkor iratkozz fel az InfoPack hírlevélre vagy kövesd a cikkeim.

2026 01 08

Kubernetes namespaces – mert rend a lelke mindennek

Cloud, Docker, Kubernetes cloudservices, docker, iaas, k8s, kubernetes

| Olvasási idő: 3 perc |

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,
strukturált, átlátható cluster felépítést szeretnénk.

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.

2026 01 04

2026 tervei: új struktúra, tisztább irány a blogon

Hírek 2026, cloudservices, evolvia, news

| Olvasási idő: 2 perc |

Nemrég zártuk le az előző évet és máris itt egy újabb év, túl vagyunk a pezsgő pukkanásán és a karácsonyi hangulaton. Bár még csak január van, már most rengeteg ötletem van 2026-ra, amelyekből szeretnék néhányat megosztani veletek. Nem nagy bejelentések ezek, inkább olyan döntések és változások, amelyek csendben, de határozottan formálják majd az előttünk álló hónapokat.

Tervek

Idén is foglalkozom azokkal a technológiai területekkel, amelyek az elmúlt években is meghatározták a munkámat. Felhő, DevOps, automatizálás, Kubernetes, AI – ezek nem elszigetelt témák, hanem egymásra épülő rendszerek és gondolkodásmódok. 2026-ban sem az a célom, hogy minden újdonságot azonnal feldolgozzak, sokkal inkább az, hogy értelmezhetővé tegyem őket. Érdekel, hogyan kapcsolódnak össze, mit jelentenek a gyakorlatban, és milyen következményeik vannak egy valós környezetben.

Blog

Ezzel párhuzamosan a blog maga is változik. Az oldal struktúrája átalakul, letisztultabb lesz, és a cikkek egyértelműen a blog menüpont alá kerülnek. Ez nem látványos redesign, inkább egy tudatos egyszerűsítés. Szeretném, ha az írások könnyebben megtalálhatók lennének, ha az oldal logikája magától értetődőbb lenne, és nem kellene azon gondolkodni, hol érdemes keresni egy korábbi cikket. Kevesebb kerülőút, tisztább felépítés, jobb áttekinthetőség – számomra ez most fontosabb, mint bármilyen extra funkció.

A cikkek elérésében is lesz változás. Az új írások a könnyebb követhetőség miatt az én LinkedIn-profilomon is megjelennek majd. Így ott is olvashatók lesznek, ahol sokan amúgy is napi szinten jelen vagytok, és ahol gyorsabban elindulhat egy-egy szakmai gondolatmenet vagy beszélgetés. Fontos viszont, hogy a korábban megjelent cikkek továbbra is elérhetők maradnak a Cloud Mentor LinkedIn-oldalon, tehát a régi anyagok nem tűnnek el, csak bővül a hozzáférésük.

Evolvia

Evolvia is újabb fejlődési szakaszba lép 2026-ban. A rendszer új architektúrára kerül, mert a jelenlegi megoldás már nem szolgálja ki megfelelően azt az igényt, amely a megnövekedett használattal együtt jelent meg. Ez nem pusztán technikai frissítés: a cél egy stabilabb, skálázhatóbb alap, amely hosszú távon is elbírja a terhelést.

Emellett bővítem a gyakorló környezetek számát is, hogy többféle technológiát, többféle helyzetet lehessen valós környezetben kipróbálni. Ez számomra is fontos, mert a tanulás és a megértés kulcsfontosságú a technológiák elsajátításában.

Várom ezt az évet, hogy megmutathassam az ötleteimet. Remélem, legalább akkora örömmel fogadjátok majd őket, amekkora kedvvel és odafigyeléssel készülök rájuk.

2025 12 31

Mit adott 2025? Számok, megélések és egy apró irányváltás

Cloud, Hírek 2025, 2026, cloud, cloudservices, future, recap

| Olvasási idő: 6 perc |

Itt az évvége, amikor meg kell állnunk egy kicsit, hogy visszatekintsünk, mi is történt idén. Nem egy hosszas elemzést végzünk, csupán megnézzük, mit értünk el, és hogyan szeretnénk átlépni a következő évbe.

Én is így teszek most, ebben a cikkben. Ez nekem minden évben fontos, hogy lássam, hová jutottam el a tavalyi cikkemtől. Ami teljesen bizonyos, hogy teljesen más irányt vett az életem, mint ahogy azt előre vártam. Egy olyan irányba fordultam, amit régen érzek magamban, de nem tudtam, beérik-e valaha, de ne szaladjunk ennyire előre.

Tavaly az alábbi sorokkal búcsúztattam az évet:

2025-ben is folytatom az utamat a technológia és a tanulás világában, és bízom benne, hogy velem tartotok ezen az izgalmas utazáson. Terveim szerint rengeteg új témával, praktikus példákkal és inspiráló tartalmakkal készülök nektek.

Nézzük mi is történt, hogyan fejlődtem, milyen megéléseim voltak.

Köszönöm

Először is szeretném megköszönni a Feleségemnek a sok-sok támogatást, amit mindig és folyamatosan kapok Tőle. Ő az, aki mindig inspirál és átsegít a nehéz pillanatokon.

Kiemelt köszönet azoknak, akik követik munkásságomat és támogatnak a mindennapokban, azzal hogy olvassák cikkeimet vagy tanácsot kérnek a szakmai fejlődésükhöz.

Hálás vagyok a Mentor Klubnak is, hogy már több mint 3 éve egy inspiráló, baráti és motiváló együttműködés keretében tesszük jobbá a világot azzal, hogy a fejlődni és váltani vágyóknak biztosítjuk a lehetőséget a tanulásra.

Összességében szeretném megköszönni a sok kedves visszajelzést és energiát, amit rendszeresen kapok. Ez motivál arra, hogy a következő időszakban is tovább folytassam az utam és rendszeres megújulásokon keresztül még jobb és praktikus témákat hozzak nektek.

Oktatás és mentorálás

Ebben az évben a Mentor Klubon belül kicsit bővítettük azt a palettát, amit nyújtok a fejlődni vágyóknak. Már nem csupán szakmai képzéseken (Azure, AWS) találkozhattatok velem, hanem volt egy nagyon jó hangulatú karrier-tanácsadás is.

Egy olyan élő lehetőség, ahol bárki kérdezhetett tőlem a karriercéljai és esetleges nehézségei kapcsán. Ezen az eredetileg 2 órásra tervezett (végül 2,5 órás) interaktív beszélgetésen több mint 190 ember vett részt és ennek többszöröse az, aki utólag nézte vissza a felvételt. Ez fantasztikus és felemelő volt egyszerre.

És ez csak egy kis szelete annak a több mint 1000 hallgatónak, akik résztvettek idén a képzéseimen vagy online, vagy offline módon. Hihetetlenül sok energiát kapok ezeken keresztül is.

Hiszen felhő képzéseimen is megnőtt az érdeklődők száma, ami jól mutatja, hogy a felhő egy fontos összetevője a jelenlegi informatika világának. Ráadásul a mesterséges intelligencia térhódításával, talán még fontosabb lett, mint korábban.

Az év negyedik negyedévében lett két mentoráltam is, akikkel 2 hetente még mélyebbre ássuk magunkat a felhő és a modern karrierváltás világába. Rajtuk keresztül még jobban látom, mennyit ér a kitartó és kemény munka, ha valaki szeretné megvalósítani az álmait.

2025-ben indítottam útjára az ingyenes karrier-tanácsadási kérdőívemet, a Felhő Iránytűt, amit február vége és november vége között húszan töltöttétek ki. Nekik személyre szabott felhő karrier tanácsokat adtam, amit a visszajelzések alapján mindenki kiemelten hasznosnak tartott.

Evolvia – a büszkeségem

Az Evolvia számomra különösen fontos. Ez egy olyan felhőalapú gyakorló platform, amelyet teljes egészében egyedül építettem fel. Az volt a célom, hogy ne csak beszéljünk a technológiáról, hanem valódi, gyakorlati környezetben lehessen kipróbálni, megtapasztalni és megtanulni.

Az Evolvia pontosan azt a hiányt tölti ki, amit én is sokszor éreztem korábban: az elmélet és a gyakorlat közötti szakadékot. A fejlesztését 2026-ban is folytatom, hogy még több ember számára legyen elérhető, használható és értékes tanulási lehetőség.

Az Evolvián jelenleg olyan gyakorlati képzések érhetők el, amelyek az Azure alapjaitól indulnak, és fokozatosan vezetnek el az összetettebb, valós életből vett megoldásokig. A cél végig ugyanaz: ne csak értsük, miről szól egy szolgáltatás, hanem saját kézzel hozzuk létre, konfiguráljuk és működtessük.

A tananyagok lefedik az Azure Portál használatát, a virtuális gépek és hálózatok létrehozását, a terheléselosztást és a skálázhatóság alapjait, valamint a CloudShell és az Azure CLI gyakorlati alkalmazását. Ezekre épülnek a modernebb irányok is, mint az App Service alapú webalkalmazások, a DevOps folyamatok automatizálása, a Docker-alapú telepítések, vagy akár az AI-hoz kapcsolódó megoldások, például az OpenAI és RAG-alapú alkalmazások Azure környezetben.

Alkotás és kódolás

Ezen a területen is sokat tevékenykedtem idén. 2025-ben ezzel a cikkel együtt 88 alkalommal osztottam meg veletek valamilyen tudást vagy információt. Remélem, hogy hasznos számotokra és jövőre is velem tartotok.

Munkám során és a hobbi projektjeim keretein belül több mint 33 075 kódsort írtam több mint 18 GitHub repository-ba, amelyekkel valamilyen Cloud, AI valamint DevOps projektet keltettem életre vagy járultam hozzá annak hatékonyabb működéséhez.

Az alkotás itt nem állt meg. Az általam tartott képzésekhez idén 542 db prezentációs diát készítettem, amelyeket az élő- és videós képzésekhez készítettem nektek.

Ebben az évben 3 új – általam készített – videós képzéssel is megajándékozott Titeket a Mentor Klub. Ezek széles spektrumon mozognak: DevOps & SRE, AI, NoCode-LowCode. Igazán izgalmas volt ezeket elkészíteni, mert tudtam, hogy hasznos és használható tudást adhatok nektek ezzel.

Tanulás

Ahogy előrevetítettem, idén is rengeteget tanultam. Évelején elkezdtem a felkészülést a Certified Kubernetes Administrator (CKA) vizsgára, amely kapcsán volt néhány negatív megélésem. Rájöttem, hogy nem egy újabb technológiai vizsga az az út vagy irány ami a jövőm.

Ez a megélés meghatározta az év nagy részét, így egy valódi hullámvasút érzést adott. Izgalmas volt, de nyár végére rájöttem egy új, nagyobb cél, amit nekem szánt a sors.

Emiatt tanulásomat 2025-ben a vezetői soft skill képzések tették ki, ezen belül is az új irány a Leadership, azaz a menedzsment irány. Lehetőségem volt a Harvard ManageMentor keretében több mint 25 tanúsítványt szereznem. Izgalmas és új utazás volt, ahol azt tanulhattam és tanúsíthattam, hogyan tudok embereket vezetni.

Olyan képességeimet tudtam fejleszteni mint a delegálás, coaching, mentoring, visszajelzések kezelése, emberek vezetése, AI alkalmazása a vezetésben, és még sok-sok hasonló. Érdekes hónapok voltak ezek is.

Mellette tovább képeztem magam Kubernetes, Mesterséges Intelligencia, DevOps, AI-Ops, GitOps területeken is.

Nem unatkoztam tehát idén sem.

Mi változott bennem?

2025-ben bennem is – ahogy már utaltam rá – sok minden átrendeződött. Nem egyik napról a másikra, inkább lassan, szinte észrevétlenül. Ebben új munkahelyem is segített. Egyre világosabb lett, hogy már nem az hajt igazán, hogy minél több dolgot csináljak, hanem az, hogy amit csinálok, annak valódi súlya és értelme legyen.

Megváltozott a fókuszom. Tudatosabban választok témákat, embereket, irányokat. Sokkal fontosabb lett számomra a mélység, mint a mennyiség, és az, hogy ne csak technológiai problémákat oldjak meg, hanem embereknek segítsek eligazodni, dönteni, fejlődni.

Ami viszont igazán világossá vált 2025-ben, az egy régi belső gondolat megerősödése volt: régóta éreztem magamban a vezetői irányt. Idén ez letisztult, kimondhatóvá vált, és ennek megfelelően kezdtem el tudatosan rendezni az életemet – szakmailag és emberileg egyaránt.

A karrieremben is ebbe az irányba haladok tovább, amit már nyíltan vállalok. Ennek a változásnak része az is, hogy a szakmai jelenlétemben – például a LinkedIn profilomon – már DevOps leaderként határozom meg magam.

Ez nem egy hirtelen váltás, hanem egy irány, amely mostanra érett meg bennem igazán.

A következő lépés

A következő időszak számomra egyértelműen a vezetői karrier tudatos építéséről szól. Ez már nem kérdés, hanem irány. Úgy érzem, ebben a szerepben tudok igazán többet adni: tapasztalatot, rálátást, iránymutatást.

A technológiát természetesen nem engedem el. A Cloud és az AI továbbra is központi része marad annak, amivel foglalkozom. Vannak technológiai terveim és törekvéseim is a következő évre, de ezekről egyelőre még nem szeretnék részletekbe menni.

2026-ban is folytatom az oktatást és a mentoringot, sőt, még több energiát szeretnék ebbe az irányba tenni. Akár képzésekről, akár személyes mentorprogramról vagy vizsgafelkészítésről van szó, továbbra is az a célom, hogy valódi segítséget adjak azoknak, akik fejlődni vagy váltani szeretnének.

Köszönöm, hogy idén is velem tartottatok.
Jövőre is várlak benneteket a Mentor Klub képzésein, egy személyes mentorprogramban vagy egy vizsgafelkészítőn.

Kellemes ünnepeket kívánok, és találkozunk 2026-ban!

2025 számokban

karrier tanácsadásra éhező

kódsor

blog cikk

új videós képzési anyag

AI prompt

soft skill tanúsítvány

mentorált

prezentációs dia

új GitHub repo

felhő iránytű kitöltő

2025 12 22

Kubernetes API és hozzáférés – a láthatatlan működés mélyén

Cloud, Docker, Kubernetes cloudservices, docker, iaas, k8s, kubernetes

| Olvasási idő: 4 perc |

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:

apiVersion: v1
kind: Pod
metadata:
 name: elsopod
spec:
 containers:
 - image: nginx
 name: robi

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:

kubectl --v=10 get pods elsopod

A logokban ilyen sorok is megjelennek:

curl -k -v -XGET -H "Accept: application/json" \
https://10.128.0.3:6443/api/v1/namespaces/default/pods/elsopod

Ez a sor egyértelművé teszi:

a kubectl egy kliens,
a Kubernetes API-szervere a célpont,
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:

apiVersion: v1
clusters:
- cluster:
 certificate-authority-data: <base64-adat>
 server: https://10.128.0.3:6443
 name: kubernetes
contexts:
- context:
 cluster: kubernetes
 user: kubernetes-admin
 name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
 user:
 client-certificate-data: <base64-cert>
 client-key-data: <base64-key>

Most nézzük végig, mit jelentenek ezek a mezők:

apiVersion

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.

2025 12 15

VM naplózás lelke: Log Analytics és Data Collection Rules

Azure, Cloud azure, cloud, cloudservices, iaas, logs

| Olvasási idő: 10 perc |

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.

Linux vm

Hozzunk létre egy erőforráscsoportot, ebbe fogunk most dolgozni
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.

5. lépés: Naplóbejegyzések lekérdezése központilag

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.

2025 12 01

A Microsoft AI platform evolúciója: OpenAI és Foundry

agents, Azure, Cloud, llm, mcp, Mesterséges Intelligencia, ml, rag ai, azure, cloud, cloudservices, iaas, llm

| Olvasási idő: 4 perc |

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.

Hogyan kapcsolódik össze a két világ

A Microsoft nem megszünteti az Azure OpenAI-t, hanem lehetővé teszi, hogy az adott erőforrás Foundry-erőforrássá alakuljon. A frissítési folyamat lényege:

a meglévő végpontok és kulcsok megmaradnak
a finomhangolt modellek és állapotok megmaradnak
a Foundry funkciói azonnal elérhetővé válnak
a fejlesztő továbbra is használhatja az Azure OpenAI API-t

Mindezt lépésről lépésre írja le a frissítési útmutató.

Egy példán keresztül…

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.)	✅	✅
Ügynökszolgáltatás		✅
Azure Foundry API		✅
AI-szolgáltatások (beszéd, látás, nyelv, tartalomértés)		✅

Összegzés

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é.

2025 11 24

Kubernetes API és hozzáférés – a kommunikáció idegrendszere

Cloud, Docker, Kubernetes api, cloud, cloudservices, iaas, k8s, kubernetes

| Olvasási idő: 4 perc |

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:

curl --cert user.pem --key user-key.pem \
 --cacert /path/to/ca.pem \
 https://k8sServer:6443/api/v1/pods

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.

2025 11 17

Az URL-ek működése és szerepe a modern felhővilágban

AWS, Azure, Cloud, Docker, Hírek, Kubernetes cloud, cloudservices, https, iaas, kubernetes, link, url

| Olvasási idő: 4 perc |

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.

2025 11 10

Kubernetes és Apache Mesos – két világ, egy közös cél

Cloud, Docker, Kubernetes cloudservices, docker, k8s, kubernetes, mesos

| Olvasási idő: 3 perc |

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.