Please don't omit Flannel

[e3b0c442]

Hello!

I just wanted to say -- I found your analysis in previous years to be quite insightful, and I happened upon the post again today while I was doing some research and had considered running the benchmark tool myself (though I don't have the luxury of a local 10Gb network yet).

In the process, I noticed this repo. I'm glad you're updating the benchmarks again, but I noticed there doesn't seem to be a sign of Flannel anywhere in here.

Maybe I'm premature and it's a work in progress, but I just wanted to implore you -- please don't omit Flannel from this round. I know it's not the new hotness, but I think it's an important data point to compare these newer CNIs against a popular, basic, purpose-built and low-resource plugin like Flannel.

Thank you again for the work here, and I look forward to the final product of this repo. 👋

[AlexisDucastel]

Hi !

First of all, thanks or the feedback ! Glad to hear that you are happy about the incoming benchmark 😄

For this benchmark, we choosed to only select CNIs following these requirements :

• Be maintained (At least 1 commit in last 12 months)
• No cloud or hardware specific
• No meta-cni like Multus
• Implement Network Policies
• Have an easy setup (must be k8s or helm commands, no compilation or system tuning)

As you can see in the CNI selection spreadsheet , we did not picked Flannel because of Network policies. But as it is the only one who failed at this step, and may be a good comparison point as baremetal, we may consider adding it for reference only.

Do you agree with that ?

[e3b0c442]

I would agree. As mentioned, I think it's important to consider the basic plugins from a performance perspective; there's something to be said for the UNIX philosophy of doing one thing very well, and I think Flannel indeed would be a great point of comparison -- it's hard to get much more basic while still fulfilling what's expected from a CNI.

I understand where you're coming from with the feature set, and it makes sense, but at the same time the CNI doesn't necessarily need to implement policy itself (in fact, k3s does exactly this -- it uses Flannel for CNI by default and then a basic network policy provider on top built into k3s [ed: I've just discovered it's actually kube-router's netpol library]), so definitely worth considering.

It would also be great to see it as a reference point against Canal in 2024, given Canal is essentially also what I just described (Flannel CNI with Calico network policies).

Thanks again for the great work here, I'm looking forward to it!

[AlexisDucastel]

Here is flannel : c846914 😄