• 클러스터의 노드 이름과 ip 주소는 조직의 dns 서버에 등록되어 있을 것이다.
• 쿠버네티스는 기본적으로 내장된 dns 서버를 배포한다.

• 서비스가 생성될 떄마다, 쿠버네티스 DNS 서비스는 서비스에 대한 기록, 서비스 이름을 ip 주소에 매핑한다. 따라서, 클러스터 내에서 모든 pod는 이제, 서비스 이름을 이용해 서비스에 도달할 수 있다.
• 일전에 “네트워크 네임스페이스" 에서 배웠다 싶이, 파란색 pod 는 동일한 클러스터에 있는 보라색에게, 서비스 이름의 웹서비스 curl 만으로도 단순히 접근할 수 있다.: curl <http://web-service>
• 만약에 보라색이 혼자 apps 라 불리는 다른 네임스페이스에 혼자 있다면, 기본값에서 참조하기 위해 web-service.apps 라 해야한다. 서비스의 꼬리는 이제, 네임스페이스이다. :curl <http://web-service.apps>
• 각 네임스페이스에 대해 DNS는 하위 도메인을 만들고, 모든 서비스는 svc 라는 하위 도메인에 함께 그룹화된다.

web-service.apps.svc.cluster.local 이 FQDN(Fully Qualified Domain Name) 이다. (= 서비스의 정규화된 도메인 이름이다.)

이것이 클러스터 내에서 서비스가 해결되는 방식이다.

• 그렇다면, pod 는 ?

  

  • pod 에 대한 레코드는 기본적으로 생성되지 않지만, 명시적으로 활성화할 수 있다.
  • 각 pod 에 대해 k8s 는 . 을 대체해서 - 을 이용한 주소를 생성하고, 네임스페이스는 동일하게 유지되고, 유형은 pod 로 설정된다. 루트 도메인은 항상 cluster.local 이다.

    • 마찬가지로, 기본 네임스페이스의 test pod 는 변환된 Ip 와 함께 dns 서버 레코드를 가져온다.

      

Pod DNS Record

<POD-IP-ADDRESS>.<namespace-name>.pod.cluster.local

# example
# Pod is located in a default namespace
10-244-1-10.default.pod.cluster.local

# to create a namespace
$ k create ns apps

# to create a pod
$k run nginx --image=nginx -n apps

# to create the additional information of the pod in the namespace "apps"
$k get po -n apps -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          99s   10.244.1.3   node01   <none>           <none>

# to get the dns record of the nginx pod from the default namespace
$k run -it test --image=busybox:1.28 -rm --restarr=Never -- nslookup 10-244-1-3.apps.pod.cluster.local
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      10-244-1-3.apps.pod.cluster.local
Address 1: 10.244.1.3
pod "test" deleted

# accessing with curl command 
$k run -tit nginx-test --image=nginx -rm --restart=Never -- curl -Is <http://10-244-1-3.apps.pod.cluster.local>
HTTP/1.1 200 OK
Server: nginx/1.19.2