GKE 永久磁碟區和佈建

本頁面概略介紹 Google Kubernetes Engine (GKE) 的永久磁碟區 (PV)、永久磁碟區要求 (PVC) 和 StorageClass。重點在於由 Compute Engine 永久磁碟支援的儲存空間。

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

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

透過 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 掛接該磁碟區。

可攜性是使用 PersistentVolumes 和 PersistentVolumeClaims 的另一項優勢。您可以在不同叢集和環境中使用相同的 Pod 規格，因為 PersistentVolume 是實際備份儲存空間的介面。

StorageClasses

Compute Engine 永久磁碟 Container Storage Interface (CSI) 驅動程式等磁碟區實作項目，是透過 StorageClass 資源設定。

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

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

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

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

動態佈建 PersistentVolume

大多數情況下，不需直接設定 PersistentVolume 物件或建立 Compute Engine 永久磁碟。若是改為建立 PersistentVolumeClaim，Kubernetes 即可自動佈建永久磁碟。

下列資訊清單描述了對 30 GiB 儲存空間磁碟的要求，其存取模式允許單一節點以讀寫方式掛接該磁碟。此外，也會建立將 PersistentVolumeClaim 做為磁碟區使用的 Pod。

# 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 永久磁碟支援。

刪除永久儲存空間

在動態佈建期間，您可以控制是否要在刪除 PersistentVolumeClaim (PVC) 時刪除永久儲存空間。方法是將 StorageClass 設定中的 reclaimPolicy 欄位設為 Delete 或 Retain。

  • reclaimPolicy: Delete：這是預設政策。刪除 PVC 時，系統會自動刪除 PersistentVolume (PV) 物件和基礎磁碟 (例如 Compute Engine 永久磁碟)。這項政策適用於臨時工作負載，或必須在工作完成後清除資料的法規遵循要求。

  • reclaimPolicy: Retain：如果設定這項政策，刪除 PVC 時，PV 和基礎磁碟不會刪除。PV 狀態會變更為 Released。資料會保留，但磁碟區必須由管理員手動回收，才能供新的 PVC 使用。

手動管理保留的磁碟區

當 PersistentVolume 處於 Released 狀態時，您必須手動決定如何處理基礎資料和磁碟。

  • 如要永久刪除儲存空間：您必須同時刪除 Kubernetes PersistentVolume 資源和基礎 Compute Engine 磁碟。

    1. 刪除 PersistentVolume： bash kubectl delete pv <your-pv-name>
    2. 描述 PV 的 YAML 設定檔，並尋找 volumeHandle 或類似欄位，找出基礎磁碟的名稱。
    3. 刪除 Compute Engine 永久磁碟： bash gcloud compute disks delete <your-disk-name> --zone=<your-zone>

  • 如要重複使用磁碟區：回收狀態為 Released 的磁碟區，供其他 PVC 使用，這是一項進階工作，涉及手動清理磁碟資料，以及編輯 PersistentVolume 物件，使其再次成為 Available。如要進一步瞭解詳細程序，請參閱 Kubernetes 官方說明文件中有關回收 PersistentVolume 的部分。

為避免或減少資料遺失，建議您啟用 GKE 備份，並安排定期備份 GKE 叢集。

排解磁碟意外刪除的問題

如果您發現基礎永久磁碟在不應刪除時遭到刪除，最常見的原因是 PersistentVolumeClaim 使用的 StorageClass 設定中，reclaimPolicy 欄位設為 Delete。

如要診斷這個問題，請完成下列步驟：

  1. 檢查 PVC 的 StorageClass： bash kubectl get pvc <your-pvc-name> -o jsonpath='{.spec.storageClassName}'

  2. 檢查 reclaimPolicy 欄位： bash kubectl get sc <your-storageclass-name> -o yaml

  3. 根據意圖調整政策：

    • 如果政策為 Delete，且應用程式需要保留資料，則必須更新應用程式，使用將政策設為 Retain 的 StorageClass 設定。
    • 如果政策為 Delete，且應用程式為暫時性或受限於資料清理法規遵循規則，則設定正確且運作正常。

詳情請參閱 Kubernetes 回收說明文件。

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

刪除 GKE 叢集時，GKE 會保留具有 Delete 或 Retain 回收政策的 PersistentVolume 資源。

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

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

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

存取模式

PersistentVolume 資源支援下列存取模式：

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

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

ReadWriteOnce 是永久磁碟最常見的用途，也是大多數應用程式的預設存取模式。Compute Engine 永久磁碟也支援 ReadOnlyMany 模式，因此多個應用程式或同一應用程式的多個副本可以同時使用同一個磁碟。舉例來說，您可以在多個副本中提供靜態內容。

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

使用既有的永久磁碟做為 PersistentVolume

動態佈建的 PersistentVolume 資源在建立時是空的。如果您現有的 Compute Engine 永久磁碟已填入資料，可以手動建立對應的 PersistentVolume 資源，將其導入叢集。永久磁碟必須與叢集節點位於相同的可用區。

請參閱這個範例，瞭解如何建立由預先存在的永久磁碟支援的永久磁碟區。

Deployment 與 StatefulSet

您可以在較高層級的控制器 (例如部署項目或 StatefulSets) 中，分別使用 PersistentVolumeClaim 或 VolumeClaim 範本。

Deployment 是專為無狀態應用程式設計，因此 Deployment 的所有副本都會共用相同的 PersistentVolumeClaim。由於建立的副本 Pod 彼此完全相同，因此只有 ReadWriteMany 模式的磁碟區才能在這項設定中運作。

即使是使用 ReadWriteOnce 磁碟區且只有一個副本的 Deployment，也不建議使用。這是因為預設的 Deployment 策略會在重新建立時，先建立第二個 Pod，再關閉第一個 Pod。Deployment 可能會因死結而失敗，因為 ReadWriteOnce 磁碟區已在使用中，第二個 Pod 無法啟動，而第一個 Pod 也不會移除，因為第二個 Pod 尚未啟動。請改用具有 ReadWriteOnce 磁碟區的 StatefulSet。

如要部署需要為每個副本建立專屬磁碟區的有狀態應用程式，建議使用 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 與對應的磁碟分散在不同可用區。此外，這項設定會延遲儲存空間佈建，直到能確保節點健康且可用，有助於在可用區缺乏運算能力時，減輕問題。這種延遲佈建機制可避免有狀態應用程式永久鎖定在降級可用區，導致卡在 Pending 狀態。

以下是佈建可用區永久磁碟的 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

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

後續步驟