一、概述

1.1 背景介紹

Ingress Nginx 是 Kubernetes 集群中最主流的流量入口組件，承擔著集群內所有 HTTP/HTTPS 流量的路由和轉發(fā)。默認配置能應付開發(fā)測試環(huán)境，但一到生產環(huán)境扛高并發(fā)，各種瓶頸就暴露出來了——worker 進程數(shù)不夠、連接池耗盡、SSL 握手吃滿 CPU、upstream 超時雪崩。

很多團隊遇到性能問題的第一反應是加副本數(shù)、加節(jié)點，但 Ingress Nginx 的性能瓶頸往往不在資源量上，而在配置參數(shù)上。一個 4C8G 的 Pod，默認配置可能只能跑到 2 萬 QPS，但經過系統(tǒng)性調優(yōu)，同樣的資源可以穩(wěn)定輸出 10 萬+ QPS。差距就在幾十個參數(shù)的合理配置上。

這篇文章從 Ingress Nginx 的架構原理出發(fā)，逐層拆解影響性能的關鍵參數(shù)，覆蓋 worker 模型、連接復用、緩沖區(qū)、SSL 優(yōu)化、負載均衡、限流防護、內核調優(yōu)等全鏈路，最終給出一套經過壓測驗證的高性能配置方案。

1.2 技術特點

全鏈路調優(yōu)：從內核參數(shù)到 Nginx 配置到 K8s 資源編排，覆蓋每一層性能瓶頸

參數(shù)有據(jù)可依：每個參數(shù)的取值都有計算公式或壓測數(shù)據(jù)支撐，不是拍腦袋

生產可落地：所有配置都基于 Ingress Nginx Controller 1.12+ 驗證，可直接用于生產

面向未來：包含 Gateway API 遷移路徑，為下一代流量管理做準備

1.3 適用場景

場景一：高并發(fā) Web 服務入口，需要單 Pod 承載 5 萬+ QPS

場景二：SSL 密集型場景，HTTPS 流量占比超過 90% 需要優(yōu)化握手性能

場景三：多租戶集群的流量網關，需要精細化的限流和防護策略

場景四：從 Ingress API 向 Gateway API 遷移，需要平滑過渡方案

1.4 環(huán)境要求

組件	版本要求	說明
Kubernetes	1.32+	2026 年主流生產版本
Ingress Nginx Controller	1.12+	基于 Nginx 1.27.x
操作系統(tǒng)	Ubuntu 24.04 LTS	內核 6.8+，支持 io_uring
節(jié)點配置	4C8G 起步	推薦 8C16G 用于高并發(fā)場景
cert-manager	1.17+	證書自動管理和輪轉
Prometheus + Grafana	最新穩(wěn)定版	監(jiān)控指標采集和可視化

二、架構原理與性能調優(yōu)

2.1 Ingress Nginx 架構解析

2.1.1 請求處理鏈路

理解性能調優(yōu)的前提是搞清楚一個請求在 Ingress Nginx 里經過了哪些環(huán)節(jié)。完整鏈路如下：

客戶端 -> NodePort/LoadBalancer -> Nginx Worker 進程
 -> SSL/TLS 終止 -> 請求解析 -> 路由匹配
 -> 限流檢查 -> 負載均衡選擇 upstream
 -> 代理轉發(fā)到后端 Pod -> 響應回傳客戶端

每個環(huán)節(jié)都有對應的性能參數(shù)可以調。瓶頸通常出現(xiàn)在這幾個地方：

連接建立階段：TCP 握手、SSL 握手消耗 CPU 和時間

請求處理階段：worker 進程數(shù)不夠、連接數(shù)打滿、緩沖區(qū)不足

代理轉發(fā)階段：upstream 連接復用率低、超時參數(shù)不合理

響應回傳階段：緩沖區(qū)配置不當導致磁盤 I/O

2.1.2 Nginx Worker 模型

Ingress Nginx 底層就是 Nginx，采用經典的 Master-Worker 多進程模型：

Master 進程：負責讀取配置、管理 Worker 進程、處理信號

Worker 進程：實際處理請求，每個 Worker 是一個獨立進程，內部使用 epoll 事件驅動模型

關鍵點在于：每個 Worker 進程是單線程的，通過 epoll 實現(xiàn)非阻塞 I/O 多路復用。一個 Worker 可以同時處理數(shù)千個并發(fā)連接，但 CPU 密集型操作（比如 SSL 握手、gzip 壓縮）會阻塞整個 Worker。

# 查看當前 Ingress Nginx 的 worker 配置
kubectlexec-n ingress-nginx deploy/ingress-nginx-controller -- 
 cat /etc/nginx/nginx.conf | grep -E"worker_processes|worker_connections"

2.1.3 ConfigMap 與 Annotation 的關系

Ingress Nginx 的配置分兩層：

ConfigMap（全局配置）：影響所有 Ingress 規(guī)則，對應 nginx.conf 的全局和 http 塊

Annotation（單個 Ingress 配置）：只影響特定 Ingress 規(guī)則，對應 server/location 塊

性能調優(yōu)主要在 ConfigMap 層面操作，個別場景需要 Annotation 配合。

2.2 Worker 進程與連接數(shù)優(yōu)化

2.2.1 worker_processes 配置

默認情況下 Ingress Nginx 的worker-processes設置為auto，即等于 CPU 核心數(shù)。在容器環(huán)境下，這個值取決于 Pod 的 CPU limit。

# ConfigMap 配置
apiVersion:v1
kind:ConfigMap
metadata:
name:ingress-nginx-controller
namespace:ingress-nginx
data:
worker-processes:"auto"

調優(yōu)建議：

auto在大多數(shù)場景下是最優(yōu)選擇，不需要手動指定

如果 Pod 的 CPU limit 設置為 4，worker_processes 就是 4

不要設置超過 CPU 核心數(shù)的 worker 數(shù)量，多了反而因為上下文切換降低性能

對于 SSL 密集型場景，確保 CPU limit 給夠，因為 SSL 握手是 CPU 密集型操作

關鍵陷阱：如果 Pod 沒有設置 CPU limit（只設了 request），auto會讀取宿主機的 CPU 核心數(shù)。一臺 64 核的機器上跑出 64 個 worker 進程，每個 worker 只分到零點幾核 CPU，性能反而更差。所以必須設置 CPU limit。

