2. Kubernetes弹性伸缩基础：HPA原理与局限、Pod生命周期与资源请求/限制、Cluster Autoscaler简介
2.1 弹性伸缩的核心维度
Kubernetes 的弹性伸缩并非单一机制，而是由三个独立但可协同的维度构成。理解这三个维度是掌握 KEDA 与 Knative 协同工作的前提。
| 维度 | 组件 | 作用范围 | 伸缩对象 | 典型响应时间 |
|---|---|---|---|---|
| Pod 水平 | Horizontal Pod Autoscaler (HPA) | 单个 Workload (Deployment/StatefulSet) | Pod 副本数 | 15s – 5min |
| Pod 垂直 | Vertical Pod Autoscaler (VPA) | 单个 Workload | Pod 的 CPU/内存请求值 | 分钟级（需重建 Pod） |
| 集群节点 | Cluster Autoscaler (CA) | 整个集群 | Node 数量 | 1 – 10min（取决于云商） |
课程聚焦： 本章重点讲解 HPA（水平伸缩）和 Cluster Autoscaler（节点伸缩），因为 KEDA 本质上是 HPA 的增强替代方案，而 Knative 的 Serverless 弹性最终依赖节点级资源的供给。
2.2 HPA 原理与工作流程
HPA 是 Kubernetes 内置的 Pod 水平自动扩缩容控制器。它周期性地（默认 15s）根据 CPU、内存或自定义指标调整目标 Workload 的副本数。
- 指标采集： Metrics Server 从 Kubelet 的 cAdvisor 接口聚合 Pod 的 CPU/内存使用率。
- 计算期望副本： HPA Controller 根据公式
期望副本数 = ceil[当前副本数 × (当前指标值 / 目标指标值)]计算。 - 更新 Workload： 通过 API 修改 Deployment/StatefulSet 的
spec.replicas字段。 - ReplicaSet 调整： Deployment 控制器驱动 ReplicaSet 创建或销毁 Pod。
2.3 HPA 的局限性与痛点
HPA 在设计上存在若干限制，这些限制正是 KEDA 和 Knative 要解决的核心问题。
| 局限性 | 具体表现 | 对流水线场景的影响 |
|---|---|---|
| 指标源单一 | 原生仅支持 CPU/Memory 和 Prometheus/Custom Metrics API 的简单集成 | 无法直接根据消息队列积压、HTTP 请求排队长度等业务指标伸缩 |
| 无“缩容到零”能力 | HPA 最小副本数只能设为 1，无法缩容到 0 | 流水线空闲时仍需保留至少一个 Pod，造成资源浪费 |
| 冷却/稳定窗口僵化 | --horizontal-pod-autoscaler-downscale-stabilization 全局生效，无法按 Workload 差异化配置 | 短时突发流水线任务可能被冷却窗口延迟扩容 |
| 无事件驱动触发 | HPA 是轮询模型，无法感知 Kafka 消息、CRD 事件等异步事件 | 流水线触发延迟取决于 HPA 的轮询间隔（默认 15s） |
| 不支持外部指标队列深度 | 需要额外部署 Prometheus Adapter 或 Custom Metrics Adapter，配置复杂 | 增加运维复杂度，且 Adapter 本身可能成为性能瓶颈 |
关键认知： HPA 适合“持续型负载”的弹性伸缩，但对于“事件驱动型”和“突发型”的 CI/CD 流水线场景，其响应速度和灵活性均不足。KEDA 正是作为 HPA 的“事件驱动增强器”而诞生。
2.4 Pod 生命周期与资源请求/限制
弹性伸缩的最终执行单元是 Pod。理解 Pod 的生命周期阶段和资源模型，是配置合理伸缩策略的基础。
2.4.1 Pod 生命周期阶段
- Pending： Pod 已被 API 接受，但尚未调度到节点或镜像拉取中。调度器在此阶段检查资源请求。
- Running： Pod 已绑定到节点，至少一个容器正在运行。HPA 在此阶段采集指标。
- Succeeded： 所有容器正常退出（退出码 0）。流水线任务完成后的理想状态。
- Failed： 至少一个容器以非零退出码终止。需要重试或告警。
- Unknown： 节点失联或 kubelet 无响应。通常需要人工介入。
2.4.2 资源请求与限制
资源请求（requests）和限制（limits）是 HPA 和调度器决策的基础。
| 参数 | 含义 | 调度器作用 | HPA 作用 | CPU 特性 | 内存特性 |
|---|---|---|---|---|---|
| requests | Pod 保证能获得的最小资源量 | 节点必须满足所有 Pod 的 requests 总和 ≤ 节点容量 | HPA 默认基于 requests 计算利用率 | 可超卖（Burstable） | 不可超卖，超限即 OOMKill |
| limits | Pod 允许使用的资源上限 | 不影响调度决策 | 不直接影响 HPA，但影响 Pod 运行质量 | 受 CPU CFS 配额限制 | 硬限制，超过即触发 OOM |
流水线避坑： 如果流水线 Pod 的
requests 设置过高，会导致节点资源碎片化，Cluster Autoscaler 可能过度扩容；如果 limits 设置过低，编译或测试任务可能因 OOM 被 Kill。建议对流水线 Pod 使用 requests == limits（Guaranteed QoS），避免因资源争抢导致任务不稳定。
2.5 Cluster Autoscaler 简介
Cluster Autoscaler（CA）负责在节点资源不足时自动扩容集群，在节点利用率过低时缩容节点。它与 HPA 形成“Pod 级 + 节点级”的双层弹性。
- 扩容触发： 当 HPA 扩容 Pod 后，新 Pod 因节点资源不足进入 Pending 状态，CA 检测到 Pending Pod 后向云商 API 请求新节点。
- 缩容触发： 当 HPA 缩容 Pod 后，节点利用率持续低于阈值（默认 50%），CA 将节点上的 Pod 驱逐到其他节点，然后释放节点。
- 与 HPA 的协同： HPA 负责“水平扩缩 Pod”，CA 负责“水平扩缩节点”。两者配合可实现从 Pod 到基础设施的完整弹性闭环。
- 流水线场景价值： 当大量流水线任务并发触发时，HPA 快速扩容 Pod，CA 随后补充节点资源；任务完成后，HPA 缩容 Pod，CA 回收空闲节点，实现成本优化。
最佳实践： 在配置 CA 时，建议为流水线任务使用独立的节点组（Node Group），并设置
cluster-autoscaler.kubernetes.io/safe-to-evict: "false" 注解保护关键 Pod。同时，CA 的缩容间隔（默认 10min）应与 HPA 的冷却窗口协调，避免频繁的节点震荡。