容量规划与负载预测：自动伸缩实践

CH-22-03-022·约 19 分钟·现代软件架构与云原生·更新 2026-08-12

林叔开了一家面馆，生意越做越大，却开始失眠——中午十二点客人挤满店堂，厨师手忙脚乱，出餐要等四十分钟；下午三点店里却空无一人，五个厨师站在灶台前擦碗。林叔的两个问题，和每一位系统管理员面对的困境一模一样：该准备多少资源？什么时候准备？他决定用一套“聪明”的方法来经营：先看天气预报和节假日日历预测客流，再根据预测提前备菜、安排人手，同时装一个自动感应系统，客人一多就自动加桌加人，客人少了就自动撤桌。这套方法，就是云原生世界里的“容量规划与自动伸缩”——通过历史数据预测未来负载，让 HPA、VPA、KEDA 这些“自动排班工具”替你把资源安排得明明白白。

岗位关联

对 AI 从业者而言，理解容量规划与自动伸缩是构建弹性系统的必修课，这意味着你会用预测模型驱动资源决策，把“运维救火”升级成“全自动管理”。

可视化演示
容量规划基础
负载预测方法
水平伸缩 HPA
垂直伸缩 VPA
KEDA事件驱动
预测驱动规划
监控告警干预
实践方法论
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

三步展示容量规划实践：HPA控制循环采集-计算-调整副本、水平与垂直伸缩对比、以及基于ARIMA时间序列的负载预测驱动主动式容量规划。

本节配有交互动效（进入视口后自动加载，约 3KB）。

HPA控制循环采集：指标数据计算：目标副本调整：增删Pod Metric→Desired 约15秒一个循环。

容量规划基础

林叔反思面馆的困境：他过去凭感觉做生意，周末不加人手，非高峰时段却养着满编厨师。真正的经营高手，会先回答四个问题——客人能等多久（SLO）、店里挤到什么程度算饱和（资源饱和度）、多雇一个人多花多少钱（成本）、凭什么数据做这些决定（数据驱动）。容量规划正是解决这四个问题的系统性过程。

在云原生世界里，这里的“客人等待上限”对应服务水平目标（SLO）；“店里挤到没法转身”对应资源饱和度——当 CPU、内存逼近上限时，系统开始排队、超时甚至崩溃。传统做法是“拍脑袋定机器数”，要么过度采购造成云账单膨胀，要么配置不足导致大促时服务雪崩。数据驱动的容量规划，则是把历史负载画成曲线，找出业务增长与资源消耗之间的规律。

衡量一个系统“挤不挤”，最直观的指标就是资源利用率：

林叔按照这个方法，重新盘点了面馆的家底：翻出台账发现晚餐时段座位上座率平均 85%，后厨冷柜容量利用率达到 90%——他这才明白，过去不是“生意差”，而是没有用量化视角看问题。

\displaystyle \text{资源利用率} = \frac{\text{实际使用资源}}{\text{总容量}} \times 100\%

实际使用资源指当前被业务进程占用的 CPU 核数、内存字节数，可以在监控面板上直接读取，相当于面馆里正在就餐的顾客数。
$\displaystyle \text{实际使用资源} = \text{CPU 用量、内存用量}$
总容量系统配置的资源上限，如 16 核 CPU、64GB 内存，相当于面馆满座时的最大接待能力。
$\displaystyle \text{总容量} = \text{Node 可分配资源总和或 Pod 配额}$
比值百分化将“已用/总量”归一为 0–100% 的百分比，方便制定统一的扩展阈值，比如 70% 触发扩容。
$\displaystyle \frac{\text{实际使用资源}}{\text{总容量}} \times 100\%$

负载预测方法

有了基础数据，林叔开始研究一个更高级的问题：能不能提前知道明天中午会有多少客人？他翻出三个月的账本，发现周一中午总比周二多三成，雨天外卖订单暴增，月底发工资后几天生意特别旺。这就是规律——历史数据里藏着预测未来的线索。

