- A K8s nem drága — a rossz méretezés az; a foglalt CPU/RAM 30–65%-a tipikusan kihasználatlan.
- A két fő pénzszivárgás: túl magas pod requests és az üresen futó kapacitás (idle workload, rossz bin-packing).
- A recept sorrendben: mérj (költség-láthatóság) → méretezz (requests/limits) → skálázz (HPA+VPA+Cluster Autoscaler/Karpenter) → pakolj sűrűn + spot.
- A spot node 60–90% megtakarítás, de csak megszakítás-tűrő, több replikás workloadhoz (PodDisruptionBudget).
- Namespace-szintű láthatóság OpenCost / Kubecost-tal; együtt jellemzően 40–60% megtakarítás, a stabilitás romlása nélkül.
01A lényeg 30 másodpercben
A Kubernetes nem drága — a rossz méretezés az. A költség túlnyomó része két dologból jön: a pod-ok túl magas requests értékei (a klaszter ezekre foglal node-ot, akkor is, ha a tényleges használat fele ennyi), és az üresen futó kapacitás (elfelejtett workload-ok, túl nagy node-ok, rossz bin-packing). A tipikus klaszterben a foglalt CPU/RAM 30-65%-a kihasználatlan.
A megfékezés receptje sorrendben: (1) mérj — namespace-szintű költség-láthatóság; (2) méretezd a requests/limits értékeket a valós használathoz; (3) skálázz automatikusan (HPA + VPA + Cluster Autoscaler/Karpenter); (4) pakold sűrűn (bin-packing) és használj spot node-ot a megszakítás-tűrő részhez. Együtt jellemzően 40-60% megtakarítás, a stabilitás romlása nélkül.
02Miért drága egy Kubernetes-klaszter?
A felhő számlája csak annyit lát, hogy hány node fut és mekkorák. Hogy ezeken belül mi pazarol, az a Kubernetes-réteg dolga. A leggyakoribb pénzszivárgások:
- Túlméretezett requests — a fejlesztő biztonságból 1 CPU / 2 GB-ot kér, a pod 0,2 CPU-t használ. A scheduler az 1 CPU-ra foglal node-ot.
- Idle workload-ok — elfelejtett dev/teszt namespace-ek, leállított projektek pod-jai, túlméretezett replikaszámok.
- Rossz bin-packing — sok félig üres node ahelyett, hogy kevesebb, jól megpakolt node futna.
- Nincs lefelé skálázás — éjszaka és hétvégén is a csúcskapacitás fut.
- Mellékköltségek — naplók/metrikák tárolása, egress, load balancer-ek, felügyelt control plane díja.
03A foglalt vs. tényleges használat rése
Ez a legbeszédesebb ábra: amit fizetsz (requests), és amit valóban használsz. A kettő közötti rés a közvetlen optimalizálási potenciál.
Amit fizetsz, az a foglalt requests; amit valóban használsz, gyakran a fele. A kettő közötti rés a közvetlen optimalizálási potenciál.
04Requests és limits — a helyes méretezés
A requests az, amit a pod garantáltan lefoglal — erre méretezi a scheduler a node-okat, tehát ez határozza meg a klaszter méretét és a számlát. A limits a felső korlát (CPU-nál throttle, memóriánál OOM-kill). A költségoptimalizálás kulcsa a requests valós használathoz közelítése:
- Nézd meg a tényleges használatot (P95/P99 a metrikákból), ne a csúcsot egyszer.
- A VPA (Vertical Pod Autoscaler) ajánlást ad — kezdd csak ajánló módban (
updateMode: Off), ne kapcsold azonnal automatikus frissítésre. - A túl alacsony limits instabilitást okoz — a requests-et csökkentsd, a limits-et óvatosan hangold.
- Vezess be namespace-szintű ResourceQuota-t és LimitRange-et, hogy ne tudjon bárki túlfoglalni.
A requests-et a tényleges használathoz (P95/P99 a metrikákból) igazítsd, ne az egyszeri csúcshoz. A VPA-t indítsd csak ajánló (Off) módban, a limits-et pedig óvatosan hangold — a túl alacsony limit instabilitást okoz.
05Autoscaling: HPA, VPA, Cluster Autoscaler, Karpenter
A három autoscaler különböző tengelyen dolgozik, és együtt adják a teljes képet:
- HPA — a pod-ok számát skálázza terhelés (CPU/RAM vagy egyedi metrika) szerint.
- VPA — a pod-ok méretét (requests/limits) igazítja a valós használathoz.
- Cluster Autoscaler — a node-ok számát igazítja a pod-igényhez, és lefelé is skáláz (üres node-ok leállítása).
- Karpenter (AWS, de terjed) — okosabb node-provizionálás: a pending pod-okhoz pont a megfelelő méretű és típusú (akár spot) node-ot indít, gyorsan és jó bin-packinggel.
A HPA és a VPA CPU-n nem szabad, hogy ütközzön (a HPA-t inkább egyedi metrikára vagy memóriára érdemes tenni, ha a VPA a CPU requests-et kezeli).
06Bin-packing és spot node-ok
A bin-packing azt jelenti, hogy a pod-okat kevesebb, jól megpakolt node-ra tömöríted, ahelyett hogy sok félig üres node futna. A scheduler beállításai (pl. a MostAllocated stratégia) és a Karpenter konszolidációja ezt segítik — kevesebb node, ugyanaz a kapacitás.
A spot (preemptible) node-ok 60-90%-kal olcsóbbak, de bármikor visszavehetők — ezért csak megszakítás-tűrő workloadhoz: batch, CI/CD, több replikás stateless szolgáltatás, dev/teszt. A recept: vegyes node-pool (kritikus rész on-demand, a többi spot), PodDisruptionBudget, és több replikás elosztás. Stateful, egyetlen replikás kritikus rendszerre nem való.
A spot (preemptible) node bármikor visszavehető, ezért csak megszakítás-tűrő workloadhoz: batch, CI/CD, több replikás stateless szolgáltatás, dev/teszt. Stateful, egyetlen replikás kritikus rendszerre ne tedd — PodDisruptionBudget és vegyes node-pool nélkül pláne.
07Mennyit hoz lépésenként?
A lépések halmozódnak. Indikatív, tipikus klaszterre vetített kumulatív megtakarítási potenciál (a kiindulóhoz képest):
08Költség-láthatóság — amit nem mérsz, nem optimalizálod
A felhő számlája node-szinten lát; Kubernetesben namespace / munkaterhelés / csapat / címke szintű bontás kell. Erre való az OpenCost (CNCF, nyílt forrású) vagy a Kubecost: megmutatja, melyik namespace/deployment mennyibe kerül, mennyi az idle kapacitás, és hol van right-sizing lehetőség konkrét ajánlással. A láthatóság teszi a költséget a csapatok felelősségévé (showback/chargeback) — ez a FinOps-kultúra alapja Kubernetesben is.
Kapcsolódó: a tágabb képhez lásd a FinOps — felhőköltség cikket, a platformdöntéshez a Kubernetes vs. VM összevetést, a teljes költségmodellhez pedig a felhő vs. on-prem TCO-kalkulátort.
09Gyakran ismételt kérdések
Miért drága egy Kubernetes-klaszter?
Főleg a túlméretezett pod requests és az üresen futó kapacitás miatt — a foglalt erőforrás 30-65%-a tipikusan kihasználatlan, de fizeted.
Mi a requests és a limits különbsége költség szempontból?
A requests határozza meg a klaszter méretét (erre foglal a scheduler), tehát a számlát; a limits a felső korlát. A requests-et kell a valós használathoz közelíteni.
Megéri a spot node?
Igen, 60-90% megtakarítás, de csak megszakítás-tűrő, több replikás workloadhoz, PodDisruptionBudgettel és vegyes node-pool-lal.
Mivel látom a Kubernetes-költségeket namespace szinten?
OpenCost (nyílt forrású) vagy Kubecost — namespace/deployment/címke szintű bontás, idle-kimutatás és right-sizing ajánlás.
Mi a HPA, a VPA és a Cluster Autoscaler szerepe?
A HPA (Horizontal Pod Autoscaler) a pod-ok SZÁMÁT skálázza terhelés szerint. A VPA (Vertical Pod Autoscaler) a pod-ok MÉRETÉT (requests/limits) ajánlja/állítja. A Cluster Autoscaler (vagy a Karpenter) a NODE-ok számát igazítja a pod-igényhez — felfelé és lefelé is, így nem futnak üresen node-ok. A három együtt: a pod-ok a terheléshez, a node-ok a pod-okhoz igazodnak, üres kapacitás nélkül.
10Optimalizáljuk a klaszteredet
Egy költség-audit (láthatóság bekapcsolása + right-sizing + autoscaling-terv) jellemzően hetek alatt megtérül a számlán. Megnézzük, hol szivárog a pénz a klaszteredben, és felépítjük a méretezést, autoscalinget és a spot-stratégiát — úgy, hogy a stabilitás egy pillanatra sem csúszik.