CCE Ingress 在 10 万 QPS 下先崩的不是后端，是 keepalive 连接

一个跑在华为云 CCE 上的 API 服务做压测，后端 Pod 的 CPU 和内存都还很从容，但入口 NGINX Ingress Controller 已经开始拒绝连接，云监控里 Ingress 所在节点的 TIME_WAIT 连接数飙升。第一反应是“Ingress 副本不够”，加到 4 个 Pod 之后现象只是推迟了几分钟。真正的瓶颈不在副本数，而在keepalive 连接的管理参数——默认配置在高并发短连接场景下会制造海量的连接重建。

一、keepalive_requests 默认 100，高 QPS 下就是灾难

NGINX 的 keepalive_requests 控制单条 keepalive 连接上最多处理多少个请求，默认值是 100。在内网场景中，单个客户端可能打到上万 QPS，如果一条连接处理 100 个请求就断开重建，每秒会产生大量的连接关闭和新建，TIME_WAIT 堆积，Ingress 的 worker 进程把大量 CPU 消耗在连接管理而不是请求转发上。CCE 的 Ingress 配置字典中，keep-alive-requests 在高并发场景下建议调到 10000。我们把 client 侧的 keep-alive-requests 从 100 拉到 10000，TIME_WAIT 数量下降了接近一个数量级。

二、上游空闲连接池：默认 320 不够用

upstream-keepalive-connections 控制 NGINX 到上游 Pod 的最大空闲 keepalive 连接数，默认 320。高并发下请求分布不均匀，部分上游连接会短暂空闲，如果空闲连接池太小，这些连接会被过早关闭，后续请求到来时又需要重新建连，同样制造 TIME_WAIT。建议高并发场景把 upstream-keepalive-connections 调到 1000 左右。但要注意：这个参数不是越大越好，设得过高会让 NGINX 长期持有到上游的长连接，减少连接调度的次数，可能造成后端 Pod 之间的负载不均。我们最终取 800，兼顾了连接复用和调度均衡。

三、worker 连接上限和超时：两个容易忽略的边界

max-worker-connections 默认值在高并发下可能不够，建议提到 65536，让单个 worker 能管理的连接数匹配实际的并发规模。另一个方向是收紧网关到上游的超时：NGINX 默认到 upstream 的读写超时较长，当某个后端 Pod 出现异常、响应时间飙升时，异常请求会长时间占住 Ingress 的连接槽位，挤占正常请求的容量。把 proxy-read-timeout 和 proxy-send-timeout 从默认值收紧到 30 秒左右，异常 Pod 的连接会被更快释放，整体可用连接容量反而更稳定。

四、资源配置和副本数：别让 Ingress 自己成为瓶颈

按照 CCE 高并发场景的建议，处理 RPS 达到 30 万的 Ingress Controller，CPU 和内存的 request/limit 可以配到 16 核 20GiB，并且 Pod 数至少保持 2 个。我们压测环境的 Ingress Pod 原来只给了 2C4G，调到 8C16G 并保持 3 副本之后，单个 worker 的 CPU 不再打满，连接处理能力线性扩展。另外，如果不需要 Ingress 的指标采集，关掉 metric collection 能省出一部分被 sidecar 类进程占用的 CPU 和内存。

五、总结

CCE Ingress 在高压下的第一瓶颈几乎总是连接生命周期管理，而不是转发性能。三条核心配置：keep-alive-requests 拉到 10000 减少连接重建、upstream-keepalive-connections 调到 800~1000 复用上游连接、max-worker-connections 提到 65536 匹配并发规模。配合合理的 CPU/内存 request 和至少 2 副本，Ingress 才不会在 backend 之前先倒下。