서비스 API 카테고리(ExternalName)

서비스 API 카테고리

컨테이너를 외부에 공개하는 엔드포인트를 제공하는 리소스

- 서비스

   - ClusterIP

 - ExternalIP  (ClusterIP의 한 종류)

   - NodePort

   - LoadBalancer

   - 그 외 서비스 기능

   - Headless (None)

   - ExternalName

   - None-Selector

- 인그레스

 

 

ExternalName 서비스

서비스명의 이름 해석에 있어 외부 도메인으로 CNAME을 반환한다.

사용 용도를 살펴보면, 다른 이름을 설정하고 싶은 경우 클러스터 내부에서의 엔드포인트를 쉽게 변경하고 싶을 경우에 사용한다.

apiVersion: v1
kind: Service
metadata:
  name: sample-externalname
  namespace: default
spec:
  type: ExternalName
  externalName: external.example.com

서비스를 확인하면 ExternalP 부분에 CNAME용 FQDN이 표시된다.

 

# 서비스 목록 표시
$ kubectl get services
NAME			 TYPE	  CLUSTER-IP	 EXTERNAL-IP	     PORT(S)  AGE
sample-externalname  ExternalName   <none>     external.example.com  <none>    5s

그러므로 컨테이너 내부에서는 '서비스명'이나 '서비스명.네임스페이스명.svc.cluster.local'로 정방향 질의를 하면 CNAME이 반환되는 것을 확인할 수 있다.

 

# 일시적으로 파드를 기동하여 ExternalName의 CNAME 이름 해석을 확인
$ kbuectl run --image=amsy810/tools:v2.0 --restart=Never --rm -i testpod \ --command -- dig sample-externalname.default.svc.cluster.local CNAME
...(생략)...
;; ANSWER SECTION:
sample-externalname.default.svc.cluster.local. 30 IN CNAME external.example.com.
...(생략)...

 

외부 서비스와 느슨한 결합(loose coupling) 확보

클러스터 내부에서는 파드와의 통신에 서비스 이름 해석을 사용하여 느슨한 결합을 유지하고 있다.

그리고 SaaS나 IaaS 등 외부에 잇는 서비스를 사용할 때도 가능하면 느슨한 결합으로 구성해야 한다.

 

예를 들어, 애플리케이션 등에 외부의 엔드포인트를 등록해 두면 목적지가 변경되었을 때 애플리케이션 측의 설정 변경이 필요하다. 그런데 ExternalName을 사용하면 목적지가 변경되어도 ExternalName 서비스를 변경하는 것만으로 가능하다.

(클러스터 내부 DNS를 사용한 이름 해석의 결과가 바뀌기 때문)

목적지 변경에 대한 대응을 쿠버네티스 내부에서 끝낼 수 있으므로 외부 서비스와 느슨한 결합을 유지할 수 있다.

 

외부 서비스와 내부 서비스 간의 전환

ExternalName을 사용하면 외부 서비스와의 느슨한 결합을 확보하고 외부 서비스와 쿠버네티스에 배포된 클러스터 내부 서비스와의 전환도 유연하게 할 수 있게 된다. 애플리케이션 측은 서비스의 FQDN(store.default.svc.cluster.local)을 지정해두고 이름 해석이 되면 ExternalName의 CNAME 레코드 또는 ClusterIP의 A레코드가 반환되는 형태가 되어 애플리케이션 측은 변경 없이 내부 서비스와 외부 서비스를 전환할 수 있다. 한 가지 주의사항은 ClusterIP 서비스에서 ExternalName 서비스로 전환할 경우 spec.clusterIP를 명시적으로 공란으로 만들어 두어야 한다는 것이다.

ExternalName 서비스와 ClusterIP 서비스를 전환하는 경우 이 설정을 잊지 않도록 주의해야 한다.