全部產品
Search
文件中心

Container Service for Kubernetes:使用ossfs 1.0動態儲存裝置卷掛載OSS Bucket

更新時間:Dec 04, 2025

ossfs 1.0 支援動態儲存裝置卷,可基於 StorageClass 和 PVC 自動建立 PV 並掛載 OSS Bucket。該功能無需手動設定 PV,極大簡化了儲存管理,適用於多租戶及需要按需、頻繁建立儲存的情境。

適用範圍

叢集和CSI組件(csi-plugin和csi-provisioner)版本需符合要求:

  • 通過RRSA鑒權方式掛載時:叢集版本為1.26及以上,CSI版本為v1.30.4及以上。

    若在1.30.4之前的版本中使用了RRSA功能,需參見【產品變更】CSI ossfs版本升級與掛載流程最佳化增加RAM角色授權配置。
  • 通過AccessKey鑒權方式掛載時:為確保掛載穩定性,CSI版本建議不低於 v1.18.8.45。

如需升級叢集,請參見手動升級叢集;如需升級組件,請參見升級CSI組件

自CSI v1.30.4-*版本起,OSS靜態卷掛載已依賴csi-provisioner組件

步驟一:選擇鑒權方式(RRSA或AccessKey)並準備訪問憑證

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

  • RRSA鑒權方式:為 Pod 動態授予臨時、自動輪換的 RAM 角色,實現應用層級的精微調權限隔離,安全性較高。

  • AccessKey鑒權方式:將靜態、長期的金鑰儲存區在 Secret 中。配置簡單,但安全性較低。

重要
  • 在1.26及以上版本的叢集中,為避免因AccessKey輪轉導致的ossfs重掛載和業務重啟,建議使用RRSA鑒權方式。

  • 本樣本中叢集與OSS Bucket處於同一阿里雲帳號下。如需跨帳號掛載OSS Bucket,建議使用RRSA鑒權方式。

RRSA方式

1. 在叢集中啟用RRSA

  1. ACK叢集列表頁面,單擊目的地組群名稱,選擇集群信息

  2. 基本資料頁簽的安全與審計地區,單擊RRSA OIDC右側的開啟,按照頁面提示在業務低峰期完成RRSA的啟用。

    當叢集狀態由更新中變為運行中,表明RRSA已成功啟用。

    重要

    啟用RRSA功能後,叢集內新建立的ServiceAccount Token的最大有效期間將限制為12小時。

2. 建立RAM角色並授權

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

展開查看步驟

  1. 建立一個RAM角色。

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

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

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

      配置項

      描述

      身份供應商類型

      OIDC

      身份供應商

      選擇ack-rrsa-<cluster_id>。其中,<cluster_id>為叢集ID。

      條件

      手動添加oidc:sub。

      • 條件鍵:選擇oidc:sub

      • 運算子:選擇StringEquals

      • 條件值:預設輸入system:serviceaccount:ack-csi-fuse:csi-fuse-ossfs

      角色名稱

      本樣本為demo-role-for-rrsa。

  2. 建立權限原則。

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

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

      若已有授權OSS許可權的RAM角色,修改其信任策略即可複用,請參見基於RRSA的Pod許可權隔離
      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加密

  3. 將該策略授權給RAM角色。

    1. 訪問RAM控制台-角色頁面,在RAM角色列表的操作列,單擊目標角色對應的新增授權

    2. 權限原則地區,按照頁面提示搜尋並選擇上一步建立的權限原則,並完成授權的新增。

AccessKey方式

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

  1. 建立RAM使用者(如有,可跳過)。

    訪問RAM控制台-建立使用者頁面,按照頁面提示完成RAM使用者的建立,如登入名稱稱、密碼等。

  2. 建立權限原則。

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

    1. 訪問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": "*"
      }
    2. (可選)使用KMS託管的指定CMK ID加密OSS Object時,還需為該RAM使用者配置KMS許可權,詳見使用KMS託管的指定CMK ID加密

  3. 將該策略授權給RAM使用者。

    1. 訪問RAM控制台-使用者頁面,在RAM使用者列表的操作列,單擊目標使用者對應的添加許可權

    2. 權限原則地區,按照頁面提示搜尋並選擇上一步建立的權限原則,並完成授權的新增。

  4. 為RAM使用者建立AccessKey,以便後續將其儲存為Secret,供PV使用。

    1. 訪問RAM控制台-使用者頁面,在RAM使用者列表單擊目標使用者,然後在AccessKey地區,單擊建立 AccessKey

    2. 按照頁面提示,在對話方塊進行AccessKey的建立,擷取並妥善保管其AccessKey ID和AccessKey Secret。

