Ⅰ k8s分布式存储-Ceph
RADOS
Librados
Crush
Pool
PG
Object
Pool、PG和OSD的关系
OSD
块存储（ RBD )
文件存储（ CephFS )
对象存储（ Object )
关闭防火墙
关闭selinux
关闭 swap
根据规划设置主机名
添加 hosts
设置文件描述符
时间同步
配置 SSH 免交互认证
1、创建rbd使用的pool
2、指定存储池使用存储类型
3、创建一个块设备
3、查看块设备
1、禁用当前系统内核不支持的feature
2、映射（任意节点操作）
3、格式化块设备
4、mount到本地
5、取消块设备和内核映射
6、删除RBD块设备
1、拷贝配置文件和秘钥
2、安装 Ceph 客户端
3、剩余操作就与本地挂载操作一样了
1、创建快照
2、列出创建的快照
3、还原快照
4、重新映射并挂载验证
5、删除快照
1、创建一个块设备
2、创建快照
3、设置快照处于被保护状态
4、通过快照克隆一个新块设备
5、将克隆的快照独立于父设备
挂载本地目录
fuse方式挂载
**全部统一命名空间到 ceph-csi **
k8s节点安装 Ceph 客户端
csi-config-map.yaml
storageclass
secret
启动验证
rbd-pod-test.yaml
测试
**全部统一命名空间到 ceph-csi **
k8s节点安装 Ceph 客户端
csi-config-map
storageclass
secret
启动验证
ceph-cephfs-test
测试
Ⅱ k8s之存储
k8s的存储常用的就是上面几种模式，分为临时存储，半持久化存储，与持久化存储这三类，本章我们着重讲解emptydir与hostpath与pvc跟pv等
当pod的存储方案设定为emptydir的时候，pod启动时，就会在pod所在节点的磁盘空间开辟出一块空卷，最开始里面是什么都没有的，pod启动后容器产生的数据会存放到那个空卷中。空卷变成了一个临时卷
供pod内的容器读取和写入数据，一旦pod容器消失，节点上开辟出的这个临时卷就会随着pod的销毁而销毁
一般来说emptydir的用途都是用来充当临时存储空间，例如一些不需要数据持久化的微服务，我们都可以用emptydir来当做微服务pod的存储方案
k8s存储emptdir实战例子：以之前的myapp应用为例
创建应用
观察是否生产data目录，并在/data目录创建文件test.txt
手动删除容器模拟容器销毁，用于是pod是被控制器管理的，删除后会被重建新的pod
这时候在看我们之前创建的data.txt已经不见了
hostPath类型则是映射node文件系统中的文件或者目录到pod里。在使用hostPath类型的存储卷时，也可以设置type字段，支持的类型有文件、目录、File、Socket、CharDevice和BlockDevice（我只映射过文件与目录）。
其实这个功能就相当于docker中的-v 目录映射，只不过在k8s中的时候，pod会漂移，当pod漂移到其他node节点的时候，pod不会跨节点的去读取目录。所以说hostpath只能算一种半持久化的存储方式
实战例子
创建应用
在node节点可以看到生成了/data/volume目录，在里面创建测试文件
检验pod里面的/data是否存在这个映射目录的文件
可以看到刚才创建的文件已经映射到我们的目录里边了
为了验证是否映射到容器里面的目录也会随着pod生命周期的消失而消失，我们手动删除pod模拟容器终止
可以看到容器被删除后，新建的pod也可以看到我们映射的目录，而且里面数据test.txt还在。
这有个缺点就是不能够跨容器去读取数据，如果删除后的pod被调度到其他节点的话，原来的数据也就没有了，如果能不受节点的影响，并且挂载的数据不会随生命周期的结束而结束，我们应该怎么解决呢？就是我们后面讲到的持久化存储了
上面介绍了俩种临时存储于半持久化存储的方案。在k8s实际生产环境中，一般会选用私有云持久化存储方案还有公有云持久化存储方案，私有云存储方案包括nfs，ceph，glusterfs等方案。公有云存储会用到AWS等方案
存储方案各有各的优缺点，可参考 https://www.cnblogs.com/yswenli/p/7234579.html 这篇文章。今天我们主要讲解pvc，pv，nfs之间的关系。
简单来说，要使用持久化存储，就需要使用pvc去跟pv去申请，然后pv查看自己有没有合适的存储空间卷，有合适的就与pvc进行绑定。pv与pvc是一一对应绑定的。现在我们用一幅图来说明pvc，pv，nfs的关系
实战例子
准备存储服务安装nfs
接下来创建pv与nfs绑定
创建pvc与pv关联
创建并查看结果
注意：STATUS为Bound说明该pvc已经与pv绑定了
接下来创建pod来引用pvc
创建pod
接下来验证一下在nfs创建一个测试文件，看是否被映射到容器中
可以看到容器里面也可以看到创建的文件
手动删除容器，或者调度到其他节点原来的文件还是不会被删除的，这里就省略验证了，这就是nfs的好处，不过企业一般不会选用nfs，磁盘IO,性能读取方面不太理想，毕竟是本地存储，还是有一定的风险。推荐用用云存储。
文件存储提供无限扩展的文件系统来给云服务器存取数据实际上相当于nfs
1、已注册阿里云账号，并完成实名认证。
如果没有，请先注册阿里云账号，详情请参见阿里云账号注册流程。
2、已开通NAS服务。
首次登录NAS控制台时，根据页面提示开通NAS服务。
3、在需要创建文件系统的地域，已有可用的云服务器ECS。
k8s应用NAS实战例子
1、打开阿里云NAS控制台确认已创建好文件系统
2、把复制挂载参数把它挂载到服务器中创建测试目录，前提是服务器需要安装nfs客户端。
安装完成挂载到本地目录并创建test目录作为测试目录
并在里面创建一个测试文件1.txt
接下来可以创建pvc和pv了
创建并查看
接下来创建pod去引用pvc
创建pod
检验刚才的1.txt是否挂到容器的/data/nas下
云存储适合于生产环境k8s的存储解决方案
Ⅲ Kubernetes应用程序的保护和移动性策略
随着Kubernetes（K8s）和容器成为开发、部署、运行和扩展云原生和下一代IT应用程序的事实选择，企业正在K8s集群上运行越来越多的业务关键型应用程序。业务关键型应用程序通常是有状态的。有状态应用程序具有关联的状态、数据和配置信息，并依赖以前的数据事务来执行其业务逻辑。
Kubernetes上提供服务的业务关键型应用程序通常与传统应用程序一样具有可用性和业务连续性要求，这意味着服务中断（违反SLA）会严重影响提供商的收入和声誉。企业通常意识到，他们需要使用数据管理工具使其Kubernetes部署能够在影响服务的灾难之后或面临到新集群或环境的硬应用程序迁移任务时对服务故障具有恢复能力。
企业认识到这一需求，但使用内部开发的定制工具，这些工具很难在企业和应用程序团队之间进行扩展、应用和规范化。换句话说，这种工具是特定于应用程序的，需要为每个应用程序定制开发。因此，企业需要为其Kubernetes资产制定一个连贯一致的持久性和数据管理战略。
K8s应用程序数据持久性和管理的现状
更大的Kubernetes社区和生态系统在定义容器存储接口（CSI）方面做得非常出色，它解决了用户在有状态Kubernetes应用程序的持久存储资源调配和消耗方面的一阶问题。CSI接口还定义了数据管理原语，如对持久卷（PV）快照和克隆的支持。这些接口为存储和数据管理供应商建立综合应用数据保护和移动性解决方案奠定了基础。
Kubernetes数据管理（应用程序感知是关键），并不总是关于集群中的内容
目前还没有关于Kubernetes应用程序组成的具体定义。但是，对于大多数Kubernetes从业者和用户来说，K8s应用程序是通过包含有关应用程序的数据和元数据形成的，这些数据和元数据结合了标准K8s对象和资源（如ConfigMap、Secrets、Deployment、ReplicaSet）、Persistent Volumes（PV）和跨命名空间（在某些情况下，跨集群）的自定义资源（CRD和CRs）。因此，任何与应用程序无关的Kubernetes数据管理工具都需要考虑构成应用程序的所有这些组件。
如果不这样做，也不复制和/或备份与K8s应用程序关联的持久卷，则在灾难发生后恢复应用程序时，可能会导致一些严重的故障。将应用程序视为保护和迁移的整体单元是实现Kubernetes应用程序数据管理的关键。
使这种情况更加复杂的是主要用于公共云的云原生K8s应用程序设计模式，在公共云中，应用程序团队利用了使用完全托管的云服务（如数据库、消息队列和对象存储）的便利性、稳定性和性能。在这种情况下，根据定义，K8s应用程序不再局限于集群，而是跨集群之外的完全托管的服务。在Kubernetes集群中运行的应用程序中使用外部完全托管或自我管理的数据库是非常常见的。
在这种云原生开发设计模式的基础上，AWS和Azure等公共云使得通过Kubernetes原生API使用Kubernetes集群的完全托管服务变得更加容易。AWS Controllers for Kubernetes（ACK）和Azure Service Operator（for Kubernetes）就是例子。
Kubernetes原生持久性的替代方案——常见设计模式及其原因
如上所述，构建基于Kubernetes的现代服务的应用程序团队除了使用不限于K8s集群中使用持久卷的原生云服务外，还经常使用多种持久性技术。出现这种模式的原因有很多，包括但不限于：
——坚信Kubernetes是只运行无状态应用程序的优秀平台。
——在K8s集群上运行数据库的早期经验，或了解尝试这样做的失败项目。
——采用云原生和微服务方法，使用原生公共云DBaaS（例如AWS RDS、Google cloud sql、Azure Cosmos DB）、第三方供应商管理的数据存储（作为SaaS提供）或自我管理的外部数据库集群构建Kubernetes应用程序，感觉很正常。这种设计范式遵守云原生设计方法，它利用这些数据服务的可伸缩性、可恢复性、弹性和灵活性，在微服务之间使用基于API的契约。
——使用对象存储满足K8s持久性需要，因为它在公共云中无处不在，并且广泛用于持久化现代应用程序。
与其他选择一样，这些持久性选择也有缺点。使用完全托管的原生公共云数据库和NoSQL数据存储可能成本高昂，并导致对一个公共云的隐式锁定。但对于那些选择单一或主要云提供商满足其IT需求的企业来说，这可能是一个不错的设计选择。为了避免云提供商锁定，采用多云战略的企业通常使用第三方ISV提供的云不可知DBaaS产品。
在其他情况下，他们在云提供商的保留实例上运行外部数据库集群（利用折扣保留实例定价），以节省成本。这样做，他们最终会自我管理数据库集群，这可能会很乏味。
使用对象存储实现Kubernetes持久性非常流行。但是，使用对象存储也会使应用程序本身的可移植性降低，因为用于访问公共云中原生对象存储服务的API不兼容，因为不支持相同的API。K8s社区正在开发一个新的标准容器对象存储接口（COSI），为使用K8s应用程序的对象存储提供公共抽象层，这将让使用对象存储的K8s应用程序的可移植性更容易。此外，对象存储不适用于许多现有应用程序，即使它们正在重构。
这对企业意味着什么？
很明显，Kubernetes应用程序的组成及其持久性需求的定义并不总是精确地映射到集群内的Kubernetes资源和连接到集群内运行的pod的持久卷。K8s数据持久性的选择非常丰富，每种选择都有其优缺点。这意味着流行的K8s应用程序数据管理功能（如备份、恢复、迁移和合规性）必须包括K8s集群内部的内容，以及可能位于集群外部且是应用程序不可分割的一部分的对象和资源。
例如，对K8s应用程序进行一致备份还意味着触发对完全管理的公共云数据库的备份，该数据库除了K8s资源、元数据和Kubernetes集群中存在的对象之外，还向该应用程序提供数据服务。除集群内K8s资源外，后续恢复过程还必须恢复外部数据库。
因此，企业必须仔细审查其K8s应用程序保护、移动性和合规性战略，并为其K8s存储和数据管理解决方案使用选择标准，以保证其应用程序团队和开发人员采用的最常见的云原生持久性设计模式。
原文链接：
https://thenewstack.io/kubernetes-application-protection-and-mobility-strategies/
Ⅳ 如何入门k8s
Kubernetes（简称K8S） 是Google开源的分布式的容器管理平台，方便我们在服务器集群中管理我们容器化应用。
节点（Master node and Worker node）
节点通常指的就是服务器，在k8s中有两种节点：管理节点（Master Node）和工作节点（Worker Node）
管理节点（Master Node）：负责管理整个k8s集群，一般由3个管理节点组成HA的架构。
工作节点（Worker Node）：主要负责运行容器。命名空间(Namespace)
k8s命名空间主要用于隔离集群资源、隔离容器等，为集群提供了一种虚拟隔离的策略；默认存在3个名字空间，分别是默认命名空间 default、系统命名空间 kube-system 和 kube-public。Object
k8s 对象(Object)是一种持久化存储并且用于表示集群状态的实体。k8s 对象其实就是k8s自己的配置协议，总之我们可以通过定义一个object让k8s根据object定义执行一些部署任务、监控任务等等。POD
Pod是 Kubernetes 部署应用或服务的最小的基本单位。一个Pod 封装多个应用容器（也可以只有一个容器）、存储资源、一个独立的网络 IP 以及管理控制容器运行方式的策略选项。副本集(Replica Set，RS)
是一种控制器，负责监控和维护集群中pod的副本(replicas)数，确保pod的副本数是我们期望的样子。部署(Deployment)
表示对k8s集群的一次更新操作，是k8s集群中最常用的Object，主要用于部署应用。支持滚动升级。服务(service)
是对应用的抽象，也是k8s中的基本操作单元，一个服务背后由多个pod支持，服务通过负载均衡策略将请求转发到容器中。Ingress
是一种网关服务，可以将k8s服务通过http协议暴露到外部。无状态应用 & 有状态应用
无状态应用指的是应用在容器中运行时候不会在容器中持久化存储数据，应用容器可以随意创建、销毁；如果一个应用有多个容器实例，对于无状态应用，请求转发给任何一个容器实例都可以正确运行。例如：web应用
有状态应用指的是应用在容器中运行时候需要稳定的持久化存储、稳定的网络标识、固定的pod启动和停止次序。例如：mysql数据库
Ⅳ K8s持久化存储
Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。
要使用 Volume，Pod 必须事先知道如下信息：
Pod 通常是由应用的开发人员维护，而 Volume 则通常是由存储系统的管理员维护。开发人员要获得上面的信息：
要么询问管理员。
要么自己就是管理员。
这样就带来一个管理上的问题：应用开发人员和系统管理员的职责耦合在一起了。如果系统规模较小或者对于开发环境这样的情况还可以接受。但当集群规模变大，特别是对于生成环境，考虑到效率和安全性，这就成了必须要解决的问题。
Kubernetes 给出的解决方案是什么 PersistentVolume （PV）和 PersistentVolumeClaim（PVC）。
PersistentVolume (PV) 是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV 具有持久性，生命周期独立于 Pod。
PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时，用户可以创建一个 PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes 查找并提供满足条件的 PV。
有了 PersistentVolumeClaim，用户只需要告诉 Kubernetes 需要什么样的存储资源，而不必关心真正的空间从哪里分配，如何访问等底层细节信息。这些 Storage Provider 的底层信息交给管理员来处理，只有管理员才应该关心创建 PersistentVolume 的细节信息。
1、配置nfs
需要安装
k8s-master：nfs-server
k8s-node1：nfs-client
k8s-node2：nfs-client
所有节点安装nfs
在master节点创建共享目录
编辑exports文件
启动rpc和nfs（注意顺序）
作为准备工作，我们已经在 k8s-master 节点上搭建了一个 NFS 服务器，目录为 /nfsdata：
2、创建PV
下面创建一个 PV mypv，配置文件 nfs-pv.yml 如下：
① capacity 指定 PV 的容量为 1G。
② accessModes 指定访问模式为 ReadWriteOnce，支持的访问模式有：
ReadWriteOnce：PV 能以 read-write 模式 mount 到单个节点。
ReadOnlyMany：PV 能以 read-only 模式 mount 到多个节点。
ReadWriteMany ：PV 能以 read-write 模式 mount 到多个节点。
③ persistentVolumeReclaimPolicy 指定当 PV 的回收策略为 Recycle，支持的策略有：
Retain： 需要管理员手工回收。
Recycle：清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*。
Delete： 删除 Storage Provider 上面的对应存储资源，例如 AWS EBS、GCE PD、Azure Disk、- OpenStack Cinder Volume 等。
④ storageClassName 指定 PV 的 class 为 nfs。相当于为 PV 设置了一个分类，PVC 可以指定 class 申请相应 class 的 PV。
⑤ 指定 PV 在 NFS 服务器上对应的目录。
创建 mypv：
STATUS 为 Available，表示 mypv 就绪，可以被 PVC 申请。
3、创建PVC
接下来创建 PVC mypvc，配置文件 nfs-pvc.yml 如下：
部署pvc
4、创建pod
上面已经创建好了pv和pvc，pod中直接使用这个pvc即可
与使用普通 Volume 的格式类似，在 volumes 中通过 persistentVolumeClaim 指定使用 mypvc 申请的 Volume。
通过命令创建mypod：
在这里，可以尝试在任何一方删除文件，文件在两端都会消失；
当 PV 不再需要时，可通过删除 PVC 回收。未删除pvc之前 pv的状态是Bound
删除pod
删除pvc
再次查看pv的状态
删除pvc之后pv的状态变为Available，，此时解除绑定后则可以被新的 PVC 申请。
/nfsdata文件中的文件被删除了
因为 PV 的回收策略设置为 Recycle，所以数据会被清除，
但这可能不是我们想要的结果。如果我们希望保留数据，可以将策略设置为 Retain
虽然 mypv 中的数据得到了保留，但其 PV 状态会一直处于 Released，不能被其他 PVC 申请。为了重新使用存储资源，可以删除并重新创建 mypv。删除操作只是删除了 PV 对象，存储空间中的数据并不会被删除。
PV 还支持 Delete 的回收策略，会删除 PV 在 Storage Provider 上对应存储空间。NFS 的 PV 不支持 Delete，支持 Delete 的 Provider 有 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。
前面的例子中，我们提前创建了 PV，然后通过 PVC 申请 PV 并在 Pod 中使用，这种方式叫做静态供给（Static Provision）。
与之对应的是动态供给（Dynamical Provision），即如果没有满足 PVC 条件的 PV，会动态创建 PV。相比静态供给，动态供给有明显的优势：不需要提前创建 PV，减少了管理员的工作量，效率高。
基于NFS的PV动态供给(StorageClass)
静态：pod-->pvc-->pv
动态：pod -->pvc-->storageclass
去官网下载三个文件
这三个文件去网上下载 https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client/deploy
使用脚本批量下载：
其中deployment.yaml需要修改一下挂载的地址,目录,镜像版本
然后分别去应用这三个文件
创建pod进行测试
查看pv和pvc
在部署 statefulset 类型的工作负载时，动态创建 PV/PVC 是一种比较常用的配置方式，动态创建 PV/PVC 的方法基本如下：
一直启动不起来，查看 pvc 和 pods 信息如下：
从上边的现象来看，是 PVC 没有创建成功，动态 PVC 中，是 provisioner 中来负责创建，查看其日志，看到如下错误信息：
Google 之后，找到主要原因是，官方在 k8s 1.20 中基于对性能和统一 apiserver 调用方式的初衷，移除了对 SelfLink 的支持，而 nfs-provisioner 需要 SelfLink 该项功能。具体计划和原因可查看这个 issue[2] 和 KEP[3] 。
K3S 为兼容 K8S 应该也继承了该项修改，按 K8S 的方式修改测试了下，完美解决。
解决问题主要有下边两种方式：
1、修改 apiserver 的配置文件，重新启用 SelfLink 功能。针对 K8S，可添加如下配置：
K3S 中没有 apiserver 的配置文件，可通过 systemd 的启动文件添加该参数，如下：
若为新安装，可如下启用：
2、使用新的不基于 SelfLink 功能的 provisioner 镜像，重新创建 provisioner 容器。
若你能科学上网，可使用这个镜像：
国内可使用这个镜像【若不可用自己查找】：
Ⅵ K8s怎么对象分布式存储
K8s对象分布式存储的方式很多，我们用的元核云分布式块存储，用的就是ceph-csi对接的他们的rbd块存储。
Ⅶ [K8S系列七]存储-PV、PVC与Storage Class
本质上说，一个volume(卷)就是一个目录，从容器内部可以访问这个目录中的内容，而这个目录是怎么来的，它背后的媒介是什么以及它里面的内容，都是由volume的类型来决定的；而使用volume，只需要在pod上指定使用哪种类型的volume，以及mount到容器中的什么位置即可。K8S支持的存储类型如下所示，这里主要介绍HostPath和Persistent Volume。
hostPath 类型的volume是映射Pod所在的节点的文件或者目录到 pod 里。在使用 hostPath 类型的存储卷时，也可以设置 type 字段，支持的类型有文件、目录、File、Socket、CharDevice 和 BlockDevice。
根据附录1的volume-pod.yaml创建一个pod，使用hostPath类型的volume
部署后查看pods详情， 发现volume-pod位于w2节点，登录到w2 尝试在pods的容器中创建文件
因为hostPath类型的volume只映射pod所在的节点的文件或目录到pod中，如果pod因为重启被调度到其他节点时，将会看不到原来节点保存的数据，因此有了网络存储+pv+pvc的方式。
通过PersistentVolume(PV)与PersistentVolumeClaim(PVC)将提供存储与消费存储分离：
2.PVC由用户创建来消费存储，如同通过创建pod来消费cpu、mem资源。
PVC与PV是通过PersistentVolume Controller 进行绑定的。PV Controller 会不断地循环去查看每一个 PVC，是不是已经处于 Bound（已绑定）状态。如果不是，那它就会遍历所有的、可用的 PV，并尝试将其与未绑定的 PVC 进行绑定，这样，Kubernetes 就可以保证用户提交的每一个 PVC，只要有合适的 PV 出现，它就能够很快进入绑定状态。而所谓将PV 与 PVC 进行“绑定”，其实就是将这个 PV 对象的名字，填在了 PVC 对象的 spec.volumeName 字段上 。
这里以NFS+PV+PVC为例进行说明， NFS搭建过程请参考附录2，根据考附录3 nginx-pv-pvc.yaml ，创建nginx(deployment)、nginx-pv(pv)、nginx-pvc(pvc)。nginx-pv挂载在/nfs/data/nginx 下。在/nfs/data/nginx下创建文件1.html，pod中也可以访问，并且pod的重新创建不影响1.html。
上节说的PV和PVC方法虽然能实现屏蔽底层存储，但是PV创建比较复杂，通常都是由集群管理员管理，这非常不方便。
利用StorageClass实现，可以根据PVC需求，自动构建相对应的PV持久化存储卷，进一步简化运维管理成本。
StorageClass对象会定义下面两部分内容:
示例部分参考 nfs-subdir-external-provisioner 。 相关文件来源于 deploy ，需要略作修改。
1. Volumes
2.《kubernetes权威指南》
3. Kubernetes 存储设计
NFS(Network File System)网络文件系统，是FreeBSD支持的文件系统中的一种，允许网络中的计算机之间通过TCP/IP网络共享资源。
Ⅷ 通过K8S部署对象存储MinIO
MinIO 是全球领先的对象存储先锋，以 Apache License v2.0 发布的对象存储服务器，是为云应用和虚拟机而设计的分布式对象存储服务器。在标准硬件上，读/写速度上高达183GB/s和171GB/s。它与 Amazon S3 云存储服务兼容。 它最适用于存储非结构化数据，如照片、视频、日志文件、备份和容器/虚拟机映像。 对象的大小可以从几KB 到最大5TB。
MinIO是一个非常轻量的服务,可以很简单的和其他应用的结合，类似 NodeJS, Redis 或者 MySQL。
MinIO支持多种灵活的部署方式，支持Docker Compose、Docker Swam、Kubernetes等，详见官网： https://docs.min.io/docs/minio-deployment-quickstart-guide.html 或者 https://min.io/download#/linux
这里着重介绍K8S下部署
1、standalone模式
由于service采用NodePort类型，通过主机IP:32593访问web
2、distributed模式
分布式部署，实例数至少4个，所以需要另外创建4个pv
Ⅸ 9. K8s存储
Kubernetes的Volume是Pod的一部分，Volume不是单独的对象，不能独立创建，只能在Pod中定义。
Pod中的所有容器都可以访问Volume，但必须要挂载，且可以挂载到容器中任何目录。
实际中使用容器存储如下图所示，将容器的内容挂载到Volume中，通过Volume两个容器间实现了存储共享。
Volume的生命周期与挂载它的Pod相同，但是Volume里面的文件可能在Volume消失后仍然存在，这取决于Volume的类型。
Kubernetes的Volume有非常多的类型：
这个Volume挂载后就是一个空目录，应用程序可以在里面读写文件，emptyDir Volume的生命周期与Pod相同，Pod删除后Volume的数据也同时删除掉。
emptyDir的一些用途：
配置示例
emptyDir也可以设置存储介质为内存
HostPath存储的内容与节点相关，如果Pod被调度到其他Node，HostPath无法提供跨Node的数据。
配置示例
ConfigMap存储的是键值对，在Volume中应用时键值对表示的是 文件名 和 文件内容 ，代表将ConfigMap的每条数据填入Volume。ConfigMap的配置数据在 data 字段下定义。
ConfigMap文件示例
Volume中引用ConfigMap
与ConfigMap类似，在data字段中存储key-value键值对形式，不过存储的value不是明文，是Base64编码的加密值。
在Volume中引用后，文件中的值是Base64解码后的值，而非加密值。
Kubernetes抽象了PV（PersistentVolume）和PVC（PersistentVolumeClaim）来解耦网络存储种类多样的问题，从而让使用者不用关心具体的基础设施，当需要存储资源的时候，只要像CPU和内存一样，声明要多少即可。
PV是集群级别的资源，并不属于某个命名空间（在 default 命名空间下），而PVC是命名空间级别的资源，PV可以与任何命名空间的PVC资源绑定。
Kubernetes管理员设置好网络存储的类型，提供对应的PV描述符配置到Kubernetes，使用者需要存储的时候只需要创建PVC，然后在Pod中使用Volume关联PVC，即可让Pod使用到存储资源，它们之间的关系如下图所示。
PV 持久卷是用 插件 的形式来实现的，目前支持以下插件：
CSI
Container Storage Interface，容器存储接口，基于CSI这套接口，可以开发定制出CSI插件，从而支持特定的存储，达到解耦的目的。
PVC创建示例：
使用StorageClass可以自动创建PV，StorageClass包含 provisioner 、 parameters 和 reclaimPolicy 字段， 这些字段会在 StorageClass 需要动态分配 PersistentVolume 时会使用到。在声明PVC时加上StorageClassName，就可以自动创建PV，并自动创建底层的存储资源。
provisioner： PV配置器，用来决定使用哪个卷插件制备 PV。 该字段必须指定。
reclaimPolicy： 回收策略，可以是 Delete 或者 Retain ，默认是 Delete
使用StorageClassName创建PVC示例：