2.2.2 worker_connections 配置

worker-connections決定每個 Worker 進程能同時處理的最大連接數(shù)。默認值是 16384。

data:
worker-connections:"65536"

計算公式：

最大并發(fā)連接數(shù) = worker_processes * worker_connections

但實際上每個客戶端請求在反向代理模式下會占用 2 個連接（客戶端到 Nginx + Nginx 到 upstream），所以實際能處理的并發(fā)請求數(shù)是：

最大并發(fā)請求數(shù) = (worker_processes * worker_connections) / 2

4 個 Worker、每個 65536 連接，理論上能處理 131072 個并發(fā)請求。

調優(yōu)建議：

生產環(huán)境建議設置為 65536

同時需要調整系統(tǒng)的文件描述符限制，因為每個連接占一個 FD

通過worker-rlimit-nofile參數(shù)設置 Worker 進程的 FD 上限

data:
worker-connections:"65536"
max-worker-open-files:"131072"

2.2.3 worker_shutdown_timeout 配置

Nginx reload 時舊 Worker 進程需要優(yōu)雅退出，worker-shutdown-timeout控制等待時間。默認 240s。

data:
worker-shutdown-timeout:"30s"

Ingress Nginx 在每次 Ingress 資源變更時都會觸發(fā) Nginx reload。如果舊 Worker 上還有長連接沒斷開，就會一直等到超時才強制關閉。設置過長會導致內存中同時存在大量舊 Worker 進程，設置過短會導致長連接被強制中斷。

30s 對大多數(shù) HTTP 服務來說足夠了。如果有 WebSocket 長連接場景，需要適當調大。

2.3 連接復用與 Keep-Alive 調優(yōu)

2.3.1 客戶端側 Keep-Alive

Keep-Alive 讓客戶端和 Nginx 之間復用 TCP 連接，避免每個請求都走三次握手。對性能的影響非常大，尤其是 HTTPS 場景下還能省掉 SSL 握手的開銷。

data:
# 單個 Keep-Alive 連接上最多處理的請求數(shù)，默認 1000
keep-alive-requests:"10000"
# Keep-Alive 連接的空閑超時時間，默認 75s
keep-alive:"75"

參數(shù)解讀：

keep-alive-requests：一個 Keep-Alive 連接上最多跑多少個請求后強制關閉。默認 1000，高并發(fā)場景建議調到 10000。設太大的風險是單個連接占用內存時間過長，但 10000 是個比較安全的值

keep-alive：連接空閑多久后關閉。75s 是個合理的默認值，不需要改太大。設太大會導致空閑連接占用 Worker 的連接槽位

2.3.2 Upstream 側 Keep-Alive

這是很多人忽略的關鍵配置。默認情況下 Nginx 到 upstream（后端 Pod）的連接是短連接，每個請求都新建 TCP 連接再關閉。在高 QPS 場景下，光是 TCP 握手和揮手就能吃掉大量性能。

data:
# 每個 Worker 到每個 upstream 保持的空閑長連接數(shù)
upstream-keepalive-connections:"320"
# upstream 長連接上最多處理的請求數(shù)
upstream-keepalive-requests:"10000"
# upstream 長連接的空閑超時
upstream-keepalive-timeout:"60"

這組參數(shù)的影響有多大？實測數(shù)據(jù)：同樣的 4C8G 配置，upstream 短連接模式下 QPS 約 3.5 萬，開啟 upstream Keep-Alive 后 QPS 直接飆到 7 萬+，提升接近一倍。原因很簡單——省掉了海量的 TCP 連接建立和銷毀開銷，同時減少了 TIME_WAIT 狀態(tài)的 socket 堆積。

upstream-keepalive-connections的取值邏輯：

這個值是每個 Worker 進程到每個 upstream 保持的空閑連接數(shù)上限。計算方式：

建議值 = 預期 QPS / worker_processes / upstream_pod_count * avg_response_time

比如目標 10 萬 QPS、4 個 Worker、10 個后端 Pod、平均響應時間 20ms：

100000 / 4 / 10 * 0.02 = 50

理論上 50 就夠了，但要留余量應對突發(fā)流量，所以設 320 是比較穩(wěn)妥的選擇。設太大會浪費內存（每個空閑連接占約 4KB），設太小會導致連接復用率下降。

2.4 緩沖區(qū)與超時參數(shù)優(yōu)化

2.4.1 代理緩沖區(qū)配置

Nginx 作為反向代理時，會先把 upstream 的響應讀到緩沖區(qū)里，再發(fā)給客戶端。如果緩沖區(qū)不夠大，響應會被寫到磁盤臨時文件，I/O 性能直接崩盤。

data:
# 代理緩沖區(qū)開關，默認開啟
proxy-buffering:"true"
# 響應頭緩沖區(qū)大小
proxy-buffer-size:"8k"
# 響應體緩沖區(qū)：數(shù)量和單個大小
proxy-buffers-number:"8"
# 單個緩沖區(qū)大小（非 ConfigMap 直接參數(shù)，通過 server-snippet 設置）
proxy-body-size:"16m"

調優(yōu)建議：

proxy-buffer-size：用于存放響應頭，8k 能覆蓋絕大多數(shù)場景。如果后端服務的響應頭特別大（比如帶大量 Set-Cookie），需要調到 16k

響應體緩沖區(qū)總大小 =proxy-buffers-number* 單個緩沖區(qū)大小。默認 8 * 4k = 32k，對于返回大 JSON 的 API 可能不夠，建議調到 8 * 16k = 128k

如果響應體超過緩沖區(qū)總大小，Nginx 會寫臨時文件。可以通過proxy-max-temp-file-size控制臨時文件上限，設為 0 表示禁止寫臨時文件（超出緩沖區(qū)的部分直接流式傳輸）

2.4.2 超時參數(shù)配置

超時參數(shù)配錯是生產事故的高頻原因。設太短，正常請求被誤殺；設太長，慢請求拖垮整個連接池。

data:
# 連接 upstream 的超時（TCP 握手階段）
proxy-connect-timeout:"5"
# 從 upstream 讀取響應的超時
proxy-read-timeout:"60"
# 向 upstream 發(fā)送請求的超時
proxy-send-timeout:"60"

