How to Accelerate Data Access from Jobs with Cache Mode - Container Service for Kubernetes

Fluid optimizes object storage access in serverless scenarios through JindoRuntime, supporting both cache mode and no-cache mode. This topic explains how to use cache mode to accelerate data access for Job applications.

Cache mode vs. no cache mode: Cache mode stores OSS data locally in JindoFS, so pods read from memory or disk instead of the network. In this example, cache mode takes 1.76 seconds to replicate the test file, compared to 23.644 seconds in no cache mode — roughly 14x faster.

Mode	Time to replicate test file	Relative speed
Cache mode (this topic)	1.76 s	~14x faster
No cache mode	23.644 s	baseline

Prerequisites

Before you begin:

An ACK Pro cluster running a non-ContainerOS OS with Kubernetes 1.18+.

Important
ack-fluid does not support ContainerOS.
The cloud-native AI suite installed with the ack-fluid component deployed.
- If not yet installed, enable Fluid acceleration during installation.
- If already installed, deploy ack-fluid from the Cloud-native AI Suite page in the ACK console.
Important
If open-source Fluid is installed, uninstall it before deploying ack-fluid.
Virtual nodes deployed in the ACK Pro cluster.
A kubectl client connected to the cluster.
OSS activated and a bucket created.

Limitations

Mutually exclusive with ACK elastic scheduling.

Step 1: Upload the test dataset to the OSS bucket

Download a 2 GB test dataset. This example uses the BERT wwm_uncased_L-24_H-1024_A-16 dataset.
Upload the dataset to your OSS bucket with ossutil. See Install ossutil.

Step 2: Create a Dataset and JindoRuntime

Define your data source and configure caching. Deployment takes a few minutes.

Create secret.yaml to store your OSS credentials:

apiVersion: v1
kind: Secret
metadata:
  name: access-key
stringData:
  fs.oss.accessKeyId: ****
  fs.oss.accessKeySecret: ****

Deploy the Secret:
```
kubectl create -f secret.yaml
```

Create dataset.yaml, which defines two resources:

Dataset: defines the remote data source and authentication.
JindoRuntime: enables JindoFS caching in your cluster.

Important

The default access mode is read-only. For read/write mode, configure the dataset access mode.

Cache medium	`mediumtype`	Recommended `volumeType`	When to use
Memory	`MEM`	`emptyDir`	Fastest access; use `emptyDir` to prevent residual cache data
Local system disk	`SSD` or `HDD`	`emptyDir`	Use when memory is insufficient; `emptyDir` prevents residual cache data
Local data disk	`SSD` or `HDD`	`hostPath`	Set `path` to the mount path of the data disk on the host

Parameter reference

Parameter	Description
`mountPoint`	The UFS mount path. Format: `oss://<oss_bucket>/<bucket_dir>` (omit endpoint). Example: `oss://mybucket/path/to/dir`. Set `path` to `/` for a single mount.
`fs.oss.endpoint`	The public or internal endpoint of your OSS bucket. Use an internal endpoint (`oss-cn-<region>-internal.aliyuncs.com`) when your cluster and bucket are in the same region.
`fs.oss.accessKeyId`	The AccessKey ID for bucket access.
`fs.oss.accessKeySecret`	The AccessKey secret for bucket access.
`replicas`	Number of JindoFS worker nodes.
`mediumtype`	The cache medium type. Valid values: `HDD`, `SSD`, `MEM`. See Policy 2: Select proper cache media.
`volumeType`	The volume type for the cache medium. Valid values: `emptyDir` and `hostPath`. Default value: `hostPath`. Use `emptyDir` for memory or local system disks to prevent residual cache data; use `hostPath` for local data disks. See Policy 2: Select proper cache media.
`path`	The cache path on the node. Only one path allowed.
`quota`	Maximum cache size. Example: `5Gi` = 5 GiB.
`high`	Upper storage watermark. JindoFS evicts cache when usage exceeds this ratio.
`low`	Lower storage watermark. JindoFS stops evicting when usage drops to this ratio.

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: serverless-data
spec:
  mounts:
  - mountPoint: oss://<oss_bucket>/<bucket_dir>
    name: demo
    path: /
    options:
      fs.oss.endpoint: <oss_endpoint>
    encryptOptions:
      - name: fs.oss.accessKeyId
        valueFrom:
          secretKeyRef:
            name: access-key
            key: fs.oss.accessKeyId
      - name: fs.oss.accessKeySecret
        valueFrom:
          secretKeyRef:
            name: access-key
            key: fs.oss.accessKeySecret
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: serverless-data
spec:
  replicas: 1
  tieredstore:
    levels:
      - mediumtype: MEM
        volumeType: emptyDir
        path: /dev/shm
        quota: 5Gi
        high: "0.95"
        low: "0.7"

