Skip to content
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

Add low-level controller-runtime object cache filters #5944

Open
rainest opened this issue Apr 26, 2024 · 0 comments
Open

Add low-level controller-runtime object cache filters #5944

rainest opened this issue Apr 26, 2024 · 0 comments
Milestone

Comments

@rainest
Copy link
Contributor

rainest commented Apr 26, 2024

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?

Previous discussion:

#5856
#5876
#4578

@rainest rainest added this to the KIC v4.0.x milestone Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant