导语:
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 来实现对容器中应用的配置管理.
来源: https://juejin.im/entry/5b34b9a1e51d4558a21fa18f