Kubernetes Cost Optimization

Break spend down by team, namespace, or cluster, and split it into compute, network, and storage, so each team sees its own bill before anyone asks it to cut. Showback also tells you where to start, because a handful of workloads usually account for most of the waste.

With DevZero: Departments groups workloads by team, namespace, or cluster using label selectors, and shows each group's compute, network, and storage costs in dollars.

Requests are what you pay for, because the scheduler reserves them whether the pod uses them or not. Most teams set requests once, sized for the worst day they can imagine, and never revisit them. Look at actual usage over a lookback window of at least a week and size to a high percentile (p90 to p95) rather than the peak.

With DevZero: Live rightsizing sets requests from observed usage and updates them as it changes.

Usage drifts with every release, traffic change, and new customer. A request that was right in March is wrong by June, so a one-off audit helps for a quarter and then decays.

With DevZero: Rightsizing runs continuously, in Statistical mode for steady workloads or Predictive mode for spiky ones.

Too little CPU makes a pod slow because it gets throttled. Too little memory gets it OOM-killed. Keep a bigger safety margin on memory, and watch for workloads that spike at startup (JVM apps are the usual offenders) so their startup peak doesn't become their permanent request.

With DevZero: The platform watches for OOM kills, pod failures, and memory pressure, and scales back up when it sees them.

The default scheduler spreads pods for availability, so nodes often sit at 30 to 40% utilization while you pay for all of it. Consolidating pods onto fewer nodes and removing the empty ones is usually the biggest single saving after rightsizing. The catch is that moving a pod normally means restarting it.

With DevZero: Bin-packing uses CRIU to snapshot and resume workloads on another node, keeping memory, TCP connections, and session state intact.

A memory-heavy service on compute-optimized nodes wastes money, and so does the reverse. Batch and other interruptible jobs can usually run on spot capacity for a fraction of the on-demand price. Prices differ by region and availability zone too.

With DevZero: Instance selection weighs current pricing, spot availability and interruption history, and your RI and Savings Plan coverage.

Reactive autoscaling waits for load to show up, then adds capacity. For bursty workloads like CI pipelines and LLM inference, that means either overprovisioning to cover the lag or eating the slowdown. If you run HPA and the cluster autoscaler together, tune them as a pair so they don't fight.

With DevZero: Predictive scaling forecasts demand and works alongside HPA, VPA, and Karpenter.

GPUs are the most expensive thing in most clusters and often the least utilized, with typical usage in the 20 to 30% range. Look for GPUs that sit allocated but idle between jobs, and for VRAM reservations far above what the model loads.

With DevZero: GPU optimization tracks utilization per workload and recommends downgrades with projected monthly savings.

Dev, staging, and preview clusters are usually the most overprovisioned and the lowest risk to change. They're a good place to build confidence before touching production. Fi Money cut non-production Kubernetes costs by up to 67%, and OpenObserve cut pre-production spend by 42%.