Container Service for Kubernetes：使用OSS靜態儲存卷

注意事項

• OSS不支援動態建立PV，也不建議跨帳號使用。

• Container ServiceKubernetes叢集升級會重啟kubelet，ossfs驅動跟隨一起重啟，導致OSS目錄不可用。此時使用OSS的Pod需要重建，可在YAML檔案中增加健全狀態檢查的配置，在容器內OSS目錄不可用時自動重啟Pod，重新掛載OSS。

  說明

  如果您使用的是v1.18.8.45及以上版本的csi-plugin和csi-provisioner外掛程式，則不會出現上述問題。

• 若您在應用模板中配置了securityContext.fsgroup參數，kubelet在儲存卷掛載完成後會執行chmod或chown操作，導致掛載時間延長。

  說明

  若您已配置securityContext.fsgroup參數，且需要減少掛載時間，請參見OSS儲存卷掛載時間延長。

• 通過ossfs進行ls等操作時，將發起HTTP請求到OSS擷取檔案的meta資訊，如果ls的目標目錄下檔案較多（超過100,000個，該數值與機器記憶體大小相關），ossfs將消耗大量系統記憶體，可能導致Pod發生OOM（Out Of Memory）事件。您可以通過掛載OSS Bucket的子目錄，或對檔案較多的目錄進行目錄分級解決此問題。

• ossfs適用於並發讀情境，建議您配置PVC和PV的訪問模式為ReadOnlyMany。若需寫入資料，建議您通過OSS SDK、ossutil工具等方式實現資料讀寫分離。具體操作，請參見OSS儲存讀寫分離最佳實務。

  說明

  配置OSS儲存卷的訪問模式為ReadWriteMany，通過ossfs進行寫操作時需要注意以下事項：

  • 在並發寫情境中，ossfs無法保證資料寫入的一致性。

  • 掛載狀態下，登入應用Pod或宿主機，在掛載路徑下刪除或變更檔案，都會直接刪除或變更OSS Bucket中對應的源檔案。您可以通過開啟OSS Bucket的版本控制，避免誤刪除重要資料，請參見版本控制概述。

• 當傳輸的檔案大於10 MB時，可以將檔案切成片段，分區上傳。分區上傳過程中斷後，如您不再需要這些Part，可通過以下方式刪除，以免產生額外儲存費用。

  • 手動刪除Part，請參見刪除片段。

  • 通過生命週期規則自動刪除Part，請參見設定生命週期規則。

通過RRSA鑒權方式掛載

基於適用於服務賬戶的RAM角色（RAM Roles for Service Accounts，簡稱RRSA）功能，您可以在叢集內實現PV維度OpenAPI許可權隔離，從而實現雲資源存取權限的細粒度隔離，降低安全風險。更多RRSA的背景資訊，請參見通過RRSA配置ServiceAccount的RAM許可權實現Pod許可權隔離。

（可選）步驟一：建立RAM角色

如果您在叢集中首次使用RRSA功能，需要按照以下步驟操作，如果您已經在叢集中使用過RRSA鑒權方式掛載OSS儲存卷，則可以跳過本步驟。

1. 在Container Service管理主控台啟用RRSA功能。具體操作，請參見通過RRSA配置ServiceAccount的RAM許可權實現Pod許可權隔離。

2. 為OSS儲存卷RRSA鑒權建立RAM角色，即使用RRSA功能扮演的指定角色。

   建立可信實體類型為身份供應商的RAM角色，以demo-role-for-rrsa為例。

   1. 使用阿里雲帳號登入RAM控制台。

   2. 在左側導覽列，選擇身份管理 > 角色，然後在角色頁面，單擊建立角色。

   3. 在建立角色面板，選擇可信實體類型為身份供應商，然後單擊下一步。

   4. 在配置角色頁面，配置如下角色資訊後，單擊完成。

      本樣本配置如下。

      配置項	描述
      角色名稱	demo-role-for-rrsa。
      備忘	選填有關該角色的備忘資訊。
      身份供應商類型	OIDC。
      選擇身份供應商	ack-rrsa-<cluster_id>。其中，<cluster_id>為您的叢集ID。
      限制條件	oidc:iss：保持預設。 oidc:aud：選擇sts.aliyuncs.com。 oidc:sub：條件判定方式選擇StringEquals，此處需要填入system:serviceaccount:ack-csi-fuse:csi-fuse-ossfs。

步驟二：為demo-role-for-rrsa角色授權

