Optimalizace nákladů na Kubernetes v roce 2026: Praktický průvodce right-sizingem a autoscalingem

Úvod: Kubernetes a skrytá cena kontejnerové orchestrace

Kubernetes se stal synonymem moderní cloudové infrastruktury – to asi nikoho nepřekvapí. Podle průzkumů CNCF z roku 2025 využívá 96 % organizací Kubernetes v produkčním prostředí, což z něj dělá de facto standard pro orchestraci kontejnerů. Jenže s masivní adopcí přichází i masivní problém: náklady, které rostou rychleji, než byste čekali, a které málokdo skutečně chápe.

Čísla mluví jasně. 68 % podů v typickém Kubernetes clusteru požaduje 3–8× více paměti, než skutečně využívá. Průměrné využití CPU requestů se pohybuje kolem 15–25 %, u memory requestů pak na 40–55 %. Upřímně – to znamená, že až 80 % nákladů na kontejnerové workloady je promrháno na idle resources. Zdroje, za které platíte, ale nikdo je nepoužívá.

V předchozím článku o FinOps v multi-cloud prostředí jsme zmínili Kubernetes waste jako jeden z hlavních zdrojů plýtvání. Dnes se do tohoto tématu ponoříme podstatně hlouběji. Ukážeme si konkrétní strategie, nástroje, konfigurace i příkazy, které vám pomůžou snížit náklady na Kubernetes o 30–60 % – a to aniž byste obětovali výkon nebo spolehlivost vašich aplikací.

Proč jsou náklady na Kubernetes tak těžko kontrolovatelné

Než se pustíme do optimalizačních strategií, pojďme si rozebrat, proč je správa nákladů v Kubernetes tak komplikovaná. Na rozdíl od tradičních virtuálních strojů, kde jeden VM odpovídá jedné položce na faktuře, v Kubernetes existuje několik vrstev abstrakce mezi tím, co platíte cloudovému poskytovateli, a tím, co vaše aplikace skutečně spotřebovávají.

Problém vrstev abstrakce

Cloud provider vám fakturuje na úrovni nodů – virtuálních strojů, které tvoří váš cluster. Kubernetes ale přiděluje zdroje na úrovni podů a kontejnerů. A právě mezi těmito dvěma vrstvami vzniká „mrtvý prostor" – kapacita, kterou nody mají k dispozici, ale pody ji nevyužívají. Tohle je hlavní příčina plýtvání.

Problém se skládá z několika faktorů:

• Nadměrné resource requests: Vývojáři nastavují CPU a memory requests příliš vysoko „pro jistotu", protože se bojí OOMKilled chyb nebo CPU throttlingu
• Chybějící resource limits: Bez explicitně nastavených limitů mohou pody konzumovat neomezené množství zdrojů a vytlačovat ostatní workloady
• Fragmentace nodů: Špatně zvolené typy instancí vedou k situacím, kde na nodech zůstává nevyužitá kapacita, která nestačí pro další pod
• Statické konfigurace: Deploymenty s pevně danými replikami a resource requests, které nikdo neaktualizuje (a ruku na srdce – kdo je aktualizuje pravidelně?)
• Chybějící viditelnost: Bez specializovaných nástrojů je prakticky nemožné zjistit, kolik stojí konkrétní služba, namespace nebo tým

70 % organizací over-provisionuje

Podle průzkumu CNCF z roku 2025 je over-provisioning hlavní příčinou rostoucích nákladů na Kubernetes u 70 % organizací. Dalších 45 % uvádí nedostatek zodpovědnosti a vlastnictví – prostě nikdo aktivně nemonitoruje náklady, a ty tak nekontrolovaně rostou. No a 43 % organizací bojuje s nepoužívanými zdroji a technickým dluhem, kde se staré workloady a testovací deploymenty nikdy neodstraní.

Right-sizing: Základ veškeré optimalizace

Right-sizing je proces nastavení optimálních hodnot resource requests a limits pro každý kontejner tak, aby odpovídaly skutečným potřebám aplikace. Je to zdaleka nejúčinnější způsob, jak snížit náklady na Kubernetes, protože přímo ovlivňuje, kolik kapacity scheduler rezervuje na nodech.

Resource requests vs. limits – jak to celé funguje

