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

當應用需要持久化儲存，或多Pod間共用資料時，可通過靜態PV和PVC的方式，將OSS Bucket 掛載為 ossfs 2.0 儲存卷。這讓應用程式容器可以像訪問本地檔案系統一樣，使用標準的POSIX介面讀寫OSS資料，適用於巨量資料分析、AI訓練、靜態資源訪問等情境。

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

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

流程指引

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

確定掛載儲存卷時的鑒權方式（支援存取金鑰（AccessKey）和RRSA）並準備訪問憑證。
建立PV：在叢集中“註冊”已有的OSS Bucket，聲明其位置（根目錄或子目錄）、儲存大小、訪問模式等。
建立PVC：“申請”使用登入的OSS儲存資源。PVC會與合格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。

步驟二：建立PV

建立PV，在叢集中“註冊”已有的OSS Bucket。

RRSA方式

建立ossfs2-pv.yaml。

以下PV將名為cnfs-oss-test 的 OSS Bucket掛載為一個 20GB 的唯讀檔案系統，供叢集內的 Pod 使用。

apiVersion: v1
kind: PersistentVolume
metadata:
  # PV名稱
  name: pv-ossfs2  
spec:
  capacity:
    # 定義儲存卷容量 (此值僅用於匹配PVC)
    storage: 20Gi  
  # 訪問模式
  accessModes:  
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  csi:
    # 使用ossfs 2.0用戶端時固定為此值
    driver: ossplugin.csi.alibabacloud.com
    # 與PV名稱（metadata.name）保持一致
    volumeHandle: pv-ossfs2  
    volumeAttributes:
      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"
      authType: "rrsa"
      # 此前建立或修改的RAM角色
      roleName: "demo-role-for-rrsa"

主要參數說明如下：

參數	是否必選	說明
`fuseType`	必選	使用ossfs 2.0用戶端時，固定為`ossfs2`。
`bucket`	必選	待掛載的OSS Bucket。
`path`	可選	待掛載的OSS Bucket的子目錄。不填寫時預設掛載Bucket根目錄。
`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`。
`otherOpts`	可選	為OSS儲存卷輸入定製化參數，格式為`-o * -o *`，例如`-o close_to_open=false`。 `close_to_open`：預設為關閉。開啟後，每次開啟檔案時，系統會主動向OSS發送GetObjectMeta請求，以擷取檔案在OSS中的最新中繼資料資訊，從而確保中繼資料的即時性。但在需要大量讀取小檔案的情境下，頻繁的中繼資料查詢會顯著增加訪問延遲。更多選擇性參數，請參見ossfs 2.0掛載選項說明。
`authType`	必選	配置為`rrsa`，使用RRSA方式鑒權。
`roleName`	必選	配置為此前建立或修改的RAM角色名稱。如需為不同PV配置不同許可權，可建立不同的RAM角色，並在PV中配置不同的`roleName`。
`sigVersion`	可選	請求OSS服務端的請求籤名版本。 `"v1"`（預設）：使用OSS簽名版本1。 `"v4"`：使用OSS簽名版本4（推薦）。

若預設的RRSA鑒權不滿足需求（如使用非預設ServiceAccount或第三方OIDC），可通過修改PV配置來指定具體的ARN或ServiceAccount，詳見如何在RRSA鑒權方式中使用指定的ARNs或ServiceAccount？。

建立PV。
```
kubectl create -f ossfs2-pv.yaml
```

確認PV狀態。

kubectl get pv pv-ossfs2

預期輸出如下，確認PV的狀態為Available。

NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pv-ossfs2   20Gi       ROX            Retain           Available                          <unset>                          15s

AccessKey方式

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

建立ossfs2-pv.yaml。

以下PV將名為cnfs-oss-test 的 OSS Bucket掛載為一個 20GiB 的唯讀檔案系統。

apiVersion: v1
kind: PersistentVolume
metadata:
  # PV名稱
  name: pv-ossfs2  
spec:
  capacity:
    # 定義儲存卷容量 (此值僅用於匹配PVC)
    storage: 20Gi  
  # 訪問模式
  accessModes:  
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: ossplugin.csi.alibabacloud.com
    # 與PV名稱（metadata.name）保持一致
    volumeHandle: pv-ossfs2   
    # 使用此前建立的Secret
    nodePublishSecretRef:
      # 儲存AK資訊的Secret名稱
      name: oss-secret  
      # 該Secret所在的命名空間
      namespace: default  
    volumeAttributes:
      fuseType: ossfs2
      # 替換為實際Bucket名稱
      bucket: cnfs-oss-test  
      # 待掛載的子目錄，留空則掛載根目錄
      path: /
      # OSS Bucket所在地區的Endpoint
      url: "http://oss-cn-hangzhou-internal.aliyuncs.com"  
      otherOpts: "-o close_to_open=false"

nodePublishSecretRef參數說明：
參數
是否必選
說明
name
必選
儲存AccessKey資訊的Secret名稱。
namespace
必選
儲存AccessKey資訊的Secret所在的命名空間。

volumeAttributes參數說明：

參數	是否必選	說明
`fuseType`	必選	使用ossfs 2.0用戶端時，固定為`ossfs2`。
`bucket`	必選	待掛載的OSS Bucket。
`path`	可選	待掛載的OSS Bucket的子目錄。不填寫時預設掛載Bucket根目錄。
`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`。
`otherOpts`	可選	為OSS儲存卷輸入定製化參數，格式為`-o * -o *`，例如`-o close_to_open=false`。 `close_to_open`：預設為關閉。開啟後，每次開啟檔案時，系統會主動向OSS發送GetObjectMeta請求，以擷取檔案在OSS中的最新中繼資料資訊，從而確保中繼資料的即時性。但在需要大量讀取小檔案的情境下，頻繁的中繼資料查詢會顯著增加訪問延遲。更多選擇性參數，請參見ossfs 2.0掛載選項說明。

建立PV。
```
kubectl create -f ossfs2-pv.yaml
```

確認PV狀態。

kubectl get pv pv-ossfs2

預期輸出如下，確認PV的狀態為Available。

NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pv-ossfs2   20Gi       ROX            Retain           Available                          <unset>                          15s

步驟三：建立PVC

建立PVC，為應用聲明其所需的持久化儲存容量。

建立ossfs2-pvc.yaml。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  # PVC名稱
  name: pvc-ossfs2  
  namespace: default
spec:
  # 以下配置需要與PV一致
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 20Gi
  storageClassName: ""
  # 待綁定的PV
  volumeName: pv-ossfs2

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

確認PVC狀態。

kubectl get pvc pvc-oss

輸出中，PVC已綁定（Bound）PV。

NAME         STATUS   VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
pvc-ossfs2   Bound    pv-ossfs2   20Gi       ROX                           <unset>                 74s

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

在應用中引用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靜態卷的PV回收策略（persistentVolumeReclaimPolicy）僅支援Retain。因此，刪除PVC後，其綁定的PV會進入Released狀態，後端的OSS Bucket及其中的所有資料都會被完整保留。
- 命令樣本：kubectl delete pvc <your-pvc-name>
刪除PV
- 操作：刪除處於Released狀態的PV。此操作僅移除Kubernetes中的資源定義，不會刪除後端OSS Bucket中的資料。
- 命令樣本：kubectl delete pv <your-pv-name>
刪除Secret（可選）
- 操作：刪除為掛載OSS而建立的Secret。此操作僅移除Kubernetes中的Secret資來源物件，不刪除後端OSS Bucket中的資料。
- 命令樣本：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讀寫權限策略

步驟二：建立PV

RRSA方式

AccessKey方式

步驟三：建立PVC

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

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

驗證共用儲存

驗證持久化儲存

功能已知影響

生產環境使用建議

資源釋放指引

相關文檔