メインコンテンツまでスキップ

Internal communication method between K8s Pod A and Pod B via API GW

このガイドでは、同じクラスター環境内でAPIゲートウェイを介して2つのKubernetesポッド - Pod A (クライアント) と Pod B (サーバー) - の間で内部通信を有効にする方法を説明します。APIゲートウェイは、Kubernetesサービス名とKongプロキシルールを使用してリクエストを内部的にルーティングします。

概念の概要​

  • Pod A: APIリクエストを開始するクライアントポッド。
  • Pod B: APIリクエストを受信し処理するサーバーポッド。
  • API Gateway: サービスディスカバリーとヘッダーに基づくルーティング（Kong経由）を使用して、構成されたルールに基づいてリクエストをルーティングします。

この構成により、同じクラスター内で実行されているサービス間でシームレスな内部API呼び出しが可能になり、スケーラビリティとサービスの抽象化が確保されます。

ステップバイステップの構成​

Pod BのサービスをAPIバックエンドとして登録​

APIMコンソールでAPIを作成する際に、Pod BのKubernetes Service FQDN をバックエンドURLとして指定します。このFQDNにより、ゲートウェイは適切なサービスに内部的にトラフィックをルーティングできます。

バックエンドURLの例:

[http://svc-apim-gateway-manager.apim.svc.cluster.local:8081](http://svc-apim-gateway-manager.apim.svc.cluster.local:8081/)
  • svc-apim-gateway-manager: Pod BのKubernetesサービス名。
  • apim: Pod Bのネームスペース。
  • svc.cluster.local: デフォルトのクラスタードメイン。
  • 8081: Pod Bによって公開されるサービスポート。

このバックエンド登録により、API GWは内部DNSベースのサービスディスカバリーを使用してPod Bにトラフィックをルーティングできます。

Pod AからKongプロキシ経由でリクエストを行う​

API登録後、Pod AはKongプロキシの内部サービスアドレスにアクセスし、正しいHostヘッダーを設定することで公開されたAPIを呼び出すことができます。KongはリクエストをPod Bに適切にルーティングします。

サンプルリクエスト:

curl -H "Host: `<desired-host>`" \
http://`<KONG_PROXY_SERVICE>`.`<kong-namespace>`.svc.cluster.local/svc-b/api
  • desired-hostをAPI構成で登録されたホスト名に置き換えます。
  • KONG_PROXY_SERVICEをKongプロキシのサービス名に置き換えます。
  • kong-namespaceをKongがデプロイされているネームスペースに置き換えます。
  • /svc-b/apiはバックエンドAPIにマッピングされたパスです。

Hostヘッダーは、Kongでどのルートがトリガーされるかを決定します。API作成時に登録されたルートと一致することを確認してください。

注意事項​

  • このセットアップは、内部DNSを使用してKubernetesネットワーク内で完全に機能します。
  • Kongプロキシが宛先サービスのFQDNにアクセスできることを確認してください。
  • 関与するすべてのサービス（Kong、Pod A、Pod B）は、DNSまたは適切なネットワークポリシーを介して互いのサービスを解決できるネームスペースに存在する必要があります。