利用 NGINX Ingress Controller 的深度服务洞察做出更好的决策

我们于 2023 年 1 月发布了NGINX Ingress Controller 3.0 版本，其中包含一系列重要的新功能和增强功能。 我们相信您会发现特别有价值的一个新功能是 Deep Service Insight，它可与 NGINX Plus 版本的 NGINX Ingress Controller 一起使用。

Deep Service Insight 解决了当路由决策系统（例如负载均衡器）位于一个或多个 Kubernetes 集群前面时阻碍其最佳运行的限制，即系统无法访问有关在 Ingress 控制器后面的集群中运行的各个服务的运行状况的信息。 这会阻止它仅将流量路由到具有健康服务的集群，这可能会使您的用户面临中断和错误，例如404和500。

Deep Service Insight 通过在专用端点上公开后端服务 pod 的运行状况（由 NGINX Ingress Controller 收集）来消除该问题，您的系统可以在该端点访问并使用它来做出更好的路由决策。

在这篇文章中，我们深入研究了 Deep Service Insight 解决的问题，解释了它在一些常见用例中的工作原理，并展示了如何配置它。

为什么要进行深度服务洞察？

标准的 Kubernetes 活跃度、就绪度和启动探测会为您提供有关集群中运行的后端服务的一些信息，但这些信息不足以让您获得在整个堆栈中做出更好的路由决策所需的洞察力。 随着 Kubernetes 部署的复杂性日益增加，以及对不间断正常运行时间的业务需求变得更加迫切，缺乏正确的信息会变得更加成问题。

在扩展 Kubernetes 环境时提高正常运行时间的常用方法是在集群前部署负载均衡器、DNS 管理器和其他自动决策系统。 但是，由于 Ingress 控制器的工作方式，位于 Kubernetes 集群前面的负载均衡器通常无法访问有关集群中 Ingress 控制器后面的服务的状态信息 - 它只能验证 Ingress 控制器 pod 本身是否健康并接受流量。

另一方面，NGINX Ingress Controller 确实具有有关服务健康的信息。 它已经通过发送HTTP 、 TCP 、 UDP和gRPC服务的定期被动健康检查、监视请求响应能力以及跟踪成功响应代码和其他指标来监视集群中上游 pod 的健康状况。 它使用这些信息来决定如何在服务的 pod 之间分配流量，以提供一致且可预测的用户体验。 通常情况下，NGINX Ingress Controller 会在后台默默地执行所有这些神奇的操作，您可能永远不会考虑背后到底发生了什么。 Deep Service Insight 将这些宝贵的信息“浮现出来”，以便您可以在堆栈的其他层更有效地使用它。

深度服务洞察如何发挥作用？

Deep Service Insight 适用于您使用 NGINX VirtualServer和TransportServer自定义资源（分别用于 HTTP 和 TCP/UDP）部署的服务。 Deep Service Insight 使用NGINX Plus API在 Deep Service Insight 独有的专用端点上共享 NGINX Ingress Controller 对后端服务中各个 pod 的视图：

• 对于虚拟服务器 - <IP 地址> :<端口> /探测/<主机名>
• 对于 TransportServer – <IP 地址> :<端口> /探测/ts/<服务名称>

在哪里

• <IP 地址> 属于 NGINX Ingress Controller
• <端口> 是 Deep Service Insight 端口号（默认为 9114）
• <主机名> 是服务的域名，定义在 规范主机 VirtualServer 资源的字段
• <服务名称> 是服务的名称，定义在 规范.上游.服务 TransportServer 资源中的字段

输出包括两类信息：

1. 主机名或服务名称的 HTTP 状态代码：

   • 200 OK – 至少有一个 Pod 是健康的
   • 418 我是茶壶——没有豆荚是健康的
   • 404 未找到– 没有与指定主机名或服务名称匹配的 Pod

2. 指定主机名或服务名称的三个计数器：

   • 服务实例 (pod)总数
   • 处于Up （健康）状态的 Pod 数量
   • 处于不健康状态的 Pod 数量

以下是一个示例，其中服务的所有三个 Pod 均处于健康状态：

HTTP/1.1 200 OKContent-Type: 应用/json; charset=utf-8 日期： 日, DD 星期一 YYYY hh : mm : ss TZ内容长度： 32 {"总计":3,"上升":3,"不健康":0}

有关更多详细信息，请参阅 NGINX Ingress Controller文档。

您可以通过配置主动健康检查进一步定制 NGINX Ingress Controller 用来判断 pod 是否健康的标准。 您可以配置发送健康检查的路径和端口、在指定时间段内必须发生的失败检查次数（该次数会使 Pod 被视为不健康）、预期状态代码、连接或接收响应的超时时间等。 在VirtualServer或TransportServer资源中包含Upstream.Healthcheck字段。