各超時參數(shù)的含義和建議值：

參數(shù)	默認值	建議值	說明
proxy-connect-timeout	5s	5s	TCP 握手超時，5s 足夠，設太長會導致故障 Pod 拖慢整體
proxy-read-timeout	60s	60s	等待 upstream 響應的超時，根據(jù)業(yè)務實際 RT 調整
proxy-send-timeout	60s	60s	發(fā)送請求到 upstream 的超時，通常不需要改
proxy-next-upstream-timeout	0	5s	重試下一個 upstream 的總超時，0 表示不限制，建議設 5s

關鍵配置：proxy-next-upstream控制什么情況下重試下一個 upstream：

data:
proxy-next-upstream:"error timeout http_502 http_503 http_504"
proxy-next-upstream-timeout:"5"
proxy-next-upstream-tries:"3"

這個配置的意思是：如果 upstream 返回 502/503/504 或者連接超時，自動重試下一個 Pod，最多重試 3 次，總超時 5s。對于冪等的 GET 請求很有用，但 POST/PUT 請求要謹慎，避免重復提交。

2.4.3 日志優(yōu)化：減少 I/O 開銷

Access log 是性能殺手之一。每個請求寫一行日志，10 萬 QPS 就是每秒 10 萬次磁盤寫入。

data:
# 關閉 access log（激進方案）
disable-access-log:"false"
# 開啟 access log 緩沖（推薦方案）
access-log-params:"buffer=256k flush=5s"
# 自定義日志格式，去掉不需要的字段減少 I/O 量
log-format-upstream:'$remote_addr - $request_method $host$uri $status $body_bytes_sent $request_time'

推薦方案：不要完全關閉 access log（排查問題需要），而是開啟緩沖寫入。buffer=256k flush=5s表示日志先寫到 256KB 的內存緩沖區(qū)，滿了或者每 5 秒刷一次盤。這樣把隨機小 I/O 合并成批量大 I/O，性能提升顯著。

對于不需要記錄日志的健康檢查路徑，可以通過 Annotation 單獨關閉：

metadata:
annotations:
 nginx.ingress.kubernetes.io/server-snippet:|
   location /healthz {
    access_log off;
    return 200 'ok';
   }

2.5 SSL/TLS 性能優(yōu)化

2.5.1 SSL Session Cache

SSL/TLS 握手是 CPU 密集型操作，一次完整的 TLS 1.3 握手需要 1-RTT，TLS 1.2 需要 2-RTT。通過 Session Cache 可以讓客戶端復用之前的 SSL 會話，跳過完整握手流程。

data:
# SSL Session 緩存大小，1MB 約存 4000 個 session
ssl-session-cache-size:"50m"
# Session 有效期
ssl-session-timeout:"1d"
# 啟用 Session Tickets（TLS 1.2 場景）
ssl-session-tickets:"true"

50MB 的 Session Cache 能存約 20 萬個 SSL Session，對于大多數(shù)場景綽綽有余。Session 復用率可以通過 Nginx 的 SSL 指標監(jiān)控：

# 查看 SSL Session 復用率
kubectlexec-n ingress-nginx deploy/ingress-nginx-controller -- 
 curl -s http://localhost:10246/nginx_status

2.5.2 OCSP Stapling

客戶端驗證服務器證書時需要檢查證書是否被吊銷，默認會去 CA 的 OCSP 服務器查詢，這個查詢可能耗時幾百毫秒。OCSP Stapling 讓 Nginx 預先獲取 OCSP 響應并緩存，在 SSL 握手時直接發(fā)給客戶端，省掉客戶端的額外查詢。

data:
enable-ocsp:"true"

注意事項：

OCSP Stapling 需要 Nginx 能訪問 CA 的 OCSP 服務器，如果集群網絡策略限制了出站流量，需要放行

Let's Encrypt 的 OCSP 響應有效期是 7 天，Nginx 會自動刷新

如果使用私有 CA 簽發(fā)的證書，需要確認 CA 支持 OCSP

2.5.3 TLS 協(xié)議版本與密碼套件

data:
# 最低 TLS 版本
ssl-protocols:"TLSv1.2 TLSv1.3"
# TLS 1.3 密碼套件（性能最優(yōu)選擇）
ssl-ciphers:"TLS_AES_128_GCM_SHA256TLS_CHACHA20_POLY1305_SHA256ECDHE-RSA-AES128-GCM-SHA256ECDHE-RSA-AES256-GCM-SHA384"
# 使用服務端優(yōu)先的密碼套件順序
ssl-prefer-server-ciphers:"on"

性能相關的選擇：

TLS 1.3 優(yōu)先：握手只需要 1-RTT（TLS 1.2 需要 2-RTT），且支持 0-RTT 恢復

AES-128-GCM 優(yōu)先于 AES-256-GCM：安全性差異可忽略，但 128 位性能更好

ECDSA 證書優(yōu)先于 RSA 證書：ECDSA P-256 簽名速度是 RSA 2048 的 10 倍以上。如果用 cert-manager 簽發(fā)證書，指定algorithm: ECDSA和size: 256

ChaCha20-Poly1305：在沒有 AES-NI 硬件加速的 ARM 平臺上性能更好

2.5.4 Early Data（0-RTT）

TLS 1.3 支持 0-RTT 恢復，客戶端可以在第一個 TLS 消息中就攜帶應用數(shù)據(jù)，完全省掉握手延遲。但有重放攻擊風險，只適用于冪等請求。

data:
ssl-early-data:"true"

開啟后需要在后端服務中檢查Early-Data: 1請求頭，對非冪等請求做防重放處理。

2.6 負載均衡算法選擇

2.6.1 可選算法對比

Ingress Nginx 支持多種負載均衡算法，通過 ConfigMap 或 Annotation 配置：

算法	ConfigMap 值	特點	適用場景
Round Robin	round_robin（默認）	輪詢分發(fā)，簡單均勻	后端 Pod 配置相同、無狀態(tài)服務
IP Hash	ip-hash	同一客戶端 IP 固定到同一 Pod	需要會話保持但沒有分布式 Session
EWMA	ewma	基于加權移動平均響應時間	后端 Pod 性能不均勻

