Optimizarea Costurilor Kubernetes: Ghid Practic pentru EKS, AKS și GKE

Introducere: De Ce Kubernetes Este Cel Mai Mare Consumator Invizibil de Buget Cloud

Kubernetes a cucerit lumea infrastructurii — asta nu mai e o surpriză pentru nimeni. În 2026, peste 84% din organizații folosesc containere în producție, iar Kubernetes e orchestratorul dominant. Dar iată paradoxul pe care mulți îl descoperă prea târziu: tocmai platforma care promite eficiență și scalabilitate inteligentă e adesea cea mai mare sursă de risipă din factura cloud.

Cifrele sunt, sincer, brutale. 68% din organizații cheltuiesc cu 20-40% mai mult decât ar trebui pe Kubernetes. Audituri recente arată că doar 13% din CPU-ul solicitat e efectiv utilizat, iar 80-90% din pod-uri au request-uri de resurse umflate „pentru siguranță". Tradus în bani? Miliarde de dolari irosite anual pe noduri care stau aproape goale.

De ce se întâmplă asta?

Pentru că Kubernetes adaugă un nivel de abstractizare între aplicații și infrastructură. Dezvoltatorii specifică cât CPU și memorie „cred" că au nevoie, scheduler-ul rezervă acea capacitate pe noduri, iar nodurile sunt facturate integral — indiferent dacă pod-urile folosesc efectiv 15% sau 95% din ce au cerut. E ca și cum ai rezerva un apartament cu 5 camere pentru că „s-ar putea" să ai musafiri, dar stai singur acolo 90% din timp.

Acest ghid continuă seria noastră de optimizare a costurilor cloud. Dacă ați parcurs deja articolele despre FinOps Autonom, Reserved Instances și Savings Plans și eliminarea resurselor zombie, aici intrăm în detaliile cu adevărat tehnice — cum optimizați efectiv costurile Kubernetes pe cele trei cloud-uri majore, cu configurații YAML concrete, comenzi CLI și strategii dovedite care pot reduce factura cu 40-70%.

Anatomia Costurilor Kubernetes: Ce Plătiți și De Ce

Înainte de a sări direct la optimizare, trebuie să înțelegeți exact pentru ce plătiți. Costurile Kubernetes au mai multe straturi, și — din experiența noastră — multe organizații se concentrează doar pe cel mai vizibil (compute), ignorând costuri semnificative ascunse.

Structura Costurilor pe Straturi

• Control Plane (Management Fee) — Taxa pentru gestionarea cluster-ului. Pe EKS plătiți $0.10/oră (~$72/lună) per cluster. Pe AKS, control plane-ul e gratuit în tier-ul standard. Pe GKE, taxa e de $0.10/oră, dar beneficiați de un credit gratuit de $74.40/lună per cont de facturare.
• Compute (Noduri) — Costul cel mai mare: mașinile virtuale pe care rulează pod-urile. Aici se concentrează 60-80% din factura Kubernetes.
• Stocare — Persistent Volumes atașate pod-urilor. Diferența între volume premium SSD și standard poate fi uriașă.
• Networking — Egress, load balancere, NAT gateways. Adesea subestimate, dar pot depăși costurile de compute la workload-uri cu trafic intens.
• Add-on-uri — Logging, monitoring, secrets management, service mesh. Se acumulează rapid și sunt frecvent ignorate (până vine factura).

Problema Fundamentală: Request-uri vs. Utilizare Reală

Acesta e conceptul cheie. Kubernetes scheduler-ul plasează pod-urile pe noduri bazându-se pe request-uri (cât CPU/memorie solicită fiecare pod), nu pe utilizarea reală. Dacă un pod solicită 1 vCPU dar folosește efectiv 0.1 vCPU, acel 0.9 vCPU diferență este capacitate blocată dar nefolosită. Nodul o „vede" ca ocupată, alte pod-uri nu pot fi plasate acolo, și plătiți integral.

Multiplicat la sute sau mii de pod-uri, acest gap devine sursa principală de risipă. Reduceri de doar 5-15% per pod se compun la 30-60% economii la nivel de cluster prin bin-packing mai eficient. Numerele par mici individual, dar efectul cumulat e enorm.

Pasul 1: Right-Sizing — Cea Mai Importantă Pârghie de Economisire

