英伟达开放自有 GPU 集群管理平面

在自己的 NVIDIA GPU 机器上提供托管 Kubernetes，难点不只是把集群装起来，还要持续处理租户隔离、节点扩缩、升级和身份校验。NVKE 想提供的，就是平台团队可以自行部署的集群管理系统：你维护管理平台，客户通过 Kubernetes API 和 kubectl 使用各自的集群。

不过，这个项目目前处于 Preview，原文明示不建议承载生产负载。它值得关注的地方是集群工厂的设计；评估时最该看的，则是默认安全配置和管理平台自身的运维缺口。

它管理的是一批独立集群

NVKE 不是 Kubernetes 发行版，原文也明确说它不是一种 Cluster API flavour。它定位为能够自托管的集群工厂：先建立管理集群，再由管理平面按需创建、维护多个工作负载集群。

这里有两类集群。管理集群运行 NVKE 管理平面和基础设施控制器；工作负载集群运行客户应用，每个都有自己的 Kubernetes 控制平面、etcd 和节点池。因此，原文所说的独立集群，不能理解成在同一个集群里给客户划分几个 Namespace。

启动过程也有两步：nvkectl 借助一个临时种子集群建立管理集群，管理平面服务随后单独安装。平台建好以后，客户通过 NVKE API 或 nvkectl 请求集群，NVKE 再协调基础设施和节点，把机器组织成可用的 Kubernetes 集群。

NVKE 提供的是集群供给与生命周期管理能力，底层资源仍由平台团队准备。

真实安装需要自行提供机器、网络、节点镜像和镜像仓库，还要配置 NVIDIA Infra Controller（NICo）访问。Preview 阶段，NICo 是唯一兼容的基础设施提供方，不能据此推断它已经支持任意云厂商或裸金属管理系统。

从镜像到节点，职责怎么分

NVKE 产品家族把构建与部署拆开了。配套项目 NVIDIA Kubernetes Recipes（NVKR）根据固定输入构建节点镜像和 NVKE 组件，负责构建、发布证据，并签名、发布产物；NVKE 负责部署这些产物。

固定输入有助于追溯构建来源，但原文没有给出构建复现率、漏洞修复速度等数据，不能进一步推导出它已经解决了全部供应链问题。

运行时，管理平面通过 CAPNICo 调用 NICo，由 NICo 使用节点 OS 镜像准备 GPU 机器。机器成为工作负载集群的 Kubernetes 节点后，每台节点运行 nvke-agent，参与后续管理。AICR 产生的加速运行时，以及工作负载集群中的 NVKE observability，属于可选组件。

节点加入集群之前，还要通过 TPM，结合 SPIFFE/SPIRE 完成身份认证，再领取加入集群的凭据。可以把它理解成：节点先证明自己的身份，管理系统才交出入场凭证。每个集群也可以启用 etcd 数据加密。

这些机制分别处理不同问题。节点身份认证不等于 API 调用者认证，etcd 加密也不能当成整台机器磁盘数据都已保密。

能运行演示，离持续运营还有多远

本地快速开始要求 Linux 主机或虚拟机，支持 amd64、arm64，至少具备 6 CPUs、12 GiB 空闲内存和 100 GiB 空闲磁盘，还需要 Docker、虚拟 TPM 支持及指南列出的工具。macOS 则按本地站点指南，在 Colima 虚拟机内评估。

演示的验收点不是命令执行完，而是成功创建工作负载集群，并确认节点报告 Ready。

如果从源码构建，要求使用 go.work 固定的 Go 1.27.3，以及 GNU Make 4 或更高版本；第一次构建需要能够访问公共 Go modules。Flox 可选，用于提供开发工具，在 macOS 上也可提供 GNU Make 4。

下面这段命令解决的是源码构建：

git clone https://github.com/dsx-ai-factory/nvke.git
cd nvke
make build

要看清最后一行 make build 的边界：它把 9 个二进制写入 bin/，不会启动管理平面，也不会创建集群。产物包括 agent、updater、controller、nvkectl、capd-reboot-controller、nvke-os-image-check、management-engine、tenant-api 和 operator-api；其中节点 agent 运行在 Linux 上。提交修改前还需要运行 make preflight，它会根据变更模块选择检查项。

更影响评估结论的是 Preview 限制。安装后，API 认证默认关闭，API 使用明文 HTTP，接入调用者之前必须配置认证和受保护的访问方式。

管理集群也不会自行升级、扩缩或替换自身节点，目前没有管理平面升级以及备份恢复流程。工作负载节点池虽然支持创建、扩缩、删除、Kubernetes 升级和节点替换，但仍有手动步骤与 Preview 限制，不能只凭功能列表判断自动化程度。

另外，原文明示 FDE 节点镜像仅供评估，不提供静态数据机密性。看到全盘加密相关名称，也不能跳过这条限制。

我的判断

我认为最有价值的是它把责任边界摆得比较清楚：NVKR 管构建，NICo 管基础设施供给，NVKE 管集群生命周期，客户继续使用熟悉的 Kubernetes 接口。对于确实要在自有 GPU 基础设施上向客户交付独立集群的平台团队，这个划分有参考价值。

但「自托管」也把管理平台的持续运营责任交给了使用者。当前缺少管理平面升级、备份恢复流程，比能否快速创建第一个集群更影响长期使用判断。

与在共享集群里划分 Namespace 相比，独立控制平面和 etcd 增加了隔离边界，也带来了更多待维护组件。原文没有提供租户规模、故障恢复时间、资源开销或运维成本对照，不能据此认定这种方式对所有团队都更划算。

它也不是一篇性能实验报告。原文描述了架构、能力和操作要求，没有给出 GPU 性能提升或大规模稳定性数据。对于只需要部署前端、Node 服务或普通 AI 应用的团队，现有信息不足以支持为了这些需求专门引入 NVKE。

能拿来做什么

• 如果正在评估自有 GPU 平台，先按快速开始完整跑到工作负载节点 Ready，并记录机器、网络、镜像仓库和 NICo 各自需要哪些配置。
• 如果要编写内部集群申请页面或调用脚本，先确认 NVKE API 的认证与访问保护方案；Preview 的 API、配置和行为都可能跨版本变化，接入时需要明确版本边界。
• 如果正在设计多租户平台，可以借用它对管理集群、工作负载集群、构建系统的职责划分，再按实际隔离需求比较独立集群与共享集群的运维成本。
• 如果计划参与开发，使用固定的 Go 1.27.3 和 GNU Make 4+，先完成构建，再按本地开发指南启动环境，提交前执行 make preflight。