在ACK中使用ossfs 2.0掛載動態OSS儲存卷 - Container Service for Kubernetes

對於需要持久化儲存或在多Pod間共用資料的應用，可通過動態PV將OSS Bucket掛載為 ossfs 2.0 儲存卷。該方式通過 StorageClass 作為模板自動建立並綁定PV，不僅簡化了儲存管理，還讓應用能像訪問本地檔案一樣，通過標準的POSIX介面讀寫OSS資料。

相較於ossfs 1.0，ossfs 2.0在順序讀寫效能上表現優異，可以更好地利用OSS的高頻寬優勢。

ossfs 2.0的效能說明，請參見ossfs 2.0用戶端壓測效能。

流程指引

在ACK叢集中掛載ossfs 2.0動態儲存裝置卷主要流程如下。

確定掛載儲存卷時的鑒權方式（支援存取金鑰（AccessKey）和RRSA）並準備訪問憑證。
建立StorageClass：定義一個儲存模板，其中包含OSS Bucket資訊、掛載參數和鑒權配置。
建立PVC：“申請”使用OSS儲存資源。PVC會根據指定的StorageClass，自動觸發PV的建立和綁定。
在應用中掛載：將PVC作為儲存卷掛載到容器的指定目錄中。

適用範圍

叢集為1.26及以上，CSI組件（csi-plugin和csi-provisioner）版本為v1.33.1及以上。如需升級叢集，請參見手動升級叢集；如需升級組件，請參見升級CSI組件。
已建立OSS Bucket，且Bucket與叢集屬於同一阿里雲帳號。
如需跨帳號掛載OSS Bucket，建議通過RRSA鑒權方式實現，請參見如何跨帳號掛載OSS Bucket？。

步驟一：選擇鑒權方式（RRSA或AccessKey）並準備訪問憑證

為確保叢集能夠安全、合規地訪問OSS Bucket資源，需先配置一種鑒權機制。

RRSA鑒權方式：為 Pod 動態授予臨時、自動輪換的 RAM 角色，實現應用層級的精微調權限隔離，安全性較高。
AccessKey鑒權方式：將靜態、長期的金鑰儲存區在 Secret 中。配置簡單，但安全性較低。

重要

在1.26及以上版本的叢集中，為避免因AccessKey輪轉導致的ossfs重掛載和業務重啟，建議使用RRSA鑒權方式。
本樣本中叢集與OSS Bucket處於同一阿里雲帳號下。如需跨帳號掛載OSS Bucket，建議使用RRSA鑒權方式。

RRSA方式

1. 在叢集中啟用RRSA

在ACK叢集列表頁面，單擊目的地組群名稱，選擇集群信息。
在基本資料頁簽的安全與審計地區，單擊RRSA OIDC右側的開啟，按照頁面提示在業務低峰期完成RRSA的啟用。
當叢集狀態由更新中變為運行中，表明RRSA已成功啟用。
重要
啟用RRSA功能後，叢集內新建立的ServiceAccount Token的最大有效期間將限制為12小時。

2. 建立RAM角色並授權

建立一個供 Pod 扮演的 RAM 角色，以通過 RRSA 鑒權來訪問 OSS 儲存卷。

展開查看步驟

建立一個RAM角色。

訪問RAM控制台-建立角色頁面，選擇信任主體類型為身份供應商，然後切換編輯器，進入可視化編輯頁面。

選擇主體為身份供應商，單擊編輯，參見以下說明完成配置。

主要配置如下，其餘參數保持預設即可。詳見建立OIDC身份供應商的RAM角色。

