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

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 Proxyのサービス名に置き換えます。
- kong-namespaceをKongがデプロイされている名前空間に置き換えます。
- /svc-b/apiはバックエンドAPIにマッピングされたパスです。

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

### Notes \{#notes}

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