使用nginx的ingress時遇到的502問題怎么解決

今天小編給大家分享一下使用nginx的ingress時遇到的502問題怎么解決的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

啟用 keep-alive，502 響應增加

nginx-ingress-controller 0.20 之前的版本存在一個 bug，配置模版 nginx.tmpl 中沒有在啟用 keep-alive 時清除請求中的 “Connection: close”，反而是為所有轉發給 upstream 的 http 請求加上了該請求頭：

image

應該是

image

因為該 bug 的存在， 0.20 之前的版本即使在 config-map 中配置了 keep-alive，nginx 與 pod 之間的 http 通信依舊是短連接，每產生一個請求就建立一個連接。連接利用效率低，并且大量連接處于 time-wait 狀態，浪費了數量有限的本地端口。

發現該問題后，我們進行了及時修復，然后問題來了。

nginx 的請求日志顯示，keep-alive 真正生效以后，502 響應的數量有所增多，大部分業務系統對此不敏感，但有個別系統因 502 響應而頻繁告警，這些系統在 keep-alive 沒有生效之前，沒有遇到 502 響應。

調查工作開始。

502 響應占比很少很少，并且出現的時機不明，一開始毫無頭緒，通過翻閱 nginx 的日志和分析抓取的部分報文發現，出現 502 響應時，nginx 向 upstream 轉發請求后，立即收到了 RST 報文：連接被 pod 斷開了。

Nginx 轉發給 Pod 的請求中指定了 keep-alive，連接也持續了較長時間，來回有過多次請求了，為什么會突然被 Pod 斷開連接呢？

各種胡思亂想之后，將目標鎖定為在 Pod 中運行的業務系統。在 Pod 中運行的業務系統是一個 tomcat 服務，tomcat 本身就是一個請求代理軟件。

事實上，客戶端發起的請求經過了兩次代理，第一次由 nginx 代理到 Pod 中的 tomcat，第二次由 tomcat 代理到處理該請求的進程。

翻看 tomcat 的配置手冊時，發現 tomcat 有幾個和 nginx 類似的配置，它們分別指定了長連接的閑置超時時間（keepAliveTimeout）和長連接中的請求數量上限（maxKeepAliveRequest）。

image

image

很巧的是，這兩個配置項的默認值和 nginx 中類似配置的默認值相同，都是連接閑置 60s 秒后斷開，以及連接中請求數量達到 100 后，斷開連接。那么問題來了，nginx 和 tomcat 誰會先斷開連接？

從捕獲的報文來看，有時候是 tomcat 先斷開的，nginx 后知后覺依舊轉發請求，結果收到了 RST 大禮包，繼而回應 502。502 錯誤碼含義正是：上游返回了非預期的數據。

隨后我們分析了另一個有同樣問題的 python 服務，這個 python 服務也不是直接監聽端口處理請求的，而是用 Gunicorn 代理。查了一下 Gunicorn 的默認配置，更夸張，它的連接閑置超時時間是 2 秒！

分析該 python 服務的報文時還在納悶，為什么它的連接很快就斷開？一度讓我們懷疑前面的假設，直到發現它的默認超時時間是 2 秒，才釋然：報文顯示，連接正是在閑置 2 秒之后，被 Pod 端主動斷開的！

image

要避免 Pod 先斷開連接，方法其實很簡單，讓 nginx 中的相關配置小于 Pod 中的代理軟件的相關配置即可。譬如tomcat 的 maxKeepAliveRequest 是 100，那么 nginx 中配置成 99，確保連接是被 nginx 主動斷開的。

這里只大概說明一下原委，查看當時的調查記錄，點擊「閱讀原文」。

另外還有一個 504 的問題，504 其實是 kube-apiserver 的配置錯誤導致的，因為配置錯誤導致 endpoints 沒有及時更新，繼而導致 nginx 的配置文件沒有更新。

Nginx 的 upstream 配置中的 IP 地址早已不存在，或者已經分配給其它 Pod，從而導致客戶端收到 504 響應或者得到的是另一個服務的響應。

以上就是“使用nginx的ingress時遇到的502問題怎么解決”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業資訊頻道。