探讨Kubernetes的不同部署策略
- 缩短了上市(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部署