data:
load-balance:"ewma"

2.6.2 EWMA 算法詳解

EWMA（Exponentially Weighted Moving Average）是 Ingress Nginx 提供的智能負載均衡算法，根據(jù)每個 upstream Pod 的實際響應時間動態(tài)調整權重。響應快的 Pod 分到更多流量，響應慢的 Pod 自動降權。

為什么推薦 EWMA：

在混合節(jié)點集群中（比如部分 Pod 跑在高配機器、部分跑在低配機器），EWMA 能自動適應性能差異

當某個 Pod 出現(xiàn)性能退化（比如 GC 停頓、磁盤 I/O 抖動）時，EWMA 會自動減少發(fā)往該 Pod 的流量

相比 Round Robin，EWMA 在后端性能不均勻時能提升 20%-40% 的整體吞吐量

注意事項：

EWMA 在后端 Pod 完全同質化的場景下和 Round Robin 差異不大

EWMA 的權重計算有一定延遲，對于突發(fā)性能變化的響應不是瞬時的

如果后端服務的響應時間波動很大（比如有些請求 10ms、有些 5s），EWMA 的效果會打折扣

2.6.3 會話保持配置

如果業(yè)務確實需要會話保持（Session Affinity），推薦用 Cookie 方式而不是 IP Hash：

metadata:
annotations:
 nginx.ingress.kubernetes.io/affinity:"cookie"
 nginx.ingress.kubernetes.io/affinity-mode:"balanced"
 nginx.ingress.kubernetes.io/session-cookie-name:"INGRESSCOOKIE"
 nginx.ingress.kubernetes.io/session-cookie-max-age:"172800"
 nginx.ingress.kubernetes.io/session-cookie-samesite:"Strict"

Cookie 方式比 IP Hash 更精確，不會因為 NAT 網關導致大量用戶被哈希到同一個 Pod。affinity-mode: balanced會在 Pod 擴縮容時自動重新平衡會話分布。

三、限流防護與內核調優(yōu)

3.1 限流配置

3.1.1 全局限流

Ingress Nginx 內置了基于 Lua 的限流模塊，支持按 IP、按 URI 等維度限流。限流不僅是防護手段，也是性能保障——防止突發(fā)流量打爆后端服務。

通過 Annotation 對單個 Ingress 配置限流：

metadata:
annotations:
 # 每秒允許的請求數(shù)（令牌桶速率）
 nginx.ingress.kubernetes.io/limit-rps:"100"
 # 突發(fā)請求容量（令牌桶大?。? nginx.ingress.kubernetes.io/limit-burst-multiplier:"5"
 # 限流時返回的 HTTP 狀態(tài)碼
 nginx.ingress.kubernetes.io/limit-rate-after:"0"
 # 并發(fā)連接數(shù)限制
 nginx.ingress.kubernetes.io/limit-connections:"50"

參數(shù)解讀：

limit-rps: 100+limit-burst-multiplier: 5：表示每秒穩(wěn)定放行 100 個請求，允許瞬間突發(fā)到 500 個（100 * 5）。令牌桶算法會平滑突發(fā)流量

limit-connections: 50：單個 IP 最多同時保持 50 個連接。防止單個客戶端占用過多連接資源

3.1.2 限流的粒度控制

默認限流是按客戶端 IP 維度的。但在有 CDN 或負載均衡器的場景下，所有請求的源 IP 都是 CDN 的 IP，按 IP 限流會誤傷正常用戶。

解決方案是使用真實客戶端 IP：

# ConfigMap 全局配置
data:
use-forwarded-headers:"true"
forwarded-for-header:"X-Forwarded-For"
compute-full-forwarded-for:"true"

同時在 Annotation 中指定限流的 key：

metadata:
annotations:
 nginx.ingress.kubernetes.io/limit-rps:"100"
 # 使用 X-Forwarded-For 頭中的真實客戶端 IP 作為限流 key
 nginx.ingress.kubernetes.io/limit-whitelist:"10.0.0.0/8,172.16.0.0/12"

limit-whitelist可以把內部網段排除在限流之外，避免健康檢查和內部調用被限。

3.1.3 全局速率限制

對于需要全局限流（不是按 IP，而是整體 QPS 上限）的場景，可以通過 ConfigMap 的global-rate-limit系列參數(shù)配置：

data:
global-rate-limit-memcached-host:"memcached.ingress-nginx.svc.cluster.local"
global-rate-limit-memcached-port:"11211"
global-rate-limit-status-code:"429"

全局限流依賴 Memcached 做分布式計數(shù)，適用于多副本 Ingress Nginx 的場景。單副本場景用本地限流就夠了。

3.1.4 WAF 防護

Ingress Nginx 支持集成 ModSecurity 作為 WAF（Web Application Firewall）：

data:
enable-modsecurity:"true"
enable-owasp-modsecurity-crs:"true"
modsecurity-snippet:|
  SecRuleEngine On
  SecRequestBodyLimit 10485760
  SecAuditLogType Serial
  SecAuditLog /dev/stdout

性能影響：ModSecurity 會對每個請求做規(guī)則匹配，開啟 OWASP CRS 全量規(guī)則集大約會降低 15%-25% 的 QPS。建議只在面向公網的 Ingress 上開啟，內部服務間調用不需要。

如果性能影響不可接受，可以只開啟部分規(guī)則：

metadata:
annotations:
 nginx.ingress.kubernetes.io/modsecurity-snippet:|
   SecRuleEngine On
   # 只開啟 SQL 注入和 XSS 防護
   SecRule REQUEST_URI "@rx (?i)(union|select|insert|update|delete|drop)" 
    "id:1001,phase:2,deny,status:403,msg:'SQL Injection Detected'"

3.2 內核參數(shù)調優(yōu)

Nginx 的性能上限不只取決于 Nginx 自身的配置，底層的 Linux 內核參數(shù)同樣關鍵。在容器環(huán)境下，部分內核參數(shù)需要通過 Pod 的securityContext或initContainers來設置。

3.2.1 TCP 連接相關參數(shù)

