Strategije i najbolje prakse 20 min čitanja

Optimizacija troškova Kubernetesa u 2026.: Vodič za FinOps u kontejnerskim okruženjima

Naučite kako smanjiti troškove Kubernetesa za 35-55% korištenjem FinOps praksi, pravilnog dimenzioniranja kontejnera, Spot instanci i automatskog skaliranja na AWS EKS, Azure AKS i GCP GKE.

Editorial Team

Zašto je optimizacija troškova Kubernetesa ključna u 2026. godini

Kubernetes je danas de facto standard za orkestraciju kontejnera — to nitko ne osporava. Ali s njegovim širokim usvajanjem došao je i jedan prilično neugodan izazov: nekontrolirani troškovi. Prema najnovijim istraživanjima iz 2026. godine, organizacije koje koriste Kubernetes prosječno troše 30 do 50 posto više nego što je zapravo potrebno. Razlozi? Prekomjerna alokacija resursa, neiskorištene instance i, iskreno, nedostatak bilo kakvog financijskog upravljanja.

S globalnim tržištem cloud computinga koje premašuje bilijun dolara, čak i mali postotak uštede može značiti milijune godišnje za srednje i velike tvrtke.

FinOps — disciplina koja spaja financije, inženjering i poslovanje u upravljanju cloud troškovima — postaje neizostavan dio svake Kubernetes strategije. U ovom vodiču ćemo detaljno proći kako implementirati FinOps prakse specifično za Kubernetes okruženja, od pravilnog dimenzioniranja kontejnera do naprednih tehnika automatizacije. Uz to, pokrit ćemo konkretne primjere za AWS EKS, Azure AKS i Google GKE.

Razumijevanje strukture troškova Kubernetesa

Prije nego što počnemo optimizirati, moramo razumjeti gdje zapravo nastaju troškovi. Za razliku od tradicionalnih virtualnih strojeva, Kubernetes dodaje sloj apstrakcije koji može prilično dobro zamagliti pravu sliku troškova. I to je, barem po mom iskustvu, jedan od glavnih razloga zašto mnoge organizacije uopće ne znaju koliko zapravo bacaju.

Glavni generatori troškova

  • Compute (računalni resursi): Čvorovi (nodes) koji pokreću vaše podove — obično najveći trošak, često 60-70% ukupnog izdatka
  • Memorija: RAM alokacije za kontejnere, koje su nekompresibilne — kad kontejner premaši limit, Kubernetes ga jednostavno terminira s OOMKilled greškom
  • Mrežni promet: Promet između zona dostupnosti, regija i prema internetu može brzo narasti
  • Trajno pohranjivanje: Persistent Volumes (PV) i njihovi provizorirani diskovi
  • Upravljačka razina: Troškovi samog klastera (control plane), posebno na upravljanim servisima
  • Load balanceri: Svaki Kubernetes Service tipa LoadBalancer kreira cloud load balancer s vlastitim troškovima

Skriveni troškovi koje mnogi zanemaruju

Jedan od najčešćih problema jest razlika između zahtjeva resursa (requests) i stvarne potrošnje. Kubernetes raspoređuje podove na temelju requests vrijednosti, ali stvarna potrošnja može biti znatno manja. Ta razlika — takozvani "slack" — predstavlja čisti gubitak novca jer plaćate kapacitet koji nikad ne koristite.

Evo kako to izgleda u praksi:

# Primjer: Pod s prekomjernim zahtjevima
apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: app
    image: web-app:latest
    resources:
      requests:
        cpu: "2"        # Zahtijeva 2 CPU jezgre
        memory: "4Gi"   # Zahtijeva 4 GB RAM-a
      limits:
        cpu: "4"        # Limit: 4 CPU jezgre
        memory: "8Gi"   # Limit: 8 GB RAM-a
    # Stvarna potrošnja: 0.3 CPU, 512 MB RAM
    # Gubitak: ~85% alociranog CPU-a, ~87% alocirane memorije

Vidite li problem? Taj pod zahtijeva 2 CPU jezgre, a koristi samo 0.3. To je kao da ste unajmili stan od 200 kvadrata, a živite u jednoj sobi.

Korak 1: Uspostavljanje vidljivosti troškova

