Stop paying for empty space in your clusters
Right-size pod requests, pack nodes tightly with Karpenter, use spot capacity safely and show each team what its workloads cost.
Overview
Kubernetes hides cost behind abstraction. Developers set CPU and memory requests once, often by guessing high, and the scheduler reserves that space whether it is used or not. The cloud bill shows nodes, not the services that forced them to exist.
We measure what your pods actually use, set requests and limits from that data, and change how nodes are chosen so the cluster packs work tightly. Where workloads can tolerate interruption, we move them to spot capacity with the safeguards to make that safe.
Signs you need this
- Node CPU usage stays low even at peak, yet the cluster keeps adding nodes
- Pod requests were copied from a template and never revisited
- You cannot say which team or service drives cluster cost
- Everything runs on on-demand instances, including jobs that could restart
What you get
- Cluster cost allocation
- OpenCost or Kubecost installed and showing cost per namespace, team and workload.
- Request and limit tuning
- New requests and limits for your workloads based on measured usage, applied through your deployment pipeline.
- Node provisioning redesign
- Karpenter or tuned node pools with suitable instance families, consolidation and bin-packing settings.
- Spot capacity strategy
- Spot node pools for interruption-tolerant workloads, with disruption budgets and fallback to on-demand.
- Autoscaling review
- Horizontal and vertical pod autoscaling settings, plus KEDA for event-driven workloads where it fits.
How the work runs
- 1
Measure
1 to 2 weeks
Install cost allocation, collect usage data across a normal business cycle and find the biggest gaps.
- 2
Right-size workloads
2 to 3 weeks
Change requests and limits service by service, starting with the largest, and watch for throttling or memory kills.
- 3
Node and spot changes
2 to 4 weeks
Roll out Karpenter or new node pools, enable consolidation and move suitable workloads to spot.
- 4
Showback and handover
1 week
Publish per-team cost views and add request checks to your pipeline so new services start with sensible values.
Timings depend on the size of your estate. The assessment fixes them before any build starts.
What you can check afterwards
- Each team can open a dashboard showing what its namespaces cost
- Pod requests that match measured usage, stored in your manifests
- Spot workloads that survive node interruptions without failed jobs or user errors
- A pipeline check that warns when a new workload has no requests or very high ones
Tools we work with
- Kubernetes
- Amazon EKS
- Azure AKS
- Google GKE
- Karpenter
- OpenCost
- Kubecost
- KEDA
- Vertical Pod Autoscaler
- Goldilocks
- Prometheus
Questions buyers ask
- Is spot capacity safe for production?
- For stateless services with several replicas and proper disruption budgets, often yes. For databases and single-replica workloads, no, and we keep those on on-demand.
- Will tuning requests cause outages?
- We change one service at a time, watch for CPU throttling and memory kills, and roll back quickly if needed. Changes go through your normal deployment pipeline.
- What access do you need?
- Cluster access in your own accounts to install cost tooling, plus access to your manifests or Helm charts to propose changes as pull requests.
- Do we need to buy Kubecost?
- No. OpenCost is free and covers most needs. We only suggest a paid tool if you need features it lacks.
Talk to us about Kubernetes cost optimisation.
Tell us what you run and where. We reply within one business day with questions or a quote.