入口控制器（Ingress Controller）处于Kubernetes集群流量的最前端，所有外部请求几乎都要经过它转发到后端服务。它一旦处理能力不足，后面再多Pod副本也救不回来。很多人上线前只做了功能验证，等流量高峰一来，入口层CPU打满、延迟飙升，才发现整个链路的瓶颈根本不在业务服务，而在Ingress这一层。本文以最常用的Nginx Ingress Controller为例，完整梳理一套压测加调优的方法论。
压测前的环境准备与基准指标确定
压测最忌讳一上来就跑工具看热闹。真正有价值的结果需要先固定变量：压测客户端和被测集群要隔离部署，最好压测机单独一台，避免压测流量和业务流量互相干扰。同时入口控制器本身要有资源限制，例如通过--cpux参数或resources.limits明确CPU上限，否则Nginx会根据节点核数启动大量Worker，压测数据毫无参考意义。
监控体系必须在压测前就位。Ingress Controller内置了Prometheus指标暴露端口，配合Grafana的官方看板可以直接观察每秒请求数、响应延迟分位数、上游连接数和Worker饱和度。重点盯这几个指标：P99延迟、当前活跃连接数、后端响应时间占比。如果P99延迟主要来自ingress_nginx_controller_requests队列等待，说明瓶颈在入口层；如果主要来自upstream_response_time，说明瓶颈在后端服务，这时候调Ingress是白费功夫。
还要确定基准场景。典型做法是准备三类请求：小于1KB的静态小响应、模拟真实业务的带参POST请求、以及大响应体的文件下载。三类场景分开压，因为Nginx对它们的处理路径完全不同，混在一起压出来的数字没法指导调优。
使用wrk和Locust进行分层压测
轻量场景推荐wrk，它基于事件驱动模型，单机就能打出很高的并发，适合测入口控制器的纯转发吞吐能力。一个典型用法如下：
# 4个线程，200个连接，持续60秒 wrk -t4 -c200 -d60s --latency http://ingress.ippipp.com/api/ping # 使用Lua脚本模拟带header的POST请求 wrk -t8 -c500 -d120s -s post.lua http://ingress.ippipp.com/api/order
post.lua脚本可以自定义请求方法、请求头和请求体，让压测流量更贴近真实：
wrk.method = "POST"
wrk.body = '{"sku":"A001","count":2}'
wrk.headers["Content-Type"] = "application/json"
wrk.headers["Authorization"] = "Bearer test-token"如果需要模拟复杂的用户行为，比如登录后顺序调用多个接口，用Locust更合适。它用Python编写场景，支持阶梯加压，可以观察QPS随并发数增长的拐点。压测时建议按阶梯递增：从50并发开始，每轮提升50，持续3分钟，记录每轮的QPS和P99延迟。当QPS不再增长而延迟快速上升时，前一个并发数就是入口层的实际容量上限。这个拐点数据是后续一切调优的参照物。
有个细节容易被忽略：压测客户端本身可能先达到瓶颈。wrk单线程打不满千兆网卡的情况很常见，务必监控压测机的CPU，如果某个核已经跑满，就要加线程数或者增加压测机数量做分布式压测，否则测出来的是客户端性能而不是服务端性能。
核心调优参数详解与效果对比
第一优先级是启用与后端的长连接复用。默认情况下Nginx Ingress对upstream使用HTTP/1.1短连接，每个请求都要新建TCP连接，三次握手加TIME_WAIT会吃掉大量性能。通过ConfigMap开启：
data: keep-alive: "120" upstream-keep-alive-connections: "1000" upstream-keep-alive-timeout: "120"
实测中，仅这一项改动，在纯转发场景下QPS提升可达30%到60%，P99延迟明显下降。原理很简单：连接复用省掉了每次请求的握手成本和端口消耗，CPU直接从内核态的连接处理中解放出来。
第二是Worker进程与CPU的匹配。Nginx Ingress默认worker-processes为auto，会按容器可见的CPU数启动Worker。这里有个大坑：如果Pod的CPU limit是2核，但节点是32核，auto模式可能仍按32核启动Worker，导致Worker之间剧烈争抢CPU配额，上下文切换开销暴涨。正确做法是通过启动参数显式指定：
args: - /nginx-ingress-controller - --worker-processes=2
第三个常被忽视的是keepalive与客户端空闲连接的平衡。客户端长连接保持时间如果设置得过长，高并发下会积累大量空闲连接占用内存；过短则频繁重连。一般线上环境设为60到120秒比较稳妥，具体要结合压测中观察到的活跃连接数曲线来定。
最后是Gzip压缩的取舍。开启压缩会消耗入口层CPU，如果后端响应本身已经压缩，或者流量以内网转发为主，建议直接关闭Gzip，把这个CPU预算留给连接处理。此外，日志输出也是隐形开销，高流量场景下关闭access-log或者改为抽样记录，通常能再挤出5%左右的吞吐。
调优验证与持续回归
每改一项配置都要重跑同样的压测场景，固定线程数和连接数，对比QPS和P99延迟的变化，确认每项优化的实际收益，避免多项改动叠加后出了问题不知道是哪个参数引起的。建议把压测脚本和配置变更都纳入版本管理，形成一份可复现的性能基线。
更成熟的做法是把压测集成到CI流水线，每次Ingress配置变更后自动跑一轮基准压测，数据异常波动时阻断发布。入口层的性能问题往往不是配置错误，而是配置随业务增长逐渐不匹配，只有持续回归才能在流量高峰前发现问题。
Ingress Controller性能压测Kubernetes调优修改时间：2026-09-04 07:26:36