Temelj svake FinOps prakse je vidljivost. Ne možete optimizirati ono što ne mjerite — to je jednostavno pravilo koje vrijedi uvijek. U Kubernetes okruženju to znači precizno praćenje troškova na razini namespaceova, deploymentova i pojedinih podova.

Implementacija Kubecosta za praćenje troškova

Kubecost je daleko najčešće korišten alat otvorenog koda za praćenje troškova Kubernetesa u 2026. godini. Izgrađen je na Prometheusu i pruža detaljan uvid u alokaciju troškova po timu, servisu i okruženju.

# Instalacija Kubecosta pomoću Helma
helm repo add kubecost https://kubecost.github.io/cost-analyzer/
helm repo update

# Instalacija u dedicated namespace
helm install kubecost kubecost/cost-analyzer \
  --namespace kubecost \
  --create-namespace \
  --set kubecostToken="vaš-token" \
  --set prometheus.server.retention="30d" \
  --set networkCosts.enabled=true

Nakon instalacije, Kubecost će automatski početi prikupljati podatke o potrošnji resursa i korelirati ih s cijenama vašeg cloud providera. Ključne metrike koje biste trebali pratiti:

  • CPU Efficiency: Omjer stvarne potrošnje CPU-a naspram zahtjeva — cilj je iznad 65%
  • Memory Efficiency: Omjer stvarne potrošnje memorije naspram zahtjeva — cilj je iznad 45%
  • Total Cost per Namespace: Ukupni troškovi po namespaceu za alokaciju prema timovima
  • Idle Cost: Troškovi neiskorištenih resursa na čvorovima

Označavanje resursa za preciznu alokaciju

Sustav oznaka (labels) u Kubernetesu je apsolutno ključan za FinOps. Bez njega ste praktički slijepi. Svaki resurs trebao bi imati standardizirane oznake koje omogućuju precizno praćenje troškova.

# Preporučeni sustav oznaka za FinOps
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
  labels:
    app: payment-service
    team: payments               # Tim odgovoran za troškove
    environment: production      # Okruženje
    cost-center: "CC-4521"      # Centar troškova
    business-unit: fintech       # Poslovna jedinica
    managed-by: helm             # Način upravljanja
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payment-service
  template:
    metadata:
      labels:
        app: payment-service
        team: payments
        environment: production
        cost-center: "CC-4521"

Na razini cloud providera, koristite politike oznaka za automatsko provođenje standarda:

# AWS Tag Policy primjer (AWS Organizations)
{
  "tags": {
    "cost-center": {
      "tag_key": {
        "@@assign": "cost-center"
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "eks:cluster"
        ]
      }
    }
  }
}

Korak 2: Pravilno dimenzioniranje kontejnera (Right-sizing)

Hajdemo sad na najsočniji dio. Right-sizing je proces usklađivanja zahtjeva i limita resursa sa stvarnom potrošnjom, i ovo je područje gdje se ostvaruju najveće uštede — govorimo o 30 do 50 posto ukupnih troškova računalnih resursa.

Analiza stvarne potrošnje

Prije bilo kakvih promjena, potrebno je prikupiti podatke o stvarnoj potrošnji kroz dovoljno dugo razdoblje. Minimalno dva tjedna, a idealno mjesec dana. Zašto toliko? Jer trebate obuhvatiti i vršna opterećenja i mirna razdoblja da biste dobili realnu sliku.

# PromQL upiti za analizu potrošnje CPU-a
# Prosječna potrošnja CPU-a po kontejneru u zadnjih 14 dana
avg_over_time(
  rate(container_cpu_usage_seconds_total{
    namespace="production",
    container!="POD"
  }[5m])[14d:1h]
)

# 95. percentil potrošnje CPU-a (za postavljanje limita)
quantile_over_time(0.95,
  rate(container_cpu_usage_seconds_total{
    namespace="production",
    container!="POD"
  }[5m])[14d:1h]
)

# Prosječna potrošnja memorije po kontejneru
avg_over_time(
  container_memory_working_set_bytes{
    namespace="production",
    container!="POD"
  }[14d]
)

Postavljanje optimalnih zahtjeva i limita