步驟二:建立StorageClass

建立StorageClass,定義儲存卷的建立模板。

RRSA方式

  1. 建立sc-oss.yaml

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: sc-oss
    parameters:
      # 替換為實際Bucket名稱
      bucket: bucket  
      # 掛載Bucket的根目錄或指定子目錄
      path: /
      # Bucket所在地區的Endpoint
      url:  "http://oss-cn-hangzhou-internal.aliyuncs.com"  
      # 使用RRSA方式鑒權
      authType: rrsa
      # 此前建立或修改的RAM角色
      roleName: demo-role-for-rrsa
      # 定製化參數
      otherOpts: "-o umask=022 -o max_stat_cache_size=100000 -o allow_other"
      # 儲存卷訪問模式
      volumeAs: sharepath
    # # 使用阿里雲OSS CSI外掛程式時固定為此值
    provisioner: ossplugin.csi.alibabacloud.com
    # 動態建立的PV的回收策略
    reclaimPolicy: Retain
    # 繫結模式
    volumeBindingMode: Immediate

    參數

    說明

    bucket

    待掛載的OSS Bucket。

    path

    CSI組件版本需為v1.14.8.32-c77e277b-aliyun及以上。

    指定掛載點相對於 Bucket 根目錄的路徑。預設為 /,即掛載整個 Bucket。

    ossfs版本小於1.91時,指定的 path 必須在 OSS Bucket 中預先存在。詳見ossfs 1.91及以上版本新增功能說明

    url

    待掛載OSS的訪問網域名稱(Endpoint)。

    • 掛載節點和Bucket處於相同地區,或已打通VPC網路時,使用內網地址。

    • 掛載節點和Bucket不同地區時,使用外網地址。

    不同訪問連接埠的常見填寫格式如下:

    • 內網格式:http://oss-{{regionName}}-internal.aliyuncs.comhttps://oss-{{regionName}}-internal.aliyuncs.com

      內網訪問連接埠格式vpc100-oss-{{regionName}}.aliyuncs.com已廢棄,請及時切換。
    • 外網格式:http://oss-{{regionName}}.aliyuncs.comhttps://oss-{{regionName}}.aliyuncs.com

    authType

    配置為rrsa,使用RRSA方式鑒權。

    roleName

    配置為此前建立或修改的RAM角色。

    如需為不同StorageClass配置不同的許可權,可建立不同的RAM角色,在StorageClass中配置不同的roleName

    otherOpts

    為OSS儲存卷輸入定製化參數,格式為-o *** -o ***,例如-o umask=022 -o max_stat_cache_size=100000 -o allow_other

    展開查看說明

    • umask:更改ossfs讀檔案的許可權。

      例如,umask=022可將ossfs檔案的許可權變更為755,解決通過SDK、OSS控制台等其他方式上傳的檔案(預設許可權為640)在掛載點內許可權不足的問題。推薦在讀寫分離或多使用者訪問時配置。

    • max_stat_cache_size:設定中繼資料快取的條目上限(例如100000),在記憶體中快取檔案元資訊來提升 lsstat 等操作的效能。

      但該緩衝無法及時感知通過OSS控制台、SDK、ossutil等方式對檔案的修改,可能導致應用讀取資料不一致。在對資料一致性有強要求時可將其設為0(禁用緩衝),或通過stat_cache_expire參數調低緩衝的失效時間,但會犧牲讀取效能。

    • allow_other:允許除掛載使用者外的其他使用者訪問掛載點中的檔案和目錄,適用於需要讓非掛載使用者也能訪問資料的多使用者共用環境。

    更多選擇性參數,請參見掛載選項說明ossfs 1.0配置最佳實務

    provisioner

    驅動類型。使用阿里雲OSS CSI外掛程式時固定為ossplugin.csi.alibabacloud.com

    reclaimPolicy

    動態建立的PV的回收策略。當前OSS儲存卷僅支援Retain,即刪除PVC時,PV和OSS Bucket中的資料不會隨之刪除。

    volumeBindingMode

    繫結模式。

    OSS儲存卷無需考慮可用性區域間節點親和,使用預設值Immediate即可。

    volumeAs

    儲存卷訪問模式。預設為sharepath模式。取值:

    • sharepath:即共用方式掛載,所有儲存卷共用掛載路徑,即資料存放區於<bucket>:<path>/下。

    • subpath:即子目錄方式掛載。PVC使用此StorageClass請求儲存資源時,CSI會使用自動建立的PV名稱作為子目錄名稱,實現資料隔離。資料存放區路徑格式為<bucket>:<path>/<pv-name>/

      此參數僅在CSI組件為1.31.3及以上版本時生效。

    sigVersion

    請求OSS服務端的請求籤名版本。

  2. 建立StorageClass。

    kubectl apply -f sc-oss.yaml

