别再“手滑上线”了：Kubernetes 部署策略全家桶 + Flagger 实战聊透

大家好，我是 Echo_Wish。

只要你在 Kubernetes 上干过活，就一定经历过这种瞬间👇：

kubectl apply -f deployment.yaml
回车的一刹那
心里默念：千万别出事，千万别出事……

然后 5 分钟后，群里有人说：

“怎么感觉刚刚有点慢？”
“是不是刚发版了？”

——恭喜你，经典运维时刻。

所以今天我们不聊“怎么部署一个 Pod”，而是聊一个更现实的问题：

在 Kubernetes 上，代码到底应该怎么“安全地”上线？

这就绕不开三个老朋友：

• 蓝绿部署（Blue-Green）
• 金丝雀发布（Canary）
• 渐进式发布（Progressive Delivery）

以及一个把它们自动化、工程化的狠角色：Flagger。

一、先说结论：发布策略，决定你是“英雄”还是“背锅侠”

我先把话放这儿：

发布策略选不好，监控、报警、SRE 全是安慰剂。

很多事故不是代码写炸了，而是：

• 新版本确实有问题
• 但你一口气让 100% 用户去试毒

这不是技术问题，这是发布方式问题。

二、蓝绿部署：最稳，但也最“壕”

蓝绿部署是啥？

一句话版本：

线上永远有两套环境：一套在服务，一套在待命

• Blue：当前稳定版本
• Green：新版本

流量一刀切过去，不行就切回来。

Kubernetes 里怎么搞？

典型做法是两套 Deployment + Service 切 selector。

apiVersion: v1
kind: Service
spec:
  selector:
    app: myapp
    version: green

优点很明显：

• 回滚极快
• 思路简单
• 特别适合 核心系统 / 金融 / 交易链路

但我说句实话：

蓝绿部署 = 拿资源换安全

你得有：

• 双倍资源
• 双倍环境成本
• 双倍配置维护

所以在我实际经验里：

• 核心链路：蓝绿
• 普通业务：没必要强上

三、金丝雀发布：最常见，也最容易“翻车”

金丝雀发布在干嘛？

先放 1% 用户试试水，没问题再慢慢放大。

在 Kubernetes 里，常见手段有：

• 多个 Deployment
• 调整副本比例
• Ingress / Service Mesh 控流

示意：

replicas: 1  # canary
replicas: 9  # stable

金丝雀的灵魂是什么？

不是“放一点流量”，而是这四个字：

边看指标，边放流量

但现实中很多金丝雀是这样的：

• 发 10%
• 过 10 分钟
• “好像没炸”
• 直接 100%

我管这叫：

“玄学金丝雀”

四、渐进式发布：别急，系统也需要“心理缓冲期”

渐进式发布，本质上是金丝雀的工程化升级版：

• 每一步都有规则
• 每一步都有指标
• 每一步都能自动回滚

发布流程像这样：

5% → 10% → 25% → 50% → 100%

每一步都要回答一个问题：

系统现在，还好吗？

而这，正是 Flagger 擅长的地方。

五、Flagger 是干嘛的？一句话讲清楚

我第一次用 Flagger 的时候，最大的感受是：

“终于有人替我盯着发布过程了。”

Flagger 是一个 Kubernetes 原生的：

• 渐进式发布控制器
• 自动金丝雀分析
• 自动回滚执行器

它会帮你做三件事：

1. 控制流量比例
2. 持续分析指标
3. 不行就回滚，不用你点鼠标

六、Flagger 实战：它到底怎么“看数据”？

一个典型的 Canary 配置（简化版）：

apiVersion: flagger.app/v1beta1
kind: Canary
spec:
  analysis:
    interval: 1m
    threshold: 5
    metrics:
    - name: request-success-rate
      thresholdRange:
        min: 99
    - name: request-duration
      thresholdRange:
        max: 500

这段配置的意思非常“人话”：

• 每 1 分钟评估一次
• 连续 5 次不达标就回滚
• 成功率 < 99%？不行
• 延迟 > 500ms？不行

注意：这里不是“看一眼”，而是“持续盯”

七、Flagger 真正的价值：把“发布经验”写进系统

说点掏心窝子的。

很多发布事故，本质上是：

• 有经验的人没盯
• 新人不敢回滚
• 值班的人不知道该不该停

Flagger 做的事情是：

把“老运维的判断逻辑”，变成机器规则

• 指标不好 → 自动停
• 趋势变坏 → 自动回滚
• 不需要你拍脑袋

这对团队来说，意义非常大。

八、我的真实建议：别追“高级”，要追“可控”

说句可能不太“酷”的话：

不是每个团队，都需要最复杂的发布策略

我自己的选择是：

• 小团队 + 非核心系统
  👉 金丝雀 + 简单监控
• 核心系统 / SLA 高
  👉 蓝绿 或 Flagger
• 微服务多、发布频繁
  👉 渐进式 + 自动回滚

最怕的是哪种？

流程复杂，但没人真正理解

那不是高级，那是风险堆叠。

九、写在最后

上线不是一瞬间的事，而是一个过程。

Kubernetes 给了我们足够多的工具，但真正决定系统稳不稳的，是：

• 你愿不愿意慢一点
• 你有没有把“失败”当成正常路径
• 你是否允许系统自己踩刹车

记住一句话：

发布策略不是为了“炫技”，是为了让你晚上睡得着。