儲存類別

本文件描述 Kubernetes 中 StorageClass 的概念。建議您先熟悉磁碟區持久磁碟區

StorageClass 提供管理員描述他們提供的儲存類別的方式。不同的類別可以對應到服務品質等級、備份策略或叢集管理員決定的任意策略。Kubernetes 本身對於類別代表什麼並無既定看法。

Kubernetes 的儲存類別概念與其他一些儲存系統設計中的「設定檔」相似。

StorageClass 物件

每個 StorageClass 都包含欄位 provisionerparametersreclaimPolicy,當需要動態佈建屬於該類別的 PersistentVolume 以滿足 PersistentVolumeClaim (PVC) 時,會使用這些欄位。

StorageClass 物件的名稱非常重要,使用者可以透過名稱請求特定的類別。管理員在首次建立 StorageClass 物件時設定類別的名稱和其他參數。

身為管理員,您可以指定預設 StorageClass,該類別會套用至任何未請求特定類別的 PVC。如需更多詳細資訊,請參閱PersistentVolumeClaim 概念

以下是 StorageClass 的範例

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: low-latency
  annotations:
    storageclass.kubernetes.io/is-default-class: "false"
provisioner: csi-driver.example-vendor.example
reclaimPolicy: Retain # default value is Delete
allowVolumeExpansion: true
mountOptions:
  - discard # this might enable UNMAP / TRIM at the block storage layer
volumeBindingMode: WaitForFirstConsumer
parameters:
  guaranteedReadWriteLatency: "true" # provider-specific

預設 StorageClass

您可以將 StorageClass 標記為叢集的預設類別。如需設定預設 StorageClass 的指示,請參閱變更預設 StorageClass

當 PVC 未指定 storageClassName 時,將會使用預設 StorageClass。

如果您在叢集中多個 StorageClass 上將storageclass.kubernetes.io/is-default-class註解設定為 true,然後您建立未設定 storageClassName 的 PersistentVolumeClaim,Kubernetes 將會使用最近建立的預設 StorageClass。

您可以建立 PersistentVolumeClaim,而無需為新的 PVC 指定 storageClassName,即使您的叢集中沒有預設 StorageClass,您也可以這樣做。在這種情況下,新的 PVC 會依照您的定義建立,並且該 PVC 的 storageClassName 會保持未設定狀態,直到預設類別可用為止。

您可以擁有沒有任何預設 StorageClass 的叢集。如果您未將任何 StorageClass 標記為預設 (並且例如雲端供應商沒有為您設定預設類別),則 Kubernetes 無法為需要它的 PersistentVolumeClaim 套用該預設值。

如果或當預設 StorageClass 變得可用時,控制平面會識別任何沒有 storageClassName 的現有 PVC。對於 storageClassName 的值為空或沒有此鍵的 PVC,控制平面接著會更新這些 PVC,以將 storageClassName 設定為符合新的預設 StorageClass。如果您有 storageClassName"" 的現有 PVC,並且您配置了預設 StorageClass,則此 PVC 不會被更新。

為了保持與 storageClassName 設定為 "" 的 PV 繫結 (當預設 StorageClass 存在時),您需要將相關聯 PVC 的 storageClassName 設定為 ""

佈建器

每個 StorageClass 都有一個佈建器,用於決定使用哪個磁碟區外掛程式來佈建 PV。此欄位必須指定。

磁碟區外掛程式內部佈建器配置範例
AzureFileAzure 檔案
CephFS--
FC--
FlexVolume--
iSCSI--
Local-Local
NFS-NFS
PortworxVolumePortworx 磁碟區
RBD-Ceph RBD
VsphereVolumevSphere

您不限於指定此處列出的「內部」佈建器 (其名稱以 "kubernetes.io" 為字首,並與 Kubernetes 一起發佈)。您也可以執行和指定外部佈建器,這些佈建器是獨立的程式,遵循 Kubernetes 定義的規格。外部佈建器的作者可以完全自行決定其程式碼的位置、佈建器的發佈方式、需要如何執行、它使用哪個磁碟區外掛程式 (包括 Flex) 等。儲存庫 kubernetes-sigs/sig-storage-lib-external-provisioner 包含一個用於編寫外部佈建器的程式庫,該程式庫實作了規格的大部分內容。一些外部佈建器列在儲存庫 kubernetes-sigs/sig-storage-lib-external-provisioner 下。

例如,NFS 不提供內部佈建器,但可以使用外部佈建器。在某些情況下,第三方儲存廠商也會提供自己的外部佈建器。

回收策略

由 StorageClass 動態建立的 PersistentVolume 將具有類別的 reclaimPolicy 欄位中指定的回收策略,它可以是 DeleteRetain。如果在建立 StorageClass 物件時未指定 reclaimPolicy,則預設為 Delete

