參考：https://kubernetes.io/zh/docs/concepts/storage/volumes/

Container 中的檔案在磁碟上是臨時存放的，這給 Container 中執行的較重要的應用 程式帶來一些問題。問題之一是當容器崩潰時檔案丟失。kubelet 會重新啟動容器， 但容器會以乾淨的狀態重啟。 第二個問題會在同一 Pod 中執行多個容器並共享檔案時出現。 Kubernetes 卷（Volume） 這一抽象概念能夠解決這兩個問題。

常用卷型別

cephfs

cephfs 卷允許你將現存的 CephFS 卷掛載到 Pod 中。 不像 emptyDir 那樣會在 Pod 被刪除的同時也會被刪除，cephfs 卷的內容在 Pod 被刪除 時會被保留，只是卷被解除安裝了。這意味著 cephfs 卷可以被預先填充資料，且這些資料可以在 Pod 之間共享。同一 cephfs 卷可同時被多個寫者掛載。

說明： 在使用 Ceph 卷之前，你的 Ceph 伺服器必須已經執行並將要使用的 share 匯出（exported）。

更多資訊請參考 CephFS 示例。
https://github.com/kubernetes/examples/tree/master/volumes/cephfs/

cinder

說明： Kubernetes 必須配置了 OpenStack Cloud Provider。

cinder 卷型別用於將 OpenStack Cinder 卷掛載到 Pod 中。

Cinder 卷示例配置

apiVersion: v1
kind: Pod
metadata:
  name: test-cinder
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-cinder-container
    volumeMounts:
    - mountPath: /test-cinder
      name: test-volume
  volumes:
  - name: test-volume
    # 此 OpenStack 卷必須已經存在
    cinder:
      volumeID: "<volume-id>"
      fsType: ext4
 

OpenStack CSI 遷移

FEATURE STATE: Kubernetes v1.21 [beta]

Cinder 的 CSIMigration 功能在 Kubernetes 1.21 版本中是預設被啟用的。 此特性會將外掛的所有操作從現有的樹內外掛重定向到 cinder.csi.openstack.org 容器儲存介面（CSI）驅動程式。 為了使用此功能，必須在叢集中安裝 OpenStack Cinder CSI 驅動程式， 你可以通過設定 CSIMigrationOpenStack 特性門控 為 false 來禁止 Cinder CSI 遷移。 如果你禁用了 CSIMigrationOpenStack 功能特性，則樹內的 Cinder 卷外掛 會負責 Cinder 卷儲存管理的方方面面。

configMap

configMap 卷 提供了向 Pod 注入配置資料的方法。 ConfigMap 物件中儲存的資料可以被 configMap 型別的卷引用，然後被 Pod 中執行的 容器化應用使用。

引用 configMap 物件時，你可以在 volume 中通過它的名稱來引用。 你可以自定義 ConfigMap 中特定條目所要使用的路徑。 下面的配置顯示瞭如何將名為 log-config 的 ConfigMap 掛載到名為 configmap-pod 的 Pod 中：

apiVersion: v1
kind: Pod
metadata:
  name: configmap-pod
spec:
  containers:
    - name: test
      image: busybox
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config
  volumes:
    - name: config-vol
      configMap:
        name: log-config
        items:
          - key: log_level
            path: log_level

log-config ConfigMap 以卷的形式掛載，並且儲存在 log_level 條目中的所有內容 都被掛載到 Pod 的 /etc/config/log_level 路徑下。 請注意，這個路徑來源於卷的 mountPath 和 log_level 鍵對應的 path。

說明：
在使用 ConfigMap 之前你首先要建立它。
容器以 subPath 卷掛載方式使用 ConfigMap 時，將無法接收 ConfigMap 的更新。
文字資料掛載成檔案時採用 UTF-8 字元編碼。如果使用其他字元編碼形式，可使用 binaryData 欄位。

emptyDir

