cri-containerd doesnt successfully reboot kubelet about kubernetes HOT 6 OPEN

ctr t delete kubelet && ctr t start kubelet starts successfully. The risk that kubelet starts before var/run/cri-containerd.sock is there seems much higher without kubeadm after first boot.

from kubernetes.

Does this still happen with Kube 1.9 (just merged via #33)? I think I saw some improvements in this area.

If not then please open an issue against kubernetes or cri-containerd (whichever seems more appropriate, and assuming there isn't already one) since they should be more robust at startup time. My guy feeling is that it is kubernetes which should be more robust to waiting for CRI than vice versa, so a kube issue would seem the way to go.

from kubernetes.

I just built and booted current master (d39e6ba), booted and ran kubeadm-init.sh waited for the pods to all come up then powered off with poweroff. I then booted again with the same persistent disk and again waited for the pods (they did).

I repeated the poweroff, boot and check 5 times and was successful each time (compared with your previous <10% success rate). I also did one iteration with poweroff -f and one with reboot for good measure, still no failures.

So either this is fixed in 1.9.0 or the odds of hitting the problem have changed dramatically, or perhaps something is different in your environment (perhaps just timings).

from kubernetes.

I tried restarting the master 3 times with no problems but could reproduce it after setting up some nodes and pods :/. From what I know Systemd usually handles Socket Activation.

from kubernetes.

LinuxKit doesn't use systemd.

As said in #26 (comment) I think this is an upstream issue.

from kubernetes.

Sure, but the upstream implementations use systemd which does socket activation. I will check if i can solve it with manually waiting until the socket is there.

from kubernetes.