我有一個實例組，其中有 2 個實例位於 HTTP 負載平衡器後面。一個實例正常運作（傳回 http 200），另一個實例崩潰（HTTP 請求逾時）。我不確定我做錯了什麼，但根據文檔，失敗的實例應該會自動從負載平衡器中刪除。
這是相關文件：https://cloud.google.com/compute/docs/load-balancing/health-checks 與相關段落：
為了使健康檢查成功，後端必須傳回代碼為 200 的有效 HTTP 回應，並在 timeoutSec 時間內正常關閉連線。如果執行個體未通過執行狀況檢查，則會將其從群組或池中刪除，且不會傳送任何通知。如果它後來通過了健康檢查，它就會被返回到群組或池中，同樣不會發出任何通知。
以下是我目前在 Google 雲端控制台頁面上看到的 HTTP 負載平衡器後端的內容。
當訪問我的網站時（http://stage2.phantomjscloud.com）大約一半的時間我得到
錯誤：伺服器錯誤 伺服器遇到臨時錯誤，無法完成您的要求。請在 30 秒後重試。
HTTP 負載平衡器（和執行狀況檢查）清楚地偵測到失敗的實例，但無論如何，流量仍然會提供給它。
我該如何解決這個問題？
答案1
運行狀況檢查託管實例組 VS 運行狀況檢查負載平衡
託管實例組使用的運行狀況檢查與負載平衡使用的運行狀況檢查相同，但行為上存在一些差異。應用於負載平衡服務的運作狀況檢查可協助負載平衡器確定將網路流量定向到何處。這些運行狀況檢查不會導致 Compute Engine 重新建立執行個體。您套用於託管實例群組的執行狀況檢查將主動向託管實例群組發出訊號，以便在執行個體變得不健康時刪除並重新建立實例。
對於大多數場景，請使用單獨的運行狀況檢查來實現負載平衡和監控託管執行個體組。負載平衡的運行狀況檢查可以而且應該更加積極，因為這些運行狀況檢查確定實例是否接收用戶流量。由於客戶可能依賴您的服務，因此您希望快速擷取無回應的實例，以便在必要時重新導向流量。相較之下，實例組的運行狀況檢查將導致 Compute Engine 主動替換故障的實例，因此您可以建立比負載平衡器運行狀況檢查更保守的運行狀況檢查。
答案2
我已經有一段時間（大約 6 個月）沒有看到這種錯誤了，所以我認為這是 Google Cloud 的錯誤，他們修復了它。