本頁面由 Cloud Translation API 翻譯而成。

設定健康狀態檢查

Google Distributed Cloud (GDC) Air-gapped 提供健康狀態檢查機制，可判斷後端執行個體是否對流量做出適當的回應。本文說明如何為負載平衡器建立及使用健康狀態檢查。

除非另有註明，否則 Google Cloud 健康狀態檢查會由專屬軟體工作執行，並根據健康狀態檢查資源中指定的參數連線至後端。每次嘗試連線的作業稱為「探測」。 Google Cloud 會記錄每次探測是成功還是失敗。

系統會根據可設定的連續探測成功或失敗次數，判斷每個後端的健康狀態。也就是說，您可以設定探測作業連續成功次數，據此將後端標示為健康狀態良好，也可以設定連續失敗次數，據此將後端標示為健康狀態不良。

這個健康狀態會決定後端是否能接收新的要求或連線。健康狀態檢查會找出不健康的後端，這類後端不會透過負載平衡器接收流量。您定義成功探查的條件。詳情請參閱「健康狀態檢查的運作方式」一節。

健康狀態檢查通訊協定

健康狀態檢查支援下列通訊協定：

TCP
HTTP
HTTPS

選取健康狀態檢查

健康狀態檢查必須與負載平衡器的類型和後端類型相容。選取健康狀態檢查時，請考慮下列因素：

通訊協定：GDC 用來探測後端的通訊協定。支援的通訊協定為 TCP、HTTP 和 HTTPS。TCP 通訊協定適用於驗證後端連線的基本健康狀態檢查，而 HTTP 和 HTTPS 通訊協定則為已執行 HTTP 或 HTTPS 工作負載的 VM 提供更精細的健康狀態檢查機制。
通訊埠規格：GDC 用於搭配通訊協定探測後端健康狀態的通訊埠。您必須為健康狀態檢查指定通訊埠。
類別：健康狀態檢查可以是全域或區域。全域健康狀態檢查會涵蓋 GDC 部署的所有可用區，而可用區健康狀態檢查則對應至一個可用區。

健康狀態檢查的運作方式

下列各節說明健康狀態檢查的運作方式。

探測

建立健康狀態檢查時，您可以定義或接受預設設定，控管每個探測器評估相關聯端點健康狀態的頻率。這些設定至關重要，因為負載平衡器會根據您設定的條件，停止將要求轉送至不健康的後端。探測器會持續評估，並在判定後端再次正常運作後，恢復將流量傳送至後端。

請務必注意，健康狀態檢查設定會統一套用至後端服務或目標集區中的所有後端，無法針對各個後端進行設定。

設定旗標	說明	預設值
檢查間隔 `check-interval`	從某個探測系統發出一次探測作業開始，到同一系統發出下一次探測作業開始之間的時間長度 (以秒為單位)。	`5s` (5 秒)
timeoutSec `timeoutSec`	在宣告失敗前，等待探測的時間 (以秒為單位)。	`5s` (5 秒)
healthyThreshold `healthyThreshold`	端點必須連續成功探測的次數，才會被視為健康狀態良好。	2
unhealthyThreshold `unhealthyThreshold`	端點必須連續探測失敗的次數，才會被視為健康狀態不良。	2

HTTP 和 HTTPS 健康狀態檢查的成功標準

如果是 HTTP 和 HTTPS 健康狀態檢查，必須在健康狀態檢查逾時前收到 HTTP 200 (OK) 狀態碼，才算成功。其他 HTTP 回應碼 (包括重新導向，例如 301、302) 則視為不正常。

除了需要 HTTP 200 (OK) 回應代碼外，您還可以：

設定每個健康狀態檢查探測器，將 HTTP 要求傳送至特定要求路徑，而非預設要求路徑 /。
設定每個健康狀態檢查探測器，檢查 HTTP 回應主體中是否有預期回應字串。預期的回應字串只能包含半形的可列印 ASCII 字元，且位於 HTTP 回應內文的前 1,024 個位元組內。

下表列出適用於 HTTP 和 HTTPS 健康狀態檢查的有效 requestPath 和 response 欄位組合。

設定旗標	探測器行為	成功標準
未指定 RequestPath 或 Response	探測器會使用 `/` 做為要求路徑。	僅限 HTTP `200 (OK)` 回應代碼。
同時指定 RequestPath 和 Response	探測器會使用設定的要求路徑。	HTTP `200 (OK)` 回應碼和 HTTP 回應內文的前 1,024 個 ASCII 字元，都必須與預期的回應字串相符。
僅指定「回應」	探測器會使用 `/` 做為要求路徑。	HTTP `200 (OK)` 回應碼和 HTTP 回應內文的前 1,024 個 ASCII 字元，都必須與預期的回應字串相符。
僅指定 RequestPath	探測器會使用設定的要求路徑。	僅限 HTTP `200 (OK)` 回應代碼。

TCP 健康狀態檢查的成功標準

TCP 健康狀態檢查有下列基本成功標準：

