GKE 永久磁碟區與動態佈建


本頁面提供 Google Kubernetes Engine (GKE) 中永久磁碟區 (PV)、永久磁碟區要求 (PVC) 和儲存空間類別的總覽。重點介紹 Compute Engine 永久磁碟所支援的儲存空間。

您將瞭解如何有效建立、管理及排解 GKE 叢集內的永久儲存空間問題,確保資料安全、高可用性和最佳效能。

本頁面適用於負責建立及分配儲存空間、設定及管理資料安全、保護、存取權和權限的儲存空間專家。如要進一步瞭解我們在Google Cloud 內容中提及的常見角色和範例工作,請參閱「常見的 GKE Enterprise 使用者角色和工作」。

透過 PersistentVolume

PersistentVolume 資源可用於管理叢集中持久可用的儲存空間。在 GKE 中,PersistentVolume 通常是由永久磁碟提供支援。

請改用 NFS 等其他儲存空間解決方案。Filestore 是Google Cloud上的 NFS 解決方案。如要瞭解如何將 Filestore 執行個體設為 GKE 叢集的 NFS PV 解決方案,請參閱 Filestore 說明文件中的「透過 Filestore CSI 驅動程式存取 Filestore 執行個體」。

PersistentVolume 的生命週期是由 Kubernetes 代管。PersistentVolume 可以動態佈建;您不必手動建立及刪除輔助儲存空間。

PersistentVolume 資源是獨立存在的叢集資源,與 Pod 無關。也就是說,當叢集有所變更,以及 Pod 重新建立與遭到刪除時,PersistentVolume 代表的磁碟和資料仍會繼續保留。PersistentVolume 資源可以透過 PersistentVolumeClaims 動態佈建,或由叢集管理員明確建立。

如要進一步瞭解 PersistentVolume 資源,請參閱 Kubernetes 永久磁碟區說明文件永久磁碟區 API 參考資料

PersistentVolumeClaim

PersistentVolumeClaim 是向 PersistentVolume 資源提出的請求和要求。PersistentVolumeClaim 物件會請求 PersistentVolume 的特定大小、存取模式及 StorageClass。如果符合該項請求的 PersistentVolume 存在或可供佈建,則 PersistentVolumeClaim 會繫結至該 PersistentVolume

Pod 使用要求所提供的磁碟區。叢集會檢查要求以找出繫結的磁碟區,然後為 Pod 掛接該磁碟區。

可攜性是使用 PersistentVolumesPersistentVolumeClaims 的另一項好處。您可以在不同的叢集和環境中輕鬆使用相同的 Pod 規格,因為 PersistentVolume 是實際輔助儲存空間的介面。

StorageClasses

Compute Engine 永久磁碟 Container Storage Interface (CSI) 驅動程式 之類的磁碟區實作必須透過 StorageClass 資源進行設定。

GKE 會為您建立預設的 StorageClass,這個級別採用平衡型永久磁碟類型 (ext4)。如果 PersistentVolumeClaim 未指定 StorageClassName,系統會使用預設的 StorageClass。您可以將指定的預設 StorageClass 替換成您自己的 StorageClass。如需操作說明,請參閱「變更預設 StorageClass」。

您可以建立自己的 StorageClass 資源,說明不同級別的儲存空間。例如,級別可以對應到服務品質層級或備份政策。在其他儲存系統中,此概念有時稱為「設定檔」。

如果您使用含有 Windows 節點集區的叢集,則必須建立 StorageClass 並在 PersistentVolumeClaim 中指定 StorageClassName,因為 Windows 不支援預設的 fstype (ext4)。如果您使用 Compute Engine 永久磁碟,則必須使用 NTFS 做為檔案儲存類型。

定義 StorageClass 時,您必須列出佈建工具。 在 GKE 上,建議使用下列其中一個佈建器:

動態佈建 PersistentVolumes

在大多數情況下,您不需要直接設定 PersistentVolume 物件或建立 Compute Engine 永久磁碟。您可以改為建立 PersistentVolumeClaim,Kubernetes 就會自動佈建永久磁碟。

下列資訊清單提供 30 gibibyte (GiB) 儲存空間的磁碟請求說明,該磁碟的存取模式允許在讀取/寫入模式中一次由一個節點掛接。此外,這個指令也會建立 Pod,將 PersistentVolumeClaim 做為磁碟區使用。

