4. 留痕概念与目的
在 K8s 灰度发布流水线中，容量基线留痕是指在每次发布批次推进时，将当前集群的副本数、资源分配、HPA 状态、Pod 分布等关键容量数据，以结构化快照的形式持久化保存。留痕不是简单的日志输出，而是一种可审计、可回放、可对比的工程实践。
4.1 留痕的定义
容量基线留痕 = 时间点 + 容量快照 + 元数据。每次发布批次（如 10% → 30% → 60% → 100%）执行前后，系统自动采集以下维度数据并写入持久化存储：
| 维度 | 采集内容 | 示例值 |
|---|---|---|
| 副本基线 | Deployment/StatefulSet 期望副本数、当前就绪副本数 | replicas: 30, ready: 28 |
| 资源分配 | requests/limits（CPU、内存）总量与利用率 | cpu request: 12C, usage: 45% |
| HPA 状态 | 当前 min/max/current 副本数、目标指标值 | min:10, max:100, current:30 |
| Pod 分布 | 各节点 Pod 数量、拓扑分布、AZ 分布 | node-1: 8, node-2: 10, node-3: 12 |
| 发布元数据 | 流水线 ID、批次号、触发人、镜像版本 | pipeline-20250321, batch-2, v2.1.3 |
关键原则：留痕数据必须包含 时间戳（RFC3339） 和 发布批次标识，确保每条记录可独立追溯。
4.2 为什么需要留痕
容量基线留痕不是可选项，而是生产级发布流水线的基础设施。以下四个核心场景决定了留痕的必要性：
4.2.1 审计 —— 谁在何时改变了容量
- 合规要求：金融、医疗等行业要求发布操作可审计，容量变更必须记录操作人、时间、变更前后值。
- 内部管控：多团队共享集群时，留痕提供容量变更的客观证据，避免“谁改了什么”的扯皮。
- 审计日志示例：
2025-03-21T14:30:00Z | pipeline-123 | batch-2 | user:zhangsan
replicas: 20 → 30 | cpu_request: 8C → 12C | status: success4.2.2 回滚 —— 快速恢复到已知安全容量
- 灰度发布过程中，如果新版本导致 Pod 频繁 OOM 或 HPA 异常扩容，需要立即回退到上一批次的容量基线。
- 留痕数据可直接驱动
kubectl scale或 Argo Rollout 的setReplicas操作，实现秒级回滚。 - 回滚流程：
- 从存储中读取上一批次容量快照。
- 比对当前容量与快照差异。
- 执行
kubectl scale deployment/<name> --replicas=<snapshot_replicas>。 - 验证就绪副本数达到快照值。
最佳实践：回滚时不仅恢复副本数，还应恢复 HPA 的 min/max 配置，避免 HPA 立即将副本数再次拉高。
4.2.3 合规 —— 满足 SLA 与监管要求
| 合规场景 | 留痕提供的证据 | 典型监管标准 |
|---|---|---|
| 容量变更审批 | 发布批次与容量快照的关联记录 | SOX, PCI-DSS |
| 资源使用审计 | 每个时间点的资源分配与利用率 | ISO 27001 |
| 灾难恢复演练 | 历史容量基线可作为恢复目标 | BCP/DR 规范 |
| 容量规划报告 | 多次发布的容量变化趋势 | 内部 IT 审计 |
4.2.4 问题追溯 —— 定位容量相关故障根因
- 场景 A：发布后出现 502 错误。通过留痕发现该批次副本数从 30 降到了 20，而流量未降，导致单 Pod 负载过高。
- 场景 B：HPA 频繁扩缩容。追溯留痕数据发现上一批次 HPA 的
targetCPUUtilizationPercentage被误改为 30%（原为 70%）。 - 场景 C：节点资源耗尽。对比 Pod 分布留痕发现新版本 Pod 全部调度到了同一可用区，未遵循拓扑分布策略。
注意：留痕数据本身不解决故障，但它提供了可对比的基准线。没有留痕，问题追溯只能依赖运维人员的记忆和零散日志，效率极低且容易遗漏关键信息。
4.3 留痕 vs 日志 vs 监控
| 对比维度 | 容量基线留痕 | 应用日志 | 监控指标 |
|---|---|---|---|
| 数据形态 | 结构化快照（JSON/YAML） | 非结构化文本 | 时序数值 |
| 保存周期 | 按发布批次长期保存（月/年） | 短期（天/周） | 中短期（周/月） |
| 主要用途 | 审计、回滚、合规、追溯 | 调试、异常排查 | 实时告警、趋势分析 |
| 关联性 | 与发布批次强关联 | 与请求/事件关联 | 与时间窗口关联 |
| 存储成本 | 低（仅快照，非全量） | 高（全量文本） | 中（采样或聚合） |
总结：留痕不是日志的替代品，也不是监控的重复建设。它是连接发布操作与容量状态的桥梁，为审计、回滚、合规和问题追溯提供结构化、可对比、可回放的数据基础。在 K8s 灰度发布流水线中，容量基线留痕是保障发布安全与可运维性的关键一环。