V Kubernetes má každý kontejner dvě klíčové nastavení zdrojů:

• Requests (požadavky): Minimální garantované množství CPU a paměti. Scheduler používá requests k rozhodování, na který node pod umístit. Toto je částka, kterou „platíte", i když ji nevyužíváte
• Limits (limity): Maximální množství zdrojů, které kontejner smí využít. Překročení memory limitu vede k OOMKill, překročení CPU limitu k throttlingu

Typický problém vypadá takto – vývojář nastaví requests příliš vysoko, protože „co kdyby":

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: api
        image: myapp:latest
        resources:
          requests:
            cpu: "1000m"      # 1 celé CPU jádro
            memory: "2Gi"     # 2 GB RAM
          limits:
            cpu: "2000m"
            memory: "4Gi"

Ale ve skutečnosti ta aplikace běžně využívá jen 150m CPU a 400 MB paměti. Tři repliky tak zbytečně blokují 3 CPU jádra a 6 GB RAM, přestože reálně potřebují zlomek těchto zdrojů. Klasika.

Jak zjistit skutečné využití zdrojů

Prvním krokem k right-sizingu je sběr dat o skutečném využití. K tomu můžete použít několik přístupů:

1. Kubectl top – rychlý přehled:

# Aktuální využití CPU a paměti podů v namespace
kubectl top pods -n production

# Využití na úrovni nodů
kubectl top nodes

# Detailní pohled na konkrétní pod
kubectl top pod web-api-7d4f8b6c9-x2k4m -n production --containers

2. Prometheus queries pro historická data:

# Průměrné CPU využití za posledních 7 dní
avg(rate(container_cpu_usage_seconds_total{
  namespace="production",
  container="api"
}[7d])) by (pod)

# P95 memory využití za posledních 30 dní
quantile_over_time(0.95,
  container_memory_working_set_bytes{
    namespace="production",
    container="api"
  }[30d]
) / 1024 / 1024  # převod na MB

3. Porovnání requests vs. skutečné využití:

# Poměr skutečného CPU využití k requestům (efficiency)
sum(rate(container_cpu_usage_seconds_total{
  namespace="production"
}[5m])) by (container)
/
sum(kube_pod_container_resource_requests{
  namespace="production",
  resource="cpu"
}) by (container)

Pokud je tento poměr pod 0,3 (tedy 30 %), je to jasný signál, že vaše requests jsou nastaveny příliš vysoko.

Praktická pravidla pro nastavení requests a limits

Na základě osvědčených postupů z praxe doporučujeme následující přístup:

• CPU requests: Nastavte na hodnotu P95 (95. percentil) skutečného využití za posledních 14–30 dní, plus 20 % rezerva
• CPU limits: Nastavte na 3–5× hodnotu CPU requests – to umožňuje handling peaků bez trvalého blokování kapacity
• Memory requests: Nastavte na P99 skutečného využití plus 10–15 % rezerva
• Memory limits: Nastavte shodně s memory requests. To zabrání situacím, kdy Kubernetes zabije váš pod kvůli spotřebě paměti jiného podu (jde o tzv. Guaranteed QoS třídu)

Optimalizovaná konfigurace z našeho příkladu by pak vypadala takto:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: api
        image: myapp:latest
        resources:
          requests:
            cpu: "200m"       # P95 + 20% rezerva
            memory: "512Mi"   # P99 + 15% rezerva
          limits:
            cpu: "800m"       # 4x requests pro handling peaků
            memory: "512Mi"   # shodné s requests (Guaranteed QoS)

Tato jednoduchá změna sníží rezervovanou kapacitu z 3 CPU + 6 GB na 0,6 CPU + 1,5 GB. To je úspora přes 75 % blokovaných zdrojů. A to jsme ještě ani nezačali s autoscalingem.

Autoscaling: VPA, HPA a KEDA

Right-sizing vám dá správný základ, ale reálné workloady mají proměnlivou zátěž – to je prostě realita. K tomu slouží autoscaling, tedy automatické přizpůsobování zdrojů aktuální poptávce. Kubernetes nabízí několik mechanismů, z nichž každý řeší jiný aspekt škálování.

Vertical Pod Autoscaler (VPA) – automatický right-sizing

