Rancher local-path-provisioner 中 PV 节点亲和性调度问题解析与解决方案

背景

Rancher 的 local-path-provisioner 是一个为 Kubernetes 提供本地存储卷动态供给能力的组件。在最新版本 v0.0.29 和 master 分支中，用户报告了一个关键问题：当使用 matchFields 方式定义 PV 的节点亲和性时，Kubernetes 调度器无法正确将 Pod 调度到 PV 所在的节点上。

问题现象

在 v0.0.29 版本中，PV 的节点亲和性配置从传统的 matchExpressions 方式：

nodeAffinity:
  required:
    nodeSelectorTerms:
    - matchExpressions:
      - key: kubernetes.io/hostname
        operator: In
        values:
        - my-node.example.com

变更为 matchFields 方式：

nodeAffinity:
  required:
    nodeSelectorTerms:
    - matchFields:
      - key: metadata.name
        operator: In
        values:
        - my-node.example.com

这种变更导致了以下问题：

1. Pod 被调度到错误的节点
2. 由于无法访问本地存储路径，Pod 启动失败
3. 节点排水(drain)操作后，Pod 被错误地调度到其他节点

技术分析

节点亲和性机制差异

1. matchExpressions：

   • 基于节点标签(label)进行匹配
   • kubernetes.io/hostname 是 Kubernetes 自动为每个节点设置的标准标签
   • 调度器可以正确识别并应用这种亲和性规则

2. matchFields：

   • 直接匹配节点对象的字段(field)
   • metadata.name 是节点对象的元数据字段
   • 在某些 Kubernetes 版本(1.19-1.26)中，调度器对这种匹配方式的支持存在问题

根本原因

1. 调度器实现差异：不同 Kubernetes 版本对 matchFields 的支持程度不同
2. 标签与字段的语义差异：节点名称作为字段(metadata.name)和作为标签(kubernetes.io/hostname)在调度逻辑中被区别对待
3. 兼容性问题：变更后的配置在部分环境无法被正确解析

解决方案

临时解决方案

回退到 v0.0.28 版本，该版本仍使用 matchExpressions 方式，已被验证可以正常工作。

长期解决方案

项目维护者已确认将在 v0.0.30 版本中修复此问题。建议用户：

1. 关注项目发布动态
2. 升级到修复后的版本
3. 测试验证新版本的节点亲和性功能

最佳实践建议

1. 生产环境升级前，务必在测试环境验证存储功能
2. 监控节点亲和性相关的调度事件
3. 对于关键业务，考虑使用静态 PV 配置作为过渡方案
4. 保持 Kubernetes 集群版本与存储组件的兼容性

总结

本地存储的动态供给是 Kubernetes 存储体系中的重要功能。Rancher local-path-provisioner 的这次变更反映了存储组件与调度器交互的复杂性。理解节点亲和性的不同实现方式及其影响，对于设计和维护可靠的存储解决方案至关重要。用户应当根据自身环境特点选择合适的版本，并密切关注组件的更新动态。