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

Set CacheOptions in ctrl.Manager to only cache secrets with certain labels to prevent caching all secrets #1255

Open
1 task
randmonkey opened this issue Feb 28, 2025 · 0 comments

Comments

@randmonkey
Copy link
Contributor

randmonkey commented Feb 28, 2025

Problem Statement

As discussed in #1250 (comment), we need to configure CacheOption in Manager to configure the constraints of cached objects. We want to limit the caching of Secret because there are too many of them in the cluster, and most of them are not relevant.

The constraint can reduce the CPU/memory consumption of the controllers as well as Kubernetes API server load. But it needs users to set certain labels on the Secret if they want to use them somewhere (like certificates or configuration). We need to discuss whether should we add a GLOBAL constraint to watched Secrets. It will be a breaking change if we are already watching Secrets somewhere.

Proposed Solution

Consider making labels for all Secrets (and ConfigMaps) to be reconciled by KGO required (it could be a konghq.com/credential label existence requirement). It can be configured in cache.Options on the controller-runtime Manager level. Most likely this change would be breaking as we may not require all Secrets to be labeled as of now (but this is to be verified).

A non-breaking alternative would be to add a default off flag (e.g. --watch-only-labeled-secrets) that would change this config when someone specifically asks for it (e.g. because they experience performance issues).

Acceptance Criteria

  • KGO only watches/caches labeled Secrets
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

2 participants