# 通過 initContainer 設置內核參數(shù)
apiVersion:apps/v1
kind:Deployment
metadata:
name:ingress-nginx-controller
spec:
template:
 spec:
  initContainers:
  -name:sysctl
   image:busybox:1.37
   command:
   -sh
   --c
   -|
     sysctl -w net.core.somaxconn=65535
     sysctl -w net.ipv4.tcp_max_syn_backlog=65535
     sysctl -w net.ipv4.ip_local_port_range="1024 65535"
     sysctl -w net.ipv4.tcp_tw_reuse=1
     sysctl -w net.ipv4.tcp_fin_timeout=15
     sysctl -w net.core.netdev_max_backlog=65535
     sysctl -w net.ipv4.tcp_max_tw_buckets=262144
   securityContext:
    privileged:true

各參數(shù)說明：

參數(shù)	默認值	建議值	作用
net.core.somaxconn	4096	65535	listen() 的 backlog 隊列上限，直接影響并發(fā)連接能力
net.ipv4.tcp_max_syn_backlog	1024	65535	SYN 隊列長度，防止 SYN Flood 時丟棄正常連接
net.ipv4.ip_local_port_range	32768-60999	1024-65535	可用的本地端口范圍，影響到 upstream 的連接數(shù)上限
net.ipv4.tcp_tw_reuse	0	1	允許復用 TIME_WAIT 狀態(tài)的 socket，減少端口耗盡風險
net.ipv4.tcp_fin_timeout	60	15	FIN_WAIT_2 超時時間，加速連接回收
net.core.netdev_max_backlog	1000	65535	網卡接收隊列長度，防止高流量下丟包

3.2.2 文件描述符限制

每個 TCP 連接占一個文件描述符，10 萬并發(fā)連接就需要 10 萬個 FD。容器內的 FD 限制需要在 Pod spec 中設置：

spec:
containers:
-name:controller
 # Ingress Nginx Controller 的 ConfigMap 參數(shù)
 # max-worker-open-files 會設置 worker_rlimit_nofile
 securityContext:
  # 容器級別的 ulimit 通過 runtimeClass 或 containerd 配置

在 ConfigMap 中設置：

data:
max-worker-open-files:"131072"

同時確保宿主機的/etc/security/limits.conf或 systemd 的LimitNOFILE設置足夠大。

3.2.3 TCP 緩沖區(qū)調優(yōu)

# 宿主機級別設置（需要 DaemonSet 或節(jié)點初始化腳本）
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
sysctl -w net.ipv4.tcp_mem="786432 1048576 1572864"

參數(shù)說明：

tcp_rmem/tcp_wmem：TCP 接收/發(fā)送緩沖區(qū)的最小值、默認值、最大值。默認的最大值通常偏小，在高帶寬場景下會成為瓶頸

tcp_mem：系統(tǒng)級 TCP 內存使用的閾值（單位是頁，通常 4KB/頁）。三個值分別是低水位、壓力水位、高水位

3.2.4 啟用 BBR 擁塞控制

BBR（Bottleneck Bandwidth and Round-trip propagation time）是 Google 開發(fā)的 TCP 擁塞控制算法，相比傳統(tǒng)的 CUBIC 算法，在高延遲和有丟包的網絡環(huán)境下性能提升顯著。

# 檢查是否支持 BBR
sysctl net.ipv4.tcp_available_congestion_control

# 啟用 BBR
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

Linux 6.8+ 內核默認支持 BBR v3，建議在所有節(jié)點上啟用。對于跨地域、跨云的流量場景，BBR 的效果尤其明顯。

四、最佳實踐

4.1 完整的高性能 ConfigMap 配置

把前面所有調優(yōu)參數(shù)匯總成一份完整的 ConfigMap：

apiVersion:v1
kind:ConfigMap
metadata:
name:ingress-nginx-controller
namespace:ingress-nginx
data:
# Worker 配置
worker-processes:"auto"
worker-connections:"65536"
max-worker-open-files:"131072"
worker-shutdown-timeout:"30s"

# Keep-Alive 配置
keep-alive-requests:"10000"
keep-alive:"75"
upstream-keepalive-connections:"320"
upstream-keepalive-requests:"10000"
upstream-keepalive-timeout:"60"

# 緩沖區(qū)配置
proxy-buffering:"true"
proxy-buffer-size:"8k"
proxy-buffers-number:"8"

# 超時配置
proxy-connect-timeout:"5"
proxy-read-timeout:"60"
proxy-send-timeout:"60"
proxy-next-upstream:"error timeout http_502 http_503 http_504"
proxy-next-upstream-timeout:"5"
proxy-next-upstream-tries:"3"

# SSL 配置
ssl-protocols:"TLSv1.2 TLSv1.3"
ssl-ciphers:"TLS_AES_128_GCM_SHA256TLS_CHACHA20_POLY1305_SHA256ECDHE-RSA-AES128-GCM-SHA256"
ssl-prefer-server-ciphers:"on"
ssl-session-cache-size:"50m"
ssl-session-timeout:"1d"
ssl-session-tickets:"true"
enable-ocsp:"true"

# 負載均衡
load-balance:"ewma"

# 日志優(yōu)化
access-log-params:"buffer=256k flush=5s"
log-format-upstream:'$remote_addr - $request_method $host$uri $status $body_bytes_sent $request_time'

# 其他優(yōu)化
use-gzip:"true"
gzip-level:"3"
enable-brotli:"true"
brotli-level:"3"
use-forwarded-headers:"true"
compute-full-forwarded-for:"true"
enable-real-ip:"true"

關于壓縮級別的說明：gzip 和 brotli 的壓縮級別設為 3 而不是更高，是因為壓縮級別越高 CPU 消耗越大，但壓縮率的邊際收益遞減。級別 3 在壓縮率和 CPU 消耗之間取得了最佳平衡。

4.2 Pod 資源配置建議

