Jimmy Song – AI 基础设施：从单卡到集群平台

上手篇：从零到第一块可调度的 GPU

Jimmy Song — Mon, 14 Sep 2026 00:00:00 +0000

本部分是全书的高速入口，目标是回答一个问题：如何在一个下午之内，让一块 GPU 从“云控制台里的一个选项”变成“Kubernetes 里一行可调度的资源请求”。

每一章都是一块垫脚石，踩在一个真实痛点上：

准备 GPU 运行环境 讲清驱动与 CUDA 的版本规则——GPU 环境里一半的故障来自“驱动、工具链、镜像各说各话”，这一章给你统一的判断框架与验证命令。
云上第一台 GPU 机器 解决“去哪里拿卡”：按用途选卡、看懂计费模型、设置止损线，并用一台竞价实例走完开机到彻底清理的全流程。
用 Docker 运行 GPU 工作负载 跨过第一道真正的工程门槛：GPU 容器不是普通容器加一个参数，理解设备注入机制后，你才能读懂后面所有 Kubernetes 方案在做什么。
单机 Kubernetes 与 GPU Operator 把前面三步收束成平台形态：nvidia.com/gpu: 1 出现在节点可分配资源里，GPU 从“机器的部件”变成“集群的资源”。

每章末尾的动手实验遵循统一格式（目标 → 前置条件与成本 → 步骤 → 验证清单 → 原理速览 → 清理），实验之间依次衔接：准备 GPU 运行环境里体检过的机器，在云上第一台 GPU 机器里开出来，用 Docker 运行 GPU 工作负载在它上面跑容器，单机 Kubernetes 与 GPU Operator再把容器升级成 Pod。全部跑通的总花费可以控制在几美元以内。

先动手，再补课

上手篇刻意压低了原理密度，只保留“动手必需”的最小解释。如果你在某个步骤停下来问“为什么是这样”，答案几乎都在认识机器与问题（硬件与设备模型）和GPU 软件栈与容器化（注入机制）两部分；而“怎么分卡、怎么治集群”的系统答案，在数据平面与控制面。

章节目录

准备 GPU 运行环境

草稿

理解 GPU 软件栈的分层与版本规则，学会用最少的命令验证一台 GPU 机器的健康状态，并掌握“容器时代宿主机只需要驱动”这一关键事实，为 GPU 容器与 Kubernetes 接入扫清环境障碍。

云上第一台 GPU 机器

草稿

按用途选对 GPU 机型、看懂三大云的实例形态与计费模型、设置预算告警与自动止损，并通过一台竞价实例走完从开机、验证到彻底清理的完整闭环。

用 Docker 运行 GPU 工作负载

草稿

理解 GPU 容器与普通容器的本质差别，安装配置 NVIDIA Container Toolkit，掌握 --gpus 语义与基础镜像选择，跑通第一个 GPU 容器并建立单卡性能的量级直觉。

单机 Kubernetes 与 GPU Operator

草稿

在单机 Kubernetes 上部署 GPU Operator，把上一章的 GPU 容器升级为可调度的 Pod：理解 device plugin 的上报链路，跑通第一个请求 nvidia.com/gpu 的 Pod，并诚实界定你此刻拥有与尚未拥有的平台能力。

认识机器与问题

Jimmy Song — Sat, 10 Jan 2026 10:45:50 +0000

本部分是一条精心设计的漏斗：从硅片到治理，每一章都在为下一章制造问题。

第一段：钻进机器。 先用GPU 基础认知建立“从硬件到 Kubernetes”的总图，并带上加速的经济学（为什么“再加点算力”不一定更快）；随后依次下钻：微架构与 Roofline 模型解释为什么“算力”和“带宽”是两条互不相同的屋顶线（这是推理容量、共享干扰的物理根因）；CUDA 执行模型讲软件如何驱动这块芯片，以及这一层的故障签名；显存管理引入第一个硬约束：显存绕过 cgroup、会碎片化、有每进程底噪，以及精度这份工程契约；世代、模块与产品语言教你把规格书读对：架构、产品、模块、平台、机架是五个不同的词；互连与集合通信把视野扩展到卡间与机器间，解释拓扑为什么决定调度上限；作为拓扑的服务器则回到机箱内部：NUMA、检查仪式与固件基线。