AccessKey方式

kubectl

1、建立儲存類StorageClass

  1. 建立Secret,該Secret選擇的Namespace需要和應用所在的Namespace一致。

    替換以下akIdakSecret為此前擷取的AccessKey ID和AccessKey Secret。

    kubectl create secret generic oss-secret --from-literal='akId=<yourAccessKey ID>' --from-literal='akSecret=<yourAccessKey Secret>'
  2. 建立儲存類。

    1. 建立sc-oss.yaml

      apiVersion: storage.k8s.io/v1
      kind: StorageClass
      metadata:
        name: sc-oss
      parameters:
        # 替換為實際Bucket名稱
        bucket: bucket
        # 掛載Bucket的根目錄或指定子目錄
        path: /
        # Bucket所在地區的Endpoint
        url: "http://oss-cn-hangzhou-internal.aliyuncs.com" 
        # 儲存AccessKey資訊的Secret名稱
        csi.storage.k8s.io/node-publish-secret-name: oss-secret
        # 儲存AccessKey資訊的Secret所在的命名空間
        csi.storage.k8s.io/node-publish-secret-namespace: default
        # 定製化參數
        otherOpts: "-o umask=022 -o max_stat_cache_size=100000 -o allow_other"
      # 使用阿里雲OSS CSI外掛程式時固定為此值
      provisioner: ossplugin.csi.alibabacloud.com
      # 動態建立的PV的回收策略
      reclaimPolicy: Retain
      # 繫結模式
      volumeBindingMode: Immediate
      

      參數

      說明

      name

      儲存類名稱。

      bucket

      待掛載的OSS Bucket。

      path

      CSI組件版本需為v1.14.8.32-c77e277b-aliyun及以上。

      指定掛載點相對於 Bucket 根目錄的路徑。預設為 /,即掛載整個 Bucket。

      ossfs版本小於1.91時,指定的 path 必須在 OSS Bucket 中預先存在。詳見ossfs 1.91及以上版本新增功能說明

      url

      待掛載OSS的訪問網域名稱(Endpoint)。

      • 掛載節點和Bucket處於相同地區,或已打通VPC網路時,使用內網地址。

      • 掛載節點和Bucket不同地區時,使用外網地址。

      不同訪問連接埠的常見填寫格式如下:

      • 內網格式:http://oss-{{regionName}}-internal.aliyuncs.comhttps://oss-{{regionName}}-internal.aliyuncs.com

        內網訪問連接埠格式vpc100-oss-{{regionName}}.aliyuncs.com已廢棄,請及時切換。
      • 外網格式:http://oss-{{regionName}}.aliyuncs.comhttps://oss-{{regionName}}.aliyuncs.com

      csi.storage.k8s.io/node-publish-secret-name

      儲存AccessKey資訊的Secret名稱。

      csi.storage.k8s.io/node-publish-secret-namespace

      儲存AccessKey資訊的Secret所在的命名空間。

      otherOpts

      為OSS儲存卷輸入定製化參數,格式為-o *** -o ***,例如-o umask=022 -o max_stat_cache_size=100000 -o allow_other

      展開查看說明

      • umask:更改ossfs讀檔案的許可權。

        例如,umask=022可將ossfs檔案的許可權變更為755,解決通過SDK、OSS控制台等其他方式上傳的檔案(預設許可權為640)在掛載點內許可權不足的問題。推薦在讀寫分離或多使用者訪問時配置。

      • max_stat_cache_size:設定中繼資料快取的條目上限(例如100000),在記憶體中快取檔案元資訊來提升 lsstat 等操作的效能。

        但該緩衝無法及時感知通過OSS控制台、SDK、ossutil等方式對檔案的修改,可能導致應用讀取資料不一致。在對資料一致性有強要求時可將其設為0(禁用緩衝),或通過stat_cache_expire參數調低緩衝的失效時間,但會犧牲讀取效能。

      • allow_other:允許除掛載使用者外的其他使用者訪問掛載點中的檔案和目錄,適用於需要讓非掛載使用者也能訪問資料的多使用者共用環境。

      更多選擇性參數,請參見掛載選項說明ossfs 1.0配置最佳實務

      provisioner

      驅動類型。使用阿里雲OSS CSI外掛程式時固定為ossplugin.csi.alibabacloud.com

      reclaimPolicy

      動態建立的PV的回收策略。當前OSS儲存卷僅支援Retain,即刪除PVC時,PV和OSS Bucket中的資料不會隨之刪除。

      volumeBindingMode

      繫結模式。

      OSS儲存卷無需考慮可用性區域間節點親和,使用預設值Immediate即可。

      volumeAs

      儲存卷訪問模式。預設為sharepath模式。取值:

      • sharepath:即共用方式掛載,所有儲存卷共用掛載路徑,即資料存放區於<bucket>:<path>/下。

      • subpath:即子目錄方式掛載。PVC使用此StorageClass請求儲存資源時,CSI會使用自動建立的PV名稱作為子目錄名稱,實現資料隔離。資料存放區路徑格式為<bucket>:<path>/<pv-name>/

        此參數僅在CSI組件為1.31.3及以上版本時生效。

      sigVersion

      請求OSS服務端的請求籤名版本。

    2. 建立StorageClass。

      kubectl apply -f sc-oss.yaml