配置項	描述
身份供應商類型	OIDC。
身份供應商	選擇`ack-rrsa-<cluster_id>`。其中，`<cluster_id>`為叢集ID。
條件	手動添加oidc:sub。條件鍵：選擇oidc:sub。運算子：選擇StringEquals。條件值：預設輸入`system:serviceaccount:ack-csi-fuse:csi-fuse-ossfs`。 `ack-csi-fuse`：ossfs用戶端所在的命名空間，不支援自訂。 `csi-fuse-ossfs`：ServiceAccount名稱。如需修改，請參見如何在RRSA鑒權方式中使用指定的ARNs或ServiceAccount？。
角色名稱	本樣本為demo-role-for-rrsa。

建立權限原則。
本樣本遵循最小許可權原則，建立一個自訂權限原則，授予訪問目標OSS Bucket的許可權（OSS唯讀許可權或OSS讀寫權限）。
1. 訪問RAM控制台-建立權限原則頁面，切換為指令碼編輯，按照頁面提示配置策略指令碼。
  若已有授權OSS許可權的RAM角色，修改其信任策略即可複用，請參見使用已存在的RAM角色並授權。
  OSS唯讀權限原則
  替換<myBucketName>為實際Bucket名稱。
  { "Statement": [ { "Action": [ "oss:Get*", "oss:List*" ], "Effect": "Allow", "Resource": [ "acs:oss:*:*:<myBucketName>", "acs:oss:*:*:<myBucketName>/*" ] } ], "Version": "1" }
  OSS讀寫權限策略
  替換<myBucketName>為實際Bucket名稱。
  { "Statement": [ { "Action": "oss:*", "Effect": "Allow", "Resource": [ "acs:oss:*:*:<myBucketName>", "acs:oss:*:*:<myBucketName>/*" ] } ], "Version": "1" }
2. （可選）使用KMS託管的指定CMK ID加密OSS Object時，還需為該角色配置KMS許可權，詳見使用KMS託管的指定CMK ID加密。
將該策略授權給RAM角色。
1. 訪問RAM控制台-角色頁面，在RAM角色列表的操作列，單擊目標角色對應的新增授權。
2. 在權限原則地區，按照頁面提示搜尋並選擇上一步建立的權限原則，並完成授權的新增。

AccessKey方式

建立具有OSS存取權限的RAM使用者並擷取其AccessKey，使其擁有OSS Bucket的操作許可權。

建立RAM使用者（如有，可跳過）。
訪問RAM控制台-建立使用者頁面，按照頁面提示完成RAM使用者的建立，如登入名稱稱、密碼等。

建立權限原則。

本樣本遵循最小許可權原則，建立一個自訂權限原則，授予訪問目標OSS Bucket的許可權（OSS唯讀許可權或OSS讀寫權限）。

訪問RAM控制台-建立權限原則頁面，切換為指令碼編輯，按照頁面提示配置策略指令碼。

OSS唯讀權限原則

替換<myBucketName>為實際Bucket名稱。

{
    "Statement": [
        {
            "Action": [
                "oss:Get*",
                "oss:List*"
            ],
            "Effect": "Allow",
            "Resource": [
                "acs:oss:*:*:<myBucketName>",
                "acs:oss:*:*:<myBucketName>/*"
            ]
        }
    ],
    "Version": "1"
}

OSS讀寫權限策略

替換mybucket為實際Bucket名稱。

{
    "Statement": [
        {
            "Action": "oss:*",
            "Effect": "Allow",
            "Resource": [
                "acs:oss:*:*:<myBucketName>",
                "acs:oss:*:*:<myBucketName>/*"
            ]
        }
    ],
    "Version": "1"
}

使用控制台建立PV時，還需擁有oss:ListBuckets許可權。

{
  "Effect": "Allow",
  "Action": "oss:ListBuckets",
  "Resource": "*"
}

（可選）使用KMS託管的指定CMK ID加密OSS Object時，還需為該RAM使用者配置KMS許可權，詳見使用KMS託管的指定CMK ID加密。

