NVKE 如何管理裸金属 GPU 集群？

NVKE 为裸金属 GPU Kubernetes 提供集中式管理平面，统一处理节点初始化、集群配置、节点接入和生命周期运维。它不是一套新的 GPU 调度器，也不替代 NVIDIA 驱动、容器运行时或 Kubernetes 调度器。

NVKE 近期进入 GitHub 趋势榜，仓库将其定位为“面向裸金属 GPU Kubernetes 的管理平面”。它受到关注，与裸金属 AI 基础设施从依赖脚本和人工经验转向可重复交付、集中协调和持续运维的工程化模式有关。本文重点回答三个问题：NVKE 到底管理什么，裸金属节点怎样接入并变成可调度的 GPU 集群，以及生产环境如何定位故障、扩容和升级。

NVKE 的管理平面边界在哪里？

从仓库公开的架构、接口和部署组织方式看，NVKE 的管理链路可分为四层：管理入口负责接收目标集群和节点的期望配置；控制与状态协调层负责持续比较期望状态与实际状态，并推进集群生命周期；节点侧执行部分负责初始化、配置、接入和状态上报；最终交付的是仍遵循 Kubernetes API、控制器和调度机制的受管集群。

Kubernetes 本身提供可扩展、声明式和可移植的工作负载管理能力，NVKE 沿用这些机制，没有另建一套面向 AI 工作负载的 API[4]。因此，NVKE 管理的是“如何形成并持续运行一个 GPU Kubernetes 集群”，容器管理仍由 Kubernetes 承担。

各组件的职责边界如下：

标准的 GPU 调度链路通常是：工作节点运行 NVIDIA Device Plugin，插件向 kubelet 注册 nvidia.com/gpu，kube-scheduler 再依据扩展资源进行分配。NVKE 可以负责编排这条链路的安装、接入和持续检查，但不会改变 Device Plugin 的基本职责。

进入 GitHub 趋势榜代表开发者关注度上升，却不能证明其 API、升级机制或高可用方案已经经过长期生产验证。尤其不能因为 NVKE 已经部署，就默认 MIG、时间切片、拓扑调度和监控都已启用；这些能力分别取决于设备模式、节点插件、标签生产链路、调度器以及监控组件是否真正配置到位。

从裸金属到 GPU 可调度，部署链路如何落地？

裸金属 GPU 集群的前置条件比普通 Kubernetes 节点更多。至少需要检查以下几类事项：

• GPU 硬件、主板和 PCIe 拓扑，以及与目标节点操作系统匹配的 NVIDIA 驱动。
• 节点访问方式，包括仓库部署清单要求的认证信息和密钥。
• 管理平面到工作节点、镜像仓库、DNS 和时间同步服务的网络。
• 节点 kubelet、容器运行时、CNI、集群 CA 以及节点加入所需的证书材料。
• 容器镜像仓库地址、认证信息和私有仓库 CA。
• NVKE 自身配置、凭据以及部署清单要求的后端或持久化目录。

通用 GPU 接入教程通常把 NVIDIA 驱动、CUDA、nvidia-docker 2、k8s-device-plugin 和 GPU 计算容器验证串成一条链路。这条链路有助于理解 GPU 数据面，但其中的 PPA、镜像版本和软件包名称都依赖具体环境，不能直接改写成 NVKE 官方安装命令。实际部署应分别确认宿主机驱动、容器运行时和容器内 CUDA Runtime 的兼容关系；宿主机安装了某个 CUDA Toolkit 版本，也不意味着容器镜像中的 CUDA Runtime 必然与其一致。

部署时应先固定版本，不直接执行仓库主分支的清单：

git clone https://github.com/dsx-ai-factory/nvke.git
cd nvke
git checkout <release-tag>

选定 release 后，应使用该版本 README 和部署清单所定义的方式安装管理平面。管理平面适合部署在与 GPU worker 分离的管理环境中，并应先完成配置、认证 Secret、外部后端或持久化目录等依赖。随后检查管理服务是否正常启动、控制组件是否持续完成状态协调，以及节点侧执行组件能否连接管理入口。这里应依据该版本公开的健康检查方式和日志进行判断，不要依赖某个未经保证的固定端口或内部服务名。

第二步是声明目标集群和节点。需要明确节点地址、控制面或 worker 角色、GPU 型号、网络配置、认证信息以及节点加入顺序。裸金属节点通常先完成系统初始化和远程连接，再下发集群配置、证书和网络参数，最后加入 Kubernetes。单节点验证阶段可以先打通完整链路；扩展到多节点时，则需要额外验证管理平面到所有节点的连通性、正反向 DNS、时间同步、镜像仓库访问和证书信任。

第三步才是 GPU 资源注册。每个符合条件的 worker 都需要能够运行 NVIDIA 容器运行时和 Device Plugin。宿主机上的 nvidia-smi 正常，只能证明驱动和 GPU 本身可见；只有 Device Plugin 成功向 kubelet 注册资源后，调度器才能感知 GPU 数量：

kubectl get nodes -o wide
kubectl get nodes -o json | jq -r '.items[] | [.metadata.name, (.status.allocatable["nvidia.com/gpu"] // "0")] | @tsv'
kubectl -n kube-system get pods -o wide | grep nvidia-device-plugin
kubectl get events -A --sort-by=.lastTimestamp

