Feature: init CacheRuntime and CacheRuntimeClass api #4478
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.
1. Background
Fluid is committed to providing Kubernetes users with a simple and efficient solution for cloud data access and cache acceleration. To achieve this, Fluid currently extends compatibility with various distributed data engines in an in-tree manner, including Alluxio, Juicefs, Vineyard, and JindoFS. This enables users to leverage these caching systems to establish seamless data access links with underlying heterogeneous storage systems within the Kubernetes cluster, while also achieving data access cache acceleration.
As Fluid continues to develop, more and more cache engines, in addition to those already integrated, hope to be connected to Fluid in the future to meet more users' requirements for data cache control and lifecycle management. Examples include Dragonfly and cubeFS. However, the existing runtime development integration model requires cache engine developers to have a substantial foundation in Kubernetes development and an in-depth understanding of the full lifecycle management of Fluid Runtime. This undoubtedly increases the difficulty and time costs of integration for developers outside the Kubernetes domain. Therefore, Fluid aims to simplify the development integration model of data cache engines in a cloud-native environment, achieve better division of responsibilities, and allow developers to focus on their areas of expertise as much as possible.
2. The goal of this PR
The Fluid community plans to introduce a common CacheRuntime mechanism to keep the complexity of interaction with Kubernetes and lifecycle management within the community.
In this way, cache engine developers only need to focus on system development and a small amount of adaptation work to connect the engine to Kubernetes, and is compatible with the data manipulation capability of the Fluid. This greatly reduces the access complexity and optimizes the user experience in Kubernetes.
3. Key concepts
There are two new CRD CacheRuntime and CacheRuntimeClass will be introduced, Users can create various types of caching systems through a CacheRuntime CRD by specifying a CacheRuntimeClass, which selects a cache system deployment template provided by the vendor. Fluid constructs the corresponding cache system based on the cache system configuration in CacheRuntime and the RuntimeClass deployment template used. It then integrates, accesses, and caches data according to the data source definitions in the user’s Dataset.