Show HN: K8s Cleaner – Roomba for Kubernetes

Show HN: K8s Cleaner – Roomba for Kubernetes(sveltos.projectsveltos.io)

68 points by pescerosso 1 year ago | 58 comments

Hello HN community!

I'm excited to share K8s Cleaner, a tool designed to help you clean up your Kubernetes clusters.

As Kubernetes environments grow, they often accumulate unused resources, leading to confusion, waste, and clutter. K8s-cleaner simplifies the process of identifying and removing unnecessary components.

The tool scans your Kubernetes clusters for unused or orphaned resources—including pods, services, ingresses, and secrets—and removes them safely. You can fully customize which resources to scan and delete, maintaining complete control over what stays and what goes.

Getting Started:

Visit https://sveltos.projectsveltos.io/k8sCleaner.html and click the "Getting Started" button to try K8s-cleaner.

Key Features:

- Easy to Use: No complex setup or configuration required—perfect for developers and operators alike - Open Source: Modify the code to better fit your specific needs - Community Driven: We welcome your feedback, feature ideas, and bug reports to help improve K8s-cleaner for everyone

I'm here to answer questions, address feedback, and discuss ideas for future improvements.

Looking forward to your thoughts! And make sure your all you kubernetes clusters are sparkling clean for the holidays. :-)

Simone

zzyzxd 1 year ago |

For resources that are supposed to be cleaned up automatically, fixing your operator/finalizer is a better approach. Using this tool is just kicking the can down the road, which may cause even bigger problem.

If you have resources that need to be regularly created and deleted, I feel a cronjob running `kubectl delete -l <your-label-selector>` should be more than enough, and less risker than installing a 3rd party software with cluster wide list/delete permission.

pcl 1 year ago | |

How should I discover the things that need deletion?

Presumably running some sort of analysis tool in a dry-run mode would help, no?

leetbulb 1 year ago | | |

https://github.com/yonahd/kor

__turbobrew__ 1 year ago | |

I think it can be useful as a discovery tool. How do you know that your operator is leaking resources in the first place? What if one of your cluster operators manually modified or created resources?

devops76 1 year ago | |

Most of the times you don't own the operator/finalizer

And most of the times, when it is a shared cluster, you don't even know what else is being deployed.

devops99 1 year ago |

If you find yourself using something like this, you seriously fucked up as DevOps / cloud admin / whatever.

pescerosso 1 year ago | |

I understand where you’re coming from, and ideally, we strive for well-managed Kubernetes environments. However, as DevOps practitioners, we often face complexities that lead to stale or orphaned resources due to fast deployment cycles, changing application needs or teams. Even the public clouds make lots of money from services that are left running and not used for which some companies make a living helping clean things up.

K8s-cleaner serves as a helpful safety net to automate the identification and cleanup of these resources, reducing manual overhead and minimizing human error. It allows teams to focus on strategic tasks instead of day-to-day resource management.

devops99 1 year ago | | |

> However, as DevOps practitioners, we often face complexities that lead to stale or orphaned resources due to fast deployment cycles

So, as a DevOps practitioner myself, I had enough say within the organizations I worked at, who are now clients, and also my other clients, that anything not in a dev environment goes through our GitOps pipeline. Other than the GitOps pipeline, there is zero write access to anything not dev.

If we stop using a resource, we remove a line or two (usually just one) in a manifest file, the GitOps pipeline takes care of the rest.

Not a single thing is unaccounted for, even if indirectly.

That said, the DevOps-in-name-only clowns far outnumber actual DevOps people, and there is no doubt a large market for your product.

edited: added clarity

benreesman 1 year ago | |

No one likes leaking resources, but it happens to the very best teams.

It seems like a tool that can propose a good guess about where you landed is strictly useful and good?

devops99 1 year ago | | |

> but it happens to the very best teams.

I am very convinced it does not. I think where the apex between our viewpoints lies is what we recognize (or not) as "best" teams.

thephyber 1 year ago | |

Or the person working that role before you did and you are trying to manage the situation as best as possible.

devops99 1 year ago | | |

As a cloud/DevOps consultant, I don't believe in letting management drag on the life support of failed deployments.

We (the team I built out since a couple years ago) carve out a new AWS subaccount / GCP Project or bare-metal K8s or whatever the environment is, instantiate our GitOps pipeline, and services get cut-over in order to get supported.

