[k8s] 쿠버네티스 Service (Headless / EndPoint / ExternalName)

쿠버네티스 클러스터 안에는 DNS Server가 별도로 존재한다. DNS Server에는 Service의 도메인 이름과 IP가 저장되어 있기 때문에 Pod가 Service1의 도메인을 질의하면 ip를 알려준다.

 

 

만약 Pod가 User1을 질의하면 어떻게 될까?? 

 

내부망에도 DNS서버 구축되어 있을 것이고 내부 서버들이 생겼을 때 해당 이름들이 DNS에 등록된다. Pod가 User1을 찾았을 때 쿠버네티스는 자신의 DNS Server에 User1이 없기 때문에 상위 DNS Server에서 이름을 찾게 되고 ip를 알 수 있다.

 

마찬가지로 외부 네트워크도 같은 메커니즘으로 동작한다. 

 

 

 

Headless

아래 그림과 같이 Pod가 Pod1에 접근하고 싶다면 어떻게 할 수 있을까?

 

headless를 이용하면 DNS Server엔 pod들의 DNS와 IP들이 등록되고 질의를 통해 Pod의 IP를 알아내 접근할 수 있다. 

 

이 DNS Server는 Pod든 Service든 생성되면 자동으로 도메인과 IP가 저장된다. 

 

지정되는 규칙은 아래와 같다. 

# {service의 이름}.{namespace}.{svc}.cluster.local
service1.default.svc.cluster.local

# {Pod의 IP}.{namespace}.{pod}.cluster.local
20-109-5-11.default.pod.cluster.local

 

이러한 규칙을 가지고 만들어진 Domain Name을 FQDN(Fully Qualified Domain Name)이라고 한다. 

 

 

Headless Service는 2가지 설정으로 만들 수 있다. 

1. ClusterIP 속성에 None이라고 지정. 해당 서비스의 IP를 생성하지 않겠다는 것을 의미

2. Pod의 속성에 hostname 지정. domain name을 넣고 subdomain에 service의 이름을 넣어줌.

 

 

이렇게 headless service를 생성 및 연결하게 될 경우, DNS Server에 Service의 IP가 없기 때문에 Service의 이름을 호출하게 되면 연결된 모든 Pod의 IP를 반환해준다. 

그리고 하단에 Pod를 보면 pod의 hostname이 앞에 붙어있고 뒤에는 subdomain이 들어있다. 따라서 pod4.headless1 (hostname.subdomain) 형식으로 접근할 수 있다.

 

 

 

Service 생성 시 ClusterIP일때와 Headless일 때의 차이는 다음과 같다.

Headless에선 Service의 IP가 사라지고 Service가 포함하고있는 Pod들의 IP들이 조회된다. 

 

 

pod에서 다른 pod로 접근하는 테스트를 해보았다. 

 

1. Pod에서 Service를 거쳐 Pod로 요청

apiVersion: v1
kind: Service
metadata:
  name: clusterip1
spec:
  selector:
    svc: clusterip
  ports:
  - port: 80
    targetPort: 8080
    
    
apiVersion: v1
kind: Pod
metadata:
  name: pod1
  labels:
    svc: clusterip
spec:
  containers:
  - name: container
    image: kubetm/app
    
    
apiVersion: v1
kind: Pod
metadata:
  name: request-pod
spec:
  containers:
  - name: container
    image: kubetm/init

 

request pod에서 service로 curl 요청을 보내면 Hostname이 잘 뜨는 걸 확인할 수 있다. 

 

 

2. pod에서 다른 pod로 service를 거치지 않고 요청 보내기

Service와 Pod2개를 생성해준다. 

apiVersion: v1
kind: Service
metadata:
  name: headless1
spec:
  selector:
    svc: headless
  ports:
    - port: 80
      targetPort: 8080    
  clusterIP: None
  -----------------------
apiVersion: v1
kind: Pod
metadata:
  name: pod4
  labels:
    svc: headless
