본문으로 건너뛰기

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

이 가이드는 동일한 클러스터 환경 내에서 API 게이트웨이를 통해 두 개의 Kubernetes Pod - Pod A (클라이언트)와 Pod B (서버) - 간의 내부 통신을 활성화하는 방법을 설명합니다. API 게이트웨이는 Kubernetes 서비스 이름과 Kong 프록시 규칙을 사용하여 요청을 내부적으로 라우팅합니다.

개념 개요​

  • Pod A: API 요청을 시작하는 클라이언트 Pod입니다.
  • Pod B: API 요청을 수신하고 처리하는 서버 Pod입니다.
  • API Gateway: 서비스 검색 및 헤더 기반 라우팅(콩을 통해)을 사용하여 구성된 규칙에 따라 요청을 라우팅합니다.

이 구성은 동일한 클러스터에서 실행되는 서비스 간의 원활한 내부 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​

  • 이 설정은 내부 DNS를 사용하여 Kubernetes 네트워크 내에서 완전히 작동합니다.
  • Kong Proxy가 대상 서비스 FQDN에 접근할 수 있는지 확인하세요.
  • 관련된 모든 서비스(Kong, Pod A, Pod B)는 서로의 서비스를 DNS 또는 적절한 네트워크 정책을 통해 해결할 수 있는 네임스페이스에 있어야 합니다.