负载预测的统计方法，最常用的是移动平均和指数平滑。移动平均像“看最近七天的平均客流”，简单但反应迟钝；指数平滑则像“重点参考昨天、兼顾上周同期”，通过一个系数 α 调节新旧信息的权重，既跟得上变化又不会被偶然噪音带偏。再进一步，趋势周期分解把数据拆成“长期趋势 + 季节性周期 + 随机波动”，对应面馆的“三年扩张趋势 + 一周营业周期 + 某天突发天气”。

指数平滑的核心公式只有一行：

林叔用这套方法，成功预测出周末晚上客流会从 80 人涨到 130 人，提前多备了 30 斤面条。负载预测的本质，就是从混沌的历史数据中找到规律，替未来做出一个“有根据的猜测”。

\displaystyle \hat{y}_{t+1} = \alpha y_t + (1-\alpha)\hat{y}_t

当前观测值 $y_t$今天晚上的实际客流，是预测系统收到的“最新情报”。
$\displaystyle y_t = \text{t 时刻的真实负载观测值}$
旧预测值 $\hat{y}_t$昨天对今天做出的预判，代表过去所有信息的浓缩。
$\displaystyle \hat{y}_t = \text{t 时刻的模型预测值}$
平滑系数 α介于 0 到 1 之间，表示对新情报的信任程度。α 越接近 1，预测越“健忘”、越追随最新变化。
$\displaystyle 0 \le \alpha \le 1$
加权求和新预测 = 最新实测与旧预测的加权平均，兼顾“最新变化”与“历史惯性”。
$\displaystyle \alpha y_t + (1-\alpha)\hat{y}_t$

水平伸缩 HPA

预测归预测，现实中总有意外——比如林叔没想到周五晚上附近商场搞促销，人流突然翻倍。这时他需要一套“即时响应”机制：客人一多，立刻从劳务市场临时加雇帮工；客人少了，就让人回去。这套机制就是水平伸缩（HPA）。

水平伸缩（Horizontal Pod Autoscaler）调整的是“厨师数量”——通过增减 Pod 副本数来应对负载变化。HPA 控制器持续采集 CPU 利用率或自定义业务指标，与预设的目标值对比，然后按比例计算目标副本数。它不会一步到位，而是像林叔每次只加一两个帮工、观察几分钟再决定是否继续加，避免一次收太多人导致人浮于事。

HPA 的核心是副本数计算公式：

HPA 还有冷却策略：每次扩容后等待若干分钟再决策，防止系统“一惊一乍”。林叔把临时帮工的调度权交给 HPA 后，面馆终于实现了“客多人多，客少人少”的自动化——它解决的永远是“临时人手不够”的燃眉之急。

\displaystyle N_{\text{desired}} = \left\lceil N_{\text{current}} \times \frac{M_{\text{current}}}{M_{\text{target}}} \right\rceil

当前指标 $M_{\text{current}}$最近一次采集的 CPU 平均利用率或自定义指标值，等价于“此刻店里有 100 位客人”。
$\displaystyle M_{\text{current}} = \text{当前观察到的负载指标}$
目标指标 $M_{\text{target}}$业务方设定的期望水位，如 70% 利用率，相当于“每桌客人最好只占七成座位”。
$\displaystyle M_{\text{target}} = \text{预设的目标负载阈值}$
副本比例缩放当前副本数乘以“当前指标与目标指标的比值”，指标超一倍就翻倍加人，低于一半就裁人。
$\displaystyle N_{\text{current}} \times \frac{M_{\text{current}}}{M_{\text{target}}}$
向上取整用 $\lceil \rceil$ 保证计算结果至少比当前多一个副本，宁可多雇不可少做。
$\displaystyle \left\lceil \cdot \right\rceil = \text{向上取整到最近整数}$

垂直伸缩 VPA