將該策略授權給RAM使用者。
1. 訪問RAM控制台-使用者頁面，在RAM使用者列表的操作列，單擊目標使用者對應的添加許可權。
2. 在權限原則地區，按照頁面提示搜尋並選擇上一步建立的權限原則，並完成授權的新增。
為RAM使用者建立AccessKey，以便後續將其儲存為Secret，供PV使用。
1. 訪問RAM控制台-使用者頁面，在RAM使用者列表單擊目標使用者，然後在AccessKey地區，單擊建立 AccessKey。
2. 按照頁面提示，在對話方塊進行AccessKey的建立，擷取並妥善保管其AccessKey ID和AccessKey Secret。

步驟二：建立StorageClass

建立StorageClass，作為動態產生PV的模板。

RRSA方式

建立ossfs2-sc-rrsa.yaml。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  # StorageClass名稱
  name: ossfs2-sc  
parameters:
  # Bucket名稱
  bucket: oss-test  
  # 掛載Bucket的根目錄或指定子目錄
  path: /
  # OSS Bucket所在地區的Endpoint
  url: "http://oss-cn-hangzhou-internal.aliyuncs.com" 
  authType: rrsa
  # 此前建立的RAM角色
  roleName: demo-role-for-rrsa  
  fuseType: ossfs2
  volumeAs: sharepath
  otherOpts: "-o close_to_open=false"
# 使用ossfs 2.0用戶端時固定為此值
provisioner: ossplugin.csi.alibabacloud.com  
# 動態建立PV的回收策略，當前僅支援Retain
reclaimPolicy: Retain  
# 卷繫結模式，使用Immediate即可
volumeBindingMode: Immediate

主要參數說明：

參數	是否必選	說明
`bucket`	必選	待掛載的OSS Bucket。
`path`	必選	待掛載的OSS Bucket的子目錄。不填寫時預設掛載Bucket根目錄。所有通過此StorageClass建立的PV都將建立在此路徑下。
`url`	必選	待掛載OSS的訪問網域名稱（Endpoint）。掛載節點和Bucket處於相同地區，或已打通VPC網路時，使用內網地址。掛載節點和Bucket不同地區時，使用外網地址。不同訪問連接埠的常見填寫格式如下：內網格式：`http://oss-{{regionName}}-internal.aliyuncs.com`或`https://oss-{{regionName}}-internal.aliyuncs.com`。內網訪問連接埠格式`vpc100-oss-{{regionName}}.aliyuncs.com`已廢棄，請及時切換。外網格式：`http://oss-{{regionName}}.aliyuncs.com`或`https://oss-{{regionName}}.aliyuncs.com`。
`fuseType`	必選	使用ossfs 2.0用戶端時，固定為`ossfs2`。
`authType`	必選	配置為`rrsa`，使用RRSA方式鑒權。
`roleName`	必選	配置為此前建立或修改的RAM角色名稱。如需為不同PV配置不同許可權，可建立不同的RAM角色，並在PV中配置不同的`roleName`。
`volumeAs`	可選	儲存卷訪問模式。預設為`sharepath`模式。取值： `sharepath`：即共用方式掛載，所有儲存卷共用掛載路徑，即資料存放區於`<bucket>:<path>/`下。 `subpath`：即子目錄方式掛載。PVC使用此StorageClass請求儲存資源時，CSI會使用自動建立的PV名稱作為子目錄名稱，實現資料隔離。資料存放區路徑格式為`<bucket>:<path>/<pv-name>/`。此參數僅在CSI組件為1.31.3及以上版本時生效。
`otherOpts`	可選	為OSS儲存卷輸入定製化參數，格式為`-o * -o *`，例如`-o close_to_open=false`。 `close_to_open`：預設為關閉。開啟後，每次開啟檔案時，系統會主動向OSS發送GetObjectMeta請求，以擷取檔案在OSS中的最新中繼資料資訊，從而確保中繼資料的即時性。但在需要大量讀取小檔案的情境下，頻繁的中繼資料查詢會顯著增加訪問延遲。更多選擇性參數，請參見ossfs 2.0掛載選項說明。
`reclaimPolicy`	必選	動態建立PV的回收策略。當前僅支援`Retain`，即刪除PVC時，PV和OSS Bucket中的資料不會被刪除。
`volumeBindingMode`	必選	卷繫結模式。OSS儲存卷無需考慮可用性區域間節點親和，使用預設值`Immediate`即可。
`sigVersion`	可選	請求OSS服務端的請求籤名版本。 `"v1"`（預設）：使用OSS簽名版本1。 `"v4"`：使用OSS簽名版本4（推薦）。

