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
https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/cache#Options provides various options for limiting which resources controller-runtime ingests into its cache, DefaultLabelSelector, DefaultFieldSelector, and ByObject map[client.Object]ByObject per-GVK overrides. These filter objects before they are sent to reconcilers. We can use them to, for example, process only Secrets with a recognized label, process only Ingresses with a specific ingressClassName field value, or bulk filter any object without a particular label.
This is a first-pass filter below more complex filters in reconcilers. We have known performance and multi-tenancy reasons to apply this first-pass filter.
Adding such filters is a significant break from older versions' behavior. Although we have required ingress.class labels on objects we process independently, we historically have not required labeling objects those objects reference. An Ingress requires a matching class label to be ingested, but a certificate Secret it references does not.
We wish to add filters, but need to manage the transition for previously un-labeled resources and determine exactly how we filter objects:
While ingress.class has de facto grandfathered status as a filter label for non-Ingress Kong CRs, it's a bit odd to use it still with Gateway API resources. Do we want to add a new bulk filter label? Can we somehow allow for backwards compatibility with ingress.class?
Do we want bulk or per-object filters, or some combination of both? Per-object filters introduce more UX complexity, but allow us more fine-grained control over object ingest or means to apply rules other than "recognized by Kong cluster X".
How do we manage the transition? Will this be required for all users, or will it remain an optional filter for users whose environment characteristics mandate it for performance or tenancy reasons?
https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/cache#Options provides various options for limiting which resources controller-runtime ingests into its cache,
DefaultLabelSelector
,DefaultFieldSelector
, andByObject map[client.Object]ByObject
per-GVK overrides. These filter objects before they are sent to reconcilers. We can use them to, for example, process only Secrets with a recognized label, process only Ingresses with a specificingressClassName
field value, or bulk filter any object without a particular label.This is a first-pass filter below more complex filters in reconcilers. We have known performance and multi-tenancy reasons to apply this first-pass filter.
Adding such filters is a significant break from older versions' behavior. Although we have required
ingress.class
labels on objects we process independently, we historically have not required labeling objects those objects reference. An Ingress requires a matching class label to be ingested, but a certificate Secret it references does not.We wish to add filters, but need to manage the transition for previously un-labeled resources and determine exactly how we filter objects:
ingress.class
has de facto grandfathered status as a filter label for non-Ingress Kong CRs, it's a bit odd to use it still with Gateway API resources. Do we want to add a new bulk filter label? Can we somehow allow for backwards compatibility withingress.class
?Previous discussion:
#5856
#5876
#4578
The text was updated successfully, but these errors were encountered: