深入剖析 Kubernetes
张磊
Kubernetes 社区资深成员与项目维护者
116705 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 57 讲
再谈开源与社区 (1讲)
结束语 (1讲)
深入剖析 Kubernetes
15
15
1.0x
00:00/00:00
登录|注册

19 | 深入理解StatefulSet(二):存储状态

关键在于,重建后的节点进行数据恢复和同步的时候,是否一定需要原先它写在本地磁盘里的数据
根据不同的项目而定
新节点加入集群时,或老节点被迁移后重建时,可以从主节点或其他从节点同步数据
解析出来的Pod的IP地址,会随着后端Pod的删除和再创建而自动更新
为有编号的Pod,在DNS服务器中生成带有同样编号的DNS记录
获取保存在Volume里的数据
通过PVC挂载对应的PV
由运维人员维护
为PVC绑定具体的实现
通过Persistent Volume机制为PVC绑定对应的PV
一种特殊的Volume
使用Kubernetes里的两个标准功能:Headless Service和PV/PVC,实现了对Pod的拓扑状态和存储状态的维护
为每一个Pod分配并创建一个同样编号的PVC
控制器直接管理的是Pod
是否有必要将节点Pod与它的PV进行一对一绑定
分布式应用的集群
Headless Service
Pod
PV
PVC
StatefulSet
思考题
StatefulSet处理应用实例之间的“存储状态”
如何用StatefulSet处理应用实例之间的“存储状态”

该思维导图由 AI 生成,仅供参考