第二段：抬头看世界。 机器讲完，加速器全景打开生态视野：GPU 之外还有 NPU、TPU 与中国厂商的加速卡；Kubernetes 管理模型抽象出它们接入 K8s 的统一四步；设备资源抽象与演进则揭示这套抽象的表达力边界：整数计数、无拓扑、无配额。

第三段：问题与出路。 至此所有矛盾就位：多维资源形态撞上离散设备抽象。GPU 资源治理为什么难完成问题定义，硬切分与软切分给出解空间的一阶模型：隔离边界放在硬件里还是软件里。这个选择将贯穿数据平面与控制面两个部分；而应用触达机器的完整链路，见GPU 软件栈与容器化。

如果你有 Kubernetes 背景但没有 GPU 经验，钻进机器各章的数字请不要跳过，后面每一个共享机制、调度策略与监控口径，都是这些数字的直接推论。

章节目录

GPU 基础认知

草稿

为从未在生产中使用过 GPU 的读者建立可复用的心智模型，理解 GPU 的本质、显存与算力的差异、NVIDIA 数据中心 GPU 演进，以及从硬件到 Kubernetes 的端到端使用与调度路径。

GPU 微架构与 Roofline 模型

草稿

从 SM、warp、张量核与显存层级的真实数字出发，建立 Roofline 模型（屋顶线模型）的分析能力：为什么同一块 GPU 上大矩阵乘法接近满速、LLM 解码只有峰值算力的 0.3%，以及这对共享、选型与监控意味着什么。

CUDA 执行模型

草稿

平台工程师需要的那部分 CUDA：host/device 旅程、kernel/stream/CUDA Graph 的语义、内核启动开销如何塑造推理引擎设计，以及这一层的故障长什么样。

GPU 显存管理

草稿

显存完全绕过 cgroup，是 GPU 资源治理的第一约束。本章拆解显存分配路径、框架缓存分配器的行为（reserved vs allocated）、碎片型 OOM，以及把 CUDA OOM 与 OOMKilled 分开的两棵排查树。

世代、模块与产品语言

草稿

架构、产品、模块、平台、机架是五个不同层级的词；H100 不告诉你 PCIe 还是 SXM，NVL72 不是一块 GPU。一张世代地图、H100/Blackwell 的正确对比姿势、PCIe 与 SXM 的系统级差异，以及采购纪律。

互连与集合通信

草稿

NVLink/NVSwitch、PCIe 与 RDMA 的带宽层级；nvidia-smi topo -m 的读法；环形 AllReduce 的通信量数学；以及为什么张量并行必须留在同一台机器、跨 MIG 实例的并行是性能陷阱。

作为拓扑的服务器

草稿

一台服务器是一张图：CPU 插槽拥有内存通道，GPU 与网卡分属不同 NUMA 节点。去神话的 NUMA、一套必须保存为工件的检查仪式，以及为什么 BIOS 与固件也在故事里。

加速器全景与生态

草稿

从基础设施工程师的视角梳理异构加速器生态：先按设备类别（CPU、GPU、TPU、NPU、DPU、APU、LPU）建立认知，再按厂商阵营（通用 GPU、专用 AI 加速器、云厂商自研、垂直场景）评估版图，最后以 Kubernetes 集成成熟度贯穿选型。

加速器的 K8s 管理

草稿

抽象掉厂商差异，提炼所有 AI 加速器在 Kubernetes 中的统一管理模型（上报、调度、分配、隔离），并给出中国厂商加速卡的工程现实与超节点新变量。

K8s 设备资源模型

草稿

理解 Kubernetes 对 GPU 这类设备资源的表达能力与天然限制，并明确调度、分配与隔离的责任边界。

GPU 资源治理为什么难

草稿

定义 GPU 共享、隔离、治理的根因：显存、拓扑、干扰与尾延迟，以及训练与推理的资源形态差异。

硬切分与软切分

草稿

在进入具体技术之前，先建立加速器虚拟化的一阶模型：硬切分与软切分的定义、隔离边界、粒度、重配置成本与各自的典型实现。

GPU 软件栈与容器化

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

认识机器与问题讲清楚了 GPU 这台机器；本部分回答下一个问题：应用如何合法地触达这台机器。答案是一条由契约组成的链：Kubernetes 编排容器，容器运行时按 OCI 规范创建进程，而 GPU 是内核模块与用户态库的组合，两者之间天然存在一道缝。

