Kubernetes költségoptimalizálás 2026: OpenCost, Kubecost és Karpenter gyakorlati útmutató

Frissítve: 2026. június 9.

A Kubernetes költségoptimalizálás 2026-ban a pontos pod-szintű resource requests beállítását, az autoscaling (Karpenter, HPA, VPA) finomhangolását, spot/preemptible node-ok használatát és a klaszter-szintű láthatóságot jelenti OpenCost vagy Kubecost segítségével. Együtt ezek tipikusan 40–70% megtakarítást eredményeznek anélkül, hogy a megbízhatóság sérülne. A CNCF FinOps Foundation 2026-os jelentése szerint a Kubernetes-t futtató szervezetek 49%-a túlfizet a klaszter-erőforrásokért, és a leggyakoribb ok az alulhasznált pod requests és a rosszul méretezett node-pool-ok. Ez az útmutató megmutatja, hogyan kerüld el ezt a hibát konkrét parancsokkal, YAML példákkal és mérhető megtakarítási stratégiákkal.

• A Kubernetes klaszterek átlagos CPU-kihasználtsága 13% a Datadog 2026-os Container Report szerint, és a túlméretezett resources.requests a legnagyobb költségszivárgás.
• Az OpenCost (CNCF incubating projekt) ingyenes alternatívája a kereskedelmi Kubecost-nak, és FOCUS 1.0 specifikációt támogat a 2026.1 verziótól.
• A Karpenter v1.2 (2026. március) bin-packing optimalizálása átlagosan 35%-kal csökkenti a node-számot a Cluster Autoscaler-hez képest.
• A spot/preemptible node-ok és a megfelelő Pod Disruption Budget kombinációja 60–90% megtakarítást ad stateless workload-okon.
• A VPA recommender üzemmódban biztonságos: ad ajánlásokat anélkül, hogy újraindítaná a pod-okat. Ezzel kezdd a right-sizinget production-ben.
• A namespace-szintű showback chargeback-té érlelése (cost allocation tags-szel) megduplázza a team-ek költségtudatosságát egy FinOps Foundation 2026-os tanulmány szerint.

Miért drágul el a Kubernetes ennyire?

Őszintén szólva, a Kubernetes elképesztően rugalmas, és pontosan ezért a legnagyobb költséggenerátor a felhőben. A Datadog 2026-os State of Cloud Costs jelentése szerint egy átlagos production klaszter CPU-kihasználtsága mindössze 13%, a memóriáé pedig 32%. Vagyis a node-ok 70–85%-áért lényegében semmiért fizetsz. Az okok három fő tényezőre bonthatók.

Túlméretezett requests. A fejlesztők biztonsági okból gyakran 2x–10x annyi CPU-t és memóriát kérnek, mint amennyit a pod ténylegesen használ. Mivel a Kubernetes scheduler a requests alapján dönt (nem a tényleges felhasználás alapján), ez egyenesen a számládhoz megy. Egy pod, amely 100m CPU-t használ, de 1000m-t kér, 10x annyiba kerül, mint kéne.

Rosszul méretezett node-pool-ok. Sok csapat egyetlen, általános célú node-pool-t használ (pl. m5.2xlarge az AWS-en), pedig a workload-ok terhelése heterogén. Memória-intenzív pod-ok pazarolják a CPU-t, CPU-intenzív pod-ok pedig kihagyják a memóriát. Tipikus bin-packing katasztrófa.

Hiányzó visibility. A Kubernetes alapból nem mutatja meg, melyik namespace, deployment vagy team mennyit fogyaszt. Showback nélkül nincs felelősség, és a költségek csendben emelkednek. Ezért elengedhetetlen egy költségmegfigyelő réteg. Itt jön be az OpenCost és a Kubecost.

OpenCost vs. Kubecost: melyiket válaszd 2026-ban?

Mielőtt bármit optimalizálnál, mérni kell. Két fő eszközöd van: az OpenCost (CNCF incubating projekt) és a Kubecost (kereskedelmi termék, az IBM tulajdonában). Az OpenCost a Kubecost open-source magjából nőtt ki, és 2026.1 verziótól natívan támogatja a FOCUS 1.0 (FinOps Open Cost and Usage Specification) export formátumot.

