标签：存储 PV Kubernetes 存储系统 Volume PVC Pod 机制
徐迪 分布式实验室
本文分为三大部分。第一部分主要介绍Kubernetes中常用的几种存储，及其使用场景和生命周期等等。第二部分试图介绍一些设计原则和基本架构，并简要介绍各种存储plugin的实现机制及持久卷的一些特性，例如访问模式、回收策略等等。动态卷供给是一个Kubernetes独有的功能，这一功能允许按需创建存储卷，使管理员不必预先创建存储卷，而是随用户需求进行创建。第三部分会介绍一下v1.9中存储的一些新特性。
一、Kubernetes中存储的应用场景
1. 无状态服务
Kubernetes使用ReplicaSet来保证一个服务的实例数量，如果说某个Pod实例由于某种原因挂掉或崩溃，ReplicaSet会立刻用这个Pod的模版新启一个Pod来替代它。由于是无状态的服务，新Pod与旧Pod一模一样。此外Kubernetes通过Service（一个Service后面可以挂多个Pod）对外提供一个稳定的访问接口，实现服务的高可用。
2. 普通有状态服务
和无状态服务相比，它多了状态保存的需求。Kubernetes提供了以Volume和Persistent Volume为基础的存储系统，可以实现服务的状态保存。
3. 有状态集群服务
和普通有状态服务相比，它多了集群管理的需求。要运行有状态集群服务要解决的问题有两个，一个是状态保存，另一个是集群管理。Kubernetes为此开发了StatefulSet（以前叫做PetSet），方便有状态集群服务在Kubernetes上部署和管理。
简单来说是通过Init Container来做集群的初始化工作，用Headless Service来维持集群成员的稳定关系，用动态存储供给来方便集群扩容，最后用StatefulSet来综合管理整个集群。
分析以上的服务类型，Kubernetes中对于存储的使用主要集中在以下几个方面：
服务的基本配置文件读取、密码密钥管理等；
服务的存储状态、数据存取等；
不同服务或应用程序间共享数据。
Kubernetes已经提供非常丰富的Volume和Persistent Volume插件，大家可以根据自己业务的需要，使用这些插件给容器提供存储服务。每一种Plugin的使用方法和注意事项在此不做赘述，请参考Kubernetes Volume 的官方文档[1]。
容器存储接口（Container Storage Interface，CSI[2]）是一项跨行业标准倡议，旨在降低云原生存储开发工作的门槛，从而进一步确保兼容性水平。Kubernetes v1.9已经引入了CSI的一套alpha实现版本，将新分卷插件的安装流程简化至与安装pod相当，并允许第三方存储供应商在无需接触核心Kubernetes代码库的前提下开发自己的解决方案。
如果上述的这些Plugin不满足业务要求, 你可以通过以下两种途径进行二次开发。
可以使用FlexVolume实现自己的Volume插件。此Plugin仍是alpha版本，后向兼容性需要考虑。具体方法在此不做赘述，参考FlexVolume的社区文档[3]。
推荐使用CSI。目前还只是alpha版本，使用时需要在feature-gate中enable，不推荐在production环境中使用。v1.9已经把CSI作为in-tree plugin，把out-off-tree volume插件的开发从 Kubernetes 中脱离出来，极大地方便了插件的开发、维护和集成。如何使用CSI，可参考How to Use Kubernetes 1.9.0 with CSI[4]。
Kubernetes中mount 一个PV的基本过程包括：
用户通过API创建一个包含PVC的Pod；
Scheduler把这个Pod分配到某个节点，比如Node1；
Node1上的Kubelet开始等待Volume Manager准备device；
PV controller调用相应Volume Plugin（in-tree或者out-of-tree），创建PV，并在系统中与对应的PVC绑定；
Attach/Detach controller或者Volume Manager通过Volume Plugin实现device挂载（Attach）；
Volume Manager等待device挂载完成后，将卷挂载到节点指定目录（mount）， 比如/var/lib/kubelet/pods/xxxxxxxxxxx/volumes/aws-ebs/vol-xxxxxxxxxxxxxxxxx；
Node1上的Kubelet此时被告知volume已经准备好后，开始启动Pod，通过volume mapping将PV已经挂载到相应的容器中去。
其实对于Kubernetes中大部分的Volume Plugin来说，mount的过程遵循着如下的规则：
这种方式的好处相当于热插拔，一旦Pod挂掉，kubelet可以马上重启，并快速mount volume，不会出现类似于device busy的情形。
但是对于hostpath这个Plugin而言，直接就是 /some/global/mount/path -> container volume。
Kubernetes使用两种资源管理存储：
PersistentVolume（简称PV）：由管理员添加的的一个存储的描述，是一个全局资源，包含存储的类型，存储的大小和访问模式等。它的生命周期独立于Pod，例如当使用它的Pod销毁时对PV没有影响。
PersistentVolumeClaim（简称PVC）：是Namespace里的资源，描述对PV的一个请求。请求信息包含存储大小，访问模式等。
Kubernetes中的Volume则是基于Docker进行扩展，使用Docker Volume挂载宿主机上的文件目录到容器中。
一般来说，Kubernetes中Pod通过如下三种方式来访问存储资源。
直接访问
该种方式移植性较差，可扩展能力差，把Volume的基本信息完全暴露给用户，有严重的安全隐患，同时需要协调不同users对Volume的访问。
静态provision
动态provision
StorageClass将说明Volume将由哪种Volume Plugin创建、创建时参数以及从其他功能性/非功能性角度描述的后台volume的各种参数。一般为storage cluster的一些配置信息，以及label注释信息。
一般来说，PV和PVC的生命周期分为5个阶段：
Provisioning，即PV的创建，可以直接创建PV（静态方式），也可以使用StorageClass动态创建
Binding，将PV分配给PVC
Using，Pod通过PVC使用该Volume
Releasing，Pod释放Volume并删除PVC
Reclaiming，回收PV，可以保留PV以便下次使用，也可以直接从云存储中删除
根据这5个阶段，Volume的状态有以下4种：
Available：可用
Bound：已经分配给PVC
Released：PVC解绑但还未执行回收策略
Failed：发生错误
五、v1.9中对存储做了哪些更改
引入了CSI alpha版本的实现，可见第二部分关于CSI的介绍。
修复Bug：删除运行状态container的PVC
这个bug会导致数据丢失。社区的解决办法是引入一个Finalizer来保护PVC。
详细的步骤请参考相关的Proposal[5]及其代码实现[6]。
简单来说，这个Fianlizer类似于垃圾回收（GC）里面的指针计数，当这个使用这个PVC的POD都被删除（deleted）或处于完成状态（completed）时，才可以删除这个PVC。从而避免了删除正在运行中的container的PVC，从而引发数据丢失。
标签：存储,PV,Kubernetes,存储系统,Volume,PVC,Pod,机制 来源： https://blog.51cto.com/u_15127630/2779280
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。