手動建立並透過 StorageClass 管理的 PersistentVolume 將具有它們在建立時指派的任何回收策略。

磁碟區擴充

PersistentVolume 可以配置為可擴充。這允許您透過編輯對應的 PVC 物件來調整磁碟區大小,請求更大的儲存量。

當底層 StorageClass 的欄位 allowVolumeExpansion 設定為 true 時,以下類型的磁碟區支援磁碟區擴充。

磁碟區類型及其所需的 Kubernetes 版本表
磁碟區類型磁碟區擴充所需的 Kubernetes 版本
Azure 檔案1.11
CSI1.24
FlexVolume1.13
Portworx1.11
rbd1.11

掛載選項

由 StorageClass 動態建立的 PersistentVolume 將會具有在該類別的 mountOptions 欄位中指定的掛載選項。

如果 Volume 外掛程式不支援掛載選項,但指定了掛載選項,則佈建將會失敗。掛載選項不會在類別或 PV 上進行驗證。如果掛載選項無效,PV 掛載將會失敗。

Volume 綁定模式

volumeBindingMode 欄位控制何時應發生Volume 綁定和動態佈建。當未設定時,預設會使用 Immediate 模式。

Immediate 模式表示 PersistentVolumeClaim 建立後,就會立即發生 Volume 綁定和動態佈建。對於拓撲受限且無法從叢集中所有節點全域存取的儲存後端,PersistentVolume 將會在不知道 Pod 的排程需求的情況下進行綁定或佈建。這可能會導致 Pod 無法排程。

叢集管理員可以透過指定 WaitForFirstConsumer 模式來解決此問題,此模式會延遲 PersistentVolume 的綁定和佈建,直到使用 PersistentVolumeClaim 的 Pod 被建立。PersistentVolume 將會根據 Pod 的排程約束所指定的拓撲來選取或佈建。這些約束包括但不限於資源需求節點選取器Pod 親和性和反親和性,以及污點和容忍度

以下外掛程式支援使用動態佈建的 WaitForFirstConsumer

  • CSI Volume,前提是特定的 CSI 驅動程式支援此功能

以下外掛程式支援使用預先建立的 PersistentVolume 綁定的 WaitForFirstConsumer

  • CSI Volume,前提是特定的 CSI 驅動程式支援此功能
  • local
apiVersion: v1
kind: Pod
metadata:
  name: task-pv-pod
spec:
  nodeSelector:
    kubernetes.io/hostname: kube-01
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

允許的拓撲

當叢集運營商指定 WaitForFirstConsumer Volume 綁定模式時,在大多數情況下不再需要將佈建限制為特定的拓撲。但是,如果仍然需要,可以指定 allowedTopologies

此範例示範如何將佈建 Volume 的拓撲限制為特定區域,並且應該用作支援外掛程式的 zonezones 參數的替代方案。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner:  example.com/example
parameters:
  type: pd-standard
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.kubernetes.io/zone
    values:
    - us-central-1a
    - us-central-1b

參數

StorageClass 具有描述屬於該儲存類別的 Volume 的參數。根據 provisioner,可能會接受不同的參數。當省略參數時,會使用一些預設值。

一個 StorageClass 最多可以定義 512 個參數。參數物件(包括其鍵和值)的總長度不能超過 256 KiB。

AWS EBS

Kubernetes 1.32 不包含 awsElasticBlockStore Volume 類型。

AWSElasticBlockStore 內建儲存驅動程式已在 Kubernetes v1.19 版本中被棄用,然後在 v1.27 版本中完全移除。

Kubernetes 專案建議您改用外部的 AWS EBS 儲存驅動程式。

以下是 AWS EBS CSI 驅動程式的 StorageClass 範例

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  csi.storage.k8s.io/fstype: xfs
  type: io1
  iopsPerGB: "50"
  encrypted: "true"
  tagSpecification_1: "key1=value1"
  tagSpecification_2: "key2=value2"
allowedTopologies:
- matchLabelExpressions:
  - key: topology.ebs.csi.aws.com/zone
    values:
    - us-east-2c

tagSpecification:具有此前綴的標籤會套用至動態佈建的 EBS Volume。

AWS EFS

若要配置 AWS EFS 儲存,您可以使用外部的 AWS_EFS_CSI_DRIVER

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-92107410
  directoryPerms: "700"
  • provisioningMode:Amazon EFS 要佈建的 Volume 類型。目前,僅支援基於存取點的佈建 (efs-ap)。
  • fileSystemId:在其下建立存取點的檔案系統。
  • directoryPerms:存取點建立的根目錄的目錄權限。