當 Pod 分派到某個 Node 上時，emptyDir 卷會被建立，並且在 Pod 在該節點上執行期間，卷一直存在。 就像其名稱表示的那樣，卷最初是空的。 儘管 Pod 中的容器掛載 emptyDir 卷的路徑可能相同也可能不同，這些容器都可以讀寫 emptyDir 卷中相同的檔案。 當 Pod 因為某些原因被從節點上刪除時，emptyDir 卷中的資料也會被永久刪除。

說明： 容器崩潰並不會導致 Pod 被從節點上移除，因此容器崩潰期間 emptyDir 卷中的資料是安全的。

emptyDir 的一些用途：

• 快取空間，例如基於磁碟的歸併排序。
• 為耗時較長的計算任務提供檢查點，以便任務能方便地從崩潰前狀態恢復執行。
• 在 Web 伺服器容器服務資料時，儲存內容管理器容器獲取的檔案。

取決於你的環境，emptyDir 卷儲存在該節點所使用的介質上；這里的介質可以是磁碟或 SSD 或網路儲存。但是，你可以將 emptyDir.medium 欄位設定為 "Memory"，以告訴 Kubernetes 為你掛載 tmpfs（基於 RAM 的檔案系統）。 雖然 tmpfs 速度非常快，但是要注意它與磁碟不同。 tmpfs 在節點重啟時會被清除，並且你所寫入的所有檔案都會計入容器的記憶體消耗，受容器記憶體限制約束。

說明： 當啟用 SizeMemoryBackedVolumes 特性門控時， 你可以為基於記憶體提供的卷指定大小。 如果未指定大小，則基於記憶體的卷的大小為 Linux 主機上記憶體的 50％。

emptyDir 配置示例

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}

hostPath

hostPath 卷能將主機節點檔案系統上的檔案或目錄掛載到你的 Pod 中。 雖然這不是大多數 Pod 需要的，但是它為一些應用程式提供了強大的逃生艙。

例如，hostPath 的一些用法有：

• 執行一個需要訪問 Docker 內部機制的容器；可使用 hostPath 掛載 /var/lib/docker 路徑。
• 在容器中執行 cAdvisor 時，以 hostPath 方式掛載 /sys。
• 允許 Pod 指定給定的 hostPath 在執行 Pod 之前是否應該存在，是否應該建立以及應該以什麼方式存在。

除了必需的 path 屬性之外，使用者可以選擇性地為 hostPath 卷指定 type。

支援的 type 值如下：

當使用這種型別的卷時要小心，因為：

• 具有相同配置（例如基於同一 PodTemplate 建立）的多個 Pod 會由於節點上檔案的不同 而在不同節點上有不同的行為。
• 下層主機上建立的檔案或目錄只能由 root 使用者寫入。你需要在 特權容器 中以 root 身份執行程序，或者修改主機上的檔案許可權以便容器能夠寫入 hostPath 卷。

hostPath 配置示例：

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # 宿主上目錄位置
      path: /data
      # 此欄位為可選
      type: Directory

注意： FileOrCreate 模式不會負責建立檔案的父目錄。 如果欲掛載的檔案的父目錄不存在，Pod 啟動會失敗。 為了確保這種模式能夠工作，可以嘗試把檔案和它對應的目錄分開掛載，如 FileOrCreate 配置 所示。

hostPath FileOrCreate 配置示例

apiVersion: v1
kind: Pod
metadata:
  name: test-webserver
spec:
  containers:
  - name: test-webserver
    image: k8s.gcr.io/test-webserver:latest
    volumeMounts:
    - mountPath: /var/local/aaa
      name: mydir
    - mountPath: /var/local/aaa/1.txt
      name: myfile
  volumes:
  - name: mydir
    hostPath:
      # 確保檔案所在目錄成功建立。
      path: /var/local/aaa
      type: DirectoryOrCreate
  - name: myfile
    hostPath:
      path: /var/local/aaa/1.txt
      type: FileOrCreate

iscsi

