-
Notifications
You must be signed in to change notification settings - Fork 260
Skip removing vnet namespace in Linux CNI Multitenancy #1841
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
Changes from all commits
54c93a8
6d5f56e
faf0100
49a5553
775f3e2
dc35667
3d7fd68
b6cebe7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -513,15 +513,18 @@ func (client *TransparentVlanEndpointClient) DeleteEndpointsImpl(ep *endpoint, g | |
|
|
||
| log.Printf("[transparent vlan] There are %d routes remaining after deletion", routesLeft) | ||
|
|
||
| if routesLeft <= numDefaultRoutes { | ||
| // Deletes default arp, default routes, vlan veth; there are two default routes | ||
| // so when we have <= numDefaultRoutes routes left, no containers use this namespace | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We are skipping deletion of vnet namespace if there are no containers but when there are new containers for that namespace, we won't need to create that namespace again ? Is that correct ? Wanted to know if there is a scenario in which the namespaces are getting accumulated since they were not deleted.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. good question. cni creates netns per vlanid and at max vlanid can range from 1-4096 and also we dont support more than 150 containers in multitenancy. so not deleting netns should not cause any issue vmss000000:/# cat /proc/sys/user/max_net_namespaces |
||
| log.Printf("[transparent vlan] Deleting namespace %s as no containers occupy it", client.vnetNSName) | ||
| delErr := client.netnsClient.DeleteNamed(client.vnetNSName) | ||
| if delErr != nil { | ||
| return errors.Wrap(delErr, "failed to delete namespace") | ||
| // TODO: revist if this require in future. | ||
| //nolint gocritic | ||
| /* if routesLeft <= numDefaultRoutes { | ||
| // Deletes default arp, default routes, vlan veth; there are two default routes | ||
| // so when we have <= numDefaultRoutes routes left, no containers use this namespace | ||
| log.Printf("[transparent vlan] Deleting namespace %s as no containers occupy it", client.vnetNSName) | ||
| delErr := client.netnsClient.DeleteNamed(client.vnetNSName) | ||
| if delErr != nil { | ||
| return errors.Wrap(delErr, "failed to delete namespace") | ||
| } | ||
| } | ||
| } | ||
| */ | ||
| return nil | ||
| } | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious, will commenting this out won't affect the unit test cases we run for it ? https://github.com/Azure/azure-container-networking/blob/master/network/transparent_vlan_endpointclient_linux_test.go#L467
If so, do we need to update the unit test cases as well ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
correct updated it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But this does limit the user's ability to go beyond 23k( approximately) even if the vlan is not at max i.e 4k
I understand that this is safe as we don't have the requirement or a user that has that many namespace, but why are we doing it? Isn't it is safer to delete and make sure it is created when needed, instead of letting it be there.
OR Does this help in reducing the latency since we don't need to create a namespace again ?
(Do correct me if I am understanding it wrong)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so this will be a problem when we parallelize the execution of cni in future.. one doing add and other doing delete in same namespace based on number of default routes