Container Service for Kubernetes：儲存基礎知識

Kubernetes提供了非常豐富的Volume類型，您在ACK可以使用的常用的Volume類型如下：

資料卷（Volume）使用原則

• 一個Pod可以掛載多個資料卷（Volume）。

• 一個Pod可以掛載多種類型的資料卷（Volume）。

• 每個被Pod掛載的Volume卷，可以在不同的容器間共用。

• Kubernetes環境推薦使用PVC和PV方式掛載資料卷（Volume）。

• 雖然單Pod可以掛載多個資料卷（Volume），但是並不建議給一個Pod掛載過多資料卷。

並非所有的Kubernetes資料卷（Volume）具有持久化特性，為了實現持久化的儲存，容器儲存需依賴於一個遠程儲存服務。為此Kubernetes引入了PV和PVC兩個資來源物件，將儲存實現的細節從其如何被使用中抽象出來，並解耦儲存使用者和系統管理員的職責。PV和PVC的概念如下：

• PV

  • PV是PersistentVolume的縮寫，譯為持久化儲存卷。PV在Kubernetes中代表一個具體儲存類型的卷，其對象中定義了具體儲存類型和卷參數。即目標儲存服務所有相關的資訊都儲存在PV中，Kubernetes引用PV中的儲存資訊執行掛載操作。

• PVC

  • PVC是PersistentVolumeClaim的縮寫，譯為儲存聲明。PVC是在Kubernetes中一種抽象的儲存卷類型，代表了某個具體類型儲存的資料卷表達。其設計意圖是分離儲存與應用編排，將儲存細節抽象出來並實現儲存的編排。這樣Kubernetes中儲存卷對象獨立於應用編排而單獨存在，在編排層面使應用和儲存解耦。

PV和PVC使用說明

• PVC和PV的綁定

  PVC與PV是一一對應關係，不能一個PVC掛載多個PV，也不能一個PV掛載多個PVC。為應用配置儲存時，需要聲明一個儲存需求聲明（PVC），而Kubernetes會通過首選的方式選擇一個滿足PVC需求的PV，並與之綁定。所以從職責上PVC是應用所需要的儲存物件，屬於應用範圍。PV是儲存平面的儲存物件，屬於整個儲存域。

  PVC只有綁定了PV之後才能被Pod使用，而PVC綁定PV的過程即是消費PV的過程，這個過程是有一定規則的，以下規則都滿足的PV才能被PVC綁定：

  • VolumeMode：被消費PV的VolumeMode需要和PVC一致。

  • AccessMode：被消費PV的AccessMode需要和PVC一致。

  • StorageClassName：如果PVC定義了此參數，PV必須有相關的參數定義才能進行綁定。

  • LabelSelector：通過標籤（labels）匹配的方式從PV列表中選擇合適的PV綁定。

  • Size：被消費PV的capacity必須大於或者等於PVC的儲存容量需求才能被綁定。

• PV和PVC定義中的size欄位

  PVC和PV裡面的size欄位作用如下：

  • PVC、PV綁定時，會根據各自的size進行篩選。

  • 通過PVC、StorageClass動態建立PV時，有些儲存類型會參考PVC的size建立相應大小的PV和後端儲存。

  • 對於支援Resize操作的儲存類型，PVC的size作為擴容後PV、後端儲存的容量值。

  一個PVC、PV的size值只是在執行一些PVC和PV管控操作的時候，作為配置參數來使用。

  真正的儲存卷資料流寫資料的時候，不會參考PVC和PV的size欄位，而是依賴底層儲存介質的實際容量。

常見的容器儲存資料卷使用方式如下：

• 靜態儲存卷

  靜態儲存卷一般是指由管理員建立的PV。所有的資料卷（Volume）都支援建立靜態儲存卷。

  靜態儲存卷先由叢集管理員分析叢集中儲存需求，並預先分配一些儲存介質（例如雲端硬碟、NAS盤等），同時建立對應的PV對象。建立好的PV對象等待PVC來消費。如果負載中定義了PVC需求，Kubernetes會通過相關規則實現PVC和匹配的PV進行綁定，這樣就實現了應用對儲存服務的訪問能力。

