Depending on the container runtime in use (containerd, crio), a separate process is managing and running those container processes (so k3s is telling that proce

Depending on the container runtime in use (containerd, crio), a separate process is managing and running those container processes (so k3s is telling that process what to do, but doesn’t “own” the containers). Also, modern container runtimes interface directly with systemd to launch transient units (think systemd services but without on disk config), so restarting a cri-o for example won’t restart those processes. That allows systemd to manage the process and for k3s/kubelet/cri-o to be upgraded / crash and recover. 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.