Kubernetes Right-Sizing: VPA Guide (2026)

Varför right-sizing är den viktigaste åtgärden för Kubernetes-kostnader

Kubernetes har blivit standardplattformen för containerorkestrering — över 96 % av organisationerna använder det i någon form 2026. Men med den breda användningen följer ett problem som förvånansvärt många ignorerar: massiv överallokering av resurser.

Branschdata visar att i genomsnitt bara 13 % av begärd CPU faktiskt utnyttjas. Tänk på det en sekund. 13 %. Mellan 20–45 % av begärda resurser driver faktiska arbetsbelastningar, vilket innebär att mer än hälften av din molnbudget kan gå rakt ner i avloppet på oanvända resurser.

Right-sizing — att anpassa CPU- och minnesresurser till det faktiska behovet — är ärligt talat den mest effektiva åtgärden du kan vidta. Även ganska små justeringar på 5–15 % per pod kan ge 30–60 % lägre klusterkostnader tack vare bättre bin-packing och färre onödiga noder. Det är inga småpengar.

I den här guiden går vi igenom steg för steg hur du använder Vertical Pod Autoscaler (VPA) och Goldilocks för att identifiera och genomföra right-sizing i dina Kubernetes-kluster — med praktiska kodexempel som fungerar på AWS EKS, Azure AKS och Google GKE.

Så fungerar requests och limits i Kubernetes

Innan vi dyker ner i verktygen behöver vi förstå de grundläggande mekanismerna som styr resursanvändning i Kubernetes. Det här är grunden som allt annat bygger på, så häng med.

Requests: det du reserverar

Requests anger den minsta mängd CPU och minne som en container garanteras. Kubernetes-schemaläggaren (kube-scheduler) använder dessa värden för att bestämma på vilken nod en pod ska placeras. Enkelt uttryckt: om en nod inte har tillräckligt med lediga resurser för att uppfylla poddens requests, schemaläggs den helt enkelt inte där.

Limits: det du begränsar

Limits sätter ett tak för hur mycket resurser en container får använda. Överstiger en container sin CPU-limit blir den throttlad — den tvingas vänta på nästa CPU-period. Överstiger den sin minneslimit? Då blir den OOM-killad (Out Of Memory) och startas om. Inte kul.

QoS-klasser som styrs av requests och limits

Kubernetes tilldelar varje pod en Quality of Service-klass baserat på hur requests och limits är konfigurerade:

Guaranteed — requests och limits är identiska. Dessa pods har högst prioritet och är sist att eviktas vid resurstryck.
Burstable — requests och limits skiljer sig åt. Pods kan använda mer resurser än begärt om det finns tillgängligt, men eviktas före Guaranteed-pods.
BestEffort — inga requests eller limits satta alls. Dessa pods saknar resursgarantier och eviktas först (undvik detta i produktion).

Bästa praxis för requests och limits 2026

De senaste rekommendationerna från Kubernetes-communityn och FinOps-ramverket pekar på följande strategi:

CPU requests: Basera på P95 (95:e percentilen) av observerad användning under 24 timmar.
Minnesrequests: Basera på P99 (99:e percentilen) — du vill ha extra marginal här eftersom minnestoppar kan orsaka OOM-kills.
CPU limits: Undvik att sätta dessa för prestandakritiska applikationer. CPU-throttling kan dramatiskt försämra responstider, även när klustret har gott om ledig kapacitet.
Minneslimits: Sätt alltid minneslimits. Utan dem riskerar en enda container att ta ner hela noden.

Vad är Vertical Pod Autoscaler (VPA)?

VPA är en Kubernetes-komponent som automatiskt analyserar pods resursanvändning över tid och antingen rekommenderar eller direkt justerar CPU- och minnesrequests. Den består av tre delar:

Recommender — observerar resursanvändning och beräknar optimala värden.
Admission Controller — fångar upp nya pod-skapelser och tillämpar VPA-rekommendationer direkt.
Updater — eviktar och återskapar pods med uppdaterade resursvärden när det behövs.

