Use advanced Fluid configurations in serverless scenarios - Container Service for Kubernetes

You can use Fluid together with JindoRuntime to accelerate access to data stored in Object Storage Service (OSS) in serverless scenarios. This topic describes how to use advanced Fluid configurations in serverless scenarios, including how to set the pod termination grace period and configure container mount target check.

Prerequisites

A Container Service for Kubernetes (ACK) Pro cluster with non-containerOS is created, and the Kubernetes version of the cluster is 1.18 or later. For more information, see Create an ACK Pro cluster.
Important
The ack-fluid component is not currently supported on the ContainerOS.
The cloud-native AI suite is installed and the ack-fluid component is deployed.
Important
If you have already installed open source Fluid, uninstall Fluid and deploy the ack-fluid component.
- If you have not installed the cloud-native AI suite, enable Fluid acceleration when you install the suite. For more information, see Deploy the cloud-native AI suite.
- If you have already installed the cloud-native AI suite, go to the Cloud-native AI Suite page of the ACK console and deploy the ack-fluid component.
Virtual nodes are deployed in the ACK Pro cluster. For more information, see Schedule pods to elastic container instances.
A kubectl client is connected to the ACK Pro cluster. For more information, see Connect to a cluster by using kubectl.
OSS is activated and a bucket is created. For more information, see Activate OSS and Create buckets.

Set the pod termination grace period

Fluid uses sidecar injection to enable the containers in a pod to access data stored in OSS in serverless scenarios. The default grace period from when the containers in a pod are gracefully terminated to when the pod is gracefully terminated is 30 seconds. To decrease the grace period, you can configure the terminationGracePeriodSeconds parameter.

Note

The terminationGracePeriodSeconds parameter specifies the grace period of pod termination. Set a proper value based on your business requirements.

Example 1: Jobs

The following YAML template shows how to set the terminationGracePeriodSeconds parameter to the minimum value for pods that are created by a Job:

apiVersion: batch/v1
kind: Job
metadata:
  name: demo-app
spec:
  terminationGracePeriodSeconds: 0
  template:
    metadata:
      labels:
        alibabacloud.com/fluid-sidecar-target: eci
        alibabacloud.com/eci: "true"
    spec:
      containers:
        - name: demo
          image: debian:buster
          args:
            - -c
            - time cp -r /data/ /tmp
          command:
            - /bin/bash
          volumeMounts:
            - mountPath: /data
              name: demo
      restartPolicy: Never
      volumes:
        - name: demo
          persistentVolumeClaim:
            claimName: serverless-data
  backoffLimit: 4

In the preceding YAML template, spec.terminationGracePeriodSeconds: 0 indicates that the pod termination grace period is set to 0.

Example 2: Argo workflows

The following YAML template shows how to set the terminationGracePeriodSeconds parameter to the minimum value for pods that are created by an Argo workflow:

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: serverless-workflow-
spec:
  podSpecPatch: '{"terminationGracePeriodSeconds": 0}'
  entrypoint: serverless-workflow-example
  volumes:
  # Pass serverless-data as an argument to the serverless-workflow-example template
  # Same syntax as k8s Pod spec
  - 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.s6-c1m2.xlarge
    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.s6-c1m2.xlarge
    container:
      image: debian:buster
      command: [bash, -c]
      args: ["du -sh /data; md5sum /data/*"]
      volumeMounts:
      - name: datadir
        mountPath: /data

In the preceding YAML template, spec.podSpecPatch: '{"terminationGracePeriodSeconds": 0}' indicates that the pod termination grace period is set to 0.

Configure container mount target check

Fluid uses sidecar injection to enable the containers in a pod to access data stored in OSS in serverless scenarios.

You may want to check the validity of the mount targets created for your sidecar containers. Fluid can automatically inject a mount target check script into your pod to check the validity of mount targets. The path of the script in the pod is /check-dataset-ready.sh. You can modify or use Fluid to automatically configure the lifecycle.postStart handler to ensure that the containers can access data as expected.

Important

The mount target check script provided by Fluid relies on Bash. Make sure that Bash is installed in the container image before you use the mount target check script.

Method 1: Manually configure container mount target check

The following YAML template shows how to configure container mount target check for a Job:

apiVersion: batch/v1
kind: Job
metadata:
  name: demo-app
