中文内容

已翻译official company source英文原文2026-01-08

Kubernetes v1.35：可变 PersistentVolume 节点亲和性（alpha）

By Weiwen Hu (Alibaba Cloud), YuanHui Qiu (Alibaba Cloud) | Thursday, January 08, 2026

PersistentVolume 节点亲和性 API 最早可追溯至 Kubernetes v1.10。它被广泛用于表示卷可能无法被集群中的所有节点同等访问。该字段此前为不可变状态，现于 Kubernetes v1.35（alpha）中支持可变。此项变更使得更灵活的在线卷管理成为可能。

为什么要使节点亲和性可变？

这引出了一个显而易见的问题：为何现在要使节点亲和性可变？尽管像 Deployment 这类无状态工作负载可以自由修改，且通过重建每个 Pod 即可自动应用更改，但 PersistentVolume (PV) 是有状态的，若不丢失数据则无法轻易重建。

然而，存储提供商在不断演进，存储需求也在随之变化。最显著的是，目前多家提供商已提供区域级（regional）磁盘。部分提供商甚至支持从可用区级（zonal）磁盘到区域级磁盘的实时迁移，且不会中断工作负载。此变更可通过 VolumeAttributesClass API 进行表达，该 API 近期已在 1.34 版本中正式达到 GA 阶段。然而，即使卷已迁移至区域级存储，由于 PV 对象中记录的节点亲和性限制，Kubernetes 仍会阻止将 Pod 调度至其他可用区。在此情况下，您可能希望将 PV 节点亲和性从：

spec:
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.kubernetes.io/zone
          operator: In
          values:
          - us-east1-b

更改为：

spec:
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.kubernetes.io/region
          operator: In
          values:
          - us-east1

作为另一个示例，提供商有时会推出新一代磁盘。新磁盘未必能挂载到集群中的旧节点上。这种访问限制同样可通过 PV 节点亲和性进行表达，以确保 Pod 被调度到正确的节点。但是，当磁盘完成升级后，使用该磁盘的新 Pod 仍可能被调度到旧节点。为防止这种情况，您可能希望将 PV 节点亲和性从：

spec:
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: provider.com/disktype.gen1
          operator: In
          values:
          - available

更改为：

spec:
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: provider.com/disktype.gen2
          operator: In
          values:
          - available

因此，该配置现已支持修改，这是迈向更灵活的在线卷管理的第一步。尽管这只是一项从 APIServer 中移除单一验证的简单更改，但要实现与 Kubernetes 生态系统的深度集成，我们仍有很长的路要走。

立即试用

如果您是 Kubernetes 集群管理员，且您的存储提供商支持在线更新，您希望利用该功能，但这些更新可能会影响卷的访问权限，那么本功能正是为您设计的。

请注意，仅修改 PV 的节点亲和性并不会实际改变底层卷的访问状态。在使用此功能前，您必须先在存储提供商处更新底层卷，并明确更新后哪些节点能够访问该卷。随后，您可以启用此功能，使 PV 的节点亲和性与实际访问状态保持同步。

目前，该功能处于 Alpha 阶段。默认情况下为禁用状态，且未来可能会发生变更。如需试用，请在 APIServer 上启用 MutablePVNodeAffinity 功能门，之后即可编辑 PV 的 spec.nodeAffinity 字段。通常仅有管理员具备编辑 PV 的权限，请确保您已配置正确的 RBAC 权限。

更新与调度之间的竞态条件

Pod 之外仅有少数因素会影响调度决策，PV 节点亲和性便是其中之一。通过放宽节点亲和性以允许更多节点访问卷是没问题的，但在收紧节点亲和性时会产生竞态条件：Scheduler 缓存中如何感知已修改的 PV 尚不明确，因此存在一个极小的时间窗口，调度器可能会将 Pod 调度至已无法访问该卷的旧节点上。此时，Pod 将会卡在 ContainerCreating 状态。

目前正在讨论的一种缓解方案是：若违反 PersistentVolume 的节点亲和性规则，则让 kubelet 直接使 Pod 启动失败。该方案尚未合入。因此，如果您当前正在试用，请密切关注使用已更新 PV 的后续 Pod，确保它们被调度至可访问该卷的节点上。若在脚本中更新 PV 后立即启动新 Pod，可能无法达到预期效果。

未来与 CSI（容器存储接口）的集成

目前，PV 的节点亲和性与存储提供商中底层卷的修改均由集群管理员负责。但手动操作容易出错且耗时。我们更倾向于最终将其与 VolumeAttributesClass 集成，从而使非特权用户能够修改其持久卷声明（PVC）以触发存储端更新，并在适当时机自动更新 PV 的节点亲和性，而无需集群管理员介入。

我们欢迎用户与存储驱动开发者提供反馈

如前所述，这仅仅是第一步。

如果您是 Kubernetes 用户，我们希望了解您目前（或计划）如何使用 PV 的节点亲和性。在您的使用场景中，在线更新它是否有益？

如果您是 CSI 驱动开发者，您是否愿意实现此功能？您期望的 API 设计是怎样的？

请通过以下方式提供您的反馈：

Slack 频道 #sig-storage。
邮件列表 kubernetes-sig-storage。
KEP 议题 Mutable PersistentVolume Node Affinity。

如有任何与该功能相关的咨询或具体问题，请联系 SIG Storage 社区。

Last modified January 18, 2026 at 1:46 PM PST: Reorganize 2026 blog content (b81b14ba1b)

Kubernetes v1.35：PersistentVolume 节点亲和性可变（alpha）