如何通过高级流量管理提升Kubernetes韧性

NGINX | 2021年3月29日

Jenn GileNGINX产品营销负责人

编者：本文是一个共10篇的系列文章之一：

还可以免费下载包含全套博客文章的电子书：《推动Kubernetes从测试走向生产》。

要判断一家公司是否未能成功运用现代应用开发技术，有一个很简单的方法：看其客户是否很快就在社交媒体上抱怨。他们会抱怨无法流畅观看最新的热门剧集、无法使用网上银行，或因购物车超时而无法完成购买。

即使客户没有公开抱怨，也不意味着糟糕的体验不会造成影响。我们的一家大型保险公司客户表示，如果其主页未能在3秒内加载，就会导致客户流失。

所有关于性能不佳或服务中断的用户投诉，都指向一个共同原因：韧性不足。微服务技术（包括容器和Kubernetes）的优势在于，它们可以提升应用的韧性，从而显著改善客户体验。如何实现？关键在于架构。

我喜欢用一串节日彩灯来比喻单体架构与微服务架构的核心区别。老式彩灯串中只要有一个灯泡熄灭，整串灯就会全部熄灭。如果无法更换灯泡，这串灯唯一值得装饰的地方恐怕就是垃圾桶内部了。这种老式彩灯就像单体应用，其组件同样紧密耦合，只要一个组件出现故障，整个应用就会失效。

但照明行业和软件行业一样，也发现了这一痛点。现代灯串中的一个灯泡损坏时，其他灯泡仍会继续发光；同样，设计良好的微服务应用即使某个服务实例发生故障，也能继续运行。

Kubernetes流量管理

容器是微服务架构中的常见选择，因为它们非常适合使用更小的独立组件构建应用，而且轻量、可移植且易于扩展。Kubernetes是容器编排领域公认的标准，但要让Kubernetes达到生产就绪状态，仍面临诸多挑战。成熟的流量管理策略有助于增强对Kubernetes应用的控制并提高其韧性。借助该策略，可以控制服务而非数据包，并可动态调整流量管理规则，或通过Kubernetes API进行调整。流量管理对任何架构都很重要，而对于高性能应用，以下两种流量管理工具不可或缺：流量控制和流量拆分。

流量控制

流量控制（有时称为“流量路由”或“流量整形”）是指控制流量的去向及其到达方式。在生产环境中运行Kubernetes时，流量控制必不可少，因为它有助于保护基础设施和应用免受攻击及流量激增的影响。建议在应用开发周期中采用以下两种技术：“速率限制”和“熔断”。

用例：保护服务，避免请求过多
解决方案：速率限制无论是恶意请求（例如暴力猜测密码和DDoS攻击），还是正常请求（例如客户集中抢购促销商品），大量HTTP请求都可能使服务不堪重负，并导致应用崩溃。速率限制可限制用户在给定时间段内能够发出的请求数量。请求可以是简单的请求，例如针对网站首页的GET请求，也可以是针对登录表单的POST请求。例如，遭受DDoS攻击时，可以使用速率限制，将传入请求速率限制在真实用户的典型水平。
用例：我希望避免级联故障
解决方案：熔断当服务不可用或延迟较高时，传入请求可能需要很长时间才会超时，客户端也要等待很久才能收到错误响应。长时间的超时可能导致级联故障，即一项服务中断导致其他服务超时，最终造成整个应用故障。熔断器通过监控服务故障来防止级联故障。当向某项服务发出的失败请求数超过预设阈值时，熔断器会触发，并在请求到达时立即向客户端返回错误响应，从而有效限制流向该服务的流量。熔断器会在规定时间内持续拦截并拒绝请求，之后允许少量请求通过以进行测试。如果这些请求成功，熔断器将停止限制流量。否则，计时器将重置，熔断器会在规定时间内再次拒绝请求。

流量拆分

流量拆分（有时称为流量测试）是流量控制的一个子类别，指控制传入流量的分配比例，将其导向同一环境中同时运行的不同后端应用版本（通常是当前生产版本和更新版本）。它是应用开发周期的重要环节，因为团队可以借此测试新功能和新版本的功能与稳定性，同时避免对客户造成负面影响。适用的部署场景包括调试路由、金丝雀部署、A/B测试和蓝绿部署。（业界对这4个术语的用法存在较大差异。本文根据我们对其定义的理解使用这些术语。）

