Kubernetes 的本機持久卷進入 Beta 階段

Kubernetes 1.10 中的 本機持久性卷冊 Beta 功能，讓您可以在 StatefulSet 中利用本機磁碟。您可以將直接連接的本機磁碟指定為 PersistentVolume，並在 StatefulSet 中使用它們，以及先前僅支援遠端卷冊類型的相同 PersistentVolumeClaim 物件。

持久性儲存對於執行具狀態應用程式非常重要，而 Kubernetes 已透過 StatefulSet、PersistentVolumeClaim 和 PersistentVolume 支援這些工作負載。這些基本元件已良好地支援遠端卷冊類型，其中可以從叢集中的任何節點存取卷冊，但不支援本機卷冊，其中只能從特定節點存取卷冊。隨著在 Kubernetes 中執行更多工作負載的需求增加，在複寫、具狀態工作負載中使用本機、快速 SSD 的需求也隨之增加。

解決 hostPath 挑戰

先前透過 hostPath 卷冊存取本機儲存的機制存在許多挑戰。hostPath 卷冊難以在生產環境中大規模使用：運營商在使用 hostPath 卷冊時，需要注意本機磁碟管理、拓撲和個別 Pod 的排程，並且無法使用許多 Kubernetes 功能 (例如 StatefulSet)。現有的 Helm chart 使用遠端卷冊，無法輕易移植以使用 hostPath 卷冊。本機持久性卷冊功能旨在解決 hostPath 卷冊的可移植性、磁碟記帳和排程挑戰。

免責聲明

在詳細介紹如何使用本機持久性卷冊之前，請注意本機卷冊不適用於大多數應用程式。使用本機儲存會將您的應用程式綁定到該特定節點，使您的應用程式更難以排程。如果該節點或本機卷冊遇到故障且變得無法存取，則該 Pod 也會變得無法存取。此外，許多雲端供應商並未為本機儲存提供廣泛的資料持久性保證，因此您可能會在某些情況下遺失所有資料。

由於這些原因，大多數應用程式應繼續使用高可用性、可遠端存取、持久性儲存。

適合的工作負載

適用於本機儲存的一些使用案例包括

• 可以利用資料重力進行快速處理的資料集快取
• 跨多個節點分片或複寫資料的分散式儲存系統。範例包括分散式資料儲存庫 (如 Cassandra) 或分散式檔案系統 (如 Gluster 或 Ceph)。

適合的工作負載可以容忍節點故障、資料無法使用和資料遺失。它們為叢集的其餘部分提供關鍵、延遲敏感性基礎架構服務，並且應以高於其他工作負載的優先順序執行。

啟用更智慧的排程和卷冊綁定

管理員必須為本機持久性卷冊啟用更智慧的排程。在建立本機持久性卷冊的任何 PersistentVolumeClaim 之前，必須建立 StorageClass，並將 volumeBindingMode 設定為「WaitForFirstConsumer」

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

此設定告知 PersistentVolume 控制器不要立即綁定 PersistentVolumeClaim。相反地，系統會等到需要使用卷冊的 Pod 被排程。然後排程器會選擇適當的本機 PersistentVolume 進行綁定，同時考慮 Pod 的其他排程限制和策略。這確保初始卷冊綁定與任何 Pod 資源需求、選取器、親和性和反親和性策略等相容。

請注意，Beta 版不支援動態佈建。所有本機 PersistentVolume 都必須靜態建立。

建立本機持久性卷冊

對於此初始 Beta 版本，本機磁碟必須首先由管理員預先分割、格式化並掛載在本機節點上。也支援共用檔案系統上的目錄，但也必須在使用前建立。

設定本機卷冊後，您可以為其建立 PersistentVolume。在此範例中，本機卷冊掛載在節點「my-node」上的「/mnt/disks/vol1」

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-local-pv
spec:
  capacity:
    storage: 500Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /mnt/disks/vol1
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - my-node

請注意，PersistentVolume 物件中有一個新的 nodeAffinity 欄位：這是 Kubernetes 排程器如何理解此 PersistentVolume 綁定到特定節點的方式。nodeAffinity 是本機 PersistentVolume 的必要欄位。

當像這樣手動建立本機卷冊時，唯一支援的 persistentVolumeReclaimPolicy 是「Retain」。當 PersistentVolume 從 PersistentVolumeClaim 釋放時，管理員必須手動清理並重新設定本機卷冊以供重複使用。

自動化本機卷冊建立和刪除

