Kubernetes Resource Right-Sizing Advisor with Cost and Risk Reports

The problem with guessed resource requests

In Kubernetes every container declares how much CPU and memory it requests, and the scheduler packs nodes based on those numbers, not on real usage. Requests are usually set once, copied from a template or a guess, and never revisited. Set too high, the cluster looks full while nodes sit mostly idle and the company pays for capacity nobody uses. Set too low, containers get CPU throttled or killed for running out of memory under load.

Startups and small platform teams feel this most. The cloud bill grows, nobody owns the numbers, and changing them feels risky because nobody knows which service will fall over.

What already exists and the gap

• Vertical Pod Autoscaler (VPA) has a recommender that studies historical usage and produces target, lower and upper bound recommendations, and can apply them by evicting pods or updating them in place.
• Goldilocks from Fairwinds creates a VPA in recommendation mode for each workload and shows the suggestions in a dashboard.
• KRR from Robusta is a command line tool that reads Prometheus and recommends CPU at the 95th percentile and memory at the recent maximum plus a buffer.
• OpenCost gives visibility of Kubernetes spend by cluster, namespace and pod.

Each covers one part: recommendations, or cost, or a dashboard. What a small team actually needs in one place is the recommendation, what it saves in money, and an honest statement of risk for each workload, with the reasoning shown. This project builds that and, more importantly, measures whether following the advice is safe.

What you build

• Collector: pulls container metrics from Prometheus (CPU usage, throttled periods, working set memory, OOM events) and writes daily per-workload summaries to PostgreSQL.
• Recommender: computes percentiles over a window, adds headroom, and labels each recommendation with confidence and risk.
• Cost model: converts CPU cores and gigabytes into money from published instance prices for your chosen provider, with the method written down.
• Dashboard: namespaces, workloads, graphs, current against recommended, and a YAML patch the engineer can copy into a pull request.

The technically interesting part

Percentiles, not averages, and different rules for CPU and memory. A workload averaging 200 millicores and peaking at 2 cores will be throttled constantly if you size for the average. CPU is compressible: going over means slowdown. Memory is not: going over means the container is killed. So CPU can be sized to a high percentile with a burst allowance, while memory must cover the observed peak plus headroom. Explaining and defending that policy, and comparing it with what VPA and KRR choose, is the analytical core.

The second part is the risk side. A tool that only cuts requests will eventually cause an outage. Detect workloads with throttling, memory close to the limit, too little history, or rising trends, and refuse to recommend a cut for them. Examiners will ask about this first.

How to evaluate it

• Savings: total requested against recommended CPU and memory, and the projected monthly cost difference, with your pricing method shown.
• Safety experiment: apply recommendations to half the workloads for two weeks under generated load; report throttling, OOM kills and p95 latency against the control half.
• Comparison: run VPA and KRR on the same cluster and explain where your recommendations differ and why.
• Honesty: if a recommendation caused an incident, report it. That is a stronger result than a claim of pure savings.

Suggested plan

1. Weeks 1 to 2: set up a k3s or kind cluster, Prometheus, and six sample workloads with different load shapes.
2. Weeks 3 to 5: collector and storage, first percentile reports.
3. Weeks 6 to 8: recommender, risk rules and cost model.
4. Weeks 9 to 10: dashboard and YAML patch output.
5. Weeks 11 to 14: safety experiment, comparison with VPA and KRR.
6. Week 15: report and demo.

Path to a product

The first user is a startup running a small Kubernetes cluster whose cloud bill worries the founder. Offer a free two-week report in exchange for permission to publish anonymised results. From there, consulting engagements (right-sizing audits) are more realistic than a SaaS in a space with established tools. As open source, the risk-first recommender is a strong portfolio piece for platform and FinOps roles.

Scope warning

Recommendations only. Automatic enforcement is a stretch goal for good reason. Do not support multiple clouds, do not rebuild a metrics pipeline, and do not attempt node pool or instance type recommendations in version one.

Learn what you need on Sefism

• DevOps and cloud roadmap : Kubernetes, monitoring and cost basics in order.
• DevOps and cloud cheat sheet : requests, limits and kubectl commands at a glance.
• OpenIntro Statistics : percentiles and distributions behind the recommender.
• PostgreSQL Documentation : storing and aggregating daily usage summaries.
• AWS Architecture Blog : cost optimisation patterns from real deployments.

Get help with this idea

The hard parts here are getting realistic load onto a student cluster and writing a risk policy you can defend. Tauseef can help you shape the workloads, the evaluation and the scope so you finish with real numbers. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session