コンテンツにスキップ
|
Kong Gateway
3.4.x LTS
report-issue問題を報告する
旧バージョンのドキュメントを参照しています。 最新のドキュメントはこちらをご参照ください。

ヘルスチェックプローブ

このチュートリアルでは、Kong Gatewayがユーザーのリクエストに対応する準備ができているかどうかを確実に判断できるノードのreadinessエンドポイントの使用方法を説明します。

準備状況チェックエンドポイントは、 Kong Gateway の準備ができたときに 200 OK 応答を返します。そうでないときには 503 サービスが一時的に利用できません 応答を返します。 これはロードバランサや、 Kong Gateway インスタンスの準備状況を監視する必要があるその他のツールに便利です。 Kong Gateway の準備ができていない場合、エンドポイントは message フィールドで応答し、準備ができていない理由が返されます。 これは、ユーザーがノードの準備ができているべきではないことを期待する状況をデバッグするのに役立ちます。

注： Readinessエンドポイントは、ノードのステータスの詳細な情報を返しません。

ヘルスチェックの種類

Kong Gateway ノードごとに、2 つの異なるヘルスチェック（「プローブ」とも呼ばれる）があります。

  • Liveness : Kong Gateway が実行されている場合/statusエンドポイントは200 OKステータスで応答します。リクエストは 500 Internal Server Errorで失敗するか、Kong Gateway が実行されていない場合は応答がありません。 GETリクエストを送信して、Kong Gatewayインスタンスのライブ性を確認できます。

    # Replace localhost:8100 with the appropriate host and port for
# your Status API server
  
curl -i http://localhost:8100/status

  • Readiness : Kong Gateway が有効な設定をロードし、プロキシトラフィックの準備ができている場合、/status/readyエンドポイントは200 OKステータスで応答します。リクエストは 503 Service Temporarily Unavailableで失敗するか、Kong Gateway がまだプロキシトラフィックの準備ができていない場合は応答しません。 GETリクエストを送信して、Kong Gateway インスタンスの準備状況を確認できます。

    # Replace localhost:8100 with the appropriate host and port for
# your Status API server
  
curl -i http://localhost:8100/status/ready

Kong Gatewayのこれら2種類のヘルスチェックは、Kubernetesがヘルスチェックプローブを定義する方法に基づいてモデル化されています。

トラフィックを送信する前に、コンポーネント（ロードバランサー）が readiness ヘルスチェックを実行することを強くお勧めします。これにより、Kong Gateway ノードは正常に起動しただけでなく、構成のロードも完了し、プロキシトラフィックを受信できるようになります。

liveness ヘルスチェックは、readiness ヘルスチェックよりも先に200 OKのレスポンスを返すことがあります。 Kong Gateway が実行中であっても、完全な構成をまだロードしている可能性があります。これは、生存状態ではあるものの準備状態ではないことを意味します。 コンポーネントが liveness プローブのみを監視して Kong Gateway にトラフィックを送信するタイミングを決定する場合、Kong Gateway がトラフィックをプロキシする準備が整うまでのわずかな時間の間に、リクエストが 404 Not Found のレスポンスを返されることがあります。 特に本番環境では、liveness プローブよりも readiness プローブを使用することをお勧めします。

ノードのReadinessエンドポイントの理解

ステップに飛び込む前に ノード準備エンドポイントの目的と、 Kong Gateway インスタンスが準備可能かどうかを決定する方法を理解することが重要です。 エンドポイントはノードの種類によって異なります。

従来モードで次の条件がすべて満たされる場合、エンドポイントは200 OKを返します。

  1. データベースへの接続が成功しました
  2. すべての Kong Gateway ワーカーはリクエストをルーティングする準備ができています
  3. すべてのルートとサービスは、そのプラグインでリクエストを処理する準備が整っていること

ハイブリッドモード（data_planeロール）またはDB-lessモードでは、次の条件が満たされるとエンドポイントは200 OKを返します。

  1. Kong Gateway は有効かつ空でない設定をロードしました kong.yaml
  2. すべての Kong Gateway ワーカーはリクエストをルーティングする準備ができています
  3. すべてのルートとサービスは、要求を処理するためのプラグインの準備ができています

