文章目录
- 背景
- 为什么需要延迟绑定
- 延迟绑定的原理
- storgeageClass yaml配置
背景
有一个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
对应的就是最后那个参数:
- 即刻绑定
- 首次使用时绑定