原文地址：https://www.weave.works/blog/kubernetes-deployment-strategies

如今，开发云原生应用程序的最大挑战之一是加快部署数量。通过微服务，开发人员已经在使用和设计完全模块化的应用程序，该应用程序允许多个团队同时编写变更并将其部署到应用程序。

更短，更频繁的部署具有以下优点：

缩短了面向市场的时间
客户可以更快地使用功能
客户反馈更快地传递到产品团队，这意味着团队可以迭代功能并更快地解决问题
更高的开发人员士气和更多的产品特性

但是随着发布的频率提高，负面影响应用程序可靠性或客户体验的机会也会增加。因此，对于运营和DevOps团队来说，开发流程和管理部署策略以最小化产品和客户风险至关重要。

部署策略

您可以根据自己的目标采用几种不同类型的部署策略。例如，您可能需要对特定环境进行变更以进行更多测试，或者对用户/客户的子集进行变更，或者可能需要在使功能“通用”之前进行一些用户测试。

滚动部署

滚动部署是Kubernetes的标准默认部署。它一步一步地工作，用新版本的Pod替换应用程序先前版本的Pod，而不会导致集群停机。

rolling-deployment-w

滚动更新等待新的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

通过调整manifest文件中的参数，可以进一步完善滚动更新：

spec:
  replicas: 3
  strategy:
        type: RollingUpdate
        rollingUpdate:
           maxSurge: 25%
           maxUnavailable: 25%  
  template:
  ...

重新建立

在这种非常简单的部署中，所有旧Pods都被立即杀死，并立即被新Pods替换。 recreate-deployment-w

manifest看起来像这样：

spec:
  replicas: 3
  strategy:
        type: Recreate
  template:
  ...

蓝/绿（或红/黑）部署

在蓝/绿部署策略（有时称为红/黑）中，应同时部署应用程序的旧版本（绿色）和新版本（蓝色）。当这两个都部署时，用户只能访问绿色。但是，质量保证小组可以使用蓝色，以通过单独的服务或通过直接端口转发进行测试自动化。

blue-green-deployment-w

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"
...

金丝雀部署

金丝雀部署有点像蓝/绿部署，但受到更多控制，并使用了一种“渐进式交付”逐步实施的方法。金丝雀的保护范围有很多，包括：dark launches(或者叫Dark Testing是Fackbook使用的一种测试产品新功能的测试方法)或A/B测试。

当您想在应用程序后端测试一些新功能时，可以使用金丝雀部署。传统上，您可能拥有两台几乎完全相同的服务器：一台用于所有用户，另一台具有新功能，这些新功能会推广到一部分用户，然后进行比较。如果未报告任何错误，则新版本可以逐步推广到其他基础架构。

尽管可以仅通过使用Kubernetes资源来替换旧的和新的Pod来完成此策略，但是使用Istio这样的服务网格来实现该策略要方便得多，也容易得多。

例如，您可以将两个不同的manifest检入Git：标记为0.1.0的GA和标记为0.2.0的金丝雀。通过更改Istio虚拟网关清单中的权重，可以管理这两个部署的流量百分比。

canary-deployment-w

有关使用Istio实现金丝雀部署的分步教程，请参阅GitOps Workflows with Istio

使用Weaveworks Flagger来实现金丝雀部署

一种简单有效的管理金丝雀部署的方法是使用Weaveworks Flagger

使用Flagger，金丝雀部署的升级是自动化的。它使用Istio或App Mesh进行路由和转移流量，并使用Prometheus指标进行金丝雀分析。金丝雀分析还可以通过Webhooks进行扩展，以运行验收测试，负载测试或任何其他类型的自定义验证。

Flagger采用Kubernetes部署，还可以选择使用水平Pod自动缩放器（HPA）来创建一系列对象（Kubernetes部署，ClusterIP服务以及Istio或App Mesh虚拟服务），以推动金丝雀的分析和升级。

flagger-canary-hpa

通过实现控制循环，Flagger逐渐将流量转移到金丝雀，同时测量关键性能指标，例如HTTP请求成功率，请求平均持续时间和Pod运行状况。基于对KPI的分析，金丝雀会被提升或中止，并将分析结果发布给Slack。有关概述和演示，请参阅Progressive Delivery for App Mesh

flagger-canary-overvie

暗部署或者A/B部署

暗部署是金丝雀的另一种变化（顺带一提，Flagger也可以处理）。暗部署和金丝雀部署之间的区别在于，暗部署处理前端中的功能，而不像金丝雀部署那样处理后端的功能。

暗部署的另一个名称是A/B测试。您可以将其发布给一小部分用户，而不是为所有用户启动新功能。用户通常不知道自己被用作新功能的测试人员，因此称为“暗”部署。（游戏应用俗称暗改）

通过使用功能切换和其他工具，您可以监视用户与新功能的交互方式，是否正在转换用户，或者他们是否发现新的UI令人困惑以及其他类型的指标。

flagger-abtest-steps

除了加权路由外，Flagger还可以根据HTTP匹配条件将流量路由到金丝雀。在A/B测试方案中，您将使用HTTP header或cookie来定位用户的特定细分受众群。这对于需要会话关联的前端应用程序特别有用。

【翻译】Kubernetes应用部署策略

在本文中，我们将讨论Kubernetes的部署策略，包括滚动部署以及诸如金丝雀部署及其变种之类的更高级的方法。