-
Notifications
You must be signed in to change notification settings - Fork 748
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multus with VPC-CNI as secondary: failed to add default route: file exists #1649
Comments
Hi @cryptk thanks for reporting, let me try to repro using the steps mentioned and will get back to you. |
I was looking for some official guidance on how the default route should be handled when running a multi-net setup, and the official spec addresses this. https://github.com/k8snetworkplumbingwg/multi-net-spec/tree/master/v1.2 Section 4.1.2.1.9
So it looks like the VPC CNI should not replace the original default route, but rather only create it if it does not already exist. That spec had lots of other good information on how a well-behaved CNI should operate in a multi-net configuration. |
@cgchinmay thanks for picking the issue up so fast! My repro steps are pretty minimal, so if you need any clarification or expansion, please let me know! |
@cryptk - Would be great if you can share your use case that drives the requirement for VPC CNI as secondary plugin . AFAIK, VPC CNI as default delegate CNI was qualified with Multus.
Doc doesn't explicitly call out that VPC CNI as secondary is not supported. Will confirm internally if this was intended to be supported and respond back. |
+1 interested in the use case for using VPC CNI as for secondary interface, regardless of the issue reported. |
Hi @cryptk I was able to repro the issue, like you mentioned. However fixing it will be just 1 part of the problem. The current Multus support expects aws-vpc-cni to be used as the Primary plugin. We will be updating our docs to explicitly call it out. For now I will mark this as a Feature Request instead. It would help to know your use case for using aws-vpc-cni as the secondary plugin. |
@sramabad1 @cgchinmay @jungy-aws sorry for the late response, the GitHub notification seemed to never hit me. The problem I am trying to solve is that when running Cilium as the CNI (to benefit from eBPF as well as all of the other cilium features) and using the Cilium overlay network, the EKS control plane can no longer talk to any of the pods to handle things like validating and mutating webhooks. A resolution for this would be to place those pods on the VPC network via vpc-cni. Ideally this would involve having the pods still be primarily on the Cilium overlay network and just having a second interface on the VPC network which can then be used for the EKS control plane communications. |
+1 for this functionality. We have the same use-case as @cryptk |
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days |
/not stale |
@cryptk did you got any progress on this? I have the same use case |
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days |
Issue closed due to inactivity. |
What happened:
Attempting to use multus with EKS. Primary CNI is Cilium and VPC-CNI as a secondary CNI on a pod. The pod fails to start with errors related to VPC-CNI failing to set the default route because Cilium has already set this route.
Attach logs
Multus Logs:
VPC-CNI plugin Logs:
What you expected to happen:
VPC-CNI should be able to run as the secondary CNI in a Multus configuration, especially with Multus support being advertised as a feature.
How to reproduce it (as minimally and precisely as possible):
Install Cilium, Multus and VPC-CNI. Multus should use the following args:
Add a NetworkAttachmentDefinition with the following spec:
This should result in pods running with Cilium as the default CNI and vpccni being available for additional interfaces.
Add the following annotation to a pod:
k8s.v1.cni.cncf.io/networks: vpccni
Anything else we need to know?:
The problem appears to lie here: https://github.com/aws/amazon-vpc-cni-k8s/blob/v1.9.1/cmd/routed-eni-cni-plugin/driver/driver.go#L147
It appears that the VPC-CNI is not capable of handling the case where the default route already exists. In general, a CNI plugin should handle this case.
Environment:
EKS Version: 1.21
Multus version: v3.8
Cilium Version: 1.10.4
VPC-CNI Version: v1.9.1-eksbuild.1 (installed via EKS Addons)
cat /etc/os-release
): Amazon Linux 2uname -a
): 5.4.141-67.229.amzn2.x86_64The text was updated successfully, but these errors were encountered: