In the June 2026 edition: why Netflix says CPU utilization alone tells you nothing, the two misconfigurations behind Spark OOM kills on Kubernetes, and why your GPUs sit 95% idle – plus the launch of Akamas AI Infrastructure Optimization. The Optimal is the Akamas newsletter where DevRel Engineer Graziano Casto breaks down Kubernetes performance, reliability, and cost optimization.
Hello everyone! Graziano here.
If you’re reading this, we are officially wrapping up June 2026 and sliding into the part of summer where the only thing running hotter than the European heatwave is a Kubernetes node nobody remembered to right-size. We’ve been busy optimizing clusters in the lab. Grab a coffee, or something with ice in it, and let’s look at the logs for this month.
The Latest Replica
This month’s three pieces all circle the same uncomfortable truth: the single number you’ve been staring at is probably lying to you.
How Netflix Shapes Our Fleet for Efficiency and Reliability
Netflix engineers make a claim that belongs on every capacity dashboard: utilization on its own tells you almost nothing. They show three services all sitting at 30% CPU, only one of which is actually safe to run hotter, and argue that the real lever is buffer, the amount of extra load a service can absorb before it falls over, weighted by how much that service matters and how fast it can recover. They also dig into matching workloads to instance shapes (the same job can need a very different core count on an AMD box versus an Intel one) and validating the choice with squeeze tests. The takeaway for anyone sizing pods: chasing a utilization target is how you end up either burning money or quietly building a fragile fleet. Size for the demand and the risk, not for a round number on a graph.
Read the full article here.
Two Misconfigurations That Caused Spark OOM Failures on Kubernetes
This is the war story of a Spark pipeline that ran fine on-prem for three years, then started getting OOMKilled daily the moment it landed on Kubernetes. The reflex fixes (more executor memory, more executors) did nothing. The real culprits were two infrastructure settings carried over without thought during the migration: RAM-backed scratch directories (tmpfs) that sent shuffle spill into node memory instead of disk, plus a hard affinity rule that crammed every executor onto a single node. Together they exhausted node RAM and triggered the kernel OOM killer, with the job spinning up as many as fifty executors before dying. The fix was disk-backed volumes, anti-affinity, and right-sized scratch space, after which the same job finished in about an hour with its original four executors, on the same hardware, with zero OOM kills over the following six months. The lesson is one we keep relearning: when something OOMKills, the instinct is to throw memory at it, but the answer is usually in the configuration you stopped reading.
Read the full article here.
Spotlight, from our own desk: Your GPUs Are 95% Idle, and Buying More Won’t Fix It
This one is ours, fair warning, but the opening number is not a sales prop: the first real utilization reports keep showing GPU usage as low as 5%, on hardware where the GPUs alone can be up to 70% of the build-out. We have seen this movie before with CPUs, where one of our customers averaged 5% across roughly 60,000 of them, about 15 million dollars a year of idle compute. Now run those same over-provisioning habits on hardware that costs around 40x more per unit and that you often cannot even buy on demand in Europe. The article makes the case that the 5% is a configuration problem, not a capacity one, and that getting 2x out of the GPUs you already own is not unusual. You do not need more GPUs, you need to find the real bottleneck. What we built to do exactly that is the next section.
Commits From The Lab
Okay, this is the big one. Clear the changelog.
Akamas just launched AI Infrastructure Optimization. Everyone is busy talking about AI models while almost nobody is talking about what it costs to actually run them in production. That is the bill we just pointed the optimizer at.
Here is the move: instead of tuning one layer and hoping, it searches across Kubernetes resources, GPU allocation, the serving infrastructure, and inference runtime parameters all at once, then validates the configurations that hold up under load. The payoff is the eye-wateringly expensive part of GenAI: higher GPU utilization, lower cost per inference, and latency and throughput targets that stay put, with cost, latency, throughput, and reliability set as explicit objectives instead of left to trial and error.
Best part if you already run Akamas: it is the same engine that tunes your JVMs, Kubernetes workloads, and cloud instances today. New frontier, same brain, nothing new to learn.
The Diff
Numbers beat opinions, so here is what optimization looked like in production this month.
Cutting resources without touching reliability.
This operator runs redundant on-prem Kubernetes farms where each cluster is sized to carry full production traffic on its own, so every wasted core gets multiplied across the farm. Continuous tuning across four production clusters reclaimed 285 cores and 78 GiB of memory while reliability went up, not down: throttling cleared on 18 workloads, recurring OOM kills removed on 3 more, and a safe memory buffer secured on 67 that were drifting toward saturation. On a redundant farm, reclaimed capacity is real headroom for new deployments and traffic growth, which pushes the next hardware purchase further out.
Catch Us
Want to meet the Akamas team in person? We’re regularly at conferences and meetups across the Kubernetes and Java ecosystems. See where we’ll be next on our Events page, and follow me on LinkedIn for the talks and sessions I’ll be at.
Keep those CPUs cool and your latencies low.
Stay optimized,
Graziano Casto, DevRel @ Akamas