VPA:s tre driftlägen

VPA stöder tre lägen med olika nivåer av automatisering:

Off — Beräknar rekommendationer men gör inga ändringar. Perfekt för att komma igång och bygga upp förtroende.
Initial — Sätter resursvärden enbart vid podskapande, rör inte pods som redan körs.
Auto — Eviktar och återskapar pods med uppdaterade requests automatiskt. Kraftfullt men kräver försiktighet.

Steg 1: Installera VPA i ditt kluster

Okej, dags att bli praktisk. Det finns två sätt att installera VPA — välj det som passar din miljö bäst:

Alternativ A: Officiella manifest

git clone https://github.com/kubernetes/autoscaler.git
cd autoscaler/vertical-pod-autoscaler
./hack/vpa-up.sh

# Verifiera att alla komponenter körs
kubectl get pods -n kube-system | grep vpa

Alternativ B: Helm-installation

helm repo add cowboysysop https://cowboysysop.github.io/charts/
helm install vpa cowboysysop/vertical-pod-autoscaler \
  --namespace kube-system

Viktigt: Om du bara vill ha rekommendationer (utan automatisk uppdatering) kan du installera enbart recommender-komponenten. Det är faktiskt vad jag rekommenderar till en början — det undviker att admission webhook introducerar oväntade ändringar i klustret.

Steg 2: Skapa en VPA-resurs i rekommendationsläge

Börja alltid med updateMode: "Off" för att samla in data utan att påverka körande pods. Inga överraskningar, bara datainsamling:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: min-app-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: min-app
  updatePolicy:
    updateMode: "Off"

Applicera med:

kubectl apply -f min-app-vpa.yaml

Låt VPA samla data i minst 24–48 timmar. Det kan vara frestande att kolla efter ett par timmar, men du behöver faktiskt data som täcker normala trafikmönster — inklusive eventuella dagliga toppar.

Steg 3: Granska VPA-rekommendationer

Nu börjar det bli intressant. Efter att VPA har samlat in tillräckligt med data kan du läsa av rekommendationerna:

kubectl describe vpa min-app-vpa -n production

Utdata visar fyra nyckelvärden per container:

Target — det rekommenderade värdet, baserat på aktuell användning.
Lower Bound — minimivärdet som VPA anser tillräckligt.
Upper Bound — maxvärdet VPA förväntar sig att behövas.
Uncapped Target — rekommendation utan hänsyn till eventuella min/max-gränser.

Här brukar folk bli förvånade. En pod som begär 500m CPU och 512Mi minne kanske faktiskt bara behöver 25m CPU och 52Mi minne. Det är en besparing på över 90 % — för en enda pod. Multiplicera det med alla pods i klustret och du förstår varför right-sizing är så kraftfullt.

Steg 4: Sätt resursgränser med resourcePolicy

Innan du (eller VPA) börjar tillämpa rekommendationer vill du ha säkerhetsmarginaler. Definiera min- och maxgränser för att förhindra orimligt låga eller höga värden:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: min-app-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: min-app
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: min-app-container
      minAllowed:
        cpu: 50m
        memory: 64Mi
      maxAllowed:
        cpu: 2
        memory: 4Gi

Steg 5: Installera Goldilocks för visuella rekommendationer

VPA:s rekommendationer via kubectl är bra, men om du har tiotals eller hundratals deployments blir det snabbt ohanterligt. Det är här Goldilocks kommer in.

Goldilocks är ett open source-verktyg från Fairwinds som skapar en visuell dashboard ovanpå VPA:s rekommendationer. Det gör det enkelt att snabbt identifiera de mest överallokerade poddarna i hela klustret — utan att behöva köra kubectl describe på varenda VPA-objekt.

Installation med Helm

helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm upgrade --install goldilocks fairwinds-stable/goldilocks \
  --namespace goldilocks \
  --create-namespace \
  --set vpa.enabled=true

