共计 4793 个字符，预计需要花费 12 分钟才能阅读完成。
原文作者：Amir Rawdat of F5
原文链接：NGINX Ingress Controller 在动静 Kubernetes 云环境中的性能测试
转载起源：NGINX 官方网站
NGINX 惟一中文官网社区，尽在 nginx.org.cn
随着越来越多的企业在生产环境中运行容器化利用，Kubernetes 将继续坚固其作为规范容器编排工具的位置。与此同时，在疫情中崛起的居家办公模式放慢了互联网流量的增长，导致云计算需要提前几年暴发。目前很多公司都在紧锣密鼓地降级基础架构，帮忙客户解决正在面临的重大网络中断和过载问题。
为了在基于云的微服务环境中达到所需的性能程度，您须要应用疾速、齐全动静的软件来开释下一代超大规模数据中心的可扩展性和性能后劲。许多应用 Kubernetes 治理容器的企业和机构都依赖基于 NGINX 的 Ingress Controller 来实现利用交付。
在这篇博客中，咱们针对在互联网中客户端连贯的提早状况，提供了三种 NGINX Ingress Controller 在实在多云环境中的性能测试后果。这三种控制器别离为：
- 基于 NGINX 开源版的 NGINX Ingress Controller，由 Kubernetes 社区保护。咱们在之前的博客中称之为_“社区版 Ingress Controller”_，本篇文章也将沿用这个说法。咱们从 Google Container Registry 中提取了其 0.34.1 版本的镜像，用于此次测试。
- NGINX 开源版 Ingress Controller1.8.0，由 NGINX 保护。
- NGINX Plus Ingress Controller1.8.0，由 NGINX 保护。
测试方法和收集的指标
咱们使用性能测试程序 wrk2 模仿了一个客户端，在规定的时间段内收回间断的 HTTPS 申请。被测试的 Ingress Controller（社区版 Ingress Controller、NGINX 开源版 Ingress Controller 和 NGINX Plus Ingress Controller）将申请转发到部署在 Kubernetes Pods 中的后端利用，并将利用生成的响应返回给客户端。咱们生成了稳固的客户端流量，并应用这些流量对 Ingress Controller 进行压力测试，收集了以下性能指标：
- 提早 — 客户端从生成申请到接管响应所用的工夫。咱们用百分位散布的模式来报告提早。例如，如果有 100 个提早测试样本，则第 99 个百分位数的值是 100 次测试中仅次于最慢值的响应提早。
- 连贯超时 — 因为 Ingress Controller 在特定工夫内无奈响应申请而被静默断开或抛弃的 TCP 连贯。
- 读取谬误 — 尝试读取连贯失败，因为来自 Ingress Controller 的套接字已敞开。
- 连贯谬误 — 客户端和 Ingress Controller 之间未建设 TCP 连贯。
拓扑构造
对于所有测试，咱们都在 AWS 客户端机器上运行 wrk2 程序，生成申请。AWS 客户端会连贯到 Ingress Controller 的内部 IP 地址，其中 Ingress Controller 作为 KubernetesDaemonSet 部署在 Google Kubernetes Engine (GKE) 环境中的 GKE-node-1 上。
Ingress Controller 配置成 SSL 终结（援用 KubernetesSecret）和 7 层路由模式，并通过 LoadBalancer 类型的 Kubernetes 服务裸露。后端利用则作为 KubernetesDeployment 在 GKE-node-2 上运行。
无关云主机类型和软件配置的全副信息，请参阅附录。
测试方法
客户端部署
咱们在 AWS 客户端机器上运行以下 wrk2（版本 4.0.0）脚本。它生成了 2 个wrk 线程，这些线程共与 GKE 中部署的 Ingress Controller 建设了 1000 个连贯。在每轮继续 3 分钟的测试期间内，脚本每秒生成 30,000 个申请 (RPS)，咱们认为这很好地模仿了 Ingress Controller 在生产环境中的负载。
wrk -t2 -c1000 -d180s -L -R30000 https://app.example.com:443/其中：
-t—— 设置线程数（2）-c—— 设置 TCP 连接数（1000）-d—— 设置每轮测试的持续时间，单位为秒（180 秒，即 3 分钟）-L—— 生成具体的提早百分位信息，以便导出到剖析工具-R—— 设置 RPS 的数量（30,000）
对于 TLS 加密，咱们应用了 2048 位 RSA 密钥加密和 PFS 完满正向加密。
每个来自后端利用的响应（拜访地址：https://app.example.com:443）都蕴含大概 1 KB 的根底服务器元数据以及200`OK`HTTP 状态码。
后端利用部署
咱们对后端应用程序进行了动态和动静部署的测试运行。
动态部署中有五个 Pod 正本，并且没有应用 Kubernetes API 做任何更改。
对于动静部署，咱们应用以下脚本定期将后端 nginx 部署从五个 Pod 正本扩大到七个，而后再缩减到五个。这模仿了一个动静 Kubernetes 环境，可能测试 Ingress Controller 如何无效适应端点变更。
相干代码配置请点击文章《NGINX Ingress Controller 在动静 Kubernetes 云环境中的性能测试》进行查看。
性能后果
动态部署的提早后果
如图所示，在动态部署后端利用时，三个 Ingress Controller 具备类似的性能。思考到它们都基于 NGINX 开源版构建，并且动态部署不须要从 Ingress Controller 重新配置，这一后果也很正当。
动静部署的提早后果
该图显示了在定期将后端利用从五个 Pod 正本扩大到七个、又缩小到五个的动静部署下（详见“后端利用部署”局部），每种 Ingress Controller 产生的提早。
很显著，只有 NGINX Plus Ingress Controller 在这种环境中体现良好，始终到第 99.99% 个都简直没有任何提早。社区版和 NGINX 开源版 Ingress Controller 尽管具备截然不同的提早模式，但都在很低的百分位上产生了显著的提早。对于社区版 Ingress Controller，提早呈迟缓但稳固的回升状态，在第 99 % 个达到大概 5000 毫秒（5 秒）并在之后趋于稳定。对于 NGINX 开源版 Ingress Controller，提早呈急剧攀升状态，在第 99 % 个达到大概 32 秒，到第 99.99% 个又变成了 60 秒。
社区版和 NGINX 开源版 Ingress Controller 所经验的提早是由 NGINX 配置更新和从新加载（以响应后端利用一直变动的端点）后呈现的谬误和超时引起的，具体内容咱们将在“动静部署中的超时和谬误后果”局部进行进一步探讨。
这是一个更细粒度的视图，展现了社区版和 NGINX Plus Ingress Controller 在与上图雷同的测试条件下得出的后果。NGINX Plus Ingress Controller 第 99.9999% 个的提早为 254 毫秒，在此之前简直没有任何提早。社区版 Ingress Controller 的提早在第 99% 个稳定增长到 5000 毫秒，尔后趋于平稳。
动静部署中的超时和谬误后果
此表更具体地显示了引起提早的起因。
| NGINX Open Source | Community | NGINX Plus | |
|---|---|---|---|
| Connection errors | 33365 | 0 | 0 |
| Connection timeouts | 309 | 8809 | 0 |
| Read errors | 4650 | 0 | 0 |
应用 NGINX 开源版 Ingress Controller 时，每次更改后端利用端点后都须要更新和从新加载 NGINX 配置，这会导致许多连贯谬误、连贯超时和读取谬误的问题。当客户端尝试连贯不再调配给 NGINX 过程的套接字时，零碎会在 NGINX 从新加载的短时间内产生连贯 / 套接字谬误。当客户端与 Ingress Controller 建设连贯，但后端端点不再可用时，会产生连贯超时。连贯谬误和连贯超时会重大影响提早，导致提早在第 99% 个激增到 32 秒，而后在第 99.99% 个变成 60 秒。
应用社区版 Ingress Controller 时，端点随着后端利用的调整而更改，引发了 8809 个连贯超时。社区版 Ingress Controller 应用 Lua 代码来防止在端点变更时从新加载配置。结果显示，在 NGINX 外部运行的检测端点变更的 Lua 处理程序解决了 NGINX 开源版 Ingress Controller 的一些性能限度问题——这些限度是由每次更改端点后都从新加载配置引起的。尽管如此，连贯超时依然会产生，导致更高百分位的显著提早。
而应用 NGINX Plus Ingress Controller 时没有谬误或超时——动静环境对性能简直没有影响。这是因为 NGINX Plus Ingress Controller 应用了 NGINX Plus API，能够在端点变更后动静更新 NGINX 配置。如上文所述，它的最高提早为 254 毫秒，并且仅产生在第 99.9999% 个。
结语
性能结果表明，要想齐全打消动静 Kubernetes 云环境中的超时和谬误，Ingress Controller 就必须动静适应后端端点的变更，且无需应用事件处理程序或从新加载配置。依据这些后果，NGINX Plus API 能够说是在动静环境中动静重新配置 NGINX 的最佳解决方案。在咱们的测试中，只有 NGINX Plus Ingress Controller 在高度动静的 Kubernetes 环境中实现了合乎用户需要的完满性能。
附录
云机器规格
| Machine | Cloud Provider | Machine Type |
|---|---|---|
| Client | AWS | m5a.4xlarge |
| GKE-node-1 | GCP | e2-standard-32 |
| GKE-node-2 | GCP | e2-standard-32 |
NGINX 开源版和 NGINX Plus Ingress Controller 的配置
Kubernetes 配置
相干代码配置请点击文章《NGINX Ingress Controller 在动静 Kubernetes 云环境中的性能测试》进行查看。
注：
- 该配置实用于 NGINX Plus。NGINX 开源版配置对
nginx‑plus的援用依据须要进行了调整。 - NGINX App Protect 蕴含在镜像中（
gcr.io/nginx-demos/nap-ingress:edge），然而曾经禁用（省略了-enable-app-protect标记）。
ConfigMap
相干代码配置请点击文章《NGINX Ingress Controller 在动静 Kubernetes 云环境中的性能测试》进行查看。
社区版 NGINX Ingress Controller 的配置
Kubernetes 配置
相干代码配置请点击文章《NGINX Ingress Controller 在动静 Kubernetes 云环境中的性能测试》进行查看。
ConfigMap
相干代码配置请点击文章《NGINX Ingress Controller 在动静 Kubernetes 云环境中的性能测试》进行查看。
后端利用配置
Kubernetes 配置
相干代码配置请点击文章《NGINX Ingress Controller 在动静 Kubernetes 云环境中的性能测试》进行查看。
ConfigMaps
相干代码配置请点击文章《NGINX Ingress Controller 在动静 Kubernetes 云环境中的性能测试》进行查看。
服务
相干代码配置请点击文章《NGINX Ingress Controller 在动静 Kubernetes 云环境中的性能测试》进行查看。
NGINX 惟一中文官网社区，尽在 nginx.org.cn
更多 NGINX 相干的技术干货、互动问答、系列课程、流动资源：
开源社区官网：https://www.nginx.org.cn/
微信公众号：https://mp.weixin.qq.com/s/XVE5