你好,我是张磊。今天我和你分享的主题是:深入理解 StatefulSet 之存储状态。
在上一篇文章中,我和你分享了 StatefulSet 如何保证应用实例的拓扑状态,在 Pod 删除和再创建的过程中保持稳定。
而在今天这篇文章中,我将继续为你解读 StatefulSet 对存储状态的管理机制。这个机制,主要使用的是一个叫作 Persistent Volume Claim 的功能。
在前面介绍 Pod 的时候,我曾提到过,要在一个 Pod 里声明 Volume,只要在 Pod 里加上 spec.volumes 字段即可。然后,你就可以在这个字段里定义一个具体类型的 Volume 了,比如:hostPath。
可是,你有没有想过这样一个场景:如果你并不知道有哪些 Volume 类型可以用,要怎么办呢
更具体地说,作为一个应用开发者,我可能对持久化存储项目(比如 Ceph、GlusterFS 等)一窍不通,也不知道公司的 Kubernetes 集群里到底是怎么搭建出来的,我也自然不会编写它们对应的 Volume 定义文件。
所谓“术业有专攻”,这些关于 Volume 的管理和远程持久化存储的知识,不仅超越了开发者的知识储备,还会有暴露公司基础设施秘密的风险。
比如,下面这个例子,就是一个声明了 Ceph RBD 类型 Volume 的 Pod:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了StatefulSet在处理应用实例之间的“存储状态”时所采用的机制。通过介绍Persistent Volume Claim(PVC)和Persistent Volume(PV)的API对象,以及它们如何降低用户声明和使用持久化Volume的门槛,文章阐述了开发人员如何使用PVC声明所需的Volume属性,并在应用的Pod中声明使用这个PVC。同时,运维人员负责给PVC绑定具体的PV,实现了PVC与PV的解耦,避免了暴露存储系统细节的隐患。 进一步介绍了StatefulSet对存储状态的管理,通过添加volumeClaimTemplates字段,StatefulSet会为管理的每个Pod声明一个对应的PVC,并自动创建与PVC匹配的PV。最后,通过实际操作验证了StatefulSet创建的Pod在删除后重新创建时,能够保持存储状态的稳定性。文章通过深入的技术解析,帮助读者理解了StatefulSet在处理应用实例存储状态时的机制,为读者提供了宝贵的技术知识。 总结来看,本文详细介绍了StatefulSet处理存储状态的方法,并梳理了StatefulSet控制器的工作原理。通过对StatefulSet的设计思想和工作原理的解析,读者可以深入理解StatefulSet在Kubernetes中的重要作用,以及其在处理存储状态时的独特优势。文章还提出了思考题,引发读者对于分布式应用集群中节点与PV绑定的必要性进行思考。整体而言,本文为读者提供了深入的技术视角,帮助他们更好地理解和应用StatefulSet在Kubernetes中的作用和特点。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入剖析 Kubernetes》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(73)

  • 最新
  • 精选
  • 虎虎❤️
    老师,由于无法追问,恳请能够回复详细一些。提前谢过了。 pvc的使用方式当中,对于由运维人员去创建pv,我始终有些疑问。 首先,一个pv对应一个pvc。如果实际绑定的pvc小于pv声明的存储大小,会造成存储的浪费吗? 其次,运维人员事先要创建多少个,以及多大容量的pv呢?因为并不清楚开发人员将来可能用多少1g的,10g的或者100g的pvc。创建的数量或大小不合适,会导致pv不够用。开发还是会来找运维的。 最后,如果回收方式是retain,那么pvc删除后,原来的pv并不会删除,如果开发人员想重新使用同一块存储,需要重建pv。这带来了很多运维工作。 所以,手动创建pv的最佳实践是怎样的呢?当然,如果用storage class去动态创建pv可以解决这件事,但是有时我们希望针对namespace创建属于自己的pv来限制存储的使用quota,而不得不用手动创建pv的模式。

    作者回复: 手动创建PV就是有这些问题,要不然为啥推崇storageclass呢。可以自己编写external provisioner来代替你自己写pv啊,跟你用storageclass一样。

    2018-10-05
    6
    77
  • 不知所措
    老师你好,statefulset 如果 不同的pod ,需要不同的配置, 比如说 zk集群,每个集群的myid 都是不同的,比如mysql集群每个主机的serverid 也是不同的,这种的怎么处理呢?

    作者回复: 用operator

    2018-12-11
    3
    25
  • silver
    所以大体是Pod与PVC绑定,PVC与PV绑定,所以完成了Pod与PV的绑定?

    作者回复: 是

    2018-10-10
    4
    16
  • Terry Hu
    由于没有ceph server ,pv用hostPath方式,在master上创建了index.html,pv pvc都创建好了,bound上了,登陆容器后在/usr/share/nginx/html目录下死活找不到index.html,搞了一个小时。突然猛醒原来hostPath指的是worker节点的path......哎,蠢啊

    作者回复: 吃一堑长一智

    2018-11-28
    4
    15
  • Joe Black
    对于有些应用,比如关系数据库,它保存数据文件的位置必须严格符合POSIX接口,远程文件系统例如NFS对于类似锁定这样的操作支持的不好,即使是sqlite官方文档也不推荐用NFS。这种情况下,数据库应用好像只能用本地硬盘或者iSCSI的存储盘,这不就等同必须把重启的StatefulSet的Pod每次调度到同一个机器上才行吗?因为那个机器硬盘上的文件不会自动传输到其它机器上。是不是可以这么理解?

    作者回复: 关系数据库也可以做replication同步数据啊。pv跟机器没有绑定关系,除非用的是local pv,这时候调度器会保证pod的调度正确。

    2018-10-14
    13
  • Alery
    前辈,我有个疑问,我通过deployment创建一个pods,在podTemplate中我声明volume使用persistentVolumeClaim并指定我事先创建pvc name, 这个时候我删除pod, 同样当pod删除的时候并不影响我事先创建的这个pvc,我是不是可以认为deployment这种资源也是能保存存储状态的呢?

    作者回复: deloyment不认识pvc模板

    2018-10-16
    12
  • kitsdk
    pv对象不会绑定namespace吗? 命令 kubectl -n myns delete pv --all --include-uninitialized 执行完了,所有的pv也进入删除状态,当然因为有其他的pv绑定,没有立即删除。

    作者回复: pv是cluster level的

    2019-04-16
    3
    11
  • 北卡
    asdf100的问题应该是:一个集群中可能有很多个pv, pvc是如何找到他对应的pv的? 试着回答一下: 1、 指定了storageClassName的pv, 只有指定了同样storageClassName的pvc才能绑定到它上面。 2、对于没有指定storageClassName的pv,默认classname为"", 同样只有没有指定classname的pvc才能绑定到它上面。 3、pvc可以用matchLabels和matchExpressions来指定标签完成更详细的匹配需求。 4、匹配成功应该还需要一些基本的存储条件吧,比如pvc申请的存储空间肯定不能大于指定的pv. 关于第四点没有验证过,用aws的efs可以动态扩展空间的,好像没有这些限制。请张老师详细解答一下。

    作者回复: 容量是重要的匹配条件之一

    2018-10-06
    11
  • LQ
    在一个 Pod 里面有两个容器, 容器 a 里自己实现一个 fuse filesystem,将远程的文件(比如 hdfs 上的数据)mount 到该容器里,另外一个容器 b 通过什么方式能读取到容器 a 里 mount 的数据呢,通过 PV 吗?有啥解决方案没?

    作者回复: 你让a通过挂载传播到宿主机上,然后b挂载宿主机目录试试。

    2018-10-17
    3
    6
  • yuliz
    storage: 1Gi,表示我想要的 Volume 大小至少是 1 GB;这里是笔误么?1Gi不等于1GB,如果这里是1G应该更符合语景

    作者回复: 是的

    2018-10-10
    4
收起评论
显示
设置
留言
73
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部