Container Service for Kubernetes:Accelerate online applications

Limits

This feature is mutually exclusive with the elastic scheduling feature of ACK. For more information about the elastic scheduling feature of ACK, see Configure priority-based resource scheduling.

Step 1: Upload the test dataset to the OSS bucket

1. Create a test dataset of 2 GB in size. In this example, the test dataset is used.

2. Upload the test dataset to the OSS bucket that you created.

   You can use the ossutil tool provided by OSS to upload data. For more information, see Install ossutil.

Step 2: Create a dataset and JindoRuntime

After you set up the ACK cluster and OSS bucket, you need to deploy the dataset and JindoRuntime. The deployment requires only a few minutes.

1. Create a file named secret.yaml based on the following content.

   The file contains the fs.oss.accessKeyId and fs.oss.accessKeySecret that are used to access the OSS bucket.

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

2. Run the following command to deploy the Secret:

   kubectl create -f secret.yaml

3. Create a file named resource.yaml based on the following content.

   The YAML file stores the following information:

   • Dataset: specifies the dataset that is stored in a remote datastore and the Unix file system (UFS) information.

   • JindoRuntime: enables JindoFS for data caching in the cluster.

   apiVersion: data.fluid.io/v1alpha1
   kind: Dataset
   metadata:
     name: serverless-data
   spec:
     mounts:
     - mountPoint: oss://large-model-sh/
       name: demo
       path: /
       options:
         fs.oss.endpoint: oss-cn-shanghai.aliyuncs.com
       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
     accessModes:
       - ReadWriteMany
   ---
   apiVersion: data.fluid.io/v1alpha1
   kind: JindoRuntime
   metadata:
     name: serverless-data
   spec:
     master:
       disabled: true
     worker:
       disabled: true

   The following table describes some of the parameters that are specified in the preceding code block.

   Parameter	Description
   mountPoint	The path to which the UFS file system is mounted. The format of the path is oss://<oss_bucket>/<bucket_dir>. Do not include endpoint information in the path. <bucket_dir> is optional if you can directly access the bucket.
   fs.oss.endpoint	The public or private endpoint of the OSS bucket. You can specify the private endpoint of the bucket to enhance data security. However, if you specify the private endpoint, make sure that your ACK cluster is deployed in the region where OSS is activated. For example, if your OSS bucket is created in the China (Hangzhou) region, the public endpoint of the bucket is oss-cn-hangzhou.aliyuncs.com and the private endpoint is oss-cn-hangzhou-internal.aliyuncs.com.
   fs.oss.accessKeyId	The AccessKey ID that is used to access the bucket.
   fs.oss.accessKeySecret	The AccessKey secret that is used to access the bucket.
   accessModes	The access mode. Valid values: ReadWriteOnce, ReadOnlyMany, ReadWriteMany, and ReadWriteOncePod. Default value: ReadOnlyMany.
   disabled	If you set this parameter to true for both master and worker nodes, the no cache mode is used.

4. Run the following command to deploy the dataset and JindoRuntime:

   kubectl create -f resource.yaml

5. Run the following command to check whether the dataset is deployed:

   kubectl get dataset serverless-data

   Expected output:

   NAME              UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
   serverless-data                                                                  Bound   1d

   Bound is displayed in the PHASE column of the output. This indicates that the dataset is deployed.

6. Run the following command to check whether the JindoRuntime is deployed:

   kubectl get jindo serverless-data

   Expected output:

   NAME              MASTER PHASE   WORKER PHASE   FUSE PHASE   AGE
   serverless-data                                 Ready        3m41s

   Ready is displayed in the FUSE column of the output. This indicates that the JindoRuntime is deployed.

Step 3: Create serverless containers to access OSS

Create containers to test data access accelerated by JindoFS, or submit machine learning jobs to use relevant features. This section describes how to use a Deployment to create containers to access the data stored in OSS.

1. Create a file named serving.yaml based on the following content:

   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"
         annotations:
            k8s.aliyun.com/eci-use-specs: ecs.g7.4xlarge
       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

2. Deploy the Deployment:

   kubectl create -f serving.yaml

3. Check the size of the Serving file.

   1. Log on to a container:

      kubectl exec -it model-serving-85b645b5d5-2trnf -c serving -- bash

   2. Query the size of the Serving file:

      bash-4.4# du -sh /data/wwm_uncased_L-24_H-1024_A-16.zip

      Expected output:

      1.2G    /data/wwm_uncased_L-24_H-1024_A-16.zip   

4. Print the container log:

   kubectl  logs model-serving-85b9587c5b-w5528  -c serving

   Expected output:

   Begin loading models at 18:23:59
   
   real    0m27.107s
   user    0m0.000s
   sys    0m0.742s
   Finish loading models at 18:24:26

   The real field in the output shows that it took 27.107 seconds (0m27.107s) to replicate the Serving file. The duration varies based on the network latency and bandwidth. To accelerate data access, see Accelerate online applications in cache mode.

Step 4: Clear data

If you no longer need data access acceleration, clear the environment.

1. Delete the containers:

   kubectl delete deployment model-serving

2. Delete the dataset:

   kubectl delete dataset serverless-data

References

• Accelerate online applications in no cache mode: Accelerate Jobs, Accelerate Argo workflows.

• Accelerate online applications in no cache mode with ACK mode: ACK cache mode.

• Accelerate online applications in no cache mode with ACK Serverless mode: ACK Serverless cache mode.