VPA analyzuje historické využití zdrojů a automaticky upravuje resource requests a limits. Je to v podstatě automatizace procesu right-sizingu, který jsme popsali výše.

VPA funguje ve třech režimech:

• Off (Recommendation-Only): Pouze generuje doporučení, nic nemění. Doporučený režim pro začátek
• Initial: Nastaví resources při vytvoření podu, ale neaktualizuje běžící pody
• Auto: Automaticky aktualizuje běžící pody – ovšem vyžaduje restart podu

Důležité upozornění: V produkci vždy začněte s režimem „Off". VPA v automatickém režimu restartuje pody, aby aplikoval nové hodnoty, a to může způsobit výpadky kritických služeb. Od Kubernetes 1.27 existuje experimentální podpora InPlaceOrRecreate, která umožňuje aktualizaci bez restartu, pokud to kontejner runtime podporuje.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-api-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  updatePolicy:
    updateMode: "Off"  # Začněte s doporučeními
  resourcePolicy:
    containerPolicies:
    - containerName: api
      minAllowed:
        cpu: "100m"
        memory: "256Mi"
      maxAllowed:
        cpu: "2000m"
        memory: "4Gi"
      controlledResources: ["cpu", "memory"]

Doporučení si poté zobrazíte jednoduchým příkazem:

kubectl describe vpa web-api-vpa -n production

VPA vám ukáže tři hodnoty – Lower Bound (minimální doporučení), Target (optimální hodnota) a Upper Bound (maximální doporučení). Použijte Target hodnotu s přiměřenou rezervou a máte solidní základ.

Horizontal Pod Autoscaler (HPA) – škálování replik

Zatímco VPA upravuje zdroje jednotlivých podů, HPA mění počet replik. Je ideální pro bezstavové služby, kde horizontální škálování dává smysl.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-api-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70  # Škáluj při 70% CPU
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # 5 minut stabilizace
      policies:
      - type: Percent
        value: 25              # Max 25% snížení najednou
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
      - type: Percent
        value: 100             # Rychlé scale-up
        periodSeconds: 60

Klíčové zásady pro HPA:

• Nepoužívejte memory jako primární metriku pro HPA. Paměť je příliš pomalá a destruktivní jako škálovací signál. Většina aplikací paměť neuvolňuje, takže HPA bude jen přidávat repliky, ale nikdy je neodebere. Paměť je zkrátka problém sizingu (VPA), ne scalingu (HPA)
• Preferujte custom metriky jako počet requestů za sekundu, délku fronty nebo latenci – ty lépe reflektují skutečnou zátěž vaší aplikace
• Nastavte stabilizační okno pro scale-down na alespoň 300 sekund. Bez toho riskujete příliš agresivní snižování počtu replik (a věřte mi, to nechcete řešit v pátek odpoledne)

Kombinace VPA a HPA – správný přístup

VPA a HPA spolu nefungují úplně hladce, pokud oba cílí na stejný zdroj. Bezpečný vzor je:

• HPA škáluje repliky na základě CPU využití nebo custom metrik
• VPA v režimu Off poskytuje doporučení pro memory (a případně CPU), která aplikujete manuálně

Alternativně můžete použít VPA jen pro memory a HPA pro CPU:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-api-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: api
      controlledResources: ["memory"]  # VPA řídí jen memory
      controlledValues: RequestsAndLimits

KEDA – event-driven autoscaling

Pro workloady řízené událostmi (message queues, streaming, batch jobs) je KEDA (Kubernetes Event-Driven Autoscaling) výrazně lepší volba než HPA. KEDA umí škálovat na základě externích metrik – třeba délky fronty v RabbitMQ, počtu zpráv v Apache Kafka nebo položek v Azure Service Bus:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor
  namespace: production
spec:
  scaleTargetRef:
    name: order-processor
  minReplicaCount: 0    # Může škálovat až na nulu!
  maxReplicaCount: 50
  triggers:
  - type: rabbitmq
    metadata:
      queueName: orders
      host: amqp://rabbitmq.default.svc.cluster.local
      queueLength: "10"  # 1 replika na každých 10 zpráv

Klíčová výhoda KEDA? Schopnost škálovat až na nulu replik. Pokud nejsou žádné zprávy ve frontě, neběží žádný pod a neplatíte nic. Pro workloady s nepravidelnou zátěží je to obrovská úspora.