如果节点可分配资源中没有 nvidia.com/gpu，应先检查宿主机驱动、容器运行时和 Device Plugin，而不是反复重建业务 Pod。插件正常但资源数量与物理卡数不一致时，再检查设备可见性、MIG 配置以及插件实际采用的资源模型。

第四步是提交实际 GPU 工作负载。下面的清单用于验证请求资源、调度、镜像启动和 GPU 枚举链路；镜像 tag 只是示例，生产环境应按驱动与 CUDA 兼容矩阵选择：

apiVersion: v1
kind: Pod
metadata:
  name: gpu-check
spec:
  restartPolicy: Never
  containers:
    - name: gpu-check
      image: nvcr.io/nvidia/cuda:12.0-base
      command: ["nvidia-smi"]
    resources:
      limits:
        nvidia.com/gpu: 1

kubectl apply -f gpu-check.yaml
kubectl get pod gpu-check -o wide
kubectl logs gpu-check
kubectl describe pod gpu-check

验收不应止于 Pod 变成 Running。日志中的 nvidia-smi 需要正常枚举 GPU，Pod 事件中不应出现调度或挂载异常。多节点环境还应提交多个单 GPU Pod，确认它们能够落到预期节点；随后模拟节点故障，检查工作负载是否迁移，以及不可调度节点是否会持续占用容量。

任何环节失败，都应在对应层级排查：管理入口不可用时检查管理平面；节点执行组件未就绪时检查配置分发、认证和时钟；节点 NotReady 时检查 kubelet、CNI 和证书；GPU 资源为零时检查驱动、运行时和 Device Plugin；Pod Pending 时检查资源数量、污点、亲和性、配额和持久卷卷；镜像启动后再检查 CUDA 与驱动兼容性。这样可以避免把所有问题都归因于 GPU。

上线后如何观测、排障与扩容？

生产环境应按“管理平面状态—Kubernetes 节点—GPU 设备—工作负载”四级顺序定位问题。第一，管理平面关注进程健康、控制循环、状态后端连接和节点上报；第二，Kubernetes 层关注 Node 条件、kubelet、CNI 和事件；第三，GPU 层关注宿主机 nvidia-smi、Device Plugin 日志和设备模式；第四，工作负载层关注调度事件、镜像启动、容器日志和实际 CUDA 输出。DCGM Exporter 可以补充设备指标，但它位于观测链路中，不参与控制决策。

常见症状可以按下面的顺序处理：

资源运营也不能只看 GPU 利用率。物理卡数、已分配资源、实际利用率和空闲容量是四个不同指标。一个节点可能已经分配了全部 GPU，却只运行了少量任务；另一组空闲卡可能因型号、显存或拓扑不匹配而无法满足工作负载。因此，容量表至少应记录节点、物理 GPU、插件暴露的可分配资源、已分配量、实际使用量、型号及拓扑标签。

整卡、MIG 和时间切片需要分别核验。整卡场景直接检查 nvidia.com/gpu 数量；MIG 场景应同时检查设备模式、MIG profile、插件配置和资源名称，必要时在节点执行：

nvidia-smi mig -lg

时间切片则需要核对 Device Plugin 的相应配置；配置后的可分配份额可能多于物理卡数，因此资源计数本身不能代替并发和性能验证。拓扑调度还要确认 GPU Feature Discovery 已生成 nvidia.com/gpu.product、nvidia.com/gpu.memory、nvidia.com/gpu.topology 等标签，并确认实际使用的调度器会消费这些标签。对于需要队列、优先级，或需要面向数千节点进行拓扑调度的环境，KAI Scheduler 可作为独立方案评估，不应把它列进 NVKE 的默认能力清单。

租户隔离通常仍要借助 Kubernetes 的 ResourceQuota、LimitRange、命名空间和 RBAC。NVKE 可以改善集群交付和节点生命周期管理，但不能据此认为它已经提供细粒度租户计费或配额系统。生产环境还要准备节点维护流程：

kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets

排空前应确认守护进程和工作负载重建策略，并评估本地数据风险。节点重启后，还要检查驱动、容器运行时、Device Plugin 和 GPU 资源是否重新注册，而不是只看 Kubernetes Node 恢复为 Ready。

升级应建立完整版本矩阵，至少覆盖 NVKE、Kubernetes、GPU Operator、Device Plugin、容器运行时和 CNI。升级前备份管理配置、渲染后的部署清单、集群状态以及密钥和证书；随后在测试或小规模集群验证兼容性，再分批推进。控制面与工作节点的升级顺序必须遵循所选版本支持的范围，不能把普通应用的回滚思路直接套到集群组件上。尤其是涉及状态迁移、证书轮换和节点重新加入时，回滚成本远高于一次 Pod rollout。

NVKE 不替代 Kubernetes、Device Plugin 或 NVIDIA GPU Operator，它试图把裸金属 GPU 集群从一组一次性脚本变成可持续运营的集群交付过程。我的判断是：对于拥有同构裸金属 GPU 节点、又没有成熟自研管理平台的技术团队，NVKE 值得进入试点和二次开发评估；但在接口稳定性、高可用、状态备份和跨版本升级回滚获得更多生产验证之前，它更适合作为可替换的管理层，不宜作为唯一的容灾底座。