手動建立和清理本機卷冊是一項繁重的管理負擔，因此我們編寫了一個簡單的本機卷冊管理器來自動化其中一些部分。它在 external-storage repo 中作為一個可選程式提供，您可以將其部署在叢集中，包括有關如何運行的說明和範例部署規範。

若要使用此功能，本機卷冊仍必須首先由管理員設定並掛載在本機節點上。管理員需要將本機卷冊掛載到本機卷冊管理器可辨識的可設定「探索目錄」中。支援共用檔案系統上的目錄，但它們必須綁定掛載到探索目錄中。

此本機卷冊管理器監控探索目錄，尋找任何新的掛載點。管理器會為其偵測到的任何新掛載點建立具有適當 storageClassName、路徑、nodeAffinity 和容量的 PersistentVolume 物件。這些 PersistentVolume 物件最終可以由 PersistentVolumeClaim 宣告，然後掛載在 Pod 中。

在 Pod 完成使用卷冊並刪除其 PersistentVolumeClaim 後，本機卷冊管理器會透過從中刪除所有檔案來清理本機掛載，然後刪除 PersistentVolume 物件。這會觸發探索週期：為卷冊建立新的 PersistentVolume，並且可以由新的 PersistentVolumeClaim 重複使用。

一旦管理員最初設定本機卷冊掛載，此本機卷冊管理器就會接管 PersistentVolume 生命週期的其餘部分，而無需任何進一步的管理員介入。

在 Pod 中使用本機卷冊

在完成所有管理員工作後，使用者實際上如何將本機卷冊掛載到他們的 Pod 中？幸運的是，從使用者的角度來看，本機卷冊可以透過與任何其他 PersistentVolume 類型完全相同的方式請求：透過 PersistentVolumeClaim。只需在 PersistentVolumeClaim 物件中指定本機卷冊的適當 StorageClassName，系統就會處理其餘部分！

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: example-local-claim
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: local-storage
  resources:
    requests:
      storage: 500Gi

或在 StatefulSet 中作為 volumeClaimTemplate

kind: StatefulSet
...
 volumeClaimTemplates:
  - metadata:
      name: example-local-claim
    spec:
      accessModes:
      - ReadWriteOnce
      storageClassName: local-storage
      resources:
        requests:
          storage: 500Gi

文件

Kubernetes 網站提供 本機持久性卷冊 的完整文件。

未來增強功能

本機持久性卷冊 Beta 功能遠非完整。正在開發中的一些值得注意的增強功能

• 從 1.10 開始，本機原始區塊卷冊作為 Alpha 功能提供。這對於需要直接存取區塊裝置並管理其自身資料格式的工作負載非常有用。
• 使用 LVM 動態佈建本機卷冊正在設計中，Alpha 實作將在未來版本中推出。只要工作負載的效能要求可以容忍共用磁碟，這將消除目前管理員預先分割、格式化和掛載本機卷冊的需求。

互補功能

Pod 優先順序和搶佔 是另一個與本機持久性卷冊互補的 Kubernetes 功能。當您的應用程式使用本機儲存時，必須將其排程到本機卷冊所在的特定節點。您可以為本機儲存工作負載提供高優先順序，因此如果該節點空間不足以執行您的工作負載，Kubernetes 可以搶佔較低優先順序的工作負載，以便為其騰出空間。

Pod 中斷預算 對於那些必須維持仲裁的工作負載也非常重要。為您的工作負載設定中斷預算可確保它不會因自願中斷事件 (例如升級期間的節點排空) 而低於仲裁。

Pod 親和性和反親和性 可確保您的工作負載保持共置或分散在整個故障域中。如果您在單一節點上有多個可用的本機持久性卷冊，則最好指定 Pod 反親和性策略，以將您的工作負載分散到各個節點。請注意，如果您希望多個 Pod 共用相同的本機持久性卷冊，則無需指定 Pod 親和性策略。排程器了解本機持久性卷冊的本機性限制，並將您的 Pod 排程到正確的節點。

參與其中

如果您對此功能有任何意見回饋，或有興趣參與設計和開發，請加入 Kubernetes 儲存特殊興趣小組 (SIG)。我們正在快速成長，並且隨時歡迎新的貢獻者。

特別感謝來自多家公司所有協助將此功能帶入 Beta 版的貢獻者，包括 Cheng Xing (verult)、David Zhu (davidz627)、Deyuan Deng (ddysher)、Dhiraj Hedge (dhirajh)、Ian Chakeres (ianchakeres)、Jan Šafránek (jsafrane)、Matthew Wong (wongma7)、Michelle Au (msau42)、Serguei Bezverkhi (sbezverk) 和 Yuquan Ren (nickrenren)。

• ←上一篇
下一篇→