騰訊雲帳號充值辦理 騰訊雲 TKE Ingress-Nginx 組件崩潰導致全站 503 搶修全記錄

事故發生：為什麼一個入口元件會拖垮整站

很多人第一次遇到 503 時，第一反應是應用掛了。這次不是。後端服務還活著，資料庫也正常，業務 Pod 甚至大多處於 Running 狀態，真正出問題的是騰訊雲 TKE 裡的 Ingress-Nginx 組件。它一旦崩潰，外部流量就沒有入口可走，最終表現出來的就是整站 503。

事故發生在一次常規變更之後。當時我們只是新增了一組路由規則，順手調了幾個 Ingress 註解，目的是讓新功能先對少量流量開放。變更本身看起來很小，風險也不高，至少在提交審核的那一刻，沒有人會把它和全站不可用聯想到一起。但入口元件的特性就是這樣，平時安安靜靜，一旦出錯，影響面往往比應用層大得多。

更麻煩的是，Ingress-Nginx 不是單一服務的邏輯故障，而是整個叢集南北向流量的闸門。它承接外部負載均衡器的請求，再根據規則轉發到不同的 Service。只要它自身異常，後面再健康的應用也接不到流量。這種故障有一個很強的迷惑性：叢集內看起來一切正常，叢集外看起來整站壞了。

故障現象：表面是 503，底層是控制器反覆重啟

第一波告警來得很快

最先響起的是監控告警，核心指標是入口層 5xx 比例瞬間拉高。緊接著，客服和產品同事開始反映，打開首頁、登入頁、支付頁都出現 503。這裡最有代表性的現象是，並不是某一個頁面報錯，而是幾乎所有對外暴露的地址都失敗。這說明問題不在單一業務，而在共同入口。

我們先看了應用層日誌，沒有明顯異常；再查資料庫與快取，也都正常；最後把目光轉回入口層，發現 Ingress-Nginx 的 Pod 已經進入反覆重啟狀態。從外面看，LB 還在，域名還在，DNS 也沒問題，可是流量打進去之後沒有穩定的轉發節點，只能看到一片 503。

關鍵線索藏在重啟與刷新之間

進一步看 Pod 事件，能看到控制器在讀取配置後短時間內退出。這不是普通的資源不足，也不像節點故障，更像是某次配置下發後，組件在重新載入時碰到無法處理的內容。當時記錄裡最刺眼的一個信號，就是重啟次數持續增加，而且每次重啟都和配置同步動作幾乎同時發生。

這類問題最難排查的地方在於，它不一定每次都能穩定復現。你會看到服務有時能短暫恢復，有時又立刻掉回 503。對應到使用者體感，就是一會兒打得開，一會兒打不開，像是網路不穩，但其實是入口元件本身在崩。

先止血：比找根因更重要的是恢復流量

第一步不是重啟，而是停止擴大影響

很多故障的壞習慣是，一看到容器掛了就先重啟。可這次不行，因為重啟只會把同一份配置再載入一次，如果問題就藏在配置或版本兼容性裡，重啟只是在重演故障。我們的第一個動作是先凍結變更，停止新的 Ingress 調整，把剛剛提交的規則暫時回退。

隨後檢查 Ingress-Nginx 的部署版本，對照上一次穩定版本，確認這次事故是否和組件升級有關。答案是有關，但不是單純升級失敗，而是版本和某條配置共同觸發了異常。這時候最有效的辦法不是繼續猜，而是直接回滾到已知穩定版本，先把入口恢復，再慢慢定位觸發條件。

回滾之後，流量開始回來

回滾完成後，我們先看控制器是否還在重啟，確認 Pod 進入穩定狀態，再看 Service Endpoint 是否正常恢復。接著用帶 Host 的 curl 從叢集外部和內部各測一次，確認路由能正確轉發到後端應用。當 503 比例開始下降，大家才算真正鬆了一口氣。

這一步最重要的不是快，而是準。很多事故之所以拖很久，不是因為沒辦法回復，而是因為團隊在止血階段還想同時做根因分析，結果既沒恢復流量，也沒找到原因。正確做法是先讓使用者不再看到錯誤，再把時間花在調查上。

騰訊雲帳號充值辦理 定位根因：不是應用壞了，而是配置和版本撞在一起

一條看似普通的規則，觸發了不穩定行為

最後把問題收斂到一條新加的 Ingress 規則。這條規則包含較複雜的路徑匹配和重寫配置，還附帶了幾個常用註解。單看每一項都不算罕見，但它們組合到一起，再疊加當前 TKE Ingress-Nginx 組件版本的已知問題，就把控制器推到了崩潰邊緣。

實際上，入口元件最怕的不是高流量，而是複雜且頻繁變動的配置。因為它每次都要把整份規則重新整理成可執行配置，只要其中某一段格式、語義或邊界條件不對，就可能導致載入失敗，甚至直接退出。這和業務程式不同，業務程式常常是單點邏輯錯誤，入口元件則是整體配置模型的錯誤，一旦失手，影響面會放大很多倍。

