I've developed a bash script that identifies resource waste in Kubernetes clusters without the need for installing additional agents, as that often leads to long security review processes. While consulting for Series B startups, I've observed significant over-provisioning – for instance, applications requesting 8GB of RAM while only using 500MB. Traditional tools that audit these issues require agents inside the cluster, which security teams typically reject due to concerns over security risks and approval delays. My solution runs on your local machine using the existing `kubectl` context, anonymizing pod names with SHA256 hashes to protect sensitive information while also comparing resource requests against actual usage metrics from `kubectl top`. I want feedback on two things: Is my anonymization method secure enough for production environments? What other cost-related issues, like orphaned PVCs, should I consider? I'm eager to hear any constructive criticism of my script!
4 Answers
This script sounds really handy for avoiding security issues! For the orphaned PVCs, consider adding a check for unbound persistent volume claims. It might also help you pinpoint more wasteful patterns.
Honestly, I love the idea, but it feels a bit vibe-coded with all the emojis running around. Still, does it really matter how it's done if it provides the results you need?
Haha, I get what you mean! The emojis were just for formatting, but I assure you the underlying functionality is strictly business.
Isn't using a Vertical Pod Autoscaler (VPA) a more automatic solution to overprovisioning? It can resize pods without manual intervention.
In theory, yes, but many teams hesitate to use the auto mode because it tends to restart pods for resizing. Your script could serve as a preliminary step to highlight waste and gain support for implementing a VPA.
Your approach sounds interesting, but be cautious. The way you're anonymizing the data might not be as secure as you think. For example, the raw JSON files still contain sensitive information before anonymization. Make sure to eliminate those from your outputs. Additionally, while you've anonymized pod names, environment variable values might still be exposed—it's a step in the right direction, but ensure you're not leaving loopholes.
Thanks for the feedback! I've released a hotfix that removes all raw files and sensitive environment variables before packaging. The new version should be much safer!
Good tip! The script currently checks persistent volumes, but I'll refine it to specifically flag any that are unbound. Any other common storage waste issues you've encountered?