Kubernetes náklady: Úspora 40–60 % (2026)

Prečo je Kubernetes najväčším zdrojom cloudového plytvania

Kubernetes sa stal de facto štandardom pre orchestráciu kontajnerov. Podľa prieskumu Cloud Native Computing Foundation (CNCF) z roku 2025 ho v produkcii používa viac ako 84 % organizácií. Lenže s masívnou adopciou prišiel aj masívny problém — väčšina firiem za svoje Kubernetes klastre platí výrazne viac, než by musela.

A štatistiky sú úprimne povedané dosť alarmujúce. Podľa Kubernetes Cost Benchmark Report od Cast AI z roku 2025 je priemerné využitie CPU v Kubernetes klastroch iba 10 % (pokles z 13 % v predchádzajúcom roku) a priemerné využitie pamäte dosahuje len 23 %. Čiže organizácie platia za zdroje, z ktorých reálne využívajú menej ako štvrtinu. Štúdia spoločnosti Wozz z roku 2026 to ešte potvrdila — takmer polovica kontajnerov spotrebúva menej ako tretinu svojej alokovanej pamäte a CPU.

V globálnom meradle sa cloudové plytvanie odhaduje na 28 až 35 % celkových výdavkov. Pri Kubernetes prostrediach je situácia ešte horšia. Kombinácia nepresného right-sizingu, chýbajúceho autoscalingu a osirelých zdrojov vedie k tomu, že firmy prichádzajú ročne o milióny eur. A to nie je prehnaná dramatizácia — je to čistá matematika.

V tomto sprievodcovi si prejdeme konkrétne, praktické kroky, ako tieto straty eliminovať. Right-sizing, autoscaling, správa node poolov, využívanie spot inštancií, nástroje na monitorovanie nákladov aj politiky governance — všetko s reálnymi príkladmi konfigurácie a kódu. Tak poďme na to.

Pochopenie štruktúry nákladov v Kubernetes

Predtým, než sa pustíme do optimalizácie, musíme pochopiť, odkiaľ náklady v Kubernetes prostredí vlastne prichádzajú. Veľa tímov vidí iba celkový účet za cloud a nemá poriadny prehľad o tom, ktoré workloady koľko stoja.

Hlavné zložky nákladov

Náklady v Kubernetes prostredí sa delia do niekoľkých kategórií:

Výpočtové zdroje (Compute) — cena za uzly (nodes), na ktorých bežia vaše pody. Toto je zvyčajne 60-70 % celkových Kubernetes nákladov a zároveň hlavný priestor na úspory.
Úložisko (Storage) — Persistent Volumes, EBS zväzky, managed disky. Osirelé a predimenzované úložisko pridáva 3-6 % zbytočných nákladov.
Sieťové náklady (Networking) — data transfer medzi availability zónami, regiónmi a k internetu. Často sa prehliadajú, ale dokážu tvoriť 10-15 % celkových nákladov.
Manažment klastra — poplatky za riadiacu rovinu (control plane). Napríklad AWS EKS účtuje 0,10 USD za hodinu za klaster.
Monitorovanie a logovanie — náklady na observability stack (CloudWatch, Datadog, Prometheus-as-a-Service).

Problém alokácie nákladov

Jednou z najväčších výziev je alokácia nákladov na konkrétne tímy a aplikácie. V tradičnom prostredí VM máte jasný vzťah: jedna VM = jedna aplikácia = konkrétny náklad. V Kubernetes ale zdieľa desiatky aplikácií rovnaké uzly a zistiť, kto koľko reálne spotrebúva, vyžaduje špecializované nástroje.

FinOps Foundation odporúča implementovať cost allocation cez Kubernetes labels a namespaces. Každý workload by mal mať definované labels ako team, environment, cost-center a application:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-gateway
  namespace: production
  labels:
    app: api-gateway
    team: platform-engineering
    cost-center: cc-1234
    environment: production
    tier: critical
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-gateway
  template:
    metadata:
      labels:
        app: api-gateway
        team: platform-engineering
        cost-center: cc-1234
        environment: production
        tier: critical
    spec:
      containers:
      - name: api-gateway
        image: api-gateway:v2.4.1
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1000m"
            memory: "1Gi"