控制台

  1. 步驟一擷取的AccessKey儲存為Secret,供PV使用。

    1. ACK叢集列表頁面,單擊目的地組群名稱,在叢集詳情頁左側導覽列,選擇配置管理 > 保密字典

    2. 單擊使用YAML建立資源,按照頁面提示,完成Secret的建立。

      apiVersion: v1
      kind: Secret
      metadata:
        name: oss-secret
        # 需與應用所在的命令空間保持一致
        namespace: default
      stringData:
        # 替換為此前擷取的AccessKey ID
        akId: <your AccessKey ID>
        # 替換為此前擷取的AccessKey Secret
        akSecret: <your AccessKey Secret>
  2. 叢集列表頁面,單擊目的地組群名稱,然後在左側導覽列,選擇儲存 > 儲存類

  3. 儲存類頁面,單擊建立,選擇儲存卷類型為OSS,按照頁面提示配置StorageClass。

    配置項

    說明

    訪問認證

    配置訪問OSS所需的保密字典,即此前擷取的AccessKey ID和AccessKey Secret。

    Bucket ID

    待使用的OSS Bucket。

    此處僅展示配置AccessKey後可擷取到的Bucket。

    OSS Path

    CSI組件版本需為v1.14.8.32-c77e277b-aliyun及以上。

    指定掛載點相對於 Bucket 根目錄的路徑。預設為 /,即掛載整個 Bucket。

    ossfs版本小於1.91時,指定的 path 必須在 OSS Bucket 中預先存在。詳見ossfs 1.91及以上版本新增功能說明

    儲存卷模式

    儲存卷訪問模式。預設為共用目錄模式。取值:

    子目錄模式僅在CSI組件為1.31.3及以上版本時生效。否則均為共用目錄模式。
    • 共用目錄sharepath):所有儲存卷共用掛載路徑,即資料存放區於<bucket>:<path>/下。

    • 子目錄subpath):建立儲存卷時在掛載路徑下自動建立子目錄,即資料存放區於<bucket>:<path>/<pv-name>/下。

    訪問網域名稱

    待掛載OSS的訪問網域名稱(Endpoint)。

    • 掛載節點和Bucket處於相同地區,或已打通VPC網路時,使用內網地址。

    • 掛載節點和Bucket不同地區時,使用外網地址。

    不同訪問連接埠的常見填寫格式如下:

    • 內網格式:http://oss-{{regionName}}-internal.aliyuncs.comhttps://oss-{{regionName}}-internal.aliyuncs.com

      內網訪問連接埠格式vpc100-oss-{{regionName}}.aliyuncs.com已廢棄,請及時切換。
    • 外網格式:http://oss-{{regionName}}.aliyuncs.comhttps://oss-{{regionName}}.aliyuncs.com

    通過私網訪問時預設使用HTTP協議。如需使用HTTPS,請使用kubectl方式。

    回收策略

    動態建立的PV的回收策略。當前OSS儲存卷僅支援Retain,即刪除PVC時,PV和OSS Bucket中的資料不會隨之刪除。

    選擇性參數

    為OSS儲存卷輸入定製化參數,格式為-o *** -o ***,例如-o umask=022 -o max_stat_cache_size=100000 -o allow_other

    展開查看說明

    • umask:更改ossfs讀檔案的許可權。

      例如,umask=022可將ossfs檔案的許可權變更為755,解決通過SDK、OSS控制台等其他方式上傳的檔案(預設許可權為640)在掛載點內許可權不足的問題。推薦在讀寫分離或多使用者訪問時配置。

    • max_stat_cache_size:設定中繼資料快取的條目上限(例如100000),在記憶體中快取檔案元資訊來提升 lsstat 等操作的效能。

      但該緩衝無法及時感知通過OSS控制台、SDK、ossutil等方式對檔案的修改,可能導致應用讀取資料不一致。在對資料一致性有強要求時可將其設為0(禁用緩衝),或通過stat_cache_expire參數調低緩衝的失效時間,但會犧牲讀取效能。

    • allow_other:允許除掛載使用者外的其他使用者訪問掛載點中的檔案和目錄,適用於需要讓非掛載使用者也能訪問資料的多使用者共用環境。

    更多選擇性參數,請參見掛載選項說明ossfs 1.0配置最佳實務

