意琦行的个人博客

最近，KubeClipper 正式发布了 1.5.0 版本。这次更新带来了多项重要改进，其中最引人注目的是新增的工作负载管理界面，用户现在可以直接在 Web UI 中管理 Deployment、StatefulSet 等 Kubernetes 工作负载。同时，该版本还升级了对 Kubernetes 及其组件的支持，并修复了大量 bug，提升了平台的稳定性和用户体验。

KubeClipper 是一个轻量便捷的 Kubernetes 多集群全生命周期管理工具，旨在提供易使用、易运维、极轻量、生产级的 Kubernetes 多集群管理服务，让运维工程师从繁复的配置和晦涩的命令行中解放出来，实现一站式管理跨区域、跨基础设施的多 K8S 集群。

🚀 5分钟快速体验

如果你是第一次接触 KubeClipper，可以通过以下步骤快速上手：

1. 一键安装工具：curl -sfL https://oss.kubeclipper.io/get-kubeclipper.sh | KC_REGION=cn bash -
2. 部署服务：kcctl deploy
3. 创建集群：kcctl create cluster --name demo --master YOUR_IP --untaint-master
4. 访问界面：浏览器访问 http://YOUR_IP:8080，账号 admin/Thinkbig1

全程只需5-10分钟，就能拥有一个功能完整的 Kubernetes 环境！

在 Kubernetes 里做“数据复制”通常有两条路：

• PVC Clone：从已有 PVC 快速克隆出一个新 PVC（开发/测试回放、批量创建环境很常用）
• VolumeSnapshot：先对 PVC 打快照，再从快照创建新 PVC（更贴近生产最佳实践，避免“边写边克隆”的不确定性）

本文以 csi-driver-nfs 为例，从 0 跑通 Clone 与 Snapshot，并给出跨命名空间场景需要的关键配置与排错点。

想象一下这样的场景：你的生产系统突然流量激增，某个 Pod 的 CPU 使用率已经飙升到 90%，传统做法是重建整个 Pod，导致服务中断 30 秒以上。而现在，只需一行命令，CPU 资源瞬间调整完毕，服务零中断！

这就是 Kubernetes 1.35 带来的重磅功能：原地 Pod 资源调整（In-Place Pod Resize）正式 GA！🎉

NVIDIA GB200 NVL72 正在将 AI 基础设施推向新的极限，使大规模语言模型训练和低延迟推理工作负载成为可能。随着 Kubernetes 在部署和扩展这些工作负载中的核心作用日益增强，快速演进的 AI 工作负载、基础设施需求和新硬件架构为 Kubernetes 编排和资源管理带来了新的挑战。

在本文中，我们将深入探讨如何通过 Kubernetes DRA (Dynamic Resource Allocation) 和 NVIDIA DRA Driver 在 GB200 平台上启用 Multi-Node NVLink (MNNVL)，实现跨节点的 GPU 到 GPU 高带宽通信。

在上一篇 告别 TCP/IP 延迟：Kubernetes 中的 RDMA 高性能网络实战 中，我们介绍了如何在 Kubernetes 中启用 RDMA（InfiniBand）能力，实现了相比 TCP/IP 延迟降低 20-40 倍、带宽提升 40 倍以上的效果。然而在超大规模 AI 训练场景下，即便是 InfiniBand 的带宽也可能成为瓶颈——当 GPU 间需要频繁同步梯度时，跨节点通信效率直接决定了整体训练吞吐。那么，有没有比 InfiniBand 更高效的多节点互联方案？答案是 MNNVL（Multi-Node NVLink）。

GPU 算力拉满了，网络却成了瓶颈？在大模型训练和推理场景中，传统 TCP/IP 网络的延迟和 CPU 开销正在严重制约集群性能。RDMA 技术通过绕过内核直接访问内存，降低网络延迟。本文将手把手教你在 Kubernetes 中启用 RDMA 能力，从 Device Plugin 部署到性能验证，让你的 AI 集群真正发挥出硬件的全部潜力。