How to accelerate data access for PV storage volumes by using JindoRuntime - Container Service for Kubernetes

Prerequisites

You have created an ACK Pro cluster of v1.18 or later that runs on an operating system other than ContainerOS. For more information, see Create an ACK Pro cluster.

Important
The ack-fluid component does not support ContainerOS.
You have installed the cloud-native AI suite and deployed the ack-fluid add-on. The ack-fluid version must be 1.0.6 or later.

Important
If you have installed open-source Fluid, uninstall it before you deploy the ack-fluid add-on.
- If the cloud-native AI suite is not installed: enable Fluid when you install it.
- If the suite is already installed: open the ACK console, go to the Cloud-native AI Suite page, and deploy ack-fluid.
You have connected to your Kubernetes cluster using kubectl. For more information, see Connect to a Kubernetes cluster by using kubectl.
You have created the persistent volume (PV) and persistent volume claim (PVC) for the storage system that you want to access.

In a Kubernetes environment, each storage system creates volumes differently. To keep the connection between the storage system and the cluster stable, prepare the volumes as described in that system's official documentation.

Step 1: Verify PV and PVC status

List the PVs and PVCs in the cluster.

kubectl get pvc,pv

Expected output:

NAME                                          STATUS   VOLUME                          CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/demo-pvc                Bound    demo-pv                         5Gi        RWX                           19h

NAME                                             CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                           STORAGECLASS   REASON   AGE
persistentvolume/demo-pv                         30Gi       RWX            Retain           Bound    default/demo-pvc                                        19h

The output shows that demo-pv (30 GiB, ReadWriteMany) is bound to demo-pvc. Both are ready to use.

Step 2: Create a Dataset and JindoRuntime

A Fluid Dataset declares which PVC to cache, and a JindoRuntime starts the JindoFS distributed caching system. Both resources must share the same name so that Fluid can associate them automatically.

Create dataset.yaml with the following content.

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: pv-demo-dataset
spec:
  mounts:
    - mountPoint: pvc://demo-pvc  # Format: pvc://<pvc-name>/<path>. The path must exist in the storage volume.
      name: data
      path: /
  accessModes:
    - ReadOnlyMany
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: pv-demo-dataset            # Must match the Dataset name above.
spec:
  replicas: 2                      # Number of JindoFS worker replicas. Adjust based on your cluster size.
  tieredstore:
    levels:
      - mediumtype: MEM            # Cache medium: HDD, SSD, or MEM.
        volumeType: emptyDir       # emptyDir for memory/system-disk cache; hostPath for data-disk cache.
        path: /dev/shm             # Use a memory-backed path for best performance.
        quota: 10Gi                # Maximum cache capacity per worker. Adjust as needed.
        high: "0.9"                # Eviction threshold: start evicting when usage reaches 90%.
        low: "0.8"                 # Eviction target: evict until usage drops to 80%.

Choosing mediumtype and volumeType

These two parameters determine where cached data is stored on each worker node. The right combination depends on the storage medium that you use for the cache, as described in the following table. For more guidance, see Select cache media.

Cache location	`mediumtype`	`volumeType`	When to use
Memory (`/dev/shm`)	`MEM`	`emptyDir`	Fastest reads; cache is released when the pod exits, so residual cache data cannot accumulate on nodes and affect node availability.
System disk	`HDD` or `SSD`	`emptyDir`	emptyDir removes the cached data when the pod exits, so residual data cannot accumulate on the node and affect node availability.
Data disk	`HDD` or `SSD`	`hostPath`	Use when you have a dedicated data disk; set `path` to the disk's mount point on the host.

Key parameters

Parameter	Description
`mountPoint`	The data source to cache. Format: `pvc://<pvc-name>/<path>`. The `<pvc-name>` must be in the same namespace as the Dataset. The `<path>` must exist in the storage volume.
`replicas`	Number of JindoFS worker replicas.
`mediumtype`	Cache medium type. Only `HDD` (hard disk drive), `SSD` (solid-state drive), and `MEM` (memory) are supported.
`volumeType`	Volume type for cache storage. Valid values: `emptyDir` and `hostPath`. The default value is `hostPath`. See the table above.
`path`	Directory where the JindoFS cache workers store cached data. For optimal data access performance, use `/dev/shm` or another path mounted as an in-memory file system.
`quota`	Maximum cache capacity per worker.

Create the Dataset and JindoRuntime resources.
```
kubectl create -f dataset.yaml
```
Wait for the Dataset to become ready.
```
kubectl get dataset pv-demo-dataset
```
On first startup, JindoFS pulls container images. This typically takes 2–3 minutes depending on your network.

Expected output when ready:
```
NAME              UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
pv-demo-dataset   10.96GiB         0.00B    20.00GiB         0.0%                Bound   2m13s
```
A PHASE of Bound means the JindoFS caching system is running and application pods can start using the Dataset.

Step 3 (optional): Prefetch data into the cache

Without prefetching, the first read of each file fetches data from remote storage, which is slower. Fluid's DataLoad resource lets you warm the cache ahead of time so that all subsequent reads come from the local cache.

Create dataload.yaml with the following content.

apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: dataset-warmup
spec:
  dataset:
    name: pv-demo-dataset    # Name of the Dataset to prefetch.
    namespace: default       # Must match the namespace of the DataLoad object.
  loadMetadata: true         # Required for JindoRuntime: syncs file metadata before prefetching.
  target:
    - path: /                # Path relative to the Dataset mount point. "/" prefetches everything.
      replicas: 1            # Number of cache copies to create for each file.

For example, if the Dataset mounts pvc://my-pvc/mydata, setting path to /test prefetches the /mydata/test directory in the storage system behind my-pvc.

Create the DataLoad object.
```
kubectl create -f dataload.yaml
```

Monitor the prefetch job.

kubectl get dataload dataset-warmup

Expected output when complete:

NAME             DATASET           PHASE      AGE   DURATION
dataset-warmup   pv-demo-dataset   Complete   62s   12s

Confirm that the cache is fully populated.

kubectl get dataset

Expected output:

NAME              UFS TOTAL SIZE   CACHED     CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
pv-demo-dataset   10.96GiB         10.96GiB   20.00GiB         100.0%              Bound   3m13s

When CACHED matches UFS TOTAL SIZE and CACHED PERCENTAGE is 100.0%, all data is cached locally.

Step 4: Access data through the cache

Create pod.yaml with the following content, and change claimName to the name of the Dataset created in Step 2.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
      command:
      - "bash"
      - "-c"
      - "sleep inf"
      volumeMounts:
        - mountPath: /data
          name: data-vol
  volumes:
    - name: data-vol
      persistentVolumeClaim:
        claimName: pv-demo-dataset  # Must be the same as the Dataset name.

Create the pod.
```
kubectl create -f pod.yaml
```

Open a shell in the pod and read data.

kubectl exec -it nginx bash

Inside the pod, verify the data is accessible and measure read throughput:

# List files in the mounted directory.
ls -lh /data
total 11G
-rw-r----- 1 root root 11G Jul 22  2022 demofile

# Read the entire file and discard output to measure throughput.
time cat /data/demofile > /dev/null
real    0m11.004s
user    0m0.065s
sys     0m3.089s

Because JindoFS caches the entire dataset locally, reads come from the cache instead of the remote storage system. This reduces network transfer and speeds up data access.

What's next

Select cache media — guidance on choosing between HDD, SSD, and MEM cache tiers for your workload.