K8s 金丝雀部署（Canary Deployment）学习笔记
本笔记基于Kubernetes v1.29相关教程整理，涵盖金丝雀部署的概念、价值、实操步骤及注意事项。
金丝雀部署概念起源
- 名称灵感来源于17世纪英国矿工的瓦斯检测传统：金丝雀对瓦斯气体敏感，中毒前会停止唱歌，矿工借此以极小代价提前发现危险，避免自身伤亡，该理念后被引入软件部署领域。
软件开发发布流程背景
- 标准发布流程：产品提出需求→项目经理评估可行性、拆分开发任务→开发人员（前端/后端/小程序等）完成代码编写→测试人员验证功能性与安全性→运维人员将代码打包发布到生产环境供用户访问。
- 行业现实：人是最大的故障点，开发、测试均无法100%保证代码无问题，因此上线后经常需要修复bug，直接全量上线风险极高。
金丝雀部署核心价值与原理
- 核心理念：用小范围的少量实例/用户作为灰度测试样本，验证新版本代码的可靠性，再逐步全量上线，降低故障影响面。
- 对比全量更新风险：如果直接全量将v1.0替换为v2.0，一旦出现问题会波及100%用户；而金丝雀部署先上线少量v2.0实例，与v1.0实例共存，仅小部分用户访问新版本，验证无问题再逐步替换全量，有问题直接回滚，风险极低。
- 概念说明：金丝雀是部署理念，不强制要求特定控制器，也不要求必须2个版本，只要是少量新版本灰度测试均符合要求，但版本数量过多（如几十上百个）会失去灰度意义。
金丝雀部署实操演示
前置操作
清理历史实验资源避免影响本次实验，已有的svc资源无需重新创建。
1. 修改Deployment滚动更新策略
- 初始状态：Deployment副本数为10，镜像版本为v1.0，默认滚动更新策略为
maxSurge=15%（允许最多超过期望副本数15%）、maxUnavailable=15%（允许最多15%实例不可用）。 - 修改目标：将策略调整为
maxSurge=1（允许最多多1个实例）、maxUnavailable=0（不允许实例不可用），实现“最多多1个、不少1个”的滚动更新规则。 - 实现方式：使用
kubectl patch命令小范围修改资源，无需修改完整YAML，命令示例如下：kubectl patch deployment demo -p '{"spec":{"template":{"spec":{"containers":[{"name":"demo","image":"v2.0"}]}}}}' - 命令说明：单引号包裹整体JSON内容，通过层级路径精准定位Deployment下的容器镜像字段；如果Deployment包含多个容器，需通过
containers[下标]指定要修改的容器，避免修改错误。 - 执行后验证：Deployment的滚动更新策略已成功修改为目标值。
2. 触发金丝雀部署
- 操作步骤：先修改Deployment的镜像版本从v1.0改为v2.0，立即执行
kubectl rollout pause deployment demo暂停滚动更新。 - 执行结果：10个v1.0旧实例 + 1个v2.0新实例共存，总Pod数为11，符合金丝雀部署的灰度状态。
- 流量验证：访问服务时大部分请求仍打到v1.0，仅少量请求打到v2.0；K8s默认Service基于iptables实现负载均衡，存在会话保持特性，后续切换为ipvs可实现严格的10:1流量比例。
3. 新版本验证后恢复全量更新
- 如果验证v2.0无问题，执行
kubectl rollout resume deployment demo恢复滚动更新，K8s会逐步销毁v1.0实例、创建v2.0实例，直到所有实例均为v2.0，完成全量上线。
4. 版本回滚操作
- 如果验证v2.0存在问题，执行
kubectl rollout undo deployment demo即可回滚到上一个版本（v1.0）。 - 回滚原理：K8s通过调整不同ReplicaSet的期望副本数实现版本切换，回滚时会将当前版本的ReplicaSet期望副本数设为0，上一个版本的ReplicaSet期望副本数恢复为原有副本数。
- 回滚顺序说明：回滚历史按操作顺序记录，例如升级顺序为v1.0→v2.0→v3.0时，第一次回滚回到v2.0，第二次回滚会回到v3.0（上一操作记录），而非v1.0；如果需要回滚到指定历史版本，可使用
kubectl rollout undo --to-revision=版本号参数。
5. 查看操作状态与历史
- 查看当前滚动更新/回滚的执行状态：执行
kubectl rollout status deployment demo，命令执行成功返回码为0，适合在脚本中判断操作是否成功。 - 查看回滚历史记录：执行
kubectl rollout history deployment demo，可查看所有版本的操作记录、版本号等信息。
金丝雀部署注意事项
- 滚动更新幅度需合理，
maxSurge和maxUnavailable不建议超过25%，避免大规模业务场景下一次性替换过多实例，导致大量用户连接中断。 - 资源修改方式灵活，小范围修改适合用
kubectl patch，大范围修改可写完整YAML后用kubectl apply，按需选择即可。
AI 总结
本视频系统讲解了Kubernetes中金丝雀部署（Canary Deployment）的完整知识体系：从其源于矿工检测瓦斯的理念起源，到结合软件开发发布流程说明其降低上线风险的核心价值，再通过实操演示了修改滚动更新策略、触发灰度发布、暂停/恢复更新、执行回滚、查看操作状态与历史的全流程，最后说明了滚动幅度控制等实操要点，帮助观众掌握用K8s原生能力实现安全灰度部署的方法。