建立StorageClass。
```
kubectl create -f ossfs2-sc-rrsa.yaml
```

確認StorageClass狀態。

kubectl get sc ossfs2-sc

預期輸出：

NAME        PROVISIONER                      RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
ossfs2-sc   ossplugin.csi.alibabacloud.com   Retain          Immediate           false                  17s

AccessKey方式

將步驟一擷取的AccessKey ID和AccessKey Secret儲存為Secret，供PV使用。
將<yourAccessKeyID>和<yourAccessKeySecret> 替換為真實憑證。Secret的Namespace需要和應用Namespace一致。
```
kubectl create secret generic oss-secret --from-literal='akId=<yourAccessKeyID>' --from-literal='akSecret=<yourAccessKeySecret>'
```

建立ossfs2-sc.yaml。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ossfs2-sc
parameters:
  # 使用此前建立的Secret
  csi.storage.k8s.io/node-publish-secret-name: oss-secret  
  csi.storage.k8s.io/node-publish-secret-namespace: default
  fuseType: ossfs2
  # OSS Bucket名稱
  bucket: oss-test 
  # 掛載Bucket的根目錄或指定子目錄
  path: /
  # OSS Bucket所在地區的Endpoint
  url: "http://oss-cn-hangzhou-internal.aliyuncs.com"
  otherOpts: "-o close_to_open=false"
# 使用ossfs 2.0用戶端時固定為此值
provisioner: ossplugin.csi.alibabacloud.com 
# 動態建立PV的回收策略，當前僅支援Retain，即刪除PVC時，PV和OSS Bucket中的資料不會被刪除
reclaimPolicy: Retain  
# 卷繫結模式。OSS儲存卷無需考慮可用性區域間節點親和，使用預設值Immediate即可
volumeBindingMode: Immediate

主要參數說明：

配置Secret

參數	是否必選	說明
`csi.storage.k8s.io/node-publish-secret-name`	必選	儲存AccessKey資訊的Secret名稱。
`csi.storage.k8s.io/node-publish-secret-namespace`	必選	儲存AccessKey資訊的Secret所在的命名空間。

配置儲存卷

參數	是否必選	說明
`bucket`	必選	待掛載的OSS Bucket。
`path`	必選	待掛載的OSS Bucket的子目錄。不填寫時預設掛載Bucket根目錄。所有通過此StorageClass建立的PV都將建立在此路徑下。
`url`	必選	待掛載OSS的訪問網域名稱（Endpoint）。掛載節點和Bucket處於相同地區，或已打通VPC網路時，使用內網地址。掛載節點和Bucket不同地區時，使用外網地址。不同訪問連接埠的常見填寫格式如下：內網格式：`http://oss-{{regionName}}-internal.aliyuncs.com`或`https://oss-{{regionName}}-internal.aliyuncs.com`。內網訪問連接埠格式`vpc100-oss-{{regionName}}.aliyuncs.com`已廢棄，請及時切換。外網格式：`http://oss-{{regionName}}.aliyuncs.com`或`https://oss-{{regionName}}.aliyuncs.com`。
`fuseType`	必選	使用ossfs 2.0用戶端時，固定為`ossfs2`。
`volumeAs`	可選	儲存卷訪問模式。預設為`sharepath`模式。取值： `sharepath`：即共用方式掛載，所有儲存卷共用掛載路徑，即資料存放區於`<bucket>:<path>/`下。 `subpath`：即子目錄方式掛載。PVC使用此StorageClass請求儲存資源時，CSI會使用自動建立的PV名稱作為子目錄名稱，實現資料隔離。資料存放區路徑格式為`<bucket>:<path>/<pv-name>/`。此參數僅在CSI組件為1.31.3及以上版本時生效。
`otherOpts`	必選	為OSS儲存卷輸入定製化參數，格式為`-o * -o *`，例如`-o close_to_open=false`。 `close_to_open`：預設為關閉。開啟後，每次開啟檔案時，系統會主動向OSS發送GetObjectMeta請求，以擷取檔案在OSS中的最新中繼資料資訊，從而確保中繼資料的即時性。但在需要大量讀取小檔案的情境下，頻繁的中繼資料查詢會顯著增加訪問延遲。更多選擇性參數，請參見ossfs 2.0掛載選項說明。
`reclaimPolicy`	必選	動態建立PV的回收策略。當前僅支援`Retain`，即刪除PVC時，PV和OSS Bucket中的資料不會被刪除。
`volumeBindingMode`	必選	卷繫結模式。OSS儲存卷無需考慮可用性區域間節點親和，使用預設值`Immediate`即可。
`sigVersion`	可選	請求OSS服務端的請求籤名版本。 `"v1"`（預設）：使用OSS簽名版本1。 `"v4"`：使用OSS簽名版本4（推薦）。

建立StorageClass。
```
kubectl create -f ossfs2-sc.yaml
```

確認StorageClass狀態。

kubectl get sc ossfs2-sc

預期輸出：

NAME        PROVISIONER                      RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
ossfs2-sc   ossplugin.csi.alibabacloud.com   Retain          Immediate           false                  35s

步驟三：建立PVC

建立PVC，從StorageClass申請儲存資源。此操作將觸發底層PV的自動建立。

建立ossfs2-pvc.yaml。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  # PVC名稱
  name: pvc-oss
  namespace: default
spec:
  # 配置訪問模式
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      # 聲明儲存容量，不能大於儲存卷總量
      storage: 20Gi
  # 此前建立的StorageClass
  storageClassName: ossfs2-sc

建立PVC。
```
kubectl create -f ossfs2-pvc.yaml
```

確認PVC和PV狀態。

kubectl get pvc pvc-oss

預期輸出中，PVC的狀態為Bound，表明已成功綁定到自動建立的PV。

NAME      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
pvc-oss   Bound    oss-31953fd4-a7c5-43cb-ae68-0b76b74bba82   20Gi       ROX            ossfs2-sc      <unset>                 12s

步驟四：建立應用並掛載儲存卷

在應用中引用PVC，完成掛載。

（可選）為儲存卷啟用監控能力。
ossfs 2.0 儲存卷的監控能力正在灰階發布中。如需啟用監控能力，需在掛載儲存卷前按如下流程啟用。
此監控配置僅對新掛載的儲存卷生效。如需為已掛載的儲存卷啟用，需重啟應用 Pod，並確認ack-csi-fuse命名空間下的ossfs2 Pod已重建。
展開查看開啟步驟
1. 升級CSI版本至1.34.1，請參見升級CSI組件。
2. 建立csi-plugin的ConfigMap。
  cat << EOF | kubectl create -f apiVersion: v1 kind: ConfigMap metadata: name: csi-plugin namespace: kube-system data: fuse-ossfs2: | metrics-mode=enabled EOF
  若csi-plugin的ConfigMap已存在，請在fuse-ossfs2下追加metrics-mode=enabled配置。
3. 重啟csi-plugin使配置生效。
  kubectl -nkube-system delete pod -lapp=csi-plugin

建立應用並掛載。

建立oss-workload.yaml。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: oss-workload
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        ports:
        - containerPort: 80
        volumeMounts:
          # 容器內的掛載路徑
          - name: pvc-oss
            mountPath: "/data"
        # 配置健全狀態檢查
        livenessProbe:
          exec:
            command:
            - ls
            - /data
          initialDelaySeconds: 30
          periodSeconds: 30
      volumes:
        - name: pvc-oss
          persistentVolumeClaim:
            # 引用此前建立的PVC
            claimName: pvc-oss

建立應用。
```
kubectl create -f oss-workload.yaml
```
驗證掛載結果。
- 確認Pod處於Running狀態。
```
kubectl get pod -l app=nginx
```
- 進入Pod，查看掛載點。
```
kubectl exec -it <pod-name> -- ls /data
```
  輸出中，可查看OSS掛載路徑下的資料。

步驟五：驗證共用儲存和持久化儲存

驗證共用儲存

在一個Pod中建立檔案，然後在另一個Pod中查看，以驗證共用儲存特性。

查看Pod資訊，在輸出中擷取Pod名稱。
```
kubectl get pod -l app=nginx
```
在一個Pod中建立tmpfile檔案。以名為 oss-workload-66fbb85b67-d**** 的Pod為例：
- ReadWriteMany：在/data路徑下建立tmpfile檔案。
```
kubectl exec oss-workload-66fbb85b67-d**** -- touch /data/tmpfile
```
- ReadOnlyMany：通過OSS控制台、cp（上傳檔案）等方式上傳tmpfile檔案至OSS Bucket對應的路徑。
在另一個Pod掛載路徑下查看檔案。
以名為oss-workload-66fbb85b67-l****、掛載路徑為data的Pod為例。
```
kubectl exec oss-workload-66fbb85b67-l**** -- ls /data | grep tmpfile
```
預期輸出如下，Pod掛載路徑下均存在此檔案，表明兩個Pod可共用資料。
```
tmpfile
```
若無預期輸出，請確認CSI組件版本是否為v1.20.7及以上版本。

驗證持久化儲存

刪除並重建Pod，在建立的Pod中查看檔案是否存在，驗證資料的持久化儲存。

刪除一個應用Pod以觸發重建。

kubectl delete pod oss-workload-66fbb85b67-d****

查看Pod，等待新Pod啟動並進入Running狀態。
```
kubectl get pod -l app=nginx
```
查看/data路徑下的檔案。
以名為oss-workload-66fbb85b67-z****、掛載路徑為data的Pod為例。
```
kubectl exec oss-workload-66fbb85b67-z**** -- ls /data | grep tmpfile
```
預期輸出如下，tmpfile檔案仍存在，表明資料可持久化儲存。
```
tmpfile
```

功能已知影響

讀寫情境：ossfs 2.0 主要適用於唯讀和順序追加寫情境。對於需要隨機寫的情境，建議使用 ossfs 1.0。
資料同步與誤刪風險：掛載狀態下，在應用Pod或宿主機上對掛載路徑下的檔案刪除或變更操作會直接同步處理到OSS Bucket源檔案。為避免資料誤刪除，建議為OSS Bucket開啟版本控制。
應用健全狀態檢查：建議為使用OSS儲存卷的Pod配置健全狀態檢查（Liveness Probe），例如檢查掛載目錄是否可用。當掛載異常時，可自動重啟Pod以恢複。
片段成本：當傳輸檔案大於10 MB時，ossfs會將檔案分區上傳。若上傳因業務自身重啟等特殊原因意外中斷，請手動刪除片段或通過生命週期規則刪除片段，避免片段佔用儲存空間併產生費用。
密鑰失效風險（AccessKey鑒權方式）：若PV引用的AccessKey失效或許可權變更，關聯應用會立即失去存取權限。
恢複訪問需更新Secret中的憑證，並重啟應用Pod以強制重新掛載（將導致業務中斷），請在維護視窗期執行。詳見解決方案。

生產環境使用建議

