I desember 2025 gikk en av de mest etterlengtede Kubernetes-funksjonene fra beta til stabil status: muligheten til å endre CPU- og minnegrenser på en kjørende pod uten å restarte den. Funksjonen heter in-place pod resize, og den er nå slått på som standard i alle klynger som kjører Kubernetes 1.35 eller nyere. Med versjon 1.36 ute siden april 2026, og 1.37 rett rundt hjørnet 26. august 2026, er dette ikke lenger en eksperimentell funksjon du må aktivere manuelt. Den er der, den virker, og de fleste teamene har ennå ikke tatt den i bruk.
Denne guiden viser deg hvordan du setter opp, tester og bruker in-place pod resize i praksis, fra første feature-sjekk til et komplett produksjonsklart oppsett med Vertical Pod Autoscaler. Du får 12 konkrete steg, fem+ kodeeksempler du kan kjøre direkte, og en liste over fallgruvene som får folk til å tro funksjonen ikke virker (den virker, men reglene rundt QoS-klasser og cgroup v2 er strengere enn de fleste forventer).
Hva er in-place pod resize i Kubernetes?
Før 1.27 var det bare én måte å endre ressursene til en kjørende container på: slette poden og lage en ny. For en Deployment betyr det en rullende omstart. For en StatefulSet med lokal state kan det bety timer med resynkronisering. In-place pod resize fjerner det steget. Feltet spec.containers[*].resources er nå mutable for CPU og minne, og kubelet kan justere cgroup-grensene til en container mens den fortsatt kjører.
Funksjonen styres av feature-gaten InPlacePodVerticalScaling. Den kom som alpha i Kubernetes 1.27 (mai 2023), gikk til beta i 1.33 (mai 2025), og ble stabil (GA) i 1.35, som ble sluppet 17. desember 2025. Fra og med GA er gaten slått på som standard, du trenger ikke lenger å aktivere den manuelt på kontrollplanet eller nodene, forutsatt at du kjører en oppdatert distribusjon.
Bruksområdene er konkrete: spillservere som må vokse når flere spillere kobler seg til, forhåndsvarmede arbeidere som kan krympes mens de er inaktive og blåses opp ved første forespørsel, JIT-kompilerte runtime-er som trenger et CPU-støt ved oppstart og deretter kan skrus ned, og generell bin-packing der du vil unngå å kaste bort noder på pods som er overdimensjonert for sikkerhets skyld.
For norske og nordiske driftsteam er dette spesielt relevant nå. Strømpriser og datasenterkapasitet har vært et tilbakevendende samtaleemne i regionen, og flere skyleverandører har begynt å prise inn kapasitetsknapphet tydeligere i fakturaene. Å kunne skalere en pod presist, uten å måtte runde opp til nærmeste hele node eller planlegge for verste-tenkelige-tilfelle hele tiden, gjør ressursbudsjettering enklere å forsvare internt, uansett om klyngen kjører hos en global hyperscaler eller en lokal leverandør.
In-place resize sammenlignet med tradisjonell recreate
Den gamle metoden for å endre ressurser på en pod var å oppdatere Deployment-specen og la Kubernetes rulle ut nye pods, en etter en. Det virker, men det koster mer enn folk flest tenker over. Hver ny pod må planlegges på nytt av schedulereren, hente et nytt container-image fra cache eller registry, kjøre gjennom readiness-probes, og eventuelt vente på at en load balancer oppdager den nye IP-adressen. For en StatefulSet med lokal disk kan dette bety en full resynkronisering av data.
| Egenskap | Tradisjonell recreate | In-place resize |
|---|---|---|
| Container-restart | Alltid | Kun hvis resizePolicy er RestartContainer |
| Ny IP-adresse til poden | Ja, hver gang | Nei, samme pod beholdes |
| Scheduler kjøres på nytt | Ja, full re-scheduling | Nei, kun kapasitetssjekk på samme node |
| Påvirker StatefulSet lokal state | Kan kreve resynkronisering | Ingen påvirkning, disken forblir festet |
| Krever oppdatert kubectl | Nei | Ja, v1.32 eller nyere for subresource-flagget |
Den praktiske konsekvensen er at et team som driver mange små, trafikktunge tjenester kan kutte antall unødvendige pod-recreates betraktelig, spesielt for arbeidslaster som allerede har VPA konfigurert i den gamle Recreate-modusen. Det er også derfor VPA-teamet i Kubernetes prioriterte InPlaceOrRecreate som neste steg etter at selve resize-funksjonen ble stabil.
Forutsetninger og versjonskrav
Du trenger ikke et stort produksjonsmiljø for å følge denne guiden. Et lokalt testcluster holder for de fleste stegene, men sett av et vindu i staging før du ruller ut mot produksjon.
| Komponent | Minstekrav | Anbefalt for GA-oppførsel |
|---|---|---|
| Kubernetes-server | v1.33 (beta) | v1.35 eller nyere (GA, standard på) |
| kubectl-klient | v1.32 | v1.36 (matcher serveren) |
| Container-runtime | containerd 1.6+ eller CRI-O 1.24+ | containerd 2.0+ |
| cgroup-versjon på noder | cgroup v1 (begrenset) | cgroup v2 |
| Operativsystem på noder | Linux | Linux (Windows støttes ikke) |
| Testverktøy | minikube 1.33+ | kind 0.24+ med node-image v1.36 |
Legg merke til cgroup-kravet. Minnenedskalering med best-effort-beskyttelse fungerer riktig kun på cgroup v2. De fleste moderne distribusjoner (Ubuntu 22.04+, Amazon Linux 2023, Bottlerocket) kjører cgroup v2 som standard, men eldre noder med Amazon Linux 2 eller Ubuntu 20.04 kjører ofte fortsatt cgroup v1, og der vil enkelte minne-resizer feile stille.
Sjekk cgroup-versjonen på en node før du går videre med kommandoen stat -fc %T /sys/fs/cgroup/ kjørt via en debug-pod eller SSH. Svaret cgroup2fs betyr at noden kjører v2 og er klar. Svaret tmpfs betyr v1, og da bør du planlegge en node-oppgradering før dere ruller ut minne-resize i produksjon, ikke bare CPU-resize som fungerer greit på begge versjoner.
Steg 1: Verifiser klynge- og kubectl-versjon
Start med å sjekke hva du faktisk kjører. Mange team har ulike patch-versjoner på tvers av klynger, og resize-subressursen krever at kubectl-klienten matcher eller ligger nært serverversjonen.
kubectl version --short
kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.kubeletVersion}'Outputen bør vise minst 1.33 på både klient og server. Kjører du under 1.35, husk at gaten ikke nødvendigvis er slått på ennå på eldre administrerte klynger, selv om selve Kubernetes-versjonen støtter beta-funksjonen.
Steg 2: Bekreft at InPlacePodVerticalScaling er aktivert
På egenforvaltede klynger sjekker du feature-gaten direkte på kube-apiserver og kubelet. På administrerte tjenester som EKS, AKS eller GKE er den som regel allerede slått på fra 1.35, men det er verdt å bekrefte før du planlegger en migrering.
# Egenforvaltet klynge: se etter flagget i manifestene
grep -r "InPlacePodVerticalScaling" /etc/kubernetes/manifests/kube-apiserver.yaml
# Enklere test: sjekk om resize-subressursen finnes
kubectl api-resources --api-group="" | grep pods/resizeHvis pods/resize ikke dukker opp i listen, kjører klyngen din enten under 1.33, eller gaten er eksplisitt slått av. Da må en klyngeadministrator legge til --feature-gates=InPlacePodVerticalScaling=true på kube-apiserver, kube-scheduler og kubelet, og restarte komponentene i tur og orden.
Steg 3: Sett opp et testcluster med kind
For å teste trygt uten å røre en delt klynge, bruk kind (Kubernetes in Docker) med et nytt nok node-image. Dette gir deg full kontroll over versjon og feature-gates lokalt.
cat <<EOF > kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
image: kindest/node:v1.36.0
- role: worker
image: kindest/node:v1.36.0
EOF
kind create cluster --name resize-lab --config kind-config.yaml
kubectl cluster-info --context kind-resize-labForventet output er en bekreftelse på at kontrollplanet og CoreDNS kjører, typisk innen 60-90 sekunder på en bærbar maskin med fire kjerner. Har du ikke Docker installert lokalt, fungerer minikube med --kubernetes-version=v1.36.0 like bra.
Steg 4: Deploy en pod med resizePolicy
Nøkkelfeltet er resizePolicy, som du setter per ressurstype (CPU og minne) på hver container. Standardverdien er NotRequired, som betyr at kubelet prøver å bruke den nye grensen uten restart. Setter du RestartContainer, tvinger du frem en restart hver gang den ressursen endres, noe som er nyttig for runtime-er som ikke takler å få CPU-grensen endret under kjøring.
apiVersion: v1
kind: Pod
metadata:
name: resize-demo
namespace: default
spec:
containers:
- name: app
image: registry.k8s.io/pause:3.9
resizePolicy:
- resourceName: cpu
restartPolicy: NotRequired
- resourceName: memory
restartPolicy: NotRequired
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 200m
memory: 256Mi
---
kubectl apply -f resize-demo.yaml
kubectl get pod resize-demo -o jsonpath='{.status.qosClass}'Sistnevnte kommando forteller deg hvilken QoS-klasse poden fikk. Med requests under limits blir det Burstable, og det påvirker akkurat hvilke resizer du får lov til å gjøre senere i denne guiden.
Steg 5: Forstå QoS-klasser og begrensningene de setter
Dette er stedet der de fleste teamene går i baret. Kubernetes lar deg ikke bytte QoS-klasse gjennom en resize, uansett hvor liten endringen er. Reglene er strenge og gjelder likt fra beta til GA:
- Guaranteed: requests må fortsatt være lik limits etter resize. Endrer du kun requests, feiler kallet.
- Burstable: requests og limits kan ikke bli like etter en resize, det ville flyttet poden til Guaranteed.
- BestEffort: du kan ikke legge til ressurskrav i det hele tatt via resize, poden må starte på nytt med krav definert fra start.
Init-containere og ephemeral containers kan ikke resizes, mens sidecar-containere (init-containere med restartPolicy: Always) kan. Pods som styres av statiske CPU- eller minnehåndteringspolicyer på noden (static policy i kubelet) er også utelatt, fordi de allerede har eksklusiv tilgang til fysiske kjerner som ikke enkelt kan endres på flukt.
Sjekk QoS-klassen før du designer en resize-strategi, ikke etter. Hvis appen din i dag kjører som BestEffort fordi ingen har satt requests og limits, må du først gjøre en vanlig oppdatering (med restart) for å gi den en QoS-klasse med ressurskrav, før du kan begynne å bruke in-place resize videre derfra. Dette er et engangsarbeid, men det overrasker team som forventer å kunne gå rett fra BestEffort til automatisk skalering uten mellomsteg.
Steg 6: Utfør en CPU-resize uten restart
Med testpoden oppe, prøv den første ekte resizen. Kommandoen bruker --subresource=resize, som krever kubectl v1.32 eller nyere.
kubectl patch pod resize-demo --subresource=resize -p \
'{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"150m"},"limits":{"cpu":"300m"}}}]}}'
kubectl get pod resize-demo -o jsonpath='{.status.containerStatuses[0].resources}'Output fra den siste kommandoen viser feltene requests og limits slik kubelet faktisk har konfigurert dem, altså den bekreftede tilstanden, ikke bare det du ba om. Et typisk svar ser slik ut:
{
"requests": {"cpu": "150m", "memory": "128Mi"},
"limits": {"cpu": "300m", "memory": "256Mi"}
}Sjekk også allocatedResources under samme containerStatus, det feltet viser hva kubelet har reservert på noden. Stemmer de to feltene overens, er resizen fullført. CPU-endringer er nesten alltid raske fordi cgroup-kvoten kan justeres direkte uten risiko for OOM, ofte innen få hundre millisekunder på en node uten hardt CPU-press.
Steg 7: Utfør en minne-resize og forstå beste-innsats-beskyttelsen
Minne er tregere og mer risikabelt å endre enn CPU. Frem til GA i 1.35 kunne du ikke senke minnegrensen på en kjørende container i det hele tatt, kun øke den. Fra 1.35 er nedskalering tillatt, men med en «beste innsats»-garanti: kubelet prøver å unngå OOM-kill, men gir ingen garanti. Bruker containeren allerede mer minne enn den nye grensen tillater, blir resizen stående i InProgress til minnebruken faller, i stedet for å drepe containeren umiddelbart.
kubectl patch pod resize-demo --subresource=resize -p \
'{"spec":{"containers":[{"name":"app","resources":{"requests":{"memory":"96Mi"},"limits":{"memory":"192Mi"}}}]}}'
kubectl describe pod resize-demo | grep -A3 "Conditions"Legg merke til at minnenedskalering krever cgroup v2 for å fungere pålitelig. På cgroup v1-noder kan kjernen nekte å senke memory.limit_in_bytes mens containeren har allokert minne over den nye grensen, og resizen blir hengende. Det er den vanligste årsaken til at team rapporterer at “minne-resize ikke virker” selv på en klynge som kjører 1.35 eller nyere.
Steg 8: Overvåk resize-status og conditions
Hver resize-forespørsel går gjennom to mulige pod-conditions du bør overvåke i produksjon, spesielt hvis du automatiserer resizer via en operator eller VPA.
| Condition | Årsak | Hva det betyr |
|---|---|---|
| PodResizePending | Infeasible | Forespurte ressurser overstiger nodens kapasitet, løser seg ikke av seg selv |
| PodResizePending | Deferred | Kan ikke innfris akkurat nå, kubelet prøver igjen senere |
| PodResizeInProgress | – | Kubelet har allokert ressursene og jobber med å ta dem i bruk |
kubectl get pod resize-demo -o jsonpath='{.status.conditions[?(@.type=="PodResizePending")]}'
kubectl get pod resize-demo -o jsonpath='{.status.observedGeneration}'En pod som venter på kapasitet viser gjerne noe slikt i condition-listen:
{
"type": "PodResizePending",
"status": "True",
"reason": "Infeasible",
"message": "Node didn't have enough capacity: cpu, requested: 300m"
}status.observedGeneration forteller deg hvilken versjon av podSpec-en kubelet faktisk har bekreftet. Bygger du automatisering rundt resize, poll dette feltet i stedet for å anta at en resize er ferdig med en gang API-kallet returnerer 200.
Steg 9: Koble sammen med Vertical Pod Autoscaler
Manuell resize er fint for testing, men produksjonsverdien kommer når VPA gjør jobben automatisk. VPA fikk en ny modus, InPlaceOrRecreate, som graduerte til beta sammen med GA-en av selve resize-funksjonen. I denne modusen forsøker VPA først en in-place resize, og faller kun tilbake til den gamle evict-og-gjenskap-metoden hvis resizen ikke er mulig (for eksempel fordi den ville byttet QoS-klasse).
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: resize-demo-vpa
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: resize-demo
updatePolicy:
updateMode: "InPlaceOrRecreate"
resourcePolicy:
containerPolicies:
- containerName: app
minAllowed:
cpu: 100m
memory: 64Mi
maxAllowed:
cpu: 1
memory: 512MiInstaller VPA-komponentene (recommender, updater, admission-controller) fra det offisielle autoscaler-repoet før du bruker denne manifesten. Sett alltid minAllowed og maxAllowed, ellers kan VPA foreslå grenser langt utenfor det noden faktisk har tilgjengelig, noe som trigger PodResizePending med årsak Infeasible i loopen.
VPA-recommenderen bygger anbefalingene sine på et histogram av faktisk CPU- og minneforbruk over tid, ikke bare et øyeblikksbilde. Som standard ser den på de siste åtte dagene og sikter mot en persentil som gir litt slingringsmonn over typisk bruk, men fortsatt lavere enn en manuelt satt buffer. Første gang du slår på VPA på en arbeidslast, gir den ofte konservative anbefalinger fordi histogrammet er tomt. Vent minst et par dager med reell trafikk før du stoler fullt på tallene den foreslår.
Steg 10: Sett opp RBAC for resize-subressursen
Resize er en egen subressurs i RBAC-modellen, adskilt fra vanlig pod-oppdatering. Et team som har update på pods har ikke automatisk lov til å kalle resize. Det gir deg finkornet kontroll: en CI-pipeline kan få lov til å endre image via vanlig update, mens kun en autoscaler-tjenestekonto får lov til å endre ressurser.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-resizer
rules:
- apiGroups: [""]
resources: ["pods/resize"]
verbs: ["patch", "update"]Bind rollen til tjenestekontoen VPA-updateren kjører under, ikke til bredere admin-roller. Mister du oversikten over hvem som har denne tillatelsen, kan uventede resizer dukke opp fra scripts du har glemt du kjørte for tre måneder siden.
Steg 11 og 12: Automatiser i produksjon og feilsøk mislykkede resizer
Når testene på steg 1-10 er grønne, flytt oppsettet til staging med reell trafikk før produksjon. Sett opp varsling på PodResizePending med årsak Infeasible gjennom Prometheus, siden den tilstanden ikke løser seg av seg selv. Et enkelt PromQL-uttrykk som kube_pod_status_reason{reason="Infeasible"} > 0 fanger opp dette hvis du kjører kube-state-metrics i en versjon som eksponerer resize-conditions (kube-state-metrics 2.13+).
Feiler en resize, sjekk i denne rekkefølgen: nodens ledige kapasitet (kubectl describe node), QoS-klassen til poden (kan endringen flytte den til en annen klasse), cgroup-versjonen på noden, og til slutt om containerens runtime faktisk støtter live cgroup-oppdatering. Docker via dockershim er fjernet siden lenge, men eldre containerd-versjoner under 1.6 har fortsatt kjente hull i resize-støtten for minne.
Kjører du GitOps med Argo CD eller Flux, husk at resize-endringer gjort direkte med kubectl patch --subresource=resize ikke går gjennom Git som kilde til sannhet. Det er greit for VPA-drevne, automatiske justeringer, men hvis et menneske manuelt resizer en pod for å slukke en brann, bør endringen følges opp med en tilsvarende oppdatering i Git etterpå. Ellers vil neste synkronisering fra Argo CD eller Flux rulle poden tilbake til de gamle verdiene og potensielt gjenskape problemet.
Vanlige fallgruver
- Å anta QoS-klassen kan endres via resize. Den kan den ikke. Planlegg requests og limits slik at klassen forblir stabil gjennom hele skaleringsintervallet.
- Å glemme cgroup v2-kravet. Minnenedskalering på cgroup v1-noder feiler stille eller blir hengende i InProgress, uten en tydelig feilmelding.
- Å bruke gammel kubectl mot ny server. Uten
--subresource=resize-støtte (kubectl under 1.32) prøver klienten å oppdatere hele pod-specen, som feiler fordi de fleste andre felt fortsatt er immutable. - Å resize init-containere eller ephemeral containers. De støttes ikke, og API-et returnerer en tydelig valideringsfeil hvis du prøver.
- Å sette VPA i InPlaceOrRecreate-modus uten min/max-grenser. Resultatet er ofte forespørsler noden ikke kan innfri, som stables opp som Infeasible-conditions.
- Å ikke teste static CPU manager-policyen. Pods med garantert CPU-pinning via kubeletens static policy hopper over resize-funksjonen helt, uansett hvor riktig manifestet ditt ser ut.
- Å blande HPA og VPA på samme ressurstype. Lar du begge kontrollere justere CPU samtidig, får du en tilbakekoblingssløyfe der replikaantall og pod-størrelse jager hverandre i motsatt retning.
- Å stole blindt på at en resize er ferdig fordi kubectl-kallet returnerte suksess. Et 200-svar betyr bare at forespørselen ble akseptert, ikke at kubelet har fullført allokeringen. Sjekk alltid observedGeneration eller conditions før du bygger videre logikk på resultatet.
Feilsøking: 8 vanlige problemer og løsninger
De fleste feil du støter på handler om versjonsmismatch, QoS-brudd eller cgroup-forskjeller mellom noder i samme klynge, ikke om selve resize-logikken. Tabellen under dekker de vanligste symptomene i den rekkefølgen du bør sjekke dem, fra enklest å bekrefte til mest tidkrevende å diagnostisere.
| Symptom | Sannsynlig årsak | Løsning |
|---|---|---|
| pods/resize finnes ikke i api-resources | Klynge under 1.33, eller gate slått av | Oppgrader til 1.35+ eller aktiver feature-gate manuelt |
| kubectl patch –subresource=resize feiler med “unknown flag” | kubectl-klient under 1.32 | Oppgrader kubectl til minst 1.32, helst matchende serverversjon |
| Resize henger i PodResizeInProgress i minutter | Minnebruk over ny grense, best-effort venter | Reduser minnebruk i appen først, eller bruk RestartContainer-policy |
| Condition Infeasible dukker opp | Node har ikke ledig kapasitet til forespurte requests | Sjekk node-utnyttelse, vurder cluster autoscaler eller mindre steg |
| Resize avvises med QoS-feilmelding | Endringen ville flyttet poden mellom QoS-klasser | Juster requests og limits sammen, ikke bare den ene |
| allocatedResources matcher ikke requests etter resize | Kubelet har ikke fullført allokeringen ennå | Poll observedGeneration til den matcher spec-generasjonen |
| Init-container resize feiler med valideringsfeil | Init-containere og ephemeral containers støttes ikke | Bruk restartable init (sidecar) containere i stedet hvis mulig |
| Ingen effekt på Windows-noder | Funksjonen er kun støttet på Linux | Planlegg Windows-arbeidslaster med tradisjonell rolling update |
Avanserte tips
Kombiner resize med CPU-oppstartsstøtte (AEP-7862) for applikasjoner med tung JIT-kompilering. Be om et høyt CPU-krav de første sekundene, og la en operator senke det automatisk etter oppstart er ferdig. Det gir raskere kaldstart uten å permanent binde opp CPU du ikke trenger i steady state.
Se også fremover mot Kubernetes 1.36, sluppet 22. april 2026, som la til alpha-støtte for in-place resize av PersistentVolumes for AWS EBS, altså volumstørrelse og IOPS uten å måtte gjenskape claim-en. Det er fortsatt alpha og krever egen feature-gate, men peker mot at hele ressursmodellen i Kubernetes beveger seg bort fra “slett og gjenskap” som standardsvar på endring. Kubernetes 1.37, ventet 26. august 2026, bygger videre på dette sporet ifølge den offisielle sneak peek-bloggen.
For klynger som kjører HPA og VPA samtidig, hold dem adskilt per ressurstype. La HPA styre replikaantall basert på CPU-utnyttelse, og la VPA i InPlaceOrRecreate-modus kun justere minnegrenser. Kjører begge på samme ressurstype samtidig, får du oscillering der HPA skalerer ut mens VPA prøver å skalere hver enkelt pod ned, og de to kontrollerne jobber mot hverandre.
På klynger med flere team i samme namespace-struktur, merk VPA-manifestene med eierskap tydelig (label eller annotation med team-navn), og eksporter resize-metrikker per namespace til kostnadsverktøyet dere allerede bruker. Da kan et FinOps-team se hvilke arbeidslaster som faktisk drar nytte av in-place resize og hvilke som fortsatt kjører med statiske, overdimensjonerte grenser fra før funksjonen ble tilgjengelig.
Sikkerhetshensyn ved automatisert resize
Fordi resize er en egen RBAC-subressurs, kan du begrense hvem som får kalle den uten å påvirke andre pod-tillatelser, men det løser ikke alt. En kompromittert tjenestekonto med resize-tilgang kan i teorien be om urimelig store CPU- og minnegrenser på pods den kontrollerer, og på en delt klynge med mange tenanter kan det bety at en enkelt arbeidslast spiser opp kapasitet andre team er avhengige av. Sett derfor alltid ResourceQuota og LimitRange på namespace-nivå som en ekstra sperre, i tillegg til minAllowed/maxAllowed i VPA-manifestet.
For klynger med strengere krav, bruk en admission-policy-motor som Kyverno eller OPA Gatekeeper til å validere resize-forespørsler mot øvre grenser før de når kubelet. Begge støtter validering på subressurs-nivå, slik at du kan avvise en resize som ber om mer enn for eksempel 4 CPU-kjerner på en enkelt container, uavhengig av hva som står i VPA-anbefalingen. Aktiver også API-server audit logging for pods/resize-verbet, slik at uventede eller unormalt hyppige resize-kall er sporbare i etterkant.
Et siste punkt mange overser: resize endrer ikke pod-ens sikkerhetskontekst eller image, kun ressursgrensene. Det betyr at en resize-hendelse alene ikke er en sikkerhetshendelse i seg selv, men et uventet mønster av gjentatte, store resizer på samme pod kan være et tegn på at noe annet i klyngen prøver å eskalere ressursbruk, for eksempel en krypto-mining-prosess som har fått fotfeste inne i en container.
Kostnadseffekten: mindre overprovisionering
Før in-place resize eksisterte, løste de fleste team usikkerhet rundt ressursbehov ved å sette requests høyere enn nødvendig. Grunnen var enkel: en pod som ble evict-et og gjenskapt for ofte skapte ustabilitet, så det var tryggere å overdimensjonere fra start. Det problemet henger direkte sammen med FinOps-arbeidet mange skyteam allerede driver med, der målet er å redusere avstanden mellom det som er reservert (requests) og det som faktisk brukes.
Med in-place resize kan et team sette lavere startrequests og la VPA i InPlaceOrRecreate-modus justere opp underveis når faktisk forbruk viser seg. Risikoen ved å prøve lavere verdier faller kraftig, fordi en feilvurdering ikke lenger betyr en full pod-restart med den nedetiden det kan medføre for stateful arbeidslaster. For klynger som allerede overvåker kostnad per namespace med verktøy som OpenCost eller Kubecost, er dette et konkret sted å angripe overprovisionering uten å øke restart-risikoen.
Kombiner dette med bin-packing-fordelen: en scheduler som vet at pods kan krympes on-demand trenger mindre slakk per node for å håndtere spisser i trafikk. Det gjør det lettere å kjøre klynger tettere pakket uten å øke antall evictions, noe som i praksis betyr færre noder for samme arbeidsmengde over tid.
Komplett eksempelprosjekt
Under følger et komplett, kjørbart oppsett som binder sammen alt fra denne guiden: en Deployment med riktig resizePolicy, en VPA i InPlaceOrRecreate-modus, og RBAC begrenset til autoscaler-kontoen.
Prosjektstruktur
resize-lab/
├── kind-config.yaml
├── deployment.yaml
├── vpa.yaml
├── rbac.yaml
└── deploy.sh# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: resize-demo
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: resize-demo
template:
metadata:
labels:
app: resize-demo
spec:
containers:
- name: app
image: registry.k8s.io/pause:3.9
resizePolicy:
- resourceName: cpu
restartPolicy: NotRequired
- resourceName: memory
restartPolicy: NotRequired
resources:
requests:
cpu: 100m
memory: 96Mi
limits:
cpu: 250m
memory: 192Mi# deploy.sh
#!/usr/bin/env bash
set -euo pipefail
kind create cluster --name resize-lab --config kind-config.yaml
kubectl apply -f rbac.yaml
kubectl apply -f deployment.yaml
kubectl rollout status deployment/resize-demo --timeout=90s
kubectl apply -f vpa.yaml
echo "Klart. Overvåk med: kubectl get pod -l app=resize-demo -w"Kjør chmod +x deploy.sh && ./deploy.sh og du har et fullt fungerende laboratorium på under to minutter. En vellykket kjøring avsluttes typisk med noe i denne stilen:
deployment.apps/resize-demo condition met
verticalpodautoscaler.autoscaling.k8s.io/resize-demo-vpa created
Klart. Overvåk med: kubectl get pod -l app=resize-demo -wrbac.yaml og vpa.yaml i prosjektstrukturen er de samme manifestene som RBAC-rollen fra steg 10 og VPA-en fra steg 9, samlet i egne filer slik at deploy.sh kan referere til dem direkte. kind-config.yaml gjenbruker konfigurasjonen fra steg 3. Rydd opp etterpå med kind delete cluster --name resize-lab slik at du ikke sitter igjen med en glemt lokal klynge som spiser batteri.
Versjonshistorikk: fra alpha til stabil funksjon
| Kubernetes-versjon | Dato | Status for InPlacePodVerticalScaling |
|---|---|---|
| 1.27 | Mai 2023 | Alpha, gate av som standard |
| 1.33 | Mai 2025 | Beta, må ofte fortsatt aktiveres manuelt på egenforvaltede klynger |
| 1.34 | 27. august 2025 | Beta videreført, fokus på Dynamic Resource Allocation GA i samme release |
| 1.35 | 17. desember 2025 | Stabil (GA), gate på som standard, minnenedskalering tillatt |
| 1.36 | 22. april 2026 | Stabil, alpha-forsøk på PV-resize for AWS EBS lagt til samme release |
| 1.37 | Ventet 26. august 2026 | Bygger videre på ressursmodellen ifølge Kubernetes’ egen sneak peek |
Ofte stilte spørsmål
Må jeg oppgradere hele klyngen til 1.35 for å bruke funksjonen?
Nei. Beta-versjonen fra 1.33 fungerer også, men da må feature-gaten som regel aktiveres manuelt, og minnenedskalering var ikke tillatt før GA i 1.35.
Fungerer in-place resize med Docker som container-runtime?
Docker via dockershim støttes ikke lenger i moderne Kubernetes uansett. Bruk containerd 1.6+ eller CRI-O 1.24+, og helst nyere versjoner for pålitelig minne-resize.
Kan jeg resize en pod som styres av en Deployment direkte?
Ja, men du resizer den enkelte poden via resize-subressursen, ikke Deployment-objektet. For automatisk, løpende resize på tvers av replikaer trenger du VPA i InPlaceOrRecreate-modus.
Hva skjer hvis resizen ikke får plass på noden?
Poden får en PodResizePending-condition med årsak Infeasible. Den løser seg ikke av seg selv, du må enten frigjøre kapasitet, flytte poden, eller be om mindre ressurser.
Er funksjonen trygg å bruke på Guaranteed QoS-pods i produksjon?
Ja, men husk at requests og limits må forbli like etter resize. Du kan skalere en Guaranteed-pod opp eller ned, men aldri gjøre den Burstable underveis.
Trenger jeg VPA for å bruke in-place resize?
Nei, kubectl patch med –subresource=resize er nok for manuell eller scriptet bruk. VPA gir deg automatikk basert på faktisk forbruk over tid, men er ikke et krav.
Virker det på administrerte tjenester som EKS, AKS og GKE?
Ja, forutsatt at nodegruppen kjører en Kubernetes-versjon på 1.33 eller nyere. Sjekk alltid leverandørens egen dokumentasjon for hvilken versjon som er standard slått på.
Kan jeg fjerne et ressurskrav helt via resize?
Nei. Du kan endre verdien på requests og limits, men du kan ikke fjerne feltene helt gjennom en resize-operasjon.
Kan jeg overvåke resize-hendelser i Grafana eller Datadog?
Ja, begge plattformene kan hente pod-conditions og containerStatuses via kube-state-metrics eller sine egne Kubernetes-integrasjoner. Bygg et dashbord som teller PodResizePending over tid, så ser du raskt om Infeasible-tilfeller hoper seg opp på bestemte noder.
Påvirker in-place resize horisontal autoskalering (HPA)?
Ikke direkte. HPA styrer antall replikaer basert på metrikker, mens in-place resize endrer størrelsen på hver enkelt pod. De kan kjøre side om side, men bør styre ulike ressurstyper for å unngå at de motvirker hverandre.
Hvor lang tid tar en typisk resize-operasjon?
CPU-resizer er som regel nesten øyeblikkelige fordi kjernen kun trenger å justere en cgroup-kvote. Minne-resizer, spesielt nedskalering, kan ta lengre tid fordi kubelet venter til faktisk bruk faller under den nye grensen før den bekrefter endringen som fullført.
Det korte svaret på om dette er verdt å sette opp nå: ja, spesielt hvis klyngen allerede kjører 1.35 eller nyere, for da er funksjonen allerede slått på og bare venter på at noen tar den i bruk. Start med et lavrisiko-team, mål effekten på antall pod-restarts og ressursbruk over noen uker, og utvid derfra til VPA-drevet automatikk når dere er komfortable med grensetilfellene rundt QoS og cgroup-versjon.
Relatert dekning
- Kubernetes 1.36: EKS-Støtte fra Juni, 26 Måneder Levetid
- Kubernetes Container-sikkerhet: 12 Steg, 45 Min
- OpenCost Setup: 12 Steg, 30% Lavere Skykostnad
- Azure AKS-Sårbarhet: CVSS 9,4, 415 Feil Patchet
- Cloudflare Workers Oppsett: 14 Steg, 45 Min
Se også vår oversikt over skytjenester for flere guider til drift og kostnadsstyring i Kubernetes.
Kilder: Kubernetes-bloggen om GA i 1.35, offisiell dokumentasjon for pod-resize, beta-annonseringen i 1.33, alpha-annonseringen i 1.27, og Kubernetes’ offisielle utgivelsesoversikt.
