[Retry, k8s] 17. 서비스 API - ExternalName

[Retry, k8s] 17. 서비스 API - ExternalName

---

🔔 ExternalName

이 서비스는 외부에서 접근하기 위한 것이 아니라, 내부 파드가 외부의 특정 FQDN에 쉽게 접근하기 위한 서비스

• 이 서비스는 외부의 특정 FQDN에 대한 CNAME (서비스의 FQDN)을 제공함으로써 해당 CNAME을 이용하여 쉽게 통신할 수 있다.

📜 ExternalName 서비스 생성

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

$ kubectl get service
NAME                  TYPE           CLUSTER-IP   EXTERNAL-IP            PORT(S)   AGE
sample-externalname   ExternalName   <none>       external.example.com   <none>    9s

# 일시적으로 파드를 기동하여 ExternalName의 CNAME 이름 해석을 확인
$ kubectl 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 서비스를 변경하는 것만으로 가능하다.

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

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

ExternalName을 사용하면 외부 서비스와의 느슨한 결합을 확보하고, 외부 서비스와 쿠버네티스에 배포된 클러스터 내부 서비스와의 전환도 유연하게 할 수 있게 된다.

• 애플리케이션 측은 서비스의 FQDN(store.default.svc.cluster.local)을 지정해 두고 이름 해석이 되면 ExternalNamedml CNAME 레코드 또는 ClusterIP의 A 레코드가 반환되는 형태가 되어 애플리케이션 측은 변경 없이 내부 서비스와 외부 서비스를 전환할 수 있다.

• 주의할 점은 ClusterIP 서비스에서 ExternalName 서비스로 전환할 겨우 spec.clusterIP를 명시적으로 공란으로 만들어 두어야 한다는 것이다.

KUBERNETES 카테고리 내 다른 글 보러가기