You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
a mode where NFD worker can update labels without needing to run nfd-master with informer cache of entire nodefeatures, maybe some subset map of nodefeatures just for gc if this issue is implemented: #2021 i.e. just store nodefeatures by name/node.
Why is this needed:
nodefeature CRs can be a footgun if users list them i.e. k get nodefeatures in a high scale environment.
nfd master also uses a ton of memory at scale.
If nodefeature-worker just handled the labels for its own node then it would alleviate a lot of scale concerns
The text was updated successfully, but these errors were encountered:
One big issue with the nodefeature objects currently is their size. Quickly thinking, I can see two big culprits adding to that. One is the "managed fields metadata", basically every feature (like kernel.enabledmodule.e1000 is listed there. Not sure how we could avoid listing every possible member of the CRD there, or alternatively filtering out this metadata in listers. Second one is the kernel.config feature which lists every kernel config option, most of which nobody is interested in, and there's a ton of those. We could start building a deny list for filtering out the uninteresting ones or smth.
Second improvent, which I think we really need (and which I have thought for a long time) would be sharding of nfd-master. I.e. distribute the nodes across multiple instances of nfd-master. E.g. calculate a checksum of the nodename and do mod number-of-shards to get the instance (shard) which is responsible for that node.
Splitting the functionality to two daemons is deliberate, e.g. from the security considerations.
What would you like to be added:
a mode where NFD worker can update labels without needing to run nfd-master with informer cache of entire nodefeatures, maybe some subset map of nodefeatures just for gc if this issue is implemented: #2021 i.e. just store nodefeatures by name/node.
Why is this needed:
nodefeature CRs can be a footgun if users list them i.e.
k get nodefeatures
in a high scale environment.nfd master also uses a ton of memory at scale.
If nodefeature-worker just handled the labels for its own node then it would alleviate a lot of scale concerns
The text was updated successfully, but these errors were encountered: