Rook项目中CephFS/RBD provisioners在hostNetwork模式下与CSIAddon的端口冲突问题分析

问题背景

在Kubernetes环境中使用Rook部署Ceph存储时，当网络环境不支持IPv6 NAT转换（如使用KubeOVN等特定CNI插件）的情况下，管理员通常需要将Rook组件（包括ceph-csi）配置为使用hostNetwork模式运行。这一配置通过设置enforceHostNetwork: true参数实现，使得provisioners能够直接使用IPv6网络。

问题现象

当同时启用CSI-addons功能时，系统会出现严重的端口冲突问题。CSI-addons会在每个Pod中注入一个sidecar容器，默认绑定9070端口。在hostNetwork模式下，这会导致以下两类组件之间产生端口冲突：

1. rbd/fs-plugin（以DaemonSet形式部署）
2. provisioners（以Deployment形式部署）

由于DaemonSet确保每个节点只运行一个实例，而Deployment可能在已有rbd/fs-plugin运行的节点上调度provisioners实例，导致其中一个组件无法绑定端口，进而引发Pod处于Pending状态或崩溃。这将导致集群出现以下两种严重后果之一：

• 节点失去挂载PVC的能力
• 整个集群失去创建/删除/调整PVC大小的能力

技术分析

问题的本质在于hostNetwork模式下，同一节点上的多个Pod无法共享相同的端口。这与常规的CNI网络模式不同，因为在CNI模式下，每个Pod拥有独立的网络命名空间，端口绑定互不干扰。

CSI-addons的设计初衷是为CSI驱动提供扩展功能，但在hostNetwork场景下，其默认的端口配置假设导致了这一冲突。特别是：

• CSI-addons sidecar默认使用9070端口
• 该端口在rbd-provisioner和cephfs-provisioner之间无法共享
• 在hostNetwork模式下，端口冲突直接导致服务不可用

解决方案演进

社区针对此问题提出了几种解决方案思路：

1. 端口可配置化方案：允许用户自定义CSI-addons的监听端口，为不同类型provisioner配置不同端口
2. 固定端口差异化方案：为CephFS和RBD provisioner硬编码不同的默认端口（如9070和9071）
3. 迁移至ceph-csi-operator：长期来看，Rook计划迁移到新的ceph-csi-operator架构，该架构已内置相关修复

经过讨论，社区最终采用了第二种方案，即通过硬编码为不同类型provisioner分配不同端口。这一方案的优势在于：

• 实现简单直接
• 无需引入额外的配置参数
• 与未来向ceph-csi-operator的迁移路径一致

实施建议

对于正在使用Rook并遇到此问题的用户，建议采取以下措施：

1. 升级到包含此修复的Rook版本
2. 如果必须使用hostNetwork模式，确保CSI-addons功能使用差异化端口配置
3. 关注Rook向ceph-csi-operator的迁移计划，提前做好升级准备

总结

这一案例展示了在Kubernetes存储系统中网络模式选择与组件交互的复杂性。hostNetwork模式虽然在某些网络环境下是必要选择，但会带来端口管理等额外挑战。Rook社区通过这一问题修复，不仅解决了特定场景下的稳定性问题，也为未来架构演进奠定了基础。