版本：3.10.x

在 AWS EKS 上运行基准

本指南将引导你在自己的 AWS 账户上重现性能基准中发布的 AWS EKS 测试结果。该设置使用三个独立的 EKS 节点组，每个节点组用于 API7 网关、NGINX 上游和 wrk2 负载生成器，因此这三个组件都不会与其他组件争用 CPU 或网络资源。

有关通用的基准测试方法和优化指导，请先参见性能基准。在 Kubernetes 上部署介绍了在 Kubernetes 上安装 API7 网关的标准生产流程；本页仅记录基准测试场景特有的调整。

前置条件

有权创建 EKS 集群和 EC2 实例的 AWS 账户。
kubectl 和 helm 本地安装，版本与目标 EKS 集群兼容。
EKS 集群服务角色和 EKS 节点 IAM 角色。请参阅Amazon EKS 集群 IAM 角色和 Amazon EKS 节点 IAM 角色。
有效的 API7 企业版许可证。如果尚未获得许可证，请申请试用。

步骤 1：创建 EKS 集群

在 AWS 控制台中创建一个新的 EKS 集群：

在 EKS 控制台中选择 Add cluster（添加集群）。
附加你在前置条件中创建的 EKS 集群服务角色。
配置 VPC 和子网，以便三个节点组能够在集群网络上相互访问。
根据需要配置可观测性（CloudWatch 日志记录）。
启用你通常运行的集群插件（例如，VPC、CNI 和 CoreDNS）。
创建集群并等待其达到 ACTIVE 状态。

步骤 2：创建三个隔离节点组

该基准测试需要三个运行 c5.4xlarge 实例的独立 EC2 节点组。API7 网关、上游和 wrk2 分别独占 16 个 vCPU 和 32 GB RAM，从而避免组件之间争用资源。

对于每个节点组：

在 EKS 控制台中打开 Compute > Add node group（计算 > 添加节点组）。
为节点组命名（例如，api7ee、upstream 或 wrk2）。
附加 EKS 节点 IAM 角色。
选择 Amazon Linux 2 (AL2_x86_64) 作为 AMI 类型。
选择 c5.4xlarge 作为实例类型。
将所需大小设置为至少 1 个节点。
如果要在节点上运行诊断命令，请启用 SSH 访问。
保存并等待节点组达到 ACTIVE 状态。

重复此操作，直到获得三个节点组：api7ee、upstream 和 wrk2。

警告

请勿使用突发型实例系列（例如 t3 或 t4g）进行基准测试。此类实例基于 CPU 积分的模型会导致结果不可复现。有关详情，请参见性能基准。

步骤 3：连接 `kubectl` 并标记节点

配置 kubectl 与新集群通信：

aws eks update-kubeconfig --region <region-code> --name <your-cluster-name>

验证连接：

kubectl get svc

预期输出（自动创建 kubernetes 服务）：

NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.100.0.1   <none>        443/TCP   39m

在每个节点组中标记一个节点，确保 Kubernetes 将 Pod 调度到指定节点：

kubectl get nodes

kubectl label nodes <api7ee-node-name>  nodeName=api7ee
kubectl label nodes <upstream-node-name> nodeName=upstream
kubectl label nodes <wrk2-node-name>    nodeName=wrk2

步骤 4：在 api7ee 节点上安装 API7 企业版

创建命名空间并安装 API7 企业版控制面 Helm Chart，将每个 CP 组件（控制台、PostgreSQL、Prometheus）固定到 api7ee 节点。

kubectl create namespace api7

helm repo add api7 https://charts.api7.ai
helm repo update

helm install api7ee3 api7/api7ee3 \
  --set nodeSelector."nodeName"=api7ee \
  --set postgresql.primary.nodeSelector."nodeName"=api7ee \
  --set prometheus.server.nodeSelector."nodeName"=api7ee \
  -n api7

备注

捆绑的 PostgreSQL 和 Prometheus 默认启用持久存储。如果你的集群没有默认的 StorageClass 并且你希望保持基准环境无状态，请将 --set postgresql.primary.persistence.enabled=false 和 --set prometheus.server.persistence.enabled=false 添加到上面的命令中。

等待控制面 Pod 就绪：

kubectl -n api7 get pods -l app.kubernetes.io/name=api7ee3 -w

端口转发控制台并上传你的许可证：

kubectl -n api7 port-forward svc/api7ee3-dashboard 7443:7443

打开 https://localhost:7443，使用默认凭证（admin/admin）登录，然后在 **Organization > Settings > License（组织 > 设置 > 许可证）**中上传许可证。

在控制台中，转到 Gateway Settings（网关设置），并将控制面地址设置为 https://api7ee3-dp-manager:7943，以便接下来安装的数据面连接到该地址。

禁用全局 Prometheus 插件

该基准测试用于测量原始请求处理性能，因此测试期间应禁用全局 prometheus 插件，否则每个请求都会产生记录 Prometheus 指标的开销。开始测试前，请在控制台中禁用全局 prometheus 插件。

步骤 5：在 api7ee 节点上安装 API7 网关

在控制台中，单击 Add Gateway Instance（添加网关实例） 并选择 Kubernetes，以生成安装脚本。控制台会生成三个证书（tls.crt、tls.key、ca.crt）以及需要运行的 Helm 命令。

保存证书并创建 Kubernetes 密钥：

kubectl create secret generic -n api7 api7-ee-3-gateway-tls \
  --from-file=tls.crt=/tmp/tls.crt \
  --from-file=tls.key=/tmp/tls.key \
  --from-file=ca.crt=/tmp/ca.crt

使用特定于基准的覆盖安装网关图表：

helm upgrade --install -n api7 --create-namespace api7-ee-3-gateway api7/gateway \
  --set "etcd.auth.tls.enabled=true" \
  --set "etcd.auth.tls.existingSecret=api7-ee-3-gateway-tls" \
  --set "etcd.auth.tls.certFilename=tls.crt" \
  --set "etcd.auth.tls.certKeyFilename=tls.key" \
  --set "etcd.auth.tls.verify=true" \
  --set "gateway.tls.existingCASecret=api7-ee-3-gateway-tls" \
  --set "gateway.tls.certCAFilename=ca.crt" \
  --set "apisix.extraEnvVars[0].name=API7_GATEWAY_GROUP_SHORT_ID" \
  --set "apisix.extraEnvVars[0].value=default" \
  --set "etcd.host[0]=https://api7ee3-dp-manager:7943" \
  --set "apisix.replicaCount=1" \
  --set "apisix.image.repository=api7/api7-ee-3-gateway" \
  --set "apisix.image.tag=${GATEWAY_VERSION}" \
  --set "nginx.workerProcesses=1" \
  --set "apisix.nodeSelector.nodeName=api7ee" \
  --set "apisix.securityContext.runAsNonRoot=false" \
  --set "apisix.securityContext.runAsUser=0"

❶ 测量单实例吞吐量。获得单实例的基准数据后，再增加实例数量。

❷ 将数据面镜像固定为与控制面匹配的版本。可在 Docker Hub 或支持的版本和互操作性中查找确切的标签。

❸ 从单个 worker 进程开始建立基线，之后再增加进程数以测量多核扩展能力。

❹ 将网关 Pod 固定到隔离的基准节点。

❺ 以 root 身份运行，以便在 Pod 内安装 perf、strace 和 tcpdump 等诊断工具。请勿在生产环境中使用这些设置。

步骤 6：在 upstream 节点上部署 NGINX 上游

上游是一个最小的 NGINX 服务器，它返回 200 字节的静态响应。禁用访问日志记录，以便上游磁盘 I/O 不会成为瓶颈。

创建 nginx-upstream.yaml：

nginx-upstream.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: api7
  name: nginx-config
data:
  nginx.conf: |
    master_process on;
    worker_processes 1;
    events {
      worker_connections 4096;
    }
    http {
      access_log off;
      server_tokens off;
      keepalive_requests 10000000;
      server {
        listen 1980;
        server_name _;
        location / {
          return 200 "hello world\n";
        }
      }
    }
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: api7
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      nodeSelector:
        nodeName: upstream
      containers:
        - name: nginx
          image: nginx:1.25.4
          volumeMounts:
            - name: nginx-config
              mountPath: /etc/nginx/nginx.conf
              subPath: nginx.conf
      volumes:
        - name: nginx-config
          configMap:
            name: nginx-config
---
apiVersion: v1
kind: Service
metadata:
  namespace: api7
  name: nginx-upstream
