Skip to content
Cloud guide

Kubernetes Without the Runaway Bill

Requests and limits, autoscaling, spot capacity and bin-packing — how to run Kubernetes efficiently instead of paying for idle nodes.

Close-up of server hardware and chips powering cloud infrastructure
Radiatus at a glance
  • Since 2021Independent studio
  • 31 servicesAcross 5 practices
  • 13 productsBuilt & run in-house
  • 24/7Managed support
On this page

Kubernetes gives you extraordinary flexibility — and an extraordinary ability to pay for capacity you never use. Clusters are usually billed by the node, while teams think in pods, so waste hides in the gap between what pods request and what they actually use. A handful of disciplined practices keep clusters efficient without sacrificing reliability.

Set requests and limits that reflect reality

Resource requests drive scheduling: the scheduler reserves that much CPU and memory on a node, whether the pod uses it or not. Requests set too high reserve capacity that sits idle, and you pay for more nodes. Requests set too low let the scheduler overpack nodes, which leads to noisy-neighbour contention and, under memory pressure, evictions.

Limits behave differently per resource: a container that hits its CPU limit is throttled, while one that exceeds its memory limit is OOM-killed. A common, sensible starting point is to set memory requests close to real usage with a memory limit, and to be cautious with CPU limits on latency-sensitive services. Base the numbers on observed usage (Prometheus metrics over a couple of weeks), and revisit them — application behaviour changes with every release.

Autoscale at every layer

  • Horizontal Pod Autoscaler (HPA) scales replicas with CPU, memory or custom metrics such as queue depth or requests per second.
  • Vertical Pod Autoscaler (VPA) recommends — or applies — better requests over time. Don't let HPA and VPA both act on CPU or memory for the same workload; running VPA in recommendation mode alongside HPA is a safe way to get sizing data.
  • Cluster Autoscaler or Karpenter adds and removes nodes as pending pods appear and disappear. Karpenter can also choose instance types per workload and consolidate nodes.
  • Event-driven autoscaling (KEDA) lets queue workers and batch jobs scale to zero when there's nothing to do.

Together they ensure you run the smallest footprint that still meets demand. They depend on good requests — autoscalers make decisions based on them.

Use spot capacity for the right workloads

Spot and preemptible capacity is heavily discounted — AWS advertises up to 90% off On-Demand prices for Spot Instances — in exchange for the provider being able to reclaim it at short notice. Stateless services with several replicas, CI runners and batch jobs are ideal candidates. Keep critical stateful services on on-demand or committed capacity, spread spot across several instance types and zones, and use PodDisruptionBudgets and graceful shutdown handling so interruptions are routine rather than incidents.

Bin-pack, don't scatter

Efficient scheduling packs pods tightly onto fewer nodes. Consolidation (Karpenter's consolidation or the Cluster Autoscaler's scale-down) drains and removes underutilised nodes so you're not paying for half-empty machines. Check the things that block consolidation: pods without controllers, restrictive PodDisruptionBudgets, local storage and overly strict anti-affinity rules.

Clean up what nobody owns

Idle namespaces from old feature branches, orphaned persistent volumes, forgotten load balancers created by Service objects, and log or metrics retention set to "forever" all add up. Give preview environments a time-to-live and delete them automatically.

Make cost visible per team

Namespace- and label-level cost allocation (with tools such as OpenCost or Kubecost) shows each team what its workloads actually cost, including the idle share of the nodes they reserve. Visibility changes behaviour faster than any policy — engineers optimise what they can see. Pair it with cloud-level reporting in CloudMonitor so cluster costs line up with the rest of the bill, and read our broader FinOps playbook for commitments and storage tiering.

Kubernetes efficiency isn't a one-off clean-up; it's a set of defaults, autoscalers and dashboards that keep the cluster honest as it grows. Our DevOps & automation and platform engineering teams build these defaults into golden-path templates, and our SRE & observability practice makes sure cost savings never come at the expense of your SLOs.

Written by the Radiatus engineering team. Questions or corrections? Email us.

Want help putting this into practice?

Talk to a senior engineer about your specific situation — no sales script.

Talk to an Engineer