Volcano HyperNode 独立控制器把拓扑发现从 vc-controller-manager 中解耦的部署设计与实操【免费下载链接】volcanoA Cloud Native Batch System (Project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/vol/volcanoHyperNode 是 Volcano 对分层网络拓扑的标准抽象长期以来只能作为vc-controller-manager的一部分运行。本文基于 Volcano 社区的设计提案讲解 HyperNode 控制器独立部署模式Standalone Mode的完整设计为什么需要它、两种部署模式如何共享同一份实现、vc-hypernode-controller-manager二进制的运行时装配、Helm 三态开关与最小权限 RBAC 的落地方式以及如何把存量集群安全地从聚合模式迁移到独立模式。读完本文你将掌握如何在只保留拓扑发现能力、不运行完整 Volcano 控制面的环境中部署和运维 HyperNode 控制器。1. 背景为什么需要独立的 HyperNode 控制器通信拓扑正在成为大规模 AI 训练与推理的通用调度输入。不同代际的加速器、不同的网络架构和厂商管理系统都要求拓扑发现能力能够独立于调度策略演进。这带来两种正当的采用模式把 Volcano 作为完整调度系统采用的用户只采用 HyperNode 拓扑能力、配合既有调度器或 AI 平台使用的用户。而现状是HyperNode 控制器只能跑在vc-controller-manager进程内。对于第二种用户Volcano 并没有提供官方的方式去独立部署、滚动升级、扩容和管理 HyperNode 的 RBAC他们必须连带运行一堆与拓扑无关的 controller-manager 能力形成不必要的运维耦合。这里有一个容易被误解的点vc-controller-manager已有的--controllers参数只能决定进程内跑哪些控制器逻辑它并不提供独立的二进制、镜像、Deployment、故障域或 RBAC 边界因此无法替代一个官方支持的独立运行时。这本质上是社区采用与长期维护问题而非源码布局问题——Volcano 的资源边界早已清晰HyperNode 控制器负责发现并维护 HyperNode 资源调度器通过volcano.sh/apis消费这些资源缺的只是一个围绕该边界构建的官方独立部署。该提案刻意只覆盖 HyperNode它拥有清晰的 API 边界和具体的独立部署场景其他组件如 PodGroup应依据各自的用户价值与耦合度单独评估。2. 总体设计两种部署模式一份实现提案的核心决策是在不把 HyperNode 拆分成独立产品的前提下解除其部署与其他控制器的耦合——扩大的是部署边界API、源码归属、社区治理和发布边界仍然与 Volcano 对齐领域本提案中的定义部署在现有 controller-manager 模式旁新增可选的 standalone 模式实现两种模式共享pkg/controllers/hypernode下的同一份实现集成自定义调度器和 AI 平台继续通过 HyperNode API 消费拓扑信息交付社区随 Volcano 版本发布独立二进制、镜像与安装支持版本与治理HyperNode 继续使用 Volcano 的版本号、发布节奏与社区流程据此独立控制器是 HyperNode 的一种官方部署形态而不是独立产品。两种模式给定相同的拓扑源配置和已注册 Discoverer必须产生语义等价的 HyperNode 资源默认升级路径不创建任何 standalone 工作负载也不需要 API、配置或数据迁移。2.1 目标与非目标目标包括在保留 controller-manager 默认模式的同时提供官方支持的独立 HyperNode 控制器让 standalone 与自定义调度器用户无需运行无关的 Volcano 控制器保留现有 HyperNode 资源 API、配置、发现行为与调度器集成保留 Discoverer 注册表使新发现方法在两种模式下都能工作保证两种模式行为一致且任意时刻只有一个进程拥有 HyperNode 调和权让独立组件具备与其他 Volcano 组件同等级别的生产运维能力leader 选举、健康检查、指标、优雅退出、最小权限 RBAC。非目标同样明确不把 HyperNode 移入staging/或拆出独立 Go module / 仓库不把内部控制器或 Discoverer 包发布为稳定公开 SDK不建立独立的 HyperNode 版本号、发布节奏或治理模型不修改 HyperNode CRD、资源语义、发现配置 schema、webhook 或调度行为也不把同样的拆分决策直接套用到 PodGroup 等其他控制器。2.2 社区用户场景社区用户期望的 HyperNode 使用方式提案后的支持情况现有 Volcano 用户升级 Volcano 后继续在vc-controller-manager中运行 HyperNode默认支持无需迁移Standalone HyperNode 或自定义调度器用户部署官方独立 HyperNode 镜像不装完整 controller manager官方支持独立构建 Volcano 的用户Clone/fork Volcano从对应源码版本构建独立组件支持维护环境专属发现逻辑的用户在 Volcano fork 中实现并注册私有 Discoverer构建增强镜像支持用户自担 rebase 与兼容性测试贡献通用发现能力的用户通过现有注册表实现 Discoverer 并贡献上游支持且推荐合入后随官方镜像发布自定义调度器或 AI 平台通过volcano.sh/apis消费 HyperNode 资源支持并推荐直接 import 控制器实现作为 Go 项目 SDK把内部控制器包当可复用 SDK不支持也不规划由此得出三条社区级结论社区应提供官方部署选择而不是让用户自维护定制部署通用的拓扑发现与调和能力应收敛到上游共享兼容性、CI 与发布维护独立演进系统之间的主要集成边界应该是 HyperNode API而不是内部控制器包。3. 代码与交付结构提案保留现有 HyperNode 实现目录在主仓库内新增独立进程入口与交付入口实际仓库中的布局与设计一致volcano/ ├── cmd/ │ ├── controller-manager/ # 既有聚合进程默认运行 HyperNode │ └── hypernode-controller-manager/ # 新增独立入口、选项与启动逻辑 │ ├── main.go │ └── app/ │ ├── server.go │ └── options/options.go ├── pkg/ │ ├── controllers/ │ │ └── hypernode/ # 保留发现、注册表、调和与测试 │ │ ├── api/ │ │ ├── config/ │ │ └── discovery/ │ │ ├── label/ # 更新复用进程提供的 informer │ │ └── ufm/ │ └── util/ │ └── hypernode/ # 新增仓库内部 MemberSelector 辅助 ├── installer/ │ ├── dockerfile/ │ │ └── hypernode-controller-manager/ # 新增独立镜像构建入口 │ └── helm/chart/volcano/ │ ├── values.yaml # 更新运行模式与独立部署配置 │ └── templates/ │ ├── controllers.yaml # 更新控制聚合进程中的 HyperNode │ └── hypernode_controller.yaml # 新增Deployment、ServiceAccount、RBAC、Service ├── Makefile # 更新二进制、镜像与发布目标 └── hack/ # 更新清单生成与发布校验各领域的实现范围如下领域主要变更独立命令新增vc-hypernode-controller-manager只组装 HyperNode 控制器及其所需运行时设施聚合命令保持既有默认行为standalone 模式下通过既有的控制器选择机制在聚合进程中禁用 HyperNode运行时装配独立命令构造 HyperNode 控制器契约所需的 Kubernetes/Volcano 客户端与共享 informer factoryHyperNode 控制器去除对调度器实现包的依赖只接受进程提供的必要 informerDiscoverers保留现有注册表Label Discoverer 改为复用 Node 与 HyperNode 共享 informerUFM 等其余 Discoverer 行为不变仓库内部工具把 MemberSelector 解析从pkg/scheduler/api移到pkg/util/hypernode供控制器与调度器复用不改volcano.sh/apisHelm 与 RBAC新增互斥的运行模式、standalone Deployment 与最小权限 ServiceAccount/RBAC共享既有控制器 ConfigMap默认不创建 standalone 资源构建与发布新二进制与镜像接入既有 Makefile、镜像构建、清单生成、CI 与 Volcano 发布流水线3.1 独立进程入口从 main 到运行时的装配查看 main.go进程入口非常克制初始化 klog、注册pflag选项、设置 leader 选举默认值并把 Lease 资源名固定为vc-hypernode-controller-managerserverOptions.LeaderElection.ResourceName见 main.go 第 49 行随后进入app.Run。options.go 定义了独立控制器暴露的命令行参数这些就是该二进制的完整配置面参数默认值说明--master空API server 地址覆盖 kubeconfig 中的值--kubeconfig空kubeconfig 文件路径--kube-api-qps50与 API server 交互的 QPS--kube-api-burst100与 API server 交互的 Burst--versionfalse打印版本后退出--healthz-address:11251健康检查监听地址--enable-healthzfalse开启健康检查端点--enable-metricsfalse开启指标端点--listen-address:8081指标监听地址--leader-elect等见 component-base标准 leader 选举参数组选项在启动前会经过 ValidateQPS/Burst 必须为正数、健康检查与指标地址必须合法、两者启用时端口不能冲突并做 leader 选举配置的合法性校验。注意健康检查11251与指标8081是默认关闭、按需开启的Helm 模板中再显式传入--enable-healthztrue等参数见第 5 节。3.2 server.go客户端、informer 与 leader 选举的装配server.go 的Run函数完成了设计文档中运行时装配承诺的具体实现按需求构造运行时设施prepareController只创建 HyperNode 需要的 kube client、Volcano client、以及各自的 SharedInformerFactory填入framework.ControllerOption然后调用hypernode.NewController()与Initialize。进程不会继承无关控制器的资源访问面。专用 Leader ElectionLease 锁通过resourcelock.New创建资源命名空间与名称由命令行注入。独立模式始终启用 leader 选举包括单副本保证替换 Pod 必须拿到 Lease 才能开始调和。OnNewLeader回调里有一个值得注意的细节follower 观察到别的 leader 时会把自身标记为 ready避免滚动更新时被当前 leader 拖住而真正开始 leading 的节点则先把processReady置为 false等 informer 缓存同步完成后才 ready。优雅退出run返回的闭包会同时等待CacheSyncSucceeded()、上下文取消与控制器完成信号三者中的正确组合确保 informer、队列与 discoverer 全部关闭后进程才退出。3.3 控制器本体共享实现如何服务两种模式两种模式共享的 HyperNode 控制器 通过framework.RegisterController注册init()中其Initialize只做三件事从ControllerOption接收进程提供的 informer factory 与客户端建立 HyperNode/Node/ConfigMap 的 lister 与限流队列用discovery.NewManagerWithInformers构造发现管理器——注意该构造器接收的是进程注入的nodeInformer与hyperNodeInformer而不是自建 List/Watch 流这正是Discoverer 必须复用共享 informer约束的落点。Run的启动序列是启动两个 informer factory → 等待缓存同步 → 启动 discovery manager → 关闭cacheSyncSucceeded通道供 readyz 判断→ 启动watchDiscoveryResults与processHyperNodeQueue两个 worker。调和逻辑 reconcileTopology 按发现源source为粒度工作先按NetworkTopologySourceLabelKey列出该源既有 HyperNode把发现的 HyperNode 打上方源标签后创建/更新删除已消失的 HyperNode每条发现结果都会被ResultSynced确认调和失败不会阻塞后续发现重载。发现侧由 discovery/manager.go 管理其中通过空导入注册了内置 Discoverermanager.go 第 37-38 行_ volcano.sh/volcano/pkg/controllers/hypernode/discovery/label _ volcano.sh/volcano/pkg/controllers/hypernode/discovery/ufm这就是提案中强调的编译期 Discoverer 注册表通用发现能力贡献到上游、随官方镜像在两种模式下同时交付环境专属能力则在 fork 中注册私有 Discoverer 并自建增强镜像。注册表本身不对外承诺跨版本兼容也不作为公开 SDK 发布。4. 运行时模式Helm 三态开关Helm chart 用一个配置项决定哪个进程拥有 HyperNode 调和权定义在 values.yaml第 34-37 行custom: hypernode_controller_mode: controller-manager # controller-manager | standalone | disabled模式生效行为controller-manager默认值不创建任何 standalone 资源HyperNode 继续由vc-controller-manager中的既有控制器门控管理standaloneHelm 在vc-controller-manager中禁用 HyperNode并创建专用的vc-hypernode-controller-managerDeploymentdisabled不创建 standalone 资源且vc-controller-manager中的 HyperNode 也被禁用模板层面的实现分两处禁用聚合进程中的 HyperNodecontrollers.yaml 中只要模式不是controller-manager就会在--controllers参数后追加-hyperNode-controller例如*,-sharding-controller,-hyperNode-controller。这与提案描述完全一致standalone和disabled模式都通过既有控制器选择机制关闭聚合进程中的 HyperNode。创建独立工作负载hypernode_controller.yaml 整体包裹在eq $mode standalone条件内非 standalone 模式下一个相关资源都不会生成。_helpers.tpl中的hypernodeControllerMode辅助函数做了取值校验只接受controller-manager、standalone、disabled三者且standalone 模式下custom.hypernode_controller_replicas必须至少为 1要停止调和请使用disabled模式。一个重要的运维约束是两种部署模式使用不同的 leader-election Leaseleader 选举无法阻止切换期间的短暂双调和。因此切换必须经过disabled中间态controller-manager → disabled → standalone standalone → disabled → controller-manager进入disabled后运维人员必须确认旧控制器已停止才能启用目标部署模式。切换期间既有 HyperNode 资源保留在集群中当前实现不支持一步切换 零重叠保证。另外在standalone/disabled模式下不要再通过custom.controller_enabled_controllers显式启用hyperNode-controller相互冲突的控制器门控是不受支持的。5. 独立组件在集群中到底部署了什么standalone模式下hypernode_controller.yaml 会渲染出以下资源名称均以 Helm release 名为前缀ServiceAccountrelease-hypernode-controllerClusterRole/ClusterRoleBindingnodeslist、watch—— 读取拓扑标签、计算每个 HyperNode 覆盖的节点数topology.volcano.sh/hypernodesget、list、watch、create、update、deletehypernodes/statusupdate—— 维护拓扑资源及其状态。Role/RoleBinding安装命名空间内configmapslist、watch。注释解释了原因部分 Kubernetes 版本的 RBAC 授权不感知 field selector无法对 list/watch 匹配resourceNames因此命名空间级授予 ConfigMap list/watch而客户端请求本身通过metadata.namefield selector 限定为仅监听本 release 的控制器 ConfigMapsecretsget—— 仅在发现配置引用时按名读取 UFM 凭据不做集群级 Secret 授权eventscreate、patch、update—— leader 选举事件coordination.k8s.io/leases全命名空间create外加对{{ .Release.Name }}-hypernode-controller-manager这个具体 Lease 的get、update—— 为独立控制器提供高可用。Deployment镜像为volcanosh/vc-hypernode-controller-managerbasic.hypernode_controller_image_name可被basic.hypernode_controller_image_tag_version单独指定 tag容器名hypernode-controller-manager关键启动参数模板第 151-163 行args: - --logtostderr - --enable-healthztrue - --enable-metricstrue # 由 custom.hypernode_controller_metrics_enable 控制 - --leader-electtrue - --leader-elect-resource-namespacerelease 命名空间 - --leader-elect-resource-namerelease-hypernode-controller-manager - --kube-api-qpscustom.hypernode_controller_kube_api_qps # 默认 50 - --kube-api-burstcustom.hypernode_controller_kube_api_burst # 默认 100 - -vcustom.hypernode_controller_log_level # 默认 4 - 21探针配置/healthz作为 liveness11251 端口/readyz作为 readiness这与 server.go 中缓存同步成功后才 ready的processReady逻辑对应。Deployment 的调度类为system-cluster-criticalaffinity/tolerations/securityContext/nodeSelector/labels/resources 均提供custom.hypernode_controller_*覆盖项。Servicecustom.hypernode_controller_metrics_enable为 true 时release-hypernode-controller-service带prometheus.io/*注解把 8081 的/metrics暴露给 Prometheus 抓取。对照设计文档中的资源访问边界表实现完全一致资源访问用途NodeList/Watch读取拓扑标签计算每个 HyperNode 代表的节点数HyperNodeGet/List/Watch 调和写维护拓扑资源及其状态控制器 ConfigMap通过metadata.namefield selector 监听本安装的配置对象加载与更新拓扑发现配置UFM Secret仅在引用时按名 Get不 Watch获取外部发现系统凭据Leader-election Lease选举所需的 Get/Create/Update独立控制器的 Leader 选举与故障转移边界要求还包括standalone 进程不得watch Pod、PodGroup、Volcano Job、Queue、存储资源等任何与 HyperNode 无关的资源Discoverer 必须复用进程提供的 Node/HyperNode 共享 informer而不是自建重复的 List/Watch 流与缓存RBAC 与该访问面一一对应。默认 RBAC 不授予集群级 Secret 访问——默认只授权安装命名空间如果 UFM Secret 在别的命名空间管理员需在该命名空间为 standalone 的 ServiceAccount 创建 Role 与 RoleBinding。6. 拓扑发现配置两种模式同一份 ConfigMapstandalone 控制器与vc-controller-manager共用同一个控制器 ConfigMap 加载发现配置Helm 侧可通过custom.controller_config_override或直接在集群中维护 ConfigMap参考 How to Use HyperNode Auto Discovery。api/example.yaml 给出了官方示例配置展示了ufm、roce、label三类发现源networkTopologyDiscovery: - source: ufm enabled: true interval: 10m credentials: secretRef: name: ufm-credentials namespace: volcano-system config: endpoint: https://ufm-server:8080 insecureSkipVerify: true - source: roce enabled: false interval: 15m config: endpoint: https://roce-server:9090 token: token - source: label enabled: true config: networkTopologyTypes: topologyA2: - nodeLabel: volcano.sh/tor - nodeLabel: kubernetes.io/hostname topologyA3: - nodeLabel: volcano.sh/hypercluster - nodeLabel: volcano.sh/hypernode - nodeLabel: kubernetes.io/hostname其中source: label是 Label Discoverer按节点标签的层级组合构建拓扑类型source: ufm则通过 UFM 凭据向外部发现系统拉取拓扑。关于行为一致性承诺设计文档特别提到一个由独立模式暴露出来的既有缺陷ConfigMap 驱动的热重载路径中已退役 Discoverer 实例的结果可能与或被确认给其替代实例产生重叠。因此管理器的生命周期在两种模式下都做了加固——manager.go 中每个 source 绑定独立的processorStopCh/processorDone通道resultAcknowledgement保证热重载等待产生方的确认回调结束后才停止并替换该实例见 manager.go 第 48-65 行。这一加固不改变 HyperNode API、发现配置、稳态调和谐义或旧版基于 client 的 Discoverer 注册契约。7. 安装与迁移操作7.1 全新安装只装拓扑能力的集群前置条件一个 Kubernetes 集群、Helm 3、创建 CRD 与集群级 RBAC 资源的权限、以及支持custom.hypernode_controller_mode的 Volcano chart 版本。仅安装 standalone HyperNode 控制器同时关掉控制器管理器、调度器与 webhookhelm install volcano volcano-sh/volcano \ --namespace volcano-system \ --create-namespace \ --set custom.hypernode_controller_modestandalone \ --set custom.controller_enablefalse \ --set custom.scheduler_enablefalse \ --set custom.admission_enablefalse从源码 checkout 安装时把仓库地址换成./installer/helm/chart/volcano。等价于如下 values 文件custom: hypernode_controller_mode: standalone controller_enable: false scheduler_enable: false admission_enable: falseHelm 值作用custom.hypernode_controller_modestandalone由 standalone 控制器运行 HyperNode 调和custom.controller_enablefalse不安装vc-controller-managercustom.scheduler_enablefalse不安装vc-schedulercustom.admission_enablefalse不安装vc-webhook-manager验证安装kubectl rollout status deployment/volcano-hypernode-controller \ --namespace volcano-system kubectl get deployments --namespace volcano-system kubectl logs --namespace volcano-system \ deployment/volcano-hypernode-controller \ --container hypernode-controller-manager kubectl get hypernodes默认 release 名与上述 values 下volcano-hypernode-controller是集群中唯一的 Volcano 控制面 Deployment若指定了其他 release 名所有资源名会换用该 release 名前缀。7.2 存量集群迁移经 disabled 的两步切换从vc-controller-manager切换到 standalone 控制器时第一步先禁用 HyperNode 调和并等待控制器管理器完成滚动helm upgrade volcano volcano-sh/volcano \ --namespace volcano-system \ --reuse-values \ --set custom.hypernode_controller_modedisabled kubectl rollout status deployment/volcano-controllers \ --namespace volcano-system第二步再启用 standalone 控制器。若只想转移 HyperNode 归属仅改custom.hypernode_controller_mode即可若要顺带把整个安装转为纯拓扑部署同时关闭控制器管理器、调度器与 webhookhelm upgrade volcano volcano-sh/volcano \ --namespace volcano-system \ --reuse-values \ --set custom.hypernode_controller_modestandalone \ --set custom.controller_enablefalse \ --set custom.scheduler_enablefalse \ --set custom.admission_enablefalse反向迁移同理standalone → disabled → controller-manager。中间disabled态的作用就是防止内嵌与独立两个控制器同时调和 HyperNode 资源。8. 风险与成功标准设计文档列出了主要风险及缓解手段风险缓解独立组件扩大社区维护与发布面两种模式复用同一实现、测试套件与 Volcano 发布流水线聚合与独立进程可能同时调和 HyperNode部署模式互斥 文档化的两步切换流程经disabled中间态两种模式行为可能漂移把行为一致性作为兼容性承诺与发布校验要求独立运行时装配引入无关/重复资源 watch按需初始化 informer、要求 Discoverer 复用共享 informer并通过 RBAC 与测试强制边界用户把独立控制器误解为独立产品源码、版本、发布、治理明确留在 Volcano 之内成功标准可以概括为现有用户升级后 HyperNode 运行方式零变化standalone 与自定义调度器用户能部署官方生产级组件两种模式行为等价安装与切换流程杜绝双调和standalone 进程不 watch 无关资源、不创建重复的 Node/HyperNode informer独立组件随 Volcano 构建、测试、安全扫描并发布HyperNode 控制器不再依赖pkg/scheduler/api或无关控制器的实现包。实现验证需覆盖二进制/镜像构建、行为一致性、所有权转移、informer 复用与 watch 范围、高可用、RBAC、升级兼容与基于 API 的集成测试。9. 小结HyperNode 独立控制器是 Volcano 对拓扑发现独立于调度策略这一趋势的官方回应通过新增 cmd/hypernode-controller-manager 入口、vc-hypernode-controller-manager镜像与一套 Helm 三态开关用户获得了完整的独立部署、故障域与最小权限 RBAC 边界而不必面对第二份实现、第二套兼容性契约或第二个维护生命周期。对已有 Volcano 用户这完全是一个无感升级对只需拓扑能力的用户这第一次成为官方支持的用法。参考资料设计提案HyperNode Controller Standalone Deployment安装指南Install the Standalone HyperNode Controller拓扑发现配置How to Use HyperNode Auto Discovery网络拓扑感知调度Network Topology Aware SchedulingHyperNode 控制器实现pkg/controllers/hypernode发现配置示例api/example.yamlHelm 模板hypernode_controller.yaml、controllers.yaml、values.yaml【免费下载链接】volcanoA Cloud Native Batch System (Project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/vol/volcano创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考