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”的儲存類，它將配置標準磁碟類別的持久磁碟。

kind: StorageClass

apiVersion: storage.k8s.io/v1beta1

metadata:

  name: fast

provisioner: kubernetes.io/gce-pd

parameters:

  type: pd-ssd

這會建立一個名為“fast”的儲存類，它將配置 SSD 類別的持久磁碟。

使用者請求

使用者透過在其 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 類別的持久磁碟。當宣告被刪除時，卷也將被銷燬。

預設行為

可以為叢集啟用動態配置，以便所有宣告都在沒有儲存類註解的情況下動態配置。此行為由叢集管理員透過將一個 StorageClass 物件標記為“default”來啟用。透過向 StorageClass 新增 `storageclass.beta.kubernetes.io/is-default-class` 註解，可以將其標記為預設。

當存在預設 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 版本的支援已被棄用，並將在未來的版本中移除。

接下來會發生什麼？

動態配置和儲存類將在未來的版本中繼續發展和完善。以下是一些正在考慮進一步開發的領域。

標準雲提供商

對於將 Kubernetes 部署到雲提供商，我們正在考慮自動為雲的本地儲存系統建立配置器。這意味著在 AWS 上的標準部署將生成一個配置 EBS 卷的 StorageClass，在 Google Cloud 上的標準部署將生成一個配置 GCE PD 的 StorageClass。目前還在討論這些配置器是否應該被標記為預設，這將使動態配置成為預設行為（無需註解）。

樹外配置器

關於 Kubernetes 儲存外掛應該“在樹內”還是“在樹外”一直存在爭論。儘管如何實現樹外外掛的細節仍在討論中，但有一個提案引入了一種標準化方法來實現樹外動態配置器。

我如何參與？

如果您有興趣參與 Kubernetes 儲存的設計和開發，請加入 Kubernetes 儲存特別興趣小組 (SIG)。我們正在迅速發展，並始終歡迎新的貢獻者。

• 下載 Kubernetes
• 在 GitHub 上參與 Kubernetes 專案
• 在 Stack Overflow 上提問（或回答問題）
• 在 Slack 上與社群聯絡
• 在 Twitter 上關注我們 @Kubernetesio 獲取最新更新

• ←上一篇
• 下一篇→