通过 OpenKruise 实现基于 Higress 的全链路灰度

OpenKruise 是一个基于 Kubernetes 的扩展套件，主要聚焦于云原生应用的自动化，比如部署、发布、运维以及可用性防护。本文介绍通过 OpenKruise 构建自动化运维的方式实现全链路灰度功能。

灰度发布提高应用交付的稳定性和效率

在发布应用的过程中，我们通常希望用少量特定流量来验证新版本的发布是否正常，以保障整体稳定性。这个过程被称为灰度发布。关于灰度发布，我们通过逐步增加发布的范围，来验证新版本的稳定性。如果新版本出现问题，我们也能及时发现，控制影响范围，保障整体的稳定性。

渐进式发布一般具有以下特点：

• 逐步增加发布的影响范围，拒绝一次性全部发布；
• 阶段性的发布过程，可以通过金丝雀发布方式小心验证，以验证新版本的稳定性；
• 可暂停、可回滚、可继续、可自动化状态流转，以便灵活地控制发布过程并确保稳定性。

据调研数据 70% 的线上问题都是由于变更导致，我们常说安全生产三板斧，可灰度、可观测、可回滚，也是为了控制变更带来的风险与影响面。通过采用灰度发布的方式，我们能够更加稳健地发布新版本，避免因发布过程中出现的问题而带来的损失。

微服务架构对灰度发布提出了更高的要求

在微服务架构的场景下，传统的灰度发布模式往往不能满足微服务交付的复杂、多样化的需求。这是因为：

• 微服务调用链路比较长，比较复杂。在微服务架构中，服务之间的调用链路比较复杂，一个服务的改动可能会影响到整个调用链路，从而影响整个应用的稳定性。
• 一次灰度可能涉及多个模块，整个链路都要调用新版本。由于微服务架构中服务之间相互依赖，一个服务的修改可能需要其他服务的相应调整。这就导致了在进行灰度发布时，需要同时调用多个服务的新版本，增加了发布的复杂度和不确定性。
• 多个项目并行，需要部署多套环境，环境构建不灵活、成本高。在微服务架构中，往往会有多个项目并行开发，需要部署多套环境来支持不同的项目。这就增加了环境构建的难度和成本，从而导致发布效率低下。

为了解决这些问题，我们需要采用更加灵活、可控并且适用于微服务场景的发布方式，全链路灰度发布的场景也就应运而生。通常每个微服务都会有灰度环境或分组来接受灰度流量。我们希望进入上游灰度环境的流量也能进入下游灰度的环境中，确保1个请求始终在灰度环境中传递，从而形成流量“泳道”。在“泳道”内的流量链路中，即使这个调用链路上有一些微服务应用不存在灰度环境，那么这些微服务应用在请求下游应用的时候依然能够回到下游应用的灰度环境中。

全链路灰度为微服务发布保驾护航

这种方式可以根据服务的实际情况，可以对单个服务可以进行独立的发布和流量控制，也可以控制多个服务同时进行发布变更，从而保证整个系统的稳定性。同时，还可以采用自动化的部署方式，实现快速、可靠的发布过程，提高发布效率和稳定性。

实践全链路灰度的挑战

在 K8s 中实现微服务全链路灰度发布是一个非常复杂的过程，需要涉及多个组件和配置的修改与协调。以下是具体的一些步骤和问题：

• 在微服务架构中，网关是服务的入口，需要根据灰度发布的要求，调整网关配置，实现路由匹配和流量特征（比如 Header 修改）。
• 为了实现全链路灰度发布，需要新部署一套灰度应用环境，并为其打上灰度标记（新部署一套 Gray 应用以及 Gray 灰度标）。这样可以将流量流向灰度环境，从而实现灰度发布。
• 验证流量正常，将基线环境升级，销毁灰度环境，恢复网关配置。在灰度发布过程中，需要对流量进行验证，确保流量的正常流向和服务的正常运行。如果验证通过，可以将基线环境升级到灰度版本，并销毁灰度环境。最后，需要恢复网关的配置，以确保流量正常流向。
• 如果发生异常，需要快速回滚。由于微服务架构复杂，可能会出现各种异常情况，比如服务崩溃、流量异常等。在这种情况下，需要快速回滚，以避免产生更大的损失。因此，需要预先设计好回滚方案，并在发生异常时快速执行回滚操作。

另外一方面，生产的流量是端到端的，那么意味着我们需要控制流量在前端、网关、后端各个微服务等组件中闭环。不仅仅是 RPC/Http 的流量，对于异步调用比如 MQ 流量我们也需要符合全链路“泳道”调用的规则，这整个过程中涉及到的流量控制的复杂度也是非常高的。

为了简化微服务全链路灰度发布的过程，可以使用一些自动化工具和产品，如 MSE、Kruise Rollout 等。这些工具和产品可以帮助我们更加便捷地实现微服务全链路灰度发布，并提高发布的效率和稳定性。

Kruise Rollout+MSE 端到端的全链路灰度发布实践

为什么要 Kruise Rollout？