深度服务洞察的示例用例

Deep Service Insight 特别有价值的一个用例是当负载均衡器将流量路由到在两个集群中运行的服务时，例如为了实现高可用性。 在每个集群中，NGINX Ingress Controller 会跟踪上游 pod 的健康状况，如上所述。 当您启用 Deep Service Insight 时，有关健康和不健康上游 pod 数量的信息也会在专用端点上公开。 您的路由决策系统可以访问端点并使用该信息将应用流量从不健康的 pod 转移到健康的 pod。

该图说明了 Deep Service Insight 在此场景中的工作方式。

在高可用性场景中对集群执行维护时，您还可以利用 Deep Service Insight。 只需将您正在进行维护的集群中服务的 pod 数量缩减为零即可。 缺少健康的 Pod 会自动显示在 Deep Service Insight 端点上，并且您的路由决策系统会使用该信息将流量发送到另一个集群中健康的 Pod。 您可以有效地获得自动故障转移，而无需更改 NGINX Ingress Controller 或系统上的配置，并且您的客户永远不会遇到服务中断。

实现深度服务洞察

要启用 Deep Service Insight，请在 Kubernetes 清单中包含-enable-service-insight命令行参数，或者如果使用 Helm，则将serviceInsight.create参数设置为true 。

您可以包含两个可选参数来调整适合您环境的端点：

• -service-insight-监听端口 <端口> – 将 Deep Service Insight 端口号从默认的 9114 更改为<端口> 是 1024–65535 范围内的整数。 Helm 等效项是serviceInsight.port参数。
• -service-insight-tls 字符串 <秘密> – 用于终止 Deep Service Insight 端点的 TLS 的 Kubernetes 密钥（TLS 证书和密钥）（<秘密> 是具有格式的字符串 <命名空间>/<秘密名称>）。 Helm 等效项是serviceInsight.secret参数。

例子： 为咖啡厅application启用深度服务洞察

要查看 Deep Service Insight 的实际效果，您可以为 NGINX Ingress Controller 文档中经常用作示例的Cafe应用启用它。

1. 安装 NGINX Plus 版本的 NGINX Ingress Controller，支持 NGINX 自定义资源并启用 Deep Service Insight：

   • 如果使用Helm ，请将serviceInsight.create参数设置为true 。
   • 如果使用Kubernetes 清单（Deployment 或 DaemonSet），请在清单文件中包含-enable-service-insight参数。

2. 验证 NGINX Ingress Controller 是否正在运行：

   $ kubectl 获取 pods -n nginx-ingress名称已就绪... ingress-plus-nginx-ingress-6db8dc5c6d-cb5hp 1/1... ...  状态重新开始年龄...  正在运行 0 9天

3. 根据README中的说明部署 Cafe应用。

4. 验证是否为 Cafe应用部署了 NGINX VirtualServer 自定义资源（为了容易辨认，省略了 IP 地址）：

   $ kubectl get vs NAME STATE HOST IP PORTS AGE cafe Valid cafe.example.com ... [80,443] 7h1m

5. 验证cafe.example.com上是否有三个 Cafe 服务的上游 pod 在运行：

   $ kubectl get pods NAME READY STATUS RESTARTS AGE coffee-87cf76b96-5b85h 1/1 运行 0 7h39m coffee-87cf76b96-lqjrp 1/1 运行 0 7h39m tea-55bc9d5586-9z26v 1/1 运行 0 111m

6. 访问 Deep Service Insight 端点：

   $ curl -i <NIC_IP_地址>:9114/probe/cafe.example.com

   这200OK响应代码表示服务已准备好接受流量（至少一个 pod 是健康的）。 在这种情况下，所有三个 pod 都处于 Up 状态。

   HTTP/1.1 200 OK 内容类型： 应用/json; charset=utf-8 日期： 日, DD 星期一 YYYY hh : mm : ss TZ内容长度： 32 {"总计":3,"上升":3,"不健康":0}

   这418我是茶壶状态代码，表示服务不可用（所有 pod 都不健康）。

   HTTP/1.1 418 我是茶壶内容类型：应用/json；charset=utf-8 日期： 日, DD 星期一 YYYY hh : mm : ss TZ内容长度： 32 {"总计":3,"上升":0,"不健康":3}

   这404未找到状态代码表示指定主机名上没有运行服务。

   HTTP/1.1 404 未找到日期： 日, DD 星期一 YYYY hh : mm : ss TZ内容长度： 0

资源

有关 NGINX Ingress Controller 版本 3.0.0 的完整更新日志，请参阅发行说明。

要尝试使用 NGINX Ingress Controller 与 NGINX Plus 和 NGINX App Protect，请立即开始30 天免费试用或联系我们讨论您的用例。