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

基本知识

存储快照产生背景

1. 如何保证重要数据在误操作之后可以快速回复，以提高数据操作容错率？
2. 如何能够快速进行复制，迁移重要数据？如进行环境复制与数据开发等。

K8s CSI Snapshotter controller正是为了解决这些需求而设计的。

存储快照用户接口-snapshot

存储快照用户接口-restore

PersistentVolumeClaim扩展字段.spec.dataSource可以指定为VolumeSnapshot对象，从而根据PVC对象生成的新PV对象，对应的存储数据是从VolumeSnapshot关联的VolumeSnapshotContent restore出来的

 此处拓扑（Topology）的含义

这里讨论的拓扑是针对k8s集群中管理的Nodes按照一定规则划分的“位置”关系，并通过在Node的Labels中设置以标识自己属于某一个具体的拓扑位置，如Node Labels包括：

• failure-domine.beta.kubernetes.io/region=>us-central1 #拓扑域为Region范围
• failure-domain.beta.kubernetes.io/zone=>us-central1-a # 拓扑域为Zone范围
• kubernetes.io/hostname=>nodename # 拓扑域为node范围

也可以自定义一个字符串key来表示一个具体的拓扑域，key所能设置的不同的value代表该拓扑域下不同的拓扑位置，如rack可以用来将属于同一个机架（rack）上的服务器（nodes）划分为一组（一个具体的拓扑rack=>rack1），以区别另一个rack上的一组机器的“位置”（rack=>rack2）。

存储拓扑调度的产生背景

k8s中通过PVC&PV体系将存储与计算分离，即使用不同的Controllers管理存储资源和计算资源。但如果创建的PV有访问“位置”（.spec.nodeAffinity）的限制，也就是只有在特定的一些Nodes上才能访问PV。原有的创建Pod的与创建PV的流程的分离，就无法保证新创建的Pod被调度到可以访问PV的Nodes上，最终导致Pod无法正常运行起来。如：

场景1：Local PV只能在指定的Node上被Pod使用

场景2：单Region多Zone k8s集群，阿里云云盘当前只能被同一个Zone的Node上的Pod访问

存储拓扑调度

1. 本质问题
   1. PV在Binding或者Dynamic Provisioning时，并不知道使用它的Pod会被调度到哪些Node上？但PV本身的访问对Node的“位置”（拓扑）有限制
2. 流程改进
   1. Binding/Dynamic Provisioning PV的操作Delay到Pod调度结果确定之后做，好处：
      1. 对于pre-provisioned的含有Node Affinity的PV对象，可以在Pod运行的Node确认之后，根据Node找到合适的PV对象，然后与Pod中使用的PVC Binding，保证Pod运行的Node满足PV对访问“位置”（拓扑）的要求。
      2. 对于Dynamic Provisioning PV场景，在Pod运行的Node确认之后，可以结合Node的“位置”（拓扑）信息创建可被该Node访问的PV对象
3. K8s相关组件改进
   1. PV Controller：支持延迟Binding操作
   2. Dynamic PV Provisioner：动态创建PV时要结合Pod待运行的Node的“位置”（拓扑）信息
   3. Sheduler：选择Node时要考虑 Pod 的PVC Binding需求，也就是要结合pre-provisioned的PV的Node Affinity以及dynamic provisioning时PVC指定StorageClass.AllowedTopologies的限制

用例解读

Volume Snapshot/Restore示例

Local PV示例

限制Dynamic Provisioning PV拓扑示例

处理流程

K8s对Volume Snapshot/Restore处理流程

K8s对Volume Topology-aware Scheduling处理流程

主流程说明：

1. 首先PV Controller对需要Delay Binding（通过StorageClass设置）的PVC暂不做任何处理
2. Scheduler根据Pod PVCs过滤per Node流程：
   1. 找到一个Pod所有Bound的PVCs以及需要Delay Binding的PVCs
   2. Bound的PVCs要check bound的PV NodeAffinity与当前Node的拓扑是否匹配，不匹配就skip this Node
   3. Delay Binding的PVCs，先check存量的PVs能满足PVC的列表，并将他们的NodeAffinity与当前Node拓扑做匹配，都不匹配进一步check PVCs对应的StorageClass.AllowedTopologies是否与Node的拓扑匹配，不匹配就skip this Node
3. 更新经过预选（Predicates）和优选（Priorities）选中Node的Pod在sheduler中的PVC&PV cache，为step（4）做准备
4. 触发相关组件对pod使用的UnBound PVCs的Binding或Dynamic Provisioning流程真正执行