為什麼測試時沒有發現

回頭看，測試環節其實有幾個盲點。第一，測試環境流量小，沒有把完整的路由組合跑透；第二，驗證只看健康檢查和首頁，沒有針對關鍵業務路徑做完整覆蓋；第三，變更流程裡雖然有審核，但沒有專門的人去關注這類入口層風險。結果就是，平時看起來一切正常，一到真實環境和真實配置，問題就被放大了。

還有一個容易被忽略的點，是健康檢查的語義。很多人以為 Pod Ready 就代表可用，實際上它只代表容器能回答探針，不代表整條入口鏈路可用。Ingress-Nginx 的探針可能是通的，但只要配置載入流程出錯，外部流量照樣進不來。這也是為什麼監控一定要看真實請求，而不能只看探針狀態。

復原過程：從 503 回到穩定，靠的是一套順序

先回滾版本，再清理風險配置

復原時我們採取的是雙線處理。第一條線是回滾 Ingress-Nginx 組件版本，保證控制器本身穩住；第二條線是移除或簡化有風險的 Ingress 配置，把複雜規則拆開處理。這樣做的好處是，即使之後要再開新路由，也能在穩定基線上一步一步加回去。

這裡有個很現實的教訓：不要把修復和優化混在同一次操作裡。事故現場最忌諱一口氣做太多事，因為你根本來不及分辨是哪一步真正起作用。回滾、驗證、觀察，這三步做完之後，再考慮是否需要調整路由拆分或增加備援入口，節奏會清楚得多。

驗證不是看一眼頁面就夠了

流量恢復後，我們沒有立刻結案，而是做了完整驗證。先從外部做多輪請求，確認不同域名、不同路徑都能正確返回；再從叢集內部對 Service 進行直連測試，排除應用層隱性問題；最後觀察一段時間的 5xx、重啟次數、配置刷新次數和延遲曲線，確定沒有回彈。

如果只看首頁打得開，事故很可能只是從顯性變成隱性。只有把常用路徑、邊界路徑、錯誤路徑都測一遍，才能確認這次修復是真的穩了。對入口元件來說，穩定不是一次成功，而是持續一段時間都成功。

復盤重點：這次 503 不只是一次故障

入口層要做真正的高可用

第一個教訓是，不要把入口層當成理所當然。很多團隊在應用層做了雙活、限流、熔斷，卻忽略了入口層本身的高可用。Ingress-Nginx 至少要做到多副本、分散節點、避免單點依賴，必要時還要準備替代入口，不能把所有流量都壓在一個控制器組件上。

其次，副本多不代表安全。若多個副本被安排在同一台節點，或者同一個可用區，一旦節點層出問題，效果和單副本差不多。真正的高可用，不只是複製數量，而是故障域要分散，控制器要有反親和，還要有合理的 PDB 和滾動更新策略，避免升級時把自己一口氣推倒。

騰訊雲帳號充值辦理 配置治理要比救火更前置

第二個教訓是，入口配置必須治理。所有 Ingress 規則都應該走審核，尤其是涉及重寫、正則、頭部處理、TLS 轉發、WebSocket 或特殊註解的變更，更要有明確的校驗。最好能把配置檢查前移，在提交階段就過一輪靜態驗證，避免帶著有風險的內容直接進生產。

對於容易觸發版本問題的功能，最穩妥的方式不是一把梭，而是灰度。先在低風險路由上驗證，再逐步擴大覆蓋範圍。就算組件升級，也不要一下子把全部入口都換掉，先保留回滾能力，觀察一段時間後再全面推進。入口層的變更，應該比應用層更保守，而不是更激進。

監控要盯住真實可用性

第三個教訓是，監控不能只看 Pod 是否存活。要補上幾個更有價值的指標：控制器重啟次數、配置刷新失敗率、Nginx reload 次數、5xx 比例、真實請求成功率，以及外部探測的整體可用性。這些指標放在一起看，才能在故障還沒全面擴大前，提前發現入口層的異常苗頭。

特別是 503 這種錯誤，往往不是應用自己吐出來的，而是中間層無法轉發、無法找到上游、或者控制器自身掛掉後給出的統一結果。也就是說，503 不是結論，只是一個表象。要真正定位問題，還得把入口、路由、控制器、後端服務串起來看。

結語：一次搶修，換來一套更成熟的入口思維

這次騰訊雲 TKE Ingress-Nginx 組件崩潰導致全站 503，看起來像一場突發事故，實際上暴露的是一整套入口治理的短板。問題不只在某個版本，也不只在某條配置，而在於我們以前對入口層的風險估計得太輕，對高可用的要求也設得不夠細。

騰訊雲帳號充值辦理 搶修結束後，真正有價值的不是「我們把網站修好了」，而是「我們知道下一次要怎麼避免同樣的事」。把版本鎖住，把配置管住，把入口做成可觀測、可回滾、可分散風險的系統，這才是事故留下來最應該換到的東西。一次 503 不可怕，可怕的是修完之後，什麼都沒變。