12 ms·
> You are always gonna have some downtime in a homelab setup I think. Unless you go all in with k8s I think the best you can do is "system reboots at 4AM, hopef
by embedding-shape 8mo ago
> You are always gonna have some downtime in a homelab setup I think. Unless you go all in with k8s I think the best you can do is "system reboots at 4AM, hopefully all the users are asleep".
Huh, why? I have a homelab, I don't have any downtime except when I need to restart services after changing something, or upgrading stuff, but that happens what, once every month in total, maybe once every 6 months or so per service?
I use systemd units + NixOS for 99% of the stuff, not sure why you'd need Kubernetes at all here, only serves to complicate, not make things simple, especially in order to avoid downtime, two very orthogonal things.
- bjackman 8mo ago> I don't have any downtime except when I need to restart services So... you have downtime then. (Also, you should be rebooting regularly to get kernel security fixes). > not sure why you'd need Kubernetes at all here To get HA, which is what we are talking about. > only serves to complicate Yes, high-availability systems are complex. This is why I am saying it's not really feasible for a homelabber, unless we are k8s enthusiasts I think the right approach is to tolerate downtime.
- embedding-shape 8mo ago> So... you have downtime then. 5 seconds of downtime as you change from port N to port N+1 is hardly "downtime" in the traditional sense. > To get HA, which is what we are talking about. Again, not related to Kubernetes at all, you can do it easier with shellscripts, and HA !== orchestration layer.
- flipped 8mo ago[dead]
- flipped 8mo ago[dead]