如何通过高级流量管理提高 Kubernetes 的弹性
编辑– 这篇文章是10 篇系列文章的一部分：
- 使用生产级 Kubernetes 降低复杂性
- 如何通过高级流量管理提高 Kubernetes 的弹性（本帖）
- 如何提高 Kubernetes 中的可见性
- 使用流量管理工具保护 Kubernetes 的六种方法
- 选择入口控制器的指南，第 1 部分： 确定您的需求
- 选择入口控制器的指南，第 2 部分： 风险与未来保障
- 选择入口控制器的指南，第 3 部分： 开源与…… 默认与…… 商业的
- 选择入口控制器的指南，第 4 部分： NGINX 入口控制器选项
- 如何选择服务网格
- 在动态 Kubernetes 云环境中对 NGINX Ingress 控制器进行性能测试
您还可以下载完整的博客作为免费的电子书 -将 Kubernetes 从测试带到生产。
有一个非常简单的方法可以判断一家公司没有成功地使用现代应用程序开发技术——它的客户很快就会在社交媒体上抱怨。 当他们无法观看最新的值得一看的电影时，他们就会抱怨。 或者访问网上银行。 或者进行购买，因为购物车已超时。
即使顾客没有公开投诉，也不意味着他们的不良经历不会产生后果。 我们的一个客户——一家大型保险公司——告诉我们，如果他们的主页在3 秒内无法加载，他们就会失去客户。
所有关于性能不佳或中断的用户投诉都指向一个共同的罪魁祸首：弹性......或缺乏弹性。 微服务技术（包括容器和 Kubernetes）的优点在于，它们可以通过提高应用程序的弹性来显著改善客户体验。 如何？ 一切都与建筑有关。
我喜欢用节日灯串的比喻来解释单片架构和微服务架构之间的核心区别。 当旧式灯串上的灯泡熄灭时，整条灯串都会变暗。 如果您不能更换灯泡，那么唯一值得用这串灯泡装饰的东西就是垃圾桶的内部。 这种旧式的灯就像一个单片应用程序，它也具有紧密耦合的组件，如果一个组件损坏，它就会失效。
但照明行业和软件行业一样，都察觉到了这个痛点。 当现代灯串上的一个灯泡坏了，其他灯泡仍然会继续明亮地闪烁，就像精心设计的微服务应用程序即使服务实例出现故障也能继续工作一样。
Kubernetes 流量管理
容器是微服务架构中的热门选择，因为它们非常适合使用较小的离散组件构建应用——它们轻量、可移植且易于扩展。 Kubernetes是容器编排的事实标准，但在使 Kubernetes 投入生产方面存在很多挑战。 成熟的流量管理策略是提高您对 Kubernetes 应用的控制力及其弹性的因素之一，它允许您控制服务而不是数据包，并动态或使用 Kubernetes API 调整流量管理规则。虽然流量管理在任何架构中都很重要，但对于高性能应用来说，两种流量管理工具必不可少：流量控制和流量分割。
交通管制
流量控制（有时称为流量路由或流量整形）是指控制流量去往何处以及如何到达那里的行为。 在生产中运行 Kubernetes 时它是必需的，因为它可以保护您的基础设施和应用程序免受攻击和流量高峰的影响。 在您的应用程序开发周期中需要纳入的两种技术是速率限制和断路。
用例： 我想保护服务不接收过多请求
解决方案： 速率限制无论是恶意的（例如，暴力破解密码和 DDoS 攻击）还是良性的（例如客户蜂拥而至购买促销商品），大量的 HTTP 请求都可能使您的服务不堪重负并导致您的应用程序崩溃。 速率限制限制了用户在给定时间段内可以发出的请求数量。 请求可以包括一些简单的内容，例如网站主页的
GET请求或登录表单的POST请求。 例如，在遭受 DDoS 攻击时，您可以使用速率限制将传入请求速率限制为真实用户的典型值。用例： 我想避免连锁故障
解决方案： 熔断当服务不可用或延迟较高时，传入请求可能需要很长时间才能超时，客户端也可能需要很长时间才能收到错误响应。 长时间超时可能会导致级联故障，其中一项服务的中断会导致其他服务超时，并最终导致整个应用失败。
断路器通过监控服务故障来防止连锁故障。 当对某个服务的失败请求数量超过预设的阈值时，断路器就会跳闸，并在请求到达时立即向客户端返回错误响应，从而有效地限制服务的流量。
断路器会在定义的时间内持续拦截和拒绝请求，然后允许有限数量的请求通过作为测试。 如果这些请求成功，断路器将停止限制流量。 否则，时钟将重置，并且断路器将再次拒绝定义时间内的请求。
流量拆分
流量分割（有时称为流量测试）是流量控制的一个子类别，指的是控制流向在环境中同时运行的后端应用程序的不同版本（通常是当前生产版本和更新版本）的传入流量的比例的行为。 它是应用程序开发周期的重要组成部分，因为它允许团队测试新功能和版本的功能和稳定性，而不会对客户产生负面影响。 有用的部署场景包括调试路由、金丝雀部署、 A/B 测试和蓝绿部署。 （整个行业对这四个术语的使用存在相当大的不一致。 在这里我们按照我们理解的定义来使用它们。）
用例： 我已准备好在生产中测试新版本
解决方案： 调试路由假设您有一个银行应用程序，并且您要添加信用评分功能。 在与客户测试之前，您可能想看看它在生产中的表现。 通过调试路由，您可以公开部署它，但通过仅允许特定用户访问它（基于第 7 层属性，例如会话 Cookie、会话 ID 或组 ID），将其“隐藏”在实际用户面前。例如，您可以只允许拥有管理员会话 Cookie 的用户访问 - 他们的请求将被路由到具有信用评分功能的新版本，而其他所有人则继续使用稳定版本。
用例： 我需要确保我的新版本是稳定的
解决方案： 金丝雀部署金丝雀部署的概念源自历史上的采矿实践，当时矿工们将关在笼子里的金丝雀带入煤矿，作为有毒气体的早期预警。 这种气体在杀死矿工之前就杀死了金丝雀，使他们能够迅速逃离危险。 在应用程序的世界里，没有鸟受到伤害！ 金丝雀部署提供了一种安全、灵活的方法来测试新功能或新版本的稳定性。 典型的金丝雀部署从大部分（比如 99%）使用稳定版本的用户开始，然后将一小部分（另外 1%）用户迁移到新版本。 如果新版本出现故障，例如崩溃或向客户端返回错误，您可以立即将测试组移回稳定版本。 如果成功，您可以将用户从稳定版本切换到新版本，可以一次性切换，也可以（更常见）以逐步、受控的方式进行迁移。
用例： 我需要了解客户是否更喜欢新版本而不是当前版本
解决方案： A/B 测试现在您已确认新功能可在生产中运行，您可能希望根据关键绩效指标 (KPI)（例如点击次数、重复用户或明确评分）获取有关该功能成功的客户反馈。 A/B 测试是许多行业使用的一种过程，用于衡量和比较用户行为，以确定不同产品或应用程序版本在客户群中的相对成功率。 在典型的 A/B 测试中，50% 的用户获得版本 A（当前应用版本），而剩余 50% 的用户获得版本 B（具有新但稳定功能的版本）。 总体而言拥有更佳 KPI 的公司即为获胜者。
用例： 我希望在不停机的情况下将用户迁移到新版本
解决方案： 蓝绿部署现在假设您的银行应用程序需要进行重大版本更改……恭喜！ 过去，升级版本通常意味着用户停机，因为您必须先删除旧版本，然后才能将新版本投入生产。 但在当今的竞争环境中，升级造成的停机对于大多数用户来说是不可接受的。 蓝绿部署大大减少甚至消除了升级造成的停机时间。 只需将旧版本（蓝色）保留在生产中，同时在同一生产环境中部署新版本（绿色）。
大多数组织不希望一次性将 100% 的用户从蓝色版本移至绿色版本——毕竟，如果绿色版本失败了怎么办？！ 解决方案是使用金丝雀部署来以最符合您的风险缓解策略的增量移动用户。 如果新版本是一个灾难，您只需按几下键就可以轻松地将所有人恢复到稳定版本。
NGINX 如何提供帮助
您可以使用大多数Ingress 控制器和服务网格完成高级流量控制和分割。 使用哪种技术取决于您的应用程序架构和用例。 例如，在以下三种情况下使用 Ingress 控制器是有意义的：
- 您的应用程序只有一个端点，就像您“提升并转移”到 Kubernetes 的简单应用程序或单片应用程序一样。
- 您的集群中没有服务到服务的通信。
- 存在服务到服务的通信，但您尚未使用服务网格。
如果您的部署足够复杂，需要服务网格，那么一个常见的用例是在服务之间分割流量以进行测试或升级单个微服务。 例如，您可能希望在移动前端后面、地理位置微服务 API 的两个不同版本之间进行金丝雀部署。
但是，由于多种原因，使用某些 Ingress 控制器和服务网格设置流量分割可能非常耗时且容易出错：
- 不同供应商的入口控制器和服务网格以不同的方式实现 Kubernetes 功能。
- Kubernetes 实际上并不是为管理和理解第 7 层流量而设计的。
- 一些 Ingress 控制器和服务网格不支持复杂的流量管理。
借助NGINX Ingress Controller和NGINX Service Mesh ，您可以在几秒钟内轻松配置强大的流量路由和拆分策略。 与我们的专家一起观看此直播演示，并继续阅读，了解我们如何通过更简单的配置、高级定制和改进的可见性为您节省时间。
使用 NGINX Ingress 资源和 SMI 规范更轻松地进行配置
这些 NGINX 功能使配置更加容易：
NGINX Ingress Controller 的 NGINX Ingress 资源– 虽然标准 Kubernetes Ingress 资源可以轻松配置 SSL/TLS 终止、HTTP 负载均衡和第 7 层路由，但它不包含断路、A/B 测试和蓝绿部署所需的自定义功能。 相反，非 NGINX 用户必须使用注释、ConfigMap 和自定义模板，这些都缺乏细粒度的控制、不安全、容易出错且难以使用。
NGINX Ingress Controller 附带NGINX Ingress 资源，作为标准 Ingress 资源（它也支持）的替代。 它们提供本机的、类型安全的和缩进的配置样式，从而简化了 Ingress 负载均衡的实现。 NGINX Ingress 资源为现有 NGINX 用户带来了额外的好处：它们可以更轻松地从非 Kubernetes 环境重新利用负载均衡配置，因此所有 NGINX 负载均衡器都可以使用相同的配置。
带有 SMI 的 NGINX 服务网格——NGINX 服务网格实现了服务网格接口 (SMI)，该规范为 Kubernetes 上的服务网格定义了一个标准接口，具有
TrafficSplit、TrafficTarget和HTTPRouteGroup等类型化资源。 使用标准 Kubernetes 配置方法，NGINX Service Mesh 和NGINX SMI 扩展使流量分割策略（如金丝雀部署）易于部署，对生产流量的中断最小。 例如，下面是如何用 NGINX Service Mesh 定义金丝雀部署：api版本：split.smi-spec.io/v1alpha2kind： TrafficSplit 元数据： 名称：target-ts 规格： 服务：target-svc 后端： - 服务：target-v1-0 权重： 90 - 服务：target-v2-0 权重： 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 服务网格进行熔断– NGINX 服务网格断路器规范有三个自定义字段：
错误– 电路跳闸前的错误数量timeoutSeconds– 跳闸前发生错误的窗口，以及关闭电路前等待的时间fallback– 线路跳闸后，流量将重新路由到的 Kubernetes 服务的名称和端口
虽然
错误和超时秒数是标准的断路器功能，但回退功能允许您定义备份服务器，从而进一步提高弹性。 如果您的备份服务器响应是唯一的，则它们可以作为集群出现问题的早期指标，让您立即开始排除故障。
使用仪表板解释流量拆分结果
您已实施流量分割……现在做什么？ 现在该分析结果了。 这可能是最困难的部分，因为许多组织缺乏对其 Kubernetes 流量和应用程序运行情况的关键见解。 NGINX 通过NGINX Plus 仪表板和预构建的 Grafana 仪表板可视化 Prometheus Exporter 公开的指标，让获取洞察变得更加容易。 有关如何提高可见性以获得洞察力的更多信息，请阅读我们博客上的如何提高 Kubernetes 中的可见性。
使用 NGINX 掌握微服务
基于 NGINX Plus 的 NGINX Ingress Controller 可免费试用 30 天，其中包括NGINX App Protect ，可保护您的容器化应用程序。
要使用 NGINX 开源尝试 NGINX Ingress Controller，您可以获取发布源代码，或从DockerHub下载预构建的容器。
永久免费的 NGINX Service Mesh 可在f5.com下载。
“这篇博文可能引用了不再可用和/或不再支持的产品。 有关 F5 NGINX 产品和解决方案的最新信息，请探索我们的NGINX 产品系列。 NGINX 现在是 F5 的一部分。 所有之前的 NGINX.com 链接都将重定向至 F5.com 上的类似 NGINX 内容。”