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

29 | PV、PVC体系是不是多此一举?从本地持久化卷谈起

你好,我是张磊。今天我和你分享的主题是:PV、PVC 体系是不是多此一举?从本地持久化卷谈起。
在上一篇文章中,我为你详细讲解了 PV、PVC 持久化存储体系在 Kubernetes 项目中的设计和实现原理。而在文章最后的思考题中,我为你留下了这样一个讨论话题:像 PV、PVC 这样的用法,是不是有“过度设计”的嫌疑?
比如,我们公司的运维人员可以像往常一样维护一套 NFS 或者 Ceph 服务器,根本不必学习 Kubernetes。而开发人员,则完全可以靠“复制粘贴”的方式,在 Pod 的 YAML 文件里填上 Volumes 字段,而不需要去使用 PV 和 PVC。
实际上,如果只是为了职责划分,PV、PVC 体系确实不见得比直接在 Pod 里声明 Volumes 字段有什么优势。
不过,你有没有想过这样一个问题,如果Kubernetes 内置的 20 种持久化数据卷实现,都没办法满足你的容器存储需求时,该怎么办?
这个情况乍一听起来有点不可思议。但实际上,凡是鼓捣过开源项目的读者应该都有所体会,“不能用”“不好用”“需要定制开发”,这才是落地开源基础设施项目的三大常态。
而在持久化存储领域,用户呼声最高的定制化需求,莫过于支持“本地”持久化存储了。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入剖析 Kubernetes》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(40)

  • 最新
  • 精选
  • vx:jiancheng_goon
    如果是容器化的kubelet要如何解决本地PV的问题,因为发现kubelet写的数据,都写在了容器里了,而没有在宿主机上。

    作者回复: 这是你volume没弄好吧……

  • shaobo
    k8S部署kfk,es可以用local persistent volume吗

    作者回复: 可以,但是没有持久战性

    3
  • realc
    知其然,知其所以然。很多教程教材,就跟上学时学校直接灌给我们一样,要让我们去硬啃。不如老师这课程,一个知识点,一个功能的来龙去脉、前世今生都给讲的清清楚楚的。
    71
  • 虎虎❤️
    思考题,我的理解: 因为当一个pvc创建之后,kubernetes因为dynamic provisioning机制会调用pvc指定的storageclass里的provisioner自动使用local disk的信息去创建pv。而且pv一旦创建,nodeaffinity参数就指定了固定的node。而此时,provisioner并没有pod调度的相关信息。 延迟绑定发生的时机是pod已经进入调度器。此时对应的pv已经创建,绑定了node。并可能与pod的调度信息发生冲突。 如果dynamic provisioning机制能够推迟到pod 调度的阶段,同时考虑pod调度条件和node硬件信息,这样才能实现dynamic provisioning。实现上可以参考延迟绑定,来一个延迟 provision。另外实现一个controller在pod调度阶段创建pv。
    4
    65
  • xfan
    思考题: 因为dynamic provision机制不知道pod需要在哪个node下运行,而提前就创建好了,,
    16
  • 张三
    Dynamic Provisioning 提供的是自动创建PV的机制,会根据PVC来创建PV并绑定,而我们的延迟绑定是需要在调度的时候综合考虑所有的调度条件来进行PVC和PV的绑定并调度Pod到PV所在的节点,二者有冲突
    6
  • 拉欧
    Dynamic Provisioning 是通过pvc 创建指定规格的pv, 而Local Persistent Volume 是先创建pv, 在创建pvc, 然后在pod创建的时候绑定pv和pvc;从语义上讲,Dynamic Provisioning 就不太可能支持延迟这种效果
    5
  • djfhchdh
    因为Dynamic Provisioning会自动创建PV,也就是说,在PVC创建后就根据StorageClass去自动创建PV并绑定了,而“延迟绑定”发生在调度Pod时,此时PVC已经创建了。因此二者是矛盾的~~
    4
  • 大星星
    手动删除pv的步骤中,1234步骤,为什么不是1342呢
    1
    3
  • 海。
    如果不是Local Persistent Volume, 而使用云块存储 aws ebs , “延迟绑定”和 Dynamic Provisioning 可以不冲突吧? 我看https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/examples/kubernetes/dynamic-provisioning/specs/storageclass.yaml 的volumeBindingMode也是 WaitForFirstConsumer
    3
    2
收起评论
显示
设置
留言
40
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部