Fluid利用Kubernetes的命名空間(Namespace)資源隔離特性,確保了數據集在計算任務與數據訪問層面的安全控制,有效滿足了跨團隊數據隔離的需求。更進一步,Fluid實現了跨命名空間的數據訪問及緩存資源共享,這意味著公開數據集能夠在多個團隊間復用,實現了單次緩存、多團隊共享的高效模式,增強了數據的利用效率與管理的靈活性,為研發團隊間的協同作業提供了便利。本文介紹如何配置跨命名空間共享數據集。
實現原理
ThinRuntime作為Fluid提供的一種可擴展的通用存儲系統實現,允許您以低代碼方式接入各類存儲系統,復用Fluid提供的數據編排管理、運行時平臺訪問接入核心能力。Fluid利用ThinRuntime,將源命名空間下的Dataset作為接入的存儲系統,與目標命名空間的Dataset關聯,使得同一份緩存運行時可以共享給不同命名空間的應用來使用。
前提條件
已創建一個非ContainerOS操作系統的ACK Pro版集群,且集群版本為1.18及以上。具體操作,請參見創建ACK Pro版集群。
重要ack-fluid組件暫不支持在ContainerOS操作系統上使用。
已安裝云原生AI套件并部署ack-fluid組件。
重要若您已安裝開源Fluid,請卸載后再部署ack-fluid組件。
已通過kubectl連接Kubernetes集群。具體操作,請參見通過kubectl工具連接集群。
步驟一:上傳測試數據到OSS Bucket
步驟二:創建共享的Dataset和緩存Runtime
使用JindoRuntime作為緩存運行時
創建
share
命名空間,用以創建共享的數據集和緩存Runtime。kubectl create ns share
執行以下命令,創建用于存儲OSS的訪問憑證的Secret。
kubectl apply -f-<<EOF apiVersion: v1 kind: Secret metadata: name: dataset-secret namespace: share stringData: fs.oss.accessKeyId: <YourAccessKey ID> fs.oss.accessKeySecret: <YourAccessKey Secret> EOF
其中,
fs.oss.accessKeyId
和fs.oss.accessKeySecret
是用來訪問OSS的AccessKey ID(AK)和AccessKey Secret(SK)。關于如何獲取AK和SK,請參見獲取AccessKey。創建并拷貝以下內容到shared-dataset.yaml文件中,用于創建一個Dataset和一個JindoRuntime來提供緩存服務。關于Dataset及JindoRuntime的詳細配置信息,請參見JindoFS加速OSS文件訪問。
# 創建一個Dataset,描述遠端存儲數據集和UFS的信息。 apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: shared-dataset namespace: share spec: mounts: - mountPoint: oss://<oss_bucket>/<bucket_dir> # 請替換為實際的OSS文件存儲地址。 options: fs.oss.endpoint: <oss_endpoint> # 請替換為實際的OSS endpoint地址。 name: hadoop path: "/" encryptOptions: - name: fs.oss.accessKeyId valueFrom: secretKeyRef: name: dataset-secret key: fs.oss.accessKeyId - name: fs.oss.accessKeySecret valueFrom: secretKeyRef: name: dataset-secret key: fs.oss.accessKeySecret --- # 創建一個JindoRuntime,啟動一個JindoFS的集群來提供緩存服務。 apiVersion: data.fluid.io/v1alpha1 kind: JindoRuntime metadata: name: shared-dataset namespace: share spec: replicas: 1 tieredstore: levels: - mediumtype: MEM path: /dev/shm quota: 4Gi high: "0.95" low: "0.7"
執行以下命令,創建JindoRuntime和Dataset。
kubectl apply -f shared-dataset.yaml
預期輸出:
dataset.data.fluid.io/shared-dataset created jindoruntime.data.fluid.io/shared-dataset created
輸出結果表明Dataset資源和JindoRuntime資源已被成功創建。
等待一段時間,執行以下命令,檢查Dataset和JindoRuntime資源的部署情況。
kubectl get dataset,jindoruntime -nshare
預期輸出:
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE dataset.data.fluid.io/shared-dataset 1.16GiB 0.00B 4.00GiB 0.0% Bound 4m1s NAME MASTER PHASE WORKER PHASE FUSE PHASE AGE jindoruntime.data.fluid.io/shared-dataset Ready Ready Ready 15m
輸出結果表明,Dataset已經與JindoRuntime綁定。
使用JuiceFSRuntime作為緩存運行時
創建
share
命名空間,用以創建共享的數據集和緩存Runtime。kubectl create ns share
執行以下命令,創建用于存儲OSS的訪問憑證的Secret。
kubectl apply -f-<<EOF apiVersion: v1 kind: Secret metadata: name: dataset-secret namespace: share type: Opaque stringData: token: <JUICEFS_VOLUME_TOKEN> access-key: <OSS_ACCESS_KEY> secret-key: <OSS_SECRET_KEY> EOF
其中,
access-key
和secret-key
是用來訪問OSS的AccessKey ID(AK)和AccessKey Secret(SK)。關于如何獲取AK和SK,請參見獲取AccessKey。創建并拷貝以下內容到shared-dataset.yaml文件中,用于創建一個Dataset和一個JuiceFSRuntime來提供緩存服務。
# 創建一個Dataset,描述遠端存儲數據集和UFS的信息。 apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: shared-dataset namespace: share spec: accessModes: ["ReadOnlyMany"] sharedEncryptOptions: - name: access-key valueFrom: secretKeyRef: name: dataset-secret key: access-key - name: secret-key valueFrom: secretKeyRef: name: dataset-secret key: secret-key - name: token valueFrom: secretKeyRef: name: dataset-secret key: token mounts: - name: <JUICEFS_VOLUME_NAME> mountPoint: juicefs:/// # 文件系統的掛載點為juicefs:///。 options: bucket: https://<OSS_BUCKET_NAME>.oss-<REGION_ID>.aliyuncs.com # 請替換為Bucket實際的URL地址,例如https://mybucket.oss-cn-beijing-internal.aliyuncs.com --- # 創建一個JuiceFSRuntime,啟動一個JuiceFS的集群來提供緩存服務。 apiVersion: data.fluid.io/v1alpha1 kind: JuiceFSRuntime metadata: name: shared-dataset namespace: share spec: replicas: 1 tieredstore: levels: - mediumtype: MEM path: /dev/shm quota: 1Gi high: "0.95" low: "0.7"
執行以下命令,創建JuiceFSRuntime和Dataset。
kubectl apply -f shared-dataset.yaml
預期輸出:
dataset.data.fluid.io/shared-dataset created juicefsruntime.data.fluid.io/shared-dataset created
輸出結果表明Dataset資源和JuiceFSRuntime資源已被成功創建。
等待一段時間,執行以下命令,檢查Dataset和JuiceFSRuntime資源的部署情況。
kubectl get dataset,juicefsruntime -nshare
預期輸出:
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE dataset.data.fluid.io/shared-dataset 2.32GiB 0.00B 4.00GiB 0.0% Bound 3d16h NAME WORKER PHASE FUSE PHASE AGE juicefsruntime.data.fluid.io/shared-dataset 3m50s
步驟三:創建引用的Dataset和Pod
創建一個名為
ref
的命名空間,以創建引用的數據集ref-dataset
。kubectl create ns ref
創建并拷貝以下內容到ref-dataset.yaml文件中,實現在
ref
命名空間下的ref-dataset
里,就可以訪問到存儲在其他命名空間中(本示例為share
命名空間)的特定數據集。重要Fluid限制了數據集只能被掛載到唯一的一個指定路徑下,且mountPoint格式必須為
dataset://
。如果mountPoint
為其它格式時,會導致Dataset創建失敗,以及spec
中的字段無效。apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: ref-dataset namespace: ref spec: mounts: - mountPoint: dataset://share/shared-dataset
mountPoint
參數說明如下:dataset://
:是協議前綴,表明這是一個數據集的引用。share
:被引用數據集所在的命名空間名稱,說明了數據集的來源位置為share
命名空間。shared-dataset
:是被引用的實際數據集的名稱。
執行以下命令,將
ref-dataset.yaml
文件中的定義應用到集群中。kubectl apply -f ref-dataset.yaml
創建并拷貝以下內容到app.yaml文件中,以在
ref
命名空間下,創建Pod引用ref-dataset
。apiVersion: v1 kind: Pod metadata: name: nginx namespace: ref spec: containers: - name: nginx image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6 command: - "bash" - "-c" - "sleep inf" volumeMounts: - mountPath: /data name: ref-data volumes: - name: ref-data persistentVolumeClaim: claimName: ref-dataset
執行以下命令,將
app.yaml
應用到集群中。kubectl apply -f app.yaml
執行以下命令,查看
ref
命名空間下Pod的狀態。kubectl get pods -n ref -o wide
如果Pod已處于Running狀態,說明Pod已正常運行。
步驟三:驗證數據的共享和緩存效果
執行以下命令,查看
share
和ref
命名空間下的Pod信息。kubectl get pods -n share kubectl get pods -n ref
預期輸出:
# share命名快哦空間下的Pod。 NAME READY STATUS RESTARTS AGE shared-dataset-jindofs-fuse-ftkb5 1/1 Running 0 44s shared-dataset-jindofs-master-0 1/1 Running 0 9m13s shared-dataset-jindofs-worker-0 1/1 Running 0 9m13s # ref命名空間下的Pod。 NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 118s
輸出結果表明,在
share
命名空間中,有三個與數據集相關的Pod正在運行。而在ref
命名空間下,只有一個名為nginx
的Pod在運行,并不存在與數據集相關的Pod。驗證共享緩存效果。
執行以下命令,進入到名為
nginx
的Pod中。kubectl exec nginx -n ref -it -- sh
共享緩存驗證。
執行以下命令,列出
/data
目錄下的內容。其中,/data
是ref
命名空間下的Dataset的路徑。du -sh /data/wwm_uncased_L-24_H-1024_A-16.zip
預期輸出:
1.3G /data/wwm_uncased_L-24_H-1024_A-16.zip
輸出結果表明盡管
config.json
文件實際存儲在share
命名空間的數據集中,但通過Fluid的機制,ref
命名空間下的Pod(例如nginx
)能夠無障礙地訪問到這些數據。測試緩存效果。
說明以下內容為本次的測試結果,具體讀取文件時長,請以具體情況為準。
# 首次讀取文件。 sh-4.4# time cat /data/wwm_uncased_L-24_H-1024_A-16.zip > /dev/null real 0m1.166s user 0m0.007s sys 0m1.154s # 再次讀取文件,共享緩存生效 sh-4.4# time cat /data/wwm_uncased_L-24_H-1024_A-16.zip > /dev/null real 0m0.289s user 0m0.011s sys 0m0.274s
測試的輸出結果顯示,首次讀取文件用了1.166s,再次讀取文件用了0.289s,讀取文件時長縮短了0.877s,表明共享緩存已生效。