When I was working in individual contributor roles, I managed to "manage upward" enough that I could establish boundaries on what could be supported or not. Yes this did involve a lot of "soft skills" (something I'm capable of doing even though my posts on this board are rather curt).

"Every DevOps job is a political job" rings true.

Do not support incumbent K8s clusters, as a famous -- more like infamous -- radio host used to say on 97.1 FM in the 90s: dump that bitch.

remram 1 year ago | |

I don't agree, you can see it as just another linting tool. Just like your IDE will warn of unused variables and functions, and offer a quick-fix to remove them. You wouldn't call someone a fucked up programmer for using an IDE.

jrsdav 1 year ago | |

Not all third party Kubernetes controllers are created equal, unfortunately.

And it is also the reality that not every infra team gets final say on what operators we have to deploy to our clusters (yet we're stuck cleaning up the messes they leave behind).

llama052 1 year ago | |

Agreed, this feels like the kubernetes descheduler as a service or something. Wild.

paolop 1 year ago | |

Possible, but if someone needs it and it works well, why not?

cameronh90 1 year ago | |

Or you're budget constrained, and haven't yet been able to allocate resources to things like GitOps.

darkwater 1 year ago |

How does it work in an IaC/CD scenario, with things like Terraform or ArgoCD creating and syncing resources lifecycle inside the cluster? A stale resource, as identified and cleaned by K8s Cleaner, would be recreated in the next sync cycle, right?

mgianluc 1 year ago | |

In that case I would use it in DryRun mode and have it generate a report. Then look at the report and if it makes sense, fix the terraform or ArgoCD configuration.

More on report: https://gianlucam76.github.io/k8s-cleaner/reports/k8s-cleane...

darkwater 1 year ago | | |

Nice, it's something already. But probably as someone else was saying, it would be cool to iterate and improve this.

Because, if you want to have a product to sell out of this (and I guess you do?), your n.1 client will be (IMO) big enterprises, which usually have a lot of cruft in their clusters and go after cost optimizations. But they also usually don't shove manifests in directly, they have at least one solution on top of it that takes care of resources lifecycle. So, IMO, if you want your product to be useful for those kind of customers, this is something that need to be improved.

imcritic 1 year ago | | |

Improve it! Teach it to figure out if the resource is managed by ArgoCD or FluxCD and then suspend reconciliation.

paolop 1 year ago |

I've been using it for a bit now and very happy with it. The stale-persistent-volume-claim detection has been almost a 100% hit in my case; it's a real game-changer for cleaning up disk space.

Kubernetes clutter can quickly become a headache, and having a tool like this to identify and remove unused resources has made my workflow so much smoother.

S0y 1 year ago |

When I saw the headline I was pretty excited, but looking at your examples, I'm really curious about why you decided to make everything work via CRDs? Also having to write code inside those CRD for the cleanup logic seems like a pretty steep learning curve and honestly I'd be pretty scared to end up writing something that would delete my entire cluster.

Any reason why you chose this approach over something like a CLI tool you can run on your cluster?

mgianluc 1 year ago | |

It has a DryRun that generates a report on which resources would be affected. So you can see what resources identifies as unused before asking it to remove those. I would be scared as well otherwise. Agree.

resouer 1 year ago | |

A CRD controller is expected, especially it will allow your clean up logic long running in cluster or periodically. But writing code inside YAML is very weird, at least there are CEL as option here.

mgianluc 1 year ago | |

one more thing. It comes with a huge library of use cases already covered. So you don't necessarily need to write any new instance.

You would need to do that only if you have your own proprietary CRDs or some use case that is not already covered.

siva7 1 year ago |

Don’t let these naysayers here discourage you. I’ve used CCleaner on Windows 20 years ago, so why not finally now on my kube cluster.

empath75 1 year ago |

why isn't this just a cli tool? I don't see any reason it needs to be installed on a cluster. There should at least be an option to scan a cluster from the cli.

sethhochberg 1 year ago | |

Ironically, I'd bet environments most desperately in need of tools like this are some of the ones where there has been lots of "just run this Helm chart/manifest!" admining over the years...

mgianluc 1 year ago | |

Agree ability to run also as a binary would be helpful.

caust1c 1 year ago |

So is this the first instance of a Cloud C-Cleaner then? You could call it CCCleaner!

fyodor0 1 year ago |

Looking at other comments and drawing Windows parallel, I propose kkCleaner

Useful project nevertheless!

mia_villarreal 1 year ago |

Seems like a simple and effective tool!

kiney 1 year ago |

I've been saying for a while that most of the time we didn't replace pets with cattle bit pet servers with pet clusters. The need for a tool like this proves my point

brianecox 1 year ago |

Sounds useful.

cjk 1 year ago |

I feel like the fact that this even needs to exist is a damning indictment of k8s.

mdaniel 1 year ago | |

Oh, good to know that your environment never loses track of any cloud resource. Maybe apply to Netflix, since it seems they're still trying to solve that problem https://www.theregister.com/2024/12/18/netflix_aws_managemen... <https://news.ycombinator.com/item?id=42448541>

cjk 1 year ago | | |

Sure, I’ll grant you that at huge companies it’s probably easy to lose track of who is responsible for what and when resources ought to be cleaned up. But for small/medium-sized companies, using Terraform is sufficient. And while you can also use Terraform to manage resources on k8s, there’s a lot more friction to doing so than using YAML + `kubectl apply`. It’s far too easy to `kubectl apply` and create a bunch of garbage that you forget to clean up.