应用蓝绿发布
在现代软件开发中,部署应用新版本是开发周期中的关键部分。然而,将更新发布到生产环境可能具有一定风险,因为即使是很小的问题也可能导致显著的停机时间和收入损失。蓝绿发布是一种通过确保应用新版本能够在零停机时间下部署来降低此风险的发布策略。
蓝绿发布是一种部署策略,它会设置两个完全相同的环境,即“蓝色”环境和“绿色”环境。蓝色环境是生产环境,当前运行着应用的正式版本;绿色环境是非生产环境,用于部署应用的新版本。
当应用的新版本准备就绪后,会将其部署到绿色环境。新版本部署并测试完成后,流量会切换到绿色环境,使其成为新的生产环境。随后,蓝色环境会变为非生产环境,未来版本的应用可以部署到该环境中。
蓝绿发布的优势
-
零停机时间:蓝绿发布允许在零停机时间下部署应用新版本,因为流量会无缝地从蓝色环境切换到绿色环境。
-
易于回滚:如果应用的新版本出现问题,可以轻松回滚到上一版本,因为蓝色环境仍然可用。
-
降低风险:通过使用蓝绿发布,可以显著降低部署应用新版本的风险。这是因为在流量从蓝色环境切换之前,可以先在绿色环境中部署并测试新版本。这样可以进行充分测试,并减少生产环境中出现问题的可能性。
-
提高可靠性:通过使用蓝绿发布,可以提升应用的可靠性。这是因为蓝色环境始终可用,而绿色环境中的任何问题都可以快速识别并解决,而不会影响用户。
-
灵活性:蓝绿发布为部署过程提供了灵活性。可以并排部署应用的多个版本,从而便于进行测试和实验。
使用 Argo Rollouts 实现蓝绿发布
Argo Rollouts 是一个 Kubernetes controller 和一组 CRD,可为 Kubernetes 提供蓝绿、金丝雀、金丝雀分析、实验以及渐进式交付等高级部署能力。
Argo Rollouts 可以(可选地)与 ingress controllers 和 service meshes 集成,利用其流量整形能力,在更新期间将流量逐步切换到新版本。此外,Rollouts 还可以查询并解析来自不同提供方的指标,以验证关键 KPI,并在更新期间驱动自动晋升或回滚。
通过 Argo Rollouts,你可以在 Alauda Container Platform (ACP) 集群上自动化蓝绿发布。典型流程包括:
- 定义 Rollout 资源来管理不同的应用版本。
- 配置 Kubernetes Services,在蓝色(当前)和绿色(新)环境之间路由流量。
- 将新版本部署到绿色环境。
- 验证并测试新版本。
- 通过切换流量,将绿色环境提升为生产环境。
这种方法可以最大限度减少停机时间,并实现受控且安全的部署。
关键概念:
- Rollout:Kubernetes 中的自定义资源定义(CRD),用于替代标准 Deployment 资源,从而实现蓝绿、金丝雀等高级部署控制。
前提条件
- ACP(Alauda Container Platform)。
- 由 ACP 管理的 Kubernetes Cluster。
- 集群中已安装 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 上的标签,由 Services 用于选择它们。spec.containers:每个 Pod 中要运行的容器。containers.name:容器名称。containers.image:要运行的容器镜像。containers.ports.containerPort:容器暴露的端口。
使用 kubectl 应用配置:
这将创建生产环境。
另外,你也可以使用 Helm Chart 来创建 Deployments 和 Services。
创建蓝色 Service
创建一个 Kubernetes Service,用于暴露蓝色 Deployment。该 Service 将根据匹配标签把流量转发到蓝色 Pods。最初,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。使用以下命令:
输出中应列出蓝色 Pods 的 IP 地址。这些就是接收流量的 endpoints。
创建 Rollout
接下来,使用 BlueGreen 策略创建 Argo Rollouts 的 Rollout 资源。
YAML 字段说明:
-
spec.selector:Pod 的标签选择器。由此选择到的现有 ReplicaSets,其 Pod 将会受到该 Rollout 的影响。它必须与 Pod 模板的标签匹配。 -
workloadRef:指定要应用到 Rollout 的 workload 引用和缩容策略。scaleDown:指定在迁移到 Rollout 后是否缩容 workload(Deployment)。可选值如下:"never":不缩容 Deployment。"onsuccess":当 Rollout 变为 healthy 后缩容 Deployment。"progressively":随着 Rollout 扩容,Deployment 逐步缩容。如果 Rollout 失败,Deployment 将重新扩容。
-
strategy:Rollout 策略,支持BlueGreen和Canary策略。blueGreen:BlueGreenRollout 策略定义。activeService:指定在切换时使用新 template hash 更新的 Service。此字段是 blueGreen 更新策略的必填项。autoPromotionEnabled:通过在切换前立即暂停 Rollout,禁用新版本的自动晋升。如果省略,则默认行为是在 ReplicaSet 完全 ready/available 后立即晋升新版本。可以使用以下命令恢复 Rollout:kubectl argo rollouts promote ROLLOUT
使用以下命令应用:
这将为该 Deployment 设置使用 BlueGreen 策略的 Rollouts。
验证 Rollouts
在创建 Rollout 之后,Argo Rollouts 会创建一个与 Deployment 模板相同的新 ReplicaSet。当新 ReplicaSet 的 Pod 处于 healthy 状态时,Deployment 会缩容到 0。
使用以下命令确保 Pod 正常运行:
Service web 会将流量转发到 Rollouts 创建的 Pods。使用以下命令:
准备绿色 Deployment
接下来,将应用的新版本作为绿色 Deployment 准备好。使用新的镜像版本更新 Deployment web(例如 hello:1.23.2)。
YAML 字段说明:
- 与原始 Deployment 相同,唯一不同之处为:
containers.image:更新为新的镜像版本。
使用以下命令应用:
这将为测试准备新的应用版本。
Rollouts 会创建一个新的 ReplicaSet 来管理绿色 Pods,而流量仍然会转发到蓝色 Pods。使用以下命令进行验证:
当前共有 4 个 Pod 在运行,同时包含蓝色和绿色版本。此时 active Service 仍指向蓝色版本,Rollout 流程处于暂停状态。
如果你使用 Helm Chart 来部署应用,则使用 Helm 工具将应用升级到绿色版本。
将 Rollout 晋升到绿色版本
当绿色版本准备就绪后,晋升 Rollout 以将流量切换到绿色 Pods。使用以下命令:
验证 Rollout 是否完成:
如果 Images 中的 active 版本已更新为 hello:1.23.2,并且蓝色 ReplicaSet 已缩容到 0,则表示 Rollout 已完成。