Tulajdonság	OpenCost	Kubecost
Licenc	Apache 2.0 (ingyenes)	Free tier + Enterprise (kereskedelmi)
Klaszter támogatás	Korlátlan	Free: 1 klaszter; Enterprise: korlátlan
Adatmegőrzés	Saját Prometheus (korlátlan)	Free: 15 nap; Enterprise: korlátlan
Multi-cloud (AWS, Azure, GCP)	Igen	Igen
FOCUS 1.0 export	Igen (2026.1+)	Igen (Enterprise)
Beépített ajánlórendszer	Alapszintű right-sizing	Fejlett (savings reports, idle detection)
SSO és RBAC	Nincs (saját megoldás)	Enterprise-ban
Telepítési idő	~10 perc Helm-mel	~10 perc Helm-mel

A legtöbb csapat számára az OpenCost a jó kezdés: ingyenes, CNCF-támogatott, és minden alapvető láthatóságot biztosít. Az utolsó projektemen egy 80 node-os klaszteren 25 perc alatt élesben volt, és már az első héten kibukott három teljesen idle namespace. A telepítés Helm-mel pofonegyszerű:

helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm repo update
helm install opencost opencost/opencost \
  --namespace opencost \
  --create-namespace \
  --set opencost.exporter.defaultClusterId=prod-eu-west-1 \
  --set opencost.prometheus.internal.enabled=true

Pár perc múlva a port-forward után (kubectl port-forward -n opencost svc/opencost 9090:9090) megnyithatod a http://localhost:9090 címet, és látod a namespace-szintű költségbontást. Ha enterprise jellegű funkciók kellenek (multi-cluster aggregáció, savings reports, idle workload detection beépítve, SSO), válaszd a Kubecost-ot. Az OpenCost GitHub repó is jó forrás, ha mélyebbre akarsz ásni a metrikák körül.

Pod resource requests és right-sizing VPA-val

A legnagyobb gyors megtakarítás a pod requests pontosabbra szabásából jön. A Vertical Pod Autoscaler (VPA) recommender módban biztonságosan futtatható production-ben, mert csak ajánlásokat ad, nem indítja újra a pod-okat.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-server-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  updatePolicy:
    updateMode: "Off"   # csak ajanlas, nincs ujrainditas
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      minAllowed:
        cpu: 50m
        memory: 64Mi
      maxAllowed:
        cpu: 4
        memory: 8Gi
      controlledResources: ["cpu", "memory"]

Hagyd futni 7–14 napig, hogy lefedje a peak load periódusokat is, majd kérdezd le az ajánlást:

kubectl describe vpa api-server-vpa -n production | grep -A 10 "Recommendation"

Praktikus szabály 2026-ra: állítsd a requests-et a p95 felhasználás 1.2x-esére, a limits-et pedig a p99 1.5x-esére. Ez biztosítja, hogy a normál terhelés alatt ne legyen throttling, de ne fizess fantom kapacitásért.

Karpenter vs. Cluster Autoscaler: a node-pool forradalom

A klasszikus Cluster Autoscaler (CAS) előre definiált node-csoportokat skáláz, minden új pod-hoz egy létező pool-ból ad node-ot. A Karpenter (eredetileg az AWS-től, ma már EKS, Azure AKS és GKE-n is fut) ezzel szemben workload-vezérelt: minden pending pod-hoz a leg-cost-hatékonyabb instance típust választja ki real-time.