Karpenter vs. Cluster Autoscaler: Inteligentní provisioning nodů

Zatímco VPA, HPA a KEDA škálují na úrovni podů, na úrovni nodů potřebujete autoscaler, který přidává a odebírá virtuální stroje z clusteru. V roce 2026 máte na výběr dvě hlavní možnosti.

Cluster Autoscaler – tradiční přístup

Cluster Autoscaler (CA) je osvědčený nástroj, který funguje od roku 2017 a podporuje všechny hlavní cloud providery (AWS, GCP, Azure, IBM). Funguje na principu předem definovaných node groups a periodicky kontroluje, zda existují unschedulable pody nebo nevyužité nody.

Nevýhody CA:

• Pomalé škálování – 3–4 minuty na provisioning nového nodu kvůli ASG spin-up time
• Omezení na předem definované node groups a instance typy
• Pouze reaktivní odebírání – odstraní nody jen když jsou úplně prázdné
• Žádná proaktivní konsolidace ani optimalizace instancí

Karpenter – nová generace

Karpenter je open-source projekt od AWS, který představuje fundamentálně odlišný přístup k provisioningu nodů. Místo práce s předem definovanými skupinami instancí komunikuje přímo s EC2 Fleet API a dynamicky vybírá optimální typ instance pro každý pending pod.

Klíčové výhody Karpenter (a je jich opravdu hodně):

• Rychlost: Provisioning nového nodu za 45–60 sekund (oproti 3–4 minutám u CA). Ten rozdíl opravdu poznáte
• Inteligentní výběr instancí: Automaticky vybírá optimální typ instance z celého katalogu cloud providera na základě požadavků podů
• Proaktivní konsolidace: Aktivně hledá levnější nebo lépe využitelné nody a migruje pody. Verze 1.5 (červenec 2025) přinesla „emptiness-first" konsolidaci
• Spot-aware: Nativní podpora pro Spot instance s automatickým nahrazením při interruption – dokáže nahradit interrupted Spot node během 2minutového varování
• Bin-packing: Pokročilý algoritmus pro optimální umístění podů s minimálním plýtváním

Konfigurace Karpenter NodePool:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
      - key: kubernetes.io/arch
        operator: In
        values: ["amd64"]
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]  # Preferuj Spot
      - key: karpenter.k8s.aws/instance-category
        operator: In
        values: ["c", "m", "r"]        # Compute, general, memory
      - key: karpenter.k8s.aws/instance-generation
        operator: Gt
        values: ["5"]                   # Jen novější generace
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: 100                            # Max 100 CPU jader
    memory: 400Gi                       # Max 400 GB RAM
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s               # Agresivní konsolidace
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiSelectorTerms:
  - alias: al2023@latest
  subnetSelectorTerms:
  - tags:
      karpenter.sh/discovery: my-cluster
  securityGroupSelectorTerms:
  - tags:
      karpenter.sh/discovery: my-cluster

Organizace, které přešly z Cluster Autoscaleru na Karpenter, reportují 20–35 % úspory na compute nákladech. A to díky lepšímu bin-packingu, agresivnější konsolidaci a efektivnějšímu využití Spot instancí.

Kdy použít který nástroj

Karpenter je jasná volba pro AWS prostředí, kde potřebujete rychlé škálování, cost optimalizaci a dynamický výběr instancí. Cluster Autoscaler ale stále dává smysl v některých scénářích:

• Multi-cloud nebo hybridní prostředí: CA má širší podporu cloud providerů
• GPU workloady s dlouhým životem: Předem definované node groups lépe chrání GPU pody před zbytečným přeplánováním
• Regulované prostředí: CA se lépe integruje s managed node group rolling upgrades

Spot a preemptible instance v Kubernetes

Využití Spot instancí (AWS), Spot VMs (Azure) nebo Preemptible VMs (GCP) v Kubernetes clusterech je jedna z nejefektivnějších cest, jak snížit compute náklady o 60–90 %. Klíčem je správná architektura, která počítá s tím, že tyto instance mohou být kdykoliv odebrány.

Zásady pro bezpečné použití Spot instancí