第一段：两边的来历。Kubernetes 的出身解释这台编排器为什么、以及如何成为 GPU 的事实标准；容器与 GPU 的问题则揭示根本矛盾：GPU 不是内核原生资源，标准容器拿不到设备文件，也拿不到驱动库。

第二段：缝合两层。NVIDIA 软件栈自顶向下过一遍从固件到 TensorRT 的每一层及其故障信号；NVIDIA Container Toolkit 深入四个组件（libnvidia-container、OCI 钩子、运行时包装器与 nvidia-ctk），以及 CDI 这条现代路径。

读完本部分，你会明白数据平面各切分机制注入的资源到底是什么，也能在“容器里看不见 GPU”时精确定位断在哪一层。

章节目录

NVIDIA 软件栈

草稿

从固件到 TensorRT，GPU 应用坐在一张由契约组成的分层图上：应用调库、库调 CUDA、运行时找驱动、驱动管硬件。逐层拆解每层的职责与故障信号，理解驱动与运行时的兼容性方向。

Kubernetes 的出身

草稿

Kubernetes 如何从 Google Borg 的内部经验走向开源事实标准，又为什么在容器与 AI 推理爆炸之后成为 GPU 工作负载的默认编排器：一段编年时间线加三个关键洞察。

容器与 GPU 的问题

草稿

容器只是命名空间与 cgroups，而 GPU 由专有内核模块与用户态驱动库组成，标准容器拿不到设备文件也拿不到库。从 nvidia-docker v1 到 v2 的 OCI 钩子方案，看这道缝最初是如何缝合的。

NVIDIA Container Toolkit

草稿

libnvidia-container、OCI 运行时钩子、nvidia-container-runtime 与 nvidia-ctk 各自做什么、如何协作；CDI 如何把厂商钩子变成中立标准；附驱动安装、工具包安装、运行时配置与验证的完整命令，以及关键 NVIDIA 基础镜像选型。

数据平面技术

Jimmy Song — Sat, 10 Jan 2026 10:45:55 +0000

硬切分与软切分留下了那个贯穿全书的选择题：隔离边界放在硬件里，还是软件里。本部分把这个解空间填满，顺序本身就是一条评估路径：先建坐标系，再看两个极端，最后看演进方向与跨厂商案例：

数据平面谱系先立起五维对比基线，后面每一章都是往这张矩阵里回填一个具体机制；
MIG 代表硬切分的极致：硬件分区、强隔离、离散粒度，也第一次暴露硬切分的运维代价；
HAMi 代表软切分的主流工程形态：配额可声明、粒度连续，以及“可声明不等于强隔离”的边界；
DRA 换一个角度：不是新的切分机制，而是 Kubernetes 设备 API 的演进，它决定上面这些机制未来的表达方式；
昇腾 vNPU 把前面各章的分析框架应用到第二厂商，检验“谱系+决策轴”这套方法是否真的可迁移，答案是可以。

读完本部分你应该能对任何共享/切分方案（包括书中没提到的）完成三步定位：它切的是什么资源、边界由谁强制、粒度是否连续。下一部分控制面治理把问题从“一块卡”升级到“一个集群”。

关于

虽然 HAMi 包含调度扩展与控制面组件，但其核心价值在于将 GPU 共享能力兑现为可运行、可治理的资源单位，因此本书将其主要归入数据平面讨论。更深一层看，随着 DRA 成熟后 Kubernetes Scheduler 接管资源声明、Kueue 接管队列、Volcano 接管 batch placement，HAMi 未来可能收缩为更纯的数据平面：专注 GPU runtime、虚拟化与异构设备执行。也就是说，HAMi 今天是跨层系统，但其不可替代价值主要在数据平面，所以将其放在本章节讨论。

章节目录

数据平面谱系

草稿

系统梳理 MIG/vGPU/时间片/配额/显存策略等机制的根本差异，并建立对比基线。

MIG

草稿

聚焦 MIG 的工程事实：强隔离的来源、离散单位的约束、重配置成本与调度耦合。

HAMi

草稿

从数据平面视角拆解 HAMi，聚焦细粒度资源单位、共享治理、隔离与兼容性的工程权衡及适用场景。

DRA

草稿

深入分析 DRA 的架构动机、API 机制与设计取舍，理解它如何从 Device Plugin 的 Allocate 黑盒走向可声明、可推理的资源分配。