步驟三:建立PVC

建立PVC,動態申請儲存資源。CSI將根據StorageClass自動建立PV。

kubectl

  1. 建立pvc-oss.yaml

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      # PVC名稱
      name: pvc-oss
    spec:
      # 配置訪問模式。ReadOnlyMany表明ossfs將以唯讀模式掛載OSS Bucket
      accessModes:
      - ReadOnlyMany
      volumeMode: Filesystem
      resources:
        requests:
          # 聲明儲存容量,不能大於儲存卷總量
          storage: 20Gi
      # 聲明引用的StorageClass
      storageClassName: sc-oss

    參數

    說明

    accessModes

    配置訪問模式,支援ReadOnlyManyReadWriteMany

    選擇ReadOnlyMany時,ossfs將以唯讀模式掛載OSS Bucket。

    storage

    聲明儲存卷的請求容量。此值不限制OSS儲存卷的實際容量。

    storageClassName

    引用的StorageClass。

  2. 建立PVC。

    kubectl apply -f pvc-oss.yaml
  3. 確認PVC已建立且進入綁定(Bound)狀態。

    kubectl get pvc pvc-oss

    預期輸出:

    NAME           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS         VOLUMEATTRIBUTESCLASS   AGE
    pvc-oss        Bound    oss-251d111d-3b0b-4879-81a0-eb5a19xxxxxx   20Gi       ROX            sc-oss             <unset>                 4d20h

控制台

  1. 叢集列表頁面,單擊目的地組群名稱,然後在左側導覽列,選擇儲存 > 儲存聲明

  2. 儲存聲明頁面,單擊建立,選擇儲存宣告類型為OSS,按照頁面提示完成PVC的配置。

    配置項

    說明

    分配模式

    選擇使用儲存類動態建立

    已有儲存類

    單擊選擇儲存類,選擇此前建立的StorageClass。

    總量

    聲明儲存卷的請求容量。此值不限制OSS儲存卷的實際容量。

    訪問模式

    配置訪問模式,支援ReadOnlyManyReadWriteMany

    選擇ReadOnlyMany時,ossfs將以唯讀模式掛載OSS Bucket。

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

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