Na temelju prikupljenih podataka, primijenite sljedeće smjernice:

  • CPU requests: Postavite na 50. percentil stvarne potrošnje s 20% marginom
  • CPU limits: Postavite na 99. percentil ili ih uklonite potpuno (burstable model)
  • Memory requests: Postavite na 95. percentil stvarne potrošnje s 15% marginom
  • Memory limits: Postavite na dvostruku vrijednost requests (omjer 2:1) za zaštitu od OOMKill grešaka
# Optimizirani Pod nakon analize
apiVersion: v1
kind: Pod
metadata:
  name: web-app-optimized
spec:
  containers:
  - name: app
    image: web-app:latest
    resources:
      requests:
        cpu: "350m"      # Smanjeno s 2000m na 350m (50. percentil + 20%)
        memory: "600Mi"  # Smanjeno s 4Gi na 600Mi (95. percentil + 15%)
      limits:
        # CPU limit uklonjen - omogućuje burstanje
        memory: "1200Mi" # 2x requests za sigurnost

Razlika je očita, zar ne? Od 2 CPU jezgre smo pali na 350 milicora. To je ogromna ušteda kad se pomnoži s desecima ili stotinama podova.

Vertical Pod Autoscaler (VPA) za automatsko dimenzioniranje

VPA automatski prilagođava zahtjeve resursa na temelju stvarne potrošnje. Posebno je koristan za workloade čija potrošnja varira tijekom vremena — a to je, budimo iskreni, većina workloada.

# Instalacija VPA
kubectl apply -f https://github.com/kubernetes/autoscaler/releases/latest/download/vpa-v1-crd-gen.yaml
kubectl apply -f https://github.com/kubernetes/autoscaler/releases/latest/download/vpa-rbac.yaml

# VPA konfiguracija
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: payment-service-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: payment-service
  updatePolicy:
    updateMode: "Auto"      # Automatski primjenjuje preporuke
  resourcePolicy:
    containerPolicies:
    - containerName: app
      minAllowed:
        cpu: "100m"
        memory: "128Mi"
      maxAllowed:
        cpu: "2"
        memory: "4Gi"
      controlledResources: ["cpu", "memory"]
      controlledValues: RequestsAndLimits

Jedan savjet iz prakse: počnite s VPA-om u načinu rada "Off" ili "Initial" kako biste prvo vidjeli preporuke bez automatskih promjena. Tek kad ste zadovoljni s onim što VPA predlaže, prebacite na "Auto".

Korak 3: Optimizacija čvorova i bin packing

Bin packing je tehnika maksimiziranja iskorištenosti čvorova smanjenjem broja čvorova potrebnih za pokretanje svih workloada. Umjesto hrpe slabo iskorištenih čvorova, cilj je imati manje čvorova s visokom iskorištenošću. Zvuči jednostavno, ali u praksi zahtijeva malo finese.

Odabir pravog tipa instance

Odabir tipa instance ima ogroman utjecaj na troškove. Evo usporedbe na tri glavna cloud providera za 2026. godinu:

  • AWS EKS: m7i.xlarge (4 vCPU, 16 GB) — približno $0.2016/sat za on-demand
  • Azure AKS: Standard_D4s_v5 (4 vCPU, 16 GB) — približno $0.192/sat
  • GCP GKE: e2-standard-4 (4 vCPU, 16 GB) — približno $0.134/sat s automatskim popustima za dugoročno korištenje

GCP ovdje izgleda privlačno, ali nemojte birati providera samo na temelju cijene instance — ukupni troškovi ovise o mnogo faktora.

Karpenter za inteligentno skaliranje čvorova (AWS)

Karpenter je AWS-ov autoscaler za Kubernetes koji zamjenjuje tradicionalni Cluster Autoscaler. Njegova ključna prednost? Sposobnost odabira optimalnog tipa instance na temelju stvarnih zahtjeva podova, umjesto da vi ručno definirate node grupe.

