Canary部署是在一部分用户上测试新代码的非常有效的方法。 由于它仅在特定子组中发生，因此可以大大减少流量负载，这可能在部署过程中引起问题。 本文专门介绍如何使用Kubernetes和部署自动化来组织类似的部署。
假设您对Helm和Kubernetes资源有所了解 。
Kubernetes的简单金丝雀部署包括两个关键资源：服务本身和部署工具。 Canary部署通过一项服务工作，该服务与为更新流量提供服务的两种不同资源进行交互。 其中一种资源将与“ canary”版本一起使用，第二种资源将与稳定版本一起使用。 在这种情况下，我们可以调整Canary版本的数量，以减少维护所需的流量。 例如，如果您更喜欢使用Yaml，则在Kubernetes中将如下所示：
kind: Deployment metadata: name: app-canary labels: app: app spec: replicas: 1 ... image: myapp:canary --- kind: Deployment metadata: name: app labels: app: app spec: replicas: 5 ... image: myapp:stable --- kind: Service selector: app: app # Selector will route traffic to both deployments.
甚至可以想象在kubectl上有这样一个选项，而且
Kubernetes文档甚至包含有关此场景的完整教程。 但是这篇文章的主要问题是我们如何使用Helm自动执行此过程。
金丝雀部署的自动化
首先，我们需要Helm Chart Map，该地图已经包含了我们上面讨论的资源。 它看起来应该像这样：
~/charts/app ├── Chart.yaml ├── README.md ├── templates │ ├── NOTES.txt │ ├── _helpers.tpl │ ├── deployment.yaml │ └── service.yaml └── values.yaml
Helm概念的基础是多版本发行版的管理。 稳定版本是我们项目代码的主要稳定分支。 但是使用Helm，我们可以使用我们的实验代码来部署canary版本。 最主要的是保持稳定版本和Canary版本之间的流量交换。 我们将使用特殊的选择器来管理所有这些：
selector: app.kubernetes.io/name: myapp
我们的“ canary”资源和稳定的部署资源都将在模块上指示此标签。 如果一切设置正确，则在部署Helm图表的Canary版本期间，我们将看到流量将定向到新部署的模块。 此命令的稳定版本如下所示：
helm upgrade --install myapp \ --namespace default \ --set app.name=myapp \ # Goes into app.kubernetes.io/name --set app.version=v1 \ # Goes into app.kubernetes.io/version --set image.tag=stable \ --set replicaCount=5
现在，让我们看看我们的金丝雀版本。 要部署金丝雀版本，我们需要记住两件事。 版本名称必须不同，这样我们才不会在当前的稳定版本上汇总更新。 版本和标签也必须不同，以便我们可以部署不同的代码并通过资源标签识别差异。
helm upgrade --install myapp-canary \ --namespace default \ --set app.name=myapp \ # Goes into app.kubernetes.io/name --set app.version=v2 \ # Goes into app.kubernetes.io/version --set image.tag=canary \ --set replicaCount=1
仅此而已！ 如果您对服务执行ping操作，则可以看到金丝雀更新仅在部分时间内路由流量。
如果您正在寻找包含上述逻辑的部署自动化工具，请
在GitHub上查看
Deliverybot和
Helm自动化工具 。 用于实现上述方法的Helm图表位于Github上，
就在此处 。 总的来说，这是关于如何在实践中实现金丝雀版本部署的理论概述，并带有特定的概念和示例。