4. 削峰策略基础：流量突发与资源弹性、HPA与KPA的区别、削峰对安全的影响
4.1 流量突发与资源弹性：削峰的核心驱动力
在 Serverless 架构中，流量突发（Traffic Burst）是常态而非异常。Knative 的削峰策略本质上是在流量高峰与资源供给之间建立动态平衡。理解流量突发与资源弹性的关系，是掌握削峰安全影响的前提。
核心指标： 削峰策略的效能通常由三个关键指标衡量：
- 冷启动延迟（Cold Start Latency）： 从请求到达到 Pod Ready 的时间，通常目标 < 100ms。
- 弹性伸缩速度（Scaling Velocity）： 每秒可增加的 Pod 副本数，KPA 可达 10+ Pods/s。
- 资源利用率（Resource Utilization）： 目标 CPU/内存使用率，通常设定在 60%-80% 之间。
流量突发模型可抽象为三个阶段：
- 蓄积期（Ramp-up）： 请求量从基线快速上升，触发弹性伸缩。
- 峰值期（Peak）： 请求量达到最高点，资源供给达到最大副本数。
- 消退期（Ramp-down）： 请求量下降，系统回收多余资源。
4.2 HPA 与 KPA 的区别：两种伸缩策略的深度对比
Knative 支持两种弹性伸缩策略：Kubernetes HPA（Horizontal Pod Autoscaler） 和 Knative KPA（Knative Pod Autoscaler）。两者在削峰场景下的行为差异显著，直接影响安全策略的制定。
| 对比维度 | HPA（Kubernetes 原生） | KPA（Knative 原生） |
|---|---|---|
| 伸缩指标 | CPU / 内存利用率（支持自定义指标） | 并发请求数（Concurrency） |
| 伸缩粒度 | 分钟级（默认 15s 采样周期） | 秒级（基于请求队列深度实时决策） |
| 冷启动支持 | 不支持（需配合 Cluster Autoscaler） | 原生支持（Activator 缓存请求） |
| 缩容到零 | 不支持（最小副本数通常 ≥ 1） | 支持（空闲时缩容到 0） |
| 削峰响应速度 | 较慢（依赖指标采集与聚合） | 快速（基于实时并发量） |
| 安全影响 | 资源争抢可能导致 DoS 放大 | 并发控制不当可能引发请求积压 |
安全建议： 在削峰场景下，优先使用 KPA 作为默认伸缩策略。KPA 的秒级响应能力可以更精确地匹配流量突发，减少因过度预配（Over-provisioning）带来的攻击面扩大风险。HPA 更适合需要基于 CPU/内存进行资源控制的混合负载场景。
4.3 削峰对安全的影响：攻击面分析与风险矩阵
削峰策略在提升系统弹性的同时，也引入了新的安全风险。以下是削峰场景下的主要安全影响分析：
4.4 削峰安全风险矩阵与缓解措施
基于上述分析，我们整理出削峰场景下的安全风险矩阵及对应的缓解措施：
| 风险编号 | 风险名称 | 风险等级 | 触发条件 | 缓解措施 |
|---|---|---|---|---|
| R-001 | 资源耗尽攻击 | 高 | 攻击者构造大量并发请求，触发 KPA 快速扩容，耗尽集群节点资源 | 设置 maxReplicas 上限；配置 ResourceQuota；启用 PodDisruptionBudget |
| R-002 | 冷启动风暴 | 中 | 流量突发导致大量 Pod 同时冷启动，镜像拉取和容器初始化造成 I/O 风暴 | 启用 imagePullPolicy: IfNotPresent；预热缓存；设置 startupProbe |
| R-003 | 并发控制失效 | 中 | KPA 并发数配置过高，导致单个 Pod 处理过多请求，引发内存溢出或数据竞争 | 设置 containerConcurrency（建议 ≤ 100）；启用 requests.limit 硬限制 |
| R-004 | 审计日志丢失 | 低 | 削峰期间日志采样率不足，导致安全事件无法追溯 | 配置 audit-log-sampling-rate ≥ 10%；启用 structured logging |
关键安全基线： 在 Knative 削峰场景下，必须同时配置以下三个参数，否则视为安全违规：
spec.maxReplicas：最大副本数，防止无限扩容。spec.containerConcurrency：单 Pod 最大并发请求数，防止资源过载。spec.timeoutSeconds：请求超时时间，防止请求长时间占用资源。
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: secure-service
spec:
template:
spec:
containerConcurrency: 50
timeoutSeconds: 300
traffic:
- latestRevision: true
percent: 100
autoscaling:
maxReplicas: 20
minReplicas: 04.5 削峰策略的安全配置清单
以下是削峰策略实施前必须完成的安全配置检查清单：
- 资源配额检查： 确认命名空间已配置
ResourceQuota，限制 CPU 和内存总量。 - 并发限制检查： 确认
containerConcurrency已设置，且值 ≤ 100。 - 副本限制检查： 确认
maxReplicas已设置，且值 ≤ 50（根据集群容量调整）。 - 审计日志检查： 确认 Knative 审计日志已启用，采样率 ≥ 10%。
- 网络策略检查： 确认
NetworkPolicy已配置，限制削峰期间的 Pod 间通信。 - 镜像拉取策略检查： 确认
imagePullPolicy: IfNotPresent，避免冷启动风暴。
实践案例： 某金融科技公司在生产环境中遭遇削峰攻击。攻击者利用 KPA 的快速扩容特性，在 30 秒内将 Pod 副本数从 2 扩展到 200，导致集群节点资源耗尽。事后分析发现，
maxReplicas 未设置上限，且 containerConcurrency 配置为 0（无限制）。修复措施：设置 maxReplicas: 30，containerConcurrency: 50，并启用审计日志采样率 20%。修复后，类似攻击仅导致 Pod 数扩展到 30，系统正常运行。