在應用Pod的生命週期內,FUSE守護進程可能會因為異常情況崩潰,導致應用Pod無法正常訪問資料。本文檔介紹如何開啟並使用FUSE掛載點自愈功能,允許在應用Pod不重啟的前提下恢複應用的資料訪問。
前提條件
已建立一個非ContainerOS作業系統的ACK Pro版叢集,且叢集版本為1.18及以上。具體操作,請參見建立ACK Pro版叢集。
重要ack-fluid組件暫不支援在ContainerOS作業系統上使用。
已安裝雲原生AI套件並部署ack-fluid組件。
重要若您已安裝開源Fluid,請卸載後再部署ack-fluid組件。
未安裝雲原生AI套件:部署Fluid,開啟資料緩衝加速。具體操作,請參見安裝雲原生AI套件。
已安裝雲原生AI套件:在Container Service管理主控台的雲原生AI套件頁面部署ack-fluid。
已部署ACK虛擬節點(Virtual Node)。具體操作,請參見通過部署ACK虛擬節點群組件建立ECI Pod。
已通過kubectl串連Kubernetes叢集。具體操作,請參見通過kubectl工具串連叢集。
已開通阿里雲Object Storage Service服務和儲存空間(Bucket)。具體操作,請參見開通OSS服務和控制台建立儲存空間。
功能概述
使用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緩衝系統。
使用以下內容,建立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。執行以下命令,建立Secret。
kubectl create -f secret.yaml使用以下內容,建立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"相關參數解釋如下表所示:
參數
說明
mountPoint
oss://<oss_bucket>/<bucket_dir>表示掛載UFS的路徑,路徑中不需要包含endpoint資訊。
fs.oss.endpoint
OSS Bucket的Endpoint資訊,公網或私網地址均支援。更多資訊,請參見OSS地區和訪問網域名稱。
replicas
表示建立JindoFS叢集的Worker數量。
mediumtype
表示緩衝類型。在建立JindoRuntime模板範例時,JindoFS暫時只支援HDD/SSD/MEM中的其中一種緩衝類型。
path
表示儲存路徑,暫時只支援單個路徑。當選擇MEM做緩衝時,需指定一個本地路徑來儲存Log等檔案。
quota
表示緩衝最大容量,單位GB。
high
表示儲存容量上限大小。
low
表示儲存容量下限大小。
執行以下命令,建立Dataset和JindoRuntime資源。
kubectl create -f dataset.yaml
步驟三:建立應用Pod掛載Fluid資料集
本文以一個Nginx容器為例,嘗試掛載Fluid資料集並訪問其中的檔案資料。
使用以下內容,建立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掛載點自愈能力。執行以下命令,建立應用程式容器。
kubectl create -f app.yaml執行以下命令,查看應用程式容器狀態。
kubectl get pod demo-app如果看到容器STATUS欄位已經進入Running狀態,則說明應用程式容器已經成功啟動。
NAME READY STATUS RESTARTS AGE demo-app 1/1 Running 0 16s
步驟四:驗證FUSE掛載點自愈功能
執行以下命令,登入到應用程式容器中並執行循環性訪問檔案元資訊的指令碼,該指令碼會每隔1秒鐘列舉掛載的Fluid資料集中的檔案。
kubectl exec -it demo-app -- bash -c 'while true; do ls -l /data; sleep 1; done'保持上述指令碼後台運行,執行以下命令,類比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'查看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自愈功能
已建立一個非ContainerOS作業系統的ACK Serverless叢集Pro版,且叢集版本為1.18及以上。具體操作,請參見建立ACK Serverless叢集。
步驟一:建立Fluid資料集
本文以加速OSSObject Storage Service中的檔案為例,部署JindoFS緩衝系統。
使用以下內容,建立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。執行以下命令,建立Secret。
kubectl create -f secret.yaml使用以下內容,建立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"相關參數解釋如下表所示:
參數
說明
mountPoint
oss://<oss_bucket>/<bucket_dir>表示掛載UFS的路徑,路徑中不需要包含endpoint資訊。
fs.oss.endpoint
OSS Bucket的Endpoint資訊,公網或私網地址均支援。更多資訊,請參見OSS地區和訪問網域名稱。
replicas
表示建立JindoFS叢集的Worker數量。
mediumtype
表示緩衝類型。在建立JindoRuntime模板範例時,JindoFS暫時只支援HDD/SSD/MEM中的一種緩衝類型。
path
表示儲存路徑,暫時只支援單個路徑。當選擇MEM做緩衝時,需指定一個本地路徑來儲存Log等檔案。
quota
表示緩衝最大容量,單位GB。
high
表示儲存容量上限大小。
low
表示儲存容量下限大小。
執行以下命令,建立Dataset和JindoRuntime資源。
kubectl create -f dataset.yaml
步驟二:建立應用Pod掛載Fluid資料集
本文以一個Nginx容器為例,嘗試掛載Fluid資料集並訪問其中的檔案資料。
使用以下內容,建立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生效。執行以下命令,建立應用Pod。
kubectl create -f app.yaml執行以下命令,查看應用程式容器狀態。
kubectl get pod demo-app如果看到容器STATUS欄位已經進入Running狀態,則說明應用程式容器已經成功啟動。
NAME READY STATUS RESTARTS AGE demo-app 2/2 Running 0 110s
步驟三:驗證FUSE掛載點自愈功能
執行以下命令,登入到應用程式容器中並執行循環性訪問檔案元資訊的指令碼,該指令碼會每隔1秒鐘列舉掛載的Fluid資料集中的檔案。
kubectl exec -it demo-app -c demo -- bash -c 'while true; do ls -l /data; sleep 1; done'保持上述指令碼後台運行,執行以下命令,類比FUSE組件異常崩潰的情況。
# 類比FUSE Pod異常崩潰情境 kubectl exec -it demo-app -c fluid-fuse-0 -- bash -c 'kill 1'查看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