本文介紹關於Nginx基礎知識點,Nginx Ingress Controller實現原理,以及相關營運能力。
Nginx基礎知識點
Nginx Ingress Controller
實現原理
Nginx Ingress Controller是一個集控制平面和資料平面於一體的實現方案。每個Pod下有一個Controller進程,同時也包含Nginx相關進程。
Nginx Ingress資料面相關核心模組
第三方模組:
ACK Nginx Ingress整合了該模組,可以實現同ARMS Trace服務的整合。瞭解更多詳情,請參見實現Nginx Ingress Controller組件的鏈路追蹤。
Nginx Ingress可以通過Configmap配置開啟該模組。
data: enable-opentelemetry: "true" otlp-collector-host: "otel-coll-collector.otel.svc" ## open telemetry 地址
瞭解更多模組詳情,請參見Nginx官方文檔。
配置同步原理
瞭解配置同步的工作原理之後,我們便能夠掌握如何減少配置Reload的頻率,以及在何種情況下需要執行配置Reload。
Nginx Ingress Controller通過Watch Ingress、Service、Pod、Endpoint相關資源,將配置更新到nginx.conf檔案或lua table中。Lua部分主要包含了Upstream端點、灰階發布和認證部分,而如果修改了需要寫入 nginx.conf 檔案的其他Nginx原生參數,則仍會觸發Reload。詳細資料,請參見Nginx Ingress社區文檔部分《When a reload is required》。
Nginx Ingress控制面配置
啟動參數說明
瞭解更多啟動參數詳情,請參見Ingress控制器命令列參數。
查看Nginx Ingress對應的Deployment或者Pod Spec可以看到Nginx Ingress對應的Container的啟動參數,大致如下:
containers:
- args:
- /nginx-ingress-controller
- --election-id=ingress-controller-leader-nginx
- --ingress-class=nginx
- --watch-ingress-without-class
- --controller-class=k8s.io/ingress-nginx
- --configmap=$(POD_NAMESPACE)/nginx-configuration
- --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
- --udp-services-configmap=$(POD_NAMESPACE)/udp-services
- --annotations-prefix=nginx.ingress.kubernetes.io
- --publish-service=$(POD_NAMESPACE)/nginx-ingress-lb
- --enable-annotation-validation
- --validating-webhook=:8443
- --validating-webhook-certificate=/usr/local/certificates/cert
- --validating-webhook-key=/usr/local/certificates/key
- --v=2其中-v指定記錄層級:
--v=2使用Diff顯示有關Nginx中配置更改的詳細資料。--v=3顯示有關服務、入口規則、端點更改的詳細資料,並以JSON格式轉儲Nginx配置。--v=5Debug偵錯模式。
負載平衡演算法
Ingress Nginx允許設定全域預設的負載平衡演算法,主要提供了Round_robin和Ewma兩種選項,預設使用Round_robin。Round_robin演算法迴圈遍曆後端工作負載,使請求均勻分配,但如果後端效能差異較大,可能會出現負載不均衡。相反,Ewma演算法可以將請求發送到加權平均負載最低的工作負載上,加權負載指數會隨著請求的到來而逐漸層化,使得負載平衡更加均衡。
要使用IP或其他變數的一致雜湊進行Server Load Balancer,請考慮使用nginx.ingress.kubernetes.io/upstream-hash-by注釋。要使用會話Cookie進行Server Load Balancer,請考慮使用nginx.ingress.kubernetes.io/affinity注釋。
相關實現:
相關逾時配置
全域逾時配置
可通過以下配置項進行Ingress Nginx的全域逾時配置:
配置項 | 描述 | 取實值型別 | 預設值 |
| 設定與Proxy 伺服器建立串連的逾時時間,單位為秒(s)。 | int |
建議不超過75 |
| 設定從Proxy 伺服器讀取響應的逾時。該逾時僅在兩個連續的讀取操作之間設定,而不是為整個響應的傳輸設定,單位為秒(s)。 | int |
|
| 設定向Proxy 伺服器傳輸請求的逾時。該逾時只在兩個連續的寫操作之間設定,而不是為整個請求的傳輸設定,單位為秒(s)。 | int |
|
| 限制允許將串連傳遞到下一個伺服器的時間,設定為 | string |
|
| 設定用戶端或Proxy 伺服器串連上兩個連續的讀或寫操作之間的逾時時間。如果在這個時間內沒有資料轉送,串連就會關閉。 | string |
|
| 設定一個逾時時間,在這個時間內,與上遊伺服器的空閑串連將保持開放,單位為秒(s)。 | int |
|
| 設定優雅停機的逾時時間。 | string |
|
| 設定接收代理協議標頭檔的逾時值。預設的5秒可以防止TLS直通處理常式無限期地等待一個中斷的串連。 | string |
|
| 設定 SSL 會話緩衝中的會話參數的有效時間。會話到期時間是相對於建立時間而言的。每個會話緩衝會佔用大約0.25MB的空間。 | string |
|
| 定義讀取用戶端請求本文的逾時,單位為秒(s)。 | int |
|
| 定義讀取用戶端要求標頭的逾時,單位為秒(s)。 | int |
|
特定的資源自訂逾時配置
以下是特定的資源自訂逾時配置,以及相關的參數配置。
配置項 | 描述 |
| 設定代理連線逾時時間。 |
| 設定代理髮送逾時時間。 |
nginx.ingress.kubernetes.io/proxy-read-timeout | 設定代理讀取逾時時間。 |
| 配置重試策略或者重試條件,可以使用多個組合用空格分隔,例如設定為
|
| 如果滿足重試條件,則可用的重試次數。 |
| 是否啟用請求緩衝功能。
|
通用全域配置ConfigMap
瞭解更多詳情資訊,請參見Nginx-configuration_configmap。
其他Annotation
瞭解更多詳情資訊,請參見Nginx-configuration_annotations。
自訂配置snippet
nginx.ingress.kubernetes.io/configuration-snippet:對應配置會生效到Location塊下。nginx.ingress.kubernetes.io/server-snippet:對應配置會生效到Server塊下。nginx.ingress.kubernetes.io/stream-snippet:對應配置會生效到Stream塊下。
Nginx Ingress資料面配置
Nginx Ingress的資料平面是通過結合Nginx和ngx_lua模組(即OpenResty)來實現的。Nginx採用多模組化設計,將HTTP請求處理切分成多個階段,允許多個模組協同工作,其中每個模組負責處理一個獨立且簡單的功能。這使得處理更高效、更可靠,並提高了系統的可擴充性。
OpenResty依託NGINX的處理階段,在Rewrite/Access階段、Content階段和Log階段注入了自訂的Handler。加上系統啟動的初始階段,即Master階段,總計OpenResty提供了11個階段,這些階段賦予了 Lua指令碼在HTTP請求處理過程中介入的能力。接下來是OpenResty主要可用階段的圖示描述:
HTTP塊
http {
lua_package_path "/etc/nginx/lua/?.lua;;";
lua_shared_dict balancer_ewma 10M;
lua_shared_dict balancer_ewma_last_touched_at 10M;
lua_shared_dict balancer_ewma_locks 1M;
lua_shared_dict certificate_data 20M;
lua_shared_dict certificate_servers 5M;
lua_shared_dict configuration_data 20M;
lua_shared_dict global_throttle_cache 10M;
lua_shared_dict ocsp_response_cache 5M;
...
}init_by_lua_block
初始化載入了Lua相關模組:
configurationbalancermonitorcertificateplugins
init_worker_by_lua_block
init_worker_by_lua_block {
lua_ingress.init_worker()
balancer.init_worker()
monitor.init_worker(10000)
plugins.run()
}upstream和balancer_by_lua_block
upstream upstream_balancer {
### Attention!!!
#
# We no longer create "upstream" section for every backend.
# Backends are handled dynamically using Lua. If you would like to debug
# and see what backends ingress-nginx has in its memory you can
# install our kubectl plugin https://kubernetes.github.io/ingress-nginx/kubectl-plugin.
# Once you have the plugin you can use "kubectl ingress-nginx backends" command to
# inspect current backends.
#
###
server 0.0.0.1; # placeholder
balancer_by_lua_block {
balancer.balance()
}
keepalive 8000;
keepalive_time 1h;
keepalive_timeout 60s;
keepalive_requests 10000;
}Stream塊
日誌相關
access_log off;
error_log /var/log/nginx/error.log notice;關閉了
access_log。錯誤記錄檔層級設定為了
notice,還可以設定為debug(debug_core、debug_alloc、debug_event、debug_http等)、info、warn、error、crit、alert、emerg等值,層級越高,記錄的資訊越少。
執行以下命令,可以通過查看Nginx Ingress Pod日誌是否有相關報錯資訊。
kubectl logs -f <nginx-ingress-pod-name> -n kube-system |grep -E '^[WE]'相關文檔
關於Nginx Ingress的配置,請參見社區文檔。
關於Nginx Ingress排查方法,請參見常見檢查方法。
關於Nginx Ingress進階用法,請參見Nginx Ingress進階配置。