You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because kubelet / containerd don't stop running pods / containers when they get stopped. The kubelet doesn't have any APIs to stop all pods, so k0s reset relies on containerd to stop containers instead. Therefore, containerd must be up.
you only do reset after stop, so wouldn't it be expected that containerd is offline when you run reset?
In fact, k0s reset spawns its own containerd instance just for the purpose of shutting down all containers.
I suppose the containerd process that's being spawned fails to start for some reason, hence k0s cannot connect to it.
where can I find logs or debug information about this?
You can run k0s reset --debug, which will be more verbose on standard out. But I fear that this won't include any containerd logs, as k0s reset sends containerd's output to /dev/null 🙈. (I have some draft PR floating around that'll change that, but for now, no containerd logs for us).
Before creating an issue, make sure you've checked the following:
Platform
Version
v1.31.1+k0s.1
Sysinfo
`k0s sysinfo`
What happened?
Reset never works smoothly for me. So I would say I most likely faced different issues so far, but this one is the more commend one
Why does
reset
need containerd running anyway? you only doreset
afterstop
, so wouldn't it be expected thatcontainerd
is offline when you runreset
?This issue could be related to #4211 and #4434.
Steps to reproduce
k0s stop
k0s reset
However, I'm sure this is not reproducible every time.
I haven't encountered a way to reproduce the issue reliably.
Expected behavior
No errors during reset.
Actual behavior
Errors during reset, sometimes it hangs for a very long time until it finally exits.
Screenshots and logs
Additional context
No response
The text was updated successfully, but these errors were encountered: