Kubernetes에서 다른 Namespace의 Service 호출하는 방법

Kubernetes에서 다른 Namespace의 Service 호출하는 방법

Kubernetes를 운영하다 보면 서로 다른 Namespace에 배포된 애플리케이션 간 통신이 필요한 경우가 많습니다.

예를 들어 다음과 같은 구조를 생각해 보겠습니다.

• frontend Namespace
• backend Namespace

frontend에서 실행 중인 Pod가 backend Namespace에 있는 Service를 호출해야 한다면 어떻게 해야 할까요?

이번 글에서는 Kubernetes에서 다른 Namespace의 Service를 호출하는 방법과 DNS 규칙에 대해 알아보겠습니다.

---

Kubernetes Service DNS 구조

Kubernetes는 Service를 생성하면 내부 DNS를 자동으로 생성합니다.

기본 DNS 형식은 다음과 같습니다.

<Service Name>.<Namespace>.svc.cluster.local

예를 들어 다음과 같은 Service가 있다고 가정해 보겠습니다.

apiVersion: v1
kind: Service
metadata:
  name: user-api
  namespace: backend

그러면 생성되는 DNS는 다음과 같습니다.

user-api.backend.svc.cluster.local

---

같은 Namespace에서는 Service 이름만 사용 가능

만약 Pod와 Service가 같은 Namespace에 있다면 Service 이름만 입력해도 됩니다.

예를 들어 backend Namespace 안에서는 다음과 같이 호출할 수 있습니다.

http://user-api

또는

http://user-api:8080

Kubernetes DNS가 자동으로 같은 Namespace를 검색해 주기 때문입니다.

---

다른 Namespace의 Service 호출하기

다른 Namespace에 있는 Service는 Namespace를 포함해서 호출해야 합니다.

예를 들어

• 호출하는 Pod : frontend
• 대상 Service : backend

라면 다음과 같이 호출합니다.

http://user-api.backend

또는 포트가 있다면

http://user-api.backend:8080

이 방식이 가장 많이 사용됩니다.

---

FQDN(Fully Qualified Domain Name) 사용하기

보다 명확하게 작성하고 싶다면 전체 DNS 이름을 사용할 수도 있습니다.

http://user-api.backend.svc.cluster.local

Kubernetes 내부 DNS는 다음과 같은 계층 구조를 가집니다.

Service Name
      │
      ▼
user-api
      │
Namespace
      ▼
backend
      │
Service Domain
      ▼
svc
      │
Cluster Domain
      ▼
cluster.local

즉,

user-api.backend.svc.cluster.local

은 Kubernetes Cluster 내부에서 항상 동일하게 사용할 수 있는 전체 도메인 이름입니다.

---

실제 예제

Service

apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: cache
spec:
  selector:
    app: redis
  ports:
  - port: 6379

다른 Namespace에서는 다음과 같이 접속합니다.

redis-cli -h redis.cache

또는

redis-cli -h redis.cache.svc.cluster.local

---

DNS 확인 방법

Pod 내부에서 DNS가 정상적으로 등록되었는지 확인하려면 다음 명령어를 사용할 수 있습니다.

kubectl exec -it <pod-name> -- nslookup user-api.backend

또는

kubectl exec -it <pod-name> -- dig user-api.backend

응답이 정상적으로 반환된다면 DNS 설정에는 문제가 없는 것입니다.

---

통신이 되지 않는다면 확인해야 할 사항

다른 Namespace의 Service를 호출했는데 연결되지 않는다면 다음 항목을 확인해 보세요.

1. Service가 존재하는지 확인

kubectl get svc -n backend

---

2. Endpoints 확인

Service에 연결된 Pod가 없다면 통신할 수 없습니다.

kubectl get endpoints -n backend

---

3. NetworkPolicy 확인

Cluster에 NetworkPolicy가 적용되어 있다면 다른 Namespace의 접근이 차단될 수 있습니다.

kubectl get networkpolicy -A

필요한 경우 Namespace 간 통신을 허용하는 정책을 추가해야 합니다.

---

4. Service Port 확인

Service가 노출하는 포트와 실제 애플리케이션 포트가 올바르게 매핑되어 있는지 확인합니다.

kubectl describe svc user-api -n backend

---

정리

Kubernetes에서는 Namespace가 다르더라도 Service DNS를 이용하면 쉽게 통신할 수 있습니다.

• 같은 Namespace
  • http://user-api
• 다른 Namespace
  • http://user-api.backend
• 전체 DNS 사용
  • http://user-api.backend.svc.cluster.local

실무에서는 대부분 서비스명.네임스페이스 형태를 사용하며, 특별한 이유가 없다면 전체 FQDN을 사용할 필요는 없습니다. 다만 여러 클러스터 환경이나 DNS 설정을 명확하게 관리해야 하는 경우에는 FQDN을 사용하는 것이 좋습니다.