Show HN: K8s Cleaner – Roomba for Kubernetes • Hacker News Board

Re: Show HN: K8s Cleaner – Roomba for Kubernetes

#61

Post by devops99 » Fri, Dec 20, 2024, 2:53 PM UTC

remram wrote: post #59

devops99 wrote: post #44

Earlier quoted context omitted.

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.

A more cynical man than I would say that if you need to recreate all your workloads on a new cluster to bring them up to standard, "you seriously fucked up as DevOps / cloud admin / whatever"

Heh, they aren't ""our"" workloads, before we get there, and not until they get deployed correctly for the first time ever at which point then and only then are they ""our"" workloads.

Re: Show HN: K8s Cleaner – Roomba for Kubernetes

#62

Post by benreesman » Sun, Dec 22, 2024, 5:46 AM UTC

devops99 wrote: post #58

benreesman wrote: post #48

Earlier quoted context omitted.

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.

> If you know how to do serious software without spilling any memory This thread is about K8s Pods (and other K8s resources) that have been sitting idle, not memory leaks in software. As far as "spilling" memory, the problem has already been solved by Rust which does not do garbage collection because it has static memory mapping. Does this mean egregious amounts of memory won't be used by some Rust programs? No. But…

I can assure you that memory leaks specifically and resource leaks generally are possible in any language more expressive than a stack machine with an arena.

Rust makes an interesting and demonstrably pragmatic set of tradeoffs here as opposed to e.g. C/C++: treating std::move as a default (aka linear typing) prevents a lot of leaks. But it still has pointers (Arc, etc.) and it still has tables: it’s still easy to leak in a long-lived process doing interesting things. For a lot of use cases it’s the better default and it’s popular as a result.

But neither Rust nor k8s have solved computer science.

Re: Show HN: K8s Cleaner – Roomba for Kubernetes

#63

Post by devops99 » Thu, Dec 26, 2024, 5:59 PM UTC

benreesman wrote: post #62

devops99 wrote: post #58

Earlier quoted context omitted.

> If you know how to do serious software without spilling any memory This thread is about K8s Pods (and other K8s resources) that have been sitting idle, not memory leaks in software. As far as "spilling" memory, the problem has already been solved by Rust which does not do garbage collection because it has static memory mapping. Does this mean egregious amounts of memory won't be used by some Rust programs? No. But…

I can assure you that memory leaks specifically and resource leaks generally are possible in any language more expressive than a stack machine with an arena. Rust makes an interesting and demonstrably pragmatic set of tradeoffs here as opposed to e.g. C/C++: treating std::move as a default (aka linear typing) prevents a lot of leaks. But it still has pointers (Arc, etc.) and it still has tables: it’s still easy to le…

Heh, yeah. No, no they have not.

Re: Show HN: K8s Cleaner – Roomba for Kubernetes

#64

Post by pescerosso » Thu, Dec 26, 2024, 6:56 PM UTC

benreesman wrote: post #62

devops99 wrote: post #58

Earlier quoted context omitted.

> If you know how to do serious software without spilling any memory This thread is about K8s Pods (and other K8s resources) that have been sitting idle, not memory leaks in software. As far as "spilling" memory, the problem has already been solved by Rust which does not do garbage collection because it has static memory mapping. Does this mean egregious amounts of memory won't be used by some Rust programs? No. But…

I can assure you that memory leaks specifically and resource leaks generally are possible in any language more expressive than a stack machine with an arena. Rust makes an interesting and demonstrably pragmatic set of tradeoffs here as opposed to e.g. C/C++: treating std::move as a default (aka linear typing) prevents a lot of leaks. But it still has pointers (Arc, etc.) and it still has tables: it’s still easy to le…

:-)