Kubernetes Resource Right-Sizing Advisor
A controller that observes real usage across a cluster and recommends resource requests and limits, quantifying both the waste from over-provisioning and the risk of under-provisioning. Most clusters run on numbers somebody guessed once.
Advanced
Needs a team, real planning, and a supervisor who knows the area.1 semester, 2 to 3 students
5 to ship
3 optional extrasSuggested stack
What you should ship
- Usage collection per workload over time from cluster metrics
- Recommendation engine using usage percentiles rather than averages, with headroom policy explained
- Waste quantification reporting requested against used resources, expressed as cost
- Risk assessment identifying workloads whose limits make throttling or eviction likely
- Evaluation on a cluster running realistic workloads, reporting recommended savings and any resulting incidents
If you have time left
- Automated application of recommendations behind an approval step
- Handling workloads with strong daily or weekly cycles
- Detecting workloads whose usage is trending upward and will outgrow current settings
The problem
Kubernetes resource requests are usually set once from a guess and never revisited. Set too high and the cluster runs at low utilisation while paying for capacity. Set too low and pods are throttled or evicted under load.
What you build
Usage collection, a recommendation engine, waste quantification in monetary terms, and a risk assessment.
Why percentiles rather than averages
A workload averaging two hundred millicores and peaking at two cores will be throttled constantly if you provision for the average. Recommending against a high percentile with a stated headroom policy, and explaining the choice, is the analytical core of the project.
The number that makes it compelling
Cost. Reporting that a cluster requests three times what it uses and that this equates to a specific monthly figure is what turns an interesting tool into one somebody deploys. Compute it from published instance pricing and show your method.
The risk side, which is what makes it responsible
A tool that only reduces requests will eventually cause an outage. Identifying workloads where reduction is dangerous, and refusing to recommend a cut for them, is as important as finding the savings.
How to evaluate it
Run realistic workloads on a real cluster, apply recommendations to a subset, and report both the savings and whether anything degraded. Honest reporting of an incident you caused is a stronger result than a claim of pure savings.
Scope warning
Recommendations, not automatic enforcement. Automatic application is a stretch goal for good reason.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Every session is free; a few slots open each week.
Follow along
New writing, resources and project ideas land here first.