后来林叔发现一个现象：有时候店里客人不多，但每个厨师都在手忙脚乱——因为灶台火力太小，一锅面要煮六分钟。与其加人，不如把单头灶换成双头灶，让每个厨师效率翻倍。这就是垂直伸缩（VPA）的思路：调整单个 Pod 的资源规格，而不是增加 Pod 数量。

垂直伸缩（Vertical Pod Autoscaler）分析 Pod 历史资源使用情况，推荐或自动调整 CPU/内存的 requests 和 limits。它有三个工作模式：Off 模式只给建议；Auto 模式自动调整并在必要时重启 Pod；Initial 模式只在 Pod 创建时生效。VPA 的推荐算法会收集最近若干天的资源使用样本，剔除极端峰值后取较高分位数，再乘以安全系数——这个逻辑相当于林叔不看某天意外爆满的极端数据，而是看“绝大多数时间够用，再留一点余量”。

VPA 推荐值的经典计算方式：

VPA 调整资源后需要重建 Pod 才能生效——这就像给灶台换大火力，总得让后厨停几分钟。实践中常将 VPA 与 HPA 搭配：VPA 负责“给每个厨师配更好的工具”，HPA 负责“人数不够就加人”，两者互补，让林叔的后厨既高效又弹性。

\displaystyle R_{\text{recommend}} = Q_{95}(\text{历史样本}) \times (1 + \text{安全余量})

历史样本采集获取 Pod 在过去数天至数周的 CPU/内存使用序列，去掉启动预热期和被杀死的异常 Pod 数据。
$\displaystyle \text{样本} = \{ u_1, u_2, \ldots, u_n \}$
取第 95 百分位 $Q_{95}$将样本按升序排列，取排在第 95% 位置的值——保证 95% 的时间资源都够用，又不为 1% 的极端峰值买单。
$\displaystyle Q_{95}(\text{样本}) = \text{升序排列后第 } \lceil 0.95n \rceil \text{ 个值}$
乘安全余量在分位数基础上再乘一个大于 1 的系数（如 1.15），为预测误差和突发留出缓冲。
$\displaystyle Q_{95} \times (1 + 0.15)$

KEDA事件驱动

新的麻烦出现了：林叔面馆上线了外卖平台，深夜 11 点突然涌进 200 个外卖订单——客人不在店里，但后厨瞬间被打爆。人口预测和即时监控都来不及反应。林叔需要一个“门铃”：订单一来就响铃，后厨立刻开工。这就是 KEDA 的哲学——不是看客人流量，而是听事件信号。

KEDA（Kubernetes Event-Driven Autoscaling）让 HPA 可以基于事件源（如消息队列长度、数据库积压量、自定义指标）触发扩容。它通过 Scaler 插件连接各类事件源——Kafka、RabbitMQ、Redis、Prometheus、甚至 AWS SQS——实时监听队列积压情况。当队列里积累了一批待处理任务，KEDA 就告诉 HPA“该加人了”；任务清空，再慢慢收缩。这相当于面馆装了一个智慧门铃，外卖订单一响，大师傅自动加班。

KEDA 的目标实例数计算基于队列深度：

有了 KEDA，林叔的面馆不再“望客流兴叹”，而是能对后台信号做出即时响应——这是一套事件驱动的手臂，把系统的反应速度从分钟级提升到秒级。

\displaystyle N_{\text{target}} = \left\lceil \frac{L_{\text{queue}}}{P_{\text{per instance}}} \right\rceil

队列深度 $L_{\text{queue}}$当前积压的待处理任务数，比如外卖订单数，或者 Kafka 消费者 lag。
$\displaystyle L_{\text{queue}} = \text{队列中未处理消息数量}$
单实例吞吐 $P_{\text{per instance}}$每个 Pod 每秒能处理多少个任务，需要提前压测得出，相当于“一个厨师一小时能出 30 碗面”。
$\displaystyle P_{\text{per instance}} = \text{单个实例的处理速率}$
相除向上取整订单总量除单人产能，得出最少需要几个人手，不足一人也按一人算。
$\displaystyle \left\lceil \frac{L_{\text{queue}}}{P_{\text{per instance}}} \right\rceil$

