大家好，我是张晋涛。

在前面的几期中，我们介绍了 GitOps 的相关概念、部署流程及实现工具（Argo CD & FluxCD），感兴趣的小伙伴，欢迎回顾前文。本期，我们重点来介绍下，Canary -- 金丝雀发布的相关内容，在下一期中还有 Canary 实践，请多关注，谢谢。

什么是 Canary （金丝雀）部署/发布？

在进行持续交付时，我们需要一定的部署策略用于更改、升级或回滚正在运行的应用程序实例。我们常见的部署策略有 Basic, Multi-Service, Rolling, Blue/Green, Canary, A/B Testing, Shadow 等。

我们的金丝雀类似于下图中的蓝绿色示例，通过 Canary 部署并获取生产流量，然后我们可以监控一定时间（如一小时）的金丝雀健康（延迟、错误等），以决策是否继续扩大绿色部署并将所有流量路由到绿色或者将所有流量路由回蓝色服务。

图 1，10%流量将流向绿色节点

图 2，如果没有错误，绿色部署会放大，蓝色部署会缩小。蓝色部署缩至最小后，气泡图和条形图都将显示 100% 绿色。

起源

“ Canary （金丝雀部署/发布）”这种命名来源于 19 世纪一种古老的煤矿开采技术。矿井中通常会含有一氧化碳和其他可能导致矿工死亡的危险气体。金丝雀对空气中的毒素比人类更敏感，因此它们会被用作早期探测器，保障矿工的安全。

在Canary （金丝雀部署/发布）中，一小部分用户会优先使用到新的版本及功能，用于验证该版本是否满足其设定的要求。当然，这一小部分用户同样可以检测潜在的错误和中断，而不会影响其他所有正在运行的系统。

选择哪些用户会看到 Canary 是有不同的策略的，即如何挑选“一小部分”用户：

在 GitOps 中，金丝雀发布（Canary Release）和金丝雀部署（Canary Deployments）都是指渐进式发布，即 20%生效；40%生效；··· 100%生效。

但是，在 DevOps 中，金丝雀发布和金丝雀部署还是存在些许差异的。在《GitOps 应用与实践系列（一）》中，我们简单介绍过，开发环境、QA环境、预上线环境、生产环境等，各个环境之间是需要 DevOps 来进行流程把控的。在这个过程中，不同环境的 Canary 过程可能会用不同的名词区分。

如下所示，

图 3， CanaryRelease 示图

图 4， CanaryDeployments 示图

在云原生时代，已演变成基于 K8S 的基础设施环境，这也让传统的 Canary 发布/部署观念发生了改变。