Deci, de unde începem? Right-sizing-ul pod-urilor — ajustarea request-urilor și limit-urilor de CPU/memorie la utilizarea reală — este pârghia numărul 1 de reducere a costurilor. Și e totodată cea mai accesibilă: nu necesită schimbări arhitecturale, doar configurație mai inteligentă.

Cum Verificați Utilizarea Reală

Primul pas e să vedeți cât de mult din resursele solicitate sunt efectiv folosite. Metrics Server trebuie să fie instalat în cluster:

# Verificați dacă Metrics Server este instalat
kubectl get deployment metrics-server -n kube-system

# Dacă nu este instalat, adăugați-l
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# Vizualizați utilizarea reală la nivel de pod
kubectl top pods --all-namespaces --sort-by=cpu

# Vizualizați utilizarea reală la nivel de nod
kubectl top nodes

Acum comparați utilizarea reală cu request-urile configurate:

# Script: comparați request-uri vs. utilizare reală pentru un namespace
NAMESPACE="production"
echo "=== Analiza Right-Sizing pentru namespace: $NAMESPACE ==="
echo ""
echo "POD | CPU_REQUEST | CPU_ACTUAL | MEM_REQUEST | MEM_ACTUAL"
echo "------------------------------------------------------------"

kubectl top pods -n "$NAMESPACE" --no-headers | while read POD CPU MEM; do
  REQ_CPU=$(kubectl get pod "$POD" -n "$NAMESPACE" -o jsonpath='{.spec.containers[0].resources.requests.cpu}' 2>/dev/null)
  REQ_MEM=$(kubectl get pod "$POD" -n "$NAMESPACE" -o jsonpath='{.spec.containers[0].resources.requests.memory}' 2>/dev/null)
  echo "$POD | $REQ_CPU | $CPU | $REQ_MEM | $MEM"
done

Reguli Practice pentru Setarea Request-urilor și Limit-urilor

Pe baza datelor de producție din sute de clustere, iată regulile care funcționează cel mai bine:

• Request-uri CPU — Setați la percentila 95 a utilizării reale observate pe ultimele 14 zile. Nu la media, nu la maximum — la P95. Acoperă aproape toate scenariile fără supradimensionare excesivă.
• Limit-uri CPU — Setați la 2x request pentru a permite burst. Sau, și mai bine, nu setați deloc limit de CPU — lăsați pod-ul să consume CPU liber când nodul are capacitate disponibilă. Throttling-ul de CPU din Kubernetes e agresiv și poate cauza latență crescută artificial.
• Request-uri Memorie — La percentila 99. Memoria e mai critică decât CPU — dacă un pod depășește limita de memorie, e ucis (OOMKilled). Mai bine prea mult decât prea puțin.
• Limit-uri Memorie — La 1.5x request-ul de memorie. Suficient pentru spike-uri, dar previne un pod rogue să consume toată memoria nodului.

Exemplu Concret: Înainte și După Right-Sizing

Iată un caz tipic pe care-l vedem constant — un serviciu web provizionat generos la lansare și niciodată ajustat după aceea:

# ÎNAINTE: Request-uri generoase „pentru siguranță"
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 5
  template:
    spec:
      containers:
      - name: api
        image: api-service:v2.1
        resources:
          requests:
            cpu: "1000m"      # 1 vCPU solicitat
            memory: "2Gi"     # 2 GB memorie
          limits:
            cpu: "2000m"
            memory: "4Gi"
# Cost estimat: 5 pod-uri × 1 vCPU = 5 vCPU rezervate
# Utilizare reală: ~150m CPU, ~384Mi memorie per pod

# DUPĂ: Right-sizing bazat pe 14 zile de monitorizare
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 5
  template:
    spec:
      containers:
      - name: api
        image: api-service:v2.1
        resources:
          requests:
            cpu: "200m"       # P95 real: 150m + margin
            memory: "512Mi"   # P99 real: 384Mi + margin
          limits:
            # Fără limit CPU - permitem burst
            memory: "768Mi"   # 1.5x request
# Cost estimat: 5 pod-uri × 0.2 vCPU = 1 vCPU rezervat
# Economie: 80% reducere pe compute pentru acest deployment

80% reducere dintr-o singură modificare de configurație. Și asta e doar un deployment.

Pasul 2: VPA — Vertical Pod Autoscaler pentru Right-Sizing Automat

Right-sizing-ul manual funcționează, dar nu scalează. Dacă aveți zeci sau sute de deployment-uri, nu puteți verifica manual fiecare. Aici intervine Vertical Pod Autoscaler (VPA) — un component Kubernetes care analizează automat utilizarea reală și recomandă (sau aplică) request-uri optime.

Cum Funcționează VPA

VPA are trei componente interne:

• Recommender — Monitorizează continuu utilizarea resurselor și calculează request-uri optime bazate pe istoric.
• Updater — Verifică pod-urile active și le evictează pe cele cu request-uri care diferă semnificativ de recomandări, ca să fie recreate cu valori optime.
• Admission Controller — Interceptează crearea de pod-uri noi și le setează automat request-urile conform recomandărilor.

Moduri de Operare VPA

VPA poate funcționa în mai multe moduri — și acesta e un detaliu pe care mulți îl trec cu vederea:

• Off (Recommendation Only) — Generează recomandări fără a aplica nimic. Ideal pentru început — vedeți ce ar schimba VPA fără niciun risc.
• Initial — Aplică recomandări doar la crearea pod-urilor noi. Pod-urile existente nu sunt afectate. Un compromis bun între automație și siguranță.
• Auto — Aplică recomandări și la pod-urile existente (prin evicție și recreare). Cel mai agresiv mod. Sincer, folosiți-l doar după ce ați validat recomandările în modul Off timp de cel puțin 2 săptămâni.

Instalare și Configurare VPA

# Instalați VPA în cluster
git clone https://github.com/kubernetes/autoscaler.git
cd autoscaler/vertical-pod-autoscaler
./hack/vpa-up.sh

# Verificați că toate componentele rulează
kubectl get pods -n kube-system | grep vpa

Acum creați un obiect VPA pentru deployment-ul care vă interesează — începeți în modul „Off" pentru a vedea recomandările fără risc:

# vpa-api-service.yaml — Modul recomandare (Off)
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-service-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-service
  updatePolicy:
    updateMode: "Off"    # Doar recomandări, fără acțiuni
  resourcePolicy:
    containerPolicies:
    - containerName: api
      minAllowed:
        cpu: "50m"
        memory: "128Mi"
      maxAllowed:
        cpu: "2000m"
        memory: "4Gi"
      controlledResources: ["cpu", "memory"]

# Aplicați configurația
kubectl apply -f vpa-api-service.yaml

# După câteva ore, verificați recomandările
kubectl describe vpa api-service-vpa -n production

Output-ul va arăta recomandări concrete — lower bound, target și upper bound — pentru CPU și memorie. Valorile sunt calculate pe baza utilizării reale observate.

Atenție: Conflictul VPA + HPA

Un avertisment important (și am văzut echipe care au picat în capcana asta): nu folosiți VPA și HPA pe aceeași metrică simultan. Dacă ambele scalează pe CPU, se pot contrazice — VPA crește CPU-ul per pod, HPA adaugă mai multe pod-uri, și rezultatul e o escaladare de costuri în loc de economii. Soluția? Folosiți HPA pe CPU și VPA doar pe memorie, sau VPA doar pe deployment-uri care nu au HPA activ.

Pasul 3: Karpenter — Autoscaling Inteligent la Nivel de Noduri

Right-sizing-ul pod-urilor (Pasul 1 și 2) optimizează cererea. Dar la nivel de noduri, aveți nevoie de un autoscaler care să potrivească oferta de compute cu cererea reală. Aici intervine Karpenter — autoscaler-ul de nouă generație care a înlocuit practic Cluster Autoscaler pe AWS EKS.

De Ce Karpenter > Cluster Autoscaler

Cluster Autoscaler tradițional funcționează cu node groups predefinite. Vreți trei tipuri de instanțe? Creați trei node groups separate. Vreți instanțe diferite pe zone de disponibilitate? Și mai multe node groups. La scară, devine (fără exagerare) un coșmar de administrat.

Karpenter abordează problema radical diferit — fără node groups. Analizează pod-urile pending, selectează automat tipul optim de instanță din perspectivă cost/performanță, și lansează nodul în sub un minut. Dar cel mai important: consolidează automat — identifică noduri subutilizate, mută workload-urile pe noduri mai mici sau mai ieftine, și termină nodurile goale.

Configurare Karpenter cu Optimizare de Cost

Iată o configurație Karpenter optimizată pentru cost, care combină instanțe on-demand pentru baseline și Spot pentru workload-uri tolerante la întreruperi:

# nodepool-general.yaml — NodePool Karpenter v1 optimizat cost
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general-workloads
spec:
  template:
    metadata:
      labels:
        team: platform
        cost-optimization: enabled
    spec:
      requirements:
        # Permiteți atât Spot cât și On-Demand
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]
        # Familii de instanțe cost-eficiente
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values:
            - "m6i.large"
            - "m6a.large"
            - "m6i.xlarge"
            - "m6a.xlarge"
            - "m5.large"
            - "m5.xlarge"
            - "c6i.large"
            - "c6a.large"
        # Arhitectură
        - key: "kubernetes.io/arch"
          operator: In
          values: ["amd64"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      # Nodurile expiră după 72h — forțează refresh și previne drift
      expireAfter: 72h
  # Limitați resursele totale ale pool-ului
  limits:
    cpu: "500"
    memory: 500Gi
  # Consolidare agresivă
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 60s
  # Buget de disruption — max 20% din noduri terminate simultan
  budgets:
    - nodes: "20%"

# ec2nodeclass.yaml — Configurația AWS pentru nodurile Karpenter
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2023
  amiSelectorTerms:
    - alias: al2023@latest
  role: "KarpenterNodeRole-${CLUSTER_NAME}"
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: "${CLUSTER_NAME}"
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: "${CLUSTER_NAME}"
  tags:
    ManagedBy: karpenter
    Environment: production
  # Bloc device optimizat — gp3 e mai ieftin decât gp2
  blockDeviceMappings:
    - deviceName: /dev/xvda
      ebs:
        volumeSize: 50Gi
        volumeType: gp3
        deleteOnTermination: true

EKS Auto Mode: Karpenter Fără Configurare

Dacă nu doriți să gestionați Karpenter manual, Amazon EKS Auto Mode (disponibil de la finalul lui 2024) integrează Karpenter nativ în EKS. Activați-l și EKS se ocupă automat de provizionarea, scalarea și consolidarea nodurilor. E perfect pentru echipe care vor beneficiile Karpenter fără complexitatea operațională — dar pierdeți o parte din controlul granular.

Pasul 4: Spot Instances pentru Kubernetes — Economii de 60-90%

Instanțele Spot (AWS), Spot VMs (Azure) și Preemptible VMs (GCP) oferă capacitate cloud nefolosită la reduceri de 60-90% față de prețul on-demand. În contextul Kubernetes, sunt ideale pentru workload-uri care pot tolera întreruperi — batch processing, CI/CD, ML training, job-uri event-driven.

Implementare Spot pe EKS cu Karpenter

Dacă folosiți deja Karpenter (vezi Pasul 3), Spot e practic configurat — doar includeți "spot" în capacity-type. Karpenter va prefera automat instanțele Spot când sunt disponibile și va face fallback la on-demand când nu sunt.

Pentru workload-uri care trebuie să ruleze obligatoriu pe Spot (job-uri batch, de exemplu), folosiți tolerations:

# deployment-batch-spot.yaml — Workload forțat pe Spot
apiVersion: batch/v1
kind: Job
metadata:
  name: data-processing-job
spec:
  template:
    spec:
      # Toleranță pentru taint-ul Spot
      tolerations:
      - key: "karpenter.sh/capacity-type"
        operator: "Equal"
        value: "spot"
        effect: "NoSchedule"
      # Preferință pentru noduri Spot
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: "karpenter.sh/capacity-type"
                operator: In
                values: ["spot"]
      containers:
      - name: processor
        image: data-processor:latest
        resources:
          requests:
            cpu: "500m"
            memory: "1Gi"
      restartPolicy: OnFailure
  backoffLimit: 3

Spot VMs pe Azure AKS

# Creați un node pool Spot pe AKS
az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name spotnodepool \
  --priority Spot \
  --eviction-policy Delete \
  --spot-max-price -1 \
  --node-count 3 \
  --min-count 1 \
  --max-count 10 \
  --enable-cluster-autoscaler \
  --node-vm-size Standard_D4s_v5 \
  --labels "kubernetes.azure.com/scalesetpriority=spot"

# Verificați node pool-urile
az aks nodepool list \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --output table

Preemptible/Spot VMs pe GKE

# Creați un node pool cu Spot VMs pe GKE
gcloud container node-pools create spot-pool \
  --cluster=my-gke-cluster \
  --zone=europe-west1-b \
  --spot \
  --num-nodes=3 \
  --min-nodes=1 \
  --max-nodes=10 \
  --enable-autoscaling \
  --machine-type=e2-standard-4 \
  --node-labels="cloud.google.com/gke-spot=true"

Gestionarea Întreruperilor Spot

Cel mai mare risc al instanțelor Spot: pot fi reclamate cu un preaviz de doar 2 minute (AWS) sau 30 secunde (GCP). Pare puțin, și chiar e puțin. Dar cu pregătirea potrivită, se poate gestiona:

• Diversificați tipurile de instanțe — Nu depindeți de un singur tip. Configurați 5-10 tipuri eligibile. Karpenter face asta automat.
• PodDisruptionBudgets (PDB) — Asigurați că cel puțin N replici rămân active în orice moment.
• Graceful Shutdown — Configurați terminationGracePeriodSeconds adecvat și gestionați SIGTERM în aplicație.
• AWS Node Termination Handler — Detectează notificări de terminare Spot și evictează graceful pod-urile înainte de terminare.

# pdb-api-service.yaml — Protejați serviciile critice
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-service-pdb
  namespace: production
spec:
  minAvailable: 2    # Minim 2 pod-uri active întotdeauna
  selector:
    matchLabels:
      app: api-service

Pasul 5: Vizibilitate și Monitorizare a Costurilor cu OpenCost

Nu poți optimiza ce nu poți măsura — e un clișeu, dar în cazul costurilor Kubernetes e 100% adevărat. OpenCost este proiectul CNCF de referință pentru monitorizarea costurilor Kubernetes — open-source, vendor-neutral și compatibil cu EKS, AKS și GKE.

Instalare OpenCost

# Instalați OpenCost via 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.prometheus.internal.enabled=true

# Verificați instalarea
kubectl get pods -n opencost

# Accesați dashboard-ul local
kubectl port-forward -n opencost svc/opencost 9090:9090

Interogare Costuri cu kubectl-cost

Plugin-ul kubectl-cost oferă acces rapid la datele de cost direct din terminal — și sincer, e unul din tool-urile pe care le folosim cel mai des:

# Instalați kubectl-cost
kubectl krew install cost

# Vizualizați costurile per namespace
kubectl cost namespace --show-all-resources

# Vizualizați costurile per deployment
kubectl cost deployment -n production

# Vizualizați costurile per label
kubectl cost label -l app --show-all-resources

Noutate 2026: OpenCost MCP Server pentru Agenți AI

Începând cu versiunea 1.118, OpenCost include un MCP (Model Context Protocol) Server integrat. Acesta permite agenților AI să acceseze direct datele de cost Kubernetes — pentru analiză automată, predicții și recomandări de optimizare. Server-ul MCP rulează pe portul 8081 și e activat implicit. Dacă ați citit articolul nostru despre FinOps Autonom, acesta e exact tipul de integrare AI-cost care face posibilă optimizarea autonomă.

Kubecost pentru Funcționalități Enterprise

OpenCost e excelent pentru vizibilitate de bază. Dar dacă aveți nevoie de funcționalități enterprise — reconciliere cu factura reală (inclusiv discounturi negociate), alerte de buget, guvernanță multi-cluster, rapoarte detaliate — Kubecost (care se bazează pe motorul OpenCost) e varianta de luat în considerare. Instalarea e la fel de simplă:

# Instalați Kubecost
helm repo add kubecost https://kubecost.github.io/cost-analyzer/
helm upgrade --install kubecost kubecost/cost-analyzer \
  --namespace kubecost \
  --create-namespace

# Accesați dashboard-ul
kubectl port-forward -n kubecost svc/kubecost-cost-analyzer 9090:9090

Pasul 6: Strategii Specifice per Cloud — EKS, AKS, GKE

Fiecare cloud are particularitățile lui când vine vorba de costurile Kubernetes. Iată ce merită să știți pentru fiecare.

Amazon EKS — Optimizări Specifice

• Folosiți Karpenter sau EKS Auto Mode în loc de Cluster Autoscaler. Karpenter selectează automat tipul optim de instanță și consolidează agresiv nodurile subutilizate.
• Instanțe Graviton (ARM64) — Instanțele bazate pe AWS Graviton (m7g, c7g, r7g) sunt cu 20% mai ieftine și oferă performanță similară sau mai bună decât x86. Dacă aplicațiile suportă ARM64, migrarea e una din cele mai simple și mai eficiente optimizări pe care le puteți face.
• Compute Savings Plans — Se aplică și pe nodurile EKS (sunt instanțe EC2 underneath). Combinați Savings Plans pentru baseline-ul stabil cu Spot pentru variabilitate.
• EKS Extended Support — Dacă nu actualizați versiunea Kubernetes la timp, AWS taxează $0.60/oră (în loc de $0.10) pentru cluster-ele în extended support. Un motiv în plus să mențineți versiunile la zi.

Azure AKS — Optimizări Specifice

• Control plane gratuit — AKS nu taxează pentru control plane în tier-ul standard. Economisire directă vs. EKS ($72/lună) și GKE.
• Azure Spot VMs — Reduceri de până la 90%. Configurați node pools dedicate Spot cu eviction policy „Delete" pentru workload-uri tolerante la întreruperi.
• Azure Reservations — Se aplică pe VM-urile din nodurile AKS. Combinați cu Azure Savings Plans for Compute pentru flexibilitate maximă.
• Start/Stop Clusters — AKS permite oprirea completă a cluster-elor de dev/test. Când clusterul e oprit, nu plătiți pentru compute — doar stocare. O funcționalitate surprinzător de utilă.

# Opriți un cluster AKS de dev (economie imediată pe compute)
az aks stop \
  --resource-group myResourceGroup \
  --name dev-cluster

# Porniți-l înapoi când e necesar
az aks start \
  --resource-group myResourceGroup \
  --name dev-cluster

Google GKE — Optimizări Specifice

• GKE Autopilot vs. Standard — Autopilot facturează per resurse pod, nu per nod. Pe hârtie pare mai scump, dar pentru workload-uri cu utilizare variabilă, Autopilot poate fi cu 50% mai ieftin decât Standard, deoarece nu plătiți pentru capacitate de nod nefolosită.
• Committed Use Discounts (CUDs) — Din ianuarie 2026, Google a migrat complet la CUD-uri spend-based flexibile. Reduceri de 28% (1 an) sau 46% (3 ani), aplicabile atât pe Standard cât și pe Autopilot.
• E2 vs. N2 — Instanțele E2 sunt cu 20-30% mai ieftine decât N2 și suficiente pentru majoritatea workload-urilor. Folosiți N2 sau C2 doar pentru workload-uri compute-intensive.
• Spot VMs pe GKE — Reduceri de 60-91%. Funcționează similar cu AWS Spot, dar cu preaviz de doar 30 secunde.

Pasul 7: Governance as Code — Preveniți Risipa de la Început

Optimizarea reactivă funcționează, dar e ineficientă — curățați după ce risipa s-a acumulat deja. În 2026, organizațiile mature tratează guvernanța costurilor ca pe cod — exact ca securitatea sau reliability-ul. Politicile sunt aplicate automat la deploy, nu verificate manual post-factum.

LimitRange — Setați Valori Implicite și Maxime per Namespace

# limitrange-production.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: cost-guardrails
  namespace: production
spec:
  limits:
  - type: Container
    default:          # Limite implicite dacă nu sunt specificate
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:   # Request-uri implicite
      cpu: "100m"
      memory: "128Mi"
    max:              # Maxim permis per container
      cpu: "4000m"
      memory: "8Gi"
    min:              # Minim permis
      cpu: "50m"
      memory: "64Mi"

ResourceQuota — Limitați Resursele Totale per Namespace

# resourcequota-team-backend.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-backend-quota
  namespace: team-backend
spec:
  hard:
    requests.cpu: "20"        # Max 20 vCPU solicitate total
    requests.memory: "40Gi"   # Max 40 Gi memorie
    limits.cpu: "40"
    limits.memory: "80Gi"
    pods: "100"               # Max 100 pod-uri în namespace
    persistentvolumeclaims: "20"

Labeling Obligatoriu pentru Alocare Costuri

Fără labeling consistent, nu puteți atribui costurile pe echipe sau proiecte. Și fără atribuire clară, nimeni nu se simte responsabil. Impuneți label-uri obligatorii folosind admission controllers:

# kyverno-require-labels.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-cost-labels
spec:
  validationFailureAction: Enforce
  rules:
  - name: require-team-label
    match:
      any:
      - resources:
          kinds:
          - Deployment
          - StatefulSet
          - Job
    validate:
      message: "Label-urile 'team' și 'cost-center' sunt obligatorii."
      pattern:
        metadata:
          labels:
            team: "?*"
            cost-center: "?*"

Checklist de Optimizare Kubernetes: Acțiuni Concrete

Hai să recapitulăm. Iată un rezumat acționabil al tuturor pașilor — fiecare punct debifat înseamnă economii reale:

1. Audit request-uri vs. utilizare reală — Rulați kubectl top pods și comparați cu request-urile. Identificați pod-urile cu utilizare sub 30% din request.
2. Implementați VPA în modul Off — Lăsați-l 2 săptămâni să colecteze date, apoi aplicați recomandările.
3. Migrați de la Cluster Autoscaler la Karpenter (EKS) — Activați consolidarea agresivă.
4. Adăugați node pools Spot — Pe toate cele trei cloud-uri, pentru workload-uri tolerante la întreruperi.
5. Instalați OpenCost sau Kubecost — Vizibilitate pe namespace, deployment și label.
6. Configurați LimitRange și ResourceQuota — Preveniți supraprovizionarea de la deploy.
7. Impuneți labeling obligatoriu — Cu Kyverno sau OPA Gatekeeper.
8. Opriți mediile de dev/test în afara orelor de lucru — AKS Start/Stop, sau CronJobs care scalează la zero.
9. Evaluați instanțe ARM64/Graviton (AWS) sau E2 (GCP) — 20-30% mai ieftine.
10. Revizuiți lunar — Costurile Kubernetes nu sunt „set and forget". Programați review-uri lunare ale recomandărilor VPA și rapoartelor de cost.

Întrebări Frecvente (FAQ)

Cât pot economisi cu optimizarea costurilor Kubernetes?

Pe baza datelor din producție, organizațiile care aplică sistematic right-sizing, autoscaling inteligent și instanțe Spot obțin reduceri de 40-70% din costurile Kubernetes. Chiar și optimizări moderate — doar right-sizing-ul request-urilor — generează economii de 30-40%. Cheia e abordarea sistematică: nicio singură tactică nu rezolvă totul, dar combinarea lor produce rezultate pe care nu le-ați aștepta.

Este sigur să folosesc instanțe Spot pentru Kubernetes în producție?

Da, dar cu precauții. Instanțele Spot sunt sigure pentru workload-uri stateless, replicabile și tolerante la întreruperi — servicii web cu multiple replici, job-uri batch, pipeline-uri CI/CD, antrenament ML. Nu le folosiți pentru baze de date, servicii singleton sau workload-uri cu stare persistentă. Combinați Spot cu PodDisruptionBudgets, diversificare de tipuri de instanțe și graceful shutdown handling.

Ce diferențe de cost există între EKS, AKS și GKE?

Diferența principală la nivel de management: AKS oferă control plane gratuit, EKS costă ~$72/lună per cluster, iar GKE are un credit gratuit de $74.40/lună. La nivel de compute, prețurile sunt comparabile, dar fiecare cloud are avantaje specifice: AWS are Graviton (ARM64 mai ieftin), Azure oferă Start/Stop pentru clustere de dev, iar GKE are Autopilot care facturează per pod. La finalul zilei, alegerea depinde de ecosistemul dvs. existent, nu doar de prețul Kubernetes.

VPA sau HPA — care este mai bun pentru optimizarea costurilor?

Nu sunt alternative — sunt complementare. VPA optimizează resursele per pod individual (vertical), HPA optimizează numărul de replici (orizontal). Strategia ideală le folosește pe amândouă: HPA scalează replicile pe baza traficului, VPA ajustează request-urile per pod la utilizarea reală. Atenție doar să nu le configurați pe aceeași metrică (de exemplu, ambele pe CPU), ca să nu se contrazică.

Cum monitorizez costurile Kubernetes în timp real?

OpenCost (proiect CNCF, gratuit, open-source) e soluția de referință. Se instalează în câteva minute cu Helm, oferă dashboard web și API-uri, și funcționează pe EKS, AKS și GKE. Pentru funcționalități enterprise, Kubecost extinde OpenCost cu un tier gratuit generos. Din 2026, OpenCost include și un server MCP pentru integrare cu agenți AI de optimizare — lucru care deschide posibilități interesante pentru automatizare.