kubectl

  1. 建立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
  2. 建立應用。

    kubectl create -f oss-workload.yaml
  3. 驗證掛載結果。

    • 確認Pod處於Running狀態。

      kubectl get pod -l app=nginx
    • 進入Pod,查看掛載點。

      kubectl exec -it <pod-name> -- ls /data

      輸出中,可查看OSS掛載路徑下的資料。

控制台

  1. ACK叢集列表頁面,單擊目的地組群名稱,在叢集詳情頁左側導覽列,選擇工作负载 > 无状态

  2. 無狀態頁面,單擊使用鏡像建立

  3. 單擊使用鏡像建立,按照頁面提示配置應用參數。

    關鍵參數如下,其他參數保持預設即可。詳見建立無狀態工作負載Deployment

    配置頁

    參數

    說明

    應用基本資料

    副本數量

    Deployment副本數量。

    容器配置

    鏡像名稱

    用於部署應用的鏡像地址,如anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6

    所需資源

    所需的vCPU和記憶體資源。

    資料卷

    單擊增加雲端儲存聲明,然後完成參數配置。

    • 掛載源:選擇之前建立的PVC。

    • 容器路徑:輸入OSS要掛載到的容器路徑,如/data

    標籤和註解

    Pod標籤

    如名稱為app,值為nginx。

  4. 查看應用部署狀態。

    無狀態頁面,單擊應用程式名稱,在容器組頁簽下,確認Pod已正常運行(狀態為Running)。

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

驗證共用儲存

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

  1. 查看Pod資訊,在輸出中擷取Pod名稱。

    kubectl get pod -l app=nginx
  2. 在一個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對應的路徑。

  3. 在另一個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中查看檔案是否存在,驗證資料的持久化儲存。

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

    kubectl delete pod oss-workload-66fbb85b67-d****
  2. 查看Pod,等待新Pod啟動並進入Running狀態。

    kubectl get pod -l app=nginx
  3. 查看/data路徑下的檔案。

    以名為oss-workload-66fbb85b67-z****、掛載路徑為data的Pod為例。

    kubectl exec oss-workload-66fbb85b67-z**** -- ls /data | grep tmpfile

    預期輸出如下,tmpfile檔案仍存在,表明資料可持久化儲存。

    tmpfile

功能已知影響

  • 資料完整性風險

    • 並發寫一致性風險:為提升寫操作穩定性,建議升級CSI組件至v1.28及以上版本。但對於單檔案並發寫情境,OSS的“覆蓋上傳”特性仍可能導致資料覆蓋,需在應用程式層保障資料一致性。

    • 資料同步與誤刪風險:掛載狀態下,在應用Pod或宿主機上對掛載路徑下的檔案刪除或變更操作會直接同步處理到OSS Bucket源檔案。為避免資料誤刪除,建議為OSS Bucket開啟版本控制

  • 應用穩定性風險

    • OOM風險:初次對大量檔案(如超10萬,具體取決於節點記憶體)進行readdir操作時(如Shell指令碼中的ls命令),ossfs會因一次性載入全部元資訊而消耗大量記憶體,可能導致進程OOM Killed,並引發掛載點不可用。

      建議掛載OSS Bucket子目錄或最佳化目錄層級來規避此風險。

    • 掛載時間延長:在應用中配置securityContext.fsgroup會導致kubelet在掛載儲存卷時遞迴修改檔案許可權(chmod/chown)。若檔案數量龐大,將顯著延長掛載時間,可能導致 Pod 啟動嚴重延遲。

      配置此參數時,如需減少掛載時間,請參見OSS儲存卷掛載時間延長

    • 密鑰失效風險(AccessKey鑒權方式):若PV引用的AccessKey失效或許可權變更,關聯應用會立即失去存取權限。

      恢複訪問需更新Secret中的憑證,並重啟應用Pod以強制重新掛載(將導致業務中斷),請在維護視窗期執行。詳見解決方案

  • 成本風險

相關文檔