借助NGINX Ingress Controller的深度服务洞察，做出更明智的决策

Akash Ananthanarayanan技术营销经理 | F5 NGINX

我们于2023年1月发布了NGINX Ingress Controller 3.0版，其中包含多项重要的新功能和功能增强。我们认为，Deep Service Insight这项新功能尤其有价值，可用于NGINX Ingress Controller的NGINX Plus版本。

当负载均衡器等路由决策系统位于一个或多个Kubernetes集群前端时，会面临一项影响其充分发挥作用的限制：该系统无法获取Ingress控制器后端集群中各项服务的运行状况信息。Deep Service Insight可解决这一限制。由于缺少这些信息，系统无法仅将流量路由到服务运行正常的集群，可能导致用户遭遇服务中断以及404和500等错误。

Deep Service Insight通过专用端点公开后端服务Pod的运行状况（由NGINX Ingress Controller收集），使系统能够访问并利用这些信息优化路由决策，从而解决这一问题。

本文将深入探讨Deep Service Insight所解决的问题，说明其在一些常见用例中的工作原理，并介绍如何进行配置。

为何选择Deep Service Insight？

标准的Kubernetes存活、就绪和启动探针可以提供集群中后端服务的部分信息，但这些信息不足以帮助您深入了解整个技术栈，从而做出更合理的路由决策。随着Kubernetes部署日益复杂，业务对持续可用的要求愈发迫切，缺少适当信息会带来更严重的问题。

随着Kubernetes环境扩展，提高正常运行时间的一种常见方法是在集群前端部署负载均衡器、DNS管理器和其他自动决策系统。但是，由于Ingress控制器的工作方式，位于Kubernetes集群前端的负载均衡器通常无法获取集群中Ingress控制器后端服务的状态信息，只能确认Ingress控制器Pod本身运行正常且正在接收流量。

相比之下，NGINX Ingress Controller可以获取服务运行状况信息。它会定期对集群中的上游Pod执行被动运行状况检查，以监控HTTP、TCP、UDP和gRPC服务的请求响应情况，并跟踪成功响应代码及其他指标，从而持续监控上游Pod的运行状况。它利用这些信息来决定如何在服务的各个Pod之间分配流量，以提供一致且可预测的用户体验。通常，NGINX Ingress Controller会在后台默默完成这一切，您可能从未留意其内部的运行机制。Deep Service Insight会将这些宝贵信息呈现出来，以便您在技术栈的其他层更有效地加以利用。

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的视图：

• 对于VirtualServer：<IP_address>：<port>/probe/<hostname>
• 对于TransportServer：<IP_address>：<port>/probe/ts/<service_name>

其中

• <IP_address>属于NGINX Ingress Controller
• <port>是Deep Service Insight端口号（默认为9114）
• <hostname> 是服务的域名，该域名在VirtualServer资源的spec.host字段中定义
• <service_name> 是在 TransportServer 资源的 spec.upstreams.service 字段中定义的服务名称

输出包含两类信息：

1. 主机名或服务名称的HTTP状态码：
   • 200 OK ，至少有一个 Pod 处于健康状态
   • 418 I’m a teapot：没有健康的 Pod
   • 404 Not Found：没有与指定主机名或服务名称匹配的 Pod
2. 指定主机名或服务名称的3个计数器：
   • Total 服务实例（Pod）数
   • 处于Up（健康）状态的 Pod 数量
   • 处于Unhealthy状态的 Pod 数量

以下示例中，某项服务的3个Pod均处于健康状态：

HTTP/1.1 200 OKContent-Type: application/json; charset=utf-8
Date: Day, DD Mon YYYY hh:mm:ss TZ
Content-Length: 32
{"Total":3,"Up":3,"Unhealthy":0}

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

通过配置主动健康检查，可以进一步自定义NGINX Ingress Controller用于判断Pod是否健康的条件。可配置健康检查的目标路径和端口、在指定时间段内将Pod判定为不健康所需的检查失败次数、预期状态码、连接或接收响应的超时时间等。请在Upstream.Healthcheck资源中添加VirtualServer或TransportServer字段。

