從舊版升級為分割健康狀態檢查

自 2019 年 9 月 15 日起，如果您仍然使用舊版健康狀態檢查機制，雖然您的應用程式可以繼續執行並接受健康狀態檢查，但您無法部署新版的應用程式。

本頁面說明如何從舊版健康狀態檢查升級至分割健康狀態檢查。

驗證健康狀態檢查類型

如要驗證應用程式使用的健康狀態檢查類型，請執行下列指令：

gcloud app describe

如果您的應用程式使用的是分割健康狀態檢查，則說明應包含下列資訊：

featureSettings:
    splitHealthChecks: true

瞭解主要差異

升級到分割健康狀態檢查之前，請考量舊版與分割健康狀態檢查之間的以下重要差異：

  • 根據預設，系統不會轉送分割健康狀態檢查的 HTTP 要求。而舊版健康狀態檢查在預設情況下則會轉送至應用程式中的 /_ah/health 路徑。

  • 健康狀態良好時，轉送的分割健康狀態檢查必須傳回 200 OK。舊版健康狀態檢查會將下列 HTTP 代碼視為健康狀態良好：200、301、302、303、307、401、402、403、404、405。

如未指定執行中的檢查路徑或已就緒的檢查路徑，根據預設，分割健康檢查只會確認 VM 執行個體與 Docker 容器正在執行中。只要這些條件成立，VM 就會繼續接收流量，並保持運作，不管應用程式的內部狀態為何。

但如果啟用的是舊版健康狀態檢查，則當應用程式的 /_ah/health 路徑開始傳回健康狀態不良的 HTTP 錯誤代碼 (例如 5XX)，舊版健康狀態檢查就會開始發生失敗，而 VM 也會停止接收流量並重新啟動。

如果應用程式依賴預設的舊版健康狀態來檢查行為，請視情況設定執行中的檢查路徑與已就緒的檢查路徑。

轉換舊版健康狀態檢查選項

每個舊版健康狀態檢查選項都可以轉換成相對應的分割健康狀態檢查，說明如下：

選項 在分割健康狀態檢查中保持相同行為
enable_health_check 若為 True 或未設定，請將 liveness_check.path 與 readiness_check.path 設定為當應用程式健康狀態良好時在應用程式上傳回 200 OK 的路徑。
check_interval_sec 將 liveness_check.check_interval_sec 和 readiness_check.check_interval_sec 設為相同的值。
timeout_sec 將 liveness_check.timeout_sec 和 readiness_check.timeout_sec 設為相同的值。
unhealthy_threshold 將 readiness_check.failure_threshold 設為相同的值。
healthy_threshold 將 liveness_check.success_threshold 和 readiness_check.success_threshold 設為相同的值。
restart_threshold 將 liveness_check.failure_threshold 設為相同的值。請注意，將 check_interval_sec 選項乘以 failure_threshold 選項，所得的值就是移除健康狀態不良的 VM 需要的時間。

啟用分割健康狀態檢查

如要從舊版健康狀態檢查遷移至分割健康狀態檢查，並避免出現數值較高的 5xx 狀態代碼，請完成下列步驟：

  1. 瞭解舊版健康狀態檢查和分割健康狀態檢查之間的重要差異。

  2. 為應用程式的每個版本轉換舊版健康狀態檢查選項。

    您也可以為每個版本自訂 app.yaml 檔案中的 liveness_check 或 readiness_check 區段。如需相關範例，請參閱有效性檢查和就緒檢查。

  3. 執行下列指令：

    gcloud app update --split-health-checks --project [YOUR_PROJECT_ID]

  4. 如果您為舊版健康狀態檢查使用自訂設定，則必須從 app.yaml 檔案移除 health_check 區段。

  5. 部署新的應用程式主要版本，開始使用有效性和就緒健康狀態檢查。