# pvc-pod-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-demo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi
  storageClassName: standard-rwo
---
kind: Pod
apiVersion: v1
metadata:
  name: pod-demo
spec:
  volumes:
    - name: pvc-demo-vol
      persistentVolumeClaim:
       claimName: pvc-demo
  containers:
    - name: pod-demo
      image: nginx
      resources:
        limits:
          cpu: 10m
          memory: 80Mi
        requests:
          cpu: 10m
          memory: 80Mi
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: pvc-demo-vol

使用 kubectl apply -f pvc-pod-demo.yaml 建立這個 PersistentVolumeClaim 物件時,Kubernetes 會動態建立對應的 PersistentVolume 物件。

由於儲存空間類別 standard-rwo 使用磁碟區繫結模式 WaitForFirstConsumer,因此系統會等到排定 Pod 使用磁碟區時,才會建立 PersistentVolume

以下範例顯示建立的 PersistentVolume

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: pd.csi.storage.gke.io
  finalizers:
  - kubernetes.io/pv-protection
  - external-attacher/pd-csi-storage-gke-io
  name: pvc-c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  uid: d52af557-edf5-4f96-8e89-42a3008209e6
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 30Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: pvc-demo
    namespace: default
    uid: c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  csi:
    driver: pd.csi.storage.gke.io
    csi.storage.k8s.io/fstype: ext4
    volumeAttributes:
      storage.kubernetes.io/csiProvisionerIdentity: 1660085000920-8081-pd.csi.storage.gke.io
    volumeHandle: projects/xxx/zones/us-central1-c/disks/pvc-c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.gke.io/zone
          operator: In
          values:
          - us-central1-c
  persistentVolumeReclaimPolicy: Delete
  storageClassName: standard-rwo
  volumeMode: Filesystem
status:
  phase: Bound

假設您尚未替換儲存空間類別 standard-rwo,這個 PersistentVolume 是由新的空白 Compute Engine 永久磁碟支援。

刪除永久儲存空間

根據預設,刪除動態佈建磁碟區 (例如 Compute Engine 永久磁碟) 的 PersistentVolumeClaim 時,系統會一併刪除 PersistentVolume 物件和實際的支援磁碟。這項行為是由 StorageClass 和 PersistentVolume 中的回收政策控管,可設為預設的 DeleteRetain。詳情請參閱 Kubernetes 說明文件中的回收

為避免或減少刪除永久儲存空間時發生資料遺失,建議您啟用 GKE 備份,並定期備份 GKE 叢集,包括已部署的工作負載及其資料。

在刪除叢集時管理永久儲存空間

刪除 GKE 叢集時,GKE 會保留具有 DeleteRetain 回收政策的資源。PersistentVolume

如要在刪除叢集時移除 PersistentVolume 資源,可以手動刪除 PersistentVolumeClaim 資源的命名空間,這會觸發刪除具有 Delete 政策的 PersistentVolume 物件。或者,您也可以刪除個別 PersistentVolumeClaim 資源。 不過,GKE 不會等待這些刪除活動完成,就會開始刪除叢集。因此,如果您刪除命名空間,然後立即刪除叢集,系統可能不會刪除具有 Delete 政策的 PersistentVolume 資源。

叢集刪除後,您可以在控制台中查看其餘 PersistentVolume Google Cloud 資源。

如要查看任何未使用的資源 (例如未使用的 PersistentVolume 資源),可以查看閒置資源的建議

存取模式

PersistentVolume 資源支援下列存取模式

  • ReadWriteOnce:磁碟區可由單個節點以讀取/寫入方式掛接。
  • ReadOnlyMany:可由多個節點掛接成唯讀磁碟區。
  • ReadWriteMany:可由多個節點掛接成讀取/寫入磁碟區。 Compute Engine 永久磁碟支援的 PersistentVolume 資源不支援此存取模式。
  • ReadWriteOncePod:磁碟區只能由單一 Pod 以讀取/寫入方式掛接。

以 ReadOnlyMany 模式使用 Compute Engine 永久磁碟

ReadWriteOnce 是最常見的永久磁碟使用情況,可做為大部分應用程式的預設存取模式。Compute Engine 永久磁碟也支援 ReadOnlyMany 模式,因此許多應用程式或同一個應用程式的多個備用資源可以同時使用相同的磁碟。其中一個範例用法便是在多個備用資源中提供靜態內容。

