W05 · S29—S35 · 总 Day 119—125
平台工程:声明需求与协调实际状态
用服务目录、租户配额和协调计划理解控制平面。
作者准备的学习示例 · 不计真实学习进度 · 不代表生产 / GPU / 真机结果
核心问题
一个应用团队说“我需要两份摘要服务副本,使用 bundle v2”。平台应该记住一串手工操作,还是保存这个目标并持续比较实际状态?本周用一个很小的协调函数理解声明式控制。
对应 S29~S35。重点是状态与职责,不是安装 Kubernetes 或搭建大型内部开发平台。
1. 分开四种对象
desired 是目标状态;actual 是观察到的状态;quota 是允许的资源边界;plan 是两者比较后提出的动作。计划生成不等于动作完成,动作完成也不代表后续状态永远不变。
示例有 summarizer 和 retriever 两个服务,按 tenant/name 确定身份。平台比较版本与副本数,给出 create、update 或 noop。如果租户目标副本总量超过配额,标记 blocked。配额按租户合计,不是给每个服务单独看一次上限。
真正的控制循环还需要执行器、重新观察、并发控制、失败重试、资源身份映射与删除语义。这里刻意不执行删除:actual 中额外出现的对象不会被自动清理,避免把一个教学差异计算器误当完整协调器。
2. 运行与解释
npm run learning:p2 -- w05
目标是 summarizer 2 副本/v2,加 retriever 1 副本/v1;实际只有 summarizer 1 副本/v1。配额为 3 时,一个 update、一个 create;配额为 2 时,两个目标都会 blocked。当 actual 与 desired 一致,输出全部 noop。
这里的“收敛”只指纯函数观察到目标一致,不是证明控制器可以在所有故障下最终收敛。代码没有更新实际资源,也没有调用容器、云账号或部署服务。
3. 为什么这与 AI 平台有关
AI 团队反复需要相似能力:选择模型或 bundle、创建安全工具配置、获得 trace、申请数据访问、配置预算和人工队列。Golden path 是把常见选择做成容易理解的默认路径,同时暴露重要约束与例外渠道,而不是让每个团队重装基础设施。
| 平面 | 本例中的影子 | 真实 AI 平台的例子 |
|---|---|---|
| 控制平面 | desired、quota、plan | 模型目录、租户策略、发布配置 |
| 运行平面 | actual 的描述 | 实际推理进程、任务与工具执行 |
| 数据平面 | 未实现 | 数据集、检索与特征服务 |
| 证据平面 | 终端输出 | 操作来源、trace、成本与变更记录 |
好的平台能力不只看“有多少按钮”,也看团队是否更容易理解失败、定位责任、获得合适默认值。这个判断需要真实使用反馈,单个协调函数无法证明开发效率提升。
4. 轻量练习与延伸
只把 retriever 的 tenant 改为另一个名字,观察配额为什么不应共享。然后只改变 bundle,确认更新原因来自版本而不是副本数。任选一个练习即可。
深入问题:quota 的目标总量不一定覆盖滚动更新时的临时峰值。新增副本先启动、旧副本后退出,会需要额外容量。写一个时序说明这种差别,无需实现集群调度。
5. 专业阅读与未来连接
- Kubernetes Controllers:读 desired state 与 current state 的控制循环,对照本例缺少的执行和重观察步骤。
- Stanford CS329S:用完整 ML 生命周期思路判断平台到底支持哪些工作,而不只从基础设施出发。
未来研究平台要管理实验配置与资源;具身 fleet 要管理任务、设备、策略与可用状态。但“修改 desired”不等于“允许机器人立即动作”,物理执行还需要独立的安全约束。可记下自己最想省去的一项重复配置,以及必须保持可见的一项控制。