cri-containerd cannot create a pod if the runtime removes the IP from the veth device

[nlacasse]

Some runtimes create a TAP device linked to the virtual ethernet (veth) device, and then remove the IP address from the veth device. For example, clear containers takes this approach, as documented here.

On each PodSandboxStatus request, cri-containerd runs ocicni.GetPodNetworkStatus, which joins the pod's network namespace and looks for the IP address of the veth device. If this IP has been removed, GetPodNetworkStatus returns an error, and cri-containerd returns a status with an empty Network.Ip field. Kubelet detects this, and stops and re-starts the pod, but the same issue will occur again.

Cri-o does not have this problem, since it only calls GetPodNetworkStatus once (before the IP has been removed from the veth device), and caches the results.

[abhi]

@nlacasse I think what you are asking here makes sense. @Random-Liu WDYT ?

[Random-Liu]

Since IP of a pod is considered to be immutable, I think it's reasonable to cache the IP after create the sandbox. @abhi Thanks for doing that, we should get that in v1.0.0-beta.1.

However, I'm not sure whether runtime should rely on this behavior or not. They are today, but we might want to find a better solution which doesn't make implication on the cri container runtime implementation detail. :)
But that will be a future discussion.

@nlacasse Thanks for looking into this and find the root cause! :D

[Random-Liu]

The fix #525 for v1.0.0-beta.1 has been merged, I'll remove this issue from v1.0.0-beta.1 and keep it open.
We can revisit in the future to figure out how to handle this better.
@nlacasse We are going to cut the beta.1 release next week.
@abhi Thanks for working on this!