1. 课程导入：学习目标、课程结构、Kubernetes与AI服务扩缩容背景

1.1 为什么AI服务需要“自动扩缩容”

在Kubernetes中运行AI推理服务（如模型推理、向量检索、批量预测）与运行普通Web应用有本质差异。普通Web应用的压力通常表现为请求量（QPS）的线性增长，而AI服务还面临GPU显存占用、推理延迟（P99）、批处理吞吐等非线性指标。一个典型的故障场景是：当业务流量突增时，Pod副本数未能及时扩展，导致GPU利用率超过90%，推理请求排队，P99延迟从50ms飙升到2s；而当流量回落后，副本数又未能及时回收，造成GPU资源空转和成本浪费。

Kubernetes原生提供的HorizontalPodAutoscaler（HPA）基于CPU/内存利用率进行扩缩容，但这对AI服务远远不够。AI服务的扩缩容需要同时考虑：

• 自定义指标：如GPU利用率、推理队列深度、每秒推理请求数（inferences per second）。
• 预测性扩缩容：根据历史流量模式提前扩容，避免冷启动延迟。
• 模型版本切换：新模型上线时，需要平滑迁移流量并自动调整副本。
• 成本约束：在SLA（服务等级协议）允许范围内，尽量压缩GPU节点数量。

1.2 课程学习目标

完成本课程后，你将能够：

1. 理解扩缩容原理：掌握HPA、KEDA（Kubernetes Event-driven Autoscaling）、VPA（Vertical Pod Autoscaler）的底层工作机制与适用边界。
2. 配置自定义指标：使用Prometheus Adapter将GPU利用率、推理延迟等指标暴露给HPA。
3. 设计扩缩容策略：针对在线推理、离线批处理、流式请求等不同AI负载，选择合适的扩缩容策略与参数。
4. 处理模型生命周期：结合Knative、KServe等Serverless框架，实现模型版本自动扩缩容与流量切换。
5. 排查与调优：通过Kubernetes事件、Metrics API、HPA状态等定位扩缩容失效问题，并优化扩缩容响应速度。

1.3 课程结构总览

本课程共30章，按“原理 → 实践 → 进阶 → 排障”四个阶段组织，每章均配有可操作的示例与配置片段。下表展示了课程的核心模块分布：

课程强调“配置可验证”——每章给出的YAML、命令和策略均可在真实集群或Kind测试环境中复现。建议你准备一个至少包含1张GPU节点（如NVIDIA T4）的测试集群，以便跟随实操。

1.4 AI服务扩缩容的核心挑战

与普通Web应用相比，AI服务扩缩容面临四大独特挑战，这也是本课程反复强调的主线：

• 指标非线性：GPU利用率与请求QPS并非线性关系。当并发请求超过模型批处理最优值时，GPU利用率可能不升反降（因排队等待）。
• 冷启动代价高：加载一个数GB的模型权重到GPU显存可能需要10-30秒，无法像普通容器那样秒级扩容。
• 资源类型异构：推理服务可能同时需要CPU（预处理）、GPU（推理）、内存（特征缓存），扩缩容需考虑多维资源约束。
• 流量突发性：AI服务常面临“脉冲式”流量（如推荐系统在活动开始时的流量尖峰），需要预测性扩容而非反应式扩容。

1.5 扩缩容体系架构总览

下图展示了Kubernetes AI服务自动扩缩容的整体架构，以及本课程将要深入讲解的各个组件之间的关系。图中重点标出了指标采集路径和扩缩容决策链路：

图中展示了本课程的核心闭环：客户端流量进入Ingress后分发至AI推理服务Pod；Pod的运行状态由指标采集器（如Prometheus + DCGM exporter）持续监控，采集到的GPU利用率、推理延迟等指标存入Prometheus时序库；随后Prometheus Adapter将这些自定义指标转换为Kubernetes标准的Metrics API格式；HPA控制器（或KEDA）周期性读取这些指标，与预设阈值比较后，通过ReplicaSet控制器调整Pod副本数，最终作用于Deployment，形成完整的反馈控制回路。

在后续章节中，我们将逐一深入这个架构中的每个环节：第2-6章讲解HPA/VPA/KEDA的内部机制；第7-12章聚焦如何采集和暴露AI服务特有的GPU指标；第13-22章通过真实案例展示不同AI负载的扩缩容配置；最后在第23-30章解决扩缩容震荡、冷启动等实际问题。