For anyone considering this, it's not a good plan to do it this way, if you have any family members relying on these services, you have to kill them all every time you reboot your workstation. It's really not great to mix destop and server like this. (speaking from experiance and I really need to get a separate box setup for this self hosted stuff)
> if you have any family members relying on these services, you have to kill them all every time you reboot your workstation
yikes!
Yeah I can't imagine killing my family members every time I'm shutting down my computer
It's better than having to hear them complain every time plex goes down
And yet sometimes you just need to pull the plug.
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".
(Probably a lot of the services I run don't even really support HA properly in a k8s system with replicas. E.g. taking global exclusive DB locks for the lifetime of their process)
> 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.
> 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.
> 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.
[dead]
[dead]
I run my stuff in a local k8s cluster and you are correct, most stuff runs as replica 1. DBs actually don't because CNPG and mariadb operator make HA setups very easy. That being said, the downtime is still lower than on a traditional server
It's also worth noting you don't need sophisticated hardware to run anything listed in the parent comment. 8GB of RAM and a Celeron would be adequate. More RAM might be nice if you use the NAS a lot.
[dead]