apiVersion:apps/v1
kind:Deployment
metadata:
name:ingress-nginx-controller
namespace:ingress-nginx
spec:
replicas:2
template:
 spec:
  # 調度到專用節(jié)點，避免和業(yè)務 Pod 爭搶資源
  nodeSelector:
   node-role.kubernetes.io/ingress:"true"
  tolerations:
  -key:"node-role.kubernetes.io/ingress"
   operator:"Exists"
   effect:"NoSchedule"
  # 反親和性，確保兩個副本不在同一節(jié)點
  affinity:
   podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    -labelSelector:
      matchExpressions:
      -key:app.kubernetes.io/name
       operator:In
       values:["ingress-nginx"]
     topologyKey:kubernetes.io/hostname
  containers:
  -name:controller
   resources:
    requests:
     cpu:"4"
     memory:"8Gi"
    limits:
     cpu:"4"
     memory:"8Gi"
   # 設置 CPU 親和性，減少 NUMA 跨節(jié)點訪問
   # 需要配合 CPU Manager 的 static 策略

關鍵點：

requests 等于 limits：確保 Pod 獲得 Guaranteed QoS，不會被驅逐，CPU 不會被節(jié)流

專用節(jié)點：Ingress Nginx 是流量入口，和業(yè)務 Pod 混部會互相影響。用 nodeSelector + taint 隔離

反親和性：兩個副本分散到不同節(jié)點，避免單點故障

CPU Manager static 策略：讓 Worker 進程綁定到固定 CPU 核心，減少上下文切換和緩存失效

4.3 優(yōu)雅關閉與滾動更新

Ingress Nginx 的滾動更新如果配置不當，會導致流量中斷。關鍵是確保舊 Pod 在停止接收新連接后，有足夠時間處理完存量請求。

spec:
template:
 spec:
  terminationGracePeriodSeconds:60
  containers:
  -name:controller
   lifecycle:
    preStop:
     exec:
      command:
      -/wait-shutdown
strategy:
 type:RollingUpdate
 rollingUpdate:
  maxUnavailable:0
  maxSurge:1

配置邏輯：

maxUnavailable: 0：滾動更新時不允許減少可用副本數(shù)，先起新的再停舊的

maxSurge: 1：最多多出一個副本

terminationGracePeriodSeconds: 60：給舊 Pod 60 秒的優(yōu)雅關閉時間

/wait-shutdown：Ingress Nginx 內置的優(yōu)雅關閉腳本，會等待存量連接處理完畢

五、壓測驗證與故障排查

5.1 壓測方法

調優(yōu)不壓測等于白調。每次參數(shù)變更后都需要壓測驗證效果，確認性能提升而不是引入新問題。

5.1.1 使用 wrk 進行基準壓測

wrk 是輕量級的 HTTP 壓測工具，適合快速驗證單接口性能：

# 安裝 wrk
apt install -y wrk

# 基礎壓測：4 線程、200 并發(fā)連接、持續(xù) 30 秒
wrk -t4 -c200 -d30s https://your-domain.com/api/health

# 帶 Keep-Alive 的壓測（wrk 默認就是 Keep-Alive）
wrk -t8 -c1000 -d60s --latency https://your-domain.com/api/health

# 使用 Lua 腳本自定義請求
wrk -t4 -c200 -d30s -s post.lua https://your-domain.com/api/data

wrk 的 Lua 腳本示例：

-- post.lua：模擬 POST 請求
wrk.method ="POST"
wrk.body  ='{"key": "value"}'
wrk.headers["Content-Type"] ="application/json"

解讀 wrk 輸出：

Running 30stest@ https://your-domain.com/api/health
 8 threads and 1000 connections
 Thread Stats  Avg   Stdev   Max  +/- Stdev
  Latency   1.23ms  0.56ms  15.67ms  89.12%
  Req/Sec  12.85k   1.23k  15.67k  72.34%
 Latency Distribution
  50%  1.12ms
  75%  1.45ms
  90%  1.89ms
  99%  3.45ms
 3078456 requestsin30.00s, 1.23GBread
Requests/sec: 102615.20
Transfer/sec:   42.01MB

關注的核心指標：Requests/sec（QPS）、p99 延遲、是否有 Socket errors。

5.1.2 使用 vegeta 進行恒定速率壓測

wrk 是盡可能快地發(fā)請求，但生產環(huán)境的流量模式通常是恒定速率。vegeta 支持指定固定 QPS 進行壓測，更貼近真實場景：

# 安裝 vegeta
go install github.com/tsenart/vegeta/v12@latest

# 恒定 50000 QPS 壓測 60 秒
echo"GET https://your-domain.com/api/health"| 
 vegeta attack -rate=50000/s -duration=60s | 
 vegeta report

# 階梯式壓測：從 10000 QPS 逐步增加到 100000 QPS
echo"GET https://your-domain.com/api/health"| 
 vegeta attack -rate=10000/s -duration=30s > results_10k.bin
echo"GET https://your-domain.com/api/health"| 
 vegeta attack -rate=50000/s -duration=30s > results_50k.bin
echo"GET https://your-domain.com/api/health"| 
 vegeta attack -rate=100000/s -duration=30s > results_100k.bin

# 生成 HTML 報告
vegeta report -type=json results_100k.bin | vegeta plot > report.html

vegeta 的優(yōu)勢：

恒定速率模式能準確測出系統(tǒng)在特定 QPS 下的延遲表現(xiàn)

支持輸出 HDR Histogram，精確到 p99.9 延遲

階梯式壓測能找到系統(tǒng)的性能拐點——QPS 從多少開始延遲急劇上升

5.1.3 壓測注意事項

壓測客戶端不能成為瓶頸：單臺機器的端口數(shù)有限（約 6 萬），壓 10 萬 QPS 可能需要多臺壓測機

壓測環(huán)境要隔離：不要在生產集群上直接壓測，用獨立的壓測環(huán)境

關注系統(tǒng)指標：壓測時同步監(jiān)控 CPU、內存、網絡帶寬、連接數(shù)、FD 使用量

預熱：壓測前先用低流量預熱 10-20 秒，讓連接池和緩存建立起來

多輪對比：每次只改一個參數(shù)，對比前后的壓測結果，避免多個變量干擾

5.1.4 壓測時的監(jiān)控命令

# 實時查看 Nginx 連接狀態(tài)
kubectlexec-n ingress-nginx deploy/ingress-nginx-controller -- 
 curl -s http://localhost:10246/nginx_status

# 輸出示例
# Active connections: 12345
# server accepts handled requests
# 98765432 98765432 123456789
# Reading: 123 Writing: 456 Waiting: 11766

