GKE 永久磁碟區和佈建

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

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

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

透過 PersistentVolume

PersistentVolume 資源的用途為管理叢集中的耐用儲存空間。在 GKE 中，PersistentVolume 通常是由永久磁碟提供支援。

您也可以改用 NFS 等其他儲存空間解決方案。Filestore 是 Google Cloud 中的 NFS 解決方案。Google Cloud如要瞭解如何將 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 Gibibytes (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 永久磁碟支援。

刪除永久儲存空間

在動態佈建期間，您可以控制是否要在刪除 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 叢集的定期備份。

排解磁碟遭非預期刪除的問題

如果您發現基礎永久磁碟在不該刪除時遭到刪除，最常見的原因是 reclaimPolicy 欄位在 PersistentVolumeClaim 使用的 StorageClass 設定中設為 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 資源。

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

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

存取模式

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

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

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

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

如需操作說明，請參閱「使用具備多個讀取器的 Persistent Disk」。

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

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

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

Deployment 與 StatefulSet 的差異

您可以在較高層級的控制器 (例如 Deployments 或 StatefulSets) 中使用 PersistentVolumeClaim 或 VolumeClaim 範本。

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

即使是使用 ReadWriteOnce 磁碟區、只有一個副本的 Deployment，也不建議使用。這是因為預設的 Deployment 策略會在重建時，先建立第二個 Pod，再關閉第一個 Pod。由於 ReadWriteOnce 磁碟區已在使用中，因此第二個 Pod 無法啟動，而第一個 Pod 尚未移除，因此 Deployment 可能會因死結而失敗。請改用具有 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 與對應的磁碟分散在不同可用區。

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

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

後續步驟