如需操作說明,請參閱「使用具備多個讀取器的永久磁碟」。

將既有的永久磁碟做為 PersistentVolumes 使用

動態佈建的 PersistentVolume 資源在建立時為空白。如果您在現有的 Compute Engine 永久磁碟中填入資料,則可以手動建立對應的 PersistentVolume 資源,將該磁碟加入您的叢集。永久磁碟必須位於與叢集節點相同的區域

請參閱如何建立既有永久磁碟支援的永久磁碟區範例

Deployment 與 StatefulSet 的比較

您可以在更高階的控制器中使用 PersistentVolumeClaimVolumeClaim 範本,例如 DeploymentStatefulSets

Deployment 是專為「無狀態應用程式」而設計,因此 Deployment 的所有備用資源均共用相同的 PersistentVolumeClaim。由於建立的 Pod 副本彼此相同,因此只有具備 ReadWriteMany 模式的磁碟區適用於這項設定。

即使 Deployment 只有一個使用 ReadWriteOnce 磁碟區的備用資源,也不建議使用 Deployment。這是因為部署策略會先建立第二個 Pod,然後才會在重建時關閉第一個 Pod。這個做法會因為 ReadWriteOnce 磁碟區已在使用中,使得第二個 Pod 無法啟動,而第一個 Pod 又因第二個 Pod 尚未啟動而無法移除,最終導致部署作業發生死鎖而失敗。請改用 StatefulSet 搭配 ReadWriteOnce 磁碟區。

若要部署有狀態應用程式且需要每個備用資源有一個專用磁碟區,則建議使用 StatefulSet 方法。透過 StatefulSet 方法與 PersistentVolumeClaim 範本搭配使用,您的應用程式就可以透過與每個備用資源 Pod 相關聯的專用 PersistentVolumeClaim,自動擴充資源配置。

區域性永久磁碟

地區永久磁碟是多區域資源,可在同一個地區的兩個區域之間複製資料,用法與區域永久磁碟類似。萬一發生區域服務中斷,或某個區域的叢集節點無法排程,Kubernetes 可使用此磁碟區將工作負載容錯移轉至另一個區域。您可以使用地區永久磁碟,針對 GKE 上的有狀態工作負載建構具有高度可用性的解決方案。您必須確認主要區域和容錯移轉區域均已設定足夠的資源容量,可以執行此工作負載。

針對資料庫這類需要高可用性和高效能的應用程式,您可以選擇使用地區 SSD 永久磁碟。詳情請參閱區塊儲存空間效能比較

與區域永久磁碟相同,地區永久磁碟可以視需求動態佈建,或由叢集管理員事先手動佈建。如要瞭解如何新增地區永久磁碟,請參閱佈建地區永久磁碟

永久磁碟中的可用區

區域永久磁碟是區域資源,地區永久磁碟則是多區域資源。為叢集新增永久儲存空間時,除非指定了區域,否則 GKE 會將磁碟指派給單一區域。GKE 會隨機選擇區域。佈建永久磁碟後,任何參照這個磁碟的 Pod 都會排定到與永久磁碟相同的區域。不過,Pod 或 Deployment 本身無法辨識現有永久磁碟的可用區。如要確保 Pod 能使用預先存在的永久磁碟正確排程,請在 Pod 或 Deployment 規格中使用區域放置方法 (例如 nodeAffinity),指定適當的區域。

磁碟區繫結模式 WaitForFirstConsumer

如果您在叢集中動態佈建永久磁碟,建議您在 StorageClass 中設定WaitForFirstConsumer 磁碟區繫結模式。這項設定會指示 Kubernetes 在 Pod 排程的相同區域中,佈建永久磁碟。並遵守 Pod 排程限制,例如反相依性和節點選取器。區域的互斥性可讓 StatefulSet Pod 連同對應的磁碟散佈到多個區域。

以下範例 StorageClass 說明如何佈建區域永久磁碟,並設定 WaitForFirstConsumer

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  csi.storage.k8s.io/fstype: ext4
volumeBindingMode: WaitForFirstConsumer

如需使用地區永久磁碟的範例,請參閱「佈建地區永久磁碟」。

後續步驟