云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载本文以 Rook 仓库中的设计文档 design/ceph/multus-network.md 为主线深入剖析 Rook 如何借助 Multus 为 Ceph 集群引入多宿主网络multi-homed networking涵盖 CRD 网络配置的演进、IPAM 方案的取舍Whereabouts 采纳、DHCP 否决、各 Ceph 守护进程mon/OSD/RGW/MDS/CSI的接入挑战以及最终在仓库源码中的落地印证。读完本文你将理解 Rook 中network.provider: multus的完整设计动机、selectors的语义与校验规则、为何最终选择 Whereabouts 作为 IPAM以及如何用仓库自带的验证工具提前检验你的 Multus 网络环境是否适合承载 Ceph。说明该设计文档标题注明not finalized yet and subject to update尚未最终定稿、内容可能更新属于设计阶段的早期决策记录。但其中的核心结论采用 whereabouts、否决 DHCP、selectors 双键设计已在当前仓库的 API 类型定义、CRD 文档与示例配置中落地本文会一并给出对应源码与配置路径作为佐证。一、为什么 Ceph 需要 Multus多宿主网络的动机文档开篇即声明多宿主网络本身的收益已在另一份设计文档 design/common/multi-net-multus.md 中探讨过本文不再复述只聚焦 Ceph 后端的实现。真正驱动 Rook 集成 Multus 的原因在于HostNetworking模式的两大缺陷暴露全部网络接口使用HostNetworking会把宿主的所有网络接口整个网络协议栈暴露进容器而 Multus 允许你只挑选需要的那一个接口/网络特权容器依赖HostNetworking通常要求特权容器Multus 方案可以显著减少这种特权需求。因此Multus 的目标是在获得与HostNetworking相近的性能收益绕过软件定义网络的额外延迟与带宽争抢的同时提升安全性Kubernetes 应用与 Ceph 守护进程实现网络隔离。理解这一点还需要 Ceph 自身的双网络模型作铺垫Ceph 守护进程最多可运行在两张独立网络上——public 网络面向客户端的读写流量Ceph-CSI、客户端 Pod 均走该网络与cluster 网络可选隔离 OSD 间复制、数据恢复等内部流量。若未指定 cluster 网络则内部流量回落到 public 网络。这一模型是后文public/cluster两个 selector 键存在的根本原因。二、CRD 网络配置的演进selectors 的双键扩展2.1 既有 network 属性设计文档指出CephCluster的 CRD 中已经存在network属性其原始形态为network: provider: selectors:2.2 新增的 public / cluster 两个硬编码键设计文档提出的扩展方案是在selectors下加入两个硬编码的键selectors: public: cluster:每个 selector 的值对应 Multus 中的一个NetworkAttachmentDefinitionNAD对象。规则如下至少提供一个selectorpublic数据守护进程的 public 网络绑定 Ceph 的public_network配置cluster数据守护进程的 cluster 网络绑定 Ceph 的cluster_network配置默认行为如果只设置了public则cluster自动取public的值。2.3 源码中的落地印证这一设计在当前仓库的 API 类型中已经完整实现见 pkg/apis/ceph.rook.io/v1/types.goNetworkSpec.Provider取值由NetworkProviderType枚举约束合法值为、host、multus对应常量NetworkProviderDefault、NetworkProviderHost、NetworkProviderMultusSelectors的类型为map[CephNetworkType]string而CephNetworkType的定义刻意允许任意字符串注释说明是为了兼容历史遗留的过度指定集群但常量只有两个CephNetworkPublic public与CephNetworkCluster cluster——正是设计文档中的两个硬编码键代码注释中还给出了与设计文档一致的示例selectors: public: default/cluster-fast-net cluster: rook-ceph/ceph-backend-net即 public 网络可以选用 default 命名空间下、面向 Kubernetes 全局应用的网络cluster 网络可以选用 rook-ceph 命名空间下、Ceph 专用的后端网络。校验逻辑至少一个 selector、格式合法设计文档要求至少提供一个 selector这一约束在 pkg/apis/ceph.rook.io/v1/network.go 的ValidateNetworkSpec中严格执行if spec.IsMultus() { if len(spec.Selectors) 0 { return errors.Errorf(at least one network selector must be specified when using the %q network provider, NetworkProviderMultus) } if _, err : spec.GetNetworkSelection(clusterNamespace, CephNetworkPublic); err ! nil { return errors.Wrap(err, ceph public network selector provided for multus is invalid) } if _, err : spec.GetNetworkSelection(clusterNamespace, CephNetworkCluster); err ! nil { return errors.Wrap(err, ceph cluster network selector provided for multus is invalid) } }此外还有几点值得注意的细节GetNetworkSelectionnetwork.go会通过 NAD 工具库nadutils.ParseNetworkAnnotation解析 selector 字符串为兼容旧版本用户若 selector 是单个 JSON 对象以{开头、}结尾会自动包装成单元素列表再解析且每个网络只允许一个 selection多选会直接报错CRD 层还叠加了 OpenAPI 的XValidation规则见 types.go在 API Server 侧就拦截使用 multus 但 selectors 为空与legacy hostNetwork 与其他 provider 混用两种非法组合ValidateNetworkSpecUpdatenetwork.go禁止在运行中变更 providerhost 与空值之间的切换除外保证网络方案的稳定性。三、Multus 支持的配置面接口类型与 IPAM 取舍3.1 接口类型Interface type作为 CNI 规范的一部分Multus 支持多种接口类型。设计文档指出Rook 天然支持其中任意一种因为它们不会从根本上改变 Rook 的工作行为——文档本身并未对接口类型做强制限制。3.2 IPAM 类型本设计的核心分歧点相比接口类型IPAMIP 地址分配才是复杂所在。当时设计文档撰写时点主流的三种 IPAM 方案中有两种被明确判定为不合适的候选IPAM 类型机制被否决的原因host-local维护本机 IP 分配数据库仅按主机维度工作不适用于分布式环境——各节点各自分配必然导致IP 冲突。whereabouts 项目dougbtv/whereabouts看起来能修复此问题但当时并非官方支持static为容器分配静态 IPv4/IPv6 地址适合调试无法规模化——需要为所有守护进程预先手工分配 IPDHCP由 DHCP 服务器按范围分发 IP见下文被否决的方案章节文档同时提示更详细的分析见文档末尾的被否决的方案章节本文第六节会完整覆盖。四、各 Ceph 守护进程的实现挑战设计文档按守护进程类型逐一拆解了接入 Multus 的网络需求与难点4.1 Monitors 与 OSDsMonitorsmon只需要访问 public 网络OSDs需要同时访问 public 与 cluster 两张网络OSD 既要服务客户端读写又要承担复制与恢复流量。mon 的额外硬性需求有两条可预测的 IP 地址Predictable IP addresses整个部署生命周期内 IP 保持不变——IP 必须能在 Pod 重启后幸存survive a restart。这两条需求直接决定了后文对 IPAM 方案的取舍也是 mon 引导bootstrap流程面临的最大难题。4.2 RGW 实现只需要访问 public 网络但 RGW 使用 Service IP LoadBalancer 对外暴露需要格外小心——多网络环境下 Service IP 与 Multus 附加网络之间的交互是设计难点。4.3 MDS / RBD-MIRROR / NFS都只需要访问 public 网络由于它们不使用 Service IP无需特殊处理。4.4 CSI Pods一个必须修复的已知问题设计文档引用了一个 Rook 的已知问题对应 GitHub issue 8085核心现象是当使用 Ceph CSI 挂载了 CephFS/RBD 卷的 Pod 运行期间如果 CSI CephFS/RBD 插件 Pod 被重启或终止例如重启或删除其 DaemonSet则该卷上的所有操作都会卡死即使随后重启 CSI Pod 也无法恢复。唯一的临时解决办法是重启承载 CSI 插件 Pod 的节点。该问题的根源在于挂载点mount与 CSI 插件进程所在网络命名空间绑定CSI 插件被强杀后挂载点的网络上下文随之失效。为此设计文档提出的缓解方案是当部署配置了 multus 网络的 CephCluster 时为所有将运行 CSI 插件 Pod 的节点在宿主网络命名空间host network namespace中附加一个 multus 网络接口。这样 CSI Pod 可以继续使用宿主网络运行同时仍然能够访问 Ceph 的 public multus 网络。具体实现设计为新增一个 DaemonSet 来拥有所有 CephFS 挂载点及 RBD 映射设备对应的网络而现有的csi-{cephfs,rbd}pluginDaemonSet 保持不动。通过把网络所有权从 CSI 插件 Pod 中剥离出来避免插件重启导致挂载失联。五、已采纳的方案Whereabouts IPAM经过调研Rook 团队最终决定采用 whereabouts 作为 IPAM 插件。它的定位是一个集群级cluster-wide的 IP 地址管理 CNI 插件。如果你喜欢 host-local 的工作方式但需要它跨越集群中的所有节点host-local 只知道给本机 Pod 分配 IP那么 whereabouts 正是你要找的工具。关键能力支持 IPv4 与 IPv6 双栈寻址跨集群静态 IP 地址分配分配的IP 在部署重启后依然存活满足 mon 的需求分配动作由 whereabouts 完成而非 Rook——Rook 无需自己维护 IP 数据库。不过设计文档也明确标注了一个/!\警告唯一尚未解决的问题是如何为即将启动的 monitor 预测 IP我们可能需要小幅重构 mon 的引导方式使其不再需要预先知道 IP。这是当时设计状态下唯一悬而未决的技术债也是 mon 引导流程后续演进的重点方向。从当前仓库的最终状态看whereabouts 已被官方文档确认为推荐方案Documentation/CRDs/Cluster/network-providers.md 中的推荐 NAD 示例即使用type: whereabouts配合range指定地址段详见本文第七节并注明whereabouts 确保每个 Pod 获得集群内唯一的 IP无需 DHCP 服务器。六、被否决的方案DHCP 及其变体文档保留了两个被否决的方案目的是可追溯性与知识沉淀。6.1 IPAM 类型 DHCP在该场景下由 DHCP 服务器按给定范围向 Pod 分发 IP 地址。优点Pod 在物理网络接口上获得专用 IPCeph 侧无需任何改动——Rook 通过NetworkAttachmentDefinition探测 CIDR然后填充 Ceph 的public_network与cluster_network配置即可。缺点IP 分配不可预测——在 Pod 启动完成前无法得知 IP因此探测必须发生在 monitor 容器运行内部类似于今天 OSD 代码的做法需要对 mon 引导代码做大幅改动需要在集群的每个节点上部署DHCP 守护进程这被证明是麻烦的来源。假设走这条路mon 的引导流程需要重构成如下步骤让第一个 monitor 基于某个接口自行发现自己的 IP第一个 mon 引导完成后将其 IP 注册进一个ConfigMap同时填充 clusterInfo启动第二个 mon从 clusterInfo 中查找 initial member即使操作中途崩溃也不用担心——每次启动时都会基于该 ConfigMap 执行CreateOrLoadClusterInfo()以此类推逐个启动剩余 monitor。文档还在该方案旁标注了TBT有待验证Pod 重启后能否保持相同 IP。6.2 IPAM 类型 DHCP Service IP这是一个纯理论的变体使用带 DHCP 的 IPAM 并结合 Service IP。它要求与Kube-proxy 交互而当时乃至现在并不存在这样的特性。即便存在团队已经决定不走 DHCP 路线因此该方案不再具有现实意义。否决结论归纳DHCP 系列方案被否的核心原因是 IP 不可预测 引导流程重构成本高 每节点 DHCP 守护进程运维负担大。这从反面印证了 mon可预测且持久 IP需求对方案选择的决定性影响。七、从设计到落地仓库中的实现与配套工具设计文档描述的蓝图最终在仓库中体现为 API 类型、示例配置、官方文档与验证工具四个层面。7.1 完整的 CephCluster Multus 示例仓库中的 deploy/examples/cluster-multus-test.yaml 提供了一个可直接对照的最小化示例其网络段为apiVersion: ceph.rook.io/v1 kind: CephCluster metadata: name: my-cluster namespace: rook-ceph # namespace:cluster spec: # ... 省略其他配置 ... network: provider: multus selectors: public: public-net cluster: cluster-net注意这里 selector 的值直接使用 NAD 名称public-net/cluster-net未带命名空间前缀——Rook 会自动以 CephCluster 所在的命名空间rook-ceph解析即等价于rook-ceph/public-net。若 NAD 位于其他命名空间则需要写成namespace/name的形式。7.2 NAD 定义与 addressRanges 兜底Documentation/CRDs/Cluster/network-providers.md 给出了推荐的 NAD 定义模板macvlan whereaboutsapiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: ceph-multus-net spec: config: { cniVersion: 0.3.1, type: macvlan, master: eth0, mode: bridge, ipam: { type: whereabouts, range: 192.168.200.0/24 } }该文档还强调了几条与设计文档呼应的实操要点master必须匹配各宿主上要使用的网络接口且所有宿主必须一致CNI 类型推荐 macvlan——相比传统 Linux bridge 配置CPU 与内存开销更低IPAM 推荐 whereabouts——确保 Pod 获得集群内唯一 IP若网络中已有 DHCP 服务器务必确保 IP 范围不与其重叠selectors与addressRanges配合Rook 会尝试自动探测所选网络的 CIDR但该过程不保证成功且每次 CephCluster reconcile 都会获取一次新的网络租约。若自动探测失败、探测结果不正确、或底层网络不支持复用旧 IP则应在network.addressRanges中手工指定 CIDRnetwork: provider: multus selectors: public: default/kube-multus-net cluster: rook-ceph/ceph-multus-net # addressRanges: # public: # - 192.168.100.0/24 # - 192.168.101.0/24 # cluster: # - 192.168.200.0/24这一兜底机制的合法性同样由 network.go 的校验保障addressRanges只能配合host或multusprovider 使用且 multus 下指定 public/cluster 地址范围的前提是存在对应的 selector每个 CIDR 都会经过net.ParseCIDR严格校验。此外官方文档也如实记录了当前 Multus 方案的已知限制依赖 Kubernetes Service IP 的守护进程mon、mgr、RGW并不会直接监听selectors指定的 NAD而是监听默认网络NAD 仅作为附加网络挂载到容器中供其通信——该问题的修复工作正在进行中multus-service 项目何时支持尚不明确。这与设计文档中 RGW使用 Service IP 需小心的预警完全对应。7.3 Multus 配置验证工具Multus 网络环境是否真正适合承载 Ceph官方文档强烈建议在安装 CephCluster 之前先行验证network-providers.md。验证工具的 CLI 入口在 cmd/rook/userfacing/multus/multus.go 中注册核心实现位于 pkg/daemon/multus 目录含validation.go、resources.go、statemachine.go、templates.go、config.go等。使用步骤进入 Rook operator Podkubectl --namespace rook-ceph exec -it deploy/rook-ceph-operator -- bash查看验证工具帮助rook multus validation run --help使用配置文件做高级配置可生成带注释说明的模板rook multus validation config --help运行验证若失败工具会给出可能的原因排查建议并请求相关日志与输出用于定位问题。从源码看该验证工具是一个有状态的状态机statemachine.go 配合validation.go中定义的一系列状态会在目标节点上拉起多类探针 Pod 来模拟 Ceph 守护进程的网络拓扑Web Server Pod同时挂载 public 与 cluster 网络模拟 OSD 的落点并对外提供地址信息Image Pull DaemonSet预拉取镜像同时探测 DaemonSet 在各节点的调度能力Host Checker DaemonSet验证宿主能否路由到 public 网络对应设计文档中host 到 Pod方向的路由要求Client DaemonSet模拟两类 Ceph 守护进程——OSD同时连接 public cluster 网络与非 OSD仅连接 public 网络每节点数量由配置的osdsPerNode/otherDaemonsPerNode决定。配置项定义见 pkg/daemon/multus/config.go其中PublicNetwork/ClusterNetwork分别对应设计文档的 public/cluster 选择器默认每节点 3 个 OSD、16 个非 OSD 守护进程、资源超时 3 分钟、网络抖动阈值 30 秒。验证结果会附带针对性的调试建议如 macvlan 对交换机 MAC 学习数量的限制、Promiscuous 模式、防火墙策略等参见validation.go中的unableToProvideAddressSuggestions等常量。工具还支持hostCheckOnly模式只做宿主侧检查以及 OpenShift 等安全受限环境的专用示例 deploy/examples/multus-validation-test-openshift.yaml。7.4 端到端测试脚本仓库 tests/scripts/multus 目录下提供了完整的端到端验证脚本族与设计文档的各个关注点一一对应setup-multus.sh搭建 Multus 测试环境test-110-cli.sh验证rook multus validationCLItest-200-stretch-label-nodes.sh 与 test-200-stretch-taint-nodes.shstretch 集群场景的节点标签/污点准备test-210-stretch-overlap.sh验证仅 public / 仅 cluster / publiccluster 分离等网络配置组合对应设计文档中只设 public 时 cluster 继承 public及双网络并存的行为test-220-stretch-pub-and-cluster.sh、test-230-stretch-pub-only.sh、test-240-stretch-cluster-only.sh分别覆盖双网络仅 public仅 cluster三种部署形态。这些脚本从测试角度印证了设计文档中至少提供一个 selector以及public 与 cluster 可独立配置的语义边界。八、总结设计决策回顾与现状对照设计议题设计文档结论仓库现状印证网络模型Ceph 双网络public/clusterselectors 双键cluster 可回退到 publicCephNetworkType仅 public/cluster 两常量示例配置cluster-multus-test.yamlIPAM 主方案采纳 whereabouts集群级静态 IP、重启存活、由 whereabouts 分配官方文档 NAD 模板默认 whereabouts并推荐之IPAM 否决host-localIP 冲突、static不可扩展、DHCPIP 不可预测 引导重构 每节点 DHCP 守护进程官方文档无 DHCP 推荐场景仅作为示例之一保留mon 特殊需求可预测、持久 IP引导流程或需重构当前 mon 仍属已知限制依赖 Service IP 的守护进程不直接监听 NADCSI 问题新增 DaemonSet 拥有挂载网络CSI 插件 DaemonSet 不动设计层面落地于 CRD/网络附加逻辑详见 pkg/operator/k8sutil/network.go验证手段无设计阶段官方提供rook multus validation工具与完整测试脚本族整体来看Rook 的 Multus 集成遵循了收益明确、取舍清晰、先验证后上线的工程路线通过双 selector 的设计把 Ceph 的双网络模型平移到 Kubernetes 多网络模型上通过 whereabouts 解决 IP 分配的集群级一致性与持久性问题并用专门的验证工具把网络环境是否合格这一风险前置到 CephCluster 安装之前。对于计划在生产环境使用 Multus 承载 Ceph 的读者建议按本文第七节的流程先运行验证工具再依据 Documentation/CRDs/Cluster/network-providers.md 中的 macvlan whereabouts 模板设计 NAD最后在selectors无法可靠自动探测 CIDR 时使用addressRanges手工兜底。赞分享云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载相关推荐Rook 与 Ceph-CSI Operator 集成设计实验性部署、配置开关与新增 CRD 全解析Rook 与 Ceph CSI Operator 集成设计实验性部署、配置开关与新增 CRD 全解析 导读 本文基于 Rook 仓库中的设计文档 design云原生存储容器编排运维Rook CephCluster 网络提供商完全指南从 Kubernetes 默认网络到 Host Networking 与 MultusRook CephCluster 网络提供商完全指南从 Kubernetes 默认网络到 Host Networking 与 Multus Rook 默认使用云原生存储容器编排运维通过 CephCluster CRD 配置 Ceph 配置选项Rook cephConfig 设计解析与实战指南通过 CephCluster CRD 配置 Ceph 配置选项Rook cephConfig 设计解析与实战指南 导读 本文以 Rook 的设计文档 ceph云原生存储容器编排运维创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考