Right-sizing: Základ každej optimalizácie

Right-sizing je proces nastavenia resource requests a limits tak, aby presne zodpovedali skutočným potrebám workloadu. Je to najdôležitejší a zároveň najčastejšie zanedbávaný aspekt Kubernetes optimalizácie. A z mojej skúsenosti — práve tu sa skrývajú tie najväčšie úspory.

Prečo je right-sizing taký dôležitý

Kubernetes plánovač (scheduler) rozmiestňuje pody na uzly na základe resource requests, nie na základe skutočnej spotreby. Ak pod žiada 2 CPU a 4 GB RAM, scheduler mu tieto zdroje rezervuje — aj keď pod reálne spotrebúva iba 0,3 CPU a 500 MB RAM. Zostatok je jednoducho „zamknutý" a nedostupný pre ostatné workloady.

Toto vedie k dvom zásadným problémom:

Predimenzovanie (over-provisioning) — pody žiadajú viac zdrojov, než potrebujú. Výsledkom je nízke využitie uzlov a zbytočné náklady. Podľa Cast AI je priemerné predimenzovanie CPU v Kubernetes klastroch 7-10x. Áno, čítate správne — sedem až desaťnásobok.
Poddimenzovanie (under-provisioning) — pody nemajú dostatok zdrojov a trpia throttlingom alebo OOM killmi. To vedie k degradácii výkonu a nestabilite.

Ako správne nastaviť resource requests a limits

Správne nastavenie vyžaduje analýzu reálneho správania workloadu v produkcii. Tu je odporúčaný postup:

Krok 1: Zber metrík. Nasaďte monitoring (Prometheus + Grafana, Datadog alebo podobný nástroj) a zbierajte metriky o využití CPU a pamäte minimálne 7-14 dní. Kratšie obdobie vám neukáže týždenné vzory.

Krok 2: Analýza vzorov. Identifikujte štandardné, špičkové a minimálne využitie. Dôležité je pozerať sa na P95 a P99 percentily, nie na priemer — priemer klame.

Krok 3: Nastavenie requests a limits. Odporúčaný prístup:

CPU requests — nastavte na P95 priemernú spotrebu. CPU je kompresibilný zdroj, takže pri prekročení limitu sa pod len spomalí, nespadne.
Memory requests — nastavte na P99 spotrebu s 10-15 % rezervou. Pamäť je nekompresibilný zdroj — pri prekročení sa pod zabije (OOM kill). Tu sa neoplatí šetriť príliš agresívne.
CPU limits — zvážte ich úplné odstránenie. CPU throttling spôsobuje latenčné problémy a mnohé tímy v roku 2026 CPU limits nepoužívajú vôbec.
Memory limits — nastavte na rovnakú hodnotu ako requests (alebo mierne vyššiu). Tým zabezpečíte QoS triedu Guaranteed.

Príklad Prometheus PromQL dotazu na analýzu CPU spotreby:

# P95 CPU spotreba za poslednych 14 dni pre konkretny deployment
quantile_over_time(0.95,
  rate(container_cpu_usage_seconds_total{
    namespace="production",
    container="api-gateway"
  }[5m])[14d:]
)

# Pomer realnej spotreby k pozadovanym zdrojom (request)
sum(rate(container_cpu_usage_seconds_total{
  namespace="production"
}[5m])) by (container, pod)
/
sum(kube_pod_container_resource_requests{
  resource="cpu",
  namespace="production"
}) by (container, pod)

Automatizácia right-sizingu pomocou VPA

Manuálny right-sizing je časovo náročný a rýchlo zastará. Vertical Pod Autoscaler (VPA) tento proces automatizuje — sleduje spotrebu a automaticky upravuje resource requests a limits.

VPA pracuje v troch režimoch:

Off — iba generuje odporúčania, ale nič nemení. Ideálne na začiatok, keď si chcete najprv overiť, čo by VPA navrhol.
Initial — nastaví zdroje pri vytvorení podu, ale existujúce pody nemodifikuje.
Auto — automaticky reštartuje pody s aktualizovanými zdrojmi. Pozor: spôsobuje krátke výpadky, tak s tým počítajte.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-gateway-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: api-gateway
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: api-gateway
      minAllowed:
        cpu: "100m"
        memory: "128Mi"
      maxAllowed:
        cpu: "2000m"
        memory: "4Gi"
      controlledResources: ["cpu", "memory"]
      controlledValues: RequestsAndLimits

Dôležité upozornenie: VPA a HPA (Horizontal Pod Autoscaler) sa nemajú používať súčasne na rovnakej metrike (napríklad CPU). VPA mení veľkosť podov, HPA mení ich počet — keď oba reagujú na rovnakú metriku, môžu sa dostať do konfliktu. Odporúčaná kombinácia je VPA na CPU/pamäť a HPA na vlastné metriky (napríklad počet požiadaviek v queue).

Autoscaling: Tri piliere dynamickej optimalizácie

Autoscaling je kľúčom k tomu, aby vaša infraštruktúra reagovala na skutočný dopyt namiesto toho, aby bola natrvalo predimenzovaná pre najhoršie scenáre. A úprimne, predimenzovanie „pre istotu" je jeden z najdrahších zvykov v IT. V Kubernetes existujú tri úrovne autoscalingu, ktoré spolu tvoria komplexný optimalizačný systém.

1. Horizontal Pod Autoscaler (HPA)

HPA automaticky upravuje počet replík deploymentu na základe pozorovaných metrík. Keď zaťaženie rastie, HPA pridáva pody. Keď klesá, odoberá ich. Jednoduché a elegantné.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-gateway-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-gateway
  minReplicas: 2
  maxReplicas: 20
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 25
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
      - type: Percent
        value: 100
        periodSeconds: 30
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: requests_per_second
      target:
        type: AverageValue
        averageValue: "1000"

Kľúčové nastavenia pre optimalizáciu nákladov:

stabilizationWindowSeconds pre scaleDown — nastavte na 300-600 sekúnd, aby sa predišlo príliš rýchlemu škálovaniu smerom nadol. Nič nie je horšie ako „flapping" medzi scale up a scale down.
scaleDown policies — obmedzte percentuálny pokles na 25-50 % za periódu, aby nedošlo k náhlemu výpadku kapacity.
Viaceré metriky — kombinujte CPU s business metrikami (requests per second, queue depth) pre presnejšie škálovanie.

2. Vertical Pod Autoscaler (VPA)

Ako sme si už popísali v sekcii o right-sizingu, VPA automaticky upravuje resource requests a limits podov. Je ideálny pre workloady, kde horizontálne škálovanie nedáva zmysel — napríklad pre databázy, stavy uchovávajúce služby alebo workloady s jednou replikou.

3. Cluster Autoscaler a Karpenter

Autoscaling podov je len polovica rovnice. Bez node-level autoscalingu sa vaše nákladové úspory nikdy nepremietnu do reálneho zníženia účtu — uzly, ktoré sa stali neefektívnymi po right-sizingu podov, musia byť skutočne ukončené. Inak platíte za prázdne železo (alebo virtuálne železo, presnejšie povedané).

Cluster Autoscaler je tradičný nástroj, ktorý pridáva a odoberá uzly na základe pending podov a nevyužitých uzlov. Funguje s node groups (AWS Auto Scaling Groups, GCP Managed Instance Groups, Azure VMSS).

Karpenter je moderná alternatíva od AWS (ale použiteľná aj inde), ktorá prináša zásadné vylepšenia:

Provisioning bez node groups — Karpenter dynamicky vyberá najvhodnejší typ inštancie na základe požiadaviek workloadu.
Rýchlejšie škálovanie — uzly sú k dispozícii za sekundy, nie minúty.
Konsolidácia — automaticky presúva pody a terminuje nevyužité uzly.
Natívna podpora spot inštancií — inteligentne kombinuje spot a on-demand.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: cost-optimized
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: ["5"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: "1000"
    memory: 2000Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
  weight: 50

Karpenter s consolidationPolicy: WhenEmptyOrUnderutilized priebežne konsoliduje workloady na menší počet uzlov a terminuje nepotrebné. Toto je kľúčové — bez konsolidácie sa right-sizing podov jednoducho neprejaví na účte.

Spot inštancie: Až 90 % úspory pre vhodné workloady

Spot inštancie (AWS), Preemptible VMs (GCP) a Spot VMs (Azure) ponúkajú až 60-90 % zľavu oproti on-demand cenám. Háčik? Cloud provider ich môže kedykoľvek odobrať s krátkym varovaním (2 minúty na AWS, 30 sekúnd na GCP).

Kubernetes je ale vlastne ideálna platforma pre spot inštancie, pretože jeho architektúra je navrhnutá na zvládanie výpadkov podov. Kľúčom je správna stratégia.

Ktoré workloady sú vhodné pre spot

Ideálne: Stateless mikroslužby s viacerými replikami, batch processing, CI/CD pipelines, vývojové a testovacie prostredia, tréning ML modelov s checkpointingom.
Nevhodné: Databázy, stateful služby s jednou replikou, kontrolné roviny, workloady s dlhým štartovacím časom. Tu by som naozaj nedoporučoval riskovať.

Stratégia zmiešaných node poolov

Najlepšia prax je rozdeliť klaster na viaceré node pooly:

Kritický pool (on-demand) — pre produkčné databázy, kontrolné roviny a služby s prísnymi SLA.
Štandardný pool (mix spot + on-demand) — pre produkčné stateless služby s viacerými replikami.
Úsporný pool (čisto spot) — pre vývojové/testovacie prostredia, batch joby a nekritické workloady.

Distribúciu podov medzi pooly riadite cez node affinity, taints a tolerations:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: batch-processor
  namespace: batch-jobs
spec:
  replicas: 10
  selector:
    matchLabels:
      app: batch-processor
  template:
    metadata:
      labels:
        app: batch-processor
    spec:
      # Tolerovanie spot taintu
      tolerations:
      - key: "kubernetes.azure.com/scalesetpriority"
        operator: "Equal"
        value: "spot"
        effect: "NoSchedule"
      # Preferencia pre spot uzly
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            preference:
              matchExpressions:
              - key: "karpenter.sh/capacity-type"
                operator: In
                values: ["spot"]
      # Pod disruption budget pre graceful handling
      terminationGracePeriodSeconds: 120
      containers:
      - name: batch-processor
        image: batch-processor:v1.8
        resources:
          requests:
            cpu: "1000m"
            memory: "2Gi"
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: batch-processor-pdb
  namespace: batch-jobs
spec:
  maxUnavailable: "30%"
  selector:
    matchLabels:
      app: batch-processor

Diverzifikácia typov inštancií

Kľúčová stratégia pre zníženie rizika prerušení je diverzifikácia. Namiesto špecifikovania jedného typu inštancie umožnite Karpenteru alebo Cluster Autoscaleru vyberať z viacerých rodín a veľkostí. Spot kapacita sa líši podľa typu inštancie a regiónu — čím väčšiu flexibilitu poskytnete, tým nižšie je riziko prerušenia a tým nižšia cena.

Na AWS odporúčame povoliť minimálne 10-15 rôznych typov inštancií naprieč viacerými rodinami (c5, c6i, c6g, m5, m6i, m6g, r5, r6i). Zahrnutie ARM inštancií (Graviton) prináša ďalších 20-30 % úspor oproti x86 ekvivalentom. Graviton je podľa mňa jedno z najlepších „nízko visiacich ovocie" na AWS.

Eliminácia cloudového odpadu v Kubernetes

Aj s perfektným right-sizingom a autoscalingom existujú ďalšie zdroje plytvania, ktoré si vyžadujú systematický prístup. Poďme si ich prejsť.

Osirelé Persistent Volumes

Keď sa pod alebo deployment zmaže, Persistent Volumes (PV) a Persistent Volume Claims (PVC) často zostanú. Podľa štatistík to pridáva 3-6 % zbytočných nákladov. Nasledujúci skript vám pomôže identifikovať osirelé PVC:

#!/bin/bash
# Identifikacia osirelenych PVC - nie su pouzivane ziadnym podom

echo "=== Osirelene Persistent Volume Claims ==="
echo ""

# Ziskanie vsetkych PVC vo vsetkych namespacoch
ALL_PVC=$(kubectl get pvc --all-namespaces -o jsonpath=\
'{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\n"}{end}')

# Ziskanie PVC pouzivanych v podoch
USED_PVC=$(kubectl get pods --all-namespaces -o jsonpath=\
'{range .items[*]}{range .spec.volumes[?(@.persistentVolumeClaim)]}{.metadata.namespace}/{.persistentVolumeClaim.claimName}{"\n"}{end}{end}')

# Porovnanie
echo "$ALL_PVC" | while read pvc; do
  if ! echo "$USED_PVC" | grep -q "^${pvc}$"; then
    NAMESPACE=$(echo "$pvc" | cut -d'/' -f1)
    NAME=$(echo "$pvc" | cut -d'/' -f2)
    SIZE=$(kubectl get pvc "$NAME" -n "$NAMESPACE" \
      -o jsonpath='{.spec.resources.requests.storage}')
    echo "OSIRELENE: $pvc (velkost: $SIZE)"
  fi
done

Nečinné a predimenzované namespace-y

Vývojové, testovacie a staging prostredia sú notorické tým, že po nich zostávajú zabudnuté namespace-y s bežiacimi workloadmi. Kto z nás to nepozná? Implementujte automatické TTL politiky:

apiVersion: v1
kind: Namespace
metadata:
  name: feature-branch-xyz
  labels:
    environment: development
    created-by: ci-pipeline
  annotations:
    # Automaticke zmazanie po 72 hodinach
    janitor/ttl: "72h"
    cost-center: dev-team-alpha
    owner: [email protected]

Nástroje ako kube-janitor dokážu automaticky mazať namespace-y a zdroje na základe TTL anotácií. V praxi to znamená, že feature branch prostredie sa automaticky uprace po 72 hodinách, bez manuálneho zásahu. Ušetrí vám to viac, než by ste čakali.

Neefektívne kontajnerové obrazy

Predimenzované kontajnerové obrazy priamo ovplyvňujú náklady — väčšie obrazy znamenajú dlhšie pull časy, väčšiu spotrebu úložiska a pomalší štart podov. Prechod z obrazov založených na Ubuntu alebo Debian na Alpine alebo distroless obrazy môže znížiť veľkosť o 80-95 %. Je to jednoduchá zmena s veľkým dopadom.

Nástroje na monitorovanie a optimalizáciu nákladov

Bez viditeľnosti nemôžete optimalizovať. To je proste fakt. V roku 2026 existuje niekoľko vyspelých nástrojov špeciálne navrhnutých pre Kubernetes cost management.

OpenCost — open-source základ

OpenCost je CNCF sandbox projekt, ktorý poskytuje real-time alokáciu nákladov podľa klastra, uzla, namespace-u, controllera a podu. Je vendor-neutrálny a funguje s AWS, Azure aj GCP.

Kľúčové vlastnosti v roku 2026:

Multi-cloud podpora — jednotný pohľad na náklady naprieč všetkými cloud providermi.
MCP server — nový Model Context Protocol server umožňuje AI agentom pristupovať k nákladovým dátam cez štandardizované rozhranie.
Carbon cost tracking — sledovanie uhlíkovej stopy cloudových zdrojov.
Integrácia s Prometheus — natívne exportovanie metrík do existujúceho monitoring stacku.

Inštalácia OpenCost je pomerne jednoduchá cez Helm:

# Instalacia OpenCost cez Helm
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="production-eu-west-1" \
  --set opencost.ui.enabled=true \
  --set opencost.exporter.aws.access_key_id="" \
  --set opencost.exporter.aws.secret_access_key="" \
  --set opencost.exporter.aws.spot_data_bucket="my-spot-data-feed" \
  --set opencost.exporter.aws.spot_data_region="eu-west-1"

# Overenie instalacie
kubectl get pods -n opencost
kubectl port-forward -n opencost svc/opencost 9090:9090

Kubecost — enterprise riešenie

Kubecost (od roku 2024 súčasť IBM) rozširuje open-source základ OpenCost o pokročilé funkcie. Podľa Kubecost dokáže automaticky generovať odporúčania, ktoré vedú k 30-50 % úspore na infraštruktúrnych nákladoch.

Oproti OpenCost ponúka:

Advanced reconciliation — zohľadňuje zľavy, spot pricing, kredity a vlastné cenové dohody.
Multi-cluster dashboardy — centralizovaný pohľad na náklady naprieč desiatkami klastrov.
Automatizované akcie — nielen odporúčania, ale aj automatické nastavenie resource requests.
Alerting a budgeting — upozornenia pri prekročení rozpočtu na úrovni tímu alebo namespace-u.

Cloud-natívne nástroje

Každý cloud provider ponúka aj vlastné nástroje pre Kubernetes cost management:

AWS: AWS Cost Explorer s EKS tagging, AWS Compute Optimizer pre right-sizing odporúčania, Kubecost integrácia v EKS konzole.
Azure: Azure Cost Management + Billing s AKS integráciou, Azure Advisor pre optimalizačné odporúčania.
GCP: GKE Cost Allocation (natívna funkcia GKE), Google Cloud Billing dashboardy s namespace-level detailom.

Governance a politiky pre nákladovú kontrolu

Technické nástroje sú iba jedna strana mince. Bez správnych politík a governance sa optimalizácie rýchlo degradujú — vývojári nasadia nové workloady bez resource requests a celý cyklus začne odznova. Videl som to opakovane.

Resource Quotas a Limit Ranges

Kubernetes poskytuje natívne mechanizmy na vynútenie nákladových limitov na úrovni namespace-u:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: production-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "20"
    requests.memory: "40Gi"
    limits.cpu: "40"
    limits.memory: "80Gi"
    persistentvolumeclaims: "10"
    pods: "50"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: team-alpha
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    max:
      cpu: "4"
      memory: "8Gi"
    min:
      cpu: "50m"
      memory: "64Mi"
    type: Container

ResourceQuota definuje maximálne agregátne zdroje pre namespace — žiadny tím nemôže prekročiť pridelený rozpočet. LimitRange zasa nastavuje predvolené hodnoty pre kontajnery, ktoré nemajú definované requests/limits, a obmedzuje maximálnu veľkosť jednotlivého kontajnera.

Policy engines: OPA Gatekeeper a Kyverno

Pre komplexnejšie politiky použite policy engine. Open Policy Agent (OPA) Gatekeeper alebo Kyverno umožňujú definovať pravidlá, ktoré sa vynucujú pri každom API requeste na klaster:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-requests
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: validate-resources
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: >-
        Vsetky kontajnery musia mat definovane CPU a memory
        requests. Kontaktujte platform team pre pomoc
        s nastavenim spravnych hodnot.
      pattern:
        spec:
          containers:
          - resources:
              requests:
                memory: "?*"
                cpu: "?*"
  - name: require-cost-labels
    match:
      any:
      - resources:
          kinds:
          - Deployment
          - StatefulSet
          - DaemonSet
    validate:
      message: >-
        Vsetky workloady musia mat labels: team, cost-center
        a environment.
      pattern:
        metadata:
          labels:
            team: "?*"
            cost-center: "?*"
            environment: "?*"

Táto politika zabezpečí, že žiadny workload sa nedostane do klastra bez definovaných resource requests a povinných cost allocation labels. Je to prevencia — a prevencia je vždy efektívnejšia ako následná náprava.

Porovnanie nákladov: EKS vs. AKS vs. GKE v roku 2026

Pri plánovaní Kubernetes stratégie je užitočné porovnať cenové modely troch hlavných cloud providerov:

AWS EKS: 0,10 USD/hodina za klaster (control plane). Compute náklady závisia od typu EC2 inštancií. EKS Auto Mode (s integrovaným Karpenterom) automatizuje správu uzlov a ponúka až 60-75 % úspory v kombinácii s optimalizačnými nástrojmi.
Google GKE: GKE Autopilot mode — platíte iba za skutočne spotrebované zdroje podmi, nie za uzly. GKE Standard — 0,10 USD/hodina za klaster plus cena uzlov. Committed Use Discounts ponúkajú až 57 % zľavu.
Azure AKS: Kontrolná rovina je zadarmo (za Standard tier sa platí za uptime SLA). Spot VM pooly s prioritou nízka cena. Azure Reservations s až 72 % zľavou.

Zaujímavou voľbou pre workloady s nepredvídateľnou záťažou je GKE Autopilot, kde platíte per-pod a nemusíte sa starať o správu uzlov. Pre predvídateľné workloady s vysokým využitím je zvyčajne najvýhodnejšia kombinácia Reserved Instances/Savings Plans s on-demand a spot.

Praktický akčný plán: 30-dňová optimalizačná roadmapa

Na záver prinášame konkrétny 30-dňový plán, ako začať s optimalizáciou nákladov na Kubernetes. Nie je to teória — sú to kroky, ktoré fungujú v praxi.

Týždeň 1: Viditeľnosť

Nasaďte OpenCost alebo Kubecost na všetky klastre.
Implementujte povinné cost allocation labels (team, cost-center, environment).
Vytvorte baseline — zdokumentujte aktuálne mesačné náklady a využitie.
Identifikujte top 10 najdrahších namespace-ov a workloadov.

Týždeň 2: Quick wins

Zmazajte osirelé PVC, nepoužívané Load Balancery a staré snapshoty.
Vypnite alebo zmenšite dev/test prostredia mimo pracovných hodín.
Nasaďte VPA v režime Off na produkčné workloady a analyzujte odporúčania.
Implementujte LimitRange pre predvolené resource requests vo všetkých namespace-och.

Týždeň 3: Autoscaling a spot

Nasaďte HPA na stateless produkčné služby.
Nakonfigurujte Karpenter alebo Cluster Autoscaler s konsolidáciou.
Vytvorte spot node pool pre nekritické workloady.
Migrujte dev/test prostredia na spot inštancie.

Týždeň 4: Governance a kontinuálna optimalizácia

Nasaďte Kyverno alebo OPA Gatekeeper s politikami pre resource requests a labels.
Implementujte ResourceQuotas pre každý tím.
Nastavte alerting na prekročenie rozpočtu a anomálie v nákladoch.
Vytvorte mesačný FinOps review proces — porovnanie skutočných nákladov s baseline.

Podľa skúseností organizácií, ktoré implementovali tieto kroky, je realistická úspora 40-60 % na Kubernetes nákladoch v priebehu prvých 90 dní. Najväčší podiel úspor typicky pochádza z right-sizingu (15-25 %), spot inštancií (15-20 %) a eliminácie plytvania (10-15 %).

Záver: Optimalizácia nie je jednorazový projekt

Optimalizácia nákladov na Kubernetes nie je niečo, čo urobíte raz a zabudnete na to. Je to kontinuálny proces, ktorý vyžaduje kombináciu správnych nástrojov, automatizácie a organizačnej kultúry. Workloady sa menia, ceny sa menia, nové služby vznikajú — a s nimi aj nové príležitosti na úspory.

Kľúčové princípy, ktoré by mali riadiť vašu stratégiu:

Merajte pred optimalizáciou — bez dát robíte iba hádky.
Automatizujte všetko, čo sa dá — manuálne procesy sú pomalé a nespoľahlivé.
Začnite s quick wins — osirelé zdroje a predimenzované inštancie sú nízko visiace ovocie.
Budujte kultúru cost-awareness — keď vývojári vidia náklady svojich služieb, správajú sa zodpovednejšie.
Iterujte — každý mesiac hľadajte ďalšie príležitosti na optimalizáciu.

V kombinácii s agentickými FinOps nástrojmi, o ktorých sme písali v našom predchádzajúcom článku, máte k dispozícii kompletný arzenál na to, aby vaše Kubernetes prostredia bežali efektívne, spoľahlivo a za rozumnú cenu. Začnite dnes — každý deň bez optimalizácie je deň, keď zbytočne platíte.