预测驱动规划

现在林叔面临终极问题：HPA 反应再快，也有“加人需要时间”的冷启动延迟；KEDA 再灵敏，也赶不上一瞬间的流量洪峰。真正的解法是——提前行动。林叔看天气预报说下周台风，外卖订单必爆，于是提前一天把冻肉解冻、多雇三位帮工。这套动作叫预测驱动的容量规划。

预测驱动的容量规划，是将负载预测模型的输出，作为资源伸缩的输入信号。系统预测未来 30 分钟到几小时的流量，提前把 HPA 的最小副本数抬升、或直接创建一批预热 Pod。这样当流量真正到达时，集群已经准备好了。它不是在“救火”，而是在“防洪”——在洪水到来之前就修好堤坝。

预测驱动的容量决策公式：

预测驱动规划的落地：系统每天凌晨用历史数据训练模型，输出未来 24 小时的逐小时负载曲线；再与 HPA 联动，动态调整最小副本数。林叔发现，自从引入“看天备菜”机制后，高峰期再也没有出现“面卖断货”的窘境——预测让伸缩从被动防守变成了主动进攻。

\displaystyle C_{\text{plan}}(t+\Delta) = \left\lceil \frac{\hat{y}(t+\Delta)}{c_{\text{per replica}}} \right\rceil + B

预测负载 $\hat{y}(t+\Delta)$模型预测未来 $t+\Delta$ 时刻的负载，比如台风天外卖订单量。
$\displaystyle \hat{y}(t+\Delta) = \text{预测模型给出的未来负载}$
单副本容量 $c_{\text{per replica}}$1 个 Pod 能承接的负载量，算“平均每个厨师能应对的顾客数”。
$\displaystyle c_{\text{per replica}} = \text{单实例处理能力}$
向上取整加缓冲 $B$计算结果向上取整，再额外加固定缓冲副本，为预测误差留后手。
$\displaystyle \left\lceil \frac{\hat{y}(t+\Delta)}{c_{\text{per replica}}} \right\rceil + B$

监控告警干预

自动化程度再高，林叔也不敢完全不看店。他给面馆装了三种警报：炉灶温度超标会响、冷柜温度异常会响、收银机流水异常会响。但如果警报灵敏度设太高，一阵风吹开窗户也会误报——报警器响了一夜，店员都麻木了。监控告警正是自动伸缩系统的“神经反馈中枢”。

监控体系先解决指标采集：Prometheus 采集 CPU、内存、QPS、P99 延迟等数据，Grafana 负责可视化。告警规则解决“什么时候报警”：当指标持续超过阈值一段时间才触发，避免单次毛刺造成误报。经典的阈值设定方法，是在历史基线上加若干倍标准差：

误报的另一个抑制手段是“多指标联合判定”：同时满足 CPU 高、错误率高、队列积压才告警，就像面馆要同时看到“排队超过 20 人 + 后厨出餐明显变慢 + 冷柜快空了”才确认真出问题了。即使自动化再完善，人工干预仍是最终兜底——林叔设置了一个值班手机，收到告警后 10 分钟内人工介入检查。自动化的价值不是替代人，而是让人从低水平巡检中解放出来，专注在高价值决策上。

\displaystyle \text{触发条件} = \text{value} > \mu + k \times \sigma

基线均值 $\mu$最近一段时间负载的平均值，比如过去 14 天同一时段的平均 P99 延迟。
$\displaystyle \mu = \text{历史指标均值}$
标准差 $\sigma$负载波动的离散程度，波动越大说明系统越不稳定。
$\displaystyle \sigma = \sqrt{\frac{1}{n}\sum_{i=1}^n (x_i - \mu)^2}$
倍数系数 $k$一般取 2–4，k 越大越不容易误报，但也可能漏报真实故障。
$\displaystyle \text{value} > \mu + k\sigma = \text{超出正常波动范围}$

