能動的なヘルスチェックは、異常なサービスノードを自動的に非アクティブ化し、ノードが回復すると再度アクティブ化します。これにより、マルチレプリカデプロイにおけるサービスインターフェイスへのルートの可用性が向上します。
手順
ゲートウェイのバージョンが 1.2.1 以降の場合、サービスを作成すると TCP ヘルスチェック機能が自動的に有効になります。
MSE コンソール にログインします。上部のナビゲーションバーで、リージョンを選択します。
左側のナビゲーション ウィンドウで、Cloud-Native Gateway > ゲートウェイリスト を選択します。 [ゲートウェイ] ページで、ゲートウェイの名前をクリックします。
左側のナビゲーションウィンドウで、Routes をクリックします。表示されるページで、[サービス] タブをクリックします。
-
[Services] タブで、目的のサービスを見つけ、[Actions] 列の [Health Check Settings] をクリックします。ヘルスチェックの設定 パネルで ヘルスチェックの有効化 をオンにしてパラメーターを設定し、OK をクリックします。
ヘルスチェック失敗のトラブルシューティング
一般的なシナリオで発生するヘルスチェック失敗のトラブルシューティング
TCP ヘルスチェックと HTTP ヘルスチェックのどちらが失敗したかを判断してください：
-
TCP ヘルスチェックが失敗した場合、サービスノードへの接続を確立できません。以下を確認してください：
-
ノードが存在するかどうかを確認してください。
-
同時接続数が多すぎないかを確認してください。
-
-
HTTP ヘルスチェックが失敗した場合は、まず TCP ヘルスチェックが成功することを確認してください。成功する場合は、cURL や Postman などのツールを使用して、設定されたヘルスチェックパスが有効かどうかを確認してください。
-
バックエンドの ECS インスタンスに Docker がインストールされている場合は、Docker ブリッジネットワークが VPC ネットワークと競合していないか確認してください。デフォルトの Docker ブリッジネットワーク (例：172.17.0.0/16) が、ECS インスタンスが属する VPC ネットワーク (例：172.16.0.0/12) と重複する可能性があります。この重複により、ゲートウェイのヘルスチェックリクエストが誤ってルーティングされます。ECS インスタンスで
route -nコマンドを実行してルートテーブルを確認し、Docker ブリッジネットワークが VPC ネットワークと重複しているかどうかを確認してください。競合を解決するには、/etc/docker/daemon.jsonファイルのbipパラメーターを変更して Docker ブリッジネットワークを変更し (例：192.168.0.1/24)、Docker サービスを再起動して競合が解決されたことを確認してください。
初めてサービスを追加したときに発生するヘルスチェック失敗のトラブルシューティング
以下の操作を順番に実行してください：
-
サービス VPC がゲートウェイ VPC と同じであるか、またはサービス環境が Cloud Enterprise Network (CEN) や物理接続を介してゲートウェイ VPC に接続されているかを確認してください。VPC が異なり、接続されていない場合、ゲートウェイの IP アドレスにアクセスできません。
説明ゲートウェイは、Nacos および ZooKeeper インスタンスに登録されているオンプレミスサービスをサポートしていません。
-
サービス VPC がゲートウェイ VPC と同じであるかを確認してください。VPC が異なり、接続されていない場合、ゲートウェイの IP アドレスにアクセスできません。
-
セキュリティグループの認可が設定されているかを確認してください。サービスソースが Container Service for Kubernetes (ACK) クラスターである場合は、ゲートウェイが ACK クラスターのセキュリティグループに追加されていることを確認してください。詳細については、「セキュリティグループの認可」をご参照ください。
-
異常なゲートウェイがパブリック IP アドレスを使用している場合は、ゲートウェイ VPC でインターネット NAT ゲートウェイが有効になっているかどうかを確認してください。
「Checking」ステータス、または初回プローブ失敗時のトラブルシューティング
クラウドネイティブゲートウェイ上のサービスでは、これは通常、障害ではなく正常な移行状態です。一般的な原因は次のとおりです：
-
バックエンドサービスからの応答が遅延し、最初のプローブがタイムアウトしきい値 (例：2 秒) に近い時間がかかり、ステータスが時間内に更新されません。
-
Pod またはゲートウェイの負荷が高いため、ヘルスチェックが期待される結果を時間内に取得できません。
-
ヘルスチェックが有効になったばかり、またはサービスが登録されたばかりで、プローブサイクルが完了していません。サービスは、連続してプローブが成功した後にのみ正常とマークされます。
しばらくステータスを監視してください。ヘルスチェックが異常なままである場合は、このトピックで説明されている他の方法でトラブルシューティングを続行してください。
ヘルスチェックは成功するがアクセスに失敗する、誤ったプロトコル設定が原因のトラブルシューティング
クラウドネイティブゲートウェイ上の MSE Ingress のアップストリームヘルスチェックが成功してもサービスにアクセスできない場合は、ACK の対応するアプリケーションのプロトコルタイプが正しく設定されているかを確認してください。たとえば、HTTP リクエストは TCP プロトコルを使用する必要があります。プロトコルが誤って UDP に設定されている場合、ヘルスチェックが成功してもアクセスは失敗します。
以下のチェックを実行してください：
-
ルート設定を再保存し、再発行してください。
-
サービスソースで自動リスニングが有効になっているかを確認してください。
-
kubectl describe endpointsコマンドを実行して、サービスエンドポイントの詳細を確認してください。
IPv6 アドレスが原因でヘルスチェックが失敗する場合の FAQ
Q： Pod がすでに IPv6 ポートでリッスンしているのに、MSE ゲートウェイのヘルスチェックが失敗するのはなぜですか？
A： MSE ゲートウェイは、IPv6 リソースのプロキシをサポートしていません。この問題を解決するには、バックエンドのサービス設定を変更し、ipFamilies を IPv4 に設定して、トラフィックが IPv4 を介して送信されるようにします。