公眾號原文：https://mp.weixin.qq.com/s/nEBMG8zdW1O-3XvygMSRVQ
上一篇《Kubernetes Ingress詭異的502、503、504等奇葩問題（一）》簡要說明了使用基於 haproxy 的 ingress 時，遇到 503 的問題，這一篇記錄使用基於 nginx 的 ingress 時，遇到的 502 的問題。
啟用 keep-alive，502 響應增加
nginx-ingress-controller 0.20 之前的版本存在一個 bug，配置模版 nginx.tmpl 中沒有在啟用 keep-alive 時清除請求中的 “Connection: close”，反而是為所有轉發給 upstream 的 http 請求加上了該請求頭：
應該是
因為該 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）。
很巧的是，這兩個配置項的默認值和 nginx 中類似配置的默認值相同，都是連接閑置 60s 秒后斷開，以及連接中請求數量達到 100 后，斷開連接。那么問題來了，nginx 和 tomcat 誰會先斷開連接？
從捕獲的報文來看，有時候是 tomcat 先斷開的，nginx 后知后覺依舊轉發請求，結果收到了 RST 大禮包，繼而回應 502。502 錯誤碼含義正是：上游返回了非預期的數據。
隨后我們分析了另一個有同樣問題的 python 服務，這個 python 服務也不是直接監聽端口處理請求的，而是用 Gunicorn 代理。查了一下 Gunicorn 的默認配置，更誇張，它的連接閑置超時時間是 2 秒！
分析該 python 服務的報文時還在納悶，為什么它的連接很快就斷開？一度讓我們懷疑前面的假設，直到發現它的默認超時時間是 2 秒，才釋然：報文顯示，連接正是在閑置 2 秒之后，被 Pod 端主動斷開的！
要避免 Pod 先斷開連接，方法其實很簡單，讓 nginx 中的相關配置小於 Pod 中的代理軟件的相關配置即可。譬如tomcat 的 maxKeepAliveRequest 是 100，那么 nginx 中配置成 99，確保連接是被 nginx 主動斷開的。
這里只大概說明一下原委，查看當時的調查記錄，點擊「閱讀原文」。
另外還有一個 504 的問題，504 其實是 kube-apiserver 的配置錯誤導致的，因為配置錯誤導致 endpoints 沒有及時更新，繼而導致 nginx 的配置文件沒有更新。
Nginx 的 upstream 配置中的 IP 地址早已不存在，或者已經分配給其它 Pod，從而導致客戶端收到 504 響應或者得到的是另一個服務的響應。
因為時間緊任務多的緣故，我們把配置修復以后，沒有對此進行深入追究，如果有了進一步分析，再補發吧。感謝關注，感謝轉發！
上一篇：Kubernetes Ingress詭異的502、503、504等奇葩問題（一）
關注返回作者微信，直接加，不閑扯
（除非特殊情況，不幫忙解決問題）