# Karpenter NodePool konfiguracija
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]  # Preferiraj Spot instance
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values:
            - m7i.xlarge
            - m7i.2xlarge
            - m6i.xlarge
            - c7i.xlarge       # Compute-optimizirane za CPU workloade
            - r7i.xlarge       # Memory-optimizirane za cache workloade
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["eu-central-1a", "eu-central-1b", "eu-central-1c"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: "100"
    memory: "400Gi"
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s   # Brza konsolidacija praznih čvorova

Implementacija konsolidacije čvorova

Konsolidacija je proces premještanja podova sa slabo iskorištenih čvorova na bolje iskorištene, čime se oslobađaju čvorovi za gašenje. Ciljna iskorištenost čvorova trebala bi biti između 70 i 85 posto — ispod toga bacate novac, a iznad riskirate probleme s performansama.

# Descheduler konfiguracija za konsolidaciju
apiVersion: v1
kind: ConfigMap
metadata:
  name: descheduler-policy
  namespace: kube-system
data:
  policy.yaml: |
    apiVersion: "descheduler/v1alpha2"
    kind: "DeschedulerPolicy"
    profiles:
    - name: default
      pluginConfig:
      - name: LowNodeUtilization
        args:
          thresholds:
            cpu: 20          # Čvor s manje od 20% CPU iskorištenosti
            memory: 20       # i manje od 20% memorije
          targetThresholds:
            cpu: 70          # Premjesti podove na čvorove s manje od 70% CPU
            memory: 70
      - name: RemoveDuplicates  # Raspodijeli replike po čvorovima
      plugins:
        balance:
          enabled:
          - LowNodeUtilization
          - RemoveDuplicates

Korak 4: Korištenje Spot instanci za značajne uštede

Spot instance (na AWS-u), Spot VMs (na Azureu) ili Preemptible VMs (na GCP-u) nude popuste od 60 do 90 posto u odnosu na on-demand cijene. Da, dobro ste pročitali — do 90 posto. Ali postoji kvaka: cloud provider ih može povući s dvominutnim upozorenjem.

Ključ je pravilno identificirati workloade koji mogu tolerirati te prekide.

Koji workloadi su prikladni za Spot instance

  • Idealni kandidati: Batch obrada podataka, CI/CD pipelineovi, trening ML modela, stateless mikroservisi s više replika, razvojna i testna okruženja
  • Neprikladni: Baze podataka, sustavi s jednom replikom, stateful servisi bez redundancije, kritični sustavi s niskom tolerancijom na prekide

Konfiguracija Spot instanci s automatskim fallbackom

# AWS EKS Node Group sa Spot instancama
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: production-cluster
  region: eu-central-1
managedNodeGroups:
  - name: spot-workers
    instanceTypes:
      - m7i.xlarge
      - m6i.xlarge
      - m5.xlarge        # Raznolikost za veću dostupnost
      - c7i.xlarge
      - c6i.xlarge
    spot: true
    minSize: 2
    maxSize: 20
    desiredCapacity: 5
    labels:
      lifecycle: spot
    taints:
      - key: spot
        value: "true"
        effect: PreferNoSchedule
  - name: on-demand-baseline
    instanceTypes:
      - m7i.xlarge
    minSize: 2
    maxSize: 5
    desiredCapacity: 2
    labels:
      lifecycle: on-demand
# Deployment koji preferira Spot, ali tolerira fallback na on-demand
apiVersion: apps/v1
kind: Deployment
metadata:
  name: batch-processor
spec:
  replicas: 10
  template:
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 90
            preference:
              matchExpressions:
              - key: lifecycle
                operator: In
                values: ["spot"]
          - weight: 10
            preference:
              matchExpressions:
              - key: lifecycle
                operator: In
                values: ["on-demand"]
      tolerations:
      - key: spot
        operator: Equal
        value: "true"
        effect: PreferNoSchedule
      terminationGracePeriodSeconds: 120  # Dovoljno vremena za graceful shutdown
      containers:
      - name: processor
        image: batch-processor:latest
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 10 && /app/graceful-shutdown"]

Korak 5: Horizontalno i vertikalno automatsko skaliranje

Pravilno konfiguriran autoscaling osigurava da plaćate samo za kapacitet koji vam stvarno treba. Manje troškova tijekom mirnih razdoblja, automatsko skaliranje kad stvari zakuže — to je cilj.

HPA s prilagođenim metrikama

Umjesto skaliranja isključivo na temelju CPU-a (što je defaultni, ali često loš pristup), koristite poslovne metrike koje bolje odražavaju stvarno opterećenje.

# HPA s prilagođenim metrikama
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-gateway-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-gateway
  minReplicas: 2
  maxReplicas: 50
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300   # 5 min čekanja prije smanjenja
      policies:
      - type: Percent
        value: 10                        # Max 10% smanjenje po koraku
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 30    # Brzo skaliranje prema gore
      policies:
      - type: Percent
        value: 100                       # Može udvostručiti kapacitet
        periodSeconds: 60
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "1000"            # 1000 req/s po podu
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

KEDA za skaliranje na nulu

KEDA (Kubernetes Event-Driven Autoscaling) omogućuje nešto što standardni HPA ne može — skaliranje workloada na nulu replika kada nema aktivnosti. Savršeno za batch procesore, queue workere i periodičke zadatke koji ne trebaju biti stalno upaljen.

# KEDA ScaledObject za SQS queue worker
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor
spec:
  scaleTargetRef:
    name: order-processor
  minReplicaCount: 0        # Skaliranje na nulu kad nema poruka
  maxReplicaCount: 30
  cooldownPeriod: 300
  triggers:
  - type: aws-sqs-queue
    metadata:
      queueURL: https://sqs.eu-central-1.amazonaws.com/123456789/orders
      queueLength: "5"      # Pokreni novi pod na svakih 5 poruka
      awsRegion: eu-central-1
      identityOwner: operator

Iz iskustva, korištenjem KEDA-e za workloade koji nisu neprestano aktivni, organizacije prosječno štede 40 do 60 posto troškova u usporedbi s tradicionalnim pristupom držanja minimalnog broja replika. To je stvarno značajna razlika.

Korak 6: Optimizacija mrežnih troškova

Mrežni troškovi u Kubernetesu znaju biti iznenađujuće visoki — to je nešto što mnogi shvate tek kad im stigne račun. Posebno u višezonskim i višeregijskim deploymentima, promet između zona dostupnosti naplaćuje se na svim cloud platformama.

Topology-aware routing

# Service s topološkim rutiranjem za smanjenje cross-zone prometa
apiVersion: v1
kind: Service
metadata:
  name: cache-service
  annotations:
    service.kubernetes.io/topology-mode: Auto
spec:
  selector:
    app: redis-cache
  ports:
  - port: 6379
    targetPort: 6379

Strategija smanjenja mrežnih troškova

  • Koristite topology-aware routing za usmjeravanje prometa prema podovima u istoj zoni dostupnosti
  • Implementirajte Gateway API umjesto pojedinačnih LoadBalancer servisa — jedan gateway za više servisa značajno smanjuje broj (i trošak) load balancera
  • Komprimirajte podatke između servisa, posebno za velike JSON payloade
  • Koristite ClusterIP umjesto LoadBalancer za interne servise
  • Optimizirajte veličine container imagea za smanjenje troškova preuzimanja iz registrija
# Gateway API - jedan gateway za više servisa
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-gateway
spec:
  gatewayClassName: aws-alb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-routes
spec:
  parentRefs:
  - name: shared-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api/payments
    backendRefs:
    - name: payment-service
      port: 8080
  - matches:
    - path:
        type: PathPrefix
        value: /api/orders
    backendRefs:
    - name: order-service
      port: 8080

Korak 7: Upravljanje troškovima pohrane

Persistent Volumes mogu predstavljati značajan trošak, posebno ako koristite premium tipove pohrane za workloade kojima to uopće nije potrebno. A to se događa češće nego što biste mislili.

Strategije optimizacije pohrane

# StorageClass za različite razine performansi
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cost-optimized
provisioner: ebs.csi.aws.com
parameters:
  type: gp3              # GP3 umjesto GP2 — bolje performanse, niža cijena
  iops: "3000"           # Bazne IOPS uključene u cijenu
  throughput: "125"      # Bazni throughput uključen
reclaimPolicy: Delete    # Automatsko brisanje nekorištenih volumena
volumeBindingMode: WaitForFirstConsumer  # Odgodi kreiranje do stvarne potrebe
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: archive
provisioner: ebs.csi.aws.com
parameters:
  type: sc1              # Cold HDD za rijetko pristupane podatke
reclaimPolicy: Delete

Redovito pregledavajte neiskorištene PersistentVolumeClaims. Volumeni koji ostanu nakon brisanja podova generiraju troškove bez ikakve koristi — to je doslovno bačen novac.

# Pronađi neiskorištene PVC-ove
kubectl get pvc --all-namespaces -o json | \
  jq -r '.items[] | select(.status.phase == "Bound") |
  "\(.metadata.namespace)/\(.metadata.name) - \(.spec.resources.requests.storage)"'

# Pronađi PV-ove bez pridruženih PVC-ova
kubectl get pv -o json | \
  jq -r '.items[] | select(.status.phase == "Released") |
  "\(.metadata.name) - \(.spec.capacity.storage) - \(.spec.storageClassName)"'

Korak 8: Automatizacija i upravljanje politikama

Dugoročno uspješna optimizacija zahtijeva automatizaciju. Ručno praćenje i prilagodba jednostavno ne skaliraju s rastom infrastrukture — a infrastruktura uvijek raste brže nego što očekujete.

OPA Gatekeeper za provođenje politika troškova

# Constraint Template: Zahtijeva postavljanje resource requests/limits
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredresources
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredResources
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredresources

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.resources.requests.cpu
          msg := sprintf("Kontejner '%v' mora imati CPU request", [container.name])
        }

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.resources.requests.memory
          msg := sprintf("Kontejner '%v' mora imati memory request", [container.name])
        }

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          cpu_limit := container.resources.limits.cpu
          cpu_request := container.resources.requests.cpu
          to_number(cpu_limit) > to_number(cpu_request) * 4
          msg := sprintf("CPU limit za '%v' ne smije biti veći od 4x request", [container.name])
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredResources
metadata:
  name: must-have-resources
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
    namespaces: ["production", "staging"]