• 動態儲存裝置卷

  動態儲存裝置卷一般是指通過儲存外掛程式自動建立的PV。

  動態磁碟區一般由叢集管理員配置好後端的儲存池，並建立相應的模板（StorageClass），當有PVC需要消費PV的時候，根據PVC定義的需求，並參考StorageClass的儲存細節，由儲存外掛程式動態建立一個PV。StorageClass的定義如下：

  • StorageClass

    當您聲明一個PVC時，如果在PVC中添加了StorageClassName欄位，意味著當PVC在叢集中找不到匹配的PV時，會根據StorageClassName的定義觸發相應的Provisioner外掛程式建立合適的PV供綁定，即建立動態資料卷。

    動態資料卷由Provisioner外掛程式建立，並通過StorageClassName與PVC進行關聯。

    StorageClass可譯為儲存類，表示為一個建立PV儲存卷的模板。在PVC觸發自動建立PV的過程中，即使用StorageClass對象中的內容進行建立。其內容如下：

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: alicloud-disk-topology
    parameters:
      type: cloud_ssd
    provisioner: diskplugin.csi.alibabacloud.com
    reclaimPolicy: Delete
    allowVolumeExpansion: true
    volumeBindingMode: WaitForFirstConsumer

    參數	描述
    reclaimPolicy	用來指定建立PV的persistentVolumeReclaimPolicy欄位值，支援Delete和Retain。 Delete表示動態建立的PV，在銷毀的時候也會自動銷毀。 Retain表示動態建立的PV，不會自動銷毀，而是由管理員處理。
    allowVolumeExpansion	定義由此儲存類建立的PV是否運行動態擴容，預設為false。是否能動態擴容是由底層儲存外掛程式來實現的，這裡只是一個開關。
    volumeBindingMode	表示動態建立PV的時間，支援Immediate和WaitForFirstConsumer，分別表示立即建立和延遲建立。

  • 延遲綁定

    針對某類儲存（例如阿里雲雲端硬碟）在掛載屬性上有所限制，只能掛載相同可用性區域的資料卷和節點，不在同一個可用性區域不可以掛載。這種類型的儲存卷通常遇到如下問題：

    • 建立了A可用性區域的資料卷，但是A可用性區域的節點資源已經耗光，導致Pod啟動無法完成掛載。

    • 叢集管理員在規劃PVC、PV的時候不能確定在哪些可用性區域建立多個PV來備用。

    StorageClass中的volumeBindingMode欄位正是用來解決此問題，如果將volumeBindingMode配置為WaitForFirstConsumer值，則表示儲存外掛程式在收到PVC Pending的時候不會立即進行資料卷建立，而是等待這個PVC被Pod消費的時候才執行建立流程。

    說明

    延遲綁定實現原理如下：

    Provisioner在收到PVC Pending狀態的時候不會立即進行資料卷建立，而是等待這個PVC被Pod消費。如果有Pod消費此PVC，調度器發現PVC是延遲繫結模式，則繼續完成調度功能，且調度器會將調度結果通過patch命令到PVC的metadata中。當Provisioner發現PVC中寫入了調度資訊時，會根據調度資訊擷取建立目標資料卷的位置資訊（地區和節點資訊），並觸發PV的建立流程。

    在多可用性區域叢集環境中，更推薦使用延遲綁定的動態磁碟區方案，目前阿里雲ACK叢集已經支援上述配置方案。

  動態儲存裝置卷的優勢

  • 動態儲存裝置卷讓Kubernetes實現了PV的自動化生命週期管理，PV的建立、刪除都通過Provisioner完成。

  • 自動化建立PV對象，減少了配置複雜度和系統管理員的工作量。

  • 動態磁碟區可以實現PVC對儲存的需求容量和Provisioner出來的PV容量一致，實現儲存容量規劃最優。

• 掛載SubPath卷

  Kubernetes提供了volumeMounts.subPath屬性配置，可用於指定所引用的卷內的子路徑，而不是其根路徑。

  說明

  SubPath在Kubernetes的一些版本中存在掛載、卸載不充分的問題，故不建議使用。如果您想要掛載卷的子目錄（如NAS、OSS子目錄），可以通過阿里雲儲存CSI原生支援的能力進行掛載。