Plugin does not work with containerd runtime about cni-ipvlan-vpc-k8s HOT 6 CLOSED

Thanks for looking into this; we haven't tested with containerd. Somewhat related, I'm working on unforking our custom ipvlan plugin so we can switch back to upstream now that containernetworking/plugins#88 has been merged and shipped with 0.7.0. I'll look into your PR as part of that work -- the ipvlan unfork change should land soon.

from cni-ipvlan-vpc-k8s.

Great thanks
I think the workaround I used in my PR to populate the MAC address of the peered veth is probably an issue in the CNI ip pkg. I will check how it is used in other plugins

from cni-ipvlan-vpc-k8s.

We have been running this patch for a few weeks and it works with both docker and containerd.

However for containerd we found an issue: containerd/containerd#2329

This issue is not a big problem in general but will break the CNI plugin when triggered (which requires manually creating a network namespace, for instance when using cnitool) due to how the ipam plugin identifies used IP addresses (by iterating over /var/run/netns which will contain invalid entries). I wonder if instead of iterating over /var/run/netns we could use the CRI API directly.

from cni-ipvlan-vpc-k8s.

Calling the CRI API to enumerate namespaces is likely the best plan as it will become the most portable state. I'm happy to work on this as a third (and preferred) path for discovery of existing namespaces this week - I haven't had a chance to do any digging into any API conformance issues. Or if you jump on it first, patches accepted :)

from cni-ipvlan-vpc-k8s.

I think all the CRI implementations today are assuming eth0 is the default interface, and none of them makes it configurable:

• dockershim: https://github.com/kubernetes/kubernetes/blob/1929e0d86da29417132e83f3caf90368a49f9c96/pkg/kubelet/dockershim/network/network.go#L20, https://github.com/kubernetes/kubernetes/blob/1929e0d86da29417132e83f3caf90368a49f9c96/pkg/kubelet/dockershim/network/cni/cni_others.go#L71
• containerd: https://github.com/containerd/cri/blob/master/pkg/server/sandbox_run.go#L526
• cri-o: https://github.com/cri-o/ocicni/blob/master/pkg/ocicni/types.go#L9, https://github.com/cri-o/ocicni/blob/9b451e26eb7c694d564991fbf44f77d0afb9b03c/pkg/ocicni/ocicni.go#L352

In addition, the plugin seems to "move" the IP address created for interface eth0 to interface veth0 (https://github.com/lyft/cni-ipvlan-vpc-k8s/blob/master/plugin/unnumbered-ptp/unnumbered-ptp.go#L241) which does not work with containerd because it is explicitly looking for the IP address associated to eth0.

Not quite familiar with this. If this is done after SetupPod, it works for containerd and cri-o, because both of them cache the ip address. But if this happens before, it won't work.

from cni-ipvlan-vpc-k8s.

It turns out the netns issue is actually a bug in iproute (see containerd/containerd#2329 for more details)
We will start testing containerd with the CNI plugin much more seriously very soon (still requires PR #34)

from cni-ipvlan-vpc-k8s.