昇腾 vNPU

草稿

以昇腾 NPU 为案例应用数据平面谱系：昇腾芯片谱系与历史、与 NVIDIA GPU 的架构生态差异、三条 vNPU 路径（驱动硬切分、vCANN-RT、HAMi）的原理与支持程度，以及场景选型。

控制面治理

Jimmy Song — Sat, 10 Jan 2026 10:46:00 +0000

数据平面解决了“一块卡怎么分”；本部分解决“成百上千块卡、成百上千个租户时，秩序从哪里来”。各章按“地图 → 问题 → 基石 → 工具 → 综合”递进：

先定位。 控制面地图给出全书的架构坐标系：控制面管秩序（队列、配额、准入、抢占），数据面管兑现（切分、隔离、计量），任何项目先放进这张图再讨论；调度问题域接着把控制面要解决的具体问题摊开：碎片化、Gang 语义、放置与拓扑，它们是工具存在的理由。

再打地基。 放置策略把“放哪”写成可审计的对象：标签防错配、污点防侵占、优先级保关键、配额保公平；NUMA 感知调度深入 kubelet 的三个管理器与调度器失明问题，给出 NRT 与拓扑感知调度的修复路径；GPU Operator把驱动、工具包、设备插件与监控的安装收进一个调谐循环；这三者（放置策略、NUMA 感知调度、GPU Operator）是后续所有调度工具运行的地基。

后看工具与案例。 Volcano与Kueue是两条主流路线：前者在调度器内补批处理语义，后者在调度器外做配额准入，正交而可组合；生态放置法提供把任何新项目快速归位的方法；Kthena以 LLM 推理调度为案例，展示控制面如何进入请求路径。

最后综合。 组合架构把前面的拼装件组成六种端到端方案；能力模型把平台交付抽象为可验收的能力单元；决策轴给出评估任何方案的统一维度，并为整个解决方案侧收束。带着这把尺子进入工作负载实践，在真实负载上校准它。

章节目录

GPU 资源控制面地图

草稿

给出控制面与数据平面的分工地图，后续所有项目、机制与实验都将回到这张图上归类与对齐。

调度问题域

草稿

在进入 Volcano、Kueue 等具体工具之前，先看清 GPU 调度的三个特有问题：碎片化（闲着的卡拼不出一组）、Gang 语义（部分启动等于死锁）与放置策略（装箱与打散的反直觉结论），以及它们与拓扑约束的耦合。

放置策略

草稿

nodeSelector 简单精确、节点亲和性富有表达力、污点与容忍划定池子、PriorityClass 是锋利的抢占工具、配额则是多租户的社会架构：把“放哪”从运气变成策略。

Volcano

草稿

Volcano 作为控制面调度策略引擎，提供队列、fair-share、gang scheduling、抢占等批处理与 AI 作业治理能力，补齐原生 Kubernetes 的调度语义缺口。

NUMA 感知调度

草稿

CPU 管理器、内存管理器与设备管理器在 kubelet 内协调 NUMA 对齐，但拓扑管理器只对单个节点生效，调度器看不见 NUMA 时就会陷入“先调度后拒绝”的死循环。NRT 与 KAI Scheduler 如何补上这块盲区。

Kueue

草稿

Kueue 将 GPU 从节点设备升级为组织治理资源，实现准入、配额、队列化与资源承诺，支撑平台化与可运营性。

NVIDIA GPU Operator

草稿

把驱动、容器工具包、设备插件、DCGM、MIG Manager 从手工安装变成一条调谐循环：ClusterPolicy 唯一配置点、八个组件的严格部署顺序、Helm 安装与升级命令、金丝雀循环与最小验证阶梯。

生态放置

草稿

用控制面、数据平面、平台层定位 GPUStack 等项目职责与比较口径，避免清单式盘点。

Kthena

草稿

以 Kthena 为例，探讨 LLM 在线推理如何将 GPU 治理从资源分配升级为语义调度，分析控制面与数据面的协同及其对平台治理能力的提升。

组合架构

草稿

本章提出一套可落地的 GPU 资源组合模式，涵盖数据平面与控制面的正交拼装，配套适用场景、复杂度、风险点及验收指标，助力方案评审与落地。

GPU 平台能力模型

草稿

