[{"data":1,"prerenderedAt":641},["ShallowReactive",2],{"blog-en-k3s-cluster-autoscaler-node-provisioning-lag-pending-pods":3,"blog-related-en-k3s-cluster-autoscaler-node-provisioning-lag-pending-pods":594,"blog-en-k3s-cluster-autoscaler-node-provisioning-lag-pending-pods-alt":581},{"id":4,"title":5,"author":6,"body":7,"date":575,"description":576,"extension":577,"image":578,"locale":579,"meta":580,"navigation":581,"path":582,"seo":583,"stem":584,"tags":585,"__hash__":593},"blog\u002Fblog\u002Fen\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods.md","The 5 Minutes Between a Scale-Out Signal and a Running Pod: Why Cluster Autoscaler Can't Add Nodes Fast Enough","Kubo Team",{"type":8,"value":9,"toc":563},"minimark",[10,15,23,39,58,65,69,75,78,83,90,94,113,117,130,145,149,155,162,237,248,267,271,277,286,293,438,459,466,470,476,479,504,511,518,522,525,547,559],[11,12,14],"h2",{"id":13},"_1-why-pods-sit-pending-for-minutes-even-though-hpa-is-working-correctly","1. Why Pods Sit Pending for Minutes Even Though HPA Is Working Correctly",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods\u002Fsection01.webp",[16,24,25,26,30,31,34,35],{},"Check the HPA metrics and the replica count has indeed gone up. But run ",[27,28,29],"code",{},"kubectl get pods"," and the new Pods are all sitting in ",[27,32,33],{},"Pending",", unmoving for minutes. No errors show up in the deployment logs either. In most cases, ",[36,37,38],"strong",{},"HPA isn't broken — a separate layer, node addition by Cluster Autoscaler, simply hasn't caught up.",[16,40,41,42,49,50,53,54,57],{},"HPA and Cluster Autoscaler both get lumped together under \"autoscaling,\" but they operate at completely different layers. HPA adjusts the number of Pods; Cluster Autoscaler adjusts the number of nodes. According to the ",[43,44,48],"a",{"href":45,"rel":46},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fworkloads\u002Fautoscaling\u002Fhorizontal-pod-autoscale\u002F",[47],"nofollow","official Kubernetes documentation",", the default stabilization window (",[27,51,52],{},"stabilizationWindowSeconds",") for HPA scale-up is ",[36,55,56],{},"0 seconds"," — meaning it's designed to react to metric changes almost instantly.",[16,59,60,61,64],{},"Cluster Autoscaler, on the other hand, first has to detect that existing nodes have no room for new Pods (they become unschedulable), then request a new node from the cloud provider, and wait for that node to boot and join the cluster. This ",[36,62,63],{},"gap between an instantly-reacting HPA and a node addition process that takes minutes"," is what makes Pods appear to hang in mid-air.",[11,66,68],{"id":67},"_2-breaking-down-the-5-minute-delay-into-numbers","2. Breaking Down the 5-Minute Delay Into Numbers",[16,70,71],{},[19,72],{"alt":73,"src":74},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods\u002Fsection02.webp",[16,76,77],{},"\"A few minutes\" isn't specific enough to act on. Break it down, and the delay turns out to be the sum of three sequential stages.",[79,80,82],"h3",{"id":81},"hpas-reaction-time-roughly-1-3-minutes","HPA's reaction time (roughly 1-3 minutes)",[16,84,85,86,89],{},"Because the metrics-server's collection interval overlaps with the HPA controller's sync period, it typically takes 1-3 minutes from an actual load increase until the replica count is updated. Per the behavior field description in the ",[43,87,48],{"href":45,"rel":88},[47],", the default scale-up policy is fairly aggressive: every 15-second period, it adds either \"100% of current replicas\" or \"4 Pods,\" whichever is larger.",[79,91,93],{"id":92},"cluster-autoscalers-reaction-time-under-30-seconds","Cluster Autoscaler's reaction time (under 30 seconds)",[16,95,96,97,102,103,106,107,112],{},"Per the ",[43,98,101],{"href":99,"rel":100},"https:\u002F\u002Fgithub.com\u002Fkubernetes\u002Fautoscaler\u002Fblob\u002Fmaster\u002Fcluster-autoscaler\u002FFAQ.md",[47],"cluster-autoscaler FAQ",", Cluster Autoscaler scans for unschedulable Pods every ",[27,104,105],{},"--scan-interval"," (10 seconds by default). ",[43,108,111],{"href":109,"rel":110},"https:\u002F\u002Fkomodor.com\u002Flearn\u002Fcluster-autoscaler\u002F",[47],"Komodor's explainer"," also notes that the scale-up decision itself is reactively triggered \"once the number of pending\u002Funschedulable pods increases,\" and this detection step usually completes within 30 seconds.",[79,114,116],{"id":115},"node-provisioning-on-the-cloud-side-3-4-minutes-sometimes-more","Node provisioning on the cloud side (3-4 minutes, sometimes more)",[16,118,119,120,125,126,129],{},"This is where most of the time goes. Booting the VM instance, the OS, kubelet, and registering with the cluster — plus cloud-specific factors like the ones described in ",[43,121,124],{"href":122,"rel":123},"https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Ftroubleshooting\u002Fcluster-autoscaler-scale-up",[47],"Google Cloud's official troubleshooting guide"," — typically add up to 3-4 minutes. Add it all up, and ",[36,127,128],{},"roughly 5 minutes total"," is a reasonable rule of thumb from HPA detection to a Pod actually running.",[16,131,132,133,136,137,140,141,144],{},"The ",[43,134,101],{"href":99,"rel":135},[47]," also documents ",[27,138,139],{},"--max-node-provision-time"," (15 minutes by default): if a node isn't registered within that window, it's excluded from the scale-up simulation and a different node group is tried instead. Conversely, ",[27,142,143],{},"--scale-down-delay-after-add"," (roughly 10 minutes by default) is a safety margin that prevents a newly added node from being removed again right away.",[11,146,148],{"id":147},"_3-a-checklist-for-when-there-should-be-room-but-its-not-scaling-up","3. A Checklist for When \"There Should Be Room, But It's Not Scaling Up\"",[16,150,151],{},[19,152],{"alt":153,"src":154},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods\u002Fsection03.webp",[16,156,157,158,161],{},"If nothing changes after five minutes, suspect a configuration problem rather than simple latency. ",[43,159,124],{"href":122,"rel":160},[47]," organizes the typical reasons a GKE scale-up fails into specific error codes.",[163,164,165,181],"table",{},[166,167,168],"thead",{},[169,170,171,175,178],"tr",{},[172,173,174],"th",{},"Error code",[172,176,177],{},"Cause",[172,179,180],{},"Fix",[182,183,184,198,211,224],"tbody",{},[169,185,186,192,195],{},[187,188,189],"td",{},[27,190,191],{},"scale.up.error.out.of.resources",[187,193,194],{},"Insufficient GPU\u002FCPU resources",[187,196,197],{},"Try a different zone or machine type",[169,199,200,205,208],{},[187,201,202],{},[27,203,204],{},"scale.up.error.quota.exceeded",[187,206,207],{},"Compute Engine quota exceeded",[187,209,210],{},"Request a quota increase",[169,212,213,218,221],{},[187,214,215],{},[27,216,217],{},"scale.up.error.ip.space.exhausted",[187,219,220],{},"VPC IP allocation exhausted",[187,222,223],{},"Redesign subnets",[169,225,226,231,234],{},[187,227,228],{},[27,229,230],{},"no.scale.up.mig.failing.predicate",[187,232,233],{},"Node affinity\u002Ftaint\u002Ftoleration mismatch",[187,235,236],{},"Review Pod spec",[16,238,239,240,243,244,247],{},"The same guide notes that Cluster Autoscaler stops scaling up as a safety measure once ",[36,241,242],{},"more than 45% of nodes are unhealthy",". Running ",[27,245,246],{},"kubectl describe configmap cluster-autoscaler-status -n kube-system"," to check the current decision reason is a useful diagnostic step regardless of cloud provider.",[16,249,250,251,256,257,260,261,266],{},"In self-hosted or edge environments like K3s, the \"cloud API quota\" factor doesn't apply — instead, the spare capacity of existing nodes becomes the focus. Per ",[43,252,255],{"href":253,"rel":254},"https:\u002F\u002Fdocs.k3s.io\u002Freference\u002Fresource-profiling",[47],"K3s's official resource profiling documentation",", when a new agent node joins the cluster, the server's (control plane's) CPU usage has been observed to ",[36,258,259],{},"spike roughly 20% above baseline",", and the limiting factor for scaling is described as \"CPU, not RAM.\" If node addition feels slow on-prem or at the edge, it's worth checking the control plane's own CPU headroom, not just conditions on the destination cloud. Whether this kind of diagnosis can be visualized on a dashboard directly affects operational load — ",[43,262,265],{"href":263,"rel":264},"https:\u002F\u002Fkubo.hexabase.io\u002F",[47],"Kubo","'s Captain UI ships with screens for visualizing exactly this kind of node status and scheduling reasoning.",[11,268,270],{"id":269},"_4-skip-the-wait-option-1-preventive-overprovisioning-with-priorityclass","4. Skip the Wait, Option 1 — Preventive Overprovisioning With PriorityClass",[16,272,273],{},[19,274],{"alt":275,"src":276},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods\u002Fsection04.webp",[16,278,279,280,285],{},"Even if node provisioning itself can't be made faster, you can arrange things ahead of time so you don't have to wait. That's the technique described in the ",[43,281,284],{"href":282,"rel":283},"https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fcontainers\u002Feliminate-kubernetes-node-scaling-lag-with-pod-priority-and-over-provisioning\u002F",[47],"official AWS containers blog",".",[16,287,288,289,292],{},"Continuously deploy dummy Pods running nothing but a \"pause\" container, assigned a low-priority ",[27,290,291],{},"PriorityClass",", to reserve spare capacity in the cluster. The moment a real, high-priority workload becomes Pending, the scheduler immediately preempts these dummy Pods and places the real Pod into the freed slot — no waiting on node provisioning, so the perceived delay is close to zero.",[294,295,300],"pre",{"className":296,"code":297,"language":298,"meta":299,"style":299},"language-yaml shiki shiki-themes tokyo-night","# Real workload\nresources:\n  requests:\n    cpu: \"1\"\n    memory: \"500Mi\"\npriorityClassName: high-priority\n---\n# Dummy reserved capacity\nresources:\n  requests:\n    cpu: \"1\"\n    memory: \"500Mi\"\npriorityClassName: low-priority\n","yaml","",[27,301,302,311,322,330,349,364,375,382,388,395,402,415,428],{"__ignoreMap":299},[303,304,307],"span",{"class":305,"line":306},"line",1,[303,308,310],{"class":309},"sbD-w","# Real workload\n",[303,312,314,318],{"class":305,"line":313},2,[303,315,317],{"class":316},"s0U2E","resources",[303,319,321],{"class":320},"sAklC",":\n",[303,323,325,328],{"class":305,"line":324},3,[303,326,327],{"class":316},"  requests",[303,329,321],{"class":320},[303,331,333,336,339,342,346],{"class":305,"line":332},4,[303,334,335],{"class":316},"    cpu",[303,337,338],{"class":320},":",[303,340,341],{"class":320}," \"",[303,343,345],{"class":344},"sPY7s","1",[303,347,348],{"class":320},"\"\n",[303,350,352,355,357,359,362],{"class":305,"line":351},5,[303,353,354],{"class":316},"    memory",[303,356,338],{"class":320},[303,358,341],{"class":320},[303,360,361],{"class":344},"500Mi",[303,363,348],{"class":320},[303,365,367,370,372],{"class":305,"line":366},6,[303,368,369],{"class":316},"priorityClassName",[303,371,338],{"class":320},[303,373,374],{"class":344}," high-priority\n",[303,376,378],{"class":305,"line":377},7,[303,379,381],{"class":380},"sGX4V","---\n",[303,383,385],{"class":305,"line":384},8,[303,386,387],{"class":309},"# Dummy reserved capacity\n",[303,389,391,393],{"class":305,"line":390},9,[303,392,317],{"class":316},[303,394,321],{"class":320},[303,396,398,400],{"class":305,"line":397},10,[303,399,327],{"class":316},[303,401,321],{"class":320},[303,403,405,407,409,411,413],{"class":305,"line":404},11,[303,406,335],{"class":316},[303,408,338],{"class":320},[303,410,341],{"class":320},[303,412,345],{"class":344},[303,414,348],{"class":320},[303,416,418,420,422,424,426],{"class":305,"line":417},12,[303,419,354],{"class":316},[303,421,338],{"class":320},[303,423,341],{"class":320},[303,425,361],{"class":344},[303,427,348],{"class":320},[303,429,431,433,435],{"class":305,"line":430},13,[303,432,369],{"class":316},[303,434,338],{"class":320},[303,436,437],{"class":344}," low-priority\n",[16,439,440,441,444,445,448,449,452,453,458],{},"The same blog post also describes using a ",[27,442,443],{},"cluster-proportional-autoscaler"," to automatically adjust the number of dummy Pods based on cluster size (e.g., ",[27,446,447],{},"coresPerReplica: 8",", ",[27,450,451],{},"nodesPerReplica: 4","). That said, this approach assumes you're always leaving some spare capacity idle, and the resulting cost trade-off can't be ignored. How much spare capacity to carry depends on how often bursts occur and how much delay you can tolerate. As ",[43,454,457],{"href":455,"rel":456},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-09-08-hpa-cluster-autoscaler-burst-traffic\u002Fview",[47],"oneuptime's analysis"," points out, it's worth measuring each stage from demand spike to traffic being served (metric propagation, HPA update, Pod creation, node request, node boot, app readiness) to pinpoint the actual bottleneck before sizing your overprovisioning.",[16,460,461,462,465],{},"Managing this kind of spare capacity and its cost is also an area that tends to become tribal knowledge when handled manually. ",[43,463,265],{"href":263,"rel":464},[47],"'s AI-Driven Deployment can carry out this initial resource design from a natural-language instruction, freeing you from hand-assembling PriorityClass and dummy Pod YAML one piece at a time.",[11,467,469],{"id":468},"_5-skip-the-wait-option-2-moving-from-cluster-autoscaler-to-karpenter","5. Skip the Wait, Option 2 — Moving From Cluster Autoscaler to Karpenter",[16,471,472],{},[19,473],{"alt":474,"src":475},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods\u002Fsection05.webp",[16,477,478],{},"Rather than trading cost for hidden delay through overprovisioning, there's also the option of making node provisioning itself faster. In an AWS environment, that means moving from Cluster Autoscaler to Karpenter.",[16,480,481,482,487,488,491,492,495,496,499,500,503],{},"Per ",[43,483,486],{"href":484,"rel":485},"https:\u002F\u002Fcast.ai\u002Fblog\u002Fkarpenter-vs-cluster-autoscaler\u002F",[47],"CAST AI's 2026 comparison article",", Cluster Autoscaler typically takes ",[36,489,490],{},"3-4 minutes"," because it goes through a node-group abstraction layer (an ASG, for example), whereas Karpenter calls the cloud API directly (on AWS, EC2's ",[27,493,494],{},"RunInstances",") and picks the best-fitting instance type from a broad candidate pool, getting a node Ready in ",[36,497,498],{},"45-60 seconds",". As ",[43,501,111],{"href":109,"rel":502},[47]," also notes, Cluster Autoscaler is architecturally constrained by its 10-second polling interval, while Karpenter's event-driven design sidesteps that constraint entirely.",[16,505,506,507,510],{},"Which one to choose isn't a simple matter of \"better vs. worse\" — it depends on your operating model. ",[36,508,509],{},"If you're already running AWS EKS and burst traffic is frequent enough that the delay translates directly into business impact (SLA violations, degraded user experience), migrating to Karpenter is worth serious consideration. Conversely, if bursts are infrequent and your team already knows Cluster Autoscaler's behavior well, Option 1's overprovisioning is often good enough."," In multi-cloud or on-prem environments running K3s, Karpenter isn't even on the table, so the realistic options are Option 1's design pattern, or improving the boot speed of whatever is actually provisioning nodes (VMware, Proxmox, bare metal).",[16,512,513,514,517],{},"Operating without being conscious of this layer distinction is a quietly draining task for infrastructure engineers. ",[43,515,265],{"href":263,"rel":516},[47],", as a managed Kubernetes built on K3s, is designed so that AI-Driven Deployment can handle this kind of node-provisioning judgment and execution directly — aiming to keep the full feature set of Kubernetes at roughly 58% of EKS's cost, while letting operators stop having to think about this \"waiting time\" at all.",[11,519,521],{"id":520},"_6-summary","6. Summary",[16,523,524],{},"When HPA \"feels slow,\" in most cases it isn't HPA at all — it's a delay in a separate layer, node provisioning by Cluster Autoscaler. Three sequential stages — HPA's reaction time (1-3 minutes), Cluster Autoscaler's scan interval (10 seconds), and cloud-side node boot time (3-4 minutes) — combine into the roughly 5-minute delay you actually experience.",[16,526,527,528,531,532,534,535,538,539,542,543,546],{},"Think about the response in three stages: first ",[36,529,530],{},"diagnose"," by checking flags like ",[27,533,139],{}," and ",[27,536,537],{},"scale.up.error.*"," error codes; then apply ",[36,540,541],{},"preventive overprovisioning"," with PriorityClass; and finally, if needed, make the more fundamental architectural change of ",[36,544,545],{},"migrating to Karpenter"," (in AWS environments). How far you go depends on how much business impact the delay is actually causing.",[16,548,549,550,553,554,285],{},"If you'd rather remove this kind of node-management complexity from your list of operational concerns entirely, a managed K3s service like ",[43,551,265],{"href":263,"rel":552},[47]," is worth a look. If you'd like to talk through node-provisioning design, monitoring, and cost optimization, feel free to reach out via ",[43,555,558],{"href":556,"rel":557},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[47],"Contact Us",[560,561,562],"style",{},"html pre.shiki code .sbD-w, html code.shiki .sbD-w{--shiki-default:#51597D;--shiki-default-font-style:italic}html pre.shiki code .s0U2E, html code.shiki .s0U2E{--shiki-default:#F7768E}html pre.shiki code .sAklC, html code.shiki .sAklC{--shiki-default:#89DDFF}html pre.shiki code .sPY7s, html code.shiki .sPY7s{--shiki-default:#9ECE6A}html pre.shiki code .sGX4V, html code.shiki .sGX4V{--shiki-default:#A9B1D6}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}",{"title":299,"searchDepth":313,"depth":313,"links":564},[565,566,571,572,573,574],{"id":13,"depth":313,"text":14},{"id":67,"depth":313,"text":68,"children":567},[568,569,570],{"id":81,"depth":324,"text":82},{"id":92,"depth":324,"text":93},{"id":115,"depth":324,"text":116},{"id":147,"depth":313,"text":148},{"id":269,"depth":313,"text":270},{"id":468,"depth":313,"text":469},{"id":520,"depth":313,"text":521},"2026-09-27","Your HPA increased replica count, but the Pod is stuck Pending. The real cause is that Cluster Autoscaler needs minutes to add a node. Here's the delay breakdown, a diagnostic checklist, overprovisioning, and how Karpenter compares.","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods\u002Ftitle.webp","en",{},true,"\u002Fblog\u002Fen\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods",{"title":5,"description":576},"blog\u002Fen\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods",[586,587,588,589,590,591,592],"k3s","kubernetes","cluster-autoscaler","karpenter","node-provisioning","hpa","priorityclass","wSaYUL6ny-w2P8hy9iCJo4We8_FFTpso8VXln7INtD8",[595,604,612,619,628,634],{"path":596,"title":597,"description":598,"date":599,"tags":600},"\u002Fblog\u002Fen\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPA Was Scaling on the Sidecar's Share Too. The ContainerResource Blind Spot in Kubernetes","Kubernetes HPA sums resource usage across every container in a Pod, so Istio sidecars and logging agents dilute the scaling decision. Here's how the ContainerResource metric fixes it, in a K3s\u002FKubo context.","2026-10-21",[586,587,591,601,602,603],"containerresource","autoscaling","service-mesh",{"path":605,"title":606,"description":607,"date":608,"tags":609},"\u002Fblog\u002Fen\u002Fk3s-hpa-prometheus-adapter-discovery-interval-stale-metrics","Question Your discoveryInterval: Why K3s HPA Keeps Scaling on Stale Metrics from Prometheus Adapter","K3s HPA won't scale even though CPU usage looks normal. The culprit is a mismatch between Prometheus Adapter's metrics-relist-interval\u002Fmetrics-max-age and the HPA sync-period. Here's the three-layer delay chain and how to diagnose it.","2026-10-12",[586,587,591,610,602,611],"prometheus-adapter","observability",{"path":613,"title":614,"description":615,"date":616,"tags":617},"\u002Fblog\u002Fen\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design","\"Running Both Feels Safer\" Is the Trap. Why Combining HPA and VPA in Kubernetes Can Send Autoscaling Into a Spiral","Enabling both HPA and VPA in Kubernetes can make two well-intentioned automations fight each other, sending autoscaling into an endless spiral. Here's why the conflict happens, and how to combine them safely with updateMode and metric separation.","2026-10-07",[586,587,591,618,602],"vpa",{"path":620,"title":621,"description":622,"date":623,"tags":624},"\u002Fblog\u002Fen\u002Fk3s-keda-hpa-event-driven-autoscaling-decision","CPU Usage Looks Normal, But Requests Are Piling Up. When to Add KEDA to HPA in Kubernetes","KEDA and HPA aren't an either-or choice. When event-driven workloads grow on K3s\u002FKubernetes, here's why HPA alone hits its limits and how to decide when to add KEDA alongside it.","2026-10-03",[586,587,625,591,602,626,627],"keda","event-driven-scaling","scaledobject",{"path":629,"title":630,"description":631,"date":632,"tags":633},"\u002Fblog\u002Fen\u002Fk3s-keda-vs-hpa-event-driven-autoscaling-decision","KEDA vs HPA on K3s: A Decision Framework for Event-Driven Autoscaling","When CPU\u002Fmemory-based HPA on K3s can't keep up with event-driven workloads, should you extend HPA or adopt KEDA, the CNCF-graduated project? Here's a 3-point decision framework, plus what to watch for on K3s.","2026-09-10",[586,587,591,625,602],{"path":635,"title":636,"description":637,"date":638,"tags":639},"\u002Fblog\u002Fen\u002Fk3s-hpa-not-scaling-metrics-unknown-vpa-death-spiral","Your HPA Config Is Correct. So Why Won't Pods Scale? The Real Cause of 'Unknown Metrics' in K3s and the HPA\u002FVPA Death Spiral","You set up an HPA in K3s and Pods still won't scale. The usual culprits are unset resource requests silently disabling metrics, and a self-reinforcing HPA\u002FVPA feedback loop. Here's how to diagnose and fix it.","2026-09-02",[586,587,591,618,602,640],"metrics-server",1792592632705]