spec:
  hostname: pod-a # hostname 설정
  subdomain: headless1 # service 이름
  containers:
  - name: container
    image: kubetm/app
-----------------------
apiVersion: v1
kind: Pod
metadata:
  name: pod5
  labels:
    svc: headless
spec:
  hostname: pod-b # hostname 설정
  subdomain: headless1 # service 이름
  containers:
  - name: container
    image: kubetm/app

 

nslookup headless1 명령어로 dns에 질의를 해보면 아래와 같이 나온다.

 

DNS Server에도 등록되어있기 때문에 아래와 같이 질의를 해도 해당 Pod의 IP를 확인할 수 있다. 

nslookup headless1
nslookup pod-a.headless1
nslookup pod-b.headless1

 

 

따라서 아래와 같이 curl명령어를 날리면 잘 응답이 온다.

curl pod-a.headless1:8080/hostname
curl pod-b.headless1:8080/hostname

 

 

 

 

 

 

 

Endpoint

사용자 입장에서는 Service와 Pod가 다이렉트로 연결되어 있는 것 같지만, 쿠버네티스 내부적으로는 EndPoint라는 것이 생성되어 연결된다. 

 

쿠버네티스는 Service의 이름과 동일한 이름으로 EndPoint를 설정하고 내부에는 pod의 접속 정보를 저장한다. 그렇기 때문에 이 규칙만 알고 있다면 label/selector을 만들지 않고도 Service와 Pod를 직접 연결시킬 수 있다. 

 

 

이때 IP는 변경 가능성이 있기 때문에 DNS Server를 사용해야 하는데, 이때 사용할 수 있는 것이 ExternalName이다. 

 

 

 

EndPoint 자동 생성, 직접 생성을 비교하기 위해 다음과 같이 테스트를 진행했다. 

 

1. 엔드포인트 자동 생성 확인

apiVersion: v1
kind: Service
metadata:
  name: endpoint1
spec:
  selector:
    svc: endpoint
  ports:
  - port: 8080
  
  
  apiVersion: v1
kind: Pod
metadata:
  name: pod7
  labels:
    svc: endpoint
spec:
  containers:
  - name: container
    image: kubetm/app

 

service의 이름인 endpoint1이라는 이름의 endpoint object가 생성된 것을 확인할 수 있다. 결국 label/selector를 지정하면 쿠버네티스가 service의 이름과 동일한 endpoint를 알아서 만든다는 것을 알 수 있습니다.

 

 

 

2. 엔드포인트 직접 지정

apiVersion: v1
kind: Service
metadata:
  name: endpoint2
spec:
  ports:
  - port: 8080


apiVersion: v1
kind: Pod
metadata:
  name: pod9
spec:
  containers:
  - name: container
    image: kubetm/app
    
    
    
apiVersion: v1
kind: Endpoints
metadata:
  name: endpoint2
subsets:
 - addresses:
   - ip: 192.168.226.109 # 위에서 만들어진 pod의 ip.
   ports:
   - port: 8080

 

 

 

이제 request pod에 접속하여 curl 명령을 날리면 정상적으로 pod가 연결된 것을 확인할 수 있다.

curl endpoint2:8080/hostname

 

 

 

 

ExternalName

Service에 ExternalName이라는 속성을 넣어서 Domain 이름을 추가하면 DNS cache가 내부/외부 DNS Server를 확인하여 IP를 알아낸다. 

 

 

만약 Pod에서 접근하는 사이트가 변경되더라도 Pod는 Service만 가르키고 있다면 따로 재배포 할 필요가 없다.

 

 

 

 

아래와 같이 Service를 생성할 때 ExternalName을 설정해줄 수 있다.

apiVersion: v1
kind: Service
metadata:
 name: externalname1
spec:
 type: ExternalName
 externalName: github.github.io

 

 

 

위와 같이 ExternalName을 설정했다면 Service이름으로 curl요청을 날렸을 때 잘 동작한다. 

curl -O externalname1/kubetm/kubetm.github.io/blob/master/sample/practice/intermediate/service-sample.md