Informer support filter by multi-namespace resource

[wangyushuai]

Is your enhancement related to a problem? Please describe

I want to implement watch resources in multiple namespaces, but currently the client only supports specifying one namespace or all namespaces.

Describe the solution you'd like

support method, withNamespacesIn(List<String> namespaces)`, support filter by partly namespaces

Describe alternatives you've considered

In many scenarios, it is unnecessary to watch resources in all namespaces. , and the informer will do a layer of caching. it will waste resources if only need partly namesapce

Additional context

No response

[csviri]

Hi @wangyushuai , the problem is that Kubernetes API does not support this, in Java Operator SDK this is supported, but just creating an informer for each namespace. Another option is to provide a cache implementation where only the resources for the target namespaces are cached as a whole, others are pruned (only name, namespace, resourceVersion) is cached.

The third option is to use label selectors, if possible for your use case, and filter resources by that.

[wangyushuai]

Hi @wangyushuai , the problem is that Kubernetes API does not support this, in Java Operator SDK this is supported, but just creating an informer for each namespace. Another option is to provide a cache implementation where only the resources for the target namespaces are cached as a whole, others are pruned (only name, namespace, resourceVersion) is cached.

The third option is to use label selectors, if possible for your use case, and filter resources by that.

HI @csviri ,

I checked the k8s openapi and found that if you do not specify the namespace, you can query and match through fieldSelector, that is, metadata.namespace in (a, b) for filtering.

However, there is no such method in our sdk. I checked the source code and found that the client only supports Single key and value matching, but multiple value syntax is not supported. See the source code location: io.fabric8.kubernetes.client.dsl.internal.FilterNestedImpl#withoutField

Can you guys give me some suggestions to implement my function? @manusa @iocanel @rohanKanojia

[csviri]

Ahh yes, forgot that, field selectors are also an option for namespaces, true.

[shawkins]

I checked the k8s openapi and found that if you do not specify the namespace, you can query and match through fieldSelector, that is, metadata.namespace in (a, b) for filtering.

One consideration is that RBAC will require cluster scope.

I checked the source code and found that the client only supports Single key and value matching, but multiple value syntax is not supported

That is correct - and it is not supported by Kubernetes. See the note about set operations - https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/#supported-operators

Each filter expression is AND'd together - there's no support for OR. So the best you can do is a bunch of without field expressions to exclude every namespace you don't wont - however that is not likely to be practical you's need to restart the operator everytime a new excluded namespace needs to be added, and eventually the filter length or performance could become an issue.

[manusa]

I'm not sure if as a UX improvement it might make sense to add support for this client-side (maybe downstream in JOSDK). The client or JOSDK support observing multiple namespaces and internally (transparently for users) opens the required informers.

[csviri]

Not in the current Informer implementation IMO, maybe an additional layer above it? It might make sense for other projects like the webhooks, where users tend also to implement Informers. Note that JOSDK supports this, even more, at some request on-demand added dynamically changing the watched namespaces. Theoretically, this could be moved upstream with refactored API (In JOSDK this is quite tightly coupled with EventSources).

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!