在 Amazon EKS 上部署 NGINX Ingress Controller： 我们如何测试

在 NGINX，我们一直在寻找方法来帮助您充分利用我们的软件。 我们的解决方案简介和规模指南是我们提供的重要资源之一——通过实证测试您在不同计算能力水平下可以预期的性能，我们可以帮助您利用现有的基础设施最大限度地提高应用交付性能，并确定您正在准备的性能和规模的准确运营费用。

我们最近更新了NGINX Ingress Controller 解决方案简介，其中包含针对 Amazon Elastic Kubernetes Service (EKS) 的尺寸指南。 该简介概述了在 Amazon EKS 中的各种实例类型上运行 NGINX Ingress Controller 可以实现的性能，以及估计的每月总拥有成本 (TCO)。 在这篇博客中，我们解释了如何得出这些数字，包括您进行类似测试所需的所有信息。

拓扑

下图显示了用于测试的拓扑。

• 管理员是通过运行以下部分中指定的命令来进行测试的用户。
• Amazon ECR （Elastic Container Registry）托管测试中使用的官方 NGINX Plus Ingress Controller Docker 映像。 请参阅部署 NGINX Plus Ingress Controller 。
• Amazon EC2 （弹性计算云）托管 c5n.9xlarge 图像， wrk在该图像上运行并生成请求。 参见测试方法。
• Amazon EKS （Elastic Kubernetes Service）为 NGINX Plus Ingress Controller 和后端应用托管 c5n.9xlarge 图像。 请参阅创建 Amazon EKS 集群。
• NGINX Plus Ingress Controller将wrk生成的请求代理到后端应用，并返回应用程序的响应。 请参阅部署 NGINX Plus Ingress Controller 。
• 后端application响应 NGINX 代理的请求。请参阅部署后端 Pod 。

创建 Amazon EKS 集群

在部署 EKS 集群之前，请在本地机器上执行以下步骤，该机器由图中的管理员图标表示：

1. 下载eksctl ，Amazon EKS 的官方命令行界面。 如果您的机器上已安装了eksctl ，请务必将其更新到最新版本。
2. 将适当的 AWS 管理员凭证添加到${HOME}/.aws/credentials文件。
3. 从我们的 Gist repo 下载此博客的YAML 文件。
4. 从 GitHub 上的NGINX Ingress Controller仓库下载rbac.yaml （如果使用 NGINX App Protect，则下载 ap-rbac.yaml ）。

要部署 EKS 集群，请在本地机器上运行以下eksctl命令。 （省略了--nodes标志，因为默认情况下该命令会创建测试所需的两个节点：一个用于 NGINX Plus Ingress Controller，一个用于基本后端应用。）

笔记： 您可以在us-west-1以外的任何区域部署 EKS 集群。 该区域不支持在 Amazon Marketplace for Containers 中订阅 NGINX Plus Ingress Controller 映像（参见下一部分）。

# eksctl 创建集群 --instance-types=c5n.9xlarge --managed --ssh-access=true --ssh-public-key=/path/to/public-key

要通过 SSH 连接到集群节点，请运行此命令。 在测试过程中，您需要连接到 NGINX Plus Ingress Controller 节点以运行htop命令并验证来自wrk客户端的负载是否足以使节点上的 CPU 使用率达到 100%。

# ssh -i /path/to/private-key ec2-user@< EKS 节点的公共 IP 地址>

部署 NGINX Plus Ingress 控制器

在 Amazon EKS 上部署 NGINX Plus Ingress Controller 现在比以往更加简单。

1. 为您的 EKS 集群创建 OIDC 身份提供商 (IdP)。

   # eksctl utils associate-iam-oidc-provider --region=< eks-cluster-region > --cluster=< eks-cluster-name > --approve
   

2. 创建iamserviceaccount ，即 EKS 的标准配对IAM 角色和服务账户(IRSA)，并附加AWSMarketplaceMeteringRegisterUsage IAM 策略，以监控 NGINX Plus Ingress Controller 映像的使用情况并授权部署。 此命令自动创建一个服务帐户，并带有链接到iamserviceaccount 的注释。

   # eksctl 创建 iamserviceaccount --name <服务帐户名称> --namespace nginx-ingress --cluster < eks-cluster-name > --region < eks-cluster-region > --attach-policy-arn arn:aws:iam::aws:policy/AWSMarketplaceMeteringRegisterUsage --approve
   

3. 在 RBAC 的 YAML 文件中，编辑主题字段中名称的值以匹配您在上一步中设置的服务帐户名称。 这是rbac.yaml中的第 104 行和ap-rbac.yaml中的第 23 行。 如有必要，还可以编辑命名空间的值（第 105 行或第 24 行），但上述命令使用默认值nginx-ingress 。

4. 应用 YAML 文件（根据需要替换ap-rbac.yaml ）。

   # kubectl 应用 –f rbac.yaml
   

5. 在本地机器上安装Docker 客户端软件。

6. 订阅Amazon 容器市场中的NGINX Plus Ingress Controller (Premium Edition)列表。

7. 使用托管 NGINX Plus Ingress Controller Docker 映像的 Amazon ECR 对你的 Docker 客户端进行身份验证。

8. 在nginx-ingress.yaml中编辑以下值：

   • nodeSelector字段中的kubernetes.io/hostname （第 23 行）– EKS 集群中 NGINX Plus Ingress Controller 节点的标签，通过kubectl get nodes --show-labels命令获取
   • serviceAccountName （第 24 行）— iamserviceaccount IRSA 的名称，在步骤 2中指定为service-account-name 。
   • 容器字段中的图像（第 26 行）– NGINX Plus Ingress Controller Docker 映像在 Amazon ECR 中的位置

9. 应用 YAML 清单：

   # kubectl 应用 –f nginx-ingress.yaml
   

部署后端 Pod

执行以下步骤部署后端应用：

1. 在backend-deployment.yaml中，编辑nodeSelector字段（第 15 行）中kubernetes.io/hostname的值，替换从kubectl get nodes --show-labels命令获取的标签。

2. 应用 YAML 清单：

   # kubectl apply –f 后端部署.yaml
   

3. 将后端应用扩展到三个副本，足以处理wrk生成的负载：

   # kubectl scale 部署 web-server-payload --replicas=3
   

测试方法

在 Amazon EC2 中托管的客户端 c5n.9xlarge AMI 上运行以下wrk命令，根据需要调整值，以使 NGINX Plus Ingress Controller 实例上的 CPU 使用率在每次测试运行中达到 100%：

# wrk -t <线程数> -c <连接数> -d 180s http[s]://< NGINX-Plus-Ingress-Controller 地址>

• –c选项指定要创建的 TCP 连接数。 根据需要设置此选项，可实现 100% CPU 使用率，最多 500 个连接。
• –d选项指定生成流量的时间（每次测试运行的持续时间）。 将此选项设置为 180 秒（3 分钟）。
• –t选项指定要创建的线程数。 根据需要设置此选项以实现 100% 的 CPU 使用率，最多 16 个线程（测试运行期间客户端上使用的每个 CPU 一个线程）。

我们使用了 GitHub 上 2021 年 7 月提供的wrk版本，并建议在重现测试时使用当前版本。

运行测试以收集两个性能指标：

• 每秒请求数 (RPS) – NGINX Plus Ingress Controller 每秒可处理的请求数，在固定时间段内平均。 在这种情况下，在wrk命令中使用http://方案。

  NGINX Plus Ingress Controller 接受1 KB文件（静态内容）的请求，并在后端应用pod 之间进行负载平衡。 该文件的大小大约与小型 CSS 或 JavaScript 文件或非常小的图像相同。

• 每秒 SSL/TLS 交易数 (TPS) – NGINX Plus Ingress Controller 每秒可以建立和服务的新 HTTPS 连接数。 在这种情况下，在wrk命令中使用https://方案。 使用密钥大小为2048 位且具有完美前向保密性的 RSA；SSL 密码是ECDHE-RSA-AES256-GCM-SHA384 。

  客户端发送一系列 HTTPS 请求，每个请求都针对一个新连接。 客户端和 NGINX Plus Ingress Controller 执行 TLS 握手以建立安全连接，然后 NGINX Plus Ingress Controller 解析请求并返回0-KB响应。 请求满足后，关闭连接。

如创建 Amazon EKS 集群中所述，为简单起见，您可以在每次测试运行中在 c5n.9xlarge 实例上运行 NGINX Plus Ingress Controller。 要控制每次测试运行期间可用的 CPU 数量（性能分析表中指定的 1 到 36），请将参数设置为worker_processes指令。

使用的软件

我们使用以下软件进行测试：

• 运行wrk的客户端机器生成了 Ingress Controller 代理的流量。 我们使用了 2021 年 7 月在 GitHub 上提供的wrk版本，并建议在重现测试时使用当前版本。
• NGINX Plus Ingress Controller 版本 1.11.0
• Amazon Linux 2 LTS 在这三台机器上都运行着 OpenSSL 1.0.2k–fips

性能分析

如上所述，我们在每次测试运行中都在 c5n.9xlarge 实例上运行 NGINX Plus Ingress Controller，并使用worker_processes指令来控制使用了多少个 CPU。 在下表中，我们报告了 c5n 系列中支持每种 CPU 数量的实例类型，以及该实例类型的每月 TCO。

该表报告了根据测试方法中描述的测试，在 NGINX Plus Ingress Controller 具有不同数量的 CPU 的情况下实现的 RPS 和 SSL TPS 的数量。

请注意，RPS 不会随着 CPU 数量的增加而线性增长，事实上，随着 CPU 数量的增加，百分比的提高趋于下降。 当核心数超过 16 核时，改进率会进一步下降，因为 c5n.9xlarge 实例启用了超线程，配备 18 个核心，每个核心 2 个线程，总共最多 36 个 CPU。 超线程只能稍微提高 RPS 的数量。

SSL TPS 和 CPU 数量之间的关系也不是线性的，但直到我们扩展到超过 16 个 CPU 时，才会急剧下降。 超线程确实提高了 CPU 受限、可并行操作（例如 TLS 握手）的性能。 因此，即使我们扩展到超过 18 个 CPU，SSL TPS 的性能也会提高。

结论

我们提供了部署详细信息，您可以使用它来确定在 Amazon EKS 中运行的 NGINX Plus Ingress Controller 的预期性能。 您可以使用它来测试其他系列的 EKS 实例，并提供经济实惠的解决方案，以满足您对 Kubernetes 中生产工作负载的性能和扩展要求。

我们对 HTTP RPS 的结果显示，随着 CPU 数量增加一倍，性能提升百分比会下降，收敛到大约 300,000 RPS。 SSL TPS 的结果显示，随着 CPU 数量的增加，性能几乎呈线性增长，即使我们开始超线程（每个核心使用两个线程），因为 TLS 握手受 CPU 限制。

查看解决方案简介，并亲自测试 NGINX Plus Ingress Controller 的性能 - 立即开始！

要使用 NGINX 开源版本尝试 NGINX Ingress Controller，您可以获取源代码，或从DockerHub下载预构建的容器。