# 查看 Worker 進程的 CPU 使用率
kubectlexec-n ingress-nginx deploy/ingress-nginx-controller -- 
 top -bn1 -p $(pgrep -d','nginx)

# 查看 TCP 連接狀態(tài)分布
kubectlexec-n ingress-nginx deploy/ingress-nginx-controller -- 
 ss -s

# 查看 Prometheus 指標
kubectlexec-n ingress-nginx deploy/ingress-nginx-controller -- 
 curl -s http://localhost:10254/metrics | grep nginx_ingress_controller_requests

5.2 故障排查

5.2.1 常見性能問題排查表

現(xiàn)象	可能原因	排查方法	解決方案
QPS 上不去，CPU 未打滿	worker_connections 不夠	檢查nginx_connections_active是否接近上限	調大 worker-connections
QPS 上不去，CPU 打滿	SSL 握手消耗過多 CPU	檢查 SSL Session 復用率	調大 ssl-session-cache-size，使用 ECDSA 證書
延遲突然飆高	upstream 連接復用率低	檢查 TIME_WAIT 連接數(shù)	開啟 upstream-keepalive-connections
502 錯誤增多	upstream Pod 不可用或超時	檢查 upstream Pod 狀態(tài)和日志	調整 proxy-next-upstream 重試策略
內存持續(xù)增長	舊 Worker 進程未退出	ps aux | grep nginx 檢查進程數(shù)	調整 worker-shutdown-timeout
連接被拒絕	somaxconn 或 FD 限制	dmesg | grep "dropped"	調大內核參數(shù)和 FD 限制

5.2.2 關鍵監(jiān)控指標

用 Prometheus 采集 Ingress Nginx 的指標，配合 Grafana 做可視化。推薦監(jiān)控的核心指標：

# Prometheus 告警規(guī)則示例
groups:
-name:ingress-nginx
rules:
# QPS 突降告警
-alert:IngressNginxQPSDrop
 expr:|
   rate(nginx_ingress_controller_requests[5m]) <
? ? ? rate(nginx_ingress_controller_requests[5m] offset 1h) * 0.5
? ??for:5m
? ??labels:
? ? ??severity:warning
? ??annotations:
? ? ??summary:"Ingress Nginx QPS 下降超過 50%"

# p99 延遲告警
-alert:IngressNginxHighLatency
? ??expr:|
? ? ? histogram_quantile(0.99,
? ? ? ? rate(nginx_ingress_controller_request_duration_seconds_bucket[5m])
? ? ? ) > 1
 for:5m
 labels:
  severity:critical
 annotations:
  summary:"Ingress Nginx p99 延遲超過 1 秒"

# 5xx 錯誤率告警
-alert:IngressNginxHigh5xxRate
 expr:|
   sum(rate(nginx_ingress_controller_requests{status=~"5.."}[5m])) /
   sum(rate(nginx_ingress_controller_requests[5m])) > 0.01
 for:5m
 labels:
  severity:critical
 annotations:
  summary:"Ingress Nginx 5xx 錯誤率超過 1%"

# 連接數(shù)接近上限
-alert:IngressNginxConnectionsHigh
 expr:|
   nginx_ingress_controller_nginx_process_connections >
   nginx_ingress_controller_nginx_process_connections_total * 0.8
 for:5m
 labels:
  severity:warning
 annotations:
  summary:"Ingress Nginx 活躍連接數(shù)超過 80%"

5.2.3 日志排查技巧

# 查看最近的 5xx 錯誤
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller --tail=1000 | 
 grep" 50[0-9] "

# 查看 upstream 超時的請求
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller --tail=1000 | 
 grep"upstream timed out"

# 查看 Nginx 錯誤日志
kubectlexec-n ingress-nginx deploy/ingress-nginx-controller -- 
 tail -100 /var/log/nginx/error.log

# 查看 Nginx reload 頻率（頻繁 reload 影響性能）
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller --tail=5000 | 
 grep"Backend successfully reloaded"| wc -l

Nginx reload 頻率過高的問題：每次 Ingress/Service/Endpoint 變更都會觸發(fā) reload。在大規(guī)模集群中（幾百個 Ingress 規(guī)則），頻繁 reload 會導致性能抖動。Ingress Nginx Controller 1.9+ 引入了動態(tài)配置更新機制，upstream 變更不再需要 reload，但 Ingress 規(guī)則變更仍然需要。減少不必要的 Ingress 變更是降低 reload 頻率的關鍵。

5.3 Gateway API 遷移路徑

5.3.1 為什么要關注 Gateway API

Ingress API 從 Kubernetes 1.1 就存在了，設計上有不少歷史包袱：

表達能力有限：不支持 HTTP 頭匹配、請求鏡像、流量拆分等高級路由功能，只能靠 Annotation 擴展，而 Annotation 是非標準化的

角色模型單一：Ingress 資源把基礎設施配置和應用路由混在一起，集群管理員和應用開發(fā)者沒有清晰的職責邊界

跨實現(xiàn)不可移植：不同 Ingress Controller 的 Annotation 完全不同，從 Nginx 遷移到 Envoy 基本要重寫所有配置

Gateway API 是 Kubernetes SIG-Network 設計的下一代流量管理標準，在 Kubernetes 1.31 中已經 GA。它解決了上述所有問題：

豐富的路由能力：原生支持 HTTP 頭匹配、路徑重寫、請求鏡像、加權流量拆分

分層角色模型：GatewayClass（平臺團隊）-> Gateway（集群管理員）-> HTTPRoute（應用開發(fā)者），職責清晰

跨實現(xiàn)可移植：標準化的 API，不同實現(xiàn)之間可以無縫遷移

5.3.2 Ingress Nginx 對 Gateway API 的支持

Ingress Nginx Controller 從 1.11 版本開始實驗性支持 Gateway API。啟用方式：

# 安裝 Gateway API CRD
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.1/standard-install.yaml

# 在 Ingress Nginx Controller 啟動參數(shù)中啟用 Gateway API
# 添加 --enable-gateway-api 標志

# Helm values 配置
controller:
extraArgs:
 enable-gateway-api:"true"

5.3.3 從 Ingress 到 HTTPRoute 的遷移示例

