Container Service for Kubernetes：使用FUSE掛載點自愈功能

前提條件

• 已建立一個非ContainerOS作業系統的ACK Pro版叢集或ACK Serverless叢集Pro版，且叢集版本為1.18及以上。具體操作，請參見建立ACK Pro版叢集、建立ACK Serverless Pro叢集。

• 已安裝雲原生AI套件並部署ack-fluid組件，且ack-fluid版本為1.0.9及以上。

  重要

  • 若您已安裝開源Fluid，請卸載後再部署ack-fluid組件。

  • 未安裝雲原生AI套件：安裝時開啟Fluid資料加速。具體操作，請參見安裝雲原生AI套件。

  • 已安裝雲原生AI套件：在Container Service管理主控台的雲原生AI套件頁面部署ack-fluid。

• 已開通阿里雲Object Storage Service服務，並建立儲存空間（Bucket）。具體操作，請參見開通OSS服務和控制台建立儲存空間。

• 已通過kubectl串連Kubernetes叢集。具體操作，請參見通過kubectl工具串連叢集。

功能概述

使用Fluid資料集（Dataset）的應用Pod通過FUSE檔案系統訪問分布式緩衝系統中的資料，每一個FUSE檔案系統對應一個FUSE守護進程（Daemon），該進程負責處理FUSE檔案系統上的任何檔案訪問請求。

在應用Pod的生命週期內，FUSE守護進程可能會因為異常情況（例如：記憶體使用量超出上限被殺死）崩潰，導致應用Pod訪問檔案時出現“端點未串連”（“Transport Endpoint is Not Connected”）錯誤。為瞭解決此類錯誤，通常需要手動重啟應用程式容器或重建應用Pod以恢複FUSE檔案系統的訪問。

Fluid支援FUSE檔案系統掛載點的自愈功能。通過周期性查詢節點各應用Pod掛載的FUSE檔案系統狀態，Fluid支援在不重啟應用程式容器和不重建應用Pod的前提下，恢複應用Pod內的檔案訪問。

使用限制

• 該功能涉及的自愈過程存在一定的延遲，不支援對業務應用的無感自愈。業務應用需要容忍檔案訪問失敗的情況，並持續重試直至自愈完成。

• 該功能僅支援與唯讀類型的資料集共同使用，如果叢集中包含任意可讀寫的資料集，必須確保該功能處於關閉狀態，以避免預期外的資料寫入問題。

• 該功能不支援應用Pod通過subPath方式掛載資料集對應的儲存卷聲明（PVC）。

• FUSE掛載點自愈操作必須在FUSE守護進程自動重啟後執行，由於FUSE守護進程運行在容器中，當FUSE守護進程頻繁崩潰時，Kubernetes重啟該容器的間隔時間將會指數級增長，這將影響到FUSE掛載點自愈的恢復。

在ACK叢集環境中使用FUSE自愈功能

步驟一：開啟FUSE掛載點自愈（Feature Gate）

使用以下命令開啟FUSE掛載點自愈功能：

kubectl get ds -n fluid-system csi-nodeplugin-fluid -oyaml | sed 's/FuseRecovery=false/FuseRecovery=true/g' | kubectl apply -f -

預期輸出如下：

daemonset.apps/csi-nodeplugin-fluid configured

執行以下命令查看FUSE掛載點自愈門控是否已經正常開啟：

kubectl get ds -n fluid-system csi-nodeplugin-fluid -oyaml | grep '\- \-\-feature-gates='

如果輸出如下結果，則表示FUSE掛載點自愈門控已經成功開啟：

- --feature-gates=FuseRecovery=true

步驟二：建立Fluid資料集

本文以加速OSSObject Storage Service中的檔案為例，部署JindoFS緩衝系統。

1. 使用以下內容，建立secret.yaml檔案

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
stringData:
  fs.oss.accessKeyId: <YOUR_ACCESS_KEY_ID>
  fs.oss.accessKeySecret: <YOUR_ACCESS_KEY_SECRET>

其中，fs.oss.accessKeyId和fs.oss.accessKeySecret是用來訪問OSS的AccessKey ID和AccessKey Secret。

2. 執行以下命令，建立Secret。

kubectl create -f secret.yaml

3. 使用以下內容，建立dataset.yaml檔案。

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

4. 執行以下命令，建立Dataset和JindoRuntime資源。

kubectl create -f dataset.yaml

步驟三：建立應用Pod掛載Fluid資料集

本文以一個Nginx容器為例，嘗試掛載Fluid資料集並訪問其中的檔案資料。

1. 使用以下內容，建立app.yaml檔案。

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
  labels:
    fuse.serverful.fluid.io/inject: "true"
spec:
  containers:
    - name: demo
      image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
      volumeMounts:
        - mountPath: /data
          name: data-vol
  volumes:
    - name: data-vol
      persistentVolumeClaim:
        claimName: demo-dataset   # 與Dataset資源名稱一致

其中fuse.serverful.fluid.io/inject=true的標籤用於為該Pod啟用FUSE掛載點自愈能力。

2. 執行以下命令，建立應用程式容器。

kubectl create -f app.yaml

