線上 K8s Ingress 訪問故障排查思路，看這一篇就夠了
具體現(xiàn)象
應用遷移至我們的 PaaS 平臺后會出現(xiàn)偶發(fā)性的502問題，錯誤見圖片：
相比于程序的請求量，錯誤肯定是比較少的，但是錯誤一直在發(fā)生，會影響調用方的代碼，需要檢查下問題原因。
為啥只看到了POST請求
讀者肯定會說, 你們 ELK 過濾字段里面寫的是POST，所以肯定只有POST請求，其實不是這樣的，GET請求也會有502，只是Nginx會對GET請求進行重試，產生類似如下的日志：
重試機制是Nginx默認的: proxy_next_upstreamhttp://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream
因為GET方法會被認為是冪等的, 所以當一個upstream出現(xiàn)502的時候, nginx會再次嘗試. 對于我們的問題, 主要想確認為什么有502, 只看POST請求就足夠了, 兩者的原因應該是一致的。
網絡拓撲結構
網絡請求流入集群時, 對于我們集群的結構：
用戶請求=>Nginx=>Ingress =>uwsgi
不要問為什么有了 Ingress 還有 Nginx。這是歷史原因，有些工作暫時需要由 Nginx 承擔。
統(tǒng)計排查
基于我們對于Nginx和Ingress的錯誤請求統(tǒng)計，發(fā)現(xiàn)兩者中的502錯誤是想等的，說明問題一定是出現(xiàn)在Ingress<=>uwsgi之中。
抓包
這個并不是最先想到的方案，因為我們用了很多統(tǒng)計方法也沒總結出來規(guī)律，最后只能寄希望于抓包了…該請求日志如下:
抓包結果如下：
從抓包情況來看，當前的tcp連接被復用了，由于Ingress中使用了HTTP1.1協(xié)議，會在一次tcp連接中嘗試發(fā)送第二個HTTP請求，但是uwsgi沒有支持http1.1，所以在第二個請求根本不會被處理，直接拒絕了。所以在Ingress看來，這個請求失敗了, 因此返回了502. 由于GET請求會重試, 但POST請求無法重試, 所以訪問統(tǒng)計中出現(xiàn)了POST請求502的問題。
Ingress配置學習
Ingress中, 默認對upstream使用的http版本為1.1, 但是我們的uwsgi使用的是http-socket, 而非http11-socket, 我們Ingress中使用了與后端不同的協(xié)議, 出現(xiàn)了意料之外的502錯誤。
因為Nginx默認是1.0, 但是切換到Ingress中默認變成了1.1, 而我們沒有統(tǒng)一, 解決方案是強制指定Ingress中使用的http協(xié)議版本。
{% if keepalive_enable is sameas true %}
nginx.ingress.kubernetes.io/proxy-http-version: "1.1"
{% else %}
nginx.ingress.kubernetes.io/proxy-http-version: "1.0"
{% endif %}
如果有大佬看到了，可以簡單講講Ingress會在什么時候復用http1.1的連接，以及為什么Ingress不復用每一個連接，這樣問題會盡快的暴露，這些問題我沒有繼續(xù)深究了。畢竟你換個語言比如Golang就沒有這個問題了，這個是uwsgi專屬錯誤。
總結
有關這個502問題的排查, 我個人覺得, 最后抓包一次性解決問題其實沒什么特別的, 抓了就能發(fā)現(xiàn)問題, 不抓就發(fā)現(xiàn)不了。
我是希望給大家一個啟發(fā), 對于一整條鏈路, 如何來排查故障: 我們這里既使用了Nginx, 又使用了Ingress, 在排查時, 需要首先檢查兩者的錯誤數(shù)量, 如果確認錯誤基本一致, 那就說明錯誤與Nginx沒有關系, 需要檢查Ingres上的錯誤, 對于多個中轉的請求, 這樣的排查能比較快的確定鏈路的錯誤位置。
