DevRel Engineer @ Akamas · CNCF TAG DevEx Co-Chair · CNCF Ambassador · Kubernetes v1.35 Comms Lead
Ahead of his talk at Codemotion AI & Tech Conference 2026, we sat down with Graziano Casto to talk about one of Kubernetes’ quieter but consequential recent additions — In-Place Pod Resize — and what it actually means for cloud spend, developer experience, and where the platform still falls short. Here’s what he had to say.
Kubernetes
Most developers have heard “just give your pods more resources” as the default answer to slow startup times. What’s the real cost of that advice at scale — and why has it taken this long for Kubernetes to offer something better?
Throwing more CPU or memory at a pod is the easiest lever anyone can pull, and that’s exactly the problem. It works in the moment because more resources usually do shave a few seconds off a cold start, but nobody goes back later and tunes it down once the deadline pressure is gone. Multiply that by every service in a large fleet and you get a cluster running at a fraction of its real utilization, because requests were set for the worst-case startup spike rather than steady-state load. Teams end up paying for headroom they use for maybe thirty seconds at boot and then never touch again, and that shows up directly in the cloud bill and in how many nodes you need just to fit everyone’s inflated requests.
The reason Kubernetes couldn’t offer a cleaner answer for so long comes down to how the resource model was built from day one. Pod resource requests and limits were treated as effectively immutable once the pod started running, so if you wanted different resources for startup versus steady state, your only option was to kill the pod and bring up a new one with new values — which obviously defeats the purpose if what you’re trying to fix is slow startup in the first place. Changing that meant touching the scheduler, the kubelet, the API machinery, and every controller that assumes resources don’t move once a pod is admitted, which is a lot of surface area to get right without breaking existing workloads. That’s why in-place resource resizing took years of design work through the KEP process rather than being a quick patch. It’s only recently gotten stable enough that you can actually resize a running pod without a restart, which finally gives people a real alternative to just padding the numbers and hoping for the best.
Cloud Costs
In-Place Pod Resize sounds like an infrastructure detail, but you mention it could free up thousands of wasted cores across a cluster. Can you put that in terms a developer or engineering manager would feel in their cloud bill?
Think about what actually happens today without in-place resize. A service needs four CPUs for the first twenty seconds while it warms up caches and loads config, then it settles down and uses maybe half a CPU for the rest of its life. Since you can’t change that request without a restart, you set it at four CPUs permanently, because nobody wants a pod that gets OOMKilled or throttled during startup in production. Now multiply that by however many replicas you run and however many services look like this across the fleet, and you’ve got a huge chunk of your cluster capacity reserved for something that’s only true for a few seconds out of the pod’s entire lifetime.
That reserved capacity isn’t free just because it’s idle. The scheduler still has to find room for those four CPUs on some node, so you end up provisioning more nodes than the actual workload needs, and those nodes cost money whether the CPUs are busy or sitting there as a safety margin. With in-place resize, you can request something closer to what the pod actually needs on average, let it burst up temporarily during startup, and then scale it back down automatically once it’s stable, all without a restart. For an engineering manager looking at a cloud bill, that’s the difference between provisioning for peak-forever and provisioning for what you actually use, which on a large fleet can mean cutting node count — and therefore spend — by a meaningful percentage without touching a single line of application code.
Developer Experience
You work on both the Kubernetes release team and developer experience at CNCF. Do features like this one actually change how developers think about writing applications, or does the “right” behaviour still get pushed down to platform teams to figure out?
Honestly, in most organizations this still lands on the platform team, and I don’t think that’s a bad thing right now. In-place resize is a primitive, not a policy, and application developers generally shouldn’t need to know that Kubernetes finally lets you change CPU without a restart any more than they need to know how the scheduler binpacks nodes. What changes is that platform teams now have a lever they didn’t have before, so instead of telling application teams “just bump your requests and don’t worry about it,” they can build an internal system that sets a lower baseline request and lets it flex up automatically when a service is actually starting up or under load. The developer experience improvement isn’t that every engineer suddenly understands resource tuning — it’s that the platform can stop asking them to guess at numbers they were never equipped to guess at accurately anyway.
Where it does start to change developer behavior is at the edges, mostly for teams building their own operators or anyone working close to the workload API, because now there’s a real reason to think about resource profiles as something dynamic rather than a static number you set once and forget. And that’s actually the pattern I care about most from the DevEx side. A feature like this only pays off broadly if the tooling and defaults around it are good enough that most developers never have to think about it at all, and the harder cases get handled by people who actually understand the tradeoffs. So the short answer is that the primitive is what unlocks the smarter platform behavior, but the platform team is still the one that has to build that behavior and expose it as something sane — whether that’s a VPA-style controller, a policy engine, or an internal tool that just does the right thing by default.
Tech Conferences
You contributed directly to Kubernetes v1.35 and now you’re here explaining it on stage. How important are conferences like Codemotion in closing the gap between “the feature shipped” and “developers actually know it exists and how to use it”?
Honestly, that gap is bigger than most people realize, and it’s one of the reasons I care so much about doing this kind of talk. A feature can go through years of KEP design, implementation, testing, graduate to stable, get its release notes written, and still sit there almost invisible to the person who could actually benefit from it, because the release notes are one line in a changelog most developers never read, buried among forty other changes that shipped the same cycle. Being Comms Lead for 1.35 made that really obvious to me. We spend enormous effort making sure a feature is technically correct and well tested, and comparatively little effort making sure someone building a service on Tuesday afternoon actually knows the option exists.
Conferences like Codemotion close that gap in a way that documentation alone just can’t, because you get to show the actual cost in terms people recognize from their own bill or their own on-call rotation, rather than a paragraph in an API reference. Someone can read “KEP-1287, in-place pod vertical scaling, promoted to stable” and feel nothing, but if I show them the same idea framed as “your JVM warm-up is costing you idle cores you’re paying for right now,” that lands differently and sticks. It also works in both directions. I don’t just get to explain the feature, I get to hear from the room whether it actually solves their problem or whether there’s a rough edge nobody flagged during the KEP review, and that feedback goes straight back into the project. So I’d say the real value of a conference talk isn’t distribution in the marketing sense — it’s translation, taking something that shipped correctly and making sure it actually gets used correctly too.
What’s Next
You describe yourself as “trying to make the cloud faster, greener, and significantly less annoying for everyone.” If In-Place Pod Resize is one piece of that puzzle — what’s the piece that’s still frustratingly missing?
What’s still missing, honestly, is that these pieces still get treated as separate problems when they’re really the same problem seen from different angles. HPA and VPA are a good example. HPA decides how many replicas you need, VPA decides how big each one should be, and the two don’t actually coordinate, so you can end up with both firing on the same spike, scaling out and up at once when one of those alone would have been enough. There’s early work starting to bring these together into something closer to a genuinely multidimensional scheduler — one component that reasons about both axes at once instead of two controllers reacting independently to the same signal — and I think that’s going to matter a lot more than either optimization on its own once it actually lands.
The second piece is that even with a smarter scheduler, the platform still has no visibility into what the application runtime is actually doing inside the container. It sees CPU and memory at the cgroup boundary, but it has no idea what the application runtime is doing inside the container, so resource decisions get made on numbers that are technically accurate but don’t explain why the application is behaving the way it is.
And that connects to the third piece: PSI, pressure stall information. As of Kubernetes 1.36 the PSI metrics themselves are stable and exposed by the kubelet, so the data problem is basically solved. What’s still missing is that the schedulers and autoscalers most people actually run — the built-in HPA and VPA — don’t natively reason off that signal yet. Today it’s mostly custom controllers pulling PSI in on their own rather than it being the default input the ecosystem scales on, and until that changes, you’re still making resource decisions based on a partially complete signal.