1. 建立如下OSS訪問的自訂權限原則。具體操作，請參見建立自訂權限原則。

   以下權限原則中，請替換mybucket為您實際建立的Bucket名稱。

   • OSS唯讀權限原則

     展開查看OSS唯讀權限原則內容

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

   • OSS讀寫權限

     展開查看OSS讀寫權限策略內容

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

2. （可選）若您使用KMS託管的指定CMK ID加密OSS Object，還需要為該RAM使用者配置KMS許可權。具體操作，請參見為OSS儲存卷加密。

3. 為demo-role-for-rrsa角色授權。具體操作，請參見為RAM角色授權。

   說明

   您也可以通過修改RAM角色信任策略的方式使用已有的授權了OSS許可權的RAM角色。具體操作，請參見使用已存在的RAM角色並授權。

步驟三：建立PV和PVC

1. 配置PV使用RRSA鑒權。

   1. 使用以下內容，建立配置RRSA許可權認證的pv-rrsa.yaml樣本檔案。

      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: pv-oss
        labels:    
          alicloud-pvname: pv-oss
      spec:
        capacity:
          storage: 5Gi
        accessModes:
          - ReadOnlyMany
        persistentVolumeReclaimPolicy: Retain
        csi:
          driver: ossplugin.csi.alibabacloud.com
          volumeHandle: pv-oss # 需要和PV名字一致。
          volumeAttributes:
            bucket: "oss"
            url: "oss-cn-hangzhou.aliyuncs.com"
            otherOpts: "-o umask=022 -o max_stat_cache_size=0 -o allow_other"
            authType: "rrsa"
            roleName: "demo-role-for-rrsa"

      參數	描述
      name	PV的名稱。
      labels	配置PV的標籤。
      storage	OSS的可使用量。
      accessModes	配置訪問模式，支援ReadOnlyMany和ReadWriteMany。 選擇ReadOnlyMany時，ossfs將以唯讀模式掛載OSS Bucket。
      persistentVolumeReclaimPolicy	PV回收策略。
      driver	定義驅動類型。取值為ossplugin.csi.alibabacloud.com，表示使用OSS CSI外掛程式。
      volumeHandle	配置PV的名稱。
      bucket	需要掛載的OSS Bucket。
      url	掛載OSS的接入網域名稱。 掛載節點和Bucket相同地區時，請使用私網地址。 掛載節點和Bucket不同地區時，請使用公網地址。 禁止使用VPC網路。 不同網域名稱訪問格式如下： 內網訪問網域名稱格式：http://oss-{{regionName}}-internal.aliyuncs.com或https://oss-{{regionName}}-internal.aliyuncs.com。 外網訪問網域名稱格式：http://oss-{{regionName}}.aliyuncs.com或https://oss-{{regionName}}.aliyuncs.com。
      otherOpts	您可以為OSS儲存卷輸入定製化參數，格式為-o *** -o ***，例如-o umask=022 -o max_stat_cache_size=0 -o allow_other。 umask：用於更改ossfs讀檔案的許可權。例如，設定umask=022後，ossfs檔案的許可權都會變更為755。通過SDK、OSS控制台等其他方式上傳的檔案在ossfs中預設許可權均為640。因此，建議您在讀寫分離情境中配置umask許可權。 max_stat_cache_size：用於指定檔案中繼資料的緩衝空間，可緩衝多少個檔案的中繼資料。中繼資料快取可加快ls操作速度。但若通過其他例如OSS、SDK、控制台、ossutil等方式修改檔案，可能會導致中繼資料未被及時更新。 allow_other：賦予電腦上其他使用者訪問掛載目錄的許可權，但不包含目錄內的檔案。 更多選擇性參數，請參見ossfs掛載選項說明。
      path	表示掛載時相對Bucket根檔案的目錄結構，預設為/（v1.14.8.32-c77e277b-aliyun及之後版本支援）。 ossfs 1.91版本前，該路徑需在OSS側預先建立，詳情請參考ossfs 1.91及以上版本新功能介紹及效能壓測。
      authType	配置為rrsa，聲明使用RRSA方式鑒權。
      roleName	配置為以上（可選）步驟一：建立RAM角色中已建立或修改的RAM角色名稱。若您需要為不同的PV配置不同的許可權，可以建立不同的RAM角色，在PV中配置不同的roleName。

      說明

      如果您需要在RRSA鑒權方式中使用指定的ARNs或ServiceAccount，相關操作，請參見如何在RRSA鑒權方式中使用指定的ARNs或ServiceAccount？。

   2. 執行以下命令，在PV中配置RRSA進行許可權認證。

      kubectl create -f pv-rrsa.yaml

