别再“手滑上线”了：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 原生的：
- 渐进式发布控制器
- 自动金丝雀分析
- 自动回滚执行器
它会帮你做三件事：
- 控制流量比例
- 持续分析指标
- 不行就回滚，不用你点鼠标
六、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 给了我们足够多的工具，但真正决定系统稳不稳的，是：
- 你愿不愿意慢一点
- 你有没有把“失败”当成正常路径
- 你是否允许系统自己踩刹车
记住一句话：
发布策略不是为了“炫技”，是为了让你晚上睡得着。