如果是 TCP 健康狀態檢查，健康狀態檢查探測器必須在健康狀態檢查逾時前，成功開啟與後端的 TCP 連線。
如果是 TCP 健康狀態檢查，必須透過下列其中一種方式關閉 TCP 連線：
- 健康狀態檢查探測器傳送 FIN 或 RST (重設) 封包。
- 後端傳送 FIN 封包。
- 如果後端傳送 TCP RST 封包，且健康狀態檢查探測器已傳送 FIN 封包，探測可能會視為失敗。

事前準備

如要設定健康狀態檢查探針，您必須具備下列條件：

擁有要設定負載平衡器的專案。詳情請參閱「建立專案」一文。
必要的身分與存取權角色：
- 請要求機構 IAM 管理員授予您「負載平衡器管理員」(load-balancer-admin) 角色。
- 如果是全域 ILB，請要求機構 IAM 管理員授予您全域負載平衡器管理員 (global-load-balancer-admin) 角色。詳情請參閱「預先定義的角色說明」。

建立及管理健康狀態檢查

GDC 支援全域和區域健康狀態檢查。

HealthCheck API

您可以將 HealthCheck 物件設定為全域或可用區層級。全域 HealthCheck 物件用於全域負載平衡器設定，區域 HealthCheck 物件則用於區域負載平衡器設定。這兩種型別的名稱和規格相同。不過，兩者使用的 apiVersion 值和 API 伺服器不同：

區域 apiVersion：networking.gdc.goog
全域 apiVersion：networking.global.gdc.goog

您也可以使用 gcloud CLI 建立及管理健康狀態檢查。

建立全域 `HealthCheck`

以下範例說明如何使用 API 建立 HealthCheck：

  kubectl --kubeconfig GLOBAL_ORG_ADMIN_CLUSTER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.global.gdc.goog/v1 
  kind: HealthCheck 
  metadata: 
    namespace: PROJECT 
    name: my-hc 
  spec: 
    httpHealthCheck: 
      port: PORT 
      host: HOST 
      requestPath: requestPath 
      response: responseT 
  EOF

建立可用區 `HealthCheck`

以下範例說明如何使用 API 建立 HealthCheck：

  kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.gdc.goog/v1
  kind: HealthCheck
  metadata:
    namespace: PROJECT
    name: my-hc
  spec:
    httpHealthCheck:
      port: PORT
      host: HOST
      requestPath: requestPath 
      response: response 
  EOF

如要將健康狀態檢查連結至負載平衡器，請參閱下列說明：

設定驗證

為確保設定正確無誤，請驗證 HealthCheck 物件的 Ready 條件。這個條件表示有任何設定錯誤。此外，請確認欄位正確反映必要的HealthCheck設定。

其他使用須知

以下各節提供在 Google Cloud上使用健康狀態檢查的其他注意事項。

憑證和健康狀態檢查

對於需要後端憑證的通訊協定 (例如 HTTPS)，

憑證可以自行簽署，也可以來自任何憑證授權單位 (CA)。
過期或未來的日期皆可。

標頭

設定 HTTP 或 HTTPS 通訊協定的健康狀態檢查時，您可以使用 --host 標記指定 HTTP Host 標頭。

請務必注意，負載平衡器只會將您設定的自訂要求標頭新增至用戶端要求，不會新增至健康狀態檢查探測。因此，如果後端需要授權專用的標頭，但健康狀態檢查封包中沒有，健康狀態檢查可能會失敗。

健康狀態檢查範例

如果健康狀態檢查設定了下列參數：

間隔：30 秒
逾時：5 秒
通訊協定：HTTP
不良健康狀態判定門檻：2 (預設)
健康狀態良好判定門檻：2 (預設值)

健康狀態檢查的運作方式如下：

每個健康狀態檢查探測器都會：
1. 每 30 秒從來源 IP 位址啟動與後端執行個體的 HTTP 連線。
2. 等待最多五秒，讓 HTTP 200 (OK) 狀態碼傳回 (HTTP 和 HTTPS 通訊協定的指定成功標準)。
如果至少有一個健康狀態檢查探測系統執行下列操作，後端就會被視為健康狀態不良：
1. 由於連線遭拒、連線逾時或通訊端逾時，連續兩次探測都未收到 HTTP 200 (OK) 回應。
2. 連續收到兩則不符合通訊協定特定成功條件的回覆。
如果至少有一個健康狀態檢查探測系統連續收到兩次符合通訊協定特定成功條件的回應，後端就會被視為健康狀態良好。

在本例中，每個探測器每 30 秒會啟動一次連線。無論逾時時間長度 (連線是否逾時)，探測器每次嘗試連線之間都會間隔 30 秒。換句話說，逾時時間長度不得超過時間間隔，且逾時不會增加時間間隔。

限制

GDC 健康狀態檢查只會為 VM 端點提供服務。
如果負載平衡器設有健康狀態檢查，就無法將 Pod 和 VM 設為混合後端。負載平衡器的端點只能是 Pod 或 VM。目前負載平衡器的端點只能是 Pod 或 VM。
目前不支援負載平衡器和相關聯健康狀態檢查的可變動性。