Nginx Ingress 高并發實踐-有解無憂

概述

Nginx Ingress Controller 基于 Nginx 實作了 Kubernetes Ingress API，Nginx 是公認的高性能網關，但如果不對其進行一些引數調優，就不能充分發揮出高性能的優勢，之前我們在 Nginx Ingress on TKE 部署最佳實踐一文中講了 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://www.uj5u.com/qita/695.html

標籤：其他

上一篇：Kubernetes Operator基礎入門

下一篇：使用kind快速創建本地集群