쿠버는 기본적으로 클러스터를 설정할 때 내장 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
이다
- full FQDN은,
서비스가 아니라 Pod은 어떨까?
- 기본적으로는, Pod에 대해 DNS 레코드는 생성되지 않는다
- 하지만, 원한다면 자동 레코드 생성을 활성화할 수 있다
- 예를 들어 IP가 10.244.2.5면
10-244-2-5
같이 생성- 풀 FQDN은
10-244-2-5.네임스페이스명.pod.cluster.local
- 풀 FQDN은
- 예를 들어 IP가 10.244.2.5면
실제 구현
모든 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이다.
- 사실 Pods로 배포된다 - 2개가 한 쌍인 Deployment로 배포되기 때문
/etc/coredns/Corefile
설정파일을 이용- 각 행 맨 앞의 errors니, health니, kubernetes니 하는 것은 전부 CoreDNS의 plugin이다
- CoreDNS는 kubernetes 플러그인을 통해 쿠버와 상호작용함?
- 또 여기에서 클러스터의 TLD가 결정됨 (cluster.local)
- 따라서 이 하위에 있는 모든 레코드는 이 TLD하위에 들어가게됨
pods insecure
: Pod에 대해서도 DNS 레코드를 생성하는 옵션 (기본값: 비활성화)proxy . /etc/resolv.conf
: CoreDNS가 모르는 도메인은 기본 네임서버로 넘겨버림
- 또 여기에서 클러스터의 TLD가 결정됨 (cluster.local)
- CoreDNS는 kubernetes 플러그인을 통해 쿠버와 상호작용함?
- 이 설정파일은 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 }
- 각 행 맨 앞의 errors니, health니, kubernetes니 하는 것은 전부 CoreDNS의 plugin이다
다른 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
'콤퓨우터 > 필기: KodeKloud CKA 강의' 카테고리의 다른 글
241. etcd in HA (0) | 2024.05.17 |
---|---|
230. Ingress (0) | 2024.05.17 |
223. Service Networking (0) | 2024.05.17 |
215. CNI Weave (0) | 2024.05.17 |
206. Docker Networking (0) | 2024.05.17 |