实践方法论

林叔把面馆经营成一套完整体系后，总结出落地自动伸缩的四条经验：第一，不要迷信单一工具——HPA 管日常波动、VPA 管资源规格、KEDA 管事件突发、预测规划管大促前准备，四者协同才是完整方案。第二，团队要有协作机制，开发、运维、业务方像厨师、服务员和采购一样定期对齐。第三，任何新伸缩策略先在灰度环境验证，不要在大堂直接试验。第四，每次大促后复盘，把“经验”沉淀成“规则”。

多策略组合的最终决策公式，是取各控制器的需求最大值：

林叔的面馆最终实现了“淡季省人力、旺季不误事”的理想状态。回头看，容量规划的本质就是回答“需要多少、什么时候需要、如何准备”，而自动伸缩把这套智慧从“人的经验”升级成了“系统的本能”。最好的伸缩策略，是让人感觉不到伸缩的存在——就像客人只感受到热腾腾的面，而不会在意后厨如何调度。

\displaystyle N_{\text{final}} = \max\big(N_{\text{HPA}}, N_{\text{KEDA}}, N_{\text{prediction}}\big)

各控制器建议值HPA 根据当前指标、KEDA 根据队列深度、预测模型根据未来负载，各自独立算出需求副本数。
$\displaystyle N_{\text{HPA}}, N_{\text{KEDA}}, N_{\text{prediction}}$
取最大值三个数值中挑最大的——保证系统在任何单一视角下都不会资源不足。
$\displaystyle \max(\cdot) = \text{取所有建议中的最大者}$
最终执行以最大值为目标副本数交给 Deployment，再配合冷却和限速策略平滑执行。
$\displaystyle N_{\text{final}} = \text{实际伸缩目标}$

AI 应用场景

电商大促前的预测扩容

阶段：容量规划与负载预测

解决的问题：双十一大促流量是平日的 20 倍，传统做法是提前一周人工扩容 50 台机器，活动结束后再手动缩容——资源浪费严重，且扩容时机全凭经验。

具体案例：某电商平台利用过去三年的大促流量数据训练时间序列预测模型，在活动开始前 4 小时自动将核心订单服务的 HPA 最小副本数从 20 抬升到 200，活动结束后按衰减曲线逐步释放。系统相当于林叔“看天气预报备菜”——预测驱动容量规划直接联动 HPA 最小副本数，既保证峰值不宕机，又省下 40% 的闲置资源成本。

订单消息队列的突发事件扩容

阶段：事件驱动弹性伸缩

解决的问题：外卖平台的订单积压具有极强的突发性，晚间高峰或恶劣天气时订单量瞬间暴涨数倍，基于 CPU 的 HPA 触发太慢，消费者堆积导致订单处理延迟加大。

具体案例：某外卖平台使用 KEDA 监听 Kafka 中订单消息的消费者 lag，当 lag 超过 5000 条时在 30 秒内自动扩容 10 个消费者实例，lag 回落后自动缩容。KEDA 的 Scaler 机制让系统直接感知“事件压力”，而不是间接等待 CPU 升高——像面馆的门铃一响就开工，不等客人进店才发现人手不够。

混合云资源池的动态调度

阶段：监控告警与人工干预

解决的问题：自建机房容量有限，公有云资源按秒计费，需要判断何时把溢出的流量调度到公有云，何时回收——成本与稳定性的平衡。

具体案例：某金融科技公司构建了“本地集群 + 公有云弹性池”混合架构。本地集群利用率超过 75% 时，自动将新增 Pod 调度到私有云；利用率回落后，优先缩容云端实例。所有决策基于监控数据与预测模型的联合输出，并设置人工熔断开关——值班工程师确认扩容策略无误后一键放行，相当于林叔的“值班手机”，关键时刻人来拍板。

Python 演示

python61 行

