Felhőkonyha: Kubernetes tálalva
Képzeld el, hogy belépsz egy csúcskategóriás étterem konyhájába. Mindenki tudja a dolgát: a séfek összehangoltan dolgoznak, az alapanyagok időben érkeznek, és minden fogás pontosan akkor kerül a tányérra, amikor kell. A háttérben egy jól szervezett rendszer biztosítja, hogy semmi ne csússzon el, és minden vendég gyorsan, frissen és hibátlanul kapja meg az ételét.
Valahogy így működik a Kubernetes az Azure-ban is.
A felhasználó csak az eredményt látja — mint egy vendég az étteremben, aki nem a konyhát figyeli, hanem élvezi, hogy minden gyorsan, pontosan és zökkenőmentesen történik.
Az Azure biztosítja az éttermet és a konyhát, a Kubernetes irányítja a szakácsokat, a konténerekben készülnek a fogások, és minden mikroszolgáltatás egy külön tálalás.
Ebben a cikkben lépésről lépésre megnézzük, hogyan hoztam létre a saját „felhőkonyhámat”, hogyan készítettem elő az „alapanyagokat”, és hogyan tálaltam végül a webalkalmazást úgy, hogy a világ bármely pontjáról elérhető legyen.
👨🍳 Kubernetes konyhanyelven – Alapfogalmak
| Kubernetes fogalom | Konyhai hasonlat | Mit jelent valójában |
|---|---|---|
| Cluster | 🏨 Az egész étterem | Egy komplett Kubernetes környezet: szerverek, konfiguráció, működés |
| Control Plane (Master) | 👨🍳🍽️ A konyhafőnök és menedzsment | Dönt: hol fussanak az appok, mikor induljanak új konténerek, hogyan működjön minden |
| AKS | 🍽️ Bérelhető fine-dining étterem séfekkel | Menedzselt Kubernetes a Microsofttól — nem neked kell üzemeltetni a clustert |
| Node | 👨🍳 Egy szakács / munkaállomás | Egy VM vagy szerver, ahol ténylegesen futnak az appok |
| Pod | 🥣 Egy tál, amiben a fogás elkészül | A legkisebb futtatási egység, ebben fut(nak) a konténer(ek) |
| Container | 🍝 Maga az étel/főzési folyamat | Az alkalmazás és környezete egy csomagban |
| Deployment | 📖 Recept és menüterv | Megmondod, hány példány fusson, hogyan induljon újra hiba esetén |
| Service | 🪟 A pult, ahol kiszolgálsz | A podok elérési pontja — hogy kívülről el lehessen érni az alkalmazást |
| Ingress | 🚪 Étterem bejárata és útvonalai | Domain név, URL útvonalak, HTTPS — merre jön be a vendég |
| Azure Container Registry (ACR) | 🧊 Hűtő / alapanyag raktár | Itt tárolod a konténerképeket (Docker image-ek) |
1. Hozzunk létre egy hűtőt — Azure Container Registry (ACR)
Ahogy a konyhában az alapanyagokat hűtőben tartjuk, az alkalmazásunk “alapanyagai” a konténerképek. Ezeket egy privát repository-ban tároljuk — ez az ACR.



Miért fontos privát registry?
védi a saját kódot és képeket
gyorsabb az Azure-on belül a letöltés
jogosultságot tudsz menedzselni rá
Beállításaim:
| Paraméter | Érték |
|---|---|
| Resource Group | laci-app-rg |
| Registry Name | primuszlaciacr |
| SKU | Basic (tanuláshoz elég) |
Belépés ACR-be CLI-vel:
Először Azure CLI-vel jelentkezünk be a Subscription-be:
az login --tenant "tenant id" --use-device-code

az acr login -n primuszlaciacr
az acr repository list --name primuszlaciacr --output table
Docker image építés és feltöltés:
docker build -t primuszlaciacr.azurecr.io/app:v1 .

docker push primuszlaciacr.azurecr.io/app:v1


Most már az alkalmazás képe biztonságban pihen a felhő hűtőjében.
2. AKS cluster létrehozása — a felhőkonyha felépítése
Ez lesz a “konyha” ahol a séf (Kubernetes) dolgozik.
Az Azure Portalon:
Kubernetes services → Create cluster



