Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: K8s Cleaner – Roomba for Kubernetes

sveltos.projectsveltos.io

Post reply on HN
Print view View original

21–30 of 64 posts

Re: Show HN: K8s Cleaner – Roomba for Kubernetes

#21

Post by nine_k »

devops99 wrote: post #18
pescerosso wrote: post #12

Earlier quoted context omitted.

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 th…

> 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…

How do you realize that you have stopped using a resource? Can there be cases when you're hesitant to remove a resource just yet, because you want a possible rollback to be fast, and then it lingers, forgotten?

Re: Show HN: K8s Cleaner – Roomba for Kubernetes

#22

Post by devops99 »

thephyber wrote: post #13
devops99 wrote: post #3

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

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

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.

Re: Show HN: K8s Cleaner – Roomba for Kubernetes

#23

Post by zzyzxd »

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 wide list/delete permission.

Re: Show HN: K8s Cleaner – Roomba for Kubernetes

#24

Post by pcl »

zzyzxd wrote: post #23

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?

Re: Show HN: K8s Cleaner – Roomba for Kubernetes

#25

Post by devops99 »

nine_k wrote: post #21
devops99 wrote: post #18

Earlier 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…

How do you realize that you have stopped using a resource? Can there be cases when you're hesitant to remove a resource just yet, because you want a possible rollback to be fast, and then it lingers, forgotten?

With our GitOps patterns, anything you could call an "environment" has a Git branch that reflects "intended state".

So a K8s namespace named test02, another named test-featurebranch, and another named staging-featurebranch, all have their own Git branch with whatever Helm, OpenTOFU, etc.

With this pattern, and other patterns, we have a principle "if it's in the Git branch, we intend for it to there, if it's not in the Git branch it can't be there".

We use Helm to apply and remove things -- and we loved version 3 when it came out -- so there's not really any way for anything to linger.

Re: Show HN: K8s Cleaner – Roomba for Kubernetes

#26

Post by benreesman »

devops99 wrote: post #3

If 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?

Re: Show HN: K8s Cleaner – Roomba for Kubernetes

#29

Post by photonthug »

devops99 wrote: post #18
pescerosso wrote: post #12

Earlier quoted context omitted.

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 th…

> 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 salary/headcount and maintain job security, because it’s harder to fire someone if you’re in the middle of a migrate-to-vendor process they championed, and you’re locked into the vendor contract, etc etc. People also will seek to undermine every reasonable standard about isolation and break down the walls you design between environments so that even QA or QC type vendors want their claws in prod. Best practice or not, You can’t really say no to all of it all the time or it’s perceived as obstructionist.

Thus there’s constant churn of junk you don’t want and don’t need that’s “supposed to be available” everywhere and the list is always changing. Of course in the limit there is crusty unused junk and we barely know what’s running anywhere in clouds or clusters. Regardless of the state of the art with Devops, most orgs are going to have clutter because those orgs are operating in a changing world and without a decisive or even consistent vision of what they want/need.

Re: Show HN: K8s Cleaner – Roomba for Kubernetes

#30

Post by eigenvalue »

devops99 wrote: post #18
pescerosso wrote: post #12

Earlier quoted context omitted.

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 th…

> 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.
Post reply on HN