1.背景資訊
本案例測試環境下發生。
本次問題環境比較複雜，隻能說解決了問題，但是還沒精準定位到是哪個原因導緻，這裡還是做一個記錄。
接到web項目小夥的求助，說是通路域名網頁空白，發現調試界面的url路由到了其它項目的位址，懷疑是ingress路由問題。
但是後端pod檢視日志，日志正常，我看也沒有什麼異常問題出現。隻有一個304的狀态碼。
但是網頁通路空白，傳回其它域名資訊。比如原本通路。結果百度的網頁是一篇空白，使用浏覽器調試，結果代碼的index傳回的卻是www.google.com資訊。
2.排錯以及解決
這裡也隻能按照排錯思路去解決問題。
第一步檢視ingress,發現ingress又不正常，再次出現沒有IP的情況，以為是改變了pod時間，還是以前的bug。（參考ingress nginx出現404錯誤）。但是這次也沒出現404代碼，但是，ingress顯示沒有IP配置設定，而日志可以正常捕獲到。（之前出現404是沒有請求到pod的）。
然後按照之前的思路，以為是ingress的bug，于是删除了ingress控制器pod，問題還是沒有得到解決。
于是突然發現，這個小夥子從來不看告警，會不會叢集狀态出現了問題，便登入騰訊雲tke，檢視node資訊，果然，cpu和記憶體基本滿了。
于是擴容node節點以及同時删除了pod的ingress檔案，重新apply，最後ip出現,通路也正常。
由于這個問題出現比較急，沒有時間做更多的排查，是為了解決問題為主，是以具體什麼原因導緻尚不清楚，主要做了以下幾部，這裡做一個簡單的記錄，後期碰到了文檔再次補充。
- 删除ingress 控制器pod。
- 删除pod的ingress檔案。
- 擴容node節點。
3.2022年4月2日更新
問題得到解決，首先第一個問題是通路出現其他項目的網址，比如，結果通路到了,原因是負載均衡預設的80是是，通路的時候沒有加https，一個大烏龍，麻了。
第二個問題就是網頁還是會莫名其妙的報錯，有的人報錯，有的人不報錯，報錯的人通路的代碼也是以前的，檢查pod這回是絕對沒有問題的，果然詢問了研發，一天之内，頻繁的更新cdn資源，緩存沒有重新整理，CDN手動重新整理一次就好了。
作者：小家電維修
轉世燕還故榻,為你銜來二月的花。