升級為分割健康狀態檢查機制

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

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

驗證健康狀態檢查類型

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

gcloud app describe

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

featureSettings:
    splitHealthChecks: true

瞭解主要差異

升級為分割健康狀態檢查機制之前,請考量舊版健康狀態檢查與分割健康狀態檢查之間的不同,主要差異如下所述:

  • 根據預設,系統不會轉送分割健康狀態檢查的 HTTP 要求。相較之下,舊版健康狀態檢查會根據預設轉送至應用程式中的 /_ah/health 路徑。

  • 健康狀態良好且完備時,轉送的分割健康狀態檢查必須傳回 200 OK 舊版健康狀態檢查會將下列 HTTP 代碼視為健康狀態良好:200301302303307401402403404405

根據預設,如果您未指定有效性檢查路徑完備性檢查路徑,分割健康檢查只會確認 VM 執行個體與 Docker 容器是否正在運作。只要這些條件成立,無論應用程式的內部狀態為何,VM 都會繼續接收流量並維持運作狀態。

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

如果您的應用程式是使用預設的舊版健康狀態檢查行為,請視情況設定有效性檢查路徑完備性檢查路徑

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

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

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

啟用分割健康狀態檢查

如要從舊版健康狀態檢查升級為分割健康狀態檢查,並且避免出現更多的 5xx 錯誤狀態代碼,請完成下列步驟:

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

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

    您也可以為每個版本自訂 liveness_check 檔案中的 readiness_checkapp.yaml 區段。如需相關範例,請參閱有效性檢查完備性檢查

  3. 執行下列指令:

    gcloud app update --split-health-checks --project [YOUR_PROJECT_ID]
  4. 如果您將自訂設定用於舊版健康狀態檢查,則必須從 app.yaml 檔案中移除 health_check 區段。

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