Aktivera Goldilocks för ett namespace

# Aktivera övervakning för production-namespacet
kubectl label ns production goldilocks.fairwinds.com/enabled=true

# Verifiera att VPA-objekt har skapats
kubectl get vpa -n production

Öppna Goldilocks dashboard

kubectl -n goldilocks port-forward svc/goldilocks-dashboard 8080:80

Öppna http://localhost:8080 i din webbläsare. Du ser nu rekommendationer för varje deployment med två QoS-varianter:

Guaranteed — target-värdet sätts som både request och limit. Ger högst stabilitet.
Burstable — lowerBound som request och upperBound som limit. Tillåter resursburst vid behov.

Steg 6: Tillämpa rekommendationerna

Nu till den roliga delen — att faktiskt spara pengar. Baserat på Goldilocks dashboard kan du uppdatera dina deployment-manifest. Här är ett typiskt före och efter:

Före (överallokerad)

resources:
  requests:
    cpu: 500m
    memory: 512Mi
  limits:
    cpu: 1000m
    memory: 1Gi

Efter (right-sized baserat på VPA-rekommendation)

resources:
  requests:
    cpu: 80m
    memory: 128Mi
  limits:
    memory: 256Mi
  # CPU limit borttagen — tillåt burstbar CPU-användning

Tips: Ta bort CPU-limits för de flesta arbetsbelastningar. Kubernetes throttlar CPU även när noden har gott om ledig kapacitet, vilket leder till helt onödig latens. Behåll däremot alltid minneslimits för att förhindra OOM-situationer på nodnivå.

Steg 7: Övervaka besparingar med Prometheus-frågor

Du har gjort ändringarna — men hur vet du att de faktiskt gör skillnad? Använd dessa PromQL-frågor för att mäta effekten:

CPU-utnyttjandegrad per namespace

sum(rate(container_cpu_usage_seconds_total{namespace="production"}[5m]))
/
sum(kube_pod_container_resource_requests{namespace="production", resource="cpu"})
* 100

Minnesanvändning jämfört med requests

sum(container_memory_working_set_bytes{namespace="production"})
/
sum(kube_pod_container_resource_requests{namespace="production", resource="memory"})
* 100

Sikta på 60–80 % utnyttjande — det är sweet spot. Under 30 % tyder på fortsatt överallokering. Över 90 % innebär risk för prestandaproblem och du har förmodligen skurit för nära benet.

Kombinera VPA med HPA utan konflikter

En vanlig fråga vi får är om VPA och HPA (Horizontal Pod Autoscaler) kan köras samtidigt. Svaret är ja, men med en viktig regel:

Låt inte VPA och HPA skala på samma mätvärde. Om HPA skalar baserat på CPU bör VPA inte justera CPU-requests automatiskt — annars börjar de motarbeta varandra.
En beprövad kombination: HPA hanterar CPU-baserad horisontell skalning, VPA hanterar minnesjusteringar i Off- eller Initial-läge.
Alternativt (och det här är vad de flesta team faktiskt gör): kör VPA enbart i rekommendationsläge och gör manuella justeringar baserat på dess förslag, medan HPA hanterar all automatisk skalning.

Automatisera right-sizing i CI/CD-pipelines

Vill du ta det ett steg längre? För team som vill göra right-sizing till en kontinuerlig process finns det smarta sätt att integrera det i befintliga arbetsflöden:

Exportera VPA-rekommendationer som JSON och jämför dem med nuvarande manifest i en CI-pipeline.
Generera pull requests automatiskt när rekommendationerna avviker mer än en viss tröskel (t.ex. 20 %).
Validera med kubeval eller OPA/Gatekeeper att uppdaterade värden respekterar LimitRanges och ResourceQuotas.

Här är ett exempel på ett skript som exporterar VPA-rekommendationer:

#!/bin/bash
# Exportera VPA-rekommendationer för alla VPA-objekt i ett namespace
NAMESPACE="production"

