Re:Replacing a $3000/mo Heroku bill with a $55/mo server
by liqilin1567 on Wednesday October 22, 2025 @12:07AM
(#45664799)
Thanks for sharing I think these are very useful suggestions.
Re:Replacing a $3000/mo Heroku bill with a $55/mo server
by benterix on Wednesday October 22, 2025 @03:49AM
(#45666014)
The lengths people will go to avoid k8s... (very easy on Hetzner Cloud BTW).
Re:Replacing a $3000/mo Heroku bill with a $55/mo server
by Bender on Wednesday October 22, 2025 @06:37AM
(#45667154)
That's a more complex path I avoided discussing when I referenced CGroups. When I started doing these things kube clusters did not exist. These tips were for people using bare metal that have not decided as a company to go the k3/k8 route. Some of these settings will still apply to k8 physical nodes. The good people of Hetzner would be managing these settings on their bare metal that Kubernetes is running on and would not likely want their k8 nodes getting all broken, sticky and confused after a K8 daemon update results in memory leakage, billions of orphaned processes, etc...
Companies that use k3/k8's they may still have bare metal nodes that are dedicated to a role such as databases, ceph storage nodes, DMZ SFTP servers, PCI hosts that were deemed out of scope for kube clusters and of course any "kittens" such as Linux nodes turned into proprietary appliances after installing some proprietary application that will blow chunks if shimmed into k8's or any other type of abstraction layer.
Re:Replacing a $3000/mo Heroku bill with a $55/mo server
by carlhjerpe on Wednesday October 22, 2025 @09:44AM
(#45669059)
Every ClusterAPI infrastructure provider is similarly easy? Or what makes Hetzner Kubernetes extra easy?
Re:Replacing a $3000/mo Heroku bill with a $55/mo server
by benterix on Wednesday October 22, 2025 @10:47AM
(#45669941)
I mentioned Hetnzer only because the original article mentions it. To be fair, currently it is harder to use than any managed k8s offering because you need to deploy your control plane yourself (but fortunately there are several project that make it as easy as it can be, and this is what I was referring to).
Another option is to limit memory per application in cgroups but that requires more explaining than I am putting in an HN comment.
Another useful thing is to never OOM kill in the first place on servers that are only doing things in memory and need not commit anything to disk. So don't do this on a disked database. This is for ephemeral nodes that should self heal. Wait 60 seconds so drac/ilo can capture crash message and then earth shattering kaboom...
For a funny side note, those options can also be used as a holy hand grenade to intentionally unsafely reboot NFS diskless farms when failing over to entirely different NFS server clusters. setting panic to 15 mins, triggering OOM panic by setting min_free to 16TB at the command line via Ansible not in sysctl.conf, swapping clusters, arp storm and reconverge.