2. K8s 发布流水线基础回顾：CI/CD 流水线概念、K8s 原生发布方式与常见策略对比
2.1 CI/CD 流水线核心概念
CI/CD（持续集成/持续交付）是云原生发布流水线的基石。在 K8s 平台中，流水线将代码变更自动转化为集群中的运行负载，其核心阶段如下：
| 阶段 | 关键活动 | 产出物 |
|---|---|---|
| 持续集成 (CI) | 代码合并、静态检查、单元测试、镜像构建与扫描 | 带唯一 Tag 的容器镜像 |
| 持续交付 (CD) | 环境部署、配置注入、冒烟测试、灰度验证 | 运行中的 K8s 工作负载 |
| 持续部署 (可选) | 自动触发生产发布、全自动金丝雀/蓝绿切换 | 生产环境版本更新 |
SRE 视角： 发布窗口防护验证通常嵌入在 CD 阶段的“准入检查”环节，在流量切换前拦截配置错误、资源不足或健康检查失败等风险。
2.2 K8s 原生发布方式：Deployment 与 RollingUpdate
K8s 中最核心的发布控制器是 Deployment，它通过 ReplicaSet 管理 Pod 副本，并内置了 RollingUpdate（滚动更新） 策略。理解其工作原理是设计防护验证的前提。
2.2.1 Deployment 发布流程
- 用户更新 Deployment 的 Pod 模板（如镜像版本）。
- 控制器创建 新的 ReplicaSet，并逐步增加新 Pod 副本数。
- 控制器缩容 旧的 ReplicaSet，逐步减少旧 Pod 副本数。
- 滚动过程 受
maxSurge和maxUnavailable参数控制。
# Deployment 滚动更新示例（YAML 片段）
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # 更新期间最多允许超出期望副本数 1 个
maxUnavailable: 0 # 更新期间不允许有不可用 Pod
template:
spec:
containers:
- name: app
image: my-app:v2.0.0
readinessProbe:
httpGet:
path: /healthz
port: 8080
关键参数：
- maxSurge：滚动更新期间，允许超出期望副本数的最大 Pod 数（值或百分比）。
- maxUnavailable：滚动更新期间，允许不可用 Pod 的最大数量（值或百分比）。
- minReadySeconds：新 Pod 就绪后，等待多少秒后才视为可用，用于防止抖动。
2.2.2 RollingUpdate 滚动更新示意图
2.3 常见发布策略对比
除了 K8s 原生的 RollingUpdate，生产环境中还广泛使用蓝绿部署、金丝雀发布等策略。不同策略在风险控制、资源消耗和发布速度上各有优劣。
| 策略 | 原理 | 风险等级 | 资源开销 | 回滚速度 | 适用场景 |
|---|---|---|---|---|---|
| 滚动更新 (RollingUpdate) | 逐步替换旧 Pod，新老版本共存 | 中 | 低（无需额外副本） | 慢（需逐步回滚） | 常规迭代、无状态服务 |
| 蓝绿部署 (Blue/Green) | 同时运行两套完整环境，一次性切换流量 | 低 | 高（双倍资源） | 快（立即切回） | 关键业务、数据库迁移 |
| 金丝雀发布 (Canary) | 先让少量新版本接收流量，验证后再全量 | 极低 | 中（需额外金丝雀副本） | 快（停止金丝雀流量） | 大版本变更、A/B 测试 |
| 重建 (Recreate) | 先删除所有旧 Pod，再创建新 Pod | 高 | 低（无重叠） | 慢（需重建全部） | 开发环境、有状态应用 |
2.3.1 蓝绿部署与金丝雀发布流程对比图
发布窗口防护要点：
- 滚动更新：需验证
maxUnavailable是否会导致服务降级，以及 Readiness Probe 是否准确反映业务就绪状态。 - 蓝绿部署：切换前必须验证新环境的完整性和数据一致性，避免流量切换后出现大面积错误。
- 金丝雀发布：需设置合理的流量比例和监控指标，一旦错误率上升应立即自动回退。
2.4 发布策略选择矩阵
在实际生产环境中，选择发布策略需要综合考虑服务特性、团队能力和基础设施条件。以下矩阵可作为决策参考：
| 评估维度 | 推荐策略 | 原因 |
|---|---|---|
| 无状态微服务，迭代频繁 | 滚动更新 | 资源利用率高，自动化程度高 |
| 核心交易链路，变更风险高 | 蓝绿部署 | 瞬时切换，回滚极快，风险可控 |
| 新功能验证，需真实流量反馈 | 金丝雀发布 | 小范围验证，可精确控制影响面 |
| 有状态应用，数据迁移复杂 | 蓝绿部署 + 数据同步 | 避免数据不一致，支持回滚 |
| 开发/测试环境 | 重建 (Recreate) | 简单直接，无需考虑滚动兼容性 |
SRE 最佳实践： 在发布流水线中，建议将发布策略作为可配置参数，通过 Pipeline 参数化 实现不同环境使用不同策略。例如：开发环境用 Recreate，预发环境用 RollingUpdate，生产环境用蓝绿或金丝雀。发布窗口防护验证逻辑应适配所选策略，确保在流量切换前完成所有前置检查。