Kubernetes 1.31：防止按顺序删除时出现 PersistentVolume 泄漏

持久卷（简称 PV）与回收策略相关联。回收策略用于确定在删除绑定到 PV 的 PVC 时，存储后端需要采取的操作。当回收策略为 Delete 时，预期存储后端会释放为 PV 分配的存储资源。本质上，在删除 PV 时需要遵守回收策略。

在最近的 Kubernetes v1.31 版本中，一个 beta 功能允许您配置集群以按此方式运行，并遵守配置的回收策略。

在以前的 Kubernetes 版本中，回收是如何工作的？

持久卷声明（简称 PVC）是用户对存储的请求。如果找到了新创建的 PV 或匹配的 PV，则认为 PV 和 PVC 已绑定。PV 本身由存储后端分配的卷支持。

通常，如果要删除卷，则预期会删除已绑定 PV-PVC 对的 PVC。但是，在删除 PVC 之前删除 PV 没有任何限制。

首先，我将演示运行旧版本 Kubernetes 的集群的行为。

检索绑定到 PV 的 PVC

检索现有的 PVC example-vanilla-block-pvc

kubectl get pvc example-vanilla-block-pvc

以下输出显示了 PVC 及其绑定的 PV；PV 显示在 VOLUME 列下

NAME                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
example-vanilla-block-pvc   Bound    pvc-6791fdd4-5fad-438e-a7fb-16410363e3da   5Gi        RWO            example-vanilla-block-sc   19s

删除 PV

当我尝试删除绑定的 PV 时，kubectl 会话会阻止，并且 kubectl 工具不会将控制权返回给 shell；例如

kubectl delete pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da

persistentvolume "pvc-6791fdd4-5fad-438e-a7fb-16410363e3da" deleted
^C

检索 PV

kubectl get pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da

可以观察到 PV 处于 Terminating 状态

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS        CLAIM                               STORAGECLASS               REASON   AGE
pvc-6791fdd4-5fad-438e-a7fb-16410363e3da   5Gi        RWO            Delete           Terminating   default/example-vanilla-block-pvc   example-vanilla-block-sc            2m23s

删除 PVC

kubectl delete pvc example-vanilla-block-pvc

如果 PVC 成功删除，则会看到以下输出

persistentvolumeclaim "example-vanilla-block-pvc" deleted

集群中的 PV 对象也会被删除。尝试检索 PV 时会观察到不再找到 PV

kubectl get pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da

Error from server (NotFound): persistentvolumes "pvc-6791fdd4-5fad-438e-a7fb-16410363e3da" not found

尽管 PV 已被删除，但底层存储资源未被删除，需要手动删除。

总而言之，在某些情况下，与 PersistentVolume 关联的回收策略当前会被忽略。对于 Bound PV-PVC 对，PV-PVC 删除的顺序决定了是否遵守 PV 回收策略。如果先删除 PVC，则会遵守回收策略；但是，如果在删除 PVC 之前删除 PV，则不会执行回收策略。由于此行为，外部基础设施中相关的存储资产不会被删除。

Kubernetes v1.31 的 PV 回收策略

新行为确保当用户尝试手动删除 PV 时，底层存储对象将从后端删除。

如何启用新行为？

要利用新行为，您必须将集群升级到 Kubernetes 的 v1.31 版本，并运行 CSI external-provisioner 版本 5.0.1 或更高版本。

它是如何工作的？

对于 CSI 卷，新行为是通过在新 PV 和现有 PV 上添加 finalizer external-provisioner.volume.kubernetes.io/finalizer 实现的。仅在从后端删除存储后才会删除 finalizer。 `

带有 finalizer 的 PV 示例，请注意 finalizers 列表中的新 finalizer

kubectl get pv pvc-a7b7e3ba-f837-45ba-b243-dec7d8aaed53 -o yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: csi.vsphere.vmware.com
  creationTimestamp: "2021-11-17T19:28:56Z"
  finalizers:
  - kubernetes.io/pv-protection
  - external-provisioner.volume.kubernetes.io/finalizer
  name: pvc-a7b7e3ba-f837-45ba-b243-dec7d8aaed53
  resourceVersion: "194711"
  uid: 087f14f2-4157-4e95-8a70-8294b039d30e
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 1Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: example-vanilla-block-pvc
    namespace: default
    resourceVersion: "194677"
    uid: a7b7e3ba-f837-45ba-b243-dec7d8aaed53
  csi:
    driver: csi.vsphere.vmware.com
    fsType: ext4
    volumeAttributes:
      storage.kubernetes.io/csiProvisionerIdentity: 1637110610497-8081-csi.vsphere.vmware.com
      type: vSphere CNS Block Volume
    volumeHandle: 2dacf297-803f-4ccc-afc7-3d3c3f02051e
  persistentVolumeReclaimPolicy: Delete
  storageClassName: example-vanilla-block-sc
  volumeMode: Filesystem
status:
  phase: Bound

finalizer 阻止从此集群中删除此 PersistentVolume。如前所述，只有在从存储后端成功删除后，才会从 PV 对象中删除 finalizer。要了解有关 finalizer 的更多信息，请参阅使用 Finalizers 控制删除。

类似地，finalizer kubernetes.io/pv-controller 被添加到动态配置的 in-tree 插件卷中。

CSI 迁移卷怎么样？

该修复程序也适用于 CSI 迁移卷。

一些注意事项

该修复程序不适用于静态配置的 in-tree 插件卷。

参考

• KEP-2644
• 卷泄漏问题

如何参与？

Kubernetes Slack 频道 SIG Storage 通信渠道 是联系 SIG Storage 和迁移工作组的好方法。

特别感谢以下人员的深刻见解、认真考虑和宝贵贡献

• Fan Baofa (carlory)
• Jan Šafránek (jsafrane)
• Xing Yang (xing-yang)
• Matthew Wong (wongma7)

如果您有兴趣参与 CSI 或 Kubernetes 存储系统的任何部分的设计和开发，请加入 Kubernetes 存储特别兴趣小组 (SIG)。我们正在快速发展，并且始终欢迎新的贡献者。

• ←上一篇
下一篇→