Kubernetes 中的動態佈建與儲存類別

儲存是執行容器的關鍵部分，而 Kubernetes 提供了一些強大的基本功能來管理它。動態磁碟區佈建是 Kubernetes 獨有的功能，允許按需建立儲存磁碟區。如果沒有動態佈建，叢集管理員必須手動呼叫他們的雲端或儲存供應商來建立新的儲存磁碟區，然後建立 PersistentVolume 物件來在 Kubernetes 中表示它們。動態佈建功能消除了叢集管理員預先佈建儲存的需求。相反，它會在使用者請求時自動佈建儲存。此功能在 Kubernetes 1.2 中作為 Alpha 版本引入，並在最新版本 1.4中得到改進並升級為 Beta 版本。此版本使動態佈建更加靈活和有用。

新功能？

Alpha 版本的動態佈建僅允許在叢集中一次使用單個硬式編碼的佈建器。這表示當 Kubernetes 確定需要動態佈建儲存時，它總是使用相同的磁碟區外掛程式來進行佈建，即使叢集上有可用的多個儲存系統也是如此。要使用的佈建器是根據雲端環境推斷出來的 - AWS 的 EBS、Google Cloud 的 Persistent Disk、OpenStack 的 Cinder 和 vSphere 上的 vSphere Volumes。此外，用於佈建新儲存磁碟區的參數是固定的：只有儲存大小是可配置的。這表示所有動態佈建的磁碟區都將是相同的，除了它們的儲存大小之外，即使儲存系統公開了其他參數 (例如磁碟類型) 以在佈建期間進行配置。

雖然此功能的 Alpha 版本在實用性方面受到限制，但它讓我們能夠對這個想法「進行一些里程」並幫助確定我們想要採取的方向。

Kubernetes 1.4 中新的 Beta 版本動態佈建引入了一個新的 API 物件，StorageClass。可以定義多個 StorageClass 物件，每個物件都指定一個磁碟區外掛程式 (又名佈建器) 以用於佈建磁碟區，以及在佈建時傳遞給該佈建器的一組參數。此設計允許叢集管理員在叢集中定義和公開多種儲存類型 (來自相同或不同的儲存系統)，每種類型都具有一組自訂參數。此設計還確保終端使用者不必擔心儲存佈建方式的複雜性和細微差別，但仍然能夠從多個儲存選項中進行選擇。

我該如何使用它？

以下是如何叢集管理員公開兩個儲存層級以及使用者如何選擇和使用其中一個層級的範例。有關更多詳細資訊，請參閱參考和範例文件。

管理員配置

叢集管理員定義並部署兩個 StorageClass 物件到 Kubernetes 叢集

kind: StorageClass

apiVersion: storage.k8s.io/v1beta1

metadata:

  name: slow

provisioner: kubernetes.io/gce-pd

parameters:

  type: pd-standard

這會建立一個名為「slow」的儲存類別，它將佈建標準的類磁碟 Persistent Disk。

kind: StorageClass

apiVersion: storage.k8s.io/v1beta1

metadata:

  name: fast

provisioner: kubernetes.io/gce-pd

parameters:

  type: pd-ssd

這會建立一個名為「fast」的儲存類別，它將佈建類似 SSD 的 Persistent Disk。

使用者請求

使用者透過在其 PersistentVolumeClaim 中包含儲存類別來請求動態佈建的儲存。對於此功能的 Beta 版本，這是透過 volume.beta.kubernetes.io/storage-class 註釋完成的。此註釋的值必須與管理員配置的 StorageClass 的名稱相符。

例如，若要選擇「fast」儲存類別，使用者將建立以下 PersistentVolumeClaim

{

  "kind": "PersistentVolumeClaim",

  "apiVersion": "v1",

  "metadata": {

    "name": "claim1",

    "annotations": {

        "volume.beta.kubernetes.io/storage-class": "fast"

    }

  },

  "spec": {

    "accessModes": [

      "ReadWriteOnce"

    ],

    "resources": {

      "requests": {

        "storage": "30Gi"

      }

    }

  }

}

此宣告將導致自動佈建類似 SSD 的 Persistent Disk。當宣告被刪除時，磁碟區將被銷毀。

預設行為

可以為叢集啟用動態佈建，以便在沒有儲存類別註釋的情況下動態佈建所有宣告。叢集管理員透過將一個 StorageClass 物件標記為「default」來啟用此行為。可以透過將 storageclass.beta.kubernetes.io/is-default-class 註釋新增至 StorageClass 來將其標記為預設。

當預設 StorageClass 存在且使用者建立沒有儲存類別註釋的 PersistentVolumeClaim 時，新的 DefaultStorageClass 許可控制器 (也在 v1.4 中引入) 會自動新增指向預設儲存類別的類別註釋。

我還可以繼續使用 Alpha 版本嗎？

Kubernetes 1.4 維護與動態佈建功能的 Alpha 版本的向後相容性，以便更順利地過渡到 Beta 版本。Alpha 行為是由 Alpha 動態佈建註釋 (volume. alpha.kubernetes.io/storage-class) 的存在觸發的。請記住，如果存在 Beta 註釋 (volume. beta.kubernetes.io/storage-class)，則它優先，並觸發 Beta 行為。

對Alpha 版本的支援已棄用，並將在未來的版本中移除。

下一步是什麼？

動態佈建和 StorageClass 將在未來的版本中繼續發展和完善。以下是正在考慮進一步開發的一些領域。

標準雲端佈建器

對於將 Kubernetes 部署到雲端供應商，我們正在考慮自動為雲端原生儲存系統建立佈建器。這表示 AWS 上的標準部署將產生佈建 EBS 磁碟區的 StorageClass，Google Cloud 上的標準部署將產生佈建 GCE PD 的 StorageClass。目前也在辯論是否應將這些佈建器標記為預設，這將使動態佈建成為預設行為 (無需註釋)。

樹狀結構外佈建器

關於 Kubernetes 儲存外掛程式應該「在樹狀結構內」還是「在樹狀結構外」存在持續的討論。雖然如何實作樹狀結構外外掛程式的細節仍在討論中，但有一個提案引入了一種標準化的方式來實作樹狀結構外動態佈建器。

我該如何參與？

如果您有興趣參與 Kubernetes 儲存的設計和開發，請加入Kubernetes 儲存特殊興趣小組 (SIG)。我們正在快速成長，並隨時歡迎新的貢獻者。

• 下載 Kubernetes
• 在 GitHub 上參與 Kubernetes 專案
• 在 Stack Overflow 上發布問題 (或回答問題)
• 在 Slack 上與社群聯繫
• 在 Twitter 上關注我們 @Kubernetesio 以獲取最新更新

• ←上一篇
下一篇→