設定健康狀態檢查

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

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

系統會依據可設定的探測連續成功或失敗次數，判斷個別後端的健康狀態。也就是說，您可以設定連續探測成功的次數，達到這個次數後，後端就會標示為健康狀態良好；您也可以設定連續失敗的次數，達到這個次數後，後端就會標示為健康狀態不良。

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

健康狀態檢查通訊協定

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

• TCP
• HTTP
• HTTPS

選取健康狀態檢查

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

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

健康狀態檢查的運作方式

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

探測

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

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

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

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

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

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

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

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

您也可以使用 gdcloud 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 秒。換句話說，逾時時間長度一律必須小於或等於時間間隔，且逾時時間長度絕不會增加時間間隔。

限制

1. GDC 健康狀態檢查只會服務 VM 端點。
2. 如果負載平衡器設有健康狀態檢查，就無法將 Pod 和 VM 設為混合後端。負載平衡器的端點只能由 Pod 或 VM 組成。目前，負載平衡器的端點只能由 Pod 或 VM 組成。
3. 目前不支援變更負載平衡器和相關聯的健康狀態檢查。