A Karpenter v1.2 (2026. március) bin-packing algoritmusa átlagosan 35%-kal csökkenti a node-számot a CAS-hez képest a CNCF 2026-os benchmark szerint. Egy minimális Karpenter NodePool spot-támogatással így néz ki:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
      - key: kubernetes.io/arch
        operator: In
        values: ["amd64", "arm64"]
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]
      - key: karpenter.k8s.aws/instance-category
        operator: In
        values: ["c", "m", "r"]
      - key: karpenter.k8s.aws/instance-generation
        operator: Gt
        values: ["2"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: 1000
    memory: 1000Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

A consolidationPolicy: WhenEmptyOrUnderutilized a 2026-os v1.2 új feature: automatikusan konszolidálja a részben kihasznált node-okat, ha jobb (olcsóbb) elrendezés lehetséges. Ez tipikusan további 10–15% megtakarítást jelent a sima emptiness-alapú konszolidációhoz képest.

Hogyan használj spot instanciákat Kubernetes-en?

A spot/preemptible node-ok 60–90%-kal olcsóbbak, mint az on-demand. A Kubernetes-en az igazi kérdés nem az, hogy használd-e őket, hanem hogy melyik workload-ot tedd rájuk. Általános szabályok 2026-ra:

• Stateless web/API: 100% spot, megfelelő replikaszámmal (≥3) és Pod Disruption Budget-tel.
• Batch / CI runners / ML training: 100% spot, mert checkpointable és restartolható.
• Stateful (DB, Redis primary): 0% spot, használj on-demand-ot vagy reserved instance-t.
• Kontrol plane addon-ok (ingress, monitoring): Kevert; PDB-vel 50–70% spot megengedhető.

Kötelező Pod Disruption Budget minden spot-on futó deployment-hez:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-server-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: api-server

Ha a spot mechanikájának mélyebb háttere is érdekel (interrupt handling, diverzifikáció, fallback on-demand-ra), olvasd el a spot instanciák teljes útmutatóját 2026-ra, ami minden cloud provider-re külön lebontva tárgyalja a témát.

HPA, VPA és KEDA: a workload-szintű autoscaling

A node-szintű autoscaling önmagában nem elég, a pod-szintűt is finomhangolni kell. Három eszköz dolgozik együtt.

HPA (Horizontal Pod Autoscaler)

Replikaszámot skáláz CPU, memória vagy custom metrikák alapján. Klasszikus webes workload-ra ideális. Példa egy CPU-alapú HPA-ra:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 3
  maxReplicas: 30
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

VPA (Vertical Pod Autoscaler)

Az egyes pod-ok request/limit értékeit skálázza. Mint fent láttuk, recommender módban biztonságos production-ben.

KEDA (Kubernetes Event-Driven Autoscaling)

A KEDA event-source-okra skáláz: Kafka topic lag, SQS queue depth, Prometheus metric, Postgres rows, stb. 2026 márciusától CNCF Graduated státuszban van. Egy SQS-alapú példa:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: worker-scaler
spec:
  scaleTargetRef:
    name: queue-worker
  minReplicaCount: 0   # skalazas 0-ra, amikor ures a queue
  maxReplicaCount: 50
  triggers:
  - type: aws-sqs-queue
    metadata:
      queueURL: https://sqs.eu-west-1.amazonaws.com/123456/work-queue
      queueLength: "5"
      awsRegion: eu-west-1
    authenticationRef:
      name: aws-credentials

A minReplicaCount: 0 a KEDA igazi szuperereje: scale-to-zero éjszakai/hétvégi periódusokra, ami a batch jellegű worker-eknél 60–80% megtakarítást ad. Egy korábbi projektemen ez egyetlen worker pool-on havi kb. 1700 dollárt nyírt le.

Namespace-szintű cost allocation és showback

A showback (kinek mennyibe kerül a klaszter része) az első lépés a chargeback-hez (átszámlázáshoz). Az OpenCost és Kubecost is namespace, deployment, label és annotation alapján bontja a költséget.

Praktikus megközelítés:

1. Vezess be kötelező label-okat minden namespace-en: team, cost-center, environment. Kapu (gate) Kyverno vagy OPA policy-val.
2. Konfiguráld az OpenCost-ot úgy, hogy ezeket a label-okat aggregálja a CSV/FOCUS exportban.
3. Generálj heti CSV-t a finance team-nek és küldj automatikus Slack riportot a team lead-eknek.

Egy Kyverno policy, amely kötelezővé teszi a team label-t minden új namespace-en:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-team-label
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-team-label
    match:
      any:
      - resources:
          kinds: ["Namespace"]
    validate:
      message: "Minden namespace-nek kotelezo a 'team' label."
      pattern:
        metadata:
          labels:
            team: "?*"

A FinOps Foundation alapelvei szerint a showback szervezeti elköteleződés nélkül nem működik. Havi review meeting kell, ahol a team lead-ek átnézik a saját számukat.

Idle pod-ok és zombie workload-ok kiszűrése

A "zombie workload" olyan deployment, service vagy PVC, amit senki nem használ, de fut. Klasszikus okok: elhagyott staging environment, kísérleti POC, távozott munkatárs tesztje. Egy gyors script, amely megtalálja az utolsó 14 napban 1%-nál kevesebb CPU-t használó pod-okat (Prometheus + kubectl):

#!/bin/bash
# Idle pod-ok keresese az elmult 14 napban (Prometheus query)
PROM="http://prometheus.monitoring:9090"

curl -sG "${PROM}/api/v1/query" \
  --data-urlencode 'query=avg_over_time(rate(container_cpu_usage_seconds_total{container!="",container!="POD"}[5m])[14d:5m]) < 0.01' \
  | jq -r '.data.result[] | "\(.metric.namespace)/\(.metric.pod): \(.value[1]) CPU"'

Még praktikusabb: az OpenCost /savings endpoint-ja közvetlenül megadja az idle workload-ok listáját és a becsült havi megtakarítást. Heti CronJob-bal hívd meg, és a kimenetet küldd Slack-re. A team-eknek két hetük van reagálni, különben a következő hónapban a deployment leskálázódik 0-ra.

Kubernetes FinOps érettségi modell 2026-ra

A FinOps Foundation érettségi modellje három szintet különböztet meg: Crawl, Walk, Run. Kubernetes kontextusban így néz ki:

• Crawl (0–3 hónap): OpenCost telepítve, namespace label-ok kötelezőek, VPA recommender mód, alapvető HPA. Várható megtakarítás: 15–25%.
• Walk (3–9 hónap): Karpenter consolidation aktív, spot node-ok 50%+ stateless workload-on, KEDA scale-to-zero batch worker-eken, heti showback riportok. Várható megtakarítás: +20–30%.
• Run (9+ hónap): FOCUS 1.0 export integráció a finance rendszerrel, chargeback éles, automatikus idle workload reclaim, multi-cluster cost aggregáció, PR-szintű cost gate-ek (pl. Infracost). Várható összesített megtakarítás: 50–70%.

Ha a 2026-os év terveidben szerepel a hosszabb távú elköteleződési kedvezmények (Reserved Instances, Savings Plans, GCP CUD) használata is, nézd át a foglalt instanciák, Savings Plans és CUD-ok összehasonlító útmutatónkat. A Kubernetes baseline (stabil node-ok) ideális jelölt savings plan-re, miközben a peak terhelést spot fedezi.

Gyakran Ismételt Kérdések

Mennyit lehet megtakarítani Kubernetes költségoptimalizálással?

A FinOps Foundation 2026-os jelentése szerint a teljes optimalizálási folyamat (right-sizing + Karpenter + spot + scale-to-zero + idle reclaim) átlagosan 50–70% megtakarítást ad. Az első három hónapban már a request right-sizing 15–25%-ot hoz minimális kockázattal.

Mi a különbség az OpenCost és a Kubecost között?

Az OpenCost a Kubecost open-source magja, CNCF incubating projekt, Apache 2.0 licenc alatt, korlátlanul használható. A Kubecost kereskedelmi termék, amely SSO-t, korlátlan adatmegőrzést, multi-cluster aggregációt és fejlettebb savings ajánlórendszert kínál Enterprise tier-ben. Kisebb csapatoknak az OpenCost bőven elég.

A Karpenter felváltja a Cluster Autoscaler-t?

A legtöbb új AWS EKS, Azure AKS és GKE telepítésen 2026-ban igen. A Karpenter v1.2 bin-packing és consolidation funkciói jellemzően 30–40%-kal csökkentik a node-számot, és gyorsabban reagál. A Cluster Autoscaler ott marad releváns, ahol fix node-csoport méretek és előrejelezhető skálázódás kell (pl. szigorúan szabályozott környezetek).

Biztonságos a VPA használata production-ben?

Igen, updateMode: "Off" (recommender mód) esetén teljesen biztonságos: a VPA csak ajánlásokat generál, nem indítja újra a pod-okat. Az Auto mód viszont kockázatos stateful vagy nagy memóriaigényű workload-okon, és NEM kombinálható HPA-val ugyanazon a metrikán.

Hogyan állítsam be a Kubernetes resource requests-eket helyesen?

Gyűjts 7–14 napnyi felhasználási adatot (Prometheus + VPA recommender), majd állítsd a requests-et a p95 felhasználás 1.2x-esére, a limits-et pedig a p99 1.5x-esére. A requests-et SOHA ne állítsd magasabbra, mint amit valóban szükségesnek tartasz, mert a scheduler ez alapján foglal kapacitást, és te ezért fizetsz.