Kubernetes FinOps in 2026: scale to zero, resize in place, and know who pays

What changed this year

Scale to zero: where it pays, and where it bites

The Kubernetes post is clear about the mechanics. CPU and memory metrics come from running pods, so once you reach zero there is nothing left to measure. Scaling from zero therefore needs an object or external metric, such as a queue length, that exists independently of the workers¹.

It is just as clear about the trade-off: cold starts. The autoscaler has to see the metric, schedule a pod and start the application. And Services do not buffer requests while no pods are ready, so request-driven HTTP workloads need a separate buffering layer¹.

The savings are largest where each pod reserves expensive capacity, such as dedicated CPUs or GPUs¹. That makes this especially relevant for AI workloads: embedding pipelines and batch inference workers that sit idle between jobs.

Resize in place instead of over-provisioning

Teams over-provision because changing resources used to mean restarting pods. In-place resize weakens that excuse. With pod-level resources, containers without their own limits share a pool, and from v1.36 you can resize that pool on a running pod. The kubelet applies it without a restart where the container's resize policy allows, and reports a pending condition if the node cannot fit the change².

In practice I use this to set requests closer to real usage and resize during known peaks, rather than reserving the peak all day. Treat it as a tool for planned changes first. Automating it well needs good metrics and conservative policies.

Allocation first, optimisation second

None of this sticks without ownership. The FinOps Framework organises the work into inform, optimise and operate phases, and starts with making costs visible and attributable⁵. On Kubernetes that means allocating cluster cost to namespaces, workloads and labels, including the cost of idle capacity.

OpenCost is the open-source option I reach for. It pairs a cost allocation engine with a community specification for Kubernetes cost monitoring, and it is a CNCF incubating project³⁴. Once every team sees its own number each week, optimisation stops being a platform-team crusade.

The playbook

1. Label everything with team, product and environment. Enforce it at admission so unlabelled workloads can't be deployed.
2. Turn on allocation and publish a weekly cost per team, including their share of idle capacity.
3. Find the idle workers. Queue consumers and batch jobs that run around the clock are your first scale-to-zero candidates.
4. Move them to queue-based scaling on an external metric, then let them scale to zero. Measure cold-start impact before and after.
5. Right-size requests using real usage, and use in-place resize for planned peaks instead of permanent headroom.
6. Put GPUs on a short leash. Dedicated GPU pools with scale-to-zero for batch inference, and a clear owner for every GPU node.
7. Track unit cost: cost per transaction, per tenant or per thousand AI requests. A falling unit cost is the only number that proves the work.

What not to cut

Cost work goes wrong when it eats into reliability. I protect three things: headroom for the critical user path, redundancy across zones for anything customer-facing, and the observability needed to see what the changes did. Saving money and causing an outage is not a win.

Unit cost is also a useful lens in due diligence. A company that can tell you its cost per customer and how it falls with scale is usually in control of its platform. I cover more of this in my technical due diligence work.

How I can help

I run short platform and cost reviews that end with an allocation model, a list of safe savings and a plan to keep them. As a fractional CTO I also help teams build the habits that stop the bill creeping back. Or analyse your challenge first and bring the result to a call.