import mathimport random  def generate_traffic(hour):    """模拟业务流量的昼夜节律和噪音"""    daily = 50 + 40 * math.sin(2 * math.pi * (hour % 24 - 8) / 24)    noise = random.uniform(-8, 8)    return max(5, daily + noise)  class AutoScaler:    """模拟 HPA 自动伸缩控制器"""     def __init__(self, min_reps, max_reps, target):        self.replicas = min_reps        self.min_reps = min_reps        self.max_reps = max_reps        self.target = target        self.metric_history = []        self.scale_count = 0     def observe(self, metric):        self.metric_history.append(metric)        if len(self.metric_history) > 168:            self.metric_history.pop(0)     def predict_next(self):        """用最近 24 个点的移动平均做负载预测"""        recent = self.metric_history[-24:]        if not recent:            return 0.0        return sum(recent) / len(recent)     def decide(self):        """根据当前指标和预测值决定目标副本数"""        current = self.metric_history[-1] if self.metric_history else 0        pred = self.predict_next()        effective = max(current, pred)        ratio = effective / self.target        desired = int(math.ceil(self.replicas * ratio))        desired = max(self.min_reps, min(self.max_reps, desired))        if desired != self.replicas:            self.scale_count += 1        self.replicas = desired        return self.replicas  def main():    scaler = AutoScaler(min_reps=2, max_reps=10, target=70)    for hour in range(24 * 7):        metric = generate_traffic(hour)        scaler.observe(metric)        reps = scaler.decide()        if hour % 8 == 0:            print("hour=%d metric=%.1f replicas=%d" % (hour, metric, reps))    print("total scale actions: %d" % scaler.scale_count)  if __name__ == "__main__":    main()

目的：模拟一周的负载数据，演示 HPA 自动伸缩控制器如何根据当前指标和移动平均预测决定副本数。

def generate_traffic(hour)用正弦函数模拟白天高、夜晚低的业务流量节律，和面馆的客流曲线异曲同工。
self.metric_history.append(metric)记录历史指标，为移动平均预测提供数据窗口。
def predict_next(self):用最近 24 小时的平均负载预测下一时刻，相当于看“近一天的平均客流”。
effective = max(current, pred)当前负载和预测负载取较大者，防止突发流量打穿系统。
ratio = effective / self.target计算当前负载与目标水位的比值，比值大于 1 说明需要扩容。
desired = int(math.ceil(self.replicas * ratio))按 HPA 核心公式计算目标副本数，向上取整保证面积。
self.scale_count += 1每次副本数变化时计数，最终输出总伸缩次数。

常见误区

误区新手常以为 HPA 和 VPA 是互斥方案，用了水平伸缩就不能用垂直伸缩，选了 VPA 就关闭 HPA。

正解两者解决的是不同维度的问题——HPA 管“数量”，VPA 管“规格”。面馆既需要“人多的时候加桌子”，也需要“给桌子加大尺寸”。实践中 HPA 和 VPA 可以协同：VPA 调整每个 Pod 的资源请求，HPA 根据整体负载增减 Pod 数量。唯一要注意的是两者不要针对同一指标“搏斗”，比如让 VPA 把 CPU request 调高后 HPA 又因利用率降低而缩容，需要设置合理的协同策略。

为何常见：因为两者都带有“Autoscaler”字样，Kubernetes 文档又常分开介绍，新手容易把它们当成替代方案，而非互补工具。

误区一些工程师认为只要引入机器学习预测负载，就一定能替代 HPA 的简单比例计算，预测效果不佳时还怀疑是模型不行。

正解预测驱动的价值在于“提前量”，而不是每个时刻都更精确。简单移动平均就能捕捉大部分周期规律，复杂模型可能只多提升 10% 精度，却带来高昂的训练和维护成本。面馆老板看天气预报备菜，但炉灶还得开着实时应对意外。正确做法是让预测决定“基础水位”（最小副本数），让 HPA 响应实时波动，两者各司其职。

为何常见：因为业界宣传中“AI 预测”听起来比“阈值规则”先进，容易让人忽略工程简单性和稳定性的价值。