如需更多詳細資訊,請參閱 AWS_EFS_CSI_Driver 動態佈建 文件。

NFS

若要配置 NFS 儲存,您可以使用內建驅動程式或 Kubernetes 的 NFS CSI 驅動程式 (建議使用)。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: example-nfs
provisioner: example.com/external-nfs
parameters:
  server: nfs-server.example.com
  path: /share
  readOnly: "false"
  • server:伺服器是 NFS 伺服器的主機名稱或 IP 位址。
  • path:NFS 伺服器匯出的路徑。
  • readOnly:一個標記,指示儲存是否將以唯讀方式掛載 (預設為 false)。

Kubernetes 不包含內部的 NFS 佈建器。您需要使用外部佈建器來為 NFS 建立 StorageClass。以下是一些範例

vSphere

vSphere StorageClass 有兩種類型的佈建器

內建佈建器已被棄用。如需有關 CSI 佈建器的更多資訊,請參閱 Kubernetes vSphere CSI 驅動程式vSphereVolume CSI 遷移

CSI 佈建器

vSphere CSI StorageClass 佈建器適用於 Tanzu Kubernetes 叢集。如需範例,請參閱 vSphere CSI 儲存庫

vCP 佈建器

以下範例使用 VMware Cloud Provider (vCP) StorageClass 佈建器。

  1. 使用使用者指定的磁碟格式建立 StorageClass。

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: fast
    provisioner: kubernetes.io/vsphere-volume
    parameters:
      diskformat: zeroedthick
    

    diskformatthinzeroedthickeagerzeroedthick。預設值:"thin"

  2. 在使用者指定的資料儲存區上使用磁碟格式建立 StorageClass。

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: fast
    provisioner: kubernetes.io/vsphere-volume
    parameters:
      diskformat: zeroedthick
      datastore: VSANDatastore
    

    datastore:使用者也可以在 StorageClass 中指定資料儲存區。Volume 將會在 StorageClass 中指定的資料儲存區上建立,在本例中為 VSANDatastore。此欄位為選填。如果未指定資料儲存區,則 Volume 將會在用於初始化 vSphere Cloud Provider 的 vSphere 設定檔中指定的資料儲存區上建立。

  3. Kubernetes 內部的儲存策略管理

    • 使用現有的 vCenter SPBM 策略

      vSphere 儲存管理最重要的功能之一是基於策略的管理。儲存策略式管理 (SPBM) 是一個儲存策略框架,可在廣泛的資料服務和儲存解決方案中提供單一的統一控制平面。SPBM 使 vSphere 管理員能夠克服預先儲存佈建的挑戰,例如容量規劃、差異化服務等級和管理容量餘裕。

      可以使用 storagePolicyName 參數在 StorageClass 中指定 SPBM 策略。

    • Kubernetes 內部的 Virtual SAN 策略支援

      Vsphere 基礎架構 (VI) 管理員將能夠在動態 Volume 佈建期間指定自訂的 Virtual SAN 儲存功能。您現在可以在動態 Volume 佈建期間以儲存功能的形式定義儲存需求,例如效能和可用性。儲存功能需求會轉換為 Virtual SAN 策略,然後在建立永久 Volume(虛擬磁碟)時推送到 Virtual SAN 層。虛擬磁碟會分散在 Virtual SAN 資料儲存區中,以滿足需求。

      您可以參閱 用於動態佈建 Volume 的儲存策略式管理,以了解有關如何使用儲存策略進行永久 Volume 管理的更多詳細資訊。

有一些 vSphere 範例,您可以嘗試將它們用於 Kubernetes 內部的 vSphere 永久 Volume 管理。

Ceph RBD (已棄用)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/rbd # This provisioner is deprecated
parameters:
  monitors: 198.19.254.105:6789
  adminId: kube
  adminSecretName: ceph-secret
  adminSecretNamespace: kube-system
  pool: kube
  userId: kube
  userSecretName: ceph-secret-user
  userSecretNamespace: default
  fsType: ext4
  imageFormat: "2"
  imageFeatures: "layering"
  • monitors:Ceph 監視器,以逗號分隔。此參數為必填。

  • adminId:能夠在池中建立映像的 Ceph 用戶端 ID。預設值為 "admin"。

  • adminSecretNameadminId 的密碼名稱。此參數為必填。提供的密碼類型必須為 "kubernetes.io/rbd"。

  • adminSecretNamespaceadminSecretName 的命名空間。預設值為 "default"。

  • pool:Ceph RBD 池。預設值為 "rbd"。

  • userId:用於映射 RBD 映像的 Ceph 用戶端 ID。預設值與 adminId 相同。

  • userSecretName:用於映射 RBD 映像的 userId 的 Ceph 密碼名稱。它必須與 PVC 位於相同的命名空間中。此參數為必填。提供的密碼類型必須為 "kubernetes.io/rbd",例如以此方式建立

    kubectl create secret generic ceph-secret --type="kubernetes.io/rbd" \
      --from-literal=key='QVFEQ1pMdFhPUnQrSmhBQUFYaERWNHJsZ3BsMmNjcDR6RFZST0E9PQ==' \
      --namespace=kube-system
    
  • userSecretNamespaceuserSecretName 的命名空間。

  • fsType:Kubernetes 支援的 fsType。預設值:"ext4"

  • imageFormat:Ceph RBD 映像格式,"1" 或 "2"。預設值為 "2"。

  • imageFeatures:此參數為選填,僅當您將 imageFormat 設定為 "2" 時才應使用。目前僅支援 layering 功能。預設值為 "",且未啟用任何功能。

