NGINX Ingress Controller 和红帽 OpenShift Router 性能测试对比分析

3 years ago

红帽 OpenShift 容器平台 (OCP) 是最受欢迎的托管 Kubernetes 平台之一。与其竞争对手一样，OCP 包含默认流量管理工具，可帮助用户快速入门。基于 HAProxy 的 OCP Router 是 OCP 集群的默认入口。它可以对 HTTP 和 WebSocket 流量实施负载均衡，支持 TLS 卸载以及 OCP Router 与应用实例间的 TLS 流量，并且能够在 Passthrough 模式下对 TLS 连接进行负载均衡。

客户经常问我们：“既然 OCP Router 是免费使用的，我何必还要在 OpenShift 中使用 NGINX Ingress Controller 呢？”在《为什么需要在 OpenShift 上部署企业级 Ingress Controller》一文中，来自 GigaOm 的客座博客作者 Max Mortillaro 从定性分析的角度分享了使用 NGINX Ingress Controller 的几个原因，包括高级流量管理、易于使用、JWT 验证和 WAF 集成。另外，从定量分析的角度来讲，在 OpenShift 上部署企业级 Ingress Controller 也十分重要。为此，我们在 OCP 环境中对 OCP Router 和基于 NGINX Plus 的 NGINX Ingress Controller (nginxinc/kubernetes-ingress) 进行了性能测试，测试期间我们动态增加和减少了 upstream servers (backend pods) 的数量。

在我们的性能测试中，我们主要从两个方面去评估工具的性能表现：

因素 1：动态部署的延迟表现

我们发现，延迟分布是在动态部署中衡量最终用户体验的最有效指标。系统访问延迟越高，用户访问体验受到的影响就越大。我们还发现，要了解真实的用户访问体验，还需要考虑应用的最大访问延迟的分布情况。有关详细解释，请参见《NGINX 和 HAProxy：基于公有云环境的用户体验》博文中的“性能结果”一节。
因素 2：超时和错误

如果在业务动态部署过程中发现应用访问存在延迟问题，通常是因为系统难以处理配置动态重载，从而出现了超时或错误。

性能测试结果

我们就开门见山进入有趣的部分，并且看看结果吧。下面是关于测试拓扑和方法的详细信息。

如上文所述，我们在评估性能时考虑了两个因素：访问延迟和超时/错误。

因素 1：访问延迟分布

如下图所示，NGINX Ingress Controller 在整个测试中增加的延迟可以忽略不计， 99.999 % 的应用访问延迟不到 700 毫秒。相比之下，OCP Router 在相当低的百分位上就增加了延迟，并且延迟呈指数级增长， 99.99 % 的访问延迟趋于一个稳定值，此时延迟高达 25,000 毫秒（25 秒）之多。这表明，在频繁应用更改、频繁迭代的集群环境下，OCP Router 可能会导致糟糕的用户体验。

因素 2：超时和错误

上面观察到的延迟可能归因于超时和错误：OCP Router 产生了 260 个连接超时和 85 个套接字读取错误，而 NGINX Ingress Controller 没有出现任何超时和错误。我们从其他性能测试中得知（请参见《NGINX Ingress Controller 在动态 Kubernetes 云环境中的性能测试》），OCP Router 的超时和错误是由 HAproxy 处理动态配置重载的操作时引起的。基于 NGINX Plus 的 NGINX Ingress Controller 没有产生超时或错误，是因为当 endpoints 发生改变时，它使用 NGINX Plus API 动态更新 NGINX 配置。

测试配置和方法

测试拓扑

NGINX Ingress Controller 和 OpenShift Router 是被测系统 (SUT)，我们对两者进行了相同的测试。SUT 卸载了来自客户端的 TLS 1.3 连接，并通过单独的连接将客户端请求转发到后端应用中。

测试客户端托管在运行 CentOS 7 的独立的主机中，该主机处于与 OpenShift 集群相同的 LAN 环境。

SUT 和后端应用部署在 VMware vSphere 6.7.0.45100 托管的 OCP 集群中运行。

对于 TLS 加密连接，我们使用了 2048 位 RSA 密钥和 PFS 完美向前保密算法进行加密。

每个来自后端应用的响应都包含大约 1KB 的基础服务元数据以及 200 OK HTTP 状态码。

测试方法

客户端部署

我们使用 wrk2（版本 4.0.0）在客户端机器上运行了以下脚本，在每秒 1000 个请求（RPS，使用 -R 选项设置）的持续吞吐量下测试了 60 秒（使用 -d 选项设置）：

./wrk -t 2 -c 50 -d 60s -R 1000 -L https://ingress-url:443/

使用的 SUT 软件

OpenShift Platform 4.8 版本，默认包含基于 HAProxy 的 OCP Router
NGINX Ingress Controller 1.11.0 (NGINX Plus R22) 版本

后端应用部署

我们对动态部署的后端应用进行了测试，期间使用以下脚本定期增减后端应用的数量。这模拟了一个动态的 OpenShift 环境并衡量了 NGINX Ingress Controller 或 OCP Router 如何有效地适应 endpoint 的变化。

while [ 1 -eq 1 ]
do
  oc scale deployment nginx-backend --replicas=4  
  sleep 10 
  oc scale deployment nginx-backend --replicas=2
  sleep 10
done

结语

大多数采用微服务技术的公司都在通过 CI/CD 流水线以越来越高的频率推进新的开发项目。出于这个原因，数据平面的功能和性能能够随着这些新技术不断升级并且不影响最终用户体验，就显得尤为重要。要想提供最佳的终用户体验，要做到的一点就是在任何情况下，都能始终如一地为所有客户端提供低延迟连接。

基于性能测试结果，NGINX Ingress Controller 在需要快速更新迭代的容器化环境中提供了最佳的终端用户访问体验。下载 NGINX Ingress Controller 免费试用版，了解如何使用 NGINX Ingress Operator 进行部署，轻松入门 NGINX。