开发者学堂课程【Kubernetes 入门：应用存储和持久化数据卷：存储快照与拓扑调查（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/51/detail/1016
应用存储和持久化数据卷：存储快照与拓扑调查（一）
内容介绍：
一、基本知识
二、用例解读
三、操作演示
四、处理流程
一、基本知识
1、存储快照产生背景
l 如何保证重要数据在误操作之后可以快速恢复，以提高数据操作容错率?
l 如何能够快速进行复制，迁移重要数据的动作?如进行环境复制与数据开发等。
Kubernetes CSI Snapshotter controller 正是为了解决这些需求而设计的
2、存储快照用户接口- restore
PersistentVolumeClaim 扩展字段.spec.dataSource 可以指定为 VolumeSnapshot 对象，从而根据 PVC 对象生成的新PV对象，对应的存储数据是从 VolumeSnapshot 关联的 VolumeSnapshotContent restore 出来的
3、本讲讨论 Topology（拓扑）的含义
l 这里讨论的拓扑是指对 Kubernetes 集群中管理的 Nodes 的按照一定的规则划分的”位置”关系，并通过在 Node 的 Labels 中设置以标识自己属于某一个具体的拓扑位置，如 Node Labels 包括:. failure-domain.beta.kubernetes.iolregion => us-central1#拓扑域为 Region 范围
l failure-domain.beta.kubernetes.io/zone => us-central1-a#拓扑域为 Zone 范围
l kubernetes.io/hostname => nodename # 拓扑域为 node 范围
当然也可以自定义一个字符串key 来表示一个具体的拓扑域，key 所能设置的不同的 value 代表该拓扑域下不同的拓扑位置，如rack 可以用来将属于同一个机架（rack )上的服务器（ nodes )划分为一组（如一个具体的拓扑 rack => rack1 ) ,以区别另一个 rack 上的一组机器的“位置”(如 rack => rack2)。
4、存储拓扑调度产生背景
Kubernetes 中通过 PVC&PV 体系将存储与计算分离，即使用不同的 Controllers 管理存储资源和计算资源。但如果创建的 PV 有访问“位置”(.spec.nodeAffinity)的限制,也就是只有在特定的一些 Nodes 上才能访问 PV。原有的创建 Pod 的与创建PV的流程的分离，就无法保证新创建的 Pod 被调度到可以访问 PV 的 Nodes 上，最终导致 Pod 无法正常运行起来。如
场景1.Local PV 只能在指定的 Node 上被 Pod 使用
5、存储拓扑调度产生背景
场景2:单 Region 多 Zone K8s 集群，阿里云云盘当前只能被同一个 Zone 的 Node 上的 Pod 访问
6、存储拓扑调度
1.本质问题
PV 在 Binding 或者 Dynamic Provisioning 时，并不知道使用它的 Pod 被会调度到哪些 Node 上?但 PV 本身的访问对 Node 的“位置”(拓扑)有限制。
⒉流程改进
Binding/Dynamic Provisioning PV 的操作 Delay 到 Pod 调度结果确定之后做，好处:
对于 pre-provisioned 的含有 Node Affinity 的 PV 对象，可以在 Pod 运行的 Node 确认之后，根据 Node 找到合适的 PV 对象，然后与 Pod 中使用的 PVC Binding，保证 Pod 运行的 Node 满足 PV 对访问”位置”(拓扑)的要求。
·对于 dynamic provisioning PV 场景，在 Pod 运行的 Node 确认之后，可以结合Node 的”位置”(拓扑)信息
创建可被该 Node 访问的PV对象
3. Kubernetes 相关组件改进
. pV Controller:支持延迟 Binding 操作
. Dynamic PV Provisioner:动态创建 PV 时要结合 Pod 待运行的 Node 的”位置”
（拓扑）信息
. Scheduler:选择 Node 时要考虑 Pod 的 PVC Binding 需求，也就是要结合 pre-provisioned 的 PV 的 NodeAffinity 以及 dynamic provisioning 时 PVC 指定StorageClass.AllowedTopologies 的限制
二、用例解读
1、volume Snapshot/Restore 示例
#创建 VolumeSnapshotClass 对象
apiVersion: snapshot.storage.k8s.io/lv1alpha1
kind: VolumeSnapshotClass
metadata:
name: disk-snapshotclass
snapshotter: diskplugin.csi.alibabacloud.com #指定 VolumeSnapshot 时使用的 Volume Plugin
# 创建 VolumeSnapshot 对象
apiVersion: snapshot.storage.k8s.iolv1alpha1
kind: VolumeSnapshot
metadata:
name: disk-snapshotspec:
snapshotClassName: disk-snapshotclass
source:
name: disk-pvc #Snapshot 的数据源
kind: PersistentVolumeClaim
#从snapshot 中恢复数据到新生成的 PV 对象中
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: restore-pvc
spec:
dataSource:
name: disk-snapshot
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
storageClassName: csi-disk
2、Local PV 示例
#创建一个 no-provisioner StorageClass 对象，目的是告诉 PV
# Controller 遇到.spec.storageClassName 为 local-storage 的
# PVC 暂不做 Binding 操作
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer # deley binding
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: local-pvc
spec:
storageClassName: local-storage
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 60Gi
#创建 Local PV 对象
apiVersion: v1
kind: PersistentVolume
metadata:
name: local-pv
spec:
capacity:
storage: 60Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: local-storage
local:
path: /share
nodAffinity:#限制该 PV只能在 node1上被使用 required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname#拓扑域限制:单 node 可访问
operator: In
values:
- node1