spec:
  template:
    metadata:
      labels:
        alibabacloud.com/fluid-sidecar-target: eci
        alibabacloud.com/eci: "true"
    spec:
      containers:
        - name: demo
          image: debian:buster
          lifecycle:
            postStart:
              exec:
                command:
                - /check-dataset-ready.sh
                - "jindo"
                - "/data"
          args:
            - -c
            - time cp -r /data/ /tmp
          command:
            - /bin/bash
          volumeMounts:
            - mountPath: /data
              name: demo
      restartPolicy: Never
      volumes:
        - name: demo
          persistentVolumeClaim:
            claimName: serverless-data
  backoffLimit: 4

In the preceding YAML template, the /check-dataset-ready.sh jindo /data script for mount target check is added to lifecycle.postStart.exec.command.

The first keyword, which is jindo in this example, varies based on the type of Fluid dataset runtime. The following table describes the mount target check keywords that correspond to different runtime types.
Runtime
Mount target check keyword
JindoRuntime
jindo
AlluxioRuntime
alluxio
JuiceFSRuntime
juicefs
The second keyword, which is /data in this example, specifies the path that the Fluid dataset persistent volume claim (PVC) mounts to the container. You can obtain the path from the volumeMounts parameter.

Method 2: Use Fluid to automatically configure container mount target check

This section provides two examples to describe how to automatically configure container mount target check for a Job and an Argo workflow by using Fluid.

Example 1: Jobs

You can use Fluid to automatically configure the preceding mount target check script. The following YAML template shows how to use Fluid to automatically configure the mount target check script for a Job:

apiVersion: batch/v1
kind: Job
metadata:
  name: demo-app
spec:
  template:
    metadata:
      labels:
        alibabacloud.com/fluid-sidecar-target: eci
        alibabacloud.com/eci: "true"
        app.poststart.fluid.io/inject: "true"
    spec:
      containers:
        - name: demo
          image: debian:buster
          args:
            - -c
            - time cp -r /data/ /tmp
          command:
            - /bin/bash
          volumeMounts:
            - mountPath: /data
              name: demo
      restartPolicy: Never
      volumes:
        - name: demo
          persistentVolumeClaim:
            claimName: serverless-data
  backoffLimit: 4

Add app.poststart.fluid.io/inject: "true" to the labels section to enable Fluid to automatically configure the mount target check script.

Important

If you have configured the lifecycle.postStart handler in the container, the mount target check script configured by Fluid does not take effect. You need to manually configure mount target check.

Example 2: Argo workflows

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: serverless-workflow-
spec:
  entrypoint: serverless-workflow-example
  volumes:
  # Pass serverless-data as an argument to the serverless-workflow-example template
  # Same syntax as k8s Pod spec
  - 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"
       app.poststart.fluid.io/inject: "true"
      annotations:
         k8s.aliyun.com/eci-use-specs: ecs.s6-c1m2.xlarge
    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"
        app.poststart.fluid.io/inject: "true"
      annotations:
         k8s.aliyun.com/eci-use-specs: ecs.s6-c1m2.xlarge
    container:
      image: debian:buster
      command: [bash, -c]
      args: ["du -sh /data; md5sum /data/*"]
      volumeMounts:
      - name: datadir
        mountPath: /data

Add app.poststart.fluid.io/inject: "true" to the labels section of each container created by the Argo workflow to enable Fluid to automatically configure the mount target check script.

Important

If you have configured the lifecycle.postStart handler in the container, the mount target check script configured by Fluid does not take effect. You need to manually configure mount target check.

Configure elastic container instances to use Fluid to cache data

When you configure elastic container instances to use Fluid to cache data, you can specify memory, local disks, or the system disks of elastic container instances as the storage media. The storage media sorted based on their read speeds from high to low are: memory > local disks > system disks of elastic container instances. You can use local disks as the storage media only if the elastic container instances support local disks.

Example 1: Use memory to cache data

Note

When Fluid uses the memory of an elastic container instance to cache data, you can adjust the size of the cache on demand. The cache size is not subject to the limit that only up to 50% of the memory of an elastic container instance can be used.

The following code block shows the YAML template of a Fluid JindoRuntime CustomResource (CR) that uses memory to cache data:

apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: demo-dataset
spec:
  # The number of worker pods to be created. 
  replicas: 1
  podMetadata:
    labels:
      alibabacloud.com/eci: "true"
  worker:
    podMetadata:
      annotations:
        # The type of instance that is used to run the worker pods. 
        k8s.aliyun.com/eci-use-specs: ecs.g5.xlarge
        # Use an image cache to accelerate pod creation. 
        k8s.aliyun.com/eci-image-cache: "true"
  tieredstore:
    levels:
      - mediumtype: MEM # Use memory to cache data. 
        volumeType: emptyDir
        path: /dev/shm
        quota: 10Gi
        high: "0.99"
        low: "0.99"

In the preceding code block, the spec.tieredstore.levels.mediumtype parameter is set to MEM and the spec.tieredstore.levels.quota parameter is set to 10Gi. In this case, a memory cache of 10 GiB in size is configured for the worker pod. For more information about the procedures for creating a Fluid dataset and a runtime, see Accelerate Jobs.

Example 2: Use local disks to cache data

Fluid allows you to set the spec.tieredstore.levels.mediumtype parameter to specify the type of storage media to be used to cache data and set the spec.tieredstore.levels.quota parameter to specify the size of the cache. If you want to use a local disk to cache data, you also need to set the spec.tieredstore.levels.volumeSource.emptyDir.medium=LocalRaid0 parameter to mount the local disk of the elastic container instance.

Important

To use local disks to cache data, make sure that your elastic container instance is created from an Elastic Container Service (ECS) instance family that supports local disks. For more information, see Mount a local disk to a pod.

The following code block shows the YAML template of a Fluid JindoRuntime CR that uses a local disk to cache data:

apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: demo-dataset
spec:
  replicas: 2
  podMetadata:
    annotations:
      k8s.aliyun.com/eci-use-specs: ecs.g6e.4xlarge
      k8s.aliyun.com/eci-image-cache: "true"
    labels:
      alibabacloud.com/eci: "true"
  worker:
    podMetadata:
      annotations:
        k8s.aliyun.com/eci-use-specs: ecs.i2g.2xlarge
  tieredstore:
    levels:
      - mediumtype: SSD
        volumeType: emptyDir
        volumeSource:
          emptyDir:
            medium: LocalRaid0
        path: /cache
        quota: 20Gi
        high: "0.99"
        low: "0.99"

In the preceding code block, the spec.tieredstore.levels.quota parameter is set to 20Gi. In this case, a local disk cache of 20 GiB in size is configured for the worker pod. For more information about the procedures for creating a Fluid dataset and a runtime, see Accelerate Jobs.

Example 3: Use the system disks of elastic container instances to cache data

Fluid allows you to set the spec.tieredstore.levels.mediumtype parameter to specify the type of storage media to be used to cache data and set the spec.tieredstore.levels.quota parameter to specify the size of the cache. To use a system disk to cache data, you need to apply for temporary storage space for your elastic container instance. Fees are charged based on the size of the temporary storage space and usage duration. For more information, see Temporary storage space.

Important

If you use a system disk to cache data, the throughput of the cache may be limited by the throughput of the system disk. Consequently, the stability of the application is also affected. If you require higher input/output performance and stability, we recommend that you use memory or local disks to cache data.

The following code block shows the YAML template of a Fluid JindoRuntime CR that uses a system disk to cache data:

apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: demo-dataset
spec:
  # The number of worker pods to be created. 
  replicas: 1
  worker:
    podMetadata:
      annotations:
        # The type of instance that is used to run the worker pods. 
        k8s.aliyun.com/eci-use-specs: ecs.g5.xlarge
        # Use an image cache to accelerate pod creation. 
        k8s.aliyun.com/eci-image-cache: "true"
        # Specify 50 GiB of additional storage space, which equals the cache size specified in the tieredstore.levels.quota parameter.
        k8s.aliyun.com/eci-extra-ephemeral-storage: "50Gi"
  tieredstore:
    levels:
      # Use an SSD of 50 GiB in size to cache data for each worker pod. 
      - mediumtype: SSD
        volumeType: emptyDir
        path: /cache
        quota: 50Gi
        high: "0.99"
        low: "0.99"

In the preceding code block, a system disk cache of 50 GiB in size is configured for each worker pod. Therefore, you need to apply for 50 GiB of temporary storage space for each worker pod. For more information about the procedures for creating a Fluid dataset and a runtime, see Accelerate Jobs.

Runtime	Mount target check keyword
JindoRuntime	jindo
AlluxioRuntime	alluxio
JuiceFSRuntime	juicefs