• Diverzifikujte instance typy: Používejte více typů a velikostí instancí, abyste snížili riziko hromadného odebrání. Karpenter toto řeší automaticky
• Používejte Pod Disruption Budgets (PDB): Zajistěte, že vždy běží minimální počet replik
• Implementujte graceful shutdown: Reagujte na SIGTERM a ukončete práci během grace periody
• Oddělte Spot a On-Demand workloady: Kritické služby na On-Demand, tolerantní workloady na Spot

# Pod Disruption Budget – vždy alespoň 2 repliky
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-api-pdb
  namespace: production
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web-api

---
# Topology Spread – rozložení podů napříč zónami
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
spec:
  replicas: 4
  template:
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: web-api
      tolerations:
      - key: "karpenter.sh/capacity-type"
        operator: "Equal"
        value: "spot"
        effect: "NoSchedule"

Které workloady se hodí pro Spot

Ne každý workload je vhodný kandidát. Tady je rychlý přehled:

• Ideální: CI/CD pipeline, batch processing, data pipeline, web servery za load balancerem, strojové učení (s checkpointingem)
• Nevhodné: Databáze, stavové služby bez replikace, single-instance služby, long-running jobs bez checkpointingu

Nástroje pro viditelnost a alokaci nákladů

Bez viditelnosti nákladů na úrovni Kubernetes objektů (namespace, deployment, label) je optimalizace jako střelba poslepu. Naštěstí v roce 2026 máte k dispozici několik vyspělých nástrojů, které vám s tím pomůžou.

OpenCost – open-source standard

OpenCost je vendor-neutrální, open-source projekt pod záštitou CNCF (aktuálně ve fázi incubating). Poskytuje real-time alokaci nákladů na úrovni clusteru, nodu, namespace, controlleru, služby nebo podu.

Klíčové vlastnosti:

• Real-time Kubernetes cost allocation
• Multi-cloud podpora (AWS, Azure, GCP)
• Integrace s billing API cloud providerů
• Nový MCP (Model Context Protocol) server pro AI agenty – umožňuje AI nástrojům dotazovat se na náklady přes standardizované rozhraní
• Zdarma (licence Apache 2.0)

Instalace OpenCost přes Helm:

# Přidání repozitáře a instalace
helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm repo update

helm install opencost opencost/opencost \
  --namespace opencost \
  --create-namespace \
  -f - << EOF
opencost:
  prometheus:
    internal:
      enabled: true
  ui:
    enabled: true
EOF

# Port-forward pro přístup k UI
kubectl port-forward -n opencost svc/opencost 9090:9090

Omezení: OpenCost nezohledňuje slevy, Spot pricing, kredity ani custom cenové dohody – to je dostupné pouze v komerční verzi Kubecost. Pro menší týmy to ale nemusí být překážka.

Kubecost – enterprise řešení

Kubecost (nyní součást IBM Apptio portfolia) staví na OpenCost a přidává pokročilé funkce pro enterprise prostředí:

• Reconciliace se skutečnou fakturou: Zohledňuje negotiované slevy, RI, Spot ceny a kredity
• Customizovaná doporučení: Automatické right-sizing návrhy na míru vašemu prostředí
• Alerting a governance: Real-time upozornění přes email nebo Slack na anomálie, překročení budgetů a neefektivní workloady
• Federated multi-cluster: Jednotný pohled napříč všemi clustery přes jedno API

Kubecost nabízí bezplatnou verzi pro malé týmy, ale pro produkční nasazení s více clustery budete potřebovat placenou verzi. Cena se odvíjí od počtu monitorovaných vCPU.

Prometheus a Grafana – DIY řešení

Pokud preferujete vlastní řešení (a kdo z nás to občas nechce?), můžete vybudovat cost visibility dashboardy pomocí Prometheus a Grafana. Klíčové metriky, které byste měli sledovat:

# Grafana dashboard – klíčové panely pro Kubernetes cost optimization

# 1. CPU Efficiency (requests vs actual usage)
sum(rate(container_cpu_usage_seconds_total{
  namespace!="kube-system"
}[1h])) by (namespace)
/
sum(kube_pod_container_resource_requests{
  resource="cpu",
  namespace!="kube-system"
}) by (namespace)