用例：准备在生产环境中测试新版本
解决方案：调试路由假设您有一款银行应用，并计划添加信用评分功能。在面向客户测试之前，可能需要先了解该功能在生产环境中的表现。调试路由支持公开部署该功能，同时根据会话Cookie、会话ID或组ID等第7层属性，仅允许特定用户访问，从而对实际用户“隐藏”该功能。例如，可以仅允许拥有管理员会话Cookie的用户访问。他们的请求会被路由到包含信用评分功能的新版本，而其他所有用户仍使用稳定版本。
用例：我需要确保新版本稳定
解决方案：金丝雀部署金丝雀部署这一概念源自一种早期的采矿做法：矿工将装有金丝雀的笼子带入煤矿，用于预警有毒气体。金丝雀会先于矿工受到毒气伤害，让矿工能够迅速逃离危险。在应用领域，不会伤害任何鸟类！金丝雀部署提供了一种安全、敏捷的方式，用于测试新功能或新版本的稳定性。典型的金丝雀部署会先让大部分用户（例如99%）继续使用稳定版本，再将一小部分用户（其余1%）迁移到新版本。如果新版本出现故障，例如崩溃或向客户端返回错误，可以立即将测试组迁回稳定版本。如果新版本运行成功，则可以一次性将所有用户从稳定版本切换到新版本，也可以采用更常见的方式，逐步、有序地完成迁移。
用例：我需要了解客户是否更喜欢新版本，而不是当前版本
解决方案：A/B测试确认新功能可在生产环境中正常运行后，您可能希望根据点击次数、回访用户数或明确评分等关键绩效指标（KPI），收集客户反馈以评估该功能的成效。A/B测试广泛应用于多个行业，通过衡量和比较用户行为，确定不同产品或应用版本在客户群体中的相对成效。在典型的A/B测试中，50%的用户使用版本A（当前应用版本），其余50%的用户使用版本B（包含已稳定的新功能的版本）。整体KPI表现更好的版本胜出。
用例：我希望在不停机的情况下将用户迁移到新版本
解决方案：蓝绿部署假设您的银行应用即将进行重大版本升级……恭喜！过去，版本升级通常意味着用户会遇到停机，因为必须先停用旧版本，才能将新版本投入生产。但在当今竞争激烈的环境中，大多数用户都无法接受升级导致的停机。蓝绿部署可大幅减少甚至消除升级停机时间。只需让旧版本（蓝色）继续在生产环境中运行，同时在同一生产环境中并行部署新版本（绿色）。大多数组织都不希望一次性将100%的用户从蓝色版本迁移到绿色版本，毕竟，如果绿色版本出现故障怎么办？解决方案是采用金丝雀部署，按照最符合风险缓解策略的增量逐步迁移用户。如果新版本出现严重问题，只需按几下键，即可轻松将所有用户切换回稳定版本。

NGINX如何提供帮助

大多数Ingress控制器和服务网格都可以实现高级流量控制和拆分。具体使用哪种技术，取决于应用架构和用例。例如，在以下三种场景中，适合使用Ingress控制器：

应用只有一个端点，例如简单应用，或通过“直接迁移”方式迁移到Kubernetes的单体应用。
集群中不存在服务间通信。
存在服务间通信，但尚未使用服务网格。

如果部署环境较为复杂，需要使用服务网格，一种常见用例是在服务之间拆分流量，以便测试或升级单个微服务。例如，可以在移动前端后方，对地理位置微服务API的两个不同版本进行金丝雀部署。

然而，出于多种原因，使用某些Ingress控制器和服务网格设置流量拆分可能既耗时又容易出错：

不同供应商的Ingress控制器和服务网格采用不同方式实现Kubernetes功能。
Kubernetes本身并非专为管理和理解第7层流量而设计。
某些Ingress控制器和服务网格不支持高级流量管理。

借助NGINX Ingress Controller和NGINX Service Mesh，您只需几秒即可轻松配置可靠的流量路由和拆分策略。观看由专家演示的直播，并继续阅读，了解我们如何通过更简单的配置、高级自定义功能和更出色的可见性，帮助您节省时间。