iscsi 卷能將 iSCSI (基於 IP 的 SCSI) 卷掛載到你的 Pod 中。 不像 emptyDir 那樣會在刪除 Pod 的同時也會被刪除，iscsi 卷的內容在刪除 Pod 時 會被保留，卷只是被解除安裝。 這意味著 iscsi 卷可以被預先填充資料，並且這些資料可以在 Pod 之間共享。

注意： 在使用 iSCSI 卷之前，你必須擁有自己的 iSCSI 伺服器，並在上面建立卷。

iSCSI 的一個特點是它可以同時被多個使用者以只讀方式掛載。 這意味著你可以用資料集預先填充卷，然後根據需要在儘可能多的 Pod 上使用它。 不幸的是，iSCSI 卷只能由單個使用者以讀寫模式掛載。不允許同時寫入。

更多詳情請參考 iSCSI 示例。
https://github.com/kubernetes/examples/tree/master/volumes/iscsi

local

local 卷所代表的是某個被掛載的本地儲存裝置，例如磁碟、分割槽或者目錄。

local 卷只能用作靜態建立的持久卷。尚不支援動態配置。

與 hostPath 卷相比，local 卷能夠以持久和可移植的方式使用，而無需手動將 Pod 排程到節點。系統通過檢視 PersistentVolume 的節點親和性配置，就能瞭解卷的節點約束。

然而，local 卷仍然取決於底層節點的可用性，並不適合所有應用程式。 如果節點變得不健康，那麼local 卷也將變得不可被 Pod 訪問。使用它的 Pod 將不能執行。 使用 local 卷的應用程式必須能夠容忍這種可用性的降低，以及因底層磁碟的耐用性特徵 而帶來的潛在的資料丟失風險。

下面是一個使用 local 卷和 nodeAffinity 的持久卷示例：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 100Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: /mnt/disks/ssd1
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - example-node

使用 local 卷時，你需要設定 PersistentVolume 物件的 nodeAffinity 欄位。 Kubernetes 排程器使用 PersistentVolume 的 nodeAffinity 資訊來將使用 local 卷的 Pod 排程到正確的節點。

PersistentVolume 物件的 volumeMode 欄位可被設定為 "Block" （而不是預設值 "Filesystem"），以將 local 卷作為原始塊裝置暴露出來。

使用 local 卷時，建議建立一個 StorageClass 並將其 volumeBindingMode 設定為 WaitForFirstConsumer。要了解更多詳細資訊，請參考 local StorageClass 示例。 延遲卷繫結的操作可以確保 Kubernetes 在為 PersistentVolumeClaim 作出繫結決策時， 會評估 Pod 可能具有的其他節點約束，例如：如節點資源需求、節點選擇器、Pod 親和性和 Pod 反親和性。

你可以在 Kubernetes 之外單獨運行靜態驅動以改進對 local 卷的生命週期管理。 請注意，此驅動尚不支援動態配置。 有關如何執行外部 local 卷驅動，請參考 local 卷驅動使用者指南。

說明： 如果不使用外部靜態驅動來管理卷的生命週期，使用者需要手動清理和刪除 local 型別的持久卷。

nfs

nfs 卷能將 NFS (網路檔案系統) 掛載到你的 Pod 中。 不像 emptyDir 那樣會在刪除 Pod 的同時也會被刪除，nfs 卷的內容在刪除 Pod 時會被儲存，卷只是被解除安裝。 這意味著 nfs 卷可以被預先填充資料，並且這些資料可以在 Pod 之間共享。

注意： 在使用 NFS 卷之前，你必須運行自己的 NFS 服務器並將目標 share 匯出備用。

要了解更多詳情請參考 NFS 示例。
https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs

persistentVolumeClaim

persistentVolumeClaim 卷用來將持久卷（PersistentVolume） 掛載到 Pod 中。 持久卷申領（PersistentVolumeClaim）是使用者在不知道特定雲環境細節的情況下"申領"持久儲存 （例如 GCE PersistentDisk 或者 iSCSI 卷）的一種方法。

