feat(caching): introduce FusionCache for flexible L1/L2 caching #914
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…g (hybrid cache) - Integrated FusionCache for robust caching in resource watchers. - Enhanced default configuration with extensible settings in `OperatorSettings`. - Improved concurrency handling using `SemaphoreSlim` for entity events. - Updated tests and dependencies to reflect caching changes.
…nt entity locks - Renamed `DefaultCacheConfiguration` to `DefaultResourceWatcherCacheConfiguration` for clarity. - Introduced cache key prefix to improve cache segmentation. - Removed `ConcurrentDictionary` for entity locks to simplify concurrency management. - Refactored event handling logic for "added" and "modified" events to streamline codebase.
- Updated `ConfigureResourceWatcherEntityCache` to use `IFusionCacheBuilder` for extensibility. - Moved resource watcher cache setup logic to `WithResourceWatcherCaching` extension. - Added detailed XML comments for `EntityLoggingScope` to improve documentation. - Removed redundant `DefaultResourceWatcherCacheConfiguration`.
- Renamed `WithResourceWatcherCaching` to `WithResourceWatcherEntityCaching` for clarity. - Updated `CacheExtensions` to be `internal` to limit scope. - Removed unused dependency on `ZiggyCreatures.Caching.Fusion`.
…onstants` for consistency
- Added a new `Caching` documentation page explaining resource watcher caching with FusionCache and configuration options (in-memory and distributed). - Updated sidebar positions for `Deployment`, `Utilities`, and `Testing` to accommodate the new `Caching` page.
…usionCache details - Improved explanations for in-memory and distributed caching setups. - Added example code for customizing resource watcher cache with FusionCache. - Included references to FusionCache and Redis documentation for further guidance.
|
Amazing, thank you for this! After this has been done, I'll happily look at the change. Thanks for the contribution! |
|
That's amazing news - congrats for this! |
buehler
reviewed
Jul 16, 2025
|
Thanks Christoph / @buehler 🙏 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request introduces
FusionCacheto manage the caching of resource generations. This change replaces the simple, volatile in-memory cache with a more powerful and flexible two-level caching system.Motivation:
The previous implementation used a simple in-memory cache, which had a significant drawback: it was volatile. Upon a pod restart, the entire cache was lost, forcing the operator to perform a full reconciliation of observed resources he retrieves events for. This is inefficient and can put a significant load on the Kubernetes API server.
By integrating
FusionCache, we can address these issues:Flexibility: It provides seamless support for a two-level (L1/L2) caching strategy. Developers can continue to use a fast in-memory (L1) cache by default, requiring no extra configuration.
Scalability & Resilience: For production and HA setups, a distributed (L2) cache (e.g., Redis) can be easily configured. This ensures that the cache state is persistent across restarts and shared between multiple operator instances, preventing unnecessary reconciliation cycles.
Configurability: A new configuration delegate, , is introduced in the
OperatorSettings. This allows users to easily customize the caching behavior to fit their specific needs, such as adding a serializer, configuring a distributed cache, or adjusting entry options.ConfigureResourceWatcherEntityCacheThis change makes the operator more robust, performant, and suitable for demanding production environments while maintaining the simplicity of the default configuration.
Furthermore, this can lay the groundwork for leveraging FusionCache to persist enqueued reconciliation requests in the future, ensuring that they are not lost during pod restarts.