k8s的PVC为何需要延迟绑定(WaitForFirstConsumer)

背景

有一个pod, 使用的pvc叫pvc-1， 我们希望它只运行在node-2上，在当前的集群中存在两台主机符合pod的pvc的要求, 假如node-1上是pv-1， node-2上是pv-2，这两个完全一样.
这时如果创建pod, pv控制器看到pv-1与pvc-1是匹配的，因此将它们绑定在一起, 如果没有其它限制条件, 在调度阶段pod将会被调度到node-1上, 这显然与我们的期望不同，我们是希望它调度到node-2上，pv与pvc的绑定关系是发生在调度之前的,就会造成pv与pvc的绑定成功, 但是pod的调度却不能成功的局面

为什么需要延迟绑定

当没有延迟绑定的时候，pvc会首先绑定pv再进行调度，这也说明了CSI先于CRI。
所以需要一种机制来将这种绑定延迟到调度阶段,这就是WaitForFirstConsumer的作用

延迟绑定的原理

总结起来就是将CSI延迟到调度之后进行

WaitForFirstConsumer其实就是告诉volume控制器，虽然找到了适合的pv， 但请不要现在就执行绑定操作,而要等到第一个声明使用了该pvc的pod出现在调度器之后，调度器综合考虑所有的调度规则后, 最终决定跟哪个pv进行绑定

通过这个延迟绑定机制，原本实时发生的 PVC 和 PV 的绑定过程，就被延迟到了 Pod 第一次调度的时候在调度器中进行，从而保证了这个绑定结果不会影响 Pod 的正常调度

storgeageClass yaml配置

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

对应的就是最后那个参数：

• 即刻绑定
• 首次使用时绑定
  

这篇好文章是转载于：学新通技术网