应用蓝绿发布
在现代软件开发中,部署应用的新版本是开发周期中的关键环节。然而,将更新发布到生产环境可能存在风险,因为即使是很小的问题也可能导致严重的停机时间和收入损失。蓝绿发布是一种通过确保应用的新版本可以在零停机时间的情况下部署来缓解这一风险的部署策略。
蓝绿发布是一种部署策略,其中会搭建两个相同的环境:“蓝色”环境和“绿色”环境。蓝色环境是生产环境,当前正在运行应用的线上版本;绿色环境是非生产环境,用于部署应用的新版本。
当应用的新版本准备好部署时,会先部署到绿色环境。新版本完成部署并经过测试后,流量会切换到绿色环境,使其成为新的生产环境。随后,蓝色环境就会变成非生产环境,供未来版本的应用部署使用。
蓝绿发布的优势
-
零停机时间:蓝绿发布允许在零停机时间的情况下部署应用的新版本,因为流量会无缝地从蓝色环境切换到绿色环境。
-
易于回滚:如果应用的新版本出现问题,回滚到上一个版本非常容易,因为蓝色环境仍然可用。
-
降低风险:通过使用蓝绿发布,部署应用新版本的风险会显著降低。这是因为新版本可以先在绿色环境中部署并测试,然后再从蓝色环境切换流量。这有助于进行充分测试,并降低生产环境中出现问题的概率。
-
提高可靠性:通过使用蓝绿发布,应用的可靠性会提高。这是因为蓝色环境始终可用,而绿色环境中的任何问题都可以快速识别并解决,而不会影响用户。
-
灵活性:蓝绿发布为部署过程提供了灵活性。可以并排部署应用的多个版本,从而便于测试和实验。
使用 Argo Rollouts 的蓝绿发布
Argo Rollouts 是一个 Kubernetes 控制器和一组 CRD,它为 Kubernetes 提供诸如蓝绿、金丝雀、金丝雀分析、实验以及渐进式交付等高级部署能力。
Argo Rollouts 可(可选地)与 ingress controller 和 service mesh 集成,利用它们的流量整形能力,在更新过程中将流量逐步切换到新版本。此外,Rollouts 还可以查询并解析来自各类提供者的指标,以验证关键 KPI,并在更新期间驱动自动晋升或回滚。
使用 Argo Rollouts,你可以在 Alauda Container Platform (ACP) 集群上自动化蓝绿发布。典型流程包括:
- 定义 Rollout 资源以管理不同的应用版本。
- 配置 Kubernetes Service,在蓝色(当前)和绿色(新)环境之间路由流量。
- 将新版本部署到绿色环境。
- 验证并测试新版本。
- 通过切换流量将绿色环境提升为生产环境。
这种方式可最大限度减少停机时间,并实现受控、安全的发布。
关键概念:
- Rollout:Kubernetes 中用于替代标准 Deployment 资源的自定义资源定义(CRD),可实现蓝绿、金丝雀部署等高级部署控制。
前提条件
- ACP(Alauda Container Platform)。
- 由 ACP 管理的 Kubernetes 集群。
- 集群中已安装 Argo Rollouts。
- Argo Rollouts kubectl 插件。
- 一个用于在其中创建 namespace 的 project。
- 集群中用于部署应用的 namespace。
操作步骤
创建 Deployment
首先定义应用的“蓝色”版本。这是用户当前访问的版本。创建一个 Kubernetes Deployment,并设置合适的副本数、容器镜像版本(例如 hello:1.23.1)以及适当的标签,如 app=web。
使用以下 YAML:
YAML 字段说明:
apiVersion:用于创建资源的 Kubernetes API 版本。kind:指定这是一个 Deployment 资源。metadata.name:Deployment 的名称。spec.replicas:所需的 Pod 副本数。spec.selector.matchLabels:定义 Deployment 如何查找要管理的 Pod。template.metadata.labels:应用到 Pod 上的标签,供 Service 选择它们。spec.containers:每个 Pod 中要运行的容器。containers.name:容器名称。containers.image:要运行的 Docker 镜像。containers.ports.containerPort:容器暴露的端口。
使用 kubectl 应用配置:
这样就设置好了生产环境。
或者,你也可以使用 Helm Chart 来创建 Deployment 和 Service。
创建蓝色 Service
创建一个 Kubernetes Service 来暴露蓝色 Deployment。该 Service 会根据匹配的标签将流量转发到蓝色 Pod。最初,Service selector 的目标是带有 app=web 标签的 Pod。
YAML 字段说明:
apiVersion:用于创建 Service 的 Kubernetes API 版本。kind:指定该资源是一个 Service。metadata.name:Service 的名称。spec.selector:根据标签标识需要将流量路由到哪些 Pod。ports.protocol:使用的协议(TCP)。ports.port:Service 暴露的端口。ports.targetPort:流量被转发到容器上的端口。
使用以下命令应用:
这使外部可以访问蓝色 Deployment。
验证蓝色 Deployment
通过列出 Pod 来确认 blue Deployment 正在正常运行:
检查所有预期副本(2 个)是否都处于 Running 状态。这可确保应用已准备好接收流量。
验证到蓝色的流量路由
确保 web Service 正确地将流量转发到蓝色 Deployment。使用以下命令:
输出中应列出蓝色 Pod 的 IP 地址。这些就是接收流量的 endpoint。
创建 Rollout
接下来,使用 BlueGreen 策略创建来自 Argo Rollouts 的 Rollout 资源。
YAML 字段说明:
-
spec.selector:Pod 的标签选择器。由此选择到的现有 ReplicaSet 会受到该 rollout 的影响。它必须与 Pod template 的标签匹配。 -
workloadRef:指定要应用到 rollout 的 workload 引用和缩容策略。scaleDown:指定迁移到 Rollout 后是否缩减 workload(Deployment)。可选项如下:"never":不缩减 Deployment。"onsuccess":Rollout 变为健康状态后缩减 Deployment。"progressively":随着 Rollout 扩容,Deployment 同步缩容。如果 Rollout 失败,Deployment 将重新扩容。
-
strategy:rollout 策略,支持BlueGreen和Canary策略。blueGreen:BlueGreenrollout 策略定义。activeService:指定在晋升时要使用新 template hash 更新的 Service。该字段是 blueGreen 更新策略的必填项。autoPromotionEnabled:通过在晋升前立即暂停 rollout 来禁用新版本栈的自动晋升。如果省略,则默认行为是在 ReplicaSet 完全就绪/可用后立即晋升新版本栈。可以使用以下命令恢复 Rollout:kubectl argo rollouts promote ROLLOUT
使用以下命令应用:
这就为该 Deployment 设置了 BlueGreen 策略的 rollouts。
验证 Rollouts
创建 Rollout 后,Argo Rollouts 会创建一个与 Deployment template 相同的新 ReplicaSet。在新 ReplicaSet 的 Pod 处于健康状态时,Deployment 会被缩减到 0。
使用以下命令确保 Pod 正常运行:
web Service 会将流量转发到 Rollouts 创建的 Pod。使用以下命令:
准备绿色 Deployment
接下来,将应用的新版本作为绿色 Deployment 准备好。将 Deployment web 更新为新的镜像版本(例如 hello:1.23.2)。
YAML 字段说明:
- 与原始 Deployment 相同,唯一的区别是:
containers.image:已更新为新的镜像版本。
使用以下命令应用:
这就为测试准备好了新的应用版本。
rollouts 会创建一个新的 ReplicaSet 来管理绿色 Pod,而流量仍然会转发到蓝色 Pod。使用以下命令进行验证:
目前有 4 个 Pod 在运行,分别对应蓝色和绿色版本。当前 active service 仍然是蓝色版本,rollout 流程处于暂停状态。
如果你使用 Helm Chart 部署应用,请使用 helm 工具将应用升级到绿色版本。
将 Rollout 晋升到绿色
当绿色版本准备就绪后,执行 rollout 的晋升操作,将流量切换到绿色 Pod。使用以下命令:
验证 rollout 是否已完成:
如果 active Images 已更新为 hello:1.23.2,并且蓝色 ReplicaSet 已缩减到 0,则表示 rollout 已完成。