Kubernetes v1.35：可变持久卷节点亲和性（alpha）

Source: Kubernetes Blog

（请提供您希望翻译的正文内容，我将把它翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。）

持久卷节点亲和性

PersistentVolume node affinity API（参见 Kubernetes 文档）自 Kubernetes v1.10 起可用。它通常用于表明卷可能并非对集群中的每个节点都同等可访问。

• 之前的行为： nodeAffinity 字段是 不可变 的。
• 新的行为（v1.35 – alpha）： 该字段现在 可变，从而实现更灵活的在线卷管理。

Source: …

为什么要让 Node Affinity 可变？

Kubernetes 传统上将 PersistentVolume（PV）的 node affinity 视为不可变的。
对于无状态工作负载（例如 Deployments）这不是问题——修改 pod 规范会触发一次滚动更新，重新创建 pod。
然而，有状态工作负载依赖于不能在不冒数据丢失风险的情况下重新创建的 PV。

为什么现在要改变它？

1. 存储后端的演进 – 许多供应商现在提供 区域磁盘，甚至支持在不中断工作负载的情况下将区域磁盘从单区迁移为多区。
2. 新一代磁盘 – 新的磁盘可能只能挂载到一部分节点（例如更新的实例类型）。

这两种情况都需要能够更新 PV 的 node affinity，以便在底层存储变化后，pod 能调度到正确的节点上。

示例 1 – 从单区磁盘迁移到区域磁盘

最初绑定到特定可用区的 PV：

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

将卷迁移到区域磁盘后，affinity 应放宽到区域级别：

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

示例 2 – 切换到新一代磁盘

仅适用于第 1 代磁盘的 PV：

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

当卷升级到第 2 代磁盘时，需要相应地更新 affinity：

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

更大的图景

使节点亲和性可变是实现迈向更灵活、在线卷管理的第一步。
此更改非常简单——在 API 服务器中移除一次验证检查——但它为与 Kubernetes 生态系统的更深层集成打开了大门（例如，自动迁移工具、动态存储类更新等）。

虽然前路仍然漫长，但此功能已经能够实现：

• 在不同可用区/地区之间无缝迁移卷。
• 随着硬件需求演进，对 PV 进行相应对齐。
• 减少有状态工作负载的运维摩擦。

试用

此功能面向其存储提供程序支持在线更新的 Kubernetes 集群管理员。更新卷可能会影响其可访问性，因此您必须：

1. 首先在存储提供程序中更新底层卷。
2. 确定更新后哪些节点可以访问该卷。
3. 启用该功能 并保持 PersistentVolume (PV) 节点亲和性同步。

注意： 单独更改 PV 节点亲和性 不会 修改底层卷的可访问性。

功能状态

• Alpha – 默认禁用，且可能在后续版本中更改。
• 若要试用，请在 API server 上启用 MutablePVNodeAffinity 功能门，并编辑 PV 的 spec.nodeAffinity 字段。
• 通常只有管理员才能编辑 PV，请确保您拥有相应的 RBAC 权限。

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

PV 节点亲和性是少数几个可以影响调度决策的 Pod 之外因素之一。

• 放宽 节点亲和性（允许更多节点访问卷）是安全的。
• 收紧 节点亲和性（限制访问）会引入竞争条件：
  • 调度器可能仍然缓存着旧的 PV。
  • 它可能会把 Pod 调度到已经无法访问该卷的节点上。
  • Pod 将卡在 ContainerCreating 状态。

当前的缓解措施（讨论中）

• Kubelet 级别检查： 如果 PersistentVolume 的节点亲和性被违反，则使 Pod 启动失败。
  • 此更改尚未合并。

实际操作建议

• 在更新 PV 后，监控随后使用该 PV 的 Pod，确保它们被调度到能够访问卷的节点上。
• 不要 在脚本中紧接 PV 更新后立即启动新 Pod；调度器的缓存可能已过期，导致调度失败。

总结： 只有在你已经更新底层存储并验证节点可访问性之后，才启用 MutablePVNodeAffinity。在收紧节点亲和性期间，务必关注 Pod 的调度行为，直至 kubelet 级别的保护措施落地。

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

目前，集群管理员必须手动：

1. 修改 PersistentVolume（PV）节点亲和性，以及
2. 更新存储提供者中的底层卷。

这些手动步骤容易出错且耗时。

期望的工作流

• 目标： 让非特权用户仅通过修改其 PersistentVolumeClaim（PVC）即可触发存储端的更新。
• 机制： 利用 VolumeAttributesClass（或类似的 CSI 功能），使得：
  • PVC 的变更自动传播到存储提供者。
  • 在适当时机自动更新 PV 的节点亲和性。
• 收益： 无需集群管理员介入，降低运维开销并减少人为错误的风险。

后续步骤

• 调查 CSI 对 VolumeAttributesClass 动态更新的支持情况。
• 原型化 一个控制器，监听 PVC 变更并进行调和：
  • 存储端配置。
  • PV 节点亲和性。
• 定义 RBAC 策略，允许非特权用户修改 PVC，同时限制直接编辑 PV。

我们欢迎您的反馈

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

• Kubernetes 用户 – 我们想了解您如何使用（或计划使用）PV 节点亲和性。在您的情况下，在线更新它是否有益？
• CSI 驱动开发者 – 您是否愿意实现此功能？您希望 API 采用什么样的设计？

请通过以下任意渠道分享您的想法：

• Slack: #sig‑storage
• 邮件列表: kubernetes‑sig‑storage
• KEP 议题: Mutable PersistentVolume Node Affinity (KEP‑5381)

如有任何关于此功能的查询或具体问题，欢迎联系 SIG Storage 社区。