spec:
  selector:
    app: nginx
  ports:
    - port: 1980
      targetPort: 1980

应用它：

kubectl apply -f nginx-upstream.yaml

步骤 7：在 wrk2 节点上部署 `wrk2`

wrk2 是负载生成器。将其固定到 wrk2 节点，以便它不会与网关或上游共享 CPU。

创建 wrk2.yaml：

wrk2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: api7
  name: wrk2-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wrk2
  template:
    metadata:
      labels:
        app: wrk2
    spec:
      nodeSelector:
        nodeName: wrk2
      containers:
        - name: wrk2
          image: bootjp/wrk2
          command: ["sleep", "infinity"]

应用它：

kubectl apply -f wrk2.yaml

准备运行负载生成器后，使用 exec 进入对应的 Pod：

kubectl -n api7 exec -it deploy/wrk2-deployment -- sh

步骤 8：应用测试场景配置

公共 api7-gateway-performance-benchmark 仓库包含基准表中每个场景可直接使用的 ADC 配置。克隆仓库并使用 ADC 参考中介绍的 ADC CLI 按顺序应用每个场景：

场景	ADC 配置
1 个路由，无插件	`1-one-route-without-plugin.yaml`
1 个路由，启用 `limit-count`	`2-one-route-with-limit-count.yaml`
1 个路由，启用 `key-auth` 和 `limit-count`	`3-one-route-with-key-auth-and-limit-count.yaml`
1 个路由、1 个消费者，启用 `key-auth`	`4-one-route-with-key-auth.yaml`
100 个路由，无插件	`5-100-route-without-plugin.yaml`
100 个路由，启用 `limit-count`	`6-100-route-with-limit-count.yaml`
100 个路由、100 个消费者，启用 `key-auth` 和 `limit-count`	`7-100-route-and-consumer-with-key-auth-limit-count.yaml`
100 个路由、100 个消费者，启用 `key-auth`	`8-100-route-and-consumer-with-key-auth.yaml`

使用 adc sync 应用场景配置：

adc sync \
  --server https://<dashboard-host>:7443 \
  --token <your-api7-api-key> \
  --gateway-group default \
  -f 1-one-route-without-plugin.yaml

步骤 9：运行负载测试

从 wrk2 Pod 内部，针对 API7 网关服务运行负载生成器。以内部服务 DNS 名称为目标，以便流量保留在集群网络上：

wrk -t4 -c100 -d120s -R300000 \
  --latency \
  http://api7-ee-3-gateway.api7.svc.cluster.local:9080/get

❶ 使用 4 个线程和 100 个并发连接运行 2 分钟，并将目标速率设为每秒 300,000 个请求，与已发布测试采用的参数保持一致。

❷ 在输出中显示延迟百分位数据。

每个测试用例运行 5 次并取结果的平均值。记录每个场景的 QPS、P95 和 P99，然后与性能基准中发布的数字进行比较。

如果你的结果与已发布的数据存在显著偏差（超过约 10%），请查看性能基准中的优化建议并确认：

API7 网关和 NGINX 上游上的访问日志均被禁用。
ulimit -n 在所有三个节点上至少为 1024000。
全局 prometheus 插件已禁用。
三个基准节点上没有调度其他 Pod。
API7 网关错误日志中没有上游 DNS 错误或连接失败。

清理

完成后删除测试命名空间：

kubectl delete namespace api7

然后在 AWS 控制台中删除三个节点组和 EKS 集群，避免继续产生 EC2 费用。

后续步骤

性能基准：了解测试方法、已发布结果和优化建议。
扩缩容数据面：将基准测试结果应用到生产环境的扩缩容规划中。
在 Kubernetes 上部署：了解标准生产安装流程。

前置条件​

步骤 1：创建 EKS 集群​

步骤 2：创建三个隔离节点组​

步骤 3：连接 kubectl 并标记节点​

步骤 4：在 api7ee 节点上安装 API7 企业版​

禁用全局 Prometheus 插件​

步骤 5：在 api7ee 节点上安装 API7 网关​

步骤 6：在 upstream 节点上部署 NGINX 上游​

步骤 7：在 wrk2 节点上部署 wrk2​

步骤 8：应用测试场景配置​

步骤 9：运行负载测试​

清理​

后续步骤​