# 2. Memory Efficiency
sum(container_memory_working_set_bytes{
  namespace!="kube-system"
}) by (namespace)
/
sum(kube_pod_container_resource_requests{
  resource="memory",
  namespace!="kube-system"
}) by (namespace)

# 3. Wasted CPU (rozdíl mezi requests a actual usage v jádrech)
sum(kube_pod_container_resource_requests{
  resource="cpu",
  namespace!="kube-system"
}) by (namespace)
-
sum(rate(container_cpu_usage_seconds_total{
  namespace!="kube-system"
}[1h])) by (namespace)

Policy-as-Code: Prevence plýtvání u zdroje

Reaktivní optimalizace je důležitá, ale ještě efektivnější je plýtvání předcházet. Policy-as-Code nástroje jako OPA Gatekeeper a Kyverno umožňují definovat pravidla, která zabrání deploymentu neefektivních konfigurací ještě předtím, než se dostanou do clusteru.

Kyverno – příklady cost-related politik

Kyverno je Kubernetes-native policy engine, který je jednodušší na konfiguraci než OPA Gatekeeper a nevyžaduje znalost jazyka Rego. To je pro většinu týmů velká výhoda.

# 1. Vyžadovat resource requests a limits u všech kontejnerů
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-requests
spec:
  validationFailureAction: Enforce
  rules:
  - name: validate-resources
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "Všechny kontejnery musí mít definované CPU a memory requests a limits."
      pattern:
        spec:
          containers:
          - resources:
              requests:
                memory: "?*"
                cpu: "?*"
              limits:
                memory: "?*"
                cpu: "?*"

---
# 2. Omezit maximální resource requests
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: limit-resource-requests
spec:
  validationFailureAction: Enforce
  rules:
  - name: limit-cpu-request
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "CPU request nesmí překročit 4 jádra. Kontaktujte platform tým pro výjimku."
      deny:
        conditions:
          any:
          - key: "{{ request.object.spec.containers[].resources.requests.cpu }}"
            operator: GreaterThan
            value: "4000m"

---
# 3. Vyžadovat label 'cost-center' pro cost allocation
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-cost-center-label
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-cost-center
    match:
      any:
      - resources:
          kinds:
          - Deployment
          - StatefulSet
    validate:
      message: "Všechny Deploymenty a StatefulSety musí mít label 'cost-center' pro alokaci nákladů."
      pattern:
        metadata:
          labels:
            cost-center: "?*"

Tyto politiky zajistí, že žádný deployment neprojde bez resource requests, žádný kontejner nepožaduje nadměrné množství zdrojů a každý workload je přiřazen k nákladovému středisku. Jednoduché, ale účinné.

Praktický plán optimalizace: Krok za krokem

Tak, pojďme si shrnout všechny zmíněné strategie do praktického akčního plánu, který můžete implementovat postupně. Není třeba dělat všechno najednou.

Fáze 1: Viditelnost (týden 1–2)

1. Nasaďte OpenCost nebo Kubecost pro okamžitou viditelnost nákladů
2. Nastavte Prometheus metriky pro sledování CPU a memory efficiency
3. Identifikujte top 10 nejdražších namespaců a deploymentů
4. Spusťte VPA v režimu Off pro sběr doporučení

Fáze 2: Quick wins (týden 3–4)

1. Aplikujte VPA doporučení na top 10 nejméně efektivních deploymentů
2. Odstraňte zombie resources – nepoužívané PersistentVolumeClaims, Services bez endpoints, staré ConfigMaps a Secrets
3. Nastavte automatické vypínání dev/staging prostředí mimo pracovní dobu pomocí CronJobs nebo nástrojů jako kube-downscaler
4. Zaveďte Kyverno politiku vyžadující resource requests u všech podů

# Najít unattached PersistentVolumes
kubectl get pv --no-headers | awk '$5 == "Released" || $5 == "Available" {print $1}'

# Najít Services bez endpoints
kubectl get endpoints -A --no-headers | awk '$2 == "" {print $1, $2}'

# Příklad kube-downscaler anotace pro automatické vypínání
# Běží jen v pracovní dobu (Po-Pá, 8:00-18:00 CET)
kubectl annotate deployment web-api \
  downscaler/uptime="Mon-Fri 08:00-18:00 Europe/Prague" \
  -n staging

Fáze 3: Autoscaling (týden 5–8)