Azure 磁碟

Kubernetes 1.32 不包含 azureDisk Volume 類型。

azureDisk 內建儲存驅動程式已在 Kubernetes v1.19 版本中被棄用,然後在 v1.27 版本中完全移除。

Kubernetes 專案建議您改用第三方 Azure 磁碟 儲存驅動程式。

Azure File (已棄用)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile
provisioner: kubernetes.io/azure-file
parameters:
  skuName: Standard_LRS
  location: eastus
  storageAccount: azure_storage_account_name # example value
  • skuName:Azure 儲存帳戶 SKU 層級。預設值為空。
  • location:Azure 儲存帳戶位置。預設值為空。
  • storageAccount:Azure 儲存帳戶名稱。預設值為空。如果未提供儲存帳戶,則會搜尋與資源群組關聯的所有儲存帳戶,以尋找符合 skuNamelocation 的帳戶。如果提供了儲存帳戶,則它必須與叢集位於相同的資源群組中,並且會忽略 skuNamelocation
  • secretNamespace:包含 Azure 儲存帳戶名稱和金鑰的密碼的命名空間。預設值與 Pod 相同。
  • secretName:包含 Azure 儲存帳戶名稱和金鑰的密碼的名稱。預設值為 azure-storage-account-<accountName>-secret
  • readOnly:一個標記,指示儲存是否將以唯讀方式掛載。預設值為 false,表示讀寫掛載。此設定也會影響 VolumeMounts 中的 ReadOnly 設定。

在儲存佈建期間,會為掛載憑證建立一個名為 secretName 的密碼。如果叢集同時啟用了 RBAC控制器角色,請為 clusterrole system:controller:persistent-volume-binder 新增資源 secretcreate 權限。

在多租戶環境中,強烈建議明確設定 secretNamespace 的值,否則其他使用者可能會讀取儲存帳戶憑證。

Portworx Volume (已棄用)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: portworx-io-priority-high
provisioner: kubernetes.io/portworx-volume # This provisioner is deprecated
parameters:
  repl: "1"
  snap_interval: "70"
  priority_io: "high"
  • fs:要佈局的檔案系統:none/xfs/ext4 (預設值:ext4)。
  • block_size:區塊大小,以 Kbytes 為單位 (預設值:32)。
  • repl:要提供的同步副本數,以副本因子 1..3 的形式表示 (預設值:1)。此處預期為字串,即 "1" 而不是 1
  • priority_io:決定 Volume 是從較高效能還是較低優先順序的儲存建立 high/medium/low (預設值:low)。
  • snap_interval:觸發快照的時鐘/時間間隔,以分鐘為單位。快照是根據與先前快照的差異進行增量快照,0 表示停用快照 (預設值:0)。此處預期為字串,即 "70" 而不是 70
  • aggregation_level:指定 Volume 將分散到的區塊數,0 表示非聚合 Volume (預設值:0)。此處預期為字串,即 "0" 而不是 0
  • ephemeral:指定 Volume 在卸載後是否應清除或應為永久性。emptyDir 用例可以將此值設定為 true,而 persistent volumes 用例(例如 Cassandra 等資料庫)應設定為 false,true/false (預設值 false)。此處預期為字串,即 "true" 而不是 true

Local

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner # indicates that this StorageClass does not support automatic provisioning
volumeBindingMode: WaitForFirstConsumer

本機 Volume 在 Kubernetes 1.32 中不支援動態佈建;但是,仍然應該建立 StorageClass 以延遲 Volume 綁定,直到 Pod 實際排程到適當的節點。這由 WaitForFirstConsumer Volume 綁定模式指定。

延遲 Volume 綁定允許排程器在為 PersistentVolumeClaim 選擇適當的 PersistentVolume 時,考慮 Pod 的所有排程約束。