3. 執行以下命令，查看應用程式容器狀態。

kubectl get pod demo-app

如果看到容器STATUS欄位已經進入Running狀態，則說明應用程式容器已經成功啟動。

NAME       READY   STATUS    RESTARTS   AGE
demo-app   1/1     Running   0          16s

步驟四：驗證FUSE掛載點自愈功能

1. 執行以下命令，登入到應用程式容器中並執行循環性訪問檔案元資訊的指令碼，該指令碼會每隔1秒鐘列舉掛載的Fluid資料集中的檔案。

kubectl exec -it demo-app -- bash -c 'while true; do ls -l /data; sleep 1; done'

2. 保持上述指令碼後台運行，執行以下命令，類比FUSE組件異常崩潰的情況。

# 擷取demo-pod所在節點
demo_pod_node_name=$(kubectl get pod demo-app -ojsonpath='{.spec.nodeName}')
# 擷取與demo-pod相同節點的FUSE Pod名字
fuse_pod_name=$(kubectl get pod --field-selector spec.nodeName=$demo_pod_node_name --selector role=jindofs-fuse,release=demo-dataset -oname)
# 類比FUSE Pod異常崩潰情境
kubectl exec -it $fuse_pod_name -- bash -c 'kill 1'

3. 查看demo-app中執行的指令碼輸出結果，如果觀察到類似如下結果，則說明FUSE掛載點成功自愈。

...
total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt
total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt
ls: cannot access '/data/': Transport endpoint is not connected
ls: cannot access '/data/': Transport endpoint is not connected
ls: cannot access '/data/': Transport endpoint is not connected
ls: cannot access '/data/': Transport endpoint is not connected
ls: cannot access '/data/': Transport endpoint is not connected
ls: cannot access '/data/': Transport endpoint is not connected
ls: cannot access '/data/': Transport endpoint is not connected
ls: cannot access '/data/': Transport endpoint is not connected
total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt
total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt
...

在Serverless環境中使用FUSE自愈功能

步驟一：建立Fluid資料集

本文以加速OSSObject Storage Service中的檔案為例，部署JindoFS緩衝系統。

1. 使用以下內容，建立secret.yaml檔案

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
stringData:
  fs.oss.accessKeyId: <YOUR_ACCESS_KEY_ID>
  fs.oss.accessKeySecret: <YOUR_ACCESS_KEY_SECRET>

其中，fs.oss.accessKeyId和fs.oss.accessKeySecret是用來訪問OSS的AccessKey ID和AccessKey Secret。

2. 執行以下命令，建立Secret。

kubectl create -f secret.yaml

3. 使用以下內容，建立dataset.yaml檔案。

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

4. 執行以下命令，建立Dataset和JindoRuntime資源。

kubectl create -f dataset.yaml

步驟二：建立應用Pod掛載Fluid資料集

本文以一個Nginx容器為例，嘗試掛載Fluid資料集並訪問其中的檔案資料。

1. 使用以下內容，建立app.yaml檔案。

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
  labels:
    alibabacloud.com/fluid-sidecar-target: eci
  annotations:
    # 禁用虛擬節點調度功能。
    alibabacloud.com/burst-resource: eci_only
    # 開啟FUSE掛載點自愈功能
    alibabacloud.com/fuse-recover-policy: auto
spec:
  containers:
    - name: demo
      image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
      volumeMounts:
        - mountPath: /data
          name: data-vol
  volumes:
    - name: data-vol
      persistentVolumeClaim:
        claimName: demo-dataset  # 與Dataset資源名稱一致

其中alibabacloud.com/fuse-recover-policy=auto的註解用於為該Pod啟用FUSE掛載點自愈能力，該註解僅對運行於Serverless環境的應用Pod生效。

2. 執行以下命令，建立應用Pod。

kubectl create -f app.yaml

3. 執行以下命令，查看應用程式容器狀態。

kubectl get pod demo-app

如果看到容器STATUS欄位已經進入Running狀態，則說明應用程式容器已經成功啟動。

NAME       READY   STATUS    RESTARTS   AGE
demo-app   2/2     Running   0          110s

步驟三：驗證FUSE掛載點自愈功能

1. 執行以下命令，登入到應用程式容器中並執行循環性訪問檔案元資訊的指令碼，該指令碼會每隔1秒鐘列舉掛載的Fluid資料集中的檔案。

kubectl exec -it demo-app -c demo -- bash -c 'while true; do ls -l /data; sleep 1; done'

2. 保持上述指令碼後台運行，執行以下命令，類比FUSE組件異常崩潰的情況。

# 類比FUSE Pod異常崩潰情境
kubectl exec -it demo-app -c fluid-fuse-0 -- bash -c 'kill 1'

3. 查看demo-app中執行的指令碼輸出結果，如果觀察到類似如下結果，則說明FUSE掛載點成功自愈。

total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt
total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt
ls: cannot access '/data/demo2': Transport endpoint is not connected
ls: cannot access '/data/demo2': Transport endpoint is not connected
ls: cannot access '/data/demo2': Transport endpoint is not connected
ls: cannot access '/data/demo2': Transport endpoint is not connected
total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt
total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt