## 概述 Nginx Ingress Controller 基於 Nginx 實現了 Kubernetes Ingress API，Nginx 是公認的高效能閘道器，但如果不對其進行一些引數調優，就不能充分發揮出高效能的優勢。之前我們在 [Nginx Ingress on TKE 部署最佳實踐](https://mp.weixin.qq.com/s/NAwz4dlsPuJnqfWYBHkfGg) 一文中講了 Nginx Ingress 在 TKE 上部署最佳實踐，涉及的部署 YAML 其實已經包含了一些效能方面的引數優化，只是沒有提及，本文將繼續展開介紹針對 Nginx Ingress 的一些全域性配置與核心引數調優的建議，可用於支撐我們的高併發業務。 ## 核心引數調優 我們先看下如何對 Nginx Ingress 進行核心引數調優，設定核心引數的方法可以用 initContainers 的方式，後面會有示例。 ### 調大連線佇列的大小 程序監聽的 socket 的連線佇列最大的大小受限於核心引數 `net.core.somaxconn`，在高併發環境下，如果佇列過小，可能導致佇列溢位，使得連線部分連線無法建立。要調大 Nginx Ingress 的連線佇列，只需要調整 somaxconn 核心引數的值即可，但我想跟你分享下這背後的相關原理。 程序呼叫 listen 系統呼叫來監聽埠的時候，還會傳入一個 backlog 的引數，這個引數決定 socket 的連線佇列大小，其值不得大於 somaxconn 的取值。Go 程式標準庫在 listen 時，預設直接讀取 somaxconn 作為佇列大小，但 Nginx 監聽 socket 時沒有讀取 somaxconn，而是有自己單獨的引數配置。在 `nginx.conf` 中 listen 埠的位置，還有個叫 backlog 引數可以設定，它會決定 nginx listen 的埠的連線佇列大小。 ``` server { listen 80 backlog=1024; ... ``` 如果不設定，backlog 在 linux 上預設為 511: ``` backlog=number sets the backlog parameter in the listen() call that limits the maximum length for the queue of pending connections. By default, backlog is set to -1 on FreeBSD, DragonFly BSD, and macOS, and to 511 on other platforms. ``` 也就是說，即便你的 somaxconn 配的很高，nginx 所監聽埠的連線佇列最大卻也只有 511，高併發場景下可能導致連線佇列溢位。 不過這個在 Nginx Ingress 這裡情況又不太一樣，因為 Nginx Ingress Controller 會自動讀取 somaxconn 的值作為 backlog 引數寫到生成的 nginx.conf 中： https://github.com/kubernetes/ingress-nginx/blob/controller-v0.34.1/internal/ingress/controller/nginx.go#L592 也就是說，Nginx Ingress 的連線佇列大小隻取決於 somaxconn 的大小，這個值在 TKE 預設為 4096，建議給 Nginx Ingress 設為 65535: `sysctl -w net.core.somaxconn=65535`。 ### 擴大源埠範圍 高併發場景會導致 Nginx Ingress 使用大量源埠與 upstream 建立連線，源埠範圍從 `net.ipv4.ip_local_port_range` 這個核心引數中定義的區間隨機選取，在高併發環境下，埠範圍小容易導致源埠耗盡，使得部分連線異常。TKE 環境建立的 Pod 源埠範圍預設是 32768-60999，建議將其擴大，調整為 1024-65535: `sysctl -w net.ipv4.ip_local_port_range="1024 65535"`。 ### TIME_WAIT 複用 如果短連線併發量較高，它所在 netns 中 TIME_WAIT 狀態的連線就比較多，而 TIME_WAIT 連線預設要等 2MSL 時長才釋放，長時間佔用源埠，當這種狀態連線數量累積到超過一定量之後可能會導致無法新建連線。 所以建議給 Nginx Ingress 開啟 TIME_WAIT 重用，即允許將 TIME_WAIT 連線重新用於新的 TCP 連線： `sysctl -w net.ipv4.tcp_tw_reuse=1` ### 調大最大檔案控制代碼數 Nginx 作為反向代理，對於每個請求，它會與 client 和 upstream server 分別建立一個連線，即佔據兩個檔案控制代碼，所以理論上來說 Nginx 能同時處理的連線數最多是系統最大檔案控制代碼數限制的一半。 系統最大檔案控制代碼數由 `fs.file-max` 這個核心引數來控制，TKE 預設值為 838860，建議調大： `sysctl -w fs.file-max=1048576`。 ### 配置示例 給 Nginx Ingress Controller 的 Pod 新增 initContainers 來設定核心引數： ``` initContainers: - name: setsysctl image: busybox securityContext: privileged: true command: - sh - -c - | sysctl -w net.core.somaxconn=65535 sysctl -w net.ipv4.ip_local_port_range="1024 65535" sysctl -w net.ipv4.tcp_tw_reuse=1 sysctl -w fs.file-max=1048576 ``` ## 全域性配置調優 除了核心引數需要調優，Nginx 本身的一些配置也需要進行調優，下面我們來詳細看下。 ### 調高 keepalive 連線最大請求數 Nginx 針對 client 和 upstream 的 keepalive 連線，均有 keepalive_requests 這個引數來控制單個 keepalive 連線的最大請求數，且預設值均為 100。當一個 keepalive 連線中請求次數超過這個值時，就會斷開並重新建立連線。 如果是內網 Ingress，單個 client 的 QPS 可能較大，比如達到 10000 QPS，Nginx 就可能頻繁斷開跟 client 建立的 keepalive 連線，然後就會產生大量 TIME_WAIT 狀態連線。我們應該儘量避免產生大量 TIME_WAIT 連線，所以，建議這種高併發場景應該增大 Nginx 與 client 的 keepalive 連線的最大請求數量，在 Nginx Ingress 的配置對應 `keep-alive-requests`，可以設定為 10000，參考： https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#keep-alive-requests 同樣的，Nginx 與 upstream 的 keepalive 連線的請求數量的配置是 `upstream-keepalive-requests`，參考： https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#upstream-keepalive-requests 但是，一般情況應該不必配此引數，如果將其調高，可能導致負載不均，因為 Nginx 與 upstream 保持的 keepalive 連線過久，導致連線發生排程的次數就少了，連線就過於 "固化"，使得流量的負載不均衡。 ### 調高 keepalive 最大空閒連線數 Nginx 針對 upstream 有個叫 keepalive 的配置，它不是 keepalive 超時時間，也不是 keepalive 最大連線數，而是 keepalive 最大空閒連線數。 它的預設值為 32，在高併發下場景下會產生大量請求和連線，而現實世界中請求並不是完全均勻的，有些建立的連線可能會短暫空閒，而空閒連線數多了之後關閉空閒連線，就可能導致 Nginx 與 upstream 頻繁斷連和建連，引發 TIME_WAIT 飆升。在高併發場景下可以調到 1000，參考：https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#upstream-keepalive-connections ### 調高單個 worker 最大連線數 `max-worker-connections` 控制每個 worker 程序可以開啟的最大連線數，TKE 環境預設 16384，在高併發環境建議調高，比如設定到 65536，這樣可以讓 nginx 擁有處理更多連線的能力，參考：https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#max-worker-connections ### 配置示例 Nginx 全域性配置通過 configmap 配置（Nginx Ingress Controller 會 watch 並自動 reload 配置）： ``` apiVersion: v1 kind: ConfigMap metadata: name: nginx-ingress-controller # nginx ingress 效能優化: https://www.nginx.com/blog/tuning-nginx/ data: # nginx 與 client 保持的一個長連線能處理的請求數量，預設 100，高併發場景建議調高。 # 參考: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#keep-alive-requests keep-alive-requests: "10000" # nginx 與 upstream 保持長連線的最大空閒連線數 (不是最大連線數)，預設 32，在高併發下場景下調大，避免頻繁建聯導致 TIME_WAIT 飆升。 # 參考: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#upstream-keepalive-connections upstream-keepalive-connections: "200" # 每個 worker 程序可以開啟的最大連線數，預設 16384。 # 參考: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#max-worker-connections max-worker-connections: "65536" ``` ## 總結 本文分享了對 Nginx Ingress 進行效能調優的方法及其原理的解釋，包括核心引數與 Nginx 本身的配置調優，更好的適配高併發的業務場景，希望對大家有所幫助。 ## 參考資料 - Nginx Ingress on TKE 部署最佳實踐：https://mp.weixin.qq.com/s/NAwz4dlsPuJnqfWYBHkfGg - Nginx Ingress 配置參考：https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/ - Tuning NGINX for Performance：https://www.nginx.com/blog/tuning-nginx/ - ngx_http_upstream_module 官方文件：http://nginx.org/en/docs/http/ngx_http_upstream_module.html >【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！ ![](https://img2020.cnblogs.com/other/2041406/202009/2041406-20200902180255620-2039838