注意事项 perev。：Weaveworks的这篇复习材料介绍了最流行的应用程序部署策略，并讨论了使用Kubernetes运算符Flagger实施其中最高级的策略的可能性。 它用简单的语言编写，并包含可视化图表，即使是新手工程师也可以理解该问题。
该图取自在Container Solutions进行的另一种推广策略审查 。如今，开发云原生应用程序中最大的问题之一就是部署部署。 通过微服务方法，开发人员已经在使用全模块化应用程序并对其进行设计，从而允许不同的团队编写代码并同时对应用程序进行更改。
较短且更频繁的部署具有以下优点：
- 缩短了上市时间。
- 新功能可以更快地吸引用户。
- 用户反馈更快地到达开发团队。 这意味着团队可以补充职能并更快地解决问题。
- 开发人员的士气提高了：在开发中使用大量功能会更有趣。
但是，随着发布频率的增加，对应用程序可靠性或用户体验产生不利影响的机会也会增加。 因此，对于运营团队和DevOps而言，以最小化产品和用户风险的方式构建流程和管理部署策略非常重要。 （
在此处了解有关CI / CD管道自动化的更多信息。）
在本出版物中，我们将讨论Kubernetes中的各种部署策略，包括滚动部署和更高级的方法（例如，canary推出及其变体）。
部署策略
您可以根据目标使用几种不同类型的部署策略。 例如，您可能需要对某个环境进行更改以进行进一步的测试，或者对用户/客户端的子集进行更改，或者您可能需要先对用户进行有限的测试，然后才能将某些功能
公开发布 。
滚动（逐步，“滚动”部署）
这是Kubernetes中的标准部署策略。 它逐步地将应用程序的旧版本替换为新版本的pod，从而避免了集群停机。
Kubernetes会等到新的Pod准备好工作（通过
就绪测试对其进行
检查 ），然后再开始折叠旧的Pod。 如果出现问题，可以在不停止整个群集的情况下中断这种滚动更新。 在部署类型YAML文件中，新映像将替换旧映像：
apiVersion: apps/v1beta1 kind: Deployment metadata: name: awesomeapp spec: replicas: 3 template: metadata: labels: app: awesomeapp spec: containers: - name: awesomeapp image: imagerepo-user/awesomeapp:new ports: - containerPort: 8080
滚动更新的参数可以在清单文件中指定：
spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 25% maxUnavailable: 25% template: ...
重新创建（重新创建）
在这种最简单的部署类型中，旧的Pod被立即杀死，而被新的Pod取代：
相应的清单如下所示：
spec: replicas: 3 strategy: type: Recreate template: ...
蓝色/绿色（蓝绿色部署）
蓝绿色部署策略（有时也称为红色/黑色，即红黑色）涉及同时部署应用程序的旧（绿色）和新（蓝色）版本。 放置两个版本之后，普通用户可以访问绿色版本，而蓝色版本可供质量检查团队通过单独的服务或直接端口转发自动进行测试：
apiVersion: apps/v1beta1 kind: Deployment metadata: name: awesomeapp-02 spec: template: metadata: labels: app: awesomeapp version: "02"
在测试蓝色（新）版本并批准其发布之后，服务会切换到该版本，并将绿色（旧）最小化：
apiVersion: v1 kind: Service metadata: name: awesomeapp spec: selector: app: awesomeapp version: "02" ...
金丝雀（金丝雀部署）
金丝雀面包卷看起来像是蓝绿色，但管理起来更好，并采用了
逐步进阶的方法。 这种类型包括几种不同的策略，包括“隐藏”启动和A / B测试。
通常，在必须在应用程序后端体验一些新功能时，可以使用此策略。 该方法的本质是创建两个几乎相同的服务器：一个服务器为几乎所有用户提供服务，另一个服务器具有新功能，仅为一小部分用户提供服务，然后比较他们的结果。 如果一切顺利，新版本将逐步推广到整个基础架构。
尽管只能使用Kubernetes工具实施该策略，用新的替换旧的Pod，但是使用像Istio这样的服务网格更加方便和容易。
例如，您可以在Git中有两个不同的清单：带有0.1.0标签的常规清单和带有0.2.0标签的“ canary”清单。 通过更改Istio虚拟网关清单中的权重，可以控制以下两个部署之间的流量分配：
有关使用Istio实现金丝雀部署的演练，请参阅使用
Istio的GitOps工作流程 。
（ 注意翻译 ：我们还在Istio中翻译了有关金丝雀的材料。）带有Weaveworks Flagger的Canary部署
通过Weaveworks Flagger ，可以轻松高效地管理金丝雀的推出。
Flagger使他们的工作自动化。 它使用Istio或AWS App Mesh路由和交换流量，以及Prometheus指标来分析结果。 此外，金丝雀部署的分析可以通过用于接受测试，压力测试和任何其他类型检查的Webhooks进行补充。
根据Kubernetes部署以及必要时Pod的水平扩展（HPA），Flagger创建对象集（Kubernetes部署，ClusterIP服务以及Istio或App Mesh虚拟服务），以分析和实现Canary部署：
实施
控制循环后 ，Flagger逐渐将流量切换到Canary服务器，同时测量关键性能指标，例如成功HTTP请求的百分比，平均请求持续时间和pod运行状况。 根据对KPI（关键绩效指标）的分析，金丝雀部分会增长或崩溃，分析结果将发布在Slack中。 有关此过程的描述和演示，请参见
App Mesh的
渐进式交付 。
黑暗（隐藏）或A / B部署
秘密部署是金丝雀策略的另一种变体（顺便说一下，Flagger也可以使用它）。 隐蔽部署和Canary部署之间的区别在于，隐蔽部署像Canary部署一样处理前端而不是后端。
这些部署的另一个名称是A / B测试。 除了向所有用户开放对新功能的访问权限之外，仅向其中一部分用户提供此功能。 通常，这些用户不知道他们是先驱测试人员（因此称为“隐蔽部署”）。
使用功能
切换按钮和其他工具，您可以监视用户如何与新功能交互，是否着迷于新功能，是否发现新用户界面令人困惑以及其他类型的指标。
标记程序和A / B部署
除了加权路由外，Flagger还可以根据HTTP设置将流量定向到Canary服务器。 对于A / B测试，您可以使用HTTP标头或cookie来重定向特定的用户段。 这对于需要与服务器建立
会话亲缘关系的前端应用程序特别有效。 有关更多信息，请参见Flagger文档。
作者感谢Weaveworks工程师（兼Flagger的创建者） Stefan Prodan所做的所有出色部署。译者的PS
另请参阅我们的博客：