Choose a cache medium and volume type Pick the combination that fits your workload:

Deploy the Dataset and JindoRuntime:
```
kubectl create -f dataset.yaml
```

Verify the Dataset is ready:

kubectl get dataset serverless-data

Expected output:

NAME              UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
serverless-data   1.16GiB          0.00B    5.00GiB          0.0%                Bound   2m8s

The Dataset is ready when PHASE shows Bound.

Verify the JindoRuntime is ready:

kubectl get jindo serverless-data

Expected output:

NAME              MASTER PHASE   WORKER PHASE   FUSE PHASE   AGE
serverless-data   Ready          Ready          Ready        2m51s

The JindoRuntime is ready when FUSE PHASE shows Ready.

(Optional) Step 3: Prefetch data

Load OSS data into JindoFS cache before your Job runs to eliminate cold-start latency. Recommended for large datasets or slow OSS connections.

Create dataload.yaml:

apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: serverless-data-warmup
spec:
  dataset:
    name: serverless-data
    namespace: default
  loadMetadata: true

Deploy the DataLoad:
```
kubectl create -f dataload.yaml
```

Check prefetching progress:

kubectl get dataload

Expected output:

NAME                     DATASET           PHASE      AGE     DURATION
serverless-data-warmup   serverless-data   Complete   2m49s   45s

Prefetching is complete when PHASE shows Complete.

Verify the cache fill:

kubectl get dataset

Expected output:

NAME              UFS TOTAL SIZE   CACHED    CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
serverless-data   1.16GiB          1.16GiB   5.00GiB          100.0%              Bound   5m20s

CACHED PERCENTAGE shows 100.0% after prefetching, confirming all data is cached locally.

Step 4: Run a Job to access OSS data

Create a Job-type application container to access OSS data. Fluid adapts the pod automatically — no application changes required.

Choose the compute environment for your pods:

Deploy an application pod as an Elastic Container Instance

Add the alibabacloud.com/fluid-sidecar-target=eci label to run the pod as an Elastic Container Instance (ECI). Fluid converts the pod to ECI-compatible format at creation.

Create job.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: model-serving
spec:
  selector:
    matchLabels:
      app: model-serving
  template:
    metadata:
      labels:
        app: model-serving
        alibabacloud.com/fluid-sidecar-target: eci
        alibabacloud.com/eci: "true"
    spec:
      containers:
        - image: fluidcloudnative/serving
          name: serving
          ports:
            - name: http1
              containerPort: 8080
          env:
            - name: TARGET
              value: "World"
          volumeMounts:
            - mountPath: /data
              name: data
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: serverless-data

Deploy an application pod as an ACS pod

Add the alibabacloud.com/fluid-sidecar-target=acs label to use Alibaba Cloud Container Compute Service (ACS) compute resources. Fluid adapts the pod to ACS at creation.

Important

ack-fluid v1.0.11+ required to access cached Fluid data in ACS containers.
Accessing cached Fluid data in ACS containers requires advanced pod features. Submit a support ticket to enable this feature.

Create job.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: model-serving
spec:
  selector:
    matchLabels:
      app: model-serving
  template:
    metadata:
      labels:
        app: model-serving
        alibabacloud.com/fluid-sidecar-target: acs
        alibabacloud.com/acs: "true"
        alibabacloud.com/compute-qos: default
        alibabacloud.com/compute-class: general-purpose
    spec:
      containers:
        - image: fluidcloudnative/serving
          name: serving
          ports:
            - name: http1
              containerPort: 8080
          env:
            - name: TARGET
              value: "World"
          volumeMounts:
            - mountPath: /data
              name: data
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: serverless-data

Deploy and verify

Deploy the Job:
```
kubectl create -f job.yaml
```
Check the container log for data access performance:
```
kubectl logs demo-app--1-7zqdm -c demo
```
Expected output:
```
real    0m1.760s
user    0m0.002s
sys     0m0.740s
```
The real time (0m1.760s) is the time to replicate the file from cache. Compared to no cache mode (23.644 s), cache mode is ~14x faster.

Step 5: Clean up

Delete the resources after testing to avoid orphaned cache data.

Delete the Job:
```
kubectl delete job demo-app
```
Delete the Dataset (also removes the JindoRuntime):
```
kubectl delete dataset serverless-data
```

Next steps

Accelerate Jobs (no cache mode) — compare performance without local caching
Best practices for optimizing Fluid data caching strategies — tune cache medium, watermarks, and quota for production
Configure the access mode of a dataset — enable read/write access for datasets