Container Service for Kubernetes：通過配置JindoRuntime實現Master組件狀態持久化儲存

功能介紹

JindoFS來源於阿里雲EMR團隊，是基於C++實現的支撐Dataset資料管理和資料緩衝的執行引擎，同時支援對OSS、OSS-HDFS和PVC等多種資料來源提供資料快取服務。更多資訊，請參見JindoData概述。

JindoFS採用Master-Worker架構，Master組件和Worker組件均容器化運行於叢集中，其中Master組件負責記錄快取資料元資訊和掛載點資訊等，Worker組件負責維護快取資料資訊。當運行Master組件的容器重啟或重新調度時，Master組件緩衝的資料元資訊和掛載點資訊可能會丟失，從而導致JindoFS分布式緩衝叢集不可用。您可以通過配置Fluid JindoRuntime，使JindoFS Master組件將元資訊持久化儲存於Kubernetes儲存卷中，提高JindoFS分布式緩衝叢集的可用性。

前提條件

• 已建立ACK叢集Pro版，且叢集版本為1.18及以上。具體操作，請參見建立ACK Pro版叢集。

• 已安裝雲原生AI套件並部署ack-fluid組件，且ack-fluid版本為1.0.5及以上。具體操作，請參見安裝雲原生AI套件。

  重要

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

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

• 已建立OSS儲存空間（Bucket）並上傳檔案，且為RAM使用者授予訪問該Bucket的許可權。具體操作，請參見建立儲存空間和添加Bucket Policy。

步驟一：準備雲端硬碟儲存卷

1. 建立pvc.yaml檔案，配置雲端硬碟儲存卷PVC。

   說明

   如果您需要為雲端硬碟儲存卷PVC配置更多參數，請參見通過kubectl命令列使用雲端硬碟動態儲存裝置卷。

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: demo-jindo-master-meta
   spec:
     accessModes:
       - ReadWriteOnce
     storageClassName: alicloud-disk-topology-alltype
     resources:
       requests:
         storage: 30Gi

2. 執行以下命令，建立PVC資源。

   kubectl create -f pvc.yaml

   預期輸出：

   persistentvolumeclaim/demo-jindo-master-meta created

步驟二：建立Dataset和JindoRuntime

1. 建立secret.yaml檔案，儲存用於RAM訪問OSS Bucket的AccessKeyId（AK）和AccessKeySecret（SK）。

   apiVersion: v1
   kind: Secret
   metadata:
     name: access-key
   stringData:
     fs.oss.accessKeyId: ****** # 請輸入AccessKeyId。
     fs.oss.accessKeySecret: ****** # 請輸入AccessKeySecret。

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

   kubectl create -f secret.yaml

   預期輸出：

   secret/access-key created

3. 建立dataset.yaml檔案，配置Fluid Dataset資源和Fluid JindoRuntime資源的參數資訊。

   apiVersion: data.fluid.io/v1alpha1
   kind: Dataset
   metadata:
     name: demo
   spec:
     mounts: 
       - mountPoint: oss://<OSS_BUCKET>/<BUCKET_DIR>
         name: demo
         path: /
         options:
           fs.oss.endpoint: <OSS_BUCKET_ENDPOINT>
         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
   ---
   apiVersion: data.fluid.io/v1alpha1
   kind: JindoRuntime
   metadata:
     name: demo
   spec:
     replicas: 2
     volumes:
       - name: meta-vol
         persistentVolumeClaim:
           claimName: demo-jindo-master-meta
     master:
       volumeMounts:
         - name: meta-vol
           mountPath: /root/jindofsx-meta
       properties:
         namespace.meta-dir: "/root/jindofsx-meta"
     tieredstore:
       levels:
         - mediumtype: MEM
           path: /dev/shm
           volumeType: emptyDir
           quota: 12Gi
           high: "0.99"
           low: "0.99"

   與本功能相關的關鍵參數說明如下：

   參數		說明
   JindoRuntime	volumes	配置JindoRuntime各組件可掛載的儲存卷資訊。您需要選擇步驟一：準備雲端硬碟儲存卷中建立的雲端硬碟儲存卷PVC。
   	master.volumeMounts	配置運行JindoRuntime Master組件的容器所掛載的儲存卷和掛載路徑。
   	master.properties	配置JindoRuntime Master組件的詳細參數資訊。為啟用Master組件的元資訊持久化儲存能力，需指定namespace.meta-dir: <path>，其中<path>為master.volumeMounts中指定的儲存卷掛載路徑（即mountPath參數值）。

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

   kubectl create -f dataset.yaml

   預期輸出：

   dataset.data.fluid.io/demo created
   jindoruntime.data.fluid.io/demo created

