Container Service for Kubernetes:Accelerate Argo workflows

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 a 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: Use an Argo workflow to create containers to access OSS

You can create containers to test data access accelerated by JindoFS, or submit machine learning jobs to use relevant features. This section describes how to use an Argo workflow to create containers to access the data stored in OSS.

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

   apiVersion: argoproj.io/v1alpha1
   kind: Workflow
   metadata:
     generateName: serverless-workflow-
   spec:
     entrypoint: serverless-workflow-example
     volumes:
     - name: datadir
       persistentVolumeClaim:
         claimName: serverless-data
   
     templates:
     - name: serverless-workflow-example
       steps:
       - - name: copy
           template: copy-files
       - - name: check
           template: check-files
   
     - name: copy-files
       metadata:
         labels:
          alibabacloud.com/fluid-sidecar-target: eci
          alibabacloud.com/eci: "true"
         annotations:
            k8s.aliyun.com/eci-use-specs: ecs.g7.4xlarge
       container:
         image: debian:buster
         command: [bash, -c]
         args: ["time cp -r /data/ /tmp"]
         volumeMounts:
         - name: datadir
           mountPath: /data
   
     - name: check-files
       metadata:
         labels:
           alibabacloud.com/fluid-sidecar-target: eci
           alibabacloud.com/eci: "true"
         annotations:
            k8s.aliyun.com/eci-use-specs: ecs.g7.4xlarge
       container:
         image: debian:buster
         command: [bash, -c]
         args: ["du -sh /data; md5sum /data/*"]
         volumeMounts:
         - name: datadir
           mountPath: /data

2. Run the following command to create an Argo workflow:

   kubectl create -f workflow.yaml

3. Run the following command to print the container log:

   kubectl logs serverless-workflow-85sbr-4093682611

   Expected output:

   real    0m24.966s
   user    0m0.009s
   sys     0m0.677s

   The real field in the output shows that it took 24.966 seconds (0m24.966s) to replicate the Serving file. The duration varies based on the network latency and bandwidth. If you want to accelerate data access, refer to Accelerate Argo workflows in cache mode.

4. Check whether the file retrieved by using Fluid is the same as the local file.

   1. Run the following command to query the MD5 value of the file retrieved by using Fluid:

      kubectl logs serverless-workflow-85sbr-1882013783

      Expected output:

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

   2. Run the following command to query the MD5 value of the local file:

      md5sum ./wwm_uncased_L-24_H-1024_A-16.zip

      Expected output:

      871734851bf7d8d2d1193dc5f1f692e6  ./wwm_uncased_L-24_H-1024_A-16.zip

      The MD5 values are the same. This means that the file retrieved by using Fluid is the same as the local file.

Step 4: Clear data

After you test data access acceleration, clear the relevant data at the earliest opportunity.

1. Run the following command to delete the containers:

   kubectl delete workflow serverless-workflow-85sbr

2. Run the following command to delete the dataset:

   kubectl delete dataset serverless-data