提出一套可复用的 GPU 平台能力模型，抽象平台交付能力单元、适用前提与验收方式，助力生产环境治理与选型。

GPU 评估决策轴

草稿

给出可直接用于选型评审的决策矩阵：粒度、隔离、性能干扰、可观测、运维复杂度、兼容性与异构扩展。

工作负载实践

Jimmy Song — Sat, 10 Jan 2026 10:45:31 +0000

前三部分给出了机制（数据平面）、秩序（控制面）与评估框架（决策轴）。本部分让它们经受真实负载的检验：负载不同，所有权衡的答案都不同。各章按“由系统观到物理、由单卡到多节点”排列：

工作负载系统观是序章：训练是同步问题、推理是尾延迟问题、多节点推理继承训练的互连约束但 SLO 换成了请求路径；三个视角框定后面各章要解的方程；
LLM 推理的物理层先算清两笔账：解码受带宽屋顶线约束、KV cache 是容量货币。它是后面各章的物理地基，也解释了为什么推理与训练需要完全不同的调度语义；
vLLM在物理层之上引入治理视角：并发、批处理与显存水位线如何同时决定吞吐与尾延迟，平台如何定义可评审的推理配额与验收指标；
PyTorch转到训练侧：训练要的是稳定吞吐而非瞬时峰值，调度语义（gang、抢占、checkpoint）与“有效产出”才是正确的验收对象；
Ray/KubeRay 与拓扑约束把场景推到多卡多节点：单卡经验失效，拓扑约束必须从“偏好”升级为“可验收的硬约束”，正好呼应互连与集合通信的物理结论。

读完本部分，可观测与验收不再是事后補救，而是把每类负载的物理特性转成可运营指标的自然下一步。

章节目录

工作负载系统观

草稿

训练是同步问题，任何一个环节都能成为主导；推理是尾延迟问题，高利用率与违约的 SLO 可以并存；把平台拆成模型、服务、加速器、数据、控制五个平面之后，Kubernetes 才开始像 AI 应用平台。

LLM 推理的物理层

草稿

在讨论推理平台的资源治理之前，先算清物理账：预填充与解码为何受不同的屋顶线约束、KV cache 的容量公式与并发上限、连续批处理与分页 KV 的设计思想、分块预填充对尾延迟的意义，以及推理服务与共享/配额层的配合公式。

vLLM

草稿

从并发、KV cache 与显存形态解释推理为何放大共享问题，并给出可治理的部署与验收思路。

PyTorch

草稿

训练更依赖稳定吞吐与通信拓扑，讨论抢占、弹性与 checkpoint 如何影响调度器与数据平面策略。

Ray 与拓扑

草稿

多卡/多节点场景下，GPU 调度从资源数量升级为拓扑与通信主导，需关注资源表达与可用性验收。

可观测与验收

Jimmy Song — Sat, 10 Jan 2026 10:45:35 +0000

平台建起来了，怎么知道它真的在工作？本部分按“先问对问题，再读懂数字，然后会测量，最后会排障”递进：

可观测与计量用十个必须回答的问题框定观测体系：为什么观测、观测什么、指标如何与 HAMi/Kueue/Volcano 闭环；
GPU 指标语义下钻到字段级：“GPU 利用率”到底测的是什么、三件套（驻留时间/SM 活动/显存带宽）如何同读、多租户归因的四条路径与各自的盲区；
基准、验收与容量规划把“性能”变成“验收”：对照组设计、三类基准、验收包与容量口径；
故障模式与排障手册收尾：四段式收敛流程与五大故障模式，把前面所有章节的因果链变成可执行的 runbook。

这部分各章与前面各部分互为镜像：工作负载部分定义了每类负载的物理特性，这里把它们变成指标；数据平面与控制面部分引入的机制，在这里接受“账实一致”的对账检验。

章节目录

观测与计量

草稿

梳理 GPU 平台运营的关键问题清单，涵盖占用、利用率、干扰、SLA、计量与成本归因，并给出渐进式建设路线。

GPU 指标语义

草稿

逐字段定义 GPU 指标到底测的是什么：GPU-Util 的真实语义、必须同看的三件套（1001/1002/1005）、采样为何看不见尾延迟、多租户归因的四条路径，以及 eBPF 边界观测在 GPU 排障中的位置。

验收与容量

草稿

