本文发表已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不正确。

Kubernetes v1.26：追溯默认 StorageClass

作者：Roman Bednář (Red Hat) |

Kubernetes v1.25 版本引入了一个 alpha 功能，用于更改将默认 StorageClass 分配给 PersistentVolumeClaim (PVC) 的方式。启用该功能后，您不再需要先创建默认 StorageClass，然后再创建 PVC 来分配该类。此外，任何未分配 StorageClass 的 PVC 都可以在以后更新。此功能已在 Kubernetes v1.26 中升级为 beta 版本。

您可以在 Kubernetes 文档中阅读有关追溯默认 StorageClass 分配的更多详细信息，了解如何使用它，或者您可以继续阅读以了解 Kubernetes 项目为何进行此更改。

为什么需要改进 StorageClass 分配

用户可能已经熟悉类似的功能，该功能在创建时将默认 StorageClass 分配给新的 PVC。这目前由准入控制器处理。

但是，如果在创建 PVC 时没有定义默认的 StorageClass 怎么办？用户最终会得到一个永远不会被分配类的 PVC。因此，不会配置任何存储，并且 PVC 会在此时有点“卡住”。通常，两种主要情况可能导致 PVC “卡住”，并在以后引起问题。让我们仔细看看它们中的每一个。

更改默认 StorageClass

启用 alpha 功能后，当管理员想要更改默认 StorageClass 时，他们有两种选择

  1. 在删除与 PVC 关联的旧默认 StorageClass 之前，创建一个新的 StorageClass 作为默认 StorageClass。这会导致在短时间内存在两个默认值。此时，如果用户要创建 storageClassName 设置为 null（表示默认 StorageClass）的 PersistentVolumeClaim，则将选择最新的默认 StorageClass 并将其分配给此 PVC。

  2. 先删除旧的默认值，然后创建一个新的默认 StorageClass。这将导致在短时间内没有默认值。随后，如果用户要创建 storageClassName 设置为 null（表示默认 StorageClass）的 PersistentVolumeClaim，则 PVC 将永远处于 Pending 状态。用户必须通过删除 PVC 并在默认 StorageClass 可用后重新创建它来解决此问题。

集群安装期间的资源排序

如果集群安装工具需要创建需要存储的资源，例如镜像注册表，则很难正确排序。这是因为任何需要存储的 Pod 都将依赖于默认 StorageClass 的存在，如果未定义该类，则创建将失败。

发生了什么变化

我们更改了 PersistentVolume (PV) 控制器，将默认 StorageClass 分配给任何 storageClassName 设置为 null 的未绑定 PersistentVolumeClaim。我们还修改了 API 服务器中的 PersistentVolumeClaim 准入，以允许将值从未设置的值更改为实际的 StorageClass 名称。

Null storageClassName 与 storageClassName: "" - 有区别吗？

在此功能引入之前，这些值在行为上是相等的。任何 storageClassName 设置为 null 或 "" 的 PersistentVolumeClaim 都将绑定到 storageClassName 也设置为 null 或 "" 的现有 PersistentVolume 资源。

启用此新功能后，我们希望保持此行为，但也能够更新 StorageClass 名称。考虑到这些限制，该功能更改了 null 的语义。如果存在默认 StorageClass，则 null 将转换为“给我一个默认值”，而 "" 将表示“给我一个也具有 "" StorageClass 名称的 PersistentVolume”。在没有 StorageClass 的情况下，行为将保持不变。

总结以上内容，我们更改了 null 的语义，使其行为取决于默认 StorageClass 定义的存在或不存在。

下表显示了所有这些情况，以更好地描述 PVC 何时绑定以及何时更新其 StorageClass。

使用追溯默认 StorageClass 的 PVC 绑定行为
PVCstorageClassName = ""PVCstorageClassName= null
没有默认类PVstorageClassName = ""绑定绑定
没有的 PVstorageClassName绑定绑定
有默认类PVstorageClassName = ""绑定类更新
没有的 PVstorageClassName绑定类更新

如何使用它

如果您想在 alpha 测试该功能，则需要在 kube-controller-manager 和 kube-apiserver 中启用相关的功能门。使用 --feature-gates 命令行参数

--feature-gates="...,RetroactiveDefaultStorageClass=true"

试用

如果您想查看该功能的实际运行情况并验证它在您的集群中是否正常工作，您可以尝试以下操作

  1. 定义基本的 PersistentVolumeClaim

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

  2. 在没有默认 StorageClass 时创建 PersistentVolumeClaim。PVC 将不会配置或绑定（除非已经存在现有且合适的 PV），并且将保持 Pending 状态。

    kubectl get pvc

    输出类似于以下内容

    NAME      STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-1     Pending

  3. 配置一个 StorageClass 作为默认值。

    kubectl patch sc -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

    输出类似于以下内容

    storageclass.storage.k8s.io/my-storageclass patched

  4. 验证 PersistentVolumeClaims 现在是否已正确配置，并使用新的默认 StorageClass 追溯更新。

    kubectl get pvc

    输出类似于以下内容

    NAME      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
pvc-1     Bound    pvc-06a964ca-f997-4780-8627-b5c3bf5a87d8   1Gi        RWO            my-storageclass   87m

新指标

为了帮助您查看该功能是否按预期工作，我们还引入了一个新的 retroactive_storageclass_total 指标，用于显示 PV 控制器尝试更新 PersistentVolumeClaim 的次数，以及 retroactive_storageclass_errors_total 指标，用于显示这些尝试失败的次数。

参与其中

我们始终欢迎新的贡献者，因此如果您想参与其中，您可以加入我们的Kubernetes 存储特别兴趣小组 (SIG)。

如果您想分享反馈，您可以在我们的公共 Slack 频道上进行分享。

特别感谢所有提供出色评论、分享宝贵见解并帮助实现此功能的贡献者（按字母顺序排列）