深度服务洞察用例示例

Deep Service Insight 特别适用于以下场景：负载均衡器将流量路由到在两个集群中运行的服务，例如用于实现高可用性。在每个集群中，NGINX Ingress Controller 会按上述方式跟踪上游 Pod 的运行状况。启用 Deep Service Insight 后，专用端点还会公开健康和不健康上游 Pod 的数量信息。路由决策系统可以访问该端点，并利用这些信息将应用流量从不健康的 Pod 转移到健康的 Pod。

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

在高可用场景中对集群执行维护时，也可以利用Deep Service Insight。只需在要维护的集群中，将相应服务的Pod数量缩减至零。Deep Service Insight端点会自动显示没有健康Pod，路由决策系统将利用此信息，把流量发送到另一个集群中的健康Pod。这样无需更改NGINX Ingress Controller或路由决策系统的配置，即可实现自动故障转移，避免客户遇到服务中断。

启用Deep Service Insight

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

可使用以下两个可选参数，根据您的环境调整端点：

• -service-insight-listen-port <port>：将Deep Service Insight端口号从默认值9114更改为指定值（<port>是1024至65535范围内的整数）。对应的Helm参数为serviceInsight.port。
• -service-insight-tls-string <secret> ；用于终止Deep Service Insight端点TLS连接的Kubernetes Secret（TLS证书和密钥）（<secret>是采用以下格式的字符串：<namespace>/<secret_name>）。对应的Helm参数为serviceInsight.secret。

示例：为Cafe应用启用Deep Service Insight

要了解Deep Service Insight的实际运行效果，可以为Cafe application启用此功能。该应用常用作NGINX Ingress Controller文档中的示例。

1. 安装NGINX Ingress Controller的NGINX Plus版本，支持NGINX自定义资源并启用Deep Service Insight：
   • 如果使用Helm，请将serviceInsight.create参数设置为true。
   • 如果使用Kubernetes 清单（Deployment 或 DaemonSet），请在清单文件中添加-enable-service-insight参数。
2. 验证NGINX Ingress Controller是否正在运行：

$ kubectl get pods -n nginx-ingressNAME                                          READY ...
ingress-plus-nginx-ingress-6db8dc5c6d-cb5hp   1/1   ...  

    ...  STATUS   RESTARTS   AGE
    ...  Running   0          9d

1. 按照README中的说明部署Cafe应用。
2. 验证是否已为Cafe应用部署NGINX VirtualServer自定义资源（为便于阅读，已省略IP地址）：

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

1. 验证Cafe服务是否有3个上游Pod正在以下地址运行：cafe.example.com:

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

1. 访问Deep Service Insight端点：

$ curl -i <NIC_IP_address>:9114/probe/cafe.example.com

1. The 200 OK响应代码表示服务已准备好接收流量（至少有一个Pod处于健康状态）。在此情况下，所有三个Pod均处于Up状态。

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Date: Day, DD Mon YYYY hh:mm:ss TZ
Content-Length: 32
{"Total":3,"Up":3,"Unhealthy":0}

1. The 418 I’m a teapot 状态码表示服务不可用（所有Pod均处于不健康状态）。

HTTP/1.1 418 I'm a teapotContent-Type: application/json; charset=utf-8
Date: Day, DD Mon YYYY hh:mm:ss TZ
Content-Length: 32
{"Total":3,"Up":0,"Unhealthy":3}

1. The 404 Not Found 状态码表示指定主机名上没有正在运行的服务。

HTTP/1.1 404 Not FoundDate: Day, DD Mon YYYY hh:mm:ss TZ
Content-Length: 0

资源

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

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

关于作者

Akash Ananthanarayanan技术营销经理 | F5 NGINX

Akash Ananthanarayanan 的更多博客文章