226-227. DNS and CoreDNS in Kubernetes

쿠버는 기본적으로 클러스터를 설정할 때 내장 DNS 서버를 디플로이한다

• 단, 수동 구축했을 경우 이것도 수동으로 설정해주어야함

클러스터의 다른 노드에 Pod A와 B가 있다고 하자

• A: IP 10.244.1.5
• B: IP 10.244.2.5
  • Service b-service: 10.107.37.188

IP 대역이 다르므로, A와 B는 서로 다른 노드에 있을 것이다 - 하지만 별 상관이 없다, 쿠버가 정상적으로 설정되었다면 모든 클러스터 내의 Pod끼리는 스스로의 IP로 통신을 할 수 있어야 한다

하지만, 대부분의 경우, b에 대한 Service를 만들어 이것으로 통신을 한다 (이 경우 b-service (NodePort, etc.))

• Service가 생성되면, 쿠버 DNS 서비스가 해당 서비스에 대한 레코드를 생성한다
  • A b-service 10.107.37.188
  • 이를 통해 다른 Pod에서 해당 서비스의 이름을 통해 B Pod에 접속할 수가 있다

같은 Namespace상에서는, 그냥 서비스명으로도 접근이 가능하다

• 하지만 다른 네임스페이스의 Pod이라면, 서비스명.네임스페이스명 식으로 접근해야한다
  • full FQDN은, 서비스명.네임스페이스명.svc.cluster.local이다

서비스가 아니라 Pod은 어떨까?

• 기본적으로는, Pod에 대해 DNS 레코드는 생성되지 않는다
• 하지만, 원한다면 자동 레코드 생성을 활성화할 수 있다
  • 예를 들어 IP가 10.244.2.5면 10-244-2-5 같이 생성
    • 풀 FQDN은 10-244-2-5.네임스페이스명.pod.cluster.local

실제 구현

모든 Pod의 컨테이너의 /etc/hosts에 필요한 모든 DNS 엔트리를 때려박아 수동관리하는 것은 조금 힘겨운 일이다

• 쿠버는 중앙 DNS 서버를 만들어 DNS 엔트리를 관리하고, 모든 Pod 컨테이너의 /etc/resolv.conf에 해당 DNS 서버의 IP를 집어넣는다

이 "중앙 DNS 서버"는 구버전에서는 kube-dns였으나, 쿠버 1.12부터는 CoreDNS로 변경되었다

• CoreDNS는 클러스터에 Pod으로 배포된다
  • 사실 Pods로 배포된다 - 2개가 한 쌍인 Deployment로 배포되기 때문
    • 아무튼 Pod은 Pod이다.
• /etc/coredns/Corefile 설정파일을 이용
  • 각 행 맨 앞의 errors니, health니, kubernetes니 하는 것은 전부 CoreDNS의 plugin이다
    • CoreDNS는 kubernetes 플러그인을 통해 쿠버와 상호작용함?
      • 또 여기에서 클러스터의 TLD가 결정됨 (cluster.local)
        • 따라서 이 하위에 있는 모든 레코드는 이 TLD하위에 들어가게됨
      • pods insecure: Pod에 대해서도 DNS 레코드를 생성하는 옵션 (기본값: 비활성화)
      • proxy . /etc/resolv.conf: CoreDNS가 모르는 도메인은 기본 네임서버로 넘겨버림
  • 이 설정파일은 Pod에 ConfigMap으로 전달됨

    .:53 {
    errors
    health
    kubernetes cluster.local in-addr.arpa ip6.arpa {
     pods insecure
     fallthrough in-addr.arpa ip6.arpa
     ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf {
     max_concurrent 1000
    }
    cache 30
    loop
    reload
    loadbalance
    }

다른 Pod들은 어떻게 CoreDNS 서버에 DNS쿼리를 쏘는가?

• 자동 생성된 Service를 이용
  • 기본값은 kube-dns
  • 이 서비스의 IP가 새로 생성되는 Pod에 대해 기본 resolver (네임서버)로 들어가게 됨

이걸 누가 설정해주는가?

• 대 황 k u b e l e t

Kubelet 설정파일을 보면 이것을 담당하는 설정파일인 clusterDNS와 clisterDomain 엔트리를 볼 수 있다

짧은 형태의 도메인

그런데 host나 nslookup으로 짧은 형태의 도메인 (예를 들어 b-service)를 쿼리해 보면, 반환값이 FQDN이 되는 것을 볼 수 있다

# kubectl exec hr -- nslookup mysql.payroll
Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   mysql.payroll.svc.cluster.local
Address: 10.102.178.7

왜째서인가?

• 기본적으로 Pod에 설정되는 resolv.conf 내용은 네임서버만 있는 것이 아니다
• search default.svc.cluster local svc.cluster.local cluster.local
• 따라서 자동으로 긴 형태의 도메인이 쿼리될수있는것이다

A search domain is a domain used as part of a domain search list. The search list, as well as the local domain name, is used by a resolver to create a fully qualified domain name (FQDN) from a relative name.1 For this purpose, the local domain name functions as a single-item search list.
-Wikipedia