CSINode介绍

CSI驱动程序生成特定于节点的信息。不再将其存储在Kubernetes节点API对象中，而是创建了一个新的CSINode对象。
MaxCSIVolumeCountPred
定义决定应附加多少CSI卷的谓词。

它具有以下目的：

将Kubernetes节点名称映射到CSI节点名称，CSI GetNodeInfo调用返回存储系统引用节点所使用的名称。 Kubernetes在将来的ControllerPublishVolume调用中必须使用此名称。 因此，在注册新的CSI驱动程序时，Kubernetes将存储系统节点ID存储在CSINode对象中，以备将来参考。

驱动程序可用性

kubelet与kube-controller-manager和kubernetes调度程序进行通信的一种方法，无论驱动程序是否在节点上可用（注册）。

卷拓扑

CSI GetNodeInfo调用返回一组标识该节点拓扑的键/值标签。 Kubernetes使用此信息进行拓扑感知的预配置（有关更多详细信息，请参见PVC卷绑定模式）。 它将键/值存储为Kubernetes节点对象上的标签。 为了调出哪些Node标签密钥属于特定的CSI驱动程序，kubelet将密钥存储在CSINode对象中以备将来参考。
CSINode对象具有哪些字段？
以下是CSINode对象的示例：
apiVersion: storage.k8s.io/v1
kind: CSINode
metadata:
name: node1
spec:
drivers:
- name: mycsidriver.example.com
nodeID: storageNodeID1
topologyKeys: [‘mycsidriver.example.com/regions’, “mycsidriver.example.com/zones”]
字段的含义是：
drivers：节点上运行的CSI驱动程序及其属性的列表。
name：该对象引用的CSI驱动程序。
nodeID：由驱动程序确定的节点分配的标识符。
topologyKeys：驱动程序支持的分配给节点的拓扑密钥的列表。
是什么创建了CSINode对象？
CSI驱动程序不需要直接创建CSINode对象。 当CSI驱动程序通过kubelet插件注册机制注册时，Kubelet将管理对象。 node-driver-registrar sidecar容器有助于此注册。

CSINode：对调度逻辑的影响。
PreFilter：实现。
固定节点configmaps的格式补充。
缓存逻辑梳理。
同步输出用例。
资源预留算法补充，用例。

QueueSort

扩展用于对 Pod 的待调度队列进行排序，以决定先调度哪个 Pod，QueueSort 扩展本质上只需要实现一个方法 Less(Pod1, Pod2) 用于比较两个 Pod 谁更优先获得调度即可，同一时间点只能有一个 QueueSort 插件生效。

Pre-filter

扩展用于对 Pod 的信息进行预处理，或者检查一些集群或 Pod 必须满足的前提条件（比如只调度无nodeName的pod、有指定label的pod），如果 pre-filter 返回了 error，则调度过程终止。此扩展点不可操作node。

Filter

扩展用于排除那些不能运行该 Pod 的节点，对于每一个节点，调度器将按顺序执行 filter 扩展；如果任何一个 filter 将节点标记为不可选，则余下的 filter 扩展将不会被执行。调度器可以同时对多个节点执行 filter 扩展。

Post-filter

是一个通知类型的扩展点，调用该扩展的参数是 filter 阶段结束后被筛选为可选节点的节点列表，可以在扩展中使用这些信息更新内部状态，或者产生日志或 metrics 信息。

Scoring

扩展用于为所有可选节点进行打分，调度器将针对每一个节点调用 Soring 扩展，评分结果是一个范围内的整数。在 normalize scoring 阶段，调度器将会把每个 scoring 扩展对具体某个节点的评分结果和该扩展的权重合并起来，作为最终评分结果。

Normalize scoring

扩展在调度器对节点进行最终排序之前修改每个节点的评分结果，注册到该扩展点的扩展在被调用时，将获得同一个插件中的 scoring 扩展的评分结果作为参数，调度框架每执行一次调度，都将调用所有插件中的一个 normalize scoring 扩展一次。

Reserve

是一个通知性质的扩展点，有状态的插件可以使用该扩展点来获得节点上为 Pod 预留的资源，该事件发生在调度器将 Pod 绑定到节点之前，目的是避免调度器在等待 Pod 与节点绑定的过程中调度新的 Pod 到节点上时，发生实际使用资源超出可用资源的情况。（因为绑定 Pod 到节点上是异步发生的）。这是调度过程的最后一个步骤，Pod 进入 reserved 状态以后，要么在绑定失败时触发 Unreserve 扩展，要么在绑定成功时，由 Post-bind 扩展结束绑定过程。
磁盘调度算法，需要在pvc更新时、pod调度时、调度器启动时维护缓存，到这一步，只剩一个节点，让失败会降低调度效率。在这里维护pvc缓存，在AddPod和RemovePod时也需要维护，所以不如直接加到AddPod、RemovePod处维护。
资源预留：针对节点预留部分cpu、内存，用于调度备份恢复的pod；

Permit

扩展用于阻止或者延迟 Pod 与节点的绑定。Permit 扩展可以做下面三件事中的一项：
approve（批准）：当所有的 permit 扩展都 approve 了 Pod 与节点的绑定，调度器将继续执行绑定过程
deny（拒绝）：如果任何一个 permit 扩展 deny 了 Pod 与节点的绑定，Pod 将被放回到待调度队列，此时将触发 Unreserve 扩展
wait（等待）：如果一个 permit 扩展返回了 wait，则 Pod 将保持在 permit 阶段，直到被其他扩展 approve，如果超时事件发生，wait 状态变成 deny，Pod 将被放回到待调度队列，此时将触发 Unreserve 扩展

Pre-bind

扩展用于在 Pod 绑定之前执行某些逻辑。例如，pre-bind 扩展可以将一个基于网络的数据卷挂载到节点上，以便 Pod 可以使用。如果任何一个 pre-bind 扩展返回错误，Pod 将被放回到待调度队列，此时将触发 Unreserve 扩展。

Bind

扩展用于将 Pod 绑定到节点上：只有所有的 pre-bind 扩展都成功执行了，bind 扩展才会执行调度框架按照 bind 扩展注册的顺序逐个调用 bind 扩展具体某个 bind 扩展可以选择处理或者不处理该 Pod，如果某个 bind 扩展处理了该 Pod 与节点的绑定，余下的 bind 扩展将被忽略。

Post-bind

是一个通知性质的扩展：Post-bind 扩展在 Pod 成功绑定到节点上之后被动调；Post-bind 扩展是绑定过程的最后一个步骤，可以用来执行资源清理的动作

Unreserve

是一个通知性质的扩展，如果为 Pod 预留了资源，Pod 又在被绑定过程中被拒绝绑定，则 unreserve 扩展将被调用。Unreserve 扩展应该释放已经为 Pod 预留的节点上的计算资源。在一个插件中，reserve 扩展和 unreserve 扩展应该成对出现。