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 ` should be more than enough, and less risker than installing a 3rd party software with cluster wi…
How should I discover the things that need deletion? Presumably running some sort of analysis tool in a dry-run mode would help, no?
Show HN: K8s Cleaner – Roomba for Kubernetes
41–50 of 64 posts
Re: Show HN: K8s Cleaner – Roomba for Kubernetes
#42Earlier quoted context omitted.
> 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 no…
> I had enough say within the organizations I worked at, who are now clients This sounds like experience that’s mainly at small/medium sized orgs. At large orgs the devops/cloud people are constantly under pressure to install random stuff from random vendors. That pressure comes from every direction because every department head (infosec/engineering/data science) is trying to spend huge budgets to justify their own s…
> At large orgs the devops/cloud people are constantly
Two of our clients are large (15,000+ employees, and 22,000+ employees) orgs. Their tech execs are happy with our work, specifically our software delivery pipeline with guard rails and where we emphasize a "Heroku-like experience".
One of their projects needed HiTRUST, and we made it happen for them in under four weeks (no we're not geniuses, we stole the smarts of the AWS DoD-compliant architecture & deployment patterns) and the tone of the execs seemed to change pretty significantly after that.
One of these clients laid off more than half their IT staff suddenly this year.
When I was in individual contributor role in a mid-size (just under 3,000 employees), I wrote my thoughts, "internal whitepaper" or whatever being fully candid about the absurd struggles we were having (why does instantiating a VM take over three weeks?), and sent it to the CTO (and also the CEO, but the CTO didn't know about that) and some things changed pretty quickly.
But yeah, things suck in large orgs, that's why large orgs are outsourcing which is in the most-downstream customers' (the American peoples') best interests too -- a win-win-win all around.
Re: Show HN: K8s Cleaner – Roomba for Kubernetes
#43I feel like the fact that this even needs to exist is a damning indictment of k8s.
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 >
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.
Re: Show HN: K8s Cleaner – Roomba for Kubernetes
#44Earlier quoted context omitted.
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…
It's really hard to parse what you are trying to say in the middle of this colorful imagery and quotations, but if you are spinning up a new Kubernetes cluster (and AWS/GCP account) per deployment, it's obvious you don't need this tool.
Specifically, leaving the corporate political dynamics aside, we move the workloads to the deployments that are up to standard and then archive+drop the old ones. Very simple.
Re: Show HN: K8s Cleaner – Roomba for Kubernetes
#45If you find yourself using something like this, you seriously fucked up as DevOps / cloud admin / whatever.
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?
> 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.
Re: Show HN: K8s Cleaner – Roomba for Kubernetes
#46Earlier quoted context omitted.
> 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 no…
A tool that would be useful for organizations that don't have superstar, ultra-competent devops people on the full-time payroll sounds pretty useful in general. There are a lot of companies that just aren't at the scale to justify hiring someone for that kind of role, and even then, it's hard to find really good people who know what they are doing.
> for organizations that don't have superstar, ultra-competent
Just outsource.
Outsource to those who do have DevOps people who know what they're doing -- most companies do this already in one form or another.
Re: Show HN: K8s Cleaner – Roomba for Kubernetes
#47Earlier quoted context omitted.
> I had enough say within the organizations I worked at, who are now clients This sounds like experience that’s mainly at small/medium sized orgs. At large orgs the devops/cloud people are constantly under pressure to install random stuff from random vendors. That pressure comes from every direction because every department head (infosec/engineering/data science) is trying to spend huge budgets to justify their own s…
> At large orgs the devops/cloud people are constantly Two of our clients are large (15,000+ employees, and 22,000+ employees) orgs. Their tech execs are happy with our work, specifically our software delivery pipeline with guard rails and where we emphasize a "Heroku-like experience". One of their projects needed HiTRUST, and we made it happen for them in under four weeks (no we're not geniuses, we stole the smarts…
[deleted]
Re: Show HN: K8s Cleaner – Roomba for Kubernetes
#48Earlier quoted context omitted.
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?
> 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.
If you know how to do serious software without spilling any memory then you should write it up and collect the most significant Turing Award ever.
Hackers would be immediately bifurcated into those who followed that practice and those who are helpless.
Re: Show HN: K8s Cleaner – Roomba for Kubernetes
#49How 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?
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...
Improve it! Teach it to figure out if the resource is managed by ArgoCD or FluxCD and then suspend reconciliation.
Re: Show HN: K8s Cleaner – Roomba for Kubernetes
#50For 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 ` should be more than enough, and less risker than installing a 3rd party software with cluster wi…
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?