Automatsko gašenje razvojnih okruženja

Razvojna i testna okruženja često ostaju upaljena 24/7, iako ih ljudi koriste samo tijekom radnog vremena. Iskreno, ovo je jedan od najlakših načina za uštedu — automatsko gašenje može uštedjeti do 65 posto troškova tih okruženja, a implementacija je trivijalna.

# CronJob za skaliranje razvojnih deploymentova na nulu izvan radnog vremena
apiVersion: batch/v1
kind: CronJob
metadata:
  name: scale-down-dev
  namespace: kube-system
spec:
  schedule: "0 19 * * 1-5"   # Svaki radni dan u 19:00 UTC
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: scaler
          containers:
          - name: scaler
            image: bitnami/kubectl:latest
            command:
            - /bin/sh
            - -c
            - |
              for ns in dev staging qa; do
                for deploy in $(kubectl get deploy -n $ns -o name); do
                  kubectl scale $deploy -n $ns --replicas=0
                done
              done
          restartPolicy: OnFailure
---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: scale-up-dev
  namespace: kube-system
spec:
  schedule: "0 7 * * 1-5"    # Svaki radni dan u 07:00 UTC
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: scaler
          containers:
          - name: scaler
            image: bitnami/kubectl:latest
            command:
            - /bin/sh
            - -c
            - |
              for ns in dev staging qa; do
                for deploy in $(kubectl get deploy -n $ns -o name); do
                  kubectl scale $deploy -n $ns --replicas=1
                done
              done
          restartPolicy: OnFailure