5. 執行以下命令，查看Dataset部署情況。

   kubectl get dataset

   預期輸出：

   NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE
   demo 531.89MiB      0.00B  24.00GiB       0.0%              Bound 5m35s

   PHASE欄位變為Bound狀態，表明Dataset和JindoRuntime已部署成功。Fluid將自動為Bound狀態的Dataset建立同名PVC，應用Pod可通過掛載該PVC，訪問Dataset掛載點（Dataset.spec.mountPoint）中指定的資料。

步驟三：驗證Master組件狀態持久化儲存功能

在本步驟中，通過對節點添加汙點類比運行Master組件的Pod重新調度的情境，以驗證本功能是否正確配置並生效。

1. 建立pod.yaml檔案，用於掛載PVC。

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx
   spec:
     containers:
       - name: nginx
         image: registry.openanolis.cn/openanolis/nginx:1.14.1-8.6
         volumeMounts:
           - mountPath: /data
             name: data-vol
     volumes:
       - name: data-vol
         persistentVolumeClaim:
           claimName: demo

2. 執行以下命令，在Kubernetes叢集中部署Nginx應用。

   kubectl create -f pod.yaml

   預期輸出：

   pod/nginx created

3. 執行以下命令，從應用Pod中訪問資料。

   kubectl exec -it nginx -- ls /data

   預期輸出Dataset掛載點（Dataset.spec.mountPoint）中指定的OSS檔案系統中的資料。

4. 執行以下命令，擷取運行JindoFS Master組件的Pod所在的節點。

   master_node=$(kubectl get pod -o wide | awk '/demo-jindofs-master-0/ {print $7}')

5. 執行以下命令，通過汙點阻止新的Pod調度至步驟4中查詢的節點。

   kubectl taint node $master_node test-jindofs-master=reschedule:NoSchedule

   預期輸出：

   node/cn-beijing.192.168.xx.xx tainted

6. 執行以下命令，刪除並自動重建JindoFS Master組件的Pod。

   kubectl delete pod demo-jindofs-master-0

   預期輸出：

   pod "demo-jindofs-master-0" deleted 

   此時，重建的Pod（demo-jindofs-master-0）將會被調度到叢集中的另一個節點上。但是由於運行JindoFS Master組件的Pod掛載了儲存卷，因此Master組件可以通過儲存卷恢複到Pod被重建前的狀態。

   說明

   由於雲端硬碟儲存卷不支援跨可用性區域掛載，因此在使用雲端硬碟作為持久化儲存時，重建的Pod只能被調度到同可用性區域的其他節點上。請確保叢集中至少包含另一個與重建前Pod同可用性區域的ECS節點。

7. 執行以下命令，重建應用Pod。

   kubectl delete -f pod.yaml && kubectl create -f pod.yaml

   預期輸出：

   pod "nginx" deleted
   pod/nginx created

8. 執行以下命令，從重建後的應用Pod中再次訪問資料。

   kubectl exec -it nginx -- ls /data

   預期輸出Dataset掛載點（Dataset.spec.mountPoint）中指定的OSS檔案系統中的資料。

步驟四：環境清理

1. 執行以下命令，刪除Pod。

   kubectl delete -f pod.yaml

   預期輸出：

   pod "nginx" deleted

2. 執行以下命令，刪除為節點添加的汙點。

   kubectl taint node $master_node test-jindofs-master-

   預期輸出：

   node/cn-beijing.192.168.xx.xx untainted

3. （可選）依次執行以下命令，清理雲端硬碟儲存卷資源。

   重要

   • 本樣本中建立的雲端硬碟儲存卷將持續產生費用。如果您不再需要使用該資料加速功能，請及時清理環境。關於雲端硬碟儲存卷產生的費用，請參見雲端硬碟儲存卷概述。

   • 清理前，確保沒有正在使用該資料集並進行I/O操作的應用Pod。

   kubectl delete -f dataset.yaml
   kubectl delete -f pvc.yaml