for vpa in $(kubectl get vpa -n $NAMESPACE -o jsonpath='{.items[*].metadata.name}'); do
  echo "=== $vpa ==="
  kubectl get vpa $vpa -n $NAMESPACE -o jsonpath='{.status.recommendation.containerRecommendations[*]}' | jq .
done

Vanliga misstag att undvika

Vi har sett dessa misstag upprepas om och om igen hos team som jobbar med Kubernetes-kostnadsoptimering. Lär dig av andras erfarenheter:

Sätta VPA i Auto-läge direkt i produktion — börja alltid med Off-läge. Auto-läge eviktar och återskapar pods, vilket kan orsaka korta avbrott som inte uppskattas av vare sig användare eller on-call-teamet.
Ignorera startbeteende — Java- och .NET-applikationer behöver ofta betydligt mer resurser vid uppstart än under normal drift. Sätt minAllowed i resourcePolicy baserat på startbehov, inte bara steady-state.
Missa Cluster Autoscaler-kopplingen — right-sizing minskar resursbehovet per pod, men besparingarna syns inte på molnfakturan förrän Cluster Autoscaler (eller Karpenter) faktiskt tar bort överflödiga noder. Det här missas förvånansvärt ofta.
Använda samma inställningar för alla arbetsbelastningar — batch-jobb, API-servrar och cron-jobb har fundamentalt olika resursprofiler och kräver individuella VPA-policies.

Förväntade besparingar och ROI

Så, vad kan du faktiskt förvänta dig? Baserat på branschdata från FinOps Foundation State of FinOps 2026-rapporten:

30–50 % lägre Kubernetes-kostnader genom systematisk right-sizing.
Förbättrad klusterstabilitet tack vare korrekta resursinställningar som minskar OOM-kills och CPU-throttling.
Bättre bin-packing — fler pods per nod innebär färre noder i klustret.

Tidsramen? Räkna med 1–2 veckor för dataanalys med VPA i Off-läge, sedan ytterligare 1–2 veckor för att rulla ut justeringarna gradvis. Inte omedelbart, men definitivt värt väntan.

FAQ — Vanliga frågor om Kubernetes right-sizing

Hur vet jag om mina Kubernetes-pods är överallokerade?

Det enklaste sättet är att installera Goldilocks i ditt kluster och aktivera det för relevanta namespaces. Dashboarden visar omedelbart skillnaden mellan begärda och rekommenderade resurser. Du kan också använda PromQL-frågorna vi gick igenom ovan. Ett utnyttjande under 30 % är en ganska tydlig signal på överallokering.

Kan VPA och HPA köras samtidigt?

Ja, men de får inte skala på samma mätvärde. En beprövad kombination är att låta HPA hantera CPU-baserad horisontell skalning medan VPA justerar minnesrequests. Kör alltid VPA i Off- eller Initial-läge när du kombinerar med HPA för att undvika konflikter.

Är det säkert att köra VPA i Auto-läge i produktion?

Det beror på. Auto-läge eviktar och återskapar pods för att tillämpa nya resursvärden, vilket orsakar korta avbrott. Med rätt PodDisruptionBudgets, tillräckligt många repliker och gradvis utrullning kan det vara säkert. Men börja alltid med Off-läge och övergå till Auto först när du validerat rekommendationerna noggrant.

Hur ofta bör jag granska mina resursrekommendationer?

Minst en gång i månaden, och alltid efter större förändringar som ny applikationsversion, ändrade trafikmönster eller byte av instanstyp. I aktiva utvecklingsmiljöer kan veckovis granskning vara motiverad.

Fungerar VPA och Goldilocks på alla molnplattformar?

Ja. VPA och Goldilocks är Kubernetes-nativa verktyg som fungerar på alla plattformar som stöder Kubernetes — inklusive AWS EKS, Azure AKS, Google GKE och självhostade kluster. GKE erbjuder dessutom inbyggt VPA-stöd med enkel aktivering via konsolen, vilket gör det ännu smidigare att komma igång.