图源：Mr. Bean’s Holiday (2007) – Bean 经验万难，最终发现他的假期目的地
云存储的学习艰难，难于 K8s CSI 框架复杂性，再加上如 ceph 分布式存储的复杂性。本文试图用互动式图例，让读者串联起两个畛域本身与畛域间的知识点，从而对整个流程有一个总体的感知；防止自觉深刻一个一个零散的知识点孤岛而迷路。
注：因为是在 2023 年五一假期写的，本文的口味会轻松点。也可能会跑题和闲话，毕竟这只是个集体博客，不是个“极客工夫”上的免费文章，不能要求太高了 :)
引
最近因为生存须要，学习了之前始终写在学习清单，而总想回避的 k8s 存储架构。为备忘，写下这个笔记。如果能帮忙到更多的人去学习这个技术难点，当然更好了。
K8s 几大难点
学习过 k8s 的人，我想都感觉有点记忆过载，设计简单，材料多而散，说形象的太多说实现的少。用麦兜的一句经典表白是：
教大家一味很別緻的小菜 —- 包雞紙包雞紙包雞，首先將紙包雞小心臟撩開，大家就會有一張包雞紙及一塊雞，拿著雞包紙像我這樣子包住那塊雞，然後再像這種子用包雞紙包包住它，那一味包雞紙包雞包紙包雞就实现了！是不是很簡單單啊？還真有一塊雞吃呢！
我感觉有几个难点，同时也是重点：
- 对象（冀望状态）、事实状态、监听、事件、和谐
- 网络：之前写过的 calico 文章：《一个 IP 包的旅行 —— K8s 网络之 Calico 浅度解构》
- CSI：本文
- CRI：未深刻
多年信息技术学习，积攒的学习办法不多，但有一点我坚信不移：
“Bad programmers worry about the
code. Good programmers worry aboutdata structuresand theirrelationships.”― Linus Torvalds
在所谓的微服务架构下，情理也是相似的：
- 学习外围数据模型与分割，我称之类动态模型
- 学习服务之间的状态变动与数据流转的关系，我称之为动静行为
如何开始
如何学习形象
学习形象的常识（如 k8s CSI）时，最好的办法是不要间接学习形象的常识。如何了解？形象是设计者在常识畛域充沛积攒和提炼后的输入，形象自身是精简且易于流传的。但和过分提炼的食物一样，也通常是难于消化的。
人脑天然上是比拟适宜学习具体事物，而后提炼出形象。且不是间接学习形象。如果你学习 k8s CSI，那么找个实例来捉弄，是最快的学习过程。
上面，咱们用自底向上 + 用实例代替形象的办法，学习一下 k8s CSI 与 Ceph。
本文的浏览办法
互动图片
📢 本文提供的技术相干图片，均可点击“用 Draw.io 关上 ”后，进入互动图片状态。图中很多元素（带下划线）提供链接到相干材料文档。能够做穿插参考，是进一步深刻的入口，也是图的可信性取证。
本文的大部分内容是放在图中了。看图比文字更重要。
读者对象
假如你曾经大略读过 Ceph 的文档，也大略晓得 CSI 和 Rook 是什么。
根本的依赖关系
钻研一个大型的开源我的项目设计，终点肯定包含钻研其组件的依赖关系。明确了依赖关系，就能够在钻研流程细节时晓得：
- who knows who
- who knows what
- who doesn’t know who
- who doesn’t know what
这点对保障钻研方向正确由为重要。因为优良的开源设计，肯定有业余的人去保障这一点设计准则的，不然随着我的项目的倒退，很容易就产生依赖凌乱，循环依赖的状况。
Rook/CSI spec/CSI sidecar/ceph/ceph-CSI-driver(plugin) 的关系
如上图排版有问题，请点这里用 Draw.io 关上
Ceph Cluster
下图讲述了，rook + ceph + rbd 下，各个 Ceph Cluster 组件的外部配置与组件间的分割。
Ceph Components
如上图排版有问题，请点这里用 Draw.io 关上
CSI
下图讲述 k8s CSI 存储相干 Object 的关系，以及 Ceph 之间的关系。
CSI k8s Objects and Ceph Mapping
如上图排版有问题，请点这里用 Draw.io 关上
Ceph-CSI Driver
下图阐明了 CSI 在几个存储状态下的流程和关系：
- PVC/PV/rbd Volume 的创立 (provision) 过程。
- 提交 PV 挂载要求的过程
- worker node 理论挂载 rbd volume 的过程
CSI and Ceph processes
如上图排版有问题，请点这里用 Draw.io 关上
小结
高高举起，微微放下，始终是我的写博格调。除非必要，我简直不会去在文章中说一些比拟部分细小的知识点。本文也不例外。文字内容少，不代表我没认真去画下面的图。相同，下面的图均是在大量材料和环境实地斟酌和经验多翻订正后实现的。
我不想在文章中间接说太长篇的细节：
- 一个是我置信读者们如果真有能源去学货色，这些图能够帮忙你去零碎学习和串联知识面，而不至于迷路。
- 我不想反复官网文档的知识点，只提供到官网文档的援用。
- 心愿是授人以渔，而非鱼，尽管可能我能力无限，未能做到。
谢谢浏览！
闲话
从业快 20 年，不敢说阅人有数，也总算经验过一些货色和局面。程序员这个职业，其实在我国工夫大略就是 30 年。10 前，我看到更多的程序员是喜爱 coding 这件事，当初，我看到更多的是职业程序员。
不要误会，这里不存在褒贬，我尊敬所有敬业的人，无论他是心田喜爱做这事，还是因为各种起因去做这件事。
但，请为前者（心田喜爱做这事）的人留一条在这个行业生存的生路，因为二者的共存是这个行业强壮倒退的保障。但前者在咱们丛林法令环境下的生存能力通常是软弱的。
注：Bad 与 Good 的定义只是对于底层技术的创新能力，而非事实上的执行力
AI / ChatGPT
记得看电影和一些老科幻小说时，外面总有一些执著的老一辈武林高手的角色，蔑视那些用枪的人：“用这些货色，算什么文治”。但可悲的事实是，这些“老一辈武林高手”最初就是 killed 在枪下。我最近的感觉是，本人越来越像这些“执著的老一辈武林人（还不算是高手）”。而这个先进科技，当然就是 AI / ChatGPT 了。
“不可控”人造的抗拒
老程序员，或多或少，对“不可控”有人造的抗拒。因为大部分时候，程序想做到的就是思考所有可能，而后用程序逻辑去管制所有可能。尽管这个指标永远只能靠近而不可能达到。
只有 how，还是要 why
搜索引擎到来时，有人说搜寻只是解决了问题，而没有让人晓得为什么。但 Chat AI 下这个问题仿佛更加重大。因为 Chat 的回复比搜寻更加精准和智能定制。就像说：“我通知你答案，你照着抄就是了”。当然，你能够进一步问他 why。但有几个人真那么有好奇心呢？
回到下面说的“老一辈武林高手”最初就是 killed 在枪下，这个故事。我感觉本人迟早也是这个终局，除了小数几个哲学家，没几个人能逃过时代的车轮。只是，每个人都能够有本人的抉择，能够抉择感性和事实；也能够抉择执著和书呆子。这不是个对错的问题，只有晓得本人为何作出抉择，抉择的后果是什么，就能够了。
图源：Mr. Bean’s Holiday (2007) – 终局