给出可复用验收标准：吞吐、P99、干扰系数、碎片率、失败率，并把实验结果转化为容量规划输入。

排障

草稿

聚焦线上常见问题：OOM、版本不一致、MIG 重配置、调度抖动，并给出从控制面到数据平面的定位路径。

生产落地

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

前面各部分回答的是“机制如何工作”；本部分回答“系统如何落地”。

第一段：平台与经济。平台责任用 DGX/HGX/MGX 的责任分层回答“买什么、谁兜底”；容量经济用一条利用率曲线回答“买还是租、怎么组合”。

第二段：架构与生态。生产架构把工作负载契约变成节点池、平面划分与命名空间契约；NVIDIA × CNCF 则看向开源版图：KAI Scheduler、DRA 捐赠与 AI 一致性测试正在改变控制面的可选项。

第三段：闭环。端到端实战从一台裸机节点走到一个训练作业；安全、可靠性与生命周期补上信任边界与版本矩阵；实施顺序给出阶段 0–5 的落地路线与验收清单，为全书收官。

章节目录

平台责任

草稿

DGX 是整机系统责任、HGX 是 OEM 平台设计、MGX 是模块化参考架构、云 GPU 是服务契约：四个标签对应四种“谁为故障负责”的答案，而功耗、散热与可维护性本身就是算力特性。

容量经济

草稿

买还是租是一条利用率曲线，不是价格表：核心变量是每单位有用完成工作的成本（把启动、排队、传输、失败、工程与闲置时间全部计入），再警惕“总体很忙、GPU 却在碎片中等待”的利用率悬崖。

生产架构

草稿

先写工作负载契约再写 YAML；把异构机群按世代、内存档位、互连与生命周期切成产品化的节点池；用控制、计算、数据、网络、可观测五个平面与命名空间契约把多租户治理落到对象上。

NVIDIA × CNCF

草稿

为什么靠专有软件筑护城河的 NVIDIA 在系统性开源其 K8s 基础设施：KAI Scheduler、DRA Driver 捐赠、Grove、GPU Operator、NVCF，以及 KAI 的成组调度、分层队列与 NUMA 感知放置如何补上默认调度器的三个缺口。

端到端实战

草稿

一台全新 Ubuntu 24.04 + H100 节点，从装 containerd、加入集群，到部署 GPU Operator、观察自举顺序、跑通验证 Pod、配置 NUMA 感知调度，最后提交一个 PyTorch 训练作业并用 DCGM 监控，七步走完前面各部分的全部机制。

安全与生命周期

草稿

GPU 工作负载携带模型权重与凭据，特权 DaemonSet 需要更高级别的信任审查；可靠性是可预见的恢复而非从不报错；一份带签名性质的版本矩阵，让每次升级只动一个维度。

实施顺序

草稿

阶段 0–5 的落地路线：定义工作负载 → 验证单节点 → 验证单服务器 → 验证 Kubernetes → 验证多节点 → 生产化，附一份六项验收清单：生产始于恢复路径被演练之时。

生态与趋势

Jimmy Song — Sat, 10 Jan 2026 10:45:40 +0000

前七个部分回答的是“当下怎么把 GPU 平台建好、管好、验收好、落地好”；本部分回答“这个领域在往哪里走，以及这本书如何跟上”：

生态图谱与趋势不是项目清单，而是一套可复用的坐标系：用控制面/数据平面/工作负载面三段视角和决策轴矩阵，把任何新项目放进同一张表里持续评估，并延伸到 AI 时代的功耗、分离式推理与智能体负载维度。它本质上是控制面地图与决策轴在时间维度上的延伸；
持续更新路线图则把“写书”变成“维护一个可复现的验证资产库”：最小增量单元、版本节奏与贡献机制，让内容演进跟上生态速度；
命令速查是全书附录：硬件拓扑、Kubernetes 诊断与分布式调试的高频命令一页入口。

章节目录

趋势

草稿

收束长期判断：设备抽象演进、异构标准化、GPU 从硬件资产向可运营资源池迁移的路线图。

路线图

草稿

定义本书迭代节奏与贡献规范：每次更新至少新增一个场景、一个对比表、一个实验记录，并沉淀为模板资产。

命令速查

草稿

全书高频命令的一页速查：硬件与拓扑检查、Kubernetes 与 Operator 诊断、分布式工作负载调试，是排障与验收时的第一入口。