2. 執行以下命令建立靜態卷PVC。

   kubectl create -f pvc-oss.yaml

   以下為建立靜態卷PVC的pvc-oss.yaml樣本檔案。

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pvc-oss
   spec:
     accessModes:
       - ReadOnlyMany
     resources:
       requests:
         storage: 5Gi
     selector:
       matchLabels:
         alicloud-pvname: pv-oss

   參數	說明
   name	PVC的名稱。
   accessModes	配置訪問模式，支援ReadOnlyMany和ReadWriteMany。 選擇ReadOnlyMany時，ossfs將以唯讀模式掛載OSS Bucket。
   storage	聲明應用使用量，不能大於儲存卷的總量。
   alicloud-pvname	通過標籤關聯PV，與PV標籤保持一致。

   在叢集管理頁左側導覽列選擇儲存 > 儲存聲明，在儲存聲明頁面可以看到建立的PVC。

步驟四：建立應用

建立一個名為oss-static的應用並掛載PVC。

執行以下命令建立oss-static.yaml。

kubectl create -f oss-static.yaml

以下為建立應用oss-static.yaml樣本檔案。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: oss-static
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        volumeMounts:
          - name: pvc-oss
            mountPath: "/data"
          - name: pvc-oss
            mountPath: "/data1"
        livenessProbe:
          exec:
            command:
            - sh
            - -c
            - cd /data
          initialDelaySeconds: 30
          periodSeconds: 30
      volumes:
        - name: pvc-oss
          persistentVolumeClaim:
            claimName: pvc-oss

• livenessProbe：配置健全狀態檢查。更多資訊，請參見OSS儲存卷概述。

• mountPath：OSS在容器中掛載的位置。

• claimName：PVC的名稱，用於綁定PVC。

通過RAM使用者AccessKey鑒權方式掛載

kubectl create -f oss-static.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: oss-static
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        volumeMounts:
          - name: pvc-oss
            mountPath: "/data"
          - name: pvc-oss
            mountPath: "/data1"
        livenessProbe:
          exec:
            command:
            - sh
            - -c
            - cd /data
          initialDelaySeconds: 30
          periodSeconds: 30
      volumes:
        - name: pvc-oss
          persistentVolumeClaim:
            claimName: pvc-oss

驗證OSS的持久化儲存和共用儲存

1. 查看部署oss-static應用的Pod和OSS檔案。

   1. 執行以下命令，查看部署的oss-static應用所在Pod的名稱。

      kubectl get pod

      預期輸出：

      NAME                             READY   STATUS    RESTARTS   AGE
      oss-static-66fbb85b67-d****      1/1     Running   0          1h
      oss-static-66fbb85b67-l****      1/1     Running   0          1h

   2. 建立tmpfile檔案。

      • 若以ReadWriteMany方式掛載，執行以下命令，在/data路徑下建立tmpfile檔案。

        kubectl exec oss-static-66fbb85b67-d**** -- touch /data/tmpfile
        kubectl exec oss-static-66fbb85b67-l**** -- touch /data/tmpfile

      • 若以ReadOnlyMany方式掛載，可通過OSS控制台、cp（上傳檔案）等方式上傳tmpfile檔案至OSS Bucket對應路徑。

2. 執行以下命令，查看oss-static-66fbb85b67-d****中/data路徑，以及oss-static-66fbb85b67-l****中/data1下的檔案。

   kubectl exec oss-static-66fbb85b67-d**** -- ls /data | grep tmpfile
   kubectl exec oss-static-66fbb85b67-l**** -- ls /data1 | grep tmpfile

   預期輸出：

   tmpfile

   預期輸出表明，兩個Pod的掛載路徑下均存在此檔案，說明兩個Pod共用資料。

   說明

   若您無法看到預期輸出，請確認CSI組件版本為v1.20.7及以上版本。更多資訊，請參見csi-plugin。

3. 執行以下命令，刪除名稱為oss-static-66fbb85b67-d****的Pod。

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

   預期輸出：

   pod "oss-static-66fbb85b67-d****" deleted

4. 驗證Pod刪除後，儲存空間裡建立的檔案是否還存在。

   1. 執行以下命令，查看重建的Pod名稱。

      kubectl get pod

      預期輸出：

      NAME                             READY   STATUS    RESTARTS   AGE
      oss-static-66fbb85b67-l****      1/1     Running   0          1h
      oss-static-66fbb85b67-z****      1/1     Running   0          40s

   2. 執行以下命令，查看/data路徑下的檔案。

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

      預期輸出：

      tmpfile

      預期輸出表明，temfile檔案仍然存在，說明OSS的資料可持久化儲存。