Skip to main content

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

This guide explains how to enable internal communication between two Kubernetes Pods - Pod A (Client) and Pod B (Server) - through the API Gateway within the same cluster environment. The API Gateway routes the requests internally using Kubernetes service names and Kong proxy rules.

Concept Overview​

  • Pod A: The client pod that initiates the API request.
  • Pod B: The server pod that receives and processes the API request.
  • API Gateway: Routes requests based on configured rules using service discovery and header-based routing (via Kong).

This configuration enables seamless internal API calls between services running in the same cluster, ensuring scalability and service abstraction.

Step-by-Step Configuration​

Register Pod B’s Service as API Backend​

When creating the API in the APIM Console, specify Pod B’s Kubernetes Service FQDN as the Backend URL. This FQDN ensures the gateway can internally route traffic to the appropriate service.

Example Backend 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’s Kubernetes service name.
  • apim: Namespace of Pod B.
  • svc.cluster.local: Default cluster domain.
  • 8081: Service port exposed by Pod B.

This backend registration enables the API GW to route traffic to Pod B using internal DNS-based service discovery.

Make Request via Kong Proxy from Pod A​

After API registration, Pod A can call the exposed API by accessing Kong Proxy’s internal service address and setting the correct Host header. Kong routes the request to Pod B accordingly.

Sample Request:

curl -H "Host: `<desired-host>`" \
http://`<KONG_PROXY_SERVICE>`.`<kong-namespace>`.svc.cluster.local/svc-b/api
  • Replace desired-host with the hostname registered in the API configuration.
  • Replace KONG_PROXY_SERVICE with your Kong Proxy’s service name.
  • Replace kong-namespace with the namespace where Kong is deployed.
  • /svc-b/api is the path mapped to the backend API.

The Host header determines which route in Kong will be triggered. Ensure it matches the route registered during API creation.

Notes​

  • This setup works entirely within the Kubernetes network using internal DNS.
  • Ensure that Kong Proxy has access to the destination service FQDN.
  • All involved services (Kong, Pod A, Pod B) must be in namespaces that can resolve each other’s services via DNS or appropriate network policies.