Plugins: add multicast to loopback

[new-mikha]

There are scenarios when multicast is needed on lo, for example in testing. The change adds it to the main loopback plugin.

This change works perfectly well in our environment - a workable multicast pops up on the loopback interface once the loopback plugin is replaced with the one from the change.

Not sure yet how to write an automated test for it though, so the change is lacking the test so far. But could you please have a look at it first, and let me know if the change is good on its own - if it is, then I guess test(s) can be sorted.

Here is my initial question from which I came to this PR: https://serverfault.com/questions/1114351/is-there-a-way-to-add-multicast-to-loopback-interface-on-a-kubernetes-pod

Thanks!

[dcbw]

@new-mikha I don't see any problem with enabling multicast on the loopback interface, but we cannot unconditionally add a multicast route since other CNI plugins may want to "own" that route too. It has to be under the control of the person configuring the CNI networks.

Last point, popular Kubernetes runtimes like CRIO and containerd don't actually use the loopback plugin either, they hardcode loopback logic so they don't have to spend a bunch of time running the loopback plugin :( So even if we make the change here, it won't necessarily be used by those projects.

In any case, my suggestion would be to:

1. enable multicast on the loopback interface unconditionally
2. make the loopback plugin take an 'ipam' arg that has a Routes array, and let the admin specify the loopback routes, or create a config boolean for loopback that specifically enables setting the multicast route
3. Could the "tuning" plugin be used to do this if it's chained after loopback?

[new-mikha]

@dcbw , thanks a lot for looking at it!

It has to be under the control of the person configuring the CNI networks.

Got it, thanks. It makes sense, I will try to update the PR wrt that.

popular Kubernetes runtimes like CRIO and containerd don't actually use the loopback plugin either

Seems that containerd does. I use containerd v1.6.8, and with the loopback plugin modified as per the PR, there is MC on the lo interface (and no MC with the original loopback plugin). Your note though makes me worried - I wonder what are the chances that with the next containerd version it will stop using it...

1. enable multicast on the loopback interface unconditionally

I guess you mean do not enable it unconditionally?

2. make the loopback plugin take an 'ipam' arg that has a Routes array, and let the admin specify the loopback routes, or create a config boolean for loopback that specifically enables setting the multicast route

Yup, understood.

3. Could the "tuning" plugin be used to do this if it's chained after loopback?

I don't know. I have some (very little actually) idea about chained CNI plugins, but tbh I'm not sure how to make or even use one. On the other hand, MC functionality for loopback is such a basic feature, so from the ops point of view having it right within the original loopback plugin (albeit configurable as you suggested above) still looks correct to me.

[github-actions[bot]]

This PR has been untouched for too long without an update. It will be closed in 7 days.