如何通过高级流量管理提高 Kubernetes 的弹性
原文作者：Jenn Gile - F5 NGINX 产品营销经理
原文链接：如何通过高级流量管理提高 Kubernetes 的弹性
转载来源：NGINX 中文官网
NGINX 唯一中文官方社区 ，尽在 nginx.org.cn
编者按 —— 本文是以下系列博文中的一篇（共十篇）：
如何通过高级流量管理提高 Kubernetes 的弹性（本文）
您还可以免费下载整套博文集结成的电子书：《Kubernetes：从测试到生产》。
如何判断一家公司是否成功使用了现代应用开发技术呢？很简单，看看客户有没有在社交媒体上抱怨就知道了。客户可能会抱怨新片看不了，网银登不上去，购物车超时无法下单。
（我正要看一个我租借的电影，但是老是弹出“视频播放错误”的提示，并且网站帮助页面的网址也打不开。我的 App 是最新版本，我试过了退出重新登陆，也重启过我的网络电视。求个解决方案？）
即使他们没有公开抱怨，也不代表就没有问题。我们的一位客户 —— 一家大型保险公司曾告诉我们，如果他们未能在仅仅 3 秒内加载出主页，便会面临客户流失的问题。
用户对性能差或宕机问题的所有抱怨都指向了一个共同的元凶：缺乏弹性。微服务技术（包括容器和 Kubernetes）好就好在它能提高应用弹性，显著改善客户体验。为什么呢？这一切得从架构说起。
微服务架构与单体架构存在本质上的区别。打个比方，在老式的节日灯串中，只要有一个灯坏了，整串就都不亮了。如果不换灯泡，那就只能将整串丢掉。单体应用就像这种老式灯串一样，其组件紧密耦合在一起，一损俱损。
但是，照明行业和软件行业都发现了这个痛点。如果现代灯串上的某个灯泡发生故障，其他灯泡仍会继续照明。同样，对于设计良好的微服务应用而言，即使个别服务实例发生故障，整个应用也会继续运行。
Kubernetes 流量管理
容器因其轻便、可移植和易于扩展的特点，非常适合需要使用小型独立组件构建应用的场景，因而成为了微服务架构中颇受欢迎的一种选择。Kubernetes 已成为容器编排的事实标准，但若投入生产环境，还面临着许多挑战。要想增强 Kubernetes 应用的可控性和弹性，成熟的流量管理策略是一个重要因素，它能够让您控制服务而不是数据包，并动态地或使用 Kubernetes API 调整流量管理规则。流量管理在任何架构中都很重要，但对于高性能应用来说，有两个流量管理工具是必不可少的：流量控制和流量精分。
流量控制
流量控制（有时称为“流量路由”或“流量整形”）是指控制流量去向及其传输方式的行为。在生产环境中运行 Kubernetes 是必须的，因为它可以保护您的基础架构和应用免遭攻击和流量激增。在应用开发过程中，您需要采用“速率限制”和“断路”这两种技术。
用例：我不希望服务接收过多请求
解决方案：速率限制
无论 HTTP 请求是恶意的（例如暴力破解密码和 DDoS 攻击）还是正常的（例如顾客蜂拥抢购），大量的 HTTP 请求都会导致服务瘫痪和应用崩溃。速率限制技术可限制用户在给定时间段内的请求数量。这些请求可能非常简单，例如访问网站主页的 GET 请求，或是登录页面上的 POST 请求。举例来说，当受到 DDoS 攻击时，您可以使用速率限制将传入的请求速率限制为真实用户的合理数值。
用例：我希望避免出现级联故障
解决方案：断路
当服务不可用或出现高延迟时，传入请求的超时时间以及客户端收到错误响应的时间可能很长。长超时可能会造成级联故障，即一个服务中断导致其他服务超时，最终引发整个应用故障。
断路器可监控服务故障，防止发生级联故障。当服务请求的失败次数超过预先设定的阈值时，将触发断路器，断路器一收到请求就向客户端返回错误响应，从而对服务进行限流。
断路器将持续拦截和拒绝请求，等过了指定的时长后再放行有限数量的请求以作测试。如果这些请求成功，断路器将停止限流。如果不成功，则开始重新计时，期间断路器继续拒绝请求。
流量精分
流量精分（有时称为“流量测试”）是流量控制的一个子类，目的是为了控制传入流量的比例，这些流量会被导向到在环境中同时运行的不同版本的后端应用（通常为当前的生产版本和新版本）。流量精分是应用开发周期中的重要一环，允许团队在不影响客户的情况下测试新特性和版本的功能和稳定性。实用的部署场景包括调试路由、灰度部署、A/B 测试 和 蓝绿部署。（业界对这四个术语的使用存在很大分歧，此处先按我们理解的定义来使用它们。）
用例：我准备在生产环境中测试新版本
解决方案：调试路由
假设您有一个银行应用，现在您要为其添加一个信用评分功能。在进行客户测试之前，您可能想要看一下它在生产环境中的表现。调试路由允许您公开部署新功能，同时又向真正的用户“隐藏”它，根据 session cookie、session ID 或 group ID 等 7 层属性，只允许特定用户访问它。例如，您可以只允许拥有管理会话 cookie 的用户访问 —— 他们的请求将被路由到具有信用评分功能的新版本，而其他用户则继续访问稳定版。
用例：我需要确保新版本性能稳定
解决方案：灰度部署（又称“金丝雀部署”）
金丝雀部署的概念来自一个历史悠久的采矿实践，当时的矿工将金丝雀装在笼子里带入矿井，一旦发现金丝雀中毒就紧急撤离，因此金丝雀是“瓦斯报警鸟”。在应用世界里，不会再有牺牲品了。灰度部署为测试新特性或新版本的稳定性提供了一种安全、敏捷的方法。典型的灰度部署是，先让绝大多数（比如 99%）用户使用稳定版，然后将一小部分用户（剩余的 1%）转移到新版本。如果新版本出现问题（例如崩溃或向客户端返回错误），您可以立即将测试用户转移回稳定版。如果新版本顺利运行，您可以一次性或以可控的方式逐步（更为常见）将用户从稳定版迁移到新版本。
用例：我需要了解新版本是否比当前版本更受客户的喜爱
解决方案：A/B 测试
确认新特性在生产环境中运行无误后，您可能还希望了解客户对该特性的反馈，包括点击量、回头客比率或显式评分等关键性能指标 (KPI)。许多行业都使用 A/B 测试流程来衡量和比较用户行为，目的是确定不同产品或应用版本在客户群体中的受欢迎程度。在典型的 A/B 测试中，50% 的用户访问版本 A（当前的应用版本），剩余 50% 的用户访问版本 B（包含稳定的新功能的版本）。KPI 综合得分最高的版本将胜出。
用例：我希望在不停机的情况下将用户转移到新版本
解决方案：蓝绿部署
现在，假设您的银行应用即将进行重大版本变更，那么，恭喜您！过去，版本升级通常意味着用户停机，因为您必须先从生产环境中移除旧版本，然后才能再推送新版本。但在当今竞争激烈的环境中，大多数用户都无法接受停机升级。蓝绿部署极大地减少甚至消除了升级的停机时间。您可以继续在生产环境中运行旧版本（蓝），同时在该生产环境中部署新版本（绿）。
大多数企业都不愿意将所有用户一次性从蓝色转移到绿色，毕竟，如果绿色版本发生故障怎么办？！解决方案是使用灰度部署，以最符合您的风险规避策略的增量方式转移用户。如果新版本是一场灾难，您只需敲击几下键盘，便可以轻松地将每个人转移回稳定版。
NGINX 如何助您一臂之力
大多数 Ingress controllers 和 service mesh（服务网格）都可以帮助您实现高级流量控制和分割。使用哪种技术取决于您的应用架构和用例。例如，Ingress controller 适用于以下三种场景：
您的应用只有一个端点，就像您迁移到 Kubernetes 的简单应用或单体应用一样。
集群中没有 service 到 service 的通信。
集群中有 service 到 service 的通信，但您还没有使用 service mesh。
如果您的部署复杂到要使用 service mesh 的地步，一个常见的用例是通过分割服务流量来测试或升级各个微服务。举例来说，您可能想在移动前端的两个不同版本的地理位置微服务 API 之间进行灰度部署。
然而，有些 Ingress controller 和 service mesh 在设置流量精分时不仅非常耗时，而且容易出错，原因有很多：
不同厂商的 Ingress controller 和 service mesh 具有不同的 Kubernetes 功能实施方式。
Kubernetes 不是专为管理和理解 7 层流量而生。
有些 Ingress controller 和 service mesh 不支持复杂的流量管理。
借助 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 用户来说，NGINX Ingress 资源还有一个额外的好处：它们可以简化非 Kubernetes 环境中负载均衡配置的再利用，从而支持所有 NGINX 负载均衡器使用相同的负载均衡配置。
遵循 SMI 的 NGINX Service Mesh —— NGINX Service Mesh 实施了 Service Mesh Interface (SMI) —— SMI 是一个规范。定义了在 Kubernetes 上运行的 Service Mesh 的标准接口，具有
TrafficSplit、TrafficTarget和HTTPRouteGroup。等类型化资源。借助标准的 Kubernetes 配置方法，NGINX Service Mesh 和 NGINX SMI 扩展程序可简化流量精分策略（如灰度部署）的部署，并最大限度地减少对生产流量的中断。以下是使用 NGINX Service Mesh 定义灰度部署的示例：
我们的教程《使用流量精分的部署》介绍了利用流量精分的部署模式示例，包括灰度部署和蓝绿部署。
借助高级定制实现更复杂的流量控制和流量精分
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 断路器规范具有三个自定义字段：
errors—— 断路器触发前的错误数timeoutSeconds—— 断路器触发前发生错误的窗口，以及断路器关闭前的等待时间fallback—— o 断路器触发后，流量被重新路由到的 Kubernetes 服务的名称和端口
errors 和 timeoutSeconds 是标准的断路器功能，而 fallback 支持您定义备份服务器，进一步提高了弹性。如果您的备份服务器响应是独一无二的，它们可以作为集群故障的早期指示器，让您第一时间开启故障排除。
借助仪表盘解读流量精分结果
现在，您已实现了流量精分……接下来该做什么呢？接下来我们应该分析流量精分结果。这可能是最难的一个环节，因为许多企业都缺乏对 Kubernetes 流量和应用运行情况的关键洞察。NGINX 可通过 NGINX Plus 仪表盘 和预构建的 Grafana 仪表盘，以图示的形式展示 Prometheus Exporter 暴露的指标，从而帮助您更轻松地获取洞察信息。如欲详细了解如何提高可视性、获取洞察，请阅读我们的博文 《如何提高 Kubernetes 环境的可视性》。
NGINX 助您轻松掌控微服务
基于 NGINX Plus 的 NGINX Ingress Controller 提供 30 天免费试用版，其中包括可以保护容器化应用的 NGINX App Protect。
如欲试用 NGINX 开源版 NGINX Ingress Controller，您可以获取发布源代码，或者从 DockerHub下载预构建的容器。
您可前往 f5.com 下载始终免费的 NGINX Service Mesh。
NGINX 唯一中文官方社区 ，尽在 nginx.org.cn
NGINX唯一中文官方社区 2022-07-04 加入
- 微信公众号：https://mp.weixin.qq.com/s/XVE5yvDbmJtpV2alsIFwJg - 微信群：https://www.nginx.org.cn/static/pc/images/homePage/QR-code.png?v=1621313354 - B站：https://space.bilibili.com/628384319
评论