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 fogalomKonyhai hasonlatMit jelent valójában
Cluster🏨 Az egész étteremEgy komplett Kubernetes környezet: szerverek, konfiguráció, működés
Control Plane (Master)👨‍🍳‍🍽️ A konyhafőnök és menedzsmentDönt: hol fussanak az appok, mikor induljanak új konténerek, hogyan működjön minden
AKS🍽️ Bérelhető fine-dining étterem séfekkelMenedzselt Kubernetes a Microsofttól — nem neked kell üzemeltetni a clustert
Node👨‍🍳 Egy szakács / munkaállomásEgy VM vagy szerver, ahol ténylegesen futnak az appok
Pod🥣 Egy tál, amiben a fogás elkészülA legkisebb futtatási egység, ebben fut(nak) a konténer(ek)
Container🍝 Maga az étel/főzési folyamatAz alkalmazás és környezete egy csomagban
Deployment📖 Recept és menütervMegmondod, hány példány fusson, hogyan induljon újra hiba esetén
Service🪟 A pult, ahol kiszolgálszA podok elérési pontja — hogy kívülről el lehessen érni az alkalmazást
Ingress🚪 Étterem bejárata és útvonalaiDomain név, URL útvonalak, HTTPS — merre jön be a vendég
Azure Container Registry (ACR)🧊 Hűtő / alapanyag raktárItt 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 Grouplaci-app-rg
Registry Nameprimuszlaciacr
SKUBasic (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

 
Majd a container registry-be:
 
az acr login -n primuszlaciacr
 
Repository-k kilistázása:
az acr repository list --name primuszlaciacr --output table
 
 
Gondolat: ez olyan, mintha a szakácsod bejelentkezne a konyhába, különben nem veheti ki az alapanyagokat.

Docker image építés és feltöltés:

docker build -t primuszlaciacr.azurecr.io/app:v1 .
 
 
Docker desktop is kellett az image építéséhez.
 
 
Feltöltés az  ACR-be:
 
docker push primuszlaciacr.azurecr.io/app:v1
 
 
Az Azure portálon is megjelent:
 

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ékMiért?
PresetDev/Testtanulás, olcsóbb
RegionWest Europelegközelebbi, gyors
Node OSUbuntuKubernetes natív
Node méretD2s v6Optimális ár/teljesítmény
Node count2–5 autoscalemin. 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:

FogalomMit jelent a konyhában
Deploymentétel recept / megrendelés
Podtál / edény
Containermaga az étel
Servicekiszolgá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. 😉