Build1 distinct publisher3 min readPublished
A dev.to writeup puts 30-50% savings in a cleanup phase most teams skip. That number is a share of wasted spend, not of the invoice, and the arithmetic matters before you promise finance anything.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
A resource request is a reservation, not a measurement. Set it high to be safe and the scheduler buys node capacity for consumption that never arrives, which is why the writeup names requests as the biggest lever and node count as the wrong place to start [5]. The failure mode carries no signal: nothing pages, and the waste spreads thinly across hundreds of pods instead of parking itself in one line item you can point at [12][4].
The headline number needs care. The 30-50% is a share of wasted spend, not of the invoice [3]. Take the article's own illustration, a bill 40% higher than the workload needs, and the waste is 28.6% of what you actually pay [13]. Clearing 30-50% of that returns between 8.6% and 14.3% of the bill [14]. That is real money on a large cluster and it is nothing like what the headline implies, so the distinction is worth settling before a finance conversation rather than during one.
The prescribed method also carries a clock. You are told not to guess: pull two to four weeks of real usage, or run the Vertical Pod Autoscaler in recommendation-only mode for a couple of weeks, before editing anything [10]. So the largest lever is the slowest one to pull, roughly a month out from the day you start watching [16]. What moves this month is disks and namespaces. Released PersistentVolumes are the cleanest of those: deleting a PVC does not always take the underlying cloud disk with it, depending on reclaimPolicy, and a single jq query separates the volumes with a claim from the ones billing you for nothing [6][7].
The autoscaler floor belongs in the same bucket. Teams tune the maximum node count and leave the minimum at whatever felt safe when the cluster was provisioned, which bills every night and every weekend at that floor [9]. It is one integer in one config, and unlike requests it needs no observation period.
Two things in the source deserve pushback. The sample manifest sets limits at exactly twice requests on both CPU and memory [17][18], which is a convention rather than a finding; the whole argument of the piece is that your own usage data sets those numbers. And the four-figure monthly recovery from released volumes is offered without a named cluster or an audit trail [7], so treat it as an existence proof for looking, not a forecast for your own bill.
The ordering is also off. Labels appear last, after the cleanup, yet the taxonomy of team, application, environment and cost-center enforced at admission by Kyverno or Gatekeeper is what makes rightsizing by team, chargeback and showback possible at all [11]. It is also what lets you demonstrate that Phase 1 worked. And it is where the promise of no new tooling budget [3] gets thin: admission controllers and VPA are free to license, not free to run, and enforcement means somebody's deploy starts failing for a missing label.
Ranked by verification strength, evidence, and original report placement.
Every pod reserves resources whether it uses them or not; most teams set requests far above actual usage 'just to be safe', forcing the scheduler to over-provision nodes for capacity nothing uses. The article calls fixing requests the single biggest lever, not node count.
When a PersistentVolumeClaim is deleted, the underlying cloud disk (EBS, PD) does not always go with it; depending on reclaimPolicy it can sit billing indefinitely with nothing attached.
Namespaces created for two-week experiments keep billing eight months later; the article recommends a label-based sweep listing temporary namespaces older than 14 days, piped into a weekly cleanup job.
Teams tune the cluster autoscaler's maximum node count religiously but rarely the minimum; an overly generous minimum means paying for idle capacity 24/7 through nights, weekends and low-traffic windows, and the floor should be recomputed rather than left at what felt safe at provisioning.
The article says not to guess request values: pull 2-4 weeks of actual usage with kubectl top pods, or better, run the Vertical Pod Autoscaler in recommendation-only mode (updateMode: 'Off') for a couple of weeks before changing anything manually.
The article prescribes a cost allocation taxonomy of team, application, environment and cost-center labels, enforced by an admission policy such as Kyverno or OPA Gatekeeper, because without it Phase 2 work (rightsizing by team, chargeback, showback) cannot proceed.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Mechanisms checkable, every number unsourced
One dev.to post is the entire evidence base. Its mechanical claims — requests reserving unused capacity, reclaimPolicy leaving cloud disks orphaned after PVC deletion, ephemeral namespaces persisting, an untuned autoscaler minimum holding idle nodes, admission-enforced cost labels as a chargeback prerequisite — are specific, internally consistent, and verifiable by any reader against their own cluster, which keeps this above the floor. Everything quantitative is not: the 49%/17% cost-pressure statistics name no survey, the 40%-over-provisioned and 30-50% recovery figures carry no methodology or sample, and the only savings anecdote is an unquantified 'four-figure monthly' recovery with no cluster or invoice behind it. No second publisher, vendor dataset, or benchmark corroborates any of it.
No adoption data in the cluster
The supplied source is a how-to. It reports no release, deployment, benchmark, pricing, or usage disclosure — the tools it names (Vertical Pod Autoscaler, cluster autoscaler, Kyverno, OPA Gatekeeper, Prometheus, Grafana, Kubecost, OpenCost, Karpenter) appear as recommendations with no install counts, customer names, cluster counts, or spend figures. The generic 'most teams skip this' framing is authorial assertion, not an observed adoption signal, so no adoption level can be measured without inventing facts.
Headline percentage overstates invoice impact
Overstated, and measurably so from the article's own figures. '30-50% Savings' in the title is a share of wasted spend; applied to the piece's own claim of a bill 40% above workload need, waste is 28.6% of what is paid and recovery lands at roughly 8.6-14.3% of the invoice — a three-to-four-fold gap between how the number reads and what it delivers to a finance conversation. The premise statistics are unattributed and the single savings proof point is an anecdote. The gap is not larger because the underlying operational advice is real, cheap, low-risk, and specific: the tactics likely do recover money, just not the headline fraction of the bill.
Practitioner post with one commercial outbound link
Mixed but visible in the text. The post steers readers to free tooling first (kubectl, VPA in recommendation mode, Prometheus/Grafana, OpenCost as Kubecost's open-source core) and explicitly says Phase 1 is the phase where tooling spend is not the bottleneck, which cuts against a pure vendor pitch. Against that, it carries a single outbound link to a 'rundown of cloud cost management tools' — the kind of referral or audience-building placement that rewards traffic — and the unattributed headline statistics plus a round '30-50%' number in the title serve engagement. No employer, sponsor, or vendor affiliation is disclosed anywhere in the supplied source, so the incentive is scored as moderate content-marketing pressure rather than a specific commercial stake.
Full text in hand, no corroboration available
Confidence in this assessment, not in the article. The single source is supplied in full, so what it says, prescribes, and omits is directly observable, and the arithmetic corrections (17/49 ≈ 35%; 0.40/1.40 = 28.6%; 8.6-14.3% of the invoice) are deterministic. What limits confidence is the absence of any second publisher, vendor data, or benchmark to test the unattributed statistics and the savings anecdote against, and the total absence of adoption signal, which leaves one of five reality dimensions unmeasured.
build
One alert, two causes, four green dashboards: the day the stack agreed and was wrong1 distinct publisher
build
Your Nodes Are Not Idle, They Are Reserved: The Requests Trap In Karpenter Consolidation1 distinct publisher
build
Five pods green, GPU at 99 percent, queue up 70x: the Kubernetes dashboard is the wrong instrument1 distinct publisher
build
Split the node bill first, fix the Kubernetes labels second1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 26, 2026