探讨Kubernetes的不同部署策略

【51CTO.com快译】众所周知，我们在开发云原生应用的过程中，往往比拼的是如何加快单位时间内，应用部署的数量与质量。而通过使用微服务的方法，开发人员能够快速设计出完全模块化的应用程序，从而让更多的团队成员得以同时向单个应用程序写入并部署各种变更与发布。可见，用时更短、更频繁的部署能够给企业带来以下方面的好处：

• 缩短了上市(time-to-market)的时间。
• 客户能够更快地使用到新的特性。
• 客户的各种反馈能够更快地到达产品团队，同时产品团队也能更快地通过迭代来解决现有的问题。
• 通过向生产环境成功发布更多的新特性，来鼓舞开发人员的士气。

当然更频繁的发布，也会对应用的可靠性、以及客户的体验满意度增添一些负面的影响。这就是为什么运营和DevOps团队需要共同开发出各种流程、并管理不同的部署策略，从而最小化产品和客户可能面对的风险。(更多关于CI/CD管道自动化的信息， 请参见 )

在本文中，我们将讨论Kubernetes的不同部署策略，其中包括滚动部署、重建、蓝绿、金丝雀、及其变种等高级方法。

部署策略

根据目标的不同，我们可以对Kubernetes采取不同的部署策略。例如：您可能需要针对某个特定环境、或是用户与客户子集进行变更，进而推出更多的测试版本;或许您想在推出某个通用功能之前，先对一部分用户开展测试。

滚动部署(Rolling Deployment)

滚动部署是对Kubernetes的一种标准化、且默认的部署方式。它虽然运行较为缓慢，但是能够一个接一个地用新版本的pod替换应用程序中旧版本的pod，而且不会产生任何集群的停机时间。

在开始取代旧的pod之前，滚动更新需要通过就绪探测器(readiness probe， 请参考 )，来确认新的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: 
  ... 

重建(Recreate)

这是一种非常简单的部署方式，如下图所示，它直接“杀”掉所有旧的pod，并立即替换为新的pod。

其对应的标准清单文件，如下所示：

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

蓝/绿或红/黑部署(Blue/Green or Red/Black)

在蓝/绿(有时也被称为红/黑)部署策略中，旧版本的应用程序(简称为绿)和其对应的新版本(蓝)同时被部署到生产环境中。如下图所示，对于一般用户而言，他们只能访问到绿版本;而QA团队则可以通过单独的服务、或直接的端口转发，来对蓝版本进行自动化的测试。

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

金丝雀(Canary)

金丝雀部署有点类似于蓝/绿部署，但是它更加受控，因此其使用范围也更加广泛。金丝雀部署类型的主要特点是采用了分段式递进交付模式(progressive delivery， 请参见 )。目前，包括：暗发布(dark launches)和A/B测试在内的许多策略都属于此类。

当您想测试一些新的特性时，通常可以对自己的应用后端采用该金丝雀的部署方式。在此，您可以准备两套几乎相同的服务器：延用原有功能的那一套，面向所有用户;而部署了新功能的另一套，则仅向一小部分用户开放。通过运行效果的比较，当不再出现任何报告错误时，新版本就可以被逐步“滚动”到生产系统架构的其余部分之中。

虽然此类策略可以通过使用Kubernetes的相关资源，来实现新旧Pod的替换，但是人们通常会使用Istio之类的服务网(service mesh)，来更为方便轻松地予以实现。

如下例所示，您可以将两种不同的清单放入Git，将其中的一个GA(GitApp)标记为0.1.0，而将另一个金丝雀版本标记为0.2.0。在Istio虚拟网关的清单文件中，我们通过修改不同的权重，来管理针对这两种部署的流量百分比配额。

有关如何使用Istio来实现金丝雀的分步部署，请参见 《在GitOps工作流中使用Istio》 教程。

用Weaveworks Flagger进行金丝雀部署

另一个简单有效地管理金丝雀部署的方法是使用Weaveworks Flagger( 请参见 )

Flagger能够促进金丝雀部署的自动化。它使用Istio或APP Mesh来路由和转移流量，并且用到了Prometheus metrics的金丝雀分析。另外，金丝雀分析也可以针对各种验收测试、负载测试、以及其他类型的自定义验证，进行WebHook的扩展。

Flagger采用了Kubernetes部署，并选用HPA(horizontal pod autoscaler)来创建一系列对象(包括：Kubernetes部署、ClusterIP服务、Istio与APP Mesh虚拟服务)，进而驱动金丝雀式的分析与推送。

通过实施控制环路，Flagger会持续观测诸如HTTP请求成功率、请求平均时长、以及Pod健康性等关键性能指标，并逐步将流量转移到金丝雀的服务中。同时，我们可以通过对KPI的分析，来获悉金丝雀服务水平的提升与下降，进而将分析结果发布到Slack上。有关此方面的详述与范例，请参见 《APP Mesh的递进式交付》 。

暗部署与A/B部署

暗部署是金丝雀的另一个变种。它和金丝雀之间的区别在于：暗部署多被用于处理前端，而金丝雀常被用到后端。

暗部署的另一个名称叫A/B测试。为了测试某种新的功能，我们可能需要在用户不知情的前提下选取一小部分用户，予以部署和推送，这就是所谓的“暗”部署。

通过使用特征切换和其他类型的工具，您可以获悉用户是如何与新特性进行交互的。籍此，您可以判断是否要将该特性正式推送给用户，发现新的UI是否出现了混乱状况，以及其他类型的参数指标。

Flagger和A/B部署

其实除了加权路由，Flagger还能够在基于HTTP的各种匹配条件下，将访问流量路由到金丝雀服务之中。例如，在A/B测试场景中，您可以使用各种HTTP头或Cookie，来针对某一部分的用户进行路由转发。显然，这对于那些需要进行会话关联的前端应用来说，是特别实用的。当然具体内容，您可以去参考Flagger的相关文档。

原文标题：Kubernetes Deployment Strategies，作者：Anita Buehrle

【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】