Kubernetes의 DNS 규칙

ㅁ 들어가며

 Spring Cloud Gateway에서 http://engine-service로 호출했을 때 실제로 http://engine-service.prod.svc.cluster.local로 접근되는 이유는 Kubernetes의 DNS 규칙과 Spring Cloud Gateway가 Kubernetes 클러스터 내부에서 동작하기 때문이다.

 

ㅁ Kubernetes DNS 규칙

ㅇ Kubernetes 내부에서는 DNS를 다음 우선순위로 해석한다.

1. 서비스명 → 현재 네임스페이스 기준 (engine-service.prod에서 실행 중이면 engine-service.prod.svc.cluster.local)
2. 서비스명.네임스페이스명 → 명시적 네임스페이스
3. 풀 FQDN (서비스.네임스페이스.svc.cluster.local)

ㅇ http://engine-service는 → engine-service.prod.svc.cluster.local로 해석된다.
    (gateway가 prod 네임스페이스에 있다면)

 

 

ㅁ Spring Cloud Gateway 동작 방식

  Spring Cloud Gateway는 일반적으로 DiscoveryClient (예: Kubernetes, Eureka, Consul 등)를 사용하거나, 직접 서비스 이름 기반으로 호출한다. 만약 Spring Cloud Gateway가 Kubernetes 안에서 prod 네임스페이스에 배포되어 있다면,
Java 코드에서 http://engine-service로 호출하면 자동으로 그 네임스페이스의 DNS 컨텍스트(prod)에서 해석된다.

 

 

ㅁ 확인/테스트 방법

ㅇ gateway pod 내부에서 테스트

kubectl exec -it -- curl http://engine-service:PORT
kubectl exec -it -- nslookup engine-service

 

ㅇ gateway 네임스페이스 확인

kubectl get pods -l app=spring-cloud-gateway -o wide

ㅇ pod가 prod에 있다면, http://engine-service는 engine-service.prod.svc.cluster.local으로 해설된다.

 

 

ㅁ 마무리

 

http://engine-service는 Spring Cloud Gateway가 실행 중인 네임스페이스 기준으로 DNS가 해석된다. gateway가 prod 네임스페이스에 있다면, 특별한 설정 없이도 engine-service.prod.svc.cluster.local로 인식된다. 네임스페이스 간 통신이 필요할 경우엔 FQDN을 명시해야 한다.