我们于 2023 年 1 月发布了 NGINX Ingress Controller 3.0 版本，其中包含许多重要的新特性和增强功能。我们相信您会发现一项特别有价值的新功能是 Deep Service Insight，该功能可在 NGINX Ingress Controller 的 NGINX Plus 版本中使用。
Deep Service Insight 解决了当负载均衡器等路由决策系统位于一个或多个 Kubernetes 集群前面时阻碍最佳功能的限制，即系统无法访问有关正在运行的各个服务的运行状况的信息在 Ingress 控制器后面的集群中。这可以防止它仅将流量路由到服务正常的集群，从而可能使您的用户面临中断和 404 和 500 等错误。
深度服务洞察通过在专用端点公开后端服务 Pod 的健康状态（由 NGINX 入口控制器收集）来消除该问题您的系统可以访问并使用它来做出更好的路由决策。
在这篇文章中，我们深入研究 Deep Service Insight 解决的问题，解释它在一些常见用例中的工作原理，并展示如何配置它。
为什么要深入服务洞察？
标准的 Kubernetes 活跃度、就绪度和启动探测为您提供了有关集群中运行的后端服务的一些信息，但不足以提供您在整个堆栈中做出更好的路由决策所需的洞察力。随着 Kubernetes 部署的复杂性不断增加，并且不间断正常运行时间的业务需求变得更加紧迫，缺乏正确的信息会变得更加成问题。
扩展 Kubernetes 环境时提高正常运行时间的常见方法是在集群前面部署负载均衡器、DNS 管理器和其他自动化决策系统。然而，由于 Ingress 控制器的工作方式，负载均衡器位于 fKubernetes 集群的前端通常无法访问集群中 Ingress 控制器背后的服务的状态信息 – 它只能验证 Ingress 控制器 Pod 本身是否健康并接受流量。
另一方面，NGINX Ingress Controller 确实拥有有关服务运行状况的信息。它已经通过定期发送 HTTP、TCP、UDP 和 gRPC 服务的被动运行状况检查、监控请求响应以及跟踪成功的响应代码和其他指标来监控集群中上游 Pod 的运行状况。它使用此信息来决定如何在服务的 Pod 之间分配流量，以提供一致且可预测的用户体验。通常，NGINX Ingress Controller 会在后台默默地执行所有这些魔法，您可能永远不会仔细考虑幕后发生的事情。深度服务洞察力“展现”这些有价值的信息，以便您可以更有效地使用它ely 位于堆栈的其他层。
深度服务洞察力如何发挥作用？
Deep Service Insight 可用于使用 NGINX VirtualServer 和 TransportServer 自定义资源（分别适用于 HTTP 和 TCP/UDP）部署的服务。 Deep Service Insight 使用 NGINX Plus API 在 Deep Service Insight 独有的专用端点上共享 NGINX Ingress Controller 对后端服务中各个 Pod 的视图：
- 对于 VirtualServer – : /probe/
- 对于 TransportServer – : /probe/ts/
哪里
- 属于 NGINX 入口控制器
- 是 Deep Service Insight 端口号（默认为 9114）
- 是 VirtualServer 资源的 spec.host 字段中定义的服务域名
- 是服务的名称如 TransportServer 资源中的 spec.upstreams.service 字段中所定义
输出包括两种类型的信息：
主机名或服务名称的 HTTP 状态代码：
- 200 OK – 至少有一个 Pod 运行正常
- 418 我是一个茶壶 – 没有茶荚是健康的
- 404 Not Found – 没有与指定主机名或服务名称匹配的 Pod
指定主机名或服务名称的三个计数器：
- 服务实例（Pod）总数
- 处于 Up（正常）状态的 Pod 数量
- 处于不健康状态的 Pod 数量
下面是一个示例，其中某个服务的所有三个 Pod 均运行正常：
HTTP/1.1 200 好
内容类型：application/json；字符集=utf-8
日期：日，DD 星期一 YYYY hh:mm:ss TZ
内容长度：32
{“总计”:3,”向上”:3,”不健康”:0}
有关更多详细信息，请参阅 NGINX 入口控制器文档。
您可以进一步通过配置主动运行状况检查，自定义 NGINX Ingress Controller 用于确定 pod 是否运行状况的标准。您可以配置健康检查发送到的路径和端口、在指定时间段内必须发生的失败检查次数（Pod 被视为不健康）、预期状态代码、连接或接收响应的超时，以及更多的。在 VirtualServer 或 TransportServer 资源中包含 Upstream.Healthcheck 字段。
深度服务洞察的示例用例
深度服务洞察特别有价值的一个用例是，负载均衡器将流量路由到在两个集群中运行的服务（例如为了实现高可用性）。在每个集群中，NGINX Ingress Controller 如上所述跟踪上游 Pod 的运行状况。当您启用 Deep Service Insight 时，有关健康和不健康上游 Pod 数量的信息也会在专用端点上公开。您的路由决策系统em 可以访问端点并使用该信息将应用程序流量从不健康的 pod 转移到健康的 pod。
该图说明了 Deep Service Insight 在此场景中的工作原理。
在高可用性场景中对集群执行维护时，您还可以利用 Deep Service Insight。只需在进行维护的集群中将服务的 pod 数量缩减至零即可。缺少健康 Pod 的情况会自动显示在 Deep Service Insight 端点上，并且您的路由决策系统使用该信息将流量发送到其他集群中的健康 Pod。您可以有效地实现自动故障转移，而无需更改 NGINX Ingress Controller 或系统上的配置，并且您的客户永远不会遇到服务中断。
启用深度服务洞察
要启用 Deep Service Insight，请包含 -enable-service-insight 命令行参数在 Kubernetes 清单中，或者如果使用 Helm，则将 serviceInsight.create 参数设置为 true。
您可以包含两个可选参数来调整您环境的端点：
- -service-insight-listen-port – 更改 Deep Service Insight 端口号的默认值 9114（ 是 1024–65535 范围内的整数）。 Helm 等效项是 serviceInsight.port 参数。
- -service-insight-tls-string – 用于 Deep Service Insight 端点的 TLS 终止的 Kubernetes 密钥（TLS 证书和密钥）（ 是格式为 / 的字符串）。 Helm 等效项是 serviceInsight.secret 参数。
示例：为咖啡馆应用程序启用深度服务洞察
要查看 Deep Service Insight 的实际效果，您可以为 NGINX Ingress Controller 文档中经常用作示例的 Cafe 应用程序启用它。
安装 NGINX Ingress Controller 的 NGINX Plus 版本，支持 NGINX 自定义资源并启用 Deep Service Insight：
- 如果使用 Helm，请将 serviceInsight.create 参数设置为 true。
- 如果使用 Kubernetes 清单（Deployment 或 DaemonSet），请在清单文件中包含 -enable-service-insight 参数。
验证 NGINX 入口控制器正在运行：
$ kubectl get pods -n nginx-ingress
名字已准备好…
入口加-nginx-入口-6db8dc5c6d-cb5hp 1/1 …
…状态重新开始
… 运行 0 9d
验证是否为 Cafe 应用程序部署了 NGINX VirtualServer 自定义资源（为了便于阅读，省略了 IP 地址）：
$ kubectl 获取 vs
名称 状态 主机 IP 端口 年龄
咖啡馆 有效咖啡馆.example.com …[80,443] 7 小时 1 分钟
验证 Cafe 服务是否有三个上游 Pod 在 Cafe.example.com 上运行：
$ kubectl 获取 Pod
名称就绪状态重新开始年龄
咖啡-87cf76b96-5b85h 1/1 运行 0 7h39m
咖啡-87cf76b96-lqjrp 1/1 运行 0 7h39m
tea-55bc9d5586-9z26v 1/1 运行 0 111m
访问 Deep Service Insight 端点：
$curl -i :9114/probe/cafe.example.com
200 OK 响应代码表示服务已准备好接受流量（至少有一个 Pod 运行正常）。在这种情况下，所有三个 pod 都处于 Up 状态。
HTTP/1.1 200 好
内容类型：application/json；字符集=utf-8
日期：日，DD 星期一 YYYY hh:mm:ss TZ
内容长度：32
{“总计”:3,”向上”:3,”不健康”:0}
418 I’m a teapot 状态代码表示服务不可用（所有 Pod 均不正常）。
HTTP/1.1 418 我是茶壶
内容类型：application/json；字符集=UTF-8
日期：日，DD 星期一 YYYY hh:mm:ss TZ
内容长度：32
{“总计”:3,”向上”:0,”不健康”:3}
404 Not Found 状态代码表示指定主机名上没有正在运行的服务。
HTTP/1.1 404 未找到
日期：日，DD 星期一 YYYY hh:mm:ss TZ
内容长度：0
资源
有关 NGINX Ingress Controller 版本 3.0.0 的完整变更日志，请参阅发行说明。
要尝试使用 NGINX Plus 和 NGINX App Protect 的 NGINX Ingress Controller，请立即开始 30 天免费试用或联系我们讨论您的使用案例。
发表回复