更多詳情請參考持久卷示例。
https://kubernetes.io/zh/docs/concepts/storage/persistent-volumes/

rbd

rbd 卷允許將 Rados 塊裝置 卷掛載到你的 Pod 中. 不像 emptyDir 那樣會在刪除 Pod 的同時也會被刪除，rbd 卷的內容在刪除 Pod 時 會被儲存，卷只是被解除安裝。 這意味著 rbd 卷可以被預先填充資料，並且這些資料可以在 Pod 之間共享。

注意： 在使用 RBD 之前，你必須安裝執行 Ceph。

RBD 的一個特性是它可以同時被多個使用者以只讀方式掛載。 這意味著你可以用資料集預先填充卷，然後根據需要在儘可能多的 Pod 中並行地使用卷。 不幸的是，RBD 卷只能由單個使用者以讀寫模式安裝。不允許同時寫入。

更多詳情請參考 RBD 示例。
https://github.com/kubernetes/examples/tree/master/volumes/rbd

secret

secret 卷用來給 Pod 傳遞敏感資訊，例如密碼。你可以將 Secret 儲存在 Kubernetes API 伺服器上，然後以檔案的形式掛在到 Pod 中，無需直接與 Kubernetes 耦合。 secret 卷由 tmpfs（基於 RAM 的檔案系統）提供儲存，因此它們永遠不會被寫入非易失性 （持久化的）儲存器。

說明： 使用前你必須在 Kubernetes API 中建立 secret。

說明： 容器以 subPath 卷掛載方式掛載 Secret 時，將感知不到 Secret 的更新。

更多詳情請參考配置 Secrets。
https://kubernetes.io/zh/docs/concepts/configuration/secret/

vsphereVolume

說明： 你必須配置 Kubernetes 的 vSphere 雲驅動。雲驅動的配置方法請參考 vSphere 使用指南。

vsphereVolume 用來將 vSphere VMDK 卷掛載到你的 Pod 中。 在解除安裝卷時，卷的內容會被保留。 vSphereVolume 卷型別支援 VMFS 和 VSAN 資料倉庫。

注意： 在掛載到 Pod 之前，你必須用下列方式之一建立 VMDK。

建立 VMDK 卷

選擇下列方式之一建立 VMDK。

• 使用 vmkfstools 建立

首先 ssh 到 ESX，然後使用下面的命令來建立 VMDK：

vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk

• 使用 vmware-vdiskmanager 建立

使用下面的命令建立 VMDK：

vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk

vSphere VMDK 配置示例

apiVersion: v1
kind: Pod
metadata:
  name: test-vmdk
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-vmdk
      name: test-volume
  volumes:
  - name: test-volume
    # 此 VMDK 卷必須已經存在
    vsphereVolume:
      volumePath: "[DatastoreName] volumes/myDisk"
      fsType: ext4

進一步資訊可參考 vSphere 卷。
https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere

vSphere CSI 遷移

FEATURE STATE: Kubernetes v1.19 [beta]

當 vsphereVolume 的 CSIMigration 特性被啟用時，所有外掛操作都被從樹內外掛重定向到 csi.vsphere.vmware.com CSI 驅動。 為了使用此功能特性，必須在叢集中安裝 vSphere CSI 驅動， 並啟用 CSIMigration 和 CSIMigrationvSphere 特性門控。

此特性還要求 vSphere vCenter/ESXi 的版本至少為 7.0u1，且 HW 版本至少為 VM version 15。

說明：

vSphere CSI 驅動不支援內建 vsphereVolume 的以下 StorageClass 引數：

    diskformat
    hostfailurestotolerate
    forceprovisioning
    cachereservation
    diskstripes
    objectspacereservation
    iopslimit

使用這些引數建立的現有卷將被遷移到 vSphere CSI 驅動，不過使用 vSphere CSI 驅動所建立的新卷都不會理會這些引數。

vSphere CSI 遷移完成

FEATURE STATE: Kubernetes v1.19 [beta]