維度	說明
安全與許可權管理	優先使用RRSA鑒權：在生產環境中，推薦使用RRSA進行鑒權。RRSA通過OIDC和臨時安全性權杖（STS）為Pod提供訪問憑證，降低憑證泄露風險，還可實現Pod層級的精微調權限隔離。遵循最小許可權原則：為RAM角色或為RAM使用者授予許可權時，應嚴格遵循最小許可權原則。
效能與成本最佳化	合理配置掛載參數（`otherOpts`）：中繼資料快取（`-o close_to_open=false`）：預設行為，適用於大量讀取小檔案的情境，可快取檔案中繼資料，從而降低延遲和API請求費用。即時中繼資料（`-o close_to_open=true`）：當OSS檔案會被其他系統頻繁更新，且Pod需要立即感知時，可開啟。但會增加API調用次數和訪問延遲，請謹慎使用。根據業務情境，參見ossfs 2.0掛載選項說明進行更精細的效能調優。評估工作負載： ossfs 2.0適用於AI 訓練、推理、巨量資料處理及自動駕駛等新型計算密集型負載情境，以順序和隨機讀取、僅追加（Append-only）寫入為主要特徵，且不依賴完整 POSIX 語義的應用情境。管理分區生命週期：對於寫密集型應用，如果上傳大檔案時頻繁中斷，會產生大量未合并分區。建議在OSS Bucket上配置生命週期規則，定期自動清理片段，節省儲存成本。使用內網Endpoint：當叢集與OSS Bucket位於同一地區時，請使用內網Endpoint，以避免公網頻寬費用，並獲得更低的網路延遲。
營運管理	配置健全狀態檢查：為應用Pod配置存活探針（Liveness Probe）。當掛載點因網路抖動、CSI組件異常等原因失效時，健全狀態檢查會失敗，ACK會自動重啟Pod，觸發儲存卷的重新掛載。監控與警示：利用容器儲存監控配置警示，及時發現容量或效能瓶頸。

資源釋放指引

刪除工作負載
- 操作：刪除所有使用相關PVC的應用，如Deployment、StatefulSet等，停止Pod並卸載儲存卷。
- 命令樣本：kubectl delete deployment <your-deployment-name>
刪除PVC
- 操作：刪除應用關聯的PVC。動態建立的OSS儲存卷回收策略（reclaimPolicy）僅支援Retain。因此，刪除PVC後，其綁定的PV會進入Released狀態，後端OSS Bucket中對應的子目錄和資料都會被完整保留。
- 命令樣本：kubectl delete pvc <your-pvc-name>
刪除PV
- 操作：刪除處於Released狀態的PV。此操作僅移除Kubernetes中的PV資來源物件，不會刪除後端OSS Bucket中的資料。
- 命令樣本：kubectl delete pv <your-pv-name>
刪除StorageClass和Secret（可選）
- 操作：刪除不再需要的StorageClass和關聯的Secret。此操作僅移除Kubernetes中的資來源物件，不影響後端OSS Bucket本身。
- 命令樣本：kubectl delete sc <your-storageclass-name>、kubectl delete secret <your-secret-name>

Container Service for Kubernetes：在ACK中使用ossfs 2.0掛載動態OSS儲存卷

流程指引

適用範圍

步驟一：選擇鑒權方式（RRSA或AccessKey）並準備訪問憑證

RRSA方式

1. 在叢集中啟用RRSA

2. 建立RAM角色並授權

OSS唯讀權限原則

OSS讀寫權限策略

AccessKey方式

OSS唯讀權限原則

OSS讀寫權限策略

步驟二：建立StorageClass

RRSA方式

AccessKey方式

步驟三：建立PVC

步驟四：建立應用並掛載儲存卷

步驟五：驗證共用儲存和持久化儲存

驗證共用儲存

驗證持久化儲存

功能已知影響

生產環境使用建議

資源釋放指引

相關文檔