Kubernetes-native · Open source
Cut Cluster Cost In Half
Right-size CPU and memory from real usage. Start in Recommend, enable Cruise when you trust it, often ~50% less request overhead, without a tuning spreadsheet.
Why clusters still leak
Cluster autoscalers can pack nodes efficiently, but most waste is still per pod: inflated CPU and memory requests in YAML, and scaling logic that reads those requests—not what the workload actually needed.
- Workloads often share the same manifest pattern and peak-sized requests. When limits cause CPU throttling or an OOM kill, the usual fix is to raise requests "just to be safe." The scheduler and your cost model still treat that headroom as guaranteed capacity—so every pod carries extra reservation you rarely use.
- Those numbers live in YAML and get edited rarely—sometimes only each quarter—while deploys and traffic change every week. The gap is not "people don't care"; it is that manual manifest edits do not keep pace with a live cluster.
- Large requests reserve big slices of each node. You can end up with underused nodes, hot neighbors, and CPU or memory that is hard to schedule. Cluster autoscalers and similar tools key off the same request lines, so scaling often follows the inflated number—not measured usage.
How CruiseKube answers that
Proposed requests from metrics you already have, a clear UI to review them, and optional automation per workload—not a surprise cluster-wide toggle.
- CruiseKube reads CPU and memory metrics from Prometheus (the same time series you likely already scrape) and turns them into suggested CPU and memory requests. The goal is simple: line up requests with how the pod actually behaves, instead of a static template or a one-off spreadsheet.
- Start in Recommend: new values show up as proposals in the UI; nothing changes your manifests until you accept them. When a team is ready, switch only the workloads you trust to Cruise so updates stay scoped—never a blind "resize everything" flip for the whole cluster.
- That usually means less unused reservation (lower request overhead) while policies cap how aggressive each change can be. You shrink waste, but each adjustment stays small enough to reason about for production.
Features
Workload-shaped recommendations, guardrails you can stand behind, and an audit trail when requests move.
Workload-level
Every Deployment gets its own verdict
Savings, mode, and filters are scoped to the workloads you run—not a single cluster KPI nobody owns. Open a service, compare today’s requests to what the data says, and decide what earns the next step.
Guardrails
Recommend-only until you promote it
Start in Recommend: proposals land in the UI, nothing rewrites requests behind your back. When a team is ready, switch that workload to Cruise, automation with intent, not a blind fleet-wide toggle.
Audit trail
Events that answer “what changed—and when?”
Applied recommendations show up as a living log. When finance or SRE asks for receipts, you are not reconstructing history from kubectl and Slack threads.
Disruption windows
Optimize on your quiet hours
Define when it is safe to move numbers—cron-friendly schedules and room for the workloads that cannot shift during peak.
Monitoring
One dashboard for adoption, waste, and “are we winning?”
Roll-up views tie cost signals, resource efficiency, and who is still on Recommend vs Cruise—so platform reviews start with a shared picture.
Install in minutes
Getting started is easy, just one Helm install and you are on your way!
Get Involved
Questions, contributions, and honest bug reports all land in the open.
Cut cluster cost—on your timeline
Install when you are ready, or book a short call if you want help with a first pilot.