-
Notifications
You must be signed in to change notification settings - Fork 3.4k
policy: Use no-op ID allocator when policy is disabled #36102
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
Conversation
3d5d86d
to
254afae
Compare
Conditions for policy disabled: - EnablePolicy=never - DisableCiliumEndpointCRD=true - EnableK8sNetworkPolicy=false - EnableCiliumNetworkPolicy=false - EnableCiliumClusterwideNetworkPolicy=false - IdentityAllocationMode=crd **Benefits** The users will be able to improve scalability and performance and reduce resource consumption when network policies are not used. There will be no user facing changes other than better than that. **Transitions** When cilium-agent restarts to pick up the changed config, it will work the following way: - Enabled -> Disabled: No-op allocator is no longer watching for Cilium Identities or allocating global and local identities. The rest is covered by the system, when the mentioned configuration is applied. eBPF maps will be emptied with CEPs, CESs and CIDs, because they are no longer used. - Disabled -> Enabled: It’s just like starting the network policy enforcement system for the first time. Generation of global resources starts with cilium-agents coming up. Signed-off-by: Dorde Lapcevic <dordel@google.com>
/test |
I'm not sure this is entirely true - some Hubble flow visibility features rely on sharing Security Identities to understand the labels for peers. In the long term I think we need to grapple with the design that allows us to both scale and implement observability & network policy features, but for a band-aid in the interim I think that this sort of approach can work to optimize environments without network policies. I don't particularly want to encourage this deployment configuration for general users just because it strays quite far outside of the standard way that Cilium operates and this could cause users to get confused when they try to operate & debug Cilium. However as contributors you're welcome to deploy Cilium in whatever way you want and to maintain/support those configurations that you're actively using. |
You're right. CEP is used by Hubble. I was thinking from a perspective if users would run this configuration, and upgrade, they would not see a difference in Hubble, because they have CRD ID allocation mode, and CEP CRD disabled, so Hubble doesn't benefit from Security Identities when CEP CRD is disabled. I updated the description to cover it. Additionally, as you suggested in the follow up PR (#36167 (comment)) we will not advertise this specific configuration to all the users, but rather those who come with the interest of scaling Cilium for other features, beyond the scale that network policy supports, can learn about it. |
Ref: #33360
Conditions for policy disabled:
Benefits
Users will be able to improve scalability and performance and reduce resource consumption when network policies are not used. Other than that, users that upgrade will see no difference, because when their configuration already includes CRD ID allocation mode and disabled CEP CRD, features that could utilize these CRDs, like Hubble, already didn’t utilize them.
Transitions
When cilium-agent restarts to pick up the changed config, it will work the following way:
Signed-off-by: Dorde Lapcevic <dordel@google.com>