一個典型的 Ingress 資源：

# 舊的 Ingress 配置
apiVersion:networking.k8s.io/v1
kind:Ingress
metadata:
name:my-app
annotations:
 nginx.ingress.kubernetes.io/rewrite-target:/
 nginx.ingress.kubernetes.io/limit-rps:"100"
spec:
ingressClassName:nginx
tls:
-hosts:
 -app.example.com
 secretName:app-tls
rules:
-host:app.example.com
 http:
  paths:
  -path:/api
   pathType:Prefix
   backend:
    service:
     name:api-service
     port:
      number:80

遷移到 Gateway API 后：

# GatewayClass（平臺團隊管理）
apiVersion:gateway.networking.k8s.io/v1
kind:GatewayClass
metadata:
name:nginx
spec:
controllerName:k8s.io/ingress-nginx
---
# Gateway（集群管理員管理）
apiVersion:gateway.networking.k8s.io/v1
kind:Gateway
metadata:
name:main-gateway
namespace:ingress-nginx
spec:
gatewayClassName:nginx
listeners:
-name:https
 protocol:HTTPS
 port:443
 tls:
  mode:Terminate
  certificateRefs:
  -name:app-tls
 allowedRoutes:
  namespaces:
   from:All
---
# HTTPRoute（應用開發(fā)者管理）
apiVersion:gateway.networking.k8s.io/v1
kind:HTTPRoute
metadata:
name:my-app
namespace:default
spec:
parentRefs:
-name:main-gateway
 namespace:ingress-nginx
hostnames:
-app.example.com
rules:
-matches:
 -path:
   type:PathPrefix
   value:/api
 filters:
 -type:URLRewrite
  urlRewrite:
   path:
    type:ReplacePrefixMatch
    replacePrefixMatch:/
 backendRefs:
 -name:api-service
  port:80

5.3.4 遷移建議

Gateway API 是未來方向，但不需要急著全量遷移。推薦的漸進式遷移策略：

第一階段：共存。在集群中同時部署 Ingress 和 Gateway API 資源，新服務用 HTTPRoute，舊服務保持 Ingress 不動。Ingress Nginx Controller 同時支持兩種 API

第二階段：逐步遷移。按業(yè)務線逐步把 Ingress 資源轉換為 HTTPRoute，每次遷移后做流量驗證

第三階段：清理。所有服務遷移完成后，移除舊的 Ingress 資源

遷移過程中的性能注意事項：

Gateway API 和 Ingress API 共存時，Ingress Nginx Controller 需要同時 watch 兩種資源，會略微增加內存消耗

HTTPRoute 的路由匹配邏輯和 Ingress 有細微差異，遷移后需要驗證路由行為是否一致

Gateway API 目前還不支持 Ingress Nginx 的所有 Annotation 功能，遷移前需要確認所用的 Annotation 是否有對應的 Gateway API 替代方案

長期來看，如果團隊對 Envoy 生態(tài)更感興趣，可以考慮直接遷移到 Envoy Gateway 或 Cilium Gateway API 實現(xiàn)。Gateway API 的標準化意味著從 Nginx 遷移到 Envoy 只需要替換 GatewayClass，HTTPRoute 資源完全不用改。

六、總結

6.1 調優(yōu)效果對比

把本文涉及的所有調優(yōu)項匯總，對比默認配置和優(yōu)化配置在 4C8G 單 Pod 上的壓測結果：

指標	默認配置	優(yōu)化后配置	提升幅度
QPS（HTTP）	~25,000	~110,000	340%
QPS（HTTPS）	~15,000	~85,000	467%
p99 延遲（10 萬 QPS）	超時	3.2ms	-
最大并發(fā)連接數(shù)	~16,000	~130,000	712%
SSL Session 復用率	~30%	~92%	207%
upstream 連接復用率	0%（短連接）	~95%	-

提升最大的三個調優(yōu)項依次是：upstream Keep-Alive（連接復用）、SSL Session Cache + ECDSA 證書、內核參數(shù)調優(yōu)。這三項加起來貢獻了 80% 以上的性能提升。

6.2 調優(yōu)優(yōu)先級排序

不是所有參數(shù)都需要一次性調完。按照投入產出比排序，推薦的調優(yōu)順序：

優(yōu)先級	調優(yōu)項	預期提升	實施難度
P0	upstream Keep-Alive	80%-100%	低，改 ConfigMap
P0	worker_connections + FD 限制	30%-50%	低，改 ConfigMap
P1	SSL Session Cache + ECDSA 證書	50%-80%（HTTPS 場景）	中，需要換證書
P1	內核參數(shù)（somaxconn/tw_reuse）	20%-30%	中，需要 initContainer
P2	日志緩沖寫入	10%-15%	低，改 ConfigMap
P2	EWMA 負載均衡	10%-20%（異構環(huán)境）	低，改 ConfigMap
P3	BBR 擁塞控制	5%-15%（高延遲網絡）	中，需要節(jié)點配置
P3	0-RTT Early Data	5%-10%（TLS 1.3）	低，但有安全風險

6.3 技術要點回顧

upstream Keep-Alive 是性能提升的最大杠桿。默認的短連接模式在高 QPS 下會產生海量 TCP 握手和 TIME_WAIT，開啟 upstream-keepalive-connections 后性能直接翻倍

必須設置 CPU limit。不設 limit 的情況下 worker_processes auto 會讀取宿主機核心數(shù)，導致 Worker 進程數(shù)遠超實際可用 CPU，性能反而下降

SSL 優(yōu)化的核心是減少握手次數(shù)。Session Cache、OCSP Stapling、ECDSA 證書、TLS 1.3 這四項組合起來，能把 HTTPS 的性能損耗從 40% 降到 10% 以內

內核參數(shù)是隱形天花板。somaxconn、FD 限制、端口范圍這些參數(shù)不調，Nginx 層面再怎么優(yōu)化也突破不了系統(tǒng)層的限制

日志不要關，要緩沖。buffer=256k flush=5s 的緩沖寫入方案在保留排查能力的同時大幅降低 I/O 開銷

壓測要用恒定速率工具。vegeta 的恒定速率模式比 wrk 的最大壓力模式更能反映真實場景下的性能表現(xiàn)