误区运维新手担心漏报，把告警阈值设得很低，结果告警风暴把团队淹没，真正的故障被淹没在大量噪音里。

正解告警阈值本质是对误报率和漏报率的权衡。阈值低了误报多，工程师对告警麻木甚至关掉告警；阈值高了漏报多，故障发生时无感知。正确做法是基于“基线的 μ+kσ”设定异常边界，同时引入多指标联合判定和持续时间条件。林叔的面馆报警器如果灵敏度调到“一只苍蝇飞过也响”，真正的炉灶起火反而没人理会了。

为何常见：人们本能地认为“多报警 = 更安全”，却忽略了告警系统最重要的价值指标是信噪比，而不是告警总数。

误区刚接触 Kubernetes 时以为 HPA 只需配置 CPU 指标，所有服务的伸缩都可以按 CPU 决定。

正解CPU 只是最通用的代理指标，很多服务的瓶颈不在 CPU——订单系统受数据库连接池限制，视频处理受内存带宽制约，消息消费者受队列深度影响。面馆的瓶颈可能是灶台数量（CPU）、食材储备（内存）或外卖订单量（队列）。生产环境的 HPA 应结合业务自定义指标（QPS、P99 延迟、队列长度），配合 VPA 和 KEDA 构建多维度的伸缩体系。

为何常见：因为 Kubernetes 教程和示例几乎都以 CPU 为例，学习者容易把示例当成最佳实践。

面试题

Q1. HPA 计算期望副本数的核心公式是什么？

单选题 · easy

A.当前副本数 × 当前指标 ÷ 目标指标，向上取整← 正确答案
B.当前副本数 × 目标指标 ÷ 当前指标，向上取整
C.当前指标 ÷ 目标指标，向上取整
D.目标指标 ÷ 当前指标，向下取整

答案：A。HPA 的公式是期望副本数 = ceil（当前副本数 × 当前指标/目标指标）。当当前指标超过目标时，比值大于 1，副本数增加；未超过则减少。选项 B 分子分母颠倒，C 少了当前副本数，D 方向完全错误。

Q2. 指数平滑公式中平滑系数 α 越接近 1，预测结果会怎样？

单选题 · easy

A.越依赖最近观测值，对变化越敏感← 正确答案
B.越依赖历史平均值，预测越平滑
C.预测值恒等于历史均值
D.预测值完全不可预测

答案：A。α 是“新观测值权重”，当 α→1 时，公式主要由当前观测值决定，预测会紧紧跟随最新变化，但容易受噪音干扰。α→0 时则主要由旧预测值主导，曲线平滑但反应迟钝。这就像饭店排班：完全信天气预报（α=1）会天天过度反应，完全信历史均值（α=0）则会忽略真正的变化。

Q3. VPA 不同于 HPA 的核心价值是什么？

单选题 · mid

A.调整单个 Pod 的资源请求而不是增加副本数← 正确答案
B.自动重启所有异常 Pod
C.实现两个集群之间的自动负载均衡
D.替代 Kubernetes 的调度器

答案：A。VPA 聚焦“垂直”调整——修改 Pod 的 CPU/内存 requests 和 limits，让每个实例更有“力气”；HPA 则是增减副本数量。VPA 不负责重启异常 Pod，也不参与集群间的调度决策，它的职责边界就是资源规格的推荐和调整。

Q4. KEDA 的 Scaler 插件主要解决什么问题？

单选题 · mid

A.把 Kafka、Redis 等事件源转换为伸缩信号← 正确答案
B.替代 Prometheus 采集系统指标
C.实现容器镜像的自动构建
D.替代 Kubernetes API Server 实现认证

答案：A。KEDA 的价值在于让 HPA 可以感知事件源的积压情况——通过 Scaler 插件监听消息队列、数据库等外部系统的指标，将业务事件转化为伸缩决策的依据。它不负责指标采集、镜像构建或 API 认证。

Q5. 容量规划中“资源饱和度”通常指什么？