使用NGINX Ingress Resources和SMI规范，配置更轻松

以下NGINX功能可简化配置：

适用于NGINX Ingress Controller的NGINX Ingress资源：标准Kubernetes Ingress资源可简化SSL/TLS终止、HTTP负载均衡和第7层路由的配置，但不包含断路、A/B测试和蓝绿部署所需的自定义功能。因此，非NGINX用户必须使用注解、ConfigMap和自定义模板。这些方式都缺乏精细控制，存在安全隐患，容易出错且难以使用。NGINX Ingress Controller提供NGINX Ingress资源，作为标准Ingress资源的替代方案（同时也支持标准Ingress资源）。这些资源提供原生、类型安全且采用缩进格式的配置方式，可简化Ingress负载均衡的实施。对于现有NGINX用户，NGINX Ingress资源还有一项额外优势：可以更轻松地复用非Kubernetes环境中的负载均衡配置，让所有NGINX负载均衡器使用相同的配置。
采用SMI的NGINX Service Mesh：NGINX Service Mesh实现了Service Mesh Interface（SMI）。这是一项规范，为Kubernetes上的服务网格定义了标准接口，并提供以下类型化资源：TrafficSplit、TrafficTarget和HTTPRouteGroup。通过标准Kubernetes配置方法，NGINX Service Mesh和NGINX SMI扩展可简化金丝雀部署等流量拆分策略的部署，并尽量减少对生产流量的干扰。例如，可按如下方式使用NGINX Service Mesh定义金丝雀部署：

apiVersion: split.smi-spec.io/v1alpha2kind: TrafficSplit
metadata:
name: target-ts
spec:
service: target-svc
backends:
- service: target-v1-0
    weight: 90
- service: target-v2-0
    weight: 10

我们的教程《使用流量拆分进行部署》介绍了利用流量拆分的示例部署模式，包括金丝雀部署和蓝绿部署。

通过高级自定义实现更精细的流量控制和拆分

借助以下NGINX功能，可以轻松实现更精细的流量控制和拆分：

用于金丝雀部署的键值存储：执行A/B测试或蓝绿部署时，您可能希望按特定增量将流量逐步迁移到新版本，例如0%、5%、10%、25%、50%和100%。使用大多数工具时，这一过程需要大量手动操作，因为每次调整增量都必须修改百分比并重新加载配置文件。由于操作开销较大，您可能会决定承担风险，直接从5%提高到100%。不过，使用基于NGINX Plus的NGINX Ingress Controller版本，可以利用键值存储更改百分比，无需重新加载。
使用NGINX Ingress Controller实现熔断，高级熔断器可更快地检测故障并进行故障转移，甚至为运行状况不佳的上游服务器启用自定义格式的错误页面，从而节省时间并提高韧性。例如，可以将搜索服务的熔断器配置为返回格式正确但内容为空的搜索结果集。为实现这种高级功能，基于NGINX Plus的NGINX Ingress Controller使用主动健康检查，主动监控TCP和UDP上游服务器的运行状况。通过实时监控，客户端遇到应用返回错误的可能性会降低。
使用NGINX Service Mesh实现断路：NGINX Service Mesh的断路器规范包含3个自定义字段：虽然errors和timeoutSeconds是标准的断路器功能，但fallback允许定义备用服务器，从而进一步增强韧性。如果备用服务器返回的响应具有独特特征，这些响应可以作为集群出现问题的早期信号，便于立即开始排查。
- errors：触发熔断前的错误次数
- timeoutSeconds ；触发断路器前允许错误发生的时间窗口，以及关闭断路器前的等待时间
- fallback：熔断器触发后，流量将重新路由到的Kubernetes服务的名称和端口

使用仪表板解读流量拆分结果

您已实施流量拆分……接下来该做什么？现在需要分析结果。这可能是最困难的环节，因为许多组织缺乏关键洞察，无法了解其Kubernetes流量和应用的运行状况。借助NGINX Plus仪表板和预构建的Grafana仪表板，NGINX可帮助您更轻松地获取洞察。这些仪表板可将Prometheus Exporter公开的指标可视化。要进一步了解如何提高可见性以获取洞察，请阅读我们博客中的《如何提高Kubernetes的可见性》。