Miért AKS?
nem neked kell telepíteni a Kubernetes-t
Azure kezeli a node-okat, frissítéseket
automatikusan tud skálázni
integrálódik ACR-rel, identitással, monitorniggal
Beállítások (kezdőbarát, de profi):
| Beállítás | Érték | Miért? |
|---|---|---|
| Preset | Dev/Test | tanulás, olcsóbb |
| Region | West Europe | legközelebbi, gyors |
| Node OS | Ubuntu | Kubernetes natív |
| Node méret | D2s v6 | Optimális ár/teljesítmény |
| Node count | 2–5 autoscale | min. 2 kell HA-hoz |



Mi az a node?
A node a szakács — ő végzi a tényleges munkát a konyhában. A node valójában egy fizikai vagy virtuális gép, amelyen a konténerek futnak. Mindegyik node rendelkezik saját erőforrásokkal (CPU, memória, tárhely), és a Kubernetes ezekre osztja ki a feladatokat, vagyis a konténereket.
És mi az a pod?
A pod a tányér vagy fogás, amit a szakács elkészít. Egy podban futnak maguk a konténerek — gyakran egyetlen konténer, de lehet több is, ha szorosan együtt kell működniük. A pod tehát a legkisebb egység, amit a Kubernetes kezel, és amit a node „felszolgál”.
Ha egy node kiesik, a rendszer automatikusan áthelyezi a podokat más node-okra, vagyis más szakácsokra, hogy a vendég, azaz a felhasználó, ebből semmit se vegyen észre. A háttérben minden újraszerveződik, a „konyha” tovább működik, és az étel időben az asztalra kerül.
ACR összekötés — „engedélyezd a séfnek, hogy hozzáférjen a hűtőhöz”

💡 Tipp: Ha a pod „ImagePullBackOff” hibát kap, ellenőrizd, hogy az AKS valóban hozzáfér az ACR-hez — gyakori kezdő hiba!
3. Kapcsolódás AKS-hez — “lépj be a konyhába”
az aks get-credentials --resource-group laci-app-rg --name app-aks

Ez letölti a kubeconfig-ot és beállítja a Kubectl context-et.
Kubeconfig = séf menetrendje és jogosultságai a konyhában
Teszteljük:
kubectl get nodes

4. Deployment — „megmondjuk a séfnek, milyen ételt készítsen”
A Kubernetes nem úgy működik, hogy „futtatok egy konténert”.
Megmondod mit szeretnél, és ő intézi.
Ez a declarative konfiguráció — YAML-lal írjuk le.
Fő elemek:
| Fogalom | Mit jelent a konyhában |
|---|---|
| Deployment | étel recept / megrendelés |
| Pod | tál / edény |
| Container | maga az étel |
| Service | kiszolgáló pult |
A következő lépésben történik az alkalmazás tényleges telepítése az AKS-be a deployment.yaml fájl alapján. A YAML leírja, melyik konténer image-et használja a rendszer (itt az Azure Container Registry-ből húzza le az app:v1 verziót), valamint beállítja a szükséges erőforrásokat és portokat. A kubectl apply -f deployment.yaml parancs létrehozza a Deploymentet és a hozzá tartozó Service-t, így az alkalmazás külső IP-n keresztül is elérhetővé válik.

(Visual Studio Code a saját gépemen)
Alkalmazás deploy:
kubectl apply -f deployment.yaml

Ellenőrzés:
kubectl get pods

5. Publikus elérés — „Kiteesszük a kész ételt a pultra”
A service típusa:
LoadBalancer = publikus IP-t ad (Internet felől is elérhető)



Megjelenik:
External IP: 51.144.184.137
Böngészőben megnyitva: működő app

(Shopping Cart App – Forrás: Memi Lavi)
Eredmény
Most megtanultuk az alapokat:
privát registry-t használni
Docker image-et buildelni & pusholni
AKS cluster készíteni
appot deployolni Kubernetes-re
publikus szolgáltatást kitenni
🔭 Merre tovább?
Most, hogy elkészült az első AKS-deploy, ideje belekóstolni a Kubernetes igazi finomságaiba:
Helm chartok: hogyan lehet automatizálni a telepítéseket, hogy ne kézzel „főzzünk” minden alkalommal.
Monitoring és logolás: hogyan láss bele a „konyha” működésébe az Azure Monitor és a Log Analytics segítségével.
CI/CD integráció: hogyan tálaljuk frissen a kódot GitHub Actions vagy Azure DevOps segítségével.
Így válik a „felhőkonyha” nemcsak működőképessé, hanem valóban Michelin-csillagos rendszerré.
De hogy ez pontosan hogyan történik, az már egy következő blogban kerül tálalásra. 😉