AI 集群中的 Kubernetes 节点应该怎样规划，计算节点、管理节点和存储节点如何分工

AI 集群里的 Kubernetes 节点怎么规划，并不是简单地把机器分成“计算节点、管理节点、存储节点”三个盒子。真正需要考虑的是 GPU 拓扑、CPU 与内存比例、网络带宽、存储访问模式、控制平面稳定性，以及训练和推理任务到底需要什么样的资源。节点角色划分得合理，可以减少资源争抢和故障传播；划分得过度，又可能增加硬件成本和运维复杂度。

计算节点是 AI 集群真正消耗算力的地方。训练节点通常配置 NVIDIA H100、H200、A100 或其他加速器，也可能采用 AMD Instinct 等不同 GPU 架构。这里首先要注意一个容易被忽略的问题：GPU 并不是“插上去越多越好”。多 GPU 训练时，GPU 之间的互联拓扑直接影响 AllReduce、AllGather 等通信操作。如果节点内部具有 NVLink、NVSwitch 等高速互联，多卡之间的数据交换通常可以获得比普通 PCIe 路径更好的性能。

因此，大规模训练节点规划时，应该先看 GPU 到 GPU、GPU 到 NIC、GPU 到 CPU 的实际拓扑，而不是单纯比较 GPU 型号。可以通过 nvidia-smi topo -m 等工具检查 PCIe、NVLink 和 NIC 的关系，再结合 NCCL 通信测试验证实际带宽。不同 GPU 架构可以共存，但是否应该放进同一个训练任务，需要根据框架、算子、精度支持和通信能力验证，而不是简单地认为“异构 GPU 一定会产生数据迁移损耗”。

跨节点训练还需要高速网络。100GbE、200GbE、400GbE 甚至更高速率都可能出现在不同规模的 AI 集群中，但没有一个固定带宽适合所有部署。RDMA 是否值得采用，也取决于训练规模和通信模式。对于大规模分布式训练，InfiniBand 或 RoCE 配合 NVIDIA GPUDirect RDMA 可以显著降低通信路径中的 CPU 数据搬运；普通推理集群则未必需要这么复杂的网络。

Kubernetes 网络插件例如 Cilium 或 Calico主要解决的是 Pod 网络、策略和集群通信管理，并不能简单等同于 AI 训练网络本身。大规模 GPU 集群往往需要把 Kubernetes 网络、节点管理网络、存储网络和高速训练网络分别考虑，甚至使用独立网络接口和交换网络，避免控制流量、存储 I/O 和 GPU 集体通信相互争抢。

管理节点，也就是 Kubernetes 控制平面，承担的是集群的大脑角色。典型组件包括 kube-apiserver、etcd、scheduler 和 controller-manager。生产环境通常采用多个控制平面节点实现高可用，etcd 使用 Raft 保证集群状态的一致性。三个节点是常见的起点，但并不是任何集群都必须固定使用三个；真正需要考虑的是故障容忍能力、etcd 性能、节点规模以及维护策略。

控制平面最重要的并不是追求“多核越多越好”，而是保证 API Server、etcd 和调度系统在高并发操作下保持稳定。大量 Pod 创建、删除、扩缩容、Job 提交以及控制器事件都会增加 API Server 和 etcd 的压力。AI 集群尤其容易出现一次提交数百甚至数千个 Pod 的情况，因此控制平面的 CPU、内存、磁盘延迟和网络都需要监控。

存储节点则不能简单理解成“给计算节点提供一个大硬盘”。AI 工作负载通常同时存在模型文件、训练数据、checkpoint、日志、容器镜像和临时数据，而且不同数据对性能的要求完全不同。

训练数据和模型通常适合放在对象存储或高吞吐共享文件系统中；需要随机读写和较低延迟的场景可以采用 NVMe、本地 SSD 或分布式块存储。Ceph 可以同时提供 RBD、CephFS 和对象存储能力，但部署复杂度也明显高于单纯使用本地 NVMe。NFS 对某些共享文件场景非常方便，但不能因为使用 NFSv4.1 就认为它天然适合高规模 GPU 训练。

如果训练节点采用 GPUDirect Storage，需要重点检查 GPU、驱动、文件系统、存储设备以及整个 I/O 路径是否真正支持该技术。它的价值在于减少数据从存储到 GPU 过程中不必要的 CPU 内存拷贝，但这并不意味着“只要上 NVMe-oF 就一定获得 GPUDirect Storage”。NVMe-oF 是一种存储访问协议和架构，GPUDirect Storage 则涉及完整的软件和硬件 I/O 路径，两者不能直接画等号。

对于 checkpoint，更应该关注恢复速度和可靠性。训练任务可能运行数小时甚至数天，如果 checkpoint 只保存在 Pod 的临时文件系统里，节点故障后就可能丢失。因此通常需要把 checkpoint 写入持久化存储或对象存储，并根据训练任务设置合理的保存周期。Kubernetes 负责管理 Pod 和资源生命周期，但“训练从哪里继续”属于 AI 应用本身的状态管理问题。

节点规划还有一个非常重要的原则，就是不要把所有服务都塞进 GPU 计算节点。监控、日志、Ingress、CI/CD、镜像仓库、数据库以及各种控制服务，如果和大型训练任务争夺 CPU、内存、磁盘和网络资源，很容易导致 GPU 节点出现大量非 GPU 工作负载。可以通过 taint、toleration、nodeSelector、node affinity 和专用 node pool，把不同工作负载隔离开来。

对于 GPU 资源，则可以使用 NVIDIA GPU Operator、Device Plugin 等机制向 Kubernetes 暴露 GPU，并通过资源请求和调度策略管理 GPU。更复杂的训练任务还需要考虑 MIG、GPU 拓扑、NUMA、CPU pinning、HugePages 以及 RDMA 设备等因素。

最后要特别纠正一个常见思路：不能规定“GPU 利用率低于75%就自动迁移训练任务”。GPU 利用率低可能来自数据加载、通信等待、checkpoint、CPU 瓶颈、I/O 瓶颈甚至模型本身的计算特征。直接迁移正在运行的训练任务通常也不是 Kubernetes 能够无损完成的普通操作。更合理的方式，是通过训练框架、Job 调度器、checkpoint 和队列系统进行任务级调度，让新的任务进入空闲 GPU，而不是看到利用率下降就强行搬家。

因此，一个成熟的 AI Kubernetes 集群通常不是简单的“三类节点”，而是根据实际规模进一步形成控制平面、GPU 计算池、CPU 工作节点、高速存储节点、对象存储以及网络和监控基础设施。核心原则可以概括为：GPU 看拓扑，训练看通信，存储看 I/O，控制平面看稳定性，调度看工作负载。

Kubernetes 解决的是资源编排和生命周期管理，而不是自动解决 AI 集群中的所有性能问题。真正决定集群效率的，往往是 GPU、CPU、内存、NIC、PCIe、NVLink、存储和软件栈之间有没有形成一条完整而合理的数据路径。节点划分只是第一步，真正专业的 AI 基础设施设计，最终必须回到实际 workload 的 profiling、通信测试和 I/O 测试上。