ハイブリッドモード（control_planeロール）では、次の条件が満たされると、このエンドポイントは200 OKを返します。

  1. データベースへの接続が成功しました

ノードのreadinessエンドポイントの有効化

ノードのreadinessエンドポイントを使用するには、status_listen 設定パラメータでStatus APIサーバー（デフォルトでは無効）を有効にしていることを確認してください。

例kong.conf :

status_listen = 0.0.0.0:8100

注： Readinessプローブは、スタンドアロン、コントロールプレーン（CP）、データプレーン（DP）の各ノードを含むクラスタ内のすべてのノードで使用されます。クラスタ内のノードを1つのみチェックするだけでは不十分です。

ノードの readiness エンドポイントの使用

ノードの readiness エンドポイントを有効にしたら、GET リクエストを送信して Kong Gateway インスタンスの readiness 状態を確認できます。

# Replace localhost:8100 with the appropriate host and port for
# your Status API server

curl -i http://localhost:8100/status/ready

レスポンスコードが200の場合、 Kong Gatewayインスタンスはリクエストを処理する準備ができています。

HTTP/1.1 200 OK
Date: Thu, 04 May 2023 22:00:52 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Access-Control-Allow-Origin: *
Content-Length: 19
X-Kong-Admin-Latency: 3
Server: kong/3.3.0

{
  "message": "ready"
}

応答コードが503の場合、 Kong Gatewayインスタンスは正常ではないか、またはリクエストを処理する準備ができていません。

HTTP/1.1 503 Service Temporarily Unavailable
Date: Thu, 04 May 2023 22:01:11 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Access-Control-Allow-Origin: *
Content-Length: 43
X-Kong-Admin-Latency: 3
Server: kong/3.3.0

{
  "message": "failed to connect to database"
}

HTTP/1.1 503 Service Temporarily Unavailable
Date: Thu, 04 May 2023 22:06:58 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Access-Control-Allow-Origin: *
Content-Length: 70
X-Kong-Admin-Latency: 16
Server: kong/3.3.0

{
  "message": "no configuration available (empty configuration present)"
}

Kubernetesでのreadinessプローブの使用

Kubernetes または Helm を使用している場合は、新しいノードの readiness エンドポイントを使用するように readiness プローブ構成を更新する必要がある場合があります。構成ファイルの readinessProbe セクションを次のように変更します。

readinessProbe:
    httpGet:
        path: /status/ready
        # Make sure to replace the port number with the one you
        # configured for the Status API Server.
        port: 8100
    initialDelaySeconds: 10
    periodSeconds: 5

注意: initialDelaySecondsを設定しないと、構成を完全に読み込むのに少し時間がかかるため、Kong Gatewayがクラッシュループに陥る可能性があります。遅延する時間は、構成のサイズによって異なります。

バージョン 3.2 以前で準備状況チェックを使用する

/status/ready エンドポイントはバージョン3.3で追加されたため、以前のバージョンでは、この組み込みの準備エンドポイントのメリットを享受できません。これらのバージョンでは、次の回避策をお勧めします。

  1. この目的用に一意に設定されたパスを使用して、Kong Gatewayに新しいルートを構成します。このルートにはサービスは必要ありません。

    たとえば、パス/health/readyを使用できます。

  2. HTTP 200ステータスコードでそのルートに対するリクエストに返答するようにRequest Terminationプラグインを構成します。

注： この回避策では、ヘルスチェックリクエストを送信するポートは、ステータスAPIポートではなくプロキシポート（デフォルトでは8000 & 8443）です。

ヘルスチェックの対象外

ヘルスチェックプローブでは、以下の点は考慮されません。

  • Kong Gatewayが最適に機能しているかどうか
  • 何らかの理由で Kong Gateway が断続的な障害を引き起こしている場合
  • Kong Gatewayが DNS、クラウドプロバイダーの停止、ネットワーク障害などのサードパーティシステムによりエラーをスローしている場合
  • アップストリームサービスがエラーを出したり、応答が遅すぎる場合

関連項目

Kong Gateway と関連トピックの詳細については、以下のリソースを参照してください。