Container Service for Kubernetes:Upgrade the ack-fluid component

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 and the ack-fluid component are installed. For more information, see Install the cloud-native AI suite.

  Note

  If the latest version of the ack-fluid component is already installed, you do not need to upgrade.

• A kubectl client is connected to the ACK Pro cluster. For more information, see Connect to a cluster using kubectl.

Step 1: Upgrade the ack-fluid component

1. Log on to the ACK console. In the left navigation pane, click Clusters.

2. On the Clusters page, click the name of the target cluster. In the navigation pane on the left, choose Applications > Cloud-native AI Suite.

3. On the Cloud-native AI Suite page, find the ack-fluid component and click Upgrade in the Actions column.

   Note

   If Upgrade is not displayed in the Actions column, the ack-fluid component is already the latest version.

4. In the Upgrade Component dialog box, click Confirm.

Step 2: Verify the ack-fluid component

After upgrading the ack-fluid component, verify its functionality by following these steps.

1. Select an appropriate Runtime type. Then, create and configure the Runtime resource. For more information, see Use JindoFS to accelerate access to OSS and Use EFC to accelerate access to NAS.

2. Create an application pod and mount it to a pre-upgrade Dataset custom resource (CR). Verify that the application pod can access data as expected.

3. Delete the application pod and the pre-upgrade Dataset CR. Verify that the Dataset CR, the corresponding Runtime CR, and all related cache resources are deleted successfully.

4. Create a new Dataset CR and a new Runtime CR. Verify that they bind successfully. You can check the resource status or run kubectl commands to confirm the binding status.

5. Create an application pod and mount it to the new Dataset CR. Verify that the application pod can access data as expected.

6. Delete the application pod and the new Dataset CR. Verify that the Dataset CR, the corresponding Runtime CR, and all related cache resources are deleted successfully.

FAQ

Upgrading to v1.0.2 or later

ack-fluid v1.0.2 modifies the Helm backend storage driver for the Fluid control plane component to enhance security. This change does not affect running workloads in your cluster. However, after you delete a Dataset resource, some related Helm Secrets may remain in the cluster. If you need to clean up these residual Secrets, you can run the following bash script to identify them.

Solution

Run the following script to identify residual Secrets in the cluster.

#!/bin/bash

tmpfile=$(mktemp)
kubectl get secret -A | awk '{if ($3 == "helm.sh/release.v1") print $1,$2}' > $tmpfile

fluid_chart_names=( "jindofs" "goosefs" "alluxio" "juicefs" "efc" "thin" "fluid-dataloader" "fluid-datamigrate" )

cat $tmpfile | while read -r x y
do
  chart_name=$(kubectl get secret -n $x $y -ojson | jq .data.release -r | base64 -d | base64 -d | gunzip - | jq .chart.metadata.name -r)
  if [[ " ${fluid_chart_names[*]} " =~ " ${chart_name} " ]]; then
    # e.g. sh.helm.release.v1.demo-dataset.v1
    dataset_name=${y#sh.helm.release.v1.}
    dataset_name=${dataset_name%.v1}
    kubectl get dataset -n $x $dataset_name &> /dev/null
    if [[ ! $? -eq 0 ]]; then
        echo "secret \"$x/$y\" is possibly not cleaned up. Use \"kubectl delete secret -n $x $y\" to clean it"
    fi
  fi
done

If residual Secrets exist, the output resembles the following:

secret "default/sh.helm.release.v1.demo-dataset.v1" is possibly not cleaned up. Use "kubectl delete secret -n default sh.helm.release.v1.demo-dataset.v1" to clean it
secret "default/sh.helm.release.v1.thin-demo.v1" is possibly not cleaned up. Use "kubectl delete secret -n default sh.helm.release.v1.thin-demo.v1" to clean it

The Secret name indicates the associated Dataset. For example, default/sh.helm.release.v1.demo-dataset.v1 refers to a Dataset named demo-dataset in the default namespace. Run the following command to check whether the Dataset still exists:

kubectl get dataset -n <namespace> <dataset_name>

If the output resembles the following, the Dataset has been deleted:

Error from server (NotFound): datasets.data.fluid.io "<dataset_name>" not found

Run the following command to delete the residual Secret:

kubectl delete secret <secret_name> -n <namespace>