Kubernetes中的渐进式交付主要包括蓝绿部署和金丝雀部署两种策略，Shipper、Istio和Flagger是实现这些策略的典型工具，它们各有特点且适用于不同场景。以下是对蓝绿部署、金丝雀部署及相关工具的详细介绍：
渐进式交付概述渐进式交付是持续交付的进一步发展，其核心思想是将新版本先部署到用户的一个子集，在将其推广到全部用户之前，对新版本的正确性和性能进行评估。如果新版本不满足某些关键指标，则进行回滚操作。这种策略有助于降低发布风险，提高系统的稳定性和可靠性。
蓝绿部署- 定义：蓝绿部署是一种零停机的部署方式，它通过维护两套完全相同的环境（蓝色环境和绿色环境），其中一套环境运行当前版本（旧版本），另一套环境运行新版本。在部署过程中，通过切换流量来将用户从旧版本引导到新版本。
- 特点
零停机：由于有两套环境，切换时不会影响用户的正常使用。
快速回滚：如果新版本出现问题，可以迅速将流量切换回旧版本，实现快速回滚。
资源消耗大：需要维护两套完全相同的环境，资源消耗较大。
- 在Kubernetes中的实现工具 - Shipper
项目来源：Shipper是来自Booking.com的一个项目，对Kubernetes进行了扩展，添加了复杂的部署策略和多集群编排功能。
功能特性
多集群支持：支持从一个集群到多个集群的部署，允许多区域部署。
部署阶段管理：通过创建新的应用对象来定义部署需要经过的多个阶段。例如，常见的三个步骤过程为：
Staging：部署新版本到一个Pod，不分配流量，可用于在用户看到新版本之前进行测试，此时可以使用kubectl port-forward访问新版本，如kubectl port-forward mypod 8080:8080。
50 / 50：部署新版本到50%的Pods，同时分配50%的流量到新版本。
Full on：部署新版本到全部的Pods，分配全部流量到新版本。
配置示例：
strategy: steps: - name: staging capacity: contender: 1 incumbent: 100 traffic: contender: 0 incumbent: 100 - name: 50/50 capacity: contender: 50 incumbent: 50 traffic: contender: 50 incumbent: 50 - name: full on capacity: contender: 100 incumbent: 0 traffic: contender: 100 incumbent: 0- 局限性 - Chart限制：Chart必须有一个部署对象，Deployment的名称必须使用`{{.Release.Name}}`模板化，且Deployment对象应该有`apiVersion：apps/v1`。 - 流量切换粒度：基于正在运行的Pod数量进行流量切换，没有细粒度的流量路由，例如无法发送1%的流量到新版本。 - 故障影响：如果Shipper不工作了，新的Pod将获取不到流量。金丝雀部署- 定义：金丝雀部署是一种逐步将新版本部署到生产环境的方式，它先将新版本部署到一小部分用户，然后逐渐扩大新版本的覆盖范围，同时监控新版本的性能和稳定性。如果新版本表现良好，则继续扩大覆盖范围；如果出现问题，则停止部署并回滚。
- 特点
风险可控：通过逐步扩大新版本的覆盖范围，降低了发布风险。
数据驱动：根据实际监控数据来决定是否继续扩大覆盖范围或进行回滚。
部署周期长：由于需要逐步扩大覆盖范围，部署周期相对较长。
- 在Kubernetes中的实现工具
Istio
项目性质：Istio不是一个部署工具，而是一个服务网格，它允许进行流量管理，例如将一定比例的流量发送到不同的服务。
安装方式：在GKE中，只需在集群配置中选中复选框即可启用Istio；在其他集群中，可以通过Helm手动安装。
流量管理示例：
创建网关处理所有外部流量：
apiVersion: networking.istio.io/v1alpha3kind: Gatewaymetadata: name: public-gateway namespace: istio-systemspec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" - 创建虚拟服务管理到服务的路由，例如为所有进入ingress网关的请求向pull request或master分支中部署的服务发送1%的流量：apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: croc-hunter-jenkinsx namespace: jx-productionspec: gateways: - public-gateway.istio-system.svc.cluster.local - mesh hosts: - http://croc-hunter.istio.example.org
http: - route: - destination: host: croc-hunter-jenkinsx.jx-production.svc.cluster.local port: number: 80 weight: 99 - destination: host: croc-hunter-jenkinsx.jx-staging.svc.cluster.local port: number: 80 weight: 1- Flagger - 项目来源：Flagger是一个由Weaveworks赞助的使用了Istio的项目，它使用Prometheus的指标进行自动化金丝雀发布和回滚。 - 功能特性 - 自动化发布和回滚：超越了Istio，提供了基于指标的自动化渐进式发布和回滚。 - 监控面板：提供了一个Grafana面板来监控部署进度。 - 安装要求：需要将Istio与Prometheus、Servicegraph和某些系统的配置一起安装，另外还要安装Flagger控制器本身。 - 部署示例：部署rollout通过Canary对象定义，它会生成主要的和金丝雀Deployment对象。编辑Deployment时，例如要使用新的镜像版本，Flagger控制器将负载从0%切换到50%，每分钟增加10%，然后它将切换到新的deployment或者如果响应错误和请求持续时间等指标失败则进行回滚。工具比较- Shipper：在多集群管理和简单性方面具有价值，不需要Kubernetes以外的任何东西，但存在Chart限制、流量切换粒度粗和故障影响大等局限性。
- Flagger：在自动部署和回滚以及对流量进行细粒度控制方面表现出色，但以更高的复杂性成本提供了所需的所有额外服务（Istio、Prometheus）。
