本文提供了有关实现蓝绿部署策略的指导，以在继续运行当前版本的同时测试新版本的 Azure Kubernetes 服务 (AKS) 群集。 验证新版本后，路由更改会将用户流量切换到该版本。 以这种方式部署，可提高对 AKS 群集进行更改（包括升级）时的可用性。 本文介绍了使用 Azure 托管服务和本机 Kubernetes 功能的 AKS 蓝绿部署的设计和实现。
体系结构
本部分介绍 AKS 群集的蓝绿部署的体系结构。 存在两种情况：
- 应用程序和 API 是面向公共的。
- 应用程序和 API 是面向私人的。
还有一种混合情况，此处未讨论，其中群集中混合了面向公共和面向私人的应用程序和 API。
下图显示了面向公共的用例的体系结构：
下载此体系结构的 Visio 文件。
Azure Front Door 和 Azure DNS 提供了在蓝绿群集之间切换流量的路由机制。 有关详细信息，请参阅使用 Azure Front Door 进行蓝绿部署。 通过使用 Azure Front Door，可以实现基于权重的完全切换或更可控的切换。 此技术在 Azure 环境中是最可靠和最有效的。 如果想使用自己的 DNS 和负载均衡器，则需要确保它们已配置为提供安全可靠的切换。
Azure 应用程序网关提供专用于公共终结点的前端。
下图适用于面向私人的用例：
下载此体系结构的 Visio 文件。
在这种情况下，单个 Azure DNS 实例可实现蓝绿群集之间的流量切换。 这是通过使用 A 和 CNAME 记录来完成的。 有关详细信息，请参阅 T3：将流量切换到绿色群集部分。
应用程序网关提供专用于专用终结点的前端。
工作流
在蓝绿部署中，将群集的当前版本更新到新版本需要五个阶段。 在我们的说明中，蓝色群集是当前版本，绿色群集是新版本。
阶段包括：
新版本上线后，它将成为接下来发生的任何更改或更新的蓝色群集。
蓝色和绿色群集同时运行，但仅持续有限的时间，这可优化成本和运营工作。
转换触发器
从一个阶段转换到另一个阶段的触发器可自动执行。 在此之前，它们中的一些或全部都是手动执行的。 触发器与以下内容有关：
- 具体的工作负载指标、服务级别目标 (SLO) 和服务级别协议 (SLA)：这些主要用于 T3 阶段，以在切换流量之前验证 AKS 群集的整体状态。
- Azure 平台指标：这些指标用于评估工作负载和 AKS 群集的状态和运行状况。 它们用于所有的转换。
群集的网络可发现性
可通过以下方式为群集提供网络可发现性：
具有指向群集的 DNS 记录。 例如：
aks-blue.contoso.com指向蓝色群集的专用或公共 IP。aks-green.contoso.com指向绿色群集的专用或公共 IP。
然后，可以直接使用这些主机名，也可以在每个群集前面的应用程序网关的后端池配置中使用这些主机名。
具有指向应用程序网关的 DNS 记录。 例如：
aks-blue.contoso.com指向应用程序网关的专用或公共 IP，该网关将蓝色群集的专用或公共 IP 作为后端池。aks-green.contoso.com指向应用程序网关的专用或公共 IP，该网关将绿色群集的专用或公共 IP 作为后端池。
T0：蓝色群集已打开
初始阶段 T0 是蓝色群集处于活动状态。 此阶段准备新版本的群集以进行部署。
T1 阶段的触发条件是发布新版本的群集（即绿色群集）。
T1：部署绿色群集
此阶段开始部署新的绿色群集。 蓝色群集保持打开状态，实时流量仍路由到该群集。
进入 T2 阶段的触发条件是在平台级别验证绿色 AKS 群集。 验证使用 Azure Monitor 指标和 CLI 命令来检查部署的运行状况。 有关详细信息，请参阅使用 Monitor 监视 Azure Kubernetes 服务 (AKS) 和监视 AKS 数据参考。
AKS 监视可以分为不同的级别，如下图所示：
群集的运行状况在级别 1 和级别 2 级以及级别 3 的某些时候进行评估。 对于级别 1，可以使用 Monitor 中的本机多群集视图来验证运行状况，如下所示：
在级别 2，确保 Kubernetes API 服务器和 Kubelet 正常工作。 可以在 Monitor 中使用 Kubelet 工作簿，特别是工作簿中显示节点的关键操作统计信息的两个网格：
- 节点网格的概览汇总了每个节点的总操作数、总错误数、成功的操作数（按百分比），以及趋势。
- 操作类型网格的概览提供了每种操作类型的操作数、错误数、成功的操作数（按百分比），以及趋势。
级别 3 专用于默认部署在 AKS 中的 Kubernetes 对象和应用程序，例如 omsagent、kube-proxy 等。 对于此检查，可以使用 Monitor 的“见解”视图检查 AKS 部署的状态：
或者，也可以使用带有容器见解的部署和 HPA 指标中记录的专用工作簿。 下面是一个示例：
验证成功后，可以转换到 T2 阶段。
T2：在蓝色和绿色群集之间同步 Kubernetes 状态
在此阶段，应用程序、运算符和 Kubernetes 资源尚未部署在绿色群集中，或者至少在预配 AKS 群集时，并非所有这些内容都适用和已部署。 此阶段的最终目标是，在同步结束时，绿色群集与蓝色群集向后兼容。 如果已实现，则可以在将流量切换到绿色群集之前验证新群集的状态。
可通过多种方式在群集之间同步 Kubernetes 状态：
- 通过持续集成和持续交付 (CI/CD) 重新部署。 通常，使用用于正常部署应用的相同 CI/CD 管道就足够了。 执行此操作的常用工具有：GitHub Actions、Azure DevOps 和 Jenkins。
- GitOps，以及在云原生计算基础 (CNCF) 网站上推广的解决方案，例如 Flux 和 ArgoCD。
- 自定义解决方案，用于将 Kubernetes 配置和资源存储在数据存储中。 通常，这些解决方案基于 Kubernetes 清单生成器，该生成器从元数据定义开始，然后将生成的 Kubernetes 清单存储到 Azure Cosmos DB 等数据存储中。 这些通常是基于正在使用的应用程序说明框架的自定义解决方案。
下图显示了同步 Kubernetes 状态的过程：
通常，在同步期间，活动群集中不允许部署新版本的应用程序。 此时间段从同步开始，到切换为绿色群集完成时结束。 在 Kubernetes 中禁用部署的方法可能会有所不同。 两种可能的解决方案包括：
禁用部署管道。
禁用执行部署的 Kubernetes 服务帐户。
可以使用开放策略代理 (OPA) 自动禁用服务帐户。 尚无法为此使用 AKS 本机功能，因为它们仍处于预览状态。
通过使用管理多个群集中的 Kubernetes 状态的高级机制，可以避免同步周期。
同步完成后，需要验证群集和应用程序。 这包括：
- 检查监视和日志记录平台以验证群集的运行状况。 可以考虑执行在 T1：部署绿色群集阶段执行的操作。
- 基于当前使用的工具链对应用程序进行功能测试。
同时建议执行负载测试会话，将绿色群集应用程序的性能与性能基线进行比较。 可以使用喜欢的工具或 Azure 负载测试。
通常，绿色群集在应用程序网关或外部负载均衡器上公开，其内部 URL 对外部用户不可见。
验证新群集后，可以继续执行下一阶段，将流量切换到新群集。
T3：将流量切换到绿色群集
同步完成并在平台和应用程序级别验证绿色群集后，即可将其提升为主群集并开始接收实时流量。 切换是在网络级别执行的。 工作负载通常是无状态的。 但是，如果工作负载是有状态的，则必须实施额外的解决方案，以在切换期间维护状态和缓存。
下图显示了应用切换后的目标状态：
本文中所述的技术实现了完全切换：100% 的流量被路由到新群集。 这是因为路由是在 DNS 级别应用的，其中 A 或 CNAME 记录分配已更新为指向绿色群集，并且每个群集都有一个应用程序网关。
以下是用于切换面向私人的终结点的配置示例。 建议的解决方案使用 A 记录进行切换。 从 DNS 和 IP 映射的角度来看，切换前的情况如下：
A记录aks.priv.contoso.com指向蓝色应用程序网关的专用 IP。A记录aks-blue.priv.contoso.com指向蓝色应用程序网关的专用 IP。A记录aks-green.priv.contoso.com指向绿色应用程序网关的专用 IP。
切换重新配置为以下内容：
A记录aks.priv.contoso.com指向绿色应用程序网关的专用 IP。A记录aks-blue.priv.contoso.com指向蓝色应用程序网关的专用 IP。A记录aks-green.priv.contoso.com指向绿色应用程序网关的专用 IP。
群集的用户将在生存时间 (TTL) 和记录的 DNS 传播之后看到切换。
对于面向公共的终结点，建议的方法使用 Azure Front Door 和 Azure DNS。 切换前的配置如下：
CNAME记录official-aks.contoso.com指向自动生成的 Azure Front Door 域的记录。 有关详细信息，请参阅教程：将自定义域添加到 Front Door。A记录aks.contoso.com指向蓝色应用程序网关的公共 IP。- Azure Front Door 源配置指向
aks.contoso.com主机名。 有关配置后端池的详细信息，请参阅 Azure Front Door 中的源和源组。A记录aks-blue.contoso.com指向蓝色应用程序网关的公共 IP。A记录aks-green.contoso.com指向绿色应用程序网关的公共 IP。
切换重新配置为以下内容：
CNAME记录official-aks.contoso.com指向自动生成的 Azure Front Door 域的记录。A记录aks.contoso.com指向绿色应用程序网关的公共 IP。- Azure Front Door 源配置指向
aks.contoso.com主机名。A记录aks-blue.contoso.com指向蓝色应用程序网关的公共 IP。A记录aks-green.contoso.com指向绿色应用程序网关的公共 IP。
其他的切换技术（如 Canary 版本的部分切换）可通过 Azure Front Door 或流量管理器等其他 Azure 服务实现。 有关在 Azure Front Door 级别实现蓝绿流量切换的信息，请参阅使用 Azure Front Door 进行蓝绿部署。
如示例中所述，从网络的角度来看，该技术基于四个主机名的定义：
- 面向公共的官方主机名：最终用户和使用者使用的官方公共主机名。
- 群集主机名：群集中托管的工作负载的使用者使用的官方主机名。
- 蓝色群集主机名：蓝色群集的专用主机名。
- 绿色群集主机名：绿色群集的专用主机名。
群集主机名是在应用程序网关级别配置以管理入口流量的主机名。 主机名也是 AKS 入口配置的一部分，以便正确管理传输层安全性 (TLS)。 此主机仅用于实时事务和请求。
如果 Azure Front Door 也是部署的一部分，则不受切换的影响，因为它只管理官方群集主机名。 它为应用程序用户提供适当的抽象。 它们不受切换的影响，因为 DNS CNAME 记录始终指向 Azure Front Door。
蓝色和绿色的群集主机名主要用于测试和验证群集。 出于这些目的，主机名在具有专用终结点的应用程序网关级别公开，并且在 AKS 入口控制器级别公开以正确管理 TLS。
在此阶段，验证基于基础结构和应用监视指标，以及官方 SLO 和 SLA（如果可用）。 如果验证成功，则转换到最后阶段以销毁蓝色群集。
T4：销毁蓝色群集
成功切换流量后，进入最后阶段，在此阶段仍会进行验证和监视，以确保绿色群集按预期方式使用实时流量。 验证和监视涵盖平台和应用程序级别。
完成此验证后，可以销毁蓝色群集。 为了降低成本并正确利用 Azure 提供的弹性（尤其是 AKS），强烈建议执行销毁步骤。
蓝色群集被销毁后的情况如下：
组件
- Azure 应用程序网关是一种 Web 流量（OSI 第 7 层）负载均衡器，可用于管理 Web 应用程序的流量。 在此解决方案中，它被用作访问 AKS 群集的 HTTP 流量的网关。
- Azure Kubernetes 服务 (AKS) 是一项托管 Kubernetes 服务，可以用于部署和管理容器化应用程序。 此应用程序平台是此模式的主要组件。
- Azure 容器注册表是一项托管服务，用于存储和管理容器映像和相关项目。 在此解决方案中，用于在 AKS 群集中存储和分发容器映像和项目，例如 Helm 图表。
- Azure Monitor 是一种监视解决方案，可用于收集、分析和响应来自云和本地环境的监视数据。 它提供执行蓝绿部署所需的核心监视功能。 之所以在此体系结构中使用时因为它与 AKS 集成，能够提供日志记录、监视和警报功能，可用于管理阶段转换。
- Azure Key Vault 可帮助解决以下问题：机密管理、密钥管理和证书管理；它用于存储和管理此解决方案的平台和应用程序级别所需的机密和证书。
- Azure Front Door 是一个全局负载均衡器和应用程序终结点管理系统。 在此解决方案中，它被用作托管在 AKS 上的 HTTP 应用程序的公共终结点。 在此解决方案中，它主要负责管理蓝色群集和绿色应用程序网关之间的流量切换。
- Azure DNS 是 DNS 域的托管服务，它使用 Microsoft Azure 基础结构提供名称解析。 它管理蓝色和绿色群集的解决方案中使用的主机名，在流量切换中发挥着重要作用，特别是对于专用终结点。
备选方法
- 有一些替代技术可以实现提供更多控制的流量切换。 例如，可以使用基于以下一项或多项的流量规则进行部分切换：
- 传入流量的百分比
- HTTP 标头
- Cookie
- 另一种为更改引起的问题提供更大保护的替代方法是进行基于环的部署。 除了蓝色和绿色群集，还可以有其他群集，称为环。 每个环都足够大，足以容纳有权访问新版本 AKS 的用户数量。 至于此处所述的蓝绿部署，可以删除环，以进行适当的成本优化和控制。
- 应用程序网关的可能替代项是 NGINX 和 HAProxy。
- 容器注册表的可能替代项是 Harbor。
- 在某些情况下，可以使用不同的负载均衡和 DNS 服务来进行流量切换，而不是使用 Azure Front Door 和 Azure DNS。
- 此解决方案基于标准入口控制器 Kubernetes API。 如果解决方案会受益于网关 API，请使用适用于容器的应用程序网关。 它可以帮助管理负载均衡，并处理应用程序网关和 Pod 之间的入口流量管理。 适用于容器的应用程序网关控制应用程序网关的设置。
方案详细信息
该解决方案的主要有点是：
- 最大限度地减少部署期间的故障时间。
- 计划的回滚策略。
- 改进了 AKS 更改和升级的发布和部署期间的控制和操作。
- 测试是否需要执行灾难恢复 (DR) 程序。
以下文章讨论了蓝绿部署的关键原则和基础方面：
从自动化和 CI/CD 的角度来看，可通过多种方式实现该解决方案。 我们建议：
- 对 IaC 使用 Bicep 或 Terraform。
- 对 CI/CD 使用 Azure Pipelines 或 GitHub Actions。
可能的用例
通过蓝绿部署，可以在不影响正在运行的应用程序和工作负载的情况下对群集进行更改。 更改示例如下：
- 运营更改
- 激活新的 AKS 功能
- 更改群集中的共享资源
- 更新 Kubernetes 版本
- 修改 Kubernetes 资源和对象，如入口网关、服务网格、运算符、网络策略等
- 回滚到仍在部署的 AKS 群集的先前版本，而不影响群集中运行的工作负载
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改善工作负荷质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
- 蓝绿部署可以完全自动化，就像零接触部署一样。 通常，初始实现具有手动触发器，用于激活阶段。 在此过程中，具有适当的成熟度和监视功能后，可自动执行触发器。 这意味着有自动化测试和特定指标、SLA 和 SLO 来自动执行触发器。
- 必须为蓝色和绿色群集提供专用主机名，并且在群集前的网关和负载均衡器上设置专用终结点配置。 这对于提高新群集部署的可靠性和有效性至关重要。 通过这种方式，部署的验证将采用标准生产群集的相同体系结构和配置。
- 如果 AKS 群集是不同业务部门管理的多个应用程序的共享资源。 在这种情况下，AKS 平台本身通常由专门的团队管理，该团队负责群集的整体运营和生命周期，并且群集中存在用于管理和运营目的的终结点。 建议在 AKS 群集中为这些终结点提供专用入口控制器，以适当分离关注点并提高可靠性。
- 蓝绿部署对于为 AKS 和相关工作负载实现和测试业务连续性和灾难恢复 (BC/DR) 解决方案非常有用。 尤其是，它提供了用于管理多个群集的基本结构，包括群集分布在多个区域中的情况。
- 蓝绿部署的成功依赖于将实现的所有方面（如自动化、监视和验证）应用于 AKS 平台，同时应用于部署在平台上的工作负载和应用。 这样做有助于从蓝绿部署中获得最大好处。
- 在建议的解决方案中，每个方案都有两个应用程序网关（公共和专用），因此总共有四个。 此决定是在 Azure 应用程序网关级别应用蓝绿部署，以避免网关配置错误导致的停机时间。 此决定的主要缺点是成本，因为有四个应用程序网关实例。 它们仅在应用程序网关配置（如 WAF 策略或扩展配置）发生相关更改的时间段内并行运行。 要进一步优化成本，可以为每个方案选择单个应用程序网关，这意味着总共有两个应用程序网关。 这需要将蓝/绿逻辑移动到应用程序网关，而不是 Azure Front Door。 因此，不是 Azure Front Door 被强制控制，而是应用程序网关。
可靠性
可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性支柱概述。
- 蓝绿部署对 AKS 平台和工作负载的可用性具有直接和积极的影响。 具体而言，它提高了 AKS 平台更改部署期间的可用性。 如果用户会话管理得当，故障时间会很少。
- 蓝绿部署为部署期间的可靠性提供了保障，因为默认情况下，如果新群集版本出现问题，可以选择回滚到 AKS 群集的先前版本。
成本优化
成本优化是关于寻找减少不必要开支和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。
- 由于云提供的本机弹性，蓝绿部署在 Azure 中被广泛采用。 这使得可以在运营和资源消耗方面优化成本。 大部分节省来自于在成功部署新版本的群集后删除不再需要的群集。
- 部署新版本时，通常在同一子网中同时托管蓝色和绿色群集，以继续具有相同的成本基线。 这两个群集的所有网络连接和对资源和服务的访问都是相同的，所有 Azure 服务和资源保持不变。
卓越运营
卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅卓越运营支柱概述。
- 正确实现的蓝绿部署可提供自动化、持续交付和可复原部署。
- 持续交付的关键方面之一是迭代地交付平台和工作负载更改的增量。 通过 AKS 的蓝绿部署，可以在平台级别以可控且安全的方式实现持续交付。
- 复原能力是蓝绿部署的基础，因为它包含回滚到先前群集的选项。
- 蓝绿部署提供了适当的自动化级别，以减少与业务连续性策略相关的工作量。
- 监视平台和应用对于成功实现至关重要。 对于平台，可以使用本机 Azure 监视功能。 对于应用，需要设计和实施监视。
部署此方案
有关本指南中所述蓝绿部署的已实现示例，请参阅 AKS 登陆区域加速器。
此参考实现基于应用程序网关和应用程序网关入口控制器 (AGIC)。 每个群集都有自己的应用程序网关，流量切换是通过 DNS 完成的，具体来说，是通过 CNAME 配置。
重要
对于任务关键型工作负载，请务必将本指南中所述的蓝/绿部署与部署自动化和持续验证相结合，以实现零故障时间部署。 任务关键型设计方法中提供了详细的信息和指导。
区域注意事项
可以将蓝色和绿色群集部署到不同区域或同一区域。 设计和运营原则不受此选择的影响。 但是，某些类型的其他网络配置可能会受到影响，例如：
- AKS 和应用程序网关的专用虚拟网络和子网。
- 与 Monitor、容器注册表和 Key Vault 等支持服务的连接。
- 应用程序网关的 Azure Front Door 可见性。
部署到同一区域的先决条件如下：
- 必须调整虚拟网络和子网的大小以托管两个群集。
- Azure 订阅必须为这两个群集提供足够的容量。
部署入口控制器和外部负载均衡器
可通过不同方式部署入口控制器和外部负载均衡器：
- 可以拥有带专用外部负载均衡器的单个入口控制器，例如本指南所述体系结构的参考实现。 AGIC 是一个 Kubernetes 应用程序，可用于使用应用程序网关 L7 负载均衡器将云软件公开到 Internet。 在某些情况下，除了应用程序终结点外，AKS 群集中还有管理员终结点。 管理员终结点用于在应用程序上执行操作任务，或执行配置任务，例如更新配置映射、机密、网络策略和清单。
- 可以拥有单个外部负载均衡器，为部署在同一群集或多个群集上的多个入口控制器提供服务。 参考实现中未涵盖此方法。 在这种情况下，建议为面向公共的终结点和面向私人的终结点提供单独的应用程序网关。
- 本指南中提出和描述的最终体系结构基于作为 AKS 群集一部分部署的标准入口控制器，如基于 NGINX 和 Envoy 的入口控制器。 在参考实现中，我们使用 AGIC，这意味着应用程序网关和 AKS Pod 之间存在直接连接，但这不会影响整体蓝绿体系结构。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Vincenzo Morra | SAO 孵化架构师
其他参与者：
- Oscar Pla Alvarez | 域解决方案架构师
要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。
后续步骤
- 什么是基础结构即代码 (IaC)？
- 蓝绿部署 (Martin Fowler)
- AKS 文档
- Monitor 文档
- 蓝绿部署的 AKS 登陆区域加速器
- Azure 上任务关键型工作负载的体系结构模式
- 用于保护网络连接的 Azure 服务
- Azure 的 Microsoft 云采用框架