線上 K8s Ingress 訪問故障排查思路，看這一篇就夠了

具體現(xiàn)象

應(yīng)用遷移至我們的 PaaS 平臺后會出現(xiàn)偶發(fā)性的502問題，錯誤見圖片：

相比于程序的請求量，錯誤肯定是比較少的，但是錯誤一直在發(fā)生，會影響調(diào)用方的代碼，需要檢查下問題原因。

為啥只看到了POST請求

讀者肯定會說, 你們 ELK 過濾字段里面寫的是POST，所以肯定只有POST請求，其實不是這樣的，GET請求也會有502，只是Nginx會對GET請求進(jìn)行重試，產(chǎn)生類似如下的日志：

重試機(jī)制是Nginx默認(rèn)的: proxy_next_upstream
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream

因為GET方法會被認(rèn)為是冪等的, 所以當(dāng)一個upstream出現(xiàn)502的時候, nginx會再次嘗試. 對于我們的問題, 主要想確認(rèn)為什么有502, 只看POST請求就足夠了, 兩者的原因應(yīng)該是一致的.

網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)

網(wǎng)絡(luò)請求流入集群時, 對于我們集群的結(jié)構(gòu)：

用戶請求=>Nginx=>Ingress =>uwsgi

不要問為什么有了 Ingress 還有 Nginx。這是歷史原因，有些工作暫時需要由 Nginx 承擔(dān)。

統(tǒng)計排查

基于我們對于Nginx和Ingress的錯誤請求統(tǒng)計，發(fā)現(xiàn)兩者中的502錯誤是想等的，說明問題一定是出現(xiàn)在Ingress<=>uwsgi之中。

抓包

這個并不是最先想到的方案，因為我們用了很多統(tǒng)計方法也沒總結(jié)出來規(guī)律，最后只能寄希望于抓包了…

該請求日志如下:

抓包結(jié)果如下：

從抓包情況來看，當(dāng)前的tcp連接被復(fù)用了，由于Ingress中使用了HTTP1.1協(xié)議，會在一次tcp連接中嘗試發(fā)送第二個HTTP請求，但是uwsgi沒有支持http1.1，所以在第二個請求根本不會被處理，直接拒絕了。所以在Ingress看來，這個請求失敗了, 因此返回了502. 由于GET請求會重試, 但POST請求無法重試, 所以訪問統(tǒng)計中出現(xiàn)了POST請求502的問題。

Ingress配置學(xué)習(xí)

Ingress中, 默認(rèn)對upstream使用的http版本為1.1, 但是我們的uwsgi使用的是http-socket, 而非http11-socket, 我們Ingress中使用了與后端不同的協(xié)議, 出現(xiàn)了意料之外的502錯誤。

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#proxy-http-version

因為Nginx默認(rèn)是1.0, 但是切換到Ingress中默認(rèn)變成了1.1, 而我們沒有統(tǒng)一, 解決方案是強(qiá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會在什么時候復(fù)用http1.1的連接，以及為什么Ingress不復(fù)用每一個連接，這樣問題會盡快的暴露，這些問題我沒有繼續(xù)深究了。畢竟你換個語言比如Golang就沒有這個問題了，這個是uwsgi專屬錯誤。

總結(jié)

有關(guān)這個502問題的排查, 我個人覺得, 最后抓包一次性解決問題其實沒什么特別的, 抓了就能發(fā)現(xiàn)問題, 不抓就發(fā)現(xiàn)不了.

我是希望給大家一個啟發(fā), 對于一整條鏈路, 如何來排查故障: 我們這里既使用了Nginx, 又使用了Ingress, 在排查時, 需要首先檢查兩者的錯誤數(shù)量, 如果確認(rèn)錯誤基本一致, 那就說明錯誤與Nginx沒有關(guān)系, 需要檢查Ingres上的錯誤, 對于多個中轉(zhuǎn)的請求, 這樣的排查能比較快的確定鏈路的錯誤位置.

來源：https://corvo.myseu.cn/archives

文章轉(zhuǎn)載：高效運(yùn)維

（版權(quán)歸原作者所有，侵刪）

點擊下方“閱讀原文”查看更多