Kubernetes 1.6新特性系列
導讀：
Dynamic Provisioning的目標是完全自動化儲存資源的生命週期管理，讓使用者無需過多的關注儲存的管理，可以按需求自動動態建立和調整儲存資源。StorageClass本質上是底層儲存介質的抽象：不同的儲存介質擁有統一的表示和行為。作者注：這是五天深入理解Kubernetes新特性系列的第一篇。
儲存(Storage)是執行有狀態容器的關鍵要素，Kubernetes提供了強大的原語來管理儲存。動態卷配置(Dynamic provisioning)是Kubernetes的獨有功能，它可以根據需要動態的建立儲存卷。在動態配置之前，叢集管理員必須手動呼叫雲/儲存服務提供商的介面來配置新的儲存卷，然後建立PersistentVolume物件以在Kubernetes中表示和使用他們。通過動態配置，可以實現兩個步驟的自動化，無須叢集管理員預先配置儲存資源，而是使用StorageClass物件制定的供應商來動態配置儲存資源，具體請參考使用者指南）。StorageClass本質上是為底層儲存提供者描繪了藍圖，以及各種引數，例如磁碟型別（例如固態和標準磁碟）。
StorageClasses使用特定的儲存平臺或者雲提供商為Kubernetes提供物理介質。多個儲存配置以in-tree的形式（使用者手冊），但現在也支援out-of-tree配置器（請參閱kubernetes-incubator）。
在Kubernetes 1.6正式版中，動態配置被提升至穩定版（Kubernetes 1.4是Beta）。這是完成Kubernetes儲存自動化願景的一大重要進步，它允許叢集管理員控制資源的配置，也能夠讓使用者更好地專注應用開發。這些所有的有點，在使用Kubernetes 1.6之前，這些面向使用者的變化都是非常重要的。
1、怎麼使用Storage Classes
StorageClass是Dynamic Provisioning（動態配置）的基礎，允許叢集管理員位底層儲存平臺做定義抽象。使用者只需在PersistentVolumeClaim(PVC)通過名字引用StorageClass即可。
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mypvc namespace: testns spec: accessModes: - ReadWriteOnce resources: requests: storage: 100Gi storageClassName: gold
為了促進Dynamic Provisioning的使用，此功能允許叢集管理指定預設的StorageClass。當Dynamic Provisioning存在時，使用者可以建立一個PVC而不需要制定一個StorageClassName，進一步減少了使用者用於關注底層儲存提供者所需的精力。當使用預設的StorageClasses時，建立PersistentVolumeClaims(PV)，這一點尤為重要：
- 在Kubernetes 1.6中，已經跟PVCs繫結的PVs依然保持繫結：
- 除非使用者手動新增他們，否則，他們將不具有與他們相關聯的StorageClass。
- 如果PV變為“可用”，如果刪除的PVC和對應的PV被回收，則它要接受如下約束：
- 如果PVC中未指定StorageClassName，則預設的StorageClass將用於動態配置(Dynamic Provisioning)。
- 如果存在並且“可用”，沒有StorageClass標籤的PV將不被考慮用於繫結到PVC。
- 如果在PVC中將StorageClassName設定為空字串(“”)，則不會使用儲存類。（即：此PVC禁止使用動態配置）
- 如果存在並且“可用”，PVs（沒有指定StorageClassName），將被考慮用於繫結到PVC。
- 如果StorageClassName設定為特定值，則將使用與之匹配的儲存類。
- 如果存在並且“可用”，匹配到StorageClassName的PV將被考慮用於繫結到PVC。
- 如果不存在對應的儲存類，PVC將失敗。
為了減輕叢集中預設StorageClasses的負擔，從Kubernetes 1.6開始，Kubernetes為多個雲提供商安裝（通過add-on管理器）預設的StorageClasses。要使用這些預設的StorageClasses，使用者不需要按名稱引用他們，也就是說，不需要在PVC中指定StorageClassName，便可直接使用。
下面的表格顯示不同的雲提供商預安裝的預設StorageClasses：
| 雲提供商 | 預設StorageClasses Name | 預設儲存 |
|---|---|---|
| Amazon Web Services | gp2 | aws-ebs |
| Microsoft Auzer | standard | azure-disk |
| Google Cloud Platform | standard | gcd-pd |
| OpenStack | standard | cinder |
| VMware vSphere | thin | vsphere-volume |
對於大多數使用者來說，選擇使用每個雲提供商預設的提供的儲存是“理智的”，如果想指定自己使用的預設儲存方式，請參考使用者手冊。
2、動態配置卷和回收策略
所有的PVs都有一個與之關聯的回收策略，規定PV一旦從宣告中解除後會發生什麼（請參考使用者指南）。由於自動化儲存資源的生命週期管理，因此動態配置卷(Dynamic Provisioning Volume)的預設回收策略為“刪除”。這意味著當PersistentVolumeClaim(PVC)被釋放時，動態配置卷會被相應的刪除，並且可能資料無法恢復。如果這不是所預期的行為，則在設定卷後，使用者必須在相應的PersistentVolume(PV)物件上更改回收策略。
如何設定回收策略?
您可以通過修改PV物件中的persistentVolumeReclaimPolicy欄位的值來修改PV的回收策略。更多的細節和不同的回收策略請參考使用者手冊。
3、FAQs
A、如何使用預設的StorageClass？
如果您的叢集有一個預設的StorageClass能夠滿足您的需求，那麼您剩下所有需要做的就是建立PersistentVolumeClaim(PVC)，剩下的都有預設的動態配置搞定，包括您無需去指定storageClassName：
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mypvc namespace: testns spec: accessModes: - ReadWriteOnce resources: requests: storage: 100Gi
B、能新增自己的StorageClass嗎？
當然可以。在新增自己的StorageClass之前，需要先確定動態配置能否在叢集上工作。然後，建立一個StorageClass物件並通過設定引數來定製它。對很多使用者來說，最簡單的建立物件的方式就是通過編寫一個yaml檔案並通過kubectl create -f來建立。
下面的建立StorageClass的例子使用了Google Cloud Platform，建立了一個pd-ssd，名稱為gold：
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: gold provisioner: kubernetes.io/gce-pd parameters: type: pd-ssd
由於叢集中可以存在多個類，因此管理員可以為大多數工作負載儲存預設值（因為它使用pd-standard），為需要額外的工作負載保留gold類。
C、是否已經安裝了預設的StorageClass？
您可以使用kubectl命令檢查StorageClass物件。在下面的例子中有兩個StorageClass：gold和standard。gold類是使用者自定義的，standard類由Kubernetes預設安裝。
$ kubectl get sc NAME TYPE gold kubernetes.io/gce-pd standard (default) kubernetes.io/gce-pd
$ kubectl describe storageclass standard Name: standard IsDefaultClass: Yes Annotations: storageclass.beta.kubernetes.io/is-default-class=true Provisioner: kubernetes.io/gce-pd Parameters: type=pd-standard Events: <none>
D、能過刪除/關閉預設的StorageClass？
您不能刪除預設的StorageClass，因為它是作為叢集的add-on安裝的，如果它被刪除，會被重新安裝。
當然，您可以停掉預設的StorageClass行為，通過刪除annotation：storageclass.beta.kubernetes.io/is-default-class。
如果沒有StorageClass物件標記預設的annotation，那麼PersistentVolumeClaim物件（在不指定StorageClass情況下）將不自動觸發動態配置。相反，它們將回到繫結可用的*PersistentVolume(PV)*的狀態。
E、能否將PVs與一個特殊的StorageClass繫結？
可以。通過改變PV物件的storageClassName欄位，可以將一個StorageClass與這個PV繫結。
F、當刪除PersistentVolumeClaim(PVC)會發生什麼？
如果一個卷是動態配置的卷，則預設的回收策略為“刪除”。這意味著，在預設的情況下，當PVC被刪除時，基礎的PV和對應的儲存也會被刪除。如果需要保留儲存在捲上的資料，則必須在PV被設定之後將回收策略從delete更改為retain。
譯者微信公眾號推薦