实际上,如果只是为了职责划分,PV、PVC 体系确实不见得比直接在 Pod 里声明
Volumes 字段有什么优势。
不过,你有没有想过这样一个问题,如果Kubernetes 内置的 20 种持久化数据卷实现,都
没办法满足你的容器存储需求时,该怎么办?
这个情况乍一听起来有点不可思议。但实际上,凡是鼓捣过开源项目的读者应该都有所体
会,“不能用”“不好用”“需要定制开发”,这才是落地开源基础设施项目的三大常态。
而在持久化存储领域,用户呼声最高的定制化需求,莫过于支持“本地”持久化存储了。
也就是说,用户希望 Kubernetes 能够直接使用宿主机上的本地磁盘目录,而不依赖于远
程存储服务,来提供“持久化”的容器 Volume。
这样做的好处很明显,由于这个 Volume 直接使用的是本地磁盘,尤其是 SSD 盘,它的读
写性能相比于大多数远程存储来说,要好得多。这个需求对本地物理服务器部署的私有
Kubernetes 集群来说,非常常见。
所以,Kubernetes 在 v1.10 之后,就逐渐依靠 PV、PVC 体系实现了这个特性。这个特性
的名字叫作:Local Persistent Volume。
不过,首先需要明确的是,Local Persistent Volume 并不适用于所有应用。事实上,它
的适用范围非常固定,比如:高优先级的系统应用,需要在多个不同节点上存储数据,并且
对 I/O 较为敏感。典型的应用包括:分布式数据存储比如 MongoDB、Cassandra 等,分
布式文件系统比如 GlusterFS、Ceph 等,以及需要在本地磁盘上进行大量数据缓存的分布
式应用。
其次,相比于正常的 PV,一旦这些节点宕机且不能恢复时,Local Persistent Volume 的
数据就可能丢失。这就要求使用 Local Persistent Volume 的应用必须具备数据备份和恢
复的能力,允许你把这些数据定时备份在其他位置。
接下来,我就为你深入讲解一下这个特性。
不难想象,Local Persistent Volume 的设计,主要面临两个难点。
文档被以下合辑收录
评论