1.21之前都是pvc一旦创建立马绑定pv 之后通过参数进行了解耦

从Kubernetes v1.21开始，PVC支持volumeBindingMode字段，它可以设置为Immediate（立即绑定）或WaitForFirstConsumer（等待第一个消费者）。 Immediate模式下，Kubernetes会立即尝试为PVC绑定PV。 WaitForFirstConsumer模式下，Kubernetes会等待直到一个Pod引用了该PVC后再为其绑定PV。之前都是pvc一创建好就绑定pv吗

 

在Kubernetes v1.21之前，PersistentVolumeClaim（PVC）一旦创建，就会立即进入绑定流程，试图找到一个与之匹配的PersistentVolume（PV）。这个过程是同步的，也就是说，PVC的创建和PV的绑定是几乎同时发生的。这种模式就是类似于你提到的“Immediate（立即绑定）”模式。

从Kubernetes v1.21开始，引入了volumeBindingMode字段，为PVC提供了更灵活的绑定策略，包括：

1. Immediate：

   • 这是默认模式。在Immediate模式下，Kubernetes会在PVC创建时立即开始寻找与之匹配的PV，并尝试进行绑定。这个过程与之前的版本相同，PVC一旦创建，绑定操作就会立即执行。

2. WaitForFirstConsumer：

   • 在WaitForFirstConsumer模式下，Kubernetes会延迟PVC的绑定过程，直到有一个Pod引用了该PVC。这种模式适用于使用拓扑感知的存储，例如，你可能希望PV绑定到与使用该PVC的Pod相同的节点或区域。通过WaitForFirstConsumer模式，Kubernetes可以考虑到Pod的调度约束，从而优化PV的分配。

使用WaitForFirstConsumer模式的PVC示例配置如下：

 

从Kubernetes v1.21版本开始，Docker作为容器运行时的支持被正式标记为已弃用，并在v1.24版本中被完全移除。这意味着，从v1.24开始，Kubernetes将不再支持使用Docker作为容器运行时，用户需要迁移到其他符合Container Runtime Interface (CRI)的运行时，例如containerd或CRI-O。

Docker作为Kubernetes的容器运行时被弃用的原因主要是因为Docker没有完全实现CRI，导致Kubernetes需要通过一个名为dockershim的组件来适配Docker。随着时间的推移，维护dockershim的成本变得越来越高，而且随着容器技术的发展，社区希望能够支持更多的容器运行时，这些运行时可以直接通过CRI与Kubernetes集成。