的不同部署策略【.com快译】众所周知，在开发云原生应用的过程中，我们经常会比拼如何加快单位时间内应用部署的数量和质量。通过使用微服务方法，开发人员可以快速设计完全模块化的应用程序，允许更多团队成员同时编写和部署更改和发布到单个应用程序。由此可见，更短、更频繁的部署可以为企业带来以下好处：缩短上市时间（time-to-market）。客户可以更快地使用新功能。客户的各种反馈可以更快的到达产品团队，产品团队也可以更快的迭代解决存在的问题。通过成功发布更多新功能来提高开发人员的士气。当然，更频繁的发布也会对应用可靠性和客户体验满意度产生一些负面影响。这就是为什么运营和DevOps团队需要合作开发流程和管理不同的部署策略，以最大限度地降低产品和客户的风险。（这里有更多关于CI/CD管道自动化的信息。）在本文中，我们将讨论Kubernetes的不同部署策略，其中包括滚动部署、重建、蓝绿、金丝雀及其变体等高级方法。部署策略根据不同的目标，我们可以对Kubernetes采取不同的部署策略。例如：您可能需要针对特定??环境或部分用户和客户进行更改，然后推出更多测试版本；也许您想在推出一般功能之前测试一组特定的用户。滚动部署（RollingDeployment）滚动部署是Kubernetes一种标准化的默认部署方式。它运行缓慢，但能够在没有任何集群停机的情况下将应用程序中旧版本的pod逐一替换为新版本。在开始更换旧pod之前，rollingupdate需要通过readinessprobe（就绪探测，请参考），确认新pod是否到位。如果出现问题，滚动更新或部署将被中断，以免导致整个集群宕机。因此，我们可以参考如下YAML定义文件，以滚动部署的方式将旧镜像替换为新镜像。apiVersion:apps/v1beta1kind:Deploymentmetadata:name:awesomeappspec:replicas:3template:metadata:labels:app:awesomeappspec:containers:-name:awesomeappimage:imagerepo-user/awesomeapp:newports:-containerPort:8080如下，通过调整manifest(manifest)文件，我们可以进一步细化滚动更新：spec:replicas:3strategy:type:RollingUpdaterollingUpdate:maxSurge:25%maxUnavailable:25%template:...Recreate这是一个很简单的部署方式，如下图，直接“杀死”所有旧的pod，并立即用新的pod替换它们。其对应的标准清单文件如下：spec:replicas:3strategy:type:Recreatetemplate:...Blue/GreenorRed/Blackdeployment(Blue/GreenorRed/Black)inblue/green(有时称为Inthered/black）部署策略，旧版本应用（简称绿色）及其对应的新版本（蓝色）同时部署到生产环境。如下图，一般用户只能访问绿色版；而QA团队可以通过单独的服务或直接端口转发对蓝色版本进行自动化测试。apiVersion:apps/v1beta1kind:Deploymentmetadata:name:awesomeapp-02spec:template:metadata:labels:app:awesomeappversion:"02"因此，直到新版本完全通过测试并被发布确认，面向用户的服务被切换到蓝色版本，旧的绿色版本终于“退休”了：apiVersion:v1kind:Servicemetadata:name:awesomeappspec:selector:app:awesomeappversion:"02"...CanaryCanary部署有点类似于blue/green部署，但更受控制，因此使用更广泛。金丝雀部署类型的主要特征是使用分段渐进式交付模型（渐进式交付，请参阅参考资料）。目前，许多策略包括：暗启动和A/B测试都属于这一类。当你想测试一些新特性时，你通常可以使用这种金丝雀部署方式来为你自己的应用后端服务。在这里，你可以准备两套几乎一模一样的服务器：一套保持原有的功能，对所有用户开放；另一套新功能，只对小部分用户开放。通过运行性能比较，当不再报告错误时，新版本可以逐渐“滚动”到生产系统架构的其余部分。虽然这样的策略可以通过使用Kubernetes相关资源来替换新旧Pod来实现，但是人们通常使用Istio等服务网格来实现它更方便、更容易。如下例所示，您可以将两个不同的清单放入Git，其中一个标记为GA(GitApp)为0.1.0，另一个为标记为0.2.0的金丝雀发布。在Istio虚拟网关的清单文件中，我们通过修改不同的权重来管理这两个部署的流量百分比配额。请参阅《在GitOps工作流中使用Istio》教程，了解如何使用Istio逐步实施金丝雀部署。使用Wea??veworksFlagger进行金丝雀部署管理金丝雀部署的另一种简单有效的方法是使用Wea??veworksFlagger（请参阅参考资料）Flagger有助于金丝雀部署的自动化。它使用Istio或APPMesh来路由和传输流量，并使用Prometheus指标进行金丝雀分析。此外，金丝雀分析还可以通过WebHook进行扩展，用于各种验收测试、负载测试和其他类型的自定义验证。Flagger采用Kubernetes部署，使用HPA（horizo??ntalpodautoscaler）创建一系列对象（包括：Kubernetes部署、ClusterIP服务、Istio和APPMesh虚拟服务），然后驱动金丝雀式的分析和推送。通过实现控制循环，Flagger将持续观察HTTP请求成功率、平均请求持续时间和Pod健康状况等关键性能指标，并逐步将流量转移到Canary服务。同时，我们可以通过KPI分析了解金丝雀服务水平的提升和下降，然后将分析结果发布到Slack上。有关详细信息和示例，请参阅《APP Mesh的递进式交付》。暗部署与A/B部署暗部署是金丝雀的另一种变体。它与金丝雀的区别在于：暗部署多用于处理前端，而金丝雀多用于后端。暗部署的另一个名称是A/B测试。为了测试一个新的功能，我们可能需要在用户不知情的情况下选择少量用户，对他们进行部署和推送，这就是所谓的“暗”部署。通过使用功能切换和其他类型的工具，您可以了解用户如何与新功能交互。由此可以判断是否正式向用户推送功能，新UI是否混乱，以及其他类型的参数指标。Flagger和A/B部署除了加权路由，Flagger还可以基于HTTP在各种匹配条件下将访问流量路由到金丝雀服务。例如，在A/B测试场景中，可以使用各种HTTPheader或cookies来针对某一部分用户进行路由转发。显然，这对于需要会话关联的前端应用程序特别实用。当然具体内容可以参考Flagger的相关文档。原标题：KubernetesDeploymentStrategies，作者：AnitaBuehrle