1. Nasaďte HPA pro bezstavové služby s proměnlivou zátěží
2. Implementujte KEDA pro event-driven workloady
3. Pokud používáte AWS, zvažte migraci z Cluster Autoscaleru na Karpenter
4. Začněte s využíváním Spot instancí pro tolerantní workloady

Fáze 4: Governance a kultura (průběžně)

1. Zaveďte povinné cost-center labely přes Policy-as-Code
2. Vytvořte cost dashboardy pro jednotlivé týmy
3. Nastavte budget alerting – upozornění při překročení rozpočtu
4. Integrujte nákladové informace do CI/CD pipeline (např. Infracost pro Terraform)
5. Pravidelné měsíční review nákladů s engineering a finance týmy

Reálné výsledky: Co můžete očekávat

Pojďme si kvantifikovat potenciální úspory na příkladu středně velké organizace s měsíčními náklady na Kubernetes $50 000:

• Right-sizing resource requests: 20–30 % úspora → $10 000–15 000/měsíc
• Autoscaling (HPA + VPA): 10–15 % dodatečná úspora → $5 000–7 500/měsíc
• Spot instance pro tolerantní workloady (30 % workloadu): 5–10 % celková úspora → $2 500–5 000/měsíc
• Karpenter konsolidace: 5–10 % úspora → $2 500–5 000/měsíc
• Odstranění zombie resources: 3–5 % úspora → $1 500–2 500/měsíc
• Vypínání dev/staging mimo pracovní dobu: 2–5 % úspora → $1 000–2 500/měsíc

Celková potenciální úspora: $22 500–37 500/měsíc (45–75 %)

Realisticky počítejte s 30–50 % úsporou v prvních třech měsících implementace. Další úspory pak přijdou z kontinuální optimalizace a (hlavně) kulturních změn v organizaci.

Nejčastější chyby při optimalizaci Kubernetes nákladů

Na závěr si pojďme projít chyby, kterých se organizace nejčastěji dopouštějí. Některé z nich jsem viděl znovu a znovu:

• Příliš agresivní right-sizing: Snížení requests pod skutečné potřeby vede k performance problémům, OOMKill chybám a nespokojenosti uživatelů. Vždy ponechte 15–20 % rezervu – ušetříte si spoustu stresu
• Ignorování burst workloadů: Aplikace s nepravidelnou zátěží (e-commerce flash sales, sezónní peaky) potřebují dostatečný headroom
• VPA v Auto režimu na stateful služby: Automatické restartování databází nebo stavových služeb může vést k výpadkům. To vážně nechcete
• 100 % Spot bez fallbacku: Vždy mějte On-Demand kapacitu pro kritické služby jako záložní řešení
• Optimalizace bez monitoringu: Jakákoliv změna resource requests nebo autoscaling konfigurace musí být doprovázena pečlivým monitoringem performance metrik
• Nedostatečná komunikace: Optimalizace nákladů bez zapojení development týmů vede k odporu a obcházení pravidel. FinOps je kulturní změna, ne jen technická záležitost

Závěr

Optimalizace nákladů na Kubernetes není jednorázový projekt – je to kontinuální proces, který vyžaduje správné nástroje, automatizaci a kulturní změnu v celé organizaci. V roce 2026, kdy většina enterprise workloadů běží na Kubernetes a náklady na cloud infrastrukturu neustále rostou, se efektivní správa kontejnerových nákladů stává skutečnou konkurenční výhodou.

Začněte s viditelností – nasaďte OpenCost nebo Kubecost a pochopte, kde utrácíte. Pokračujte s right-sizingem, protože VPA v recommendation režimu vám ukáže, kde máte největší prostor pro optimalizaci. Implementujte autoscaling – HPA, VPA a KEDA zajistí, že platíte jen za kapacitu, kterou skutečně potřebujete. A nakonec zaveďte governance, aby se problémy nevracely.

Důležité je nezapomenout, že cílem není minimalizovat náklady za každou cenu, ale maximalizovat hodnotu, kterou z cloudových investic získáváte. Kubernetes, který je správně optimalizovaný, je nejenom levnější, ale také rychlejší, spolehlivější a jednodušší na správu. A to je výhra pro všechny – engineering, finance i byznys.