Not sure what you’re asking about. If Systemd didn’t start it, Systemd doesn’t manage it. Nothing strange about that…? Systemd does not start all the Kubernetes stuff.
k3s could stop everything, but it doesn’t. It’s a design decision.
k3s could stop everything, but it doesn’t. It’s a design decision.
Under crio to stop all containers you can (well, should but YMMV depending on any changes we’ve made recently)
systemctl stop kubepods.slice
Note that doing that a subsequent start shouldn’t bring the containers back unless k3s and crio were both running (the transient units don’t survive restart).
Note: there’s tons of complexity here that has changed over the last five or so years as container runtimes evolve, so if anything I said is wrong now it was right at one point and might actually be a bug.
Kube for instance didn’t use to gracefully shut down containers on node reboot, and over last few years we’ve gradually fixed all of the complexities so that you do get the correct shutdown behavior between systemd (which takes the “power down” input) to the unit (which encodes how long graceful shutdown should take based on the pod termination grace period seconds) to cri-o (which has to set the correct behavior in systemd) to kubelet (which has to stay running to keep updating the API) to the other components on the node (like container networking, which needs to stay up until all pod network pods are done).
systemd makes a lot of that a lot less painful than it would without.
At one point some distributions accidentally configured the sshd or cron unit to do that. People were a bit surprised when restarting sshd or cron killed every single background child process.
See https://www.freedesktop.org/software/systemd/man/systemd.kil...
Not to mention if k3s is just managing containers running under docker or containerd, those processes are not parentless just because k3s stopped.
Chances are the k3s service unit specifies something else (like 'none') - whether or not that is actually wise would probably require some research.
Now k3s of course starts tons of stuff, mostly in containers. Therein lies the problem: By default, Systemd indeed tries to get rid of the entire process tree. It does this using control groups (cgroups). Unfortunately, it is easy for a process to “escape” its control group, at least for root.
Stopping the master process could absolutely be made to also stop everything.
It would be great if k3s did properly integrate with Systemd. It doesn’t, but Systemd is not to blame for that. That’s my point.