tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。
原文としたのEnvoyのドキュメントはこちらのディレクトリ以下にあります（ライセンス：Apache License 2.0, NOTICE）。
ヘルスチェック
アクティブヘルスチェックは、アップストリームクラスタごとに設定できます。サービス検出のセクションで説明したように、アクティブヘルスチェックとEDSサービス検出の種類は密接に関係しています。ただし、他の種類のサービス検出を使用している場合でも、アクティブヘルスチェックが必要なシナリオは他にもあります。 Envoyは3つの異なるタイプのヘルスチェックをさまざまな設定（チェック間隔、ホストに異常とマークする前に必要な失敗、ホストに正常とマークする前に必要な成功など）をサポートします。
- HTTP： HTTPヘルスチェック中に、EnvoyはHTTPリクエストを上流のホストに送信します。デフォルトでは、ホストが正常であれば200応答を期待します。予期される応答コードは構成可能です。それ以上トラフィックを転送しないようにダウンストリームホストに直ちに通知したい場合、アップストリームホストは503を返すことができます。
- L3 / L4： L3 / L4ヘルスチェック中に、Envoyは設定可能なバイトバッファをアップストリームホストに送信します。ホストが正常であると見なされる場合は、応答でバイトバッファがエコーされることを想定しています。 Envoyはまた接続のみL3 / L4ヘルスチェックをサポートします。
- Redis： EnvoyはRedis PINGコマンドを送信し、PONG応答を待ちます。アップストリームのRedisサーバーはPONG以外のもので応答して、即時アクティブヘルスチェックに失敗する可能性があります。オプションで、Envoyはユーザー指定のキーに対してEXISTSを実行できます。キーが存在しない場合は、合格ヘルスチェックと見なされます。これにより、ユーザーは指定されたキーを任意の値に設定し、トラフィックが枯渇するのを待つことで、Redisインスタンスにメンテナンスのマークを付けることができます。 redis_keyを参照してください。
クラスタメンバーごとのヘルスチェック設定
アップストリームクラスタに対してアクティブヘルスチェックが設定されている場合は、ClusterLoadAssignmentで定義されている各LocalityLbEndpointのLbEndpointのEndpointにHealthCheckConfigを設定することで、登録された各メンバに対して特定の追加設定を指定できます。
ヘルスチェック設定を設定してクラスタメンバーの代替ヘルスチェックポートを設定する例は次のとおりです。
load_assignment：
endpoints：
- lb_endpoints：
- endpoint：
health_check_config：
port_value：8080
address：
socket_address：
アドレス：localhost
port_value：80
ヘルスチェックイベントログ
HealthCheck設定でログファイルのパスを指定することにより、ヘルスチェック担当者ごとの排出および追加イベントのログをオプションで作成できます。ログは、HealthCheckEventメッセージのJSONダンプとして構造化されています。
always_log_health_check_failuresフラグをtrueに設定することで、Envoyはすべてのヘルスチェック失敗イベントをログに記録するように設定できます。
受動的健康チェック
Envoyはまた、異常値検出による受動的ヘルスチェックもサポートしています。
接続プールの相互作用
詳しくはこちらをご覧ください。
HTTPヘルスチェックフィルタ
Envoyメッシュがクラスタ間でアクティブヘルスチェックを使用して展開されると、大量のヘルスチェックトラフィックが生成される可能性があります。 Envoyには、設定済みのHTTPリスナーにインストールできるHTTPヘルスチェックフィルタが含まれています。このフィルタは、いくつかの異なる動作モードが可能です。
- パススルーなし： このモードでは、ヘルスチェック要求はローカルサービスに渡されません。 Envoyは、現在のサーバーの排水状態に応じて、200または503で応答します。
- アップストリームクラスタの正常性から計算されたパススルーなし： このモードでは、1つ以上のアップストリームクラスタで少なくとも指定された割合のサーバーが使用可能（正常+劣化）かどうかに応じて、正常性チェックフィルタは200または503を返します。 （ただし、Envoyサーバーが枯渇状態にある場合は、アップストリームクラスターの正常性に関係なく503で応答します。）
- パススルー： このモードでは、Envoyはすべてのヘルスチェック要求をローカルサービスに渡します。サービスはその健康状態に応じて200または503を返すことが期待されています。
- キャッシュを使用してパススルー： このモードでは、Envoyはヘルスチェック要求をローカルサービスに渡しますが、その後一定期間結果をキャッシュします。後続のヘルスチェック要求では、キャッシュされた値がキャッシュ時間まで返されます。キャッシュ時間に達すると、次のヘルスチェック要求がローカルサービスに渡されます。これは、大きなメッシュを操作するときに推奨される操作モードです。 Envoyはヘルスチェックトラフィックに持続的な接続を使用し、ヘルスチェック要求はEnvoy自体にかかるコストはほとんどありません。したがって、この動作モードでは、多数のヘルスチェック要求でローカルサービスに負担をかけることなく、各アップストリームホストのヘルス状態に関する最終的に一貫したビューが得られます。
さらに進んだ情報
- Health check filter configuration.
- /healthcheck/fail admin endpoint.
- /healthcheck/ok admin endpoint.
アクティブヘルスチェックの速い失敗
アクティブヘルスチェックとパッシブヘルスチェック（異常値検出）を併用する場合、大量のアクティブヘルスチェックトラフィックを回避するために長いヘルスチェック間隔を使用するのが一般的です。この場合、/ healthcheck / fail管理エンドポイントを使用しているときに、上流のホストをすばやく排出できると便利です。これをサポートするために、ルータフィルタはx-envoy-immediate-health-check-failヘッダに応答します。このヘッダがアップストリームホストによって設定されている場合、Envoyはアクティブヘルスチェックのために失敗したものとしてそのホストを直ちにマークします。これは、ホストのクラスタにアクティブヘルスチェックが設定されている場合にのみ発生することに注意してください。 Envoyが/ healthcheck / fail管理エンドポイントで失敗とマークされている場合、ヘルスチェックフィルタは自動的にこのヘッダを設定します。
ヘルスチェックID
アップストリームホストが特定のヘルスチェックURLに応答することを確認しただけでは、アップストリームホストが有効であるとは限りません。たとえば、クラウドの自動スケーリングまたはコンテナ環境で最終的に一貫したサービス検出を使用する場合、ホストが去ってから同じIPアドレスを使用して戻ってくることは可能ですが、別のホストタイプとして可能です。この問題に対する1つの解決策は、サービスの種類ごとに異なるHTTPヘルスチェックURLを用意することです。このアプローチの欠点は、すべてのヘルスチェックURLが完全にカスタムなので、全体的な設定がより複雑になることです。
Envoy HTTPヘルスチェッカーはservice_nameオプションをサポートします。このオプションが設定されている場合、ヘルスチェッカーはx-envoy-upstream-healthchecked-clusterレスポンスヘッダーの値をservice_nameと比較します。値が一致しない場合、ヘルスチェックはパスしません。アップストリームヘルスチェックフィルタは、応答ヘッダーにx-envoy-upstream-healthchecked-clusterを追加します。追加される値は--service-clusterコマンドラインオプションによって決まります。
健康の低下
HTTPヘルスチェッカーを使用している場合、アップストリームホストはx-envoy -gradededを返して、ホストが劣化していることをヘルスチェッカーに通知できます。これが負荷分散に与える影響については、こちらを参照してください。