為了避免控制器管理器和 kubelet 載入 vsphereVolume 外掛，你需要將 CSIMigrationVSphereComplete 特性設定為 true。你還必須在所有工作節點上安裝 csi.vsphere.vmware.com CSI 驅動。

使用 subPath

有時，在單個 Pod 中共享卷以供多方使用是很有用的。 volumeMounts.subPath 屬性可用於指定所引用的卷內的子路徑，而不是其根路徑。

下面例子展示瞭如何配置某包含 LAMP 堆疊（Linux Apache MySQL PHP）的 Pod 使用同一共享卷。 此示例中的 subPath 配置不建議在生產環境中使用。 PHP 應用的程式碼和相關資料對映到卷的 html 資料夾，MySQL 資料庫儲存在卷的 mysql 資料夾中：

apiVersion: v1
kind: Pod
metadata:
  name: my-lamp-site
spec:
    containers:
    - name: mysql
      image: mysql
      env:
      - name: MYSQL_ROOT_PASSWORD
        value: "rootpasswd"
      volumeMounts:
      - mountPath: /var/lib/mysql
        name: site-data
        subPath: mysql
    - name: php
      image: php:7.0-apache
      volumeMounts:
      - mountPath: /var/www/html
        name: site-data
        subPath: html
    volumes:
    - name: site-data
      persistentVolumeClaim:
        claimName: my-lamp-site-data

使用帶有擴充套件環境變數的 subPath

FEATURE STATE: Kubernetes v1.17 [stable]

使用 subPathExpr 欄位可以基於 Downward API 環境變數來構造 subPath 目錄名。 subPath 和 subPathExpr 屬性是互斥的。

在這個示例中，Pod 使用 subPathExpr 來 hostPath 卷 /var/log/pods 中建立目錄 pod1。 hostPath 卷採用來自 downwardAPI 的 Pod 名稱生成目錄名。 宿主目錄 /var/log/pods/pod1 被掛載到容器的 /logs 中。

apiVersion: v1
kind: Pod
metadata:
  name: pod1
spec:
  containers:
  - name: container1
    env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.name
    image: busybox
    command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ]
    volumeMounts:
    - name: workdir1
      mountPath: /logs
      subPathExpr: $(POD_NAME)
  restartPolicy: Never
  volumes:
  - name: workdir1
    hostPath:
      path: /var/log/pods

資源

emptyDir 卷的儲存介質（磁碟、SSD 等）是由儲存 kubelet 資料的根目錄 （通常是 /var/lib/kubelet）的檔案系統的介質確定。 Kubernetes 對 emptyDir 卷或者 hostPath 卷可以消耗的空間沒有限制， 容器之間或 Pod 之間也沒有隔離。

要了解如何使用資源規約來請求空間，可參考 如何管理資源。
https://kubernetes.io/zh/docs/concepts/configuration/manage-resources-containers/

樹外（Out-of-Tree）卷外掛

Out-of-Tree 卷外掛包括 容器儲存介面（CSI） (CSI) 和 FlexVolume。 它們使儲存供應商能夠建立自定義儲存外掛，而無需將它們新增到 Kubernetes 程式碼倉庫。

以前，所有卷外掛（如上面列出的卷型別）都是“樹內（In-Tree）”的。 “樹內”外掛是與 Kubernetes 的核心元件一同構建、連結、編譯和交付的。 這意味著向 Kubernetes 新增新的儲存系統（卷外掛）需要將程式碼合併到 Kubernetes 核心程式碼庫中。

CSI 和 FlexVolume 都允許獨立於 Kubernetes 程式碼庫開發卷外掛，並作為擴充套件部署 （安裝）在 Kubernetes 叢集上。

對於希望建立樹外（Out-Of-Tree）卷外掛的儲存供應商，請參考 卷外掛常見問題。

CSI

容器儲存介面 (CSI) 為容器編排系統（如 Kubernetes）定義標準介面，以將任意儲存系統暴露給它們的容器工作負載。

更多詳情請閱讀 CSI 設計方案。

