Kubernetes中支持的全部磁盤掛載卷簡介發表於 2018年1月26日
7400 字 | 閱讀須要 15 分鐘
容器磁盤上的文件的生命週期是短暫的，這就使得在容器中運行重要應用時會出現一些問題。首先，當容器崩潰時，kubelet 會重啓它，可是容器中的文件將丟失——容器以乾淨的狀態（鏡像最初的狀態）從新啓動。其次，在 Pod 中同時運行多個容器時，這些容器之間一般須要共享文件。Kubernetes 中的 Volume 抽象就很好的解決了這些問題。
本文已歸檔到kubernetes-handbook。閱讀本文前建議您先熟悉 pod。php
背景
Docker 中也有一個 volume 的概念，儘管它稍微寬鬆一些，管理也不多。在 Docker 中，卷就像是磁盤或是另外一個容器中的一個目錄。它的生命週期不受管理，直到最近纔有了 local-disk-backed 卷。Docker 如今提供了卷驅動程序，可是功能還很是有限（例如Docker1.7只容許每一個容器使用一個卷驅動，而且沒法給卷傳遞參數）。html
另外一方面，Kubernetes 中的卷有明確的壽命——與封裝它的 Pod 相同。因此，卷的生命比 Pod 中的全部容器都長，當這個容器重啓時數據仍然得以保存。固然，當 Pod 再也不存在時，卷也將不復存在。也許更重要的是，Kubernetes 支持多種類型的卷，Pod 能夠同時使用任意數量的卷。node
卷的核心是目錄，可能還包含了一些數據，能夠經過 pod 中的容器來訪問。該目錄是如何造成的、支持該目錄的介質以及其內容取決於所使用的特定卷類型。mysql
要使用卷，須要爲 pod 指定爲卷（spec.volumes 字段）以及將它掛載到容器的位置（spec.containers.volumeMounts 字段）。linux
容器中的進程看到的是由其 Docker 鏡像和卷組成的文件系統視圖。 Docker 鏡像位於文件系統層次結構的根目錄，任何卷都被掛載在鏡像的指定路徑中。卷沒法掛載到其餘捲上或與其餘卷有硬鏈接。Pod 中的每一個容器都必須獨立指定每一個卷的掛載位置。nginx
卷的類型
Kubernetes 支持如下類型的卷：git
awsElasticBlockStoreazureDiskazureFilecephfscsidownwardAPIemptyDirfc(fibre channel)flockergcePersistentDiskgitRepoglusterfshostPathiscsilocalnfspersistentVolumeClaimprojectedportworxVolumequobyterbdscaleIOsecretstorageosvsphereVolume
咱們歡迎額外貢獻。github
awsElasticBlockStore
awsElasticBlockStore 卷將Amazon Web Services（AWS）EBS Volume 掛載到您的容器中。與 emptyDir 類型會在刪除 Pod 時被清除不一樣，EBS 卷的的內容會保留下來，僅僅是被卸載。這意味着 EBS 卷能夠預先填充數據，而且能夠在數據包之間「切換」數據。web
重要提示：您必須使用 aws ec2 create-volume 或 AWS API 建立 EBS 卷，才能使用它。redis
使用 awsElasticBlockStore 卷時有一些限制：
- 運行 Pod 的節點必須是 AWS EC2 實例
- 這些實例須要與 EBS 卷位於相同的區域和可用區域
- EBS 僅支持卷和 EC2 實例的一對一的掛載
建立 EBS 卷
在 pod 中使用的 EBS 卷以前，您須要先建立它。
aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2
確保區域與您啓動集羣的區域相匹配（而且檢查大小和 EBS 卷類型是否適合您的使用！）
AWS EBS 示例配置
apiVersion: v1 kind: Pod metadata: name: test-ebs spec: containers: - image: k8s.gcr.io/test-webserver name: test-container volumeMounts: - mountPath: /test-ebs name: test-volume volumes: - name: test-volume # This AWS EBS volume must already exist. awsElasticBlockStore: volumeID: <volume-id> fsType: ext4
azureDisk
AzureDisk 用於將 Microsoft Azure Data Disk 掛載到 Pod 中。
更多細節能夠在這裏找到。
azureFile
azureFile 用於將 Microsoft Azure File Volume（SMB 2.1 和 3.0）掛載到 Pod 中。
更多細節能夠在這裏找到。
cephfs
cephfs 卷容許將現有的 CephFS 卷掛載到您的容器中。不像 emptyDir，當刪除 Pod 時被刪除，cephfs 卷的內容將被保留，卷僅僅是被卸載。這意味着 CephFS 卷能夠預先填充數據，而且能夠在數據包之間「切換」數據。 CephFS 能夠被多個寫設備同時掛載。
重要提示：您必須先擁有本身的 Ceph 服務器，而後才能使用它。
有關更多詳細信息，請參見CephFS示例。
csi
CSI 表明容器存儲接口，CSI 試圖創建一個行業標準接口的規範，藉助 CSI 容器編排系統（CO）能夠將任意存儲系統暴露給本身的容器工做負載。有關詳細信息，請查看設計方案。
csi 卷類型是一種 in-tree 的 CSI 卷插件，用於 Pod 與在同一節點上運行的外部 CSI 卷驅動程序交互。部署 CSI 兼容卷驅動後，用戶可使用 csi 做爲卷類型來掛載驅動提供的存儲。
CSI 持久化卷支持是在 Kubernetes v1.9 中引入的，做爲一個 alpha 特性，必須由集羣管理員明確啓用。換句話說，集羣管理員須要在 apiserver、controller-manager 和 kubelet 組件的 「--feature-gates =」 標誌中加上 「CSIPersistentVolume = true」。
CSI 持久化卷具備如下字段可供用戶指定：
driver：一個字符串值，指定要使用的卷驅動程序的名稱。必須少於 63 個字符，並以一個字符開頭。驅動程序名稱能夠包含 「.」、「-」、「_」 或數字。volumeHandle：一個字符串值，惟一標識從 CSI 卷插件的CreateVolume調用返回的卷名。隨後在卷驅動程序的全部後續調用中使用卷句柄來引用該卷。readOnly：一個可選的布爾值，指示卷是否被髮布爲只讀。默認是 false。
downwardAPI
downwardAPI 卷用於使向下 API 數據（downward API data）對應用程序可用。它掛載一個目錄，並將請求的數據寫入純文本文件。
參考 downwardAPI 卷示例查看詳細信息。
emptyDir
當 Pod 被分配給節點時，首先建立 emptyDir 卷，而且只要該 Pod 在該節點上運行，該卷就會存在。正如卷的名字所述，它最初是空的。Pod 中的容器能夠讀取和寫入 emptyDir 卷中的相同文件，儘管該卷能夠掛載到每一個容器中的相同或不一樣路徑上。當出於任何緣由從節點中刪除 Pod 時，emptyDir 中的數據將被永久刪除。
注意：容器崩潰不會從節點中移除 pod，所以 emptyDir 卷中的數據在容器崩潰時是安全的。
emptyDir 的用法有：
- 暫存空間，例如用於基於磁盤的合併排序
- 用做長時間計算崩潰恢復時的檢查點
- Web服務器容器提供數據時，保存內容管理器容器提取的文件
Pod 示例
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: {}
fc (fibre channel)
fc 卷容許將現有的 fc 卷掛載到 pod 中。您可使用卷配置中的 targetWWN 參數指定單個或多個目標全球通用名稱（World Wide Name）。若是指定了多個 WWN，則 targetWWN 指望這些 WWN 來自多路徑鏈接。
重要提示：您必須配置 FC SAN 區域劃分，並預先將這些 LUN（卷）分配並屏蔽到目標 WWN，以便 Kubernetes 主機能夠訪問它們。
參考 FC 示例獲取詳細信息。
flocker
Flocker 是一款開源的集羣容器數據卷管理器。它提供了由各類存儲後端支持的數據卷的管理和編排。
flocker 容許將 Flocker 數據集掛載到 pod 中。若是數據集在 Flocker 中不存在，則須要先使用 Flocker CLI 或使用 Flocker API 建立數據集。若是數據集已經存在，它將被 Flocker 從新鏈接到 pod 被調度的節點上。這意味着數據能夠根據須要在數據包之間「切換」。
重要提示：您必須先運行本身的 Flocker 安裝程序才能使用它。
參考 Flocker 示例獲取更多詳細信息。
gcePersistentDisk
gcePersistentDisk 卷將 Google Compute Engine（GCE）Persistent Disk 掛載到您的容器中。與刪除 Pod 時刪除的 emptyDir 不一樣，PD 的內容被保留，只是卸載了卷。這意味着 PD 能夠預先填充數據，而且數據能夠在 Pod 之間「切換」。
重要提示：您必須先使用 gcloud 或 GCE API 或 UI 建立一個 PD，而後才能使用它。
使用 gcePersistentDisk 時有一些限制：
- 運行 Pod 的節點必須是 GCE 虛擬機
- 那些虛擬機須要在與 PD 同樣在 GCE 項目和區域中
PD 的一個特色是它們能夠同時被多個用戶以只讀方式掛載。這意味着您能夠預先使用您的數據集填充 PD，而後根據須要給多個 Pod 中並行提供。不幸的是，只能由單個消費者以讀寫模式掛載 PD，而不容許同時寫入。 在由 ReplicationController 控制的 pod 上使用 PD 將會失敗，除非 PD 是隻讀的或者副本數是 0 或 1。
建立 PD
在您在 pod 中使用 GCE PD 以前，須要先建立它。
gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk
Pod 示例
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 # This GCE PD must already exist. gcePersistentDisk: pdName: my-data-disk fsType: ext4
gitRepo
gitRepo 卷是一個能夠演示卷插件功能的示例。它會掛載一個空目錄並將 git 存儲庫克隆到您的容器中。未來，這樣的卷可能會轉移到一個更加分離的模型，而不是爲每一個這樣的用例擴展 Kubernetes API。
下面是 gitRepo 卷示例：
apiVersion: v1 kind: Pod metadata: name: server spec: containers: - image: nginx name: nginx volumeMounts: - mountPath: /mypath name: git-volume volumes: - name: git-volume gitRepo: repository: "git@somewhere:me/my-git-repository.git" revision: "22f1d8406d464b0c0874075539c1f2e96c253775"
glusterfs
glusterfs 卷容許將 Glusterfs（一個開放源代碼的網絡文件系統）卷掛載到您的集羣中。與刪除 Pod 時刪除的 emptyDir 不一樣，glusterfs 卷的內容將被保留，而卷僅僅被卸載。這意味着 glusterfs 卷能夠預先填充數據，而且能夠在數據包之間「切換」數據。 GlusterFS 能夠同時由多個寫入掛載。
重要提示：您必須先自行安裝 GlusterFS，才能使用它。
有關更多詳細信息，請參閱 GlusterFS 示例。
hostPath
hostPath 卷將主機節點的文件系統中的文件或目錄掛載到集羣中。該功能大多數 Pod 都用不到，但它爲某些應用程序提供了一個強大的解決方法。
例如，hostPath 的用途以下：
- 運行須要訪問 Docker 內部的容器；使用
/var/lib/docker的hostPath - 在容器中運行 cAdvisor；使用
/dev/cgroups的hostPath - 容許 pod 指定給定的 hostPath 是否應該在 pod 運行以前存在，是否應該建立，以及它應該以什麼形式存在
除了所需的 path 屬性以外，用戶還能夠爲 hostPath 卷指定 type。
type 字段支持如下值：
| 值 | 行爲 |
|---|---|
| 空字符串（默認）用於向後兼容，這意味着在掛載 hostPath 卷以前不會執行任何檢查。 | |
DirectoryOrCreate |
若是在給定的路徑上沒有任何東西存在，那麼將根據須要在那裏建立一個空目錄，權限設置爲 0755，與 Kubelet 具備相同的組和全部權。 |
Directory |
給定的路徑下必須存在目錄 |
FileOrCreate |
若是在給定的路徑上沒有任何東西存在，那麼會根據須要建立一個空文件，權限設置爲 0644，與 Kubelet 具備相同的組和全部權。 |
File |
給定的路徑下必須存在文件 |
Socket |
給定的路徑下必須存在 UNIX 套接字 |
CharDevice |
給定的路徑下必須存在字符設備 |
BlockDevice |
給定的路徑下必須存在塊設備 |
使用這種卷類型是請注意，由於：
- 因爲每一個節點上的文件都不一樣，具備相同配置（例如從 podTemplate 建立的）的 pod 在不一樣節點上的行爲可能會有所不一樣
- 當 Kubernetes 按照計劃添加資源感知調度時，將沒法考慮
hostPath使用的資源 - 在底層主機上建立的文件或目錄只能由 root 寫入。您須要在特權容器中以 root 身份運行進程，或修改主機上的文件權限以便寫入
hostPath卷
Pod 示例
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: # directory location on host path: /data # this field is optional type: Directory
iscsi
iscsi 卷容許將現有的 iSCSI（SCSI over IP）卷掛載到容器中。不像 emptyDir，刪除 Pod 時 iscsi 卷的內容將被保留，卷僅僅是被卸載。這意味着 iscsi 卷能夠預先填充數據，而且這些數據能夠在 pod 之間「切換」。
重要提示：必須先建立本身的 iSCSI 服務器，而後才能使用它。
iSCSI 的一個特色是它能夠同時被多個用戶以只讀方式安裝。這意味着您能夠預先使用您的數據集填充卷，而後根據須要向多個額 pod 同時提供。不幸的是，iSCSI 卷只能由單個使用者以讀寫模式掛載——不容許同時寫入。
有關更多詳細信息，請參見 iSCSI示例。
local
這個 alpha 功能要求啓用 PersistentLocalVolumes feature gate。
注意：從 1.9 開始，VolumeScheduling feature gate 也必須啓用。
local 卷表示掛載的本地存儲設備，如磁盤、分區或目錄。
本地卷只能用做靜態建立的 PersistentVolume。
與 HostPath 卷相比，local 卷能夠以持久的方式使用，而無需手動將 pod 調度到節點上，由於系統會經過查看 PersistentVolume 上的節點關聯性來了解卷的節點約束。
可是，local 卷仍然受底層節點的可用性影響，並不適用於全部應用程序。
如下是使用 local 卷的示例 PersistentVolume 規範：
apiVersion: v1 kind: PersistentVolume metadata: name: example-pv annotations: "volume.alpha.kubernetes.io/node-affinity": '{ "requiredDuringSchedulingIgnoredDuringExecution": { "nodeSelectorTerms": [ { "matchExpressions": [ { "key": "kubernetes.io/hostname", "operator": "In", "values": ["example-node"] } ]} ]} }' spec: capacity: storage: 100Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete storageClassName: local-storage local: path: /mnt/disks/ssd1
注意：本地 PersistentVolume 清理和刪除須要手動干預，無外部提供程序。
從 1.9 開始，本地卷綁定能夠被延遲，直到經過具備 StorageClass 中的 WaitForFirstConsumer 設置爲volumeBindingMode 的 pod 開始調度。請參閱示例。延遲卷綁定可確保卷綁定決策也可使用任何其餘節點約束（例如節點資源需求，節點選擇器，pod 親和性和 pod 反親和性）進行評估。
有關 local 卷類型的詳細信息，請參見本地持久化存儲用戶指南。
nfs
nfs 卷容許將現有的 NFS（網絡文件系統）共享掛載到您的容器中。不像 emptyDir，當刪除 Pod 時，nfs 卷的內容被保留，卷僅僅是被卸載。這意味着 NFS 卷能夠預填充數據，而且能夠在 pod 之間「切換」數據。 NFS 能夠被多個寫入者同時掛載。
重要提示：您必須先擁有本身的 NFS 服務器才能使用它，而後才能使用它。
有關更多詳細信息，請參見NFS示例。
persistentVolumeClaim
persistentVolumeClaim 卷用於將 PersistentVolume 掛載到容器中。PersistentVolumes 是在用戶不知道特定雲環境的細節的狀況下「聲明」持久化存儲（例如 GCE PersistentDisk 或 iSCSI 卷）的一種方式。
有關更多詳細信息，請參閱 PersistentVolumes 示例。
projected
projected 卷將幾個現有的卷源映射到同一個目錄中。
目前，能夠映射如下類型的捲來源：
secretdownwardAPIconfigMap
全部來源都必須在與 pod 相同的命名空間中。有關更多詳細信息，請參閱 all-in-one 卷設計文檔。
帶有 secret、downward API 和 configmap 的 pod
apiVersion: v1 kind: Pod metadata: name: volume-test spec: containers: - name: container-test image: busybox volumeMounts: - name: all-in-one mountPath: "/projected-volume" readOnly: true volumes: - name: all-in-one projected: sources: - secret: name: mysecret items: - key: username path: my-group/my-username - downwardAPI: items: - path: "labels" fieldRef: fieldPath: metadata.labels - path: "cpu_limit" resourceFieldRef: containerName: container-test resource: limits.cpu - configMap: name: myconfigmap items: - key: config path: my-group/my-config
使用非默認權限模式設置多個 secret 的示例 pod
apiVersion: v1 kind: Pod metadata: name: volume-test spec: containers: - name: container-test image: busybox volumeMounts: - name: all-in-one mountPath: "/projected-volume" readOnly: true volumes: - name: all-in-one projected: sources: - secret: name: mysecret items: - key: username path: my-group/my-username - secret: name: mysecret2 items: - key: password path: my-group/my-password mode: 511
每一個映射的捲來源在 sources 下的規格中列出。除了如下兩個例外，參數幾乎相同：
- 對於 secret，
secretName字段已經被更改成name以與 ConfigMap 命名一致。 defaultMode只能在映射級別指定，而不能針對每一個卷源指定。可是，如上所述，您能夠明確設置每一個映射的mode。
portworxVolume
portworxVolume 是一個與 Kubernetes 一塊兒，以超融合模式運行的彈性塊存儲層。Portwork 指紋存儲在服務器中，基於功能的分層，以及跨多個服務器聚合容量。 Portworx 在虛擬機或裸機 Linux 節點上運行。
portworxVolume 能夠經過 Kubernetes 動態建立，也能夠在 Kubernetes pod 中預先設置和引用。
如下是一個引用預先配置的 PortworxVolume 的示例 pod：
apiVersion: v1 kind: Pod metadata: name: test-portworx-volume-pod spec: containers: - image: k8s.gcr.io/test-webserver name: test-container volumeMounts: - mountPath: /mnt name: pxvol volumes: - name: pxvol # This Portworx volume must already exist. portworxVolume: volumeID: "pxvol" fsType: "<fs-type>"
重要提示：在 pod 中使用以前，請確保您有一個名爲 pxvol 的現有 PortworxVolume。
更多的細節和例子能夠在這裏找到。
quobyte
quobyte 卷容許將現有的 Quobyte 卷掛載到容器中。
重要提示：您必須先建立本身的 Quobyte 安裝程序，而後才能使用它。
有關更多詳細信息，請參見 Quobyte示例。
rbd
rbd 卷容許將 Rados Block Device 卷掛載到容器中。不像 emptyDir，刪除 Pod 時 rbd卷的內容被保留，卷僅僅被卸載。這意味着 RBD 卷能夠預先填充數據，而且能夠在 pod 之間「切換」數據。
重要提示：您必須先自行安裝 Ceph，而後才能使用 RBD。
RBD 的一個特色是它能夠同時爲多個用戶以只讀方式掛載。這意味着能夠預先使用您的數據集填充卷，而後根據須要同時爲多個 pod 並行提供。不幸的是，RBD 卷只能由單個用戶以讀寫模式安裝——不容許同時寫入。
有關更多詳細信息，請參閱 RBD示例。
scaleIO
ScaleIO 是一個基於軟件的存儲平臺，可使用現有的硬件來建立可擴展的共享塊網絡存儲集羣。scaleIO 卷插件容許已部署的 pod 訪問現有的 ScaleIO 卷（或者它能夠爲持久性卷聲明動態調配新卷，請參閱 ScaleIO 持久卷）。
重要提示：您必須有一個已經配置好的 ScaleIO 集羣，並和建立的卷一同運行，而後才能使用它們。
如下是使用 ScaleIO 的示例 pod 配置：
apiVersion: v1 kind: Pod metadata: name: pod-0 spec: containers: - image: k8s.gcr.io/test-webserver name: pod-0 volumeMounts: - mountPath: /test-pd name: vol-0 volumes: - name: vol-0 scaleIO: gateway: https://localhost:443/api system: scaleio protectionDomain: sd0 storagePool: sp1 volumeName: vol-0 secretRef: name: sio-secret fsType: xfs
有關更多詳細信息，請參閱 ScaleIO 示例。
secret
secret 卷用於將敏感信息（如密碼）傳遞到 pod。您能夠將 secret 存儲在 Kubernetes API 中，並將它們掛載爲文件，以供 Pod 使用，而無需直接鏈接到 Kubernetes。 secret 卷由 tmpfs（一個 RAM 支持的文件系統）支持，因此它們永遠不會寫入非易失性存儲器。
重要提示：您必須先在 Kubernetes API 中建立一個 secret，而後才能使用它。
Secret 在這裏被更詳細地描述。
storageOS
storageos 卷容許將現有的 StorageOS 卷掛載到容器中。
StorageOS 在 Kubernetes 環境中以容器方式運行，使本地或附加存儲能夠從 Kubernetes 集羣中的任何節點訪問。能夠複製數據以防止節點故障。精簡配置和壓縮能夠提升利用率並下降成本。
StorageOS 的核心是爲容器提供塊存儲，能夠經過文件系統訪問。
StorageOS 容器須要 64 位 Linux，沒有額外的依賴關係。可使用免費的開發者許可證。
重要提示：您必須在每一個要訪問 StorageOS 卷的節點上運行 StorageOS 容器，或者爲該池提供存儲容量。相關的安裝說明，請參閱 StorageOS文檔。
apiVersion: v1 kind: Pod metadata: labels: name: redis role: master name: test-storageos-redis spec: containers: - name: master image: kubernetes/redis:v1 env: - name: MASTER value: "true" ports: - containerPort: 6379 volumeMounts: - mountPath: /redis-master-data name: redis-data volumes: - name: redis-data storageos: # The `redis-vol01` volume must already exist within StorageOS in the `default` namespace. volumeName: redis-vol01 fsType: ext4
有關更多信息，包括動態配置和持久化卷聲明，請參閱 StorageOS 示例。
vsphereVolume
先決條件：配置了 vSphere Cloud Provider 的 Kubernetes。有關雲提供商的配置，請參閱 vSphere 入門指南。
vsphereVolume 用於將 vSphere VMDK 卷掛載到 Pod 中。卷的內容在卸載時會被保留。支持 VMFS 和 VSAN 數據存儲。
重要提示：在 Pod 中使用它以前，您必須使用如下一種方法建立 VMDK。
建立 VMDK 卷
選擇如下方法之一來建立 VMDK。
首先進入 ESX，而後使用如下命令建立一個 VMDK：
vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk
使用下列命令建立一個 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 # This VMDK volume must already exist. vsphereVolume: volumePath: "[DatastoreName] volumes/myDisk" fsType: ext4
更多的例子能夠在這裏找到。
使用 subPath
有時，在單個容器中共享一個卷用於多個用途是有用的。volumeMounts.subPath 屬性可用於在引用的卷內而不是其根目錄中指定子路徑。
下面是一個使用單個共享卷的 LAMP 堆棧（Linux Apache Mysql PHP）的示例。 HTML 內容被映射到它的 html 目錄，數據庫將被存儲在它的 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
資源
emptyDir 卷的存儲介質（磁盤、SSD 等）由保存在 kubelet 根目錄的文件系統的介質（一般是 /var/lib/kubelet）決定。 emptyDir 或 hostPath 卷可佔用多少空間並無限制，容器之間或 Pod 之間也沒有隔離。
在未來，咱們預計 emptyDir 和 hostPath 卷將可以使用 resource 規範請求必定的空間，並選擇要使用的介質，適用於具備多種媒體類型的集羣。
Out-of-Tree 卷插件
除了以前列出的卷類型以外，存儲供應商能夠建立自定義插件而不將其添加到 Kubernetes 存儲庫中。能夠經過使用 FlexVolume 插件來實現。
FlexVolume使用戶可以將供應商卷掛載到容器中。供應商插件是使用驅動程序實現的，該驅動程序支持由 FlexVolume API定義的一系列卷命令。驅動程序必須安裝在每一個節點的預約義卷插件路徑中。
更多細節能夠在這裏找到。
掛載傳播
注意：掛載傳播是 Kubernetes 1.8 中的一個 alpha 特性，在未來的版本中可能會從新設計甚至刪除。
掛載傳播容許將由容器掛載的卷共享到同一個 Pod 中的其餘容器上，甚至是同一節點上的其餘 Pod。
若是禁用 MountPropagation 功能，則不會傳播 pod 中的卷掛載。也就是說，容器按照 Linux內核文檔中所述的 private 掛載傳播運行。
要啓用此功能，請在 --feature-gates 命令行選項中指定 MountPropagation = true。啓用時，容器的 volumeMounts 字段有一個新的 mountPropagation 子字段。它的值爲：
HostToContainer：此卷掛載將接收全部後續掛載到此卷或其任何子目錄的掛載。這是 MountPropagation 功能啓用時的默認模式。
一樣的，若是任何帶有 Bidirectional 掛載傳播的 pod 掛載到同一個捲上，帶有 HostToContainer 掛載傳播的容器將會看到它。
該模式等同於Linux內核文檔中描述的 rslave 掛載傳播。
Bidirectional卷掛載與HostToContainer掛載相同。另外，由容器建立的全部卷掛載將被傳播回主機和全部使用相同卷的容器的全部容器。
此模式的一個典型用例是帶有 Flex 卷驅動器或須要使用 HostPath 卷在主機上掛載某些內容的 pod。
該模式等同於 Linux內核文檔中所述的 rshared 掛載傳播。
當心：雙向掛載傳播多是危險的。它可能會損壞主機操做系統，所以只能在特權容器中使用。強烈建議熟悉 Linux 內核行爲。另外，容器在 Pod 中建立的任何卷掛載必須在容器終止時銷燬（卸載）。
參考
原文： https://jimmysong.io/posts/kubernetes-volumes-introduction/