单选题 · mid

A.实际使用资源占总容量的百分比← 正确答案
B.系统中空闲资源的绝对数量
C.服务器开机所消耗的电力总量
D.应用程序代码的复杂度

答案：A。资源饱和度是“已用资源 / 总容量”的比值，它揭示系统离极限有多远。类比面馆，饱和度不是“店里有几张空椅子”（空闲资源绝对数），而是“坐了八成客人的上座率”。饱和度越高，系统承受突发负载的能力越弱，这正是自动伸缩的触发依据。

Q6. VPA 调整 Pod 资源请求后，通常为什么需要重启 Pod？

单选题 · mid

A.资源 requests 只在 Pod 创建时生效← 正确答案
B.重启可以提升 CPU 频率
C.不重启会导致数据丢失
D.重启是清理内存的唯一方法

答案：A。Kubernetes 的资源配置在 Pod 创建时写入容器运行时，运行中无法热更新 requests。VPA 修改资源规格后必须重建 Pod 才能让新配置生效——如同换新的灶台必须停火几分钟。这也是 VPA 与 HPA 需协同设计的原因：频繁重启会影响可用性，水平伸缩反而更适合应对实时波动。

Q7. 预测驱动的容量规划在实践中的典型做法有哪些？

多选题 · hard

A.用历史数据训练模型预测未来负载← 正确答案
B.根据预测动态调整 HPA 最小副本数← 正确答案
C.完全取消实时 HPA 的监控
D.在大促前提前扩容并逐步释放← 正确答案

答案：ABD。预测驱动的核心是“用历史推测未来”，并将预测结果用于提前配置容量：调整 HPA 最小值、预置工作负载、按时间窗口扩缩容。选项 C 说取消实时监控大错特错——预测只是设定基线水位，实时 HPA 仍需监控兜底，应对预测误差和突发流量。

Q8. 告警阈值设计中使用“μ + kσ”策略的目的是什么？

单选题 · easy

A.过滤偶发波动，只告警真正的异常← 正确答案
B.让所有告警都延迟一小时发出
C.降低监控系统的采样频率
D.强制所有指标都为非负值

答案：A。μ 是历史均值，σ 是波动标准差，μ+kσ 定义了“正常抖动的上限”。当指标超过这个上限才触发告警，能过滤掉正常范围内的随机波动。这好比面馆的报警器只在温度超过日常煮面温度+3σ 才响，不会因为烧一壶开水就误报。

Q9. 哪些措施可以有效降低自动伸缩中的“冷启动”影响？

多选题 · hard

A.提前扩容做好预热← 正确答案
B.使用预测驱动的容量规划← 正确答案
C.调低 HPA 的扩容灵敏度
D.保留一定数量的空闲 Pod 作为缓冲← 正确答案

答案：ABD。Pod 从创建到就绪需要拉镜像、初始化、加载缓存，冷启动可能花费数十秒。通过预测提前扩容（A）、随时保有缓冲副本（D）、用 KEDA 对队列深度响应（属于自动检测），都能缓解冷启动带来的延迟。C 项调低扩容灵敏度恰恰会加重冷启动问题，因为反应更慢了。

Q10. 关于 HPA、VPA、KEDA 三者的配合方式，哪些说法是正确的？

多选题 · hard

A.HPA 管数量，VPA 管规格，二者可以并行使用← 正确答案
B.KEDA 通过 Scaler 把事件信号交给 HPA 执行← 正确答案
C.VPA 可以完全替代 KEDA 处理消息队列积压
D.三者配合时需避免针对同一指标重复伸缩← 正确答案

答案：ABD。HPA 和 VPA 分别从横向和纵向扩展资源，可以协同工作（A）；KEDA 本质上是一个事件驱动的 HPA 增强器，Scaler 检测事件后触发 HPA 调整副本（B）；三者共存时需要明确各自关注的指标，避免冲突（D）。C 错误：VPA 只看资源规格，完全不感知消息队列积压。