This message was deleted.

That shouldn't happen. You should be able to restart kubelet/containerd/k3s without affecting the pods. I would probably investigate what specifically is causing it to go into an error state.

So the pod's process will continue running even after k3s/containerd dies or is stopped?

Correct. That's why we bundle a killall script with k3s.

interesting peak behind the covers! Good info.

that is how things should work on all distros

right but restarting k3s server process restarts the kubelet which makes device plugins re-register their devices, thus pods using those "old devices", get rediscovered/created, my question is quite specific to device plugins, and given k3s is often times run single-node, curious if others have seen this

why do the device plugins re-register whenever the kubelet starts? there’s no way for the devices to persist across kubelet runs?

it's supposed to, i believe it's due to this bug https://github.com/kubernetes/kubernetes/pull/118635

its all on GH…

what i mean is, can a non suse employee build a local release, the docs I see appear to be for internal use

you can’t kick one off on our infrastructure, no. But you can fork/clone the repos and build your own locally.

okay, do you have a doc you can point me to that would allow me to more or less take (https://github.com/kubernetes/kubernetes/pull/119432) and build a binary locally that I can then put somewhere to test. That would give this week a beautiful ending 🙂

you would need to clone and build https://github.com/rancher/image-build-kubernetes from a fork of kubernetes that has that commit applied