NGINX Ingress Controller与Red Hat OpenShift Router性能测试

Amir Rawdat解决方案工程师

Red Hat OpenShift Container Platform (OCP)是一款广受欢迎的托管式Kubernetes平台。与同类平台一样，OCP提供默认流量管理工具，帮助用户快速上手。OCP Router基于HAProxy，是OCP集群的默认入口点。它可以对HTTP和WebSocket流量进行负载均衡，支持TLS终止以及Router与应用实例之间的TLS连接，还可以在直通模式下对TLS连接进行负载均衡。

客户经常问我们：“既然可以免费使用Router，为什么还要在OpenShift中使用NGINX Ingress Controller？”在《为什么需要在OpenShift上使用企业级Ingress Controller》一文中，来自GigaOm的客座博主Max Mortillaro分享了使用NGINX Ingress Controller的一些定性理由：高级流量管理、易用性、JWT验证和WAF集成。但从定量角度回答这个问题也很重要。因此，我们在OCP环境中对Router和基于NGINX Plus的NGINX Ingress Controller（nginxinc/kubernetes-ingress）进行了性能测试。测试采用动态部署，并在测试期间动态增加和减少上游（后端）服务器的数量。

开展性能测试时，我们会考察两个因素，以评估这些工具的性能：

• 因素1：动态部署的延迟结果我们发现，在动态部署中，衡量最终用户体验最有效的指标是延迟百分位分布。系统增加的延迟越多，对用户体验的影响就越大。我们还发现，要准确了解用户体验，需要将分布中较高百分位的延迟纳入考量。有关详细说明，请参阅我们博客文章性能结果部分：《NGINX与HAProxy：测试云端用户体验》。
• 因素2：超时和错误在动态部署中，如果被测系统导致延迟，通常是因为系统难以处理动态重新加载，因而出现超时或错误。

性能测试结果

直接来看最值得关注的部分：测试结果。有关测试拓扑和方法的详细信息见下文。

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

因素1：延迟百分位分布

如下图所示，在整个测试过程中，NGINX Ingress Controller增加的延迟可以忽略不计，在第99.999百分位时，最大延迟不到700 ms。相比之下，OCP Router在较低百分位时就增加了延迟，随后延迟呈指数级增长，直至在第99.99百分位时稳定在略高于25,000 ms（25秒）的水平。这表明，在负载条件下频繁应用集群环境变更时，Router可能会导致较差的用户体验。

因素2：超时和错误

上述延迟可归因于超时和错误：OCP Router出现了260次连接超时和85次读取套接字错误，而NGINX Ingress Controller未出现此类问题。正如我们在其他性能测试中所见（请参阅动态Kubernetes云环境中的NGINX Ingress Controller性能测试），Router出现超时和错误的原因在于HAproxy处理动态重新加载的方式。基于NGINX Plus的NGINX Ingress Controller不会导致超时或错误，因为它会在端点发生变化时使用NGINX Plus API动态更新NGINX配置。

测试设置与方法

测试拓扑

我们分别以NGINX Ingress Controller和OpenShift Router作为被测系统（SUT），运行了相同的测试。SUT终止来自客户端的TLS 1.3连接，并通过单独的连接将客户端请求转发到后端部署。

客户端托管在另一台运行CentOS 7的计算机上，该计算机与OpenShift集群位于同一局域网中。

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

对于TLS加密，我们采用了2048位密钥的RSA算法和完全前向保密。

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

测试方法

客户端部署

我们在客户端计算机上使用wrk2（版本 4.0.0）运行以下脚本，以每秒 1,000 个请求的恒定吞吐量执行 60 秒测试（分别通过-d选项和-R选项进行设置）：

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

使用的SUT软件

• OpenShift Platform 4.8版，默认包含基于HAProxy的Router
• NGINX Ingress Controller 版本 1.11.0（NGINX Plus R22）

后端部署

我们对后端应用进行了动态部署测试，并使用以下脚本定期扩缩后端副本数量。此测试模拟动态OpenShift环境，并衡量NGINX Ingress Controller或OCP Router适应端点变化的效果。

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进行部署。

关于作者

Amir Rawdat解决方案工程师

Amir Rawdat 的更多博客文章