导语：
Docker容器的设计原理是当容器消融时，容器内的存储也随之消失，但是实际情况中有很多是需要进行持久化的存储的，所以也很有必要进行Kubernetes持久化存储的概念说明。
Kubernetes存储组成
1.本地化的存储
2.网络化的存储
3.其他特殊存储
本地化的存储
①EmptyDir，EmptyDir是一个空目录，其的生命周期和所属的Pod是完全一致的。EmptyDir的用处是可以在同一 Pod
内的不同容器之间共享工作过程中产生的文件。缺省情况下，EmptyDir 是使用主机磁盘进行存储的，也可以设置emptyDir.medium
字段的值为Memory，来提高运行速度，但是这种设置，对该卷的占用会消耗容器的内存份额。
②HostPath，HostPath存储会把宿主机上的指定卷加载到容器之中，如果Pod发生跨主机的重建，其内容就难保证了。一般是用于本地化的日志存储。
网络化的存储
Kubernetes网络存储是学习的重点，Kubernetes支持为数众多的云提供商和网络存储方案。各种支持的方式不尽相同，例如
GlusterFS 需要创建 Endpoint，Ceph/NFS
之流就没这么麻烦了。各种配置需参考不同供应商的文档，本文就以NFS网络存储作为模型。
①静态PV,静态PV和使用它的Pod之间是一种静态绑定关系，在定义Pod的文件里，同时定义了它使用的Volume。Volume 是Pod的附属品，无法单独创建一个Volume，因为它不是一个独立的K8S资源对象。
②动态PV,动态PV是一个Kubernetes资源对象，所以可以单独创建一个PV。它不和Pod直接发生关系，而是通过Persistent Volume Claim，简称PVC来实现动态绑定，然后PVC会根据Pod的要求去自动绑定合适的PV给Pod使用。
PV的使用过程
一个PV创建完后状态会变成Available，等待被PVC绑定。一旦被PVC邦定，PV的状态会变成Bound，就可以被定义了相应PVC的Pod使用。Pod使用完后会释放PV，PV的状态变成Released。变成Released的PV会根据定义的回收策略做相应的回收工作。最后还有一种特殊的情况，Failed
自动回收失败。在实际使用场景里，PV的创建和使用通常不是同一个人。这里有一个典型的应用场景：管理员创建一个PV池，开发人员创建Pod和PVC，PVC里定义了Pod所需存储的大小和访问模式，然后PVC会到PV池里自动匹配最合适的PV给Pod使用。
PV的回收机制
Retain，允许人工处理保留的数据。
Delete ，将删除PV和外部关联的存储资源。
Recycle，将执行清除操作，之后可以被新的PVC使用。
PV的访问模式
ReadWriteOnce，是最基本的方式，可读可写，但只支持被单个Pod挂载。
ReadOnlyMany，可以以只读的方式被多个Pod挂载。
ReadWriteMany，这种存储可以以读写的方式被多个Pod共享。
不是每一种存储都支持这三种方式，像共享方式，目前支持的还比较少，比较常用的是NFS。在PVC绑定PV时通常根据两个条件来绑定，一个是存储的大小，另一个就是访问模式。
官方实例
PVC
容器实例
PV
其他特殊存储
在完善的应用开发中，都会涉及到配置文件的变更，一个正常应用程序从写第一行代码开始，要经历开发环境、测试环境、预发布环境只到最终的线上环境。而每一个环境都要定义其独立的各种配置。如果我们不能很好的管理这些配置文件，运维工作将顿时变的无比的繁琐。为此业内的一些大公司专门开发了自己的一套配置管理中心，如百度的disconf等。Kubernetes也提供了自己的一套方案，即ConfigMap。Kubernetes通过ConfigMap来实现对容器中应用的配置管理。