Korak 9: FinOps izvještavanje i kultura

Tehnička optimizacija bez organizacijske kulture neće dati dugoročne rezultate. To je nešto što sam naučio na teži način. FinOps zahtijeva suradnju između inženjera, financija i menadžmenta — a to je ponekad teže od samog tehničkog dijela.

Ključni KPI-jevi za Kubernetes FinOps

  • Trošak po korisniku (CPU — Cost Per User): Ukupni Kubernetes troškovi podijeljeni s brojem aktivnih korisnika
  • Trošak po transakciji: Koliko košta obrada jedne transakcije u vašem sustavu
  • Stopa iskorištenosti resursa: Postotak alociranog kapaciteta koji se stvarno koristi
  • Pokrivenost commitment diskontima: Postotak troškova pokriven Reserved Instances ili Savings Plans — cilj je 60-80%
  • Trošak po okruženju: Usporedba troškova produkcije, staginga i razvoja

Tjedni FinOps pregled

Uspostavite tjedni pregled troškova s ključnim dionicima. Evo strukture koja se u praksi pokazala efikasnom:

  1. Pregled ukupnih troškova: Usporedba s prethodnim tjednom i budžetom
  2. Top 5 promjena: Koji servisi su najviše porasli/smanjili troškove
  3. Anomalije: Neočekivani skokovi ili padovi potrošnje
  4. Akcijski plan: Konkretne akcije za optimizaciju s odgovornim osobama
  5. Preporuke alata: Preporuke Kubecosta ili VPA-a za optimizaciju

Korak 10: Usporedba troškova upravljanih Kubernetes servisa u 2026.

Pri odabiru platforme, troškovi upravljačke razine (control plane) mogu značajno utjecati na ukupne troškove, posebno ako imate više klastera.

  • AWS EKS: $0.10/sat po klasteru ($73/mjesec) + troškovi EC2 instanci za čvorove
  • Azure AKS: Besplatna upravljačka razina za standardni tier; $0.10/sat za uptime SLA tier
  • GCP GKE: Besplatno za jedan Autopilot ili Standard klaster; $0.10/sat za dodatne klastere

GCP GKE Autopilot način rada zaslužuje posebnu pažnju jer naplaćuje samo stvarno korištene resurse podova, eliminirajući troškove neiskorištenog kapaciteta na čvorovima. Za workloade s varijabilnim opterećenjem, to može značiti uštede od 25 do 40 posto — što je poprilično impresivno.

Praktični primjer: Plan optimizacije za tipičnu organizaciju

Dakle, hajdemo sve ovo staviti u kontekst. Zamislimo organizaciju s mjesečnim Kubernetes troškovima od 50.000 dolara. Evo realističnog plana uštede, korak po korak:

  1. Tjedan 1-2: Vidljivost — Instalacija Kubecosta, postavljanje oznaka, baseline mjerenje → Trošak: 0, Ušteda: 0
  2. Tjedan 3-4: Right-sizing — Analiza i prilagodba requests/limits za top 20 deploymentova → Očekivana ušteda: 15-25% ($7.500-$12.500/mj.)
  3. Tjedan 5-6: Spot instance — Migracija prikladnih workloada na Spot → Očekivana ušteda: 10-15% ($5.000-$7.500/mj.)
  4. Tjedan 7-8: Autoscaling — Implementacija HPA/VPA/KEDA za ključne servise → Očekivana ušteda: 5-10% ($2.500-$5.000/mj.)
  5. Tjedan 9-10: Gašenje neaktivnih okruženja — Automatsko skaliranje dev/staging → Očekivana ušteda: 5-8% ($2.500-$4.000/mj.)
  6. Tjedan 11-12: Commitment diskonti — Kupnja Savings Plans za stabilne workloade → Očekivana ušteda: 10-15% ($5.000-$7.500/mj.)

Ukupna očekivana ušteda: 35-55% ($17.500-$27.500 mjesečno)

To su brojke koje se teško ignoriraju, zar ne?

Zaključak

Optimizacija troškova Kubernetesa u 2026. godini nije jednokratan projekt — to je kontinuirani proces koji zahtijeva kombinaciju tehničkih alata, organizacijskih praksi i, možda najvažnije, kulturne promjene. Ključni koraci uključuju uspostavljanje vidljivosti s alatima poput Kubecosta, pravilno dimenzioniranje kontejnera, pametno korištenje Spot instanci, implementaciju automatskog skaliranja i redovito izvještavanje.

S pristupom opisanim u ovom vodiču, organizacije mogu realno očekivati smanjenje Kubernetes troškova za 35 do 55 posto, bez ugrožavanja performansi ili pouzdanosti. Ključ je početi s malim koracima — instalirajte Kubecost, identificirajte najveće izvore otpada i postupno implementirajte optimizacije.

Na kraju, zapamtite: najbolji trenutak za početak optimizacije bio je jučer. Drugi najbolji trenutak je danas.

O Autoru Editorial Team

Our team of expert writers and editors.

Povezani Članci