說明： Kubernetes v1.13 廢棄了對 CSI 規範版本 0.2 和 0.3 的支援，並將在以後的版本中刪除。

說明： CSI 驅動可能並非相容所有的 Kubernetes 版本。 請檢視特定 CSI 驅動的文件，以瞭解各個 Kubernetes 版本所支援的部署步驟以及相容性列表。

一旦在 Kubernetes 叢集上部署了 CSI 相容卷驅動程式，使用者就可以使用 csi 卷型別來 掛接、掛載 CSI 驅動所提供的卷。

csi 卷可以在 Pod 中以三種方式使用：

• 通過 PersistentVolumeClaim(#persistentvolumeclaim) 物件引用
• 使用一般性的臨時卷 （Alpha 特性）
• 使用 CSI 臨時卷， 前提是驅動支援這種用法（Beta 特性）

儲存管理員可以使用以下欄位來配置 CSI 持久卷：

driver：指定要使用的卷驅動名稱的字串值。 這個值必須與 CSI 驅動程式在 GetPluginInfoResponse 中返回的值相對應； 該介面定義在 CSI 規範中。 Kubernetes 使用所給的值來標識要呼叫的 CSI 驅動程式；CSI 驅動程式也使用該值來辨識 哪些 PV 物件屬於該 CSI 驅動程式。

volumeHandle：唯一標識卷的字串值。 該值必須與 CSI 驅動在 CreateVolumeResponse 的 volume_id 欄位中返回的值相對應； 介面定義在 CSI spec 中。 在所有對 CSI 卷驅動程式的呼叫中，引用該 CSI 卷時都使用此值作為 volume_id 引數。

readOnly：一個可選的布林值，指示通過 ControllerPublished 關聯該卷時是否設定 該卷為只讀。預設值是 false。 該值通過 ControllerPublishVolumeRequest 中的 readonly 欄位傳遞給 CSI 驅動。

fsType：如果 PV 的 VolumeMode 為 Filesystem，那麼此欄位指定掛載卷時應該使用的檔案系統。 如果卷尚未格式化，並且支援格式化，此值將用於格式化卷。 此值可以通過 ControllerPublishVolumeRequest、NodeStageVolumeRequest 和 NodePublishVolumeRequest 的 VolumeCapability 欄位傳遞給 CSI 驅動。

volumeAttributes：一個字元串到字元串的對映表，用來設定卷的靜態屬性。 該對映必須與 CSI 驅動程式返回的 CreateVolumeResponse 中的 volume.attributes 欄位的對映相對應； CSI 規範 中有相應的定義。 該對映通過ControllerPublishVolumeRequest、NodeStageVolumeRequest、和 NodePublishVolumeRequest 中的 volume_attributes 欄位傳遞給 CSI 驅動。

controllerPublishSecretRef：對包含敏感資訊的 Secret 物件的引用； 該敏感資訊會被傳遞給 CSI 驅動來完成 CSI ControllerPublishVolume 和 ControllerUnpublishVolume 呼叫。 此欄位是可選的；在不需要 Secret 時可以是空的。 如果 Secret 物件包含多個 Secret 條目，則所有的 Secret 條目都會被傳遞。

nodeStageSecretRef：對包含敏感資訊的 Secret 物件的引用。 該資訊會傳遞給 CSI 驅動來完成 CSI NodeStageVolume 呼叫。 此欄位是可選的，如果不需要 Secret，則可能是空的。 如果 Secret 物件包含多個 Secret 條目，則傳遞所有 Secret 條目。

nodePublishSecretRef：對包含敏感資訊的 Secret 物件的引用。 該資訊傳遞給 CSI 驅動來完成 CSI NodePublishVolume 呼叫。 此欄位是可選的，如果不需要 Secret，則可能是空的。 如果 Secret 物件包含多個 Secret 條目，則傳遞所有 Secret 條目。

CSI 原始塊卷支援

FEATURE STATE: Kubernetes v1.18 [stable]

具有外部 CSI 驅動程式的供應商能夠在 Kubernetes 工作負載中實現原始塊卷支援。

你可以和以前一樣，安裝自己的 帶有原始塊卷支援的 PV/PVC， 採用 CSI 對此過程沒有影響。

CSI 臨時卷

FEATURE STATE: Kubernetes v1.16 [beta]

你可以直接在 Pod 規約中配置 CSI 卷。採用這種方式配置的卷都是臨時卷， 無法在 Pod 重新啟動後繼續存在。 進一步的資訊可參閱臨時卷。

有關如何開發 CSI 驅動的更多資訊，請參考 kubernetes-csi 文件。

從樹內外掛遷移到 CSI 驅動程式

FEATURE STATE: Kubernetes v1.17 [beta]

啟用 CSIMigration 功能後，針對現有樹內外掛的操作會被重定向到相應的 CSI 外掛 （應已安裝和配置）。 因此，操作員在過渡到取代樹內外掛的 CSI 驅動時，無需對現有儲存類、PV 或 PVC （指樹內外掛）進行任何配置更改。

所支援的操作和功能包括：配備（Provisioning）/刪除、掛接（Attach）/解掛（Detach）、 掛載（Mount）/解除安裝（Unmount）和調整卷大小。

上面的卷型別節列出了支援 CSIMigration 並已實現相應 CSI 驅動程式的樹內外掛。

flexVolume

FlexVolume 是一個自 1.2 版本（在 CSI 之前）以來在 Kubernetes 中一直存在的樹外外掛介面。 它使用基於 exec 的模型來與驅動程式對接。 使用者必須在每個節點（在某些情況下是主控節點）上的預定義卷外掛路徑中安裝 FlexVolume 驅動程式可執行檔案。

Pod 通過 flexvolume 樹內外掛與 Flexvolume 驅動程式互動。 更多詳情請參考 FlexVolume 示例。

掛載卷的傳播

掛載卷的傳播能力允許將容器安裝的卷共享到同一 Pod 中的其他容器， 甚至共享到同一節點上的其他 Pod。

卷的掛載傳播特性由 Container.volumeMounts 中的 mountPropagation 欄位控制。 它的值包括：

1.None - 此卷掛載將不會感知到主機後續在此卷或其任何子目錄上執行的掛載變化。 類似的，容器所建立的卷掛載在主機上是不可見的。這是預設模式。

該模式等同於 Linux 核心文件 中描述的 private 掛載傳播選項。

2.HostToContainer - 此卷掛載將會感知到主機後續針對此卷或其任何子目錄的掛載操作。

換句話說，如果主機在此掛載卷中掛載任何內容，容器將能看到它被掛載在那裡。

類似的，配置了 Bidirectional 掛載傳播選項的 Pod 如果在同一捲上掛載了內容， 掛載傳播設定為 HostToContainer 的容器都將能看到這一變化。

該模式等同於 Linux 核心文件 中描述的 rslave 掛載傳播選項。

3.Bidirectional - 這種卷掛載和 HostToContainer 掛載表現相同。 另外，容器建立的卷掛載將被傳播回至主機和使用同一卷的所有 Pod 的所有容器。

該模式等同於 Linux 核心文件 中描述的 rshared 掛載傳播選項。

警告： Bidirectional 形式的掛載傳播可能比較危險。 它可以破壞主機作業系統，因此它只被允許在特權容器中使用。 強烈建議你熟悉 Linux 核心行為。 此外，由 Pod 中的容器建立的任何卷掛載必須在終止時由容器銷燬（解除安裝）。

配置

在某些部署環境中，掛載傳播正常工作前，必須在 Docker 中正確配置掛載共享（mount share）， 如下所示。

編輯你的 Docker systemd 服務檔案，按下面的方法設定 MountFlags：

MountFlags=shared

或者，如果存在 MountFlags=slave 就刪除掉。然後重啟 Docker 守護程序：

sudo systemctl daemon-reload
sudo systemctl restart docker