十、应用存储和持久化数据卷 – 存储快照与拓扑调度

快照

• 锁定某一个磁盘的状态，被锁定的数据无法修改
• 如果需要修改被锁定的数据，就复制一份，再进行修改
• 未修改的数据，磁盘只保留一份，共正常使用和作为快照
• 快照是磁盘内容的一部分，占用磁盘空间，不能存到其他磁盘

存储快照产生背景

• 提高数据操作的容错性
• 支持快速 restore

存储快照用户接口-Snapshot

K8s 中通过 pvc 以及 pv 的设计体系来简化用户对存储的使用，而存储快照的设计其实是仿照 pvc & pv 体系的设计思想。当用户需要存储快照的功能时，可以通过 VolumeSnapshot 对象来声明，并指定相应的 VolumeSnapshotClass 对象，之后由集群中的相关组件动态生成存储快照以及存储快照对应的对象 VolumeSnapshotContent。

img

创建存储快照

image-20220225160551372

恢复存储快照

image-20220225160846302

• 根据 PVC 创建 PV 对象时，对应的存储数据是从 VolumeSnapshot 关联的 VolumeSnapshotContext restore 出来的

image-20220225160626413

拓扑

Topolopy-含义

拓扑是 K8s 集群中为管理的 nodes 划分的一种“位置”关系，意思为：可以通过在 node 的 labels 信息里面填写某一个 node 属于某一个拓扑。

常见的有三种：

1. region：地区
2. available zone：可用区
3. hostname：单机维度，是拓扑域为 node 范围

可自定义拓扑，例如可以用 rack，也就是机房中的机架这个纬度来做一个拓扑域

存储拓扑调度产生背景

K8s 中创建 pod 的流程和创建 PV 的流程，其实可以认为是并行进行的，这样的话，就没有办法来保证 pod 最终运行的 node 是能访问到 有位置限制的 PV 对应的存储（例如 I/O 性能高的本地存储），最终导致 pod 没法正常运行。可以通过 nodeAffinity 来指定哪些 node 可以访问这个 PV。

存储拓扑调度

在 K8s 中将 PV 和 PVC 的 binding 操作和动态创建 PV 的操作做了 delay，delay 到 pod 调度结果出来之后，再去做这两个操作。

限制静态 Provisioning PV 拓扑示例

创建 StorageClass

image-20220225172600107

• no-provisioner：告诉 K8s 它不会去动态创建 PV
• VolumeBindingMode：显示指定延迟绑定

创建 PV

image-20220225172618783

创建 PVC

image-20220225172630761

限制动态 Provisioning PV 拓扑示例

img

处理流程

kubernetes 对 Volume Snapshot/Restore 处理流程

img

K8s 中对存储的扩展功能都是推荐通过 csi out-of-tree 的方式来实现的。csi 实现存储扩展主要包含两部分：

• 第一部分是由 K8s 社区推动实现的 csi controller 部分，也就是这里的 csi-snapshottor controller 以及 csi-provisioner controller，这些主要是通用的 controller 部分;
• 另外一部分是由特定的云存储厂商用自身 OpenAPI 实现的不同的 csi-plugin 部分，也叫存储的 driver 部分。
• 两部分部件通过 unix domain socket 通信连接到一起

创建快照

1. 当用户提交 VolumeSnapshot 对象之后，会被 csi-snapshottor controller watch 到。之后它会通过 GPPC 调用到 csi-plugin
2. csi-plugin 通过 OpenAPI 来真正实现存储快照的动作
3. 等存储快照已经生成之后，会返回到 csi-snapshottor controller 中，csi-snapshottor controller 会将存储快照生成的相关信息放到 VolumeSnapshotContent 对象中并将用户提交的 VolumeSnapshot 做 bound。这个 bound 其实就有点类似 PV 和 PVC 的 bound 一样。

恢复快照

1. 通过声明一个新的 PVC 对象，并且指定他的 dataSource 为 Snapshot 对象
2. 当提交 PVC 的时候会被 csi-provisioner watch 到，之后会通过 GRPC 去创建存储。这里创建存储跟之前讲解的 csi-provisioner 有一个不太一样的地方，就是它里面还指定了 Snapshot 的 ID，当去云厂商创建存储时，需要多做一步操作，即将之前的快照数据恢复到新创建的存储中。
3. 之后流程返回到 csi-provisioner，它会将新创建的存储的相关信息写到一个新的 PV 对象中
4. 新的 PV 对象被 PV controller watch 到它会将用户提交的 PVC 与 PV 做一个 bound，之后 pod 就可以通过 PVC 来使用 Restore 出来的数据了。

kubernetes 对 Volume Topology-aware Scheduling 处理流程

img

其他

kubectl create和kubectl apply区别

• kubectl create命令，是先删除所有现有的东西，重新根据yaml文件生成新的。所以要求yaml文件中的配置必须是完整的
• kubectl create命令，用同一个yaml 文件执行替换replace命令，将会不成功，fail掉。
• kubectl apply命令，根据配置文件里面列出来的内容，升级现有的。所以yaml文件的内容可以只写需要升级的属性
• minikube 查看节点 minikube node list
• minikube 新增节点 minikube node add
• kubectl edit sc <scname>：编辑资源，不用修改编排文件，再去apply
  • sc：StorageClass