Add a TTL on the runtime predicate cache #1837
Description
What problem are you trying to solve?
Right now the predicate cache grows without constraints over the lifetime of the controller, and when used with automatically generated names (like say for pods), will grow and consume more memory than is necessary.
With the introduction of uid gating on predicates (where separate uid objectrefs count as separate) in #1830, this problem becomes relevant also for resources potentially without autogenerated names.
It would be good to have some upper bound on lifetime of objects without the predicate cache.
Describe the solution you'd like
Some kind of in-memory TTL cache in the predicates runtime module. Ideally small, we can check TTL when the events come in. A small crate could also be acceptable if it looks well maintained / stable.
TTL value could be configurable via the predicate_filter method with a required predicate::Config with a Duration and this config could have a Default impl (with a high TTL - given the old behavior is to NEVER expire).
This way the breaking change is (worst case), for people who don't care to add ,Default::default() to the fn call and they get a very long TTL.
Describe alternatives you've considered
not caring about the small memory use.
Documentation, Adoption, Migration Strategy
Forced new parameter can be added to kube v3 release.
Target crate for feature
- kube-runtime