健康檢查

主動健康檢查可以針對每個上游叢集進行設定。如服務發現章節所述，主動健康檢查和 EDS 服務發現類型是緊密相關的。但是，即使使用其他服務發現類型，在其他情況下也需要主動健康檢查。Envoy 支援三種不同的健康檢查類型，以及各種設定 (檢查間隔、將主機標記為不健康之前所需的失敗次數、將主機標記為健康之前所需的成功次數等等)。

• HTTP：在 HTTP 健康檢查期間，Envoy 將向上游主機發送 HTTP 請求。預設情況下，如果主機健康，它會預期收到 200 回應。預期的和可重試的回應代碼是可設定的。如果上游主機想要立即通知下游主機不再將流量轉發給它，則它可以傳回非預期或不可重試的狀態代碼 (預設情況下為任何非 200 代碼)。

• gRPC：在 gRPC 健康檢查期間，Envoy 將向上游主機發送 gRPC 請求。預設情況下，如果主機健康，它會預期收到 200 回應。gRPC 健康檢查可在此設定。

• L3/L4：在 L3/L4 健康檢查期間，Envoy 將向上游主機發送可設定的位元組緩衝區。如果主機要被視為健康，它會預期在回應中回顯位元組緩衝區。Envoy 也支援僅連線的 L3/L4 健康檢查。

• Redis：Envoy 將發送 Redis PING 命令，並預期收到 PONG 回應。上游 Redis 伺服器可以使用 PONG 以外的任何內容來回應，以導致立即主動健康檢查失敗。或者，Envoy 可以在使用者指定的鍵上執行 EXISTS。如果該鍵不存在，則視為通過健康檢查。這允許使用者將指定的鍵設定為任何值，並等待流量耗盡，以將 Redis 執行個體標記為維護狀態。請參閱redis_key。

• Thrift：Envoy 將發送 Thrift 請求，並預期收到成功回應。上游主機也可以回應例外狀況，以導致健康檢查失敗。請參閱thrift。

健康檢查發生在為叢集指定的傳輸插槽上。這意味著如果叢集使用啟用 TLS 的傳輸插槽，則健康檢查也將透過 TLS 進行。可以指定用於健康檢查連線的TLS 選項，如果對應的上游使用基於 ALPN 的FilterChainMatch，針對健康檢查和資料連線使用不同的協定，這會很有用。

每個叢集成員的健康檢查設定

如果為上游叢集設定了主動健康檢查，則可以透過在 Endpoint 的 HealthCheckConfig 中設定，為每個已註冊的成員指定特定的其他設定，LbEndpoint 的每個已定義LocalityLbEndpoints 在 ClusterLoadAssignment 中。

設定健康檢查設定的範例，以設定叢集成員的替代健康檢查位址和連接埠為

load_assignment:
  endpoints:
  - lb_endpoints:
    - endpoint:
        health_check_config:
          port_value: 8080
          address:
            socket_address:
              address: 127.0.0.1
              port_value: 80
        address:
          socket_address:
            address: localhost
            port_value: 80

健康檢查事件記錄

透過在HealthCheck 設定 event_log_path中指定日誌檔案路徑，Envoy 可以選擇性地產生每個健康檢查器的彈出和新增事件日誌。日誌結構化為HealthCheckEvent 訊息的 JSON 轉儲。

注意：HealthCheck 設定 event_log_path已棄用，改用HealthCheck event_logger 擴充功能。event_log_path用於 JSON 轉儲的檔案接收器擴充功能。

建立新的事件接收器擴充功能目錄 envoy.health_check.event_sinks，API 可以在這裡找到。

可以透過將always_log_health_check_failures 旗標設定為 true，將 Envoy 設定為記錄所有健康檢查失敗事件。

被動健康檢查

Envoy 也透過離群值偵測支援被動健康檢查。

連線池互動

如需詳細資訊，請參閱此處。

HTTP 健康檢查過濾器

當 Envoy 網格部署在叢集之間具有主動健康檢查時，可能會產生大量的健康檢查流量。Envoy 包含一個 HTTP 健康檢查過濾器，可以安裝在已設定的 HTTP 監聽器中。此過濾器能夠以幾種不同的操作模式執行

• 不傳遞：在此模式下，健康檢查請求永遠不會傳遞到本機服務。Envoy 將根據伺服器的目前耗盡狀態，回應 200 或 503。

• 不傳遞，從上游叢集健康狀況計算：在此模式下，健康檢查過濾器將傳回 200 或 503，具體取決於是否至少有指定百分比的伺服器在一個或多個上游叢集中可用 (健康 + 降級)。(但是，如果 Envoy 伺服器處於耗盡狀態，則無論上游叢集健康狀況如何，它都將回應 503。)

• 傳遞：在此模式下，Envoy 將每個健康檢查請求傳遞到本機服務。服務預期會根據其健康狀態，傳回 200 或 503。

• 傳遞並快取：在此模式下，Envoy 會將健康檢查請求傳遞到本機服務，然後快取結果一段時間。後續的健康檢查請求將傳回快取值，直到快取時間到期。當達到快取時間時，下一個健康檢查請求將傳遞到本機服務。這是操作大型網格時建議的操作模式。Envoy 會針對健康檢查流量使用持續連線，而健康檢查請求對 Envoy 本身幾乎沒有任何成本。因此，此操作模式會產生每個上游主機健康狀態的最終一致檢視，而不會讓本機服務被大量健康檢查請求淹沒。

延伸閱讀

• 健康檢查過濾器設定。

• /healthcheck/fail 管理端點。

• /healthcheck/ok 管理端點。

主動健康檢查快速失敗

當使用主動健康檢查與被動健康檢查（離群值偵測）時，通常會使用較長的健康檢查間隔，以避免產生大量的主動健康檢查流量。在這種情況下，當使用 /healthcheck/fail 管理介面端點時，仍然能夠快速地排空上游主機是非常有用的。為了支援此功能，路由篩選器和 HTTP 主動健康檢查器都會回應 x-envoy-immediate-health-check-fail 標頭。如果上游主機設定了這個標頭，Envoy 會立即將該主機標記為健康檢查失敗，並將其從負載平衡中排除。請注意，這只會在主機的叢集已設定主動健康檢查時發生。健康檢查篩選器會自動設定此標頭，如果 Envoy 已透過 /healthcheck/fail 管理介面端點標記為失敗。

健康檢查身分

僅僅驗證上游主機是否回應特定的健康檢查 URL 並不一定表示該上游主機是有效的。例如，當在雲端自動擴展或容器環境中使用最終一致的服務發現時，主機可能會消失，然後以相同的 IP 位址重新出現，但作為不同的主機類型。解決這個問題的一個方法是為每個服務類型使用不同的 HTTP 健康檢查 URL。這種方法的缺點是，由於每個健康檢查 URL 都是完全客製化的，因此整體配置會變得更加複雜。

Envoy HTTP 健康檢查器支援 service_name_matcher 選項。如果設定此選項，健康檢查器還會將 x-envoy-upstream-healthchecked-cluster 回應標頭的值與 service_name_matcher 進行比較。如果值不匹配，則健康檢查不會通過。上游健康檢查篩選器會將 x-envoy-upstream-healthchecked-cluster 附加到回應標頭。附加的值由 --service-cluster 命令列選項決定。

降級的健康狀態

當使用 HTTP 健康檢查器時，上游主機可以回傳 x-envoy-degraded 來通知健康檢查器該主機已降級。請參閱這裡以了解這如何影響負載平衡。