如何解析Kubernetes中的StorageClass和動態卷供給

如何解析Kubernetes中的StorageClass和動態卷供給，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

新特性

Alpha 版本的動態卷，一個集群同時只能允許單獨的、被硬編碼的提供者。也就是說，如果 Kubernetes 要提供動態卷的時候，即使集群中可以使用多個存儲系統，Kubernetes 也只會使用同一個存儲卷插件。存儲提供者的選型是基于云環境類型決定的 —— AWS 的 EBS，Google Cloud 的 Persistent Disk 或者是 OpenStack 的 Cinder，以及 vSphere 的 vSphere Volume。另外只有容量參數可以配置。這就意味著，即使有其他參數可用，所有的動態卷除了尺寸大小，其他都是一樣的。

雖說這一功能的 Alpha 版本實用性有限，這畢竟是邁出了一步，有助于確定今后的發展方向。

Kubernetes 1.4 中加入了一個 新的 API 對象 StorageClass，可以定義多個 StorageClass 對象，并可以分別指定存儲插件、設置參數，用于提供不同的存儲卷。這樣的設計讓集群管理員能夠在同一個集群內，定義和提供不同類型的、不同參數的卷（相同或者不同的存儲系統）。這樣的設計還確保了最終用戶在無需了解太多的情況下，有能力選擇不同的存儲選項。

管理員配置

集群管理員定義并發布了兩個 StorageClass 對象

kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
  name: slow
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard

這一段創建了一個名為 “slow” 的 StorageClass，用于提供標準的持久存儲。

kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd

這一段創建了一個名為 “fast” 的 StorageClass，用于提供類似 SSD 的持久存儲。

用戶請求

用戶在 PersistentVolumeClaim 中可以包含一個 StorageClass 申請動態提供存儲。這一任務需要使用 volume.beta.kubernetes.io/storage-class 注解來完成。這一注解的值必須符合管理員配置的 StorageClass 名稱。

要選擇 “fast” 存儲類，用戶需要創建如下的 PVC：

 {
  "kind": "PersistentVolumeClaim",
  "apiVersion": "v1",
  "metadata": {
    "name": "claim1",
    "annotations": {
        "volume.beta.kubernetes.io/storage-class": "fast"
    }
  },
  "spec": {
    "accessModes": [
      "ReadWriteOnce"
    ],
    "resources": {
      "requests": {
        "storage": "30Gi"
      }
    }
  }
}

上述報文會提供一個等效于 SSD 的持久盤，當這個 PVC 被刪除，這個卷也隨之銷毀。

缺省行為

所有的 PVC 都可以在不使用 StorageClass 注解的情況下，直接使用某個動態存儲。把一個StorageClass 對象標記為 “default” 就可以了。StorageClass 用注解storageclass.beta.kubernetes.io/is-default-class 就可以成為缺省存儲。

有了缺省的 StorageClass，用戶創建 PVC 就不用 storage-class 的注解了，1.4 中新加入的DefaultStorageClass 準入控制器會自動把這個標注指向缺省存儲類。

我還能使用 Alpha 版本么？

Kubernetes 1.4 兼容 alpha 版本的動態卷特性，讓用戶能夠平滑過渡到 beta 版本。用volume.alpha.kubernetes.io/storage-class 注解來標注 alpha 版本。

標準云支持

如果 Kubernetes 集群部署在云服務商，我們 考慮 自動使用云的本地存儲系統創建一個動態卷供給者。例如在 AWS 上的標準部署會得到一個 EBS 的動態卷供給，而 Google Cloud 的部署則會提供一個 GCE PD 動態卷供應者。我們還在討論是否應該把這種卷作為缺省卷。

看完上述內容，你們掌握如何解析Kubernetes中的StorageClass和動態卷供給的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！