2018년 3월 1일 목요일

Red Hat OCP 3.5 DNS 분석

Red Hat OCP 3.5 DNS 분석

이 문서는 OpenShift Cluster Platform 3.5 설치로 구성되는 OpenShift Cluster 의 DNS 구조를 분석합니다.

OCP 클러스터 서버 구성도

설명에 사용되는 OCP 클러스터 서버 구성도는 아래와 같습니다.

OCP 클러스터 네트워크 구성도

설명에 사용되는 OCP 클러스터의 네트워크 구성은 아래와 같습니다.

OCP DNS 메커니즘 분석

설치 전

master1 노드

/etc/resolv.conf

# Generated by NetworkManager 	
search 		example.com
nameserver 192.168.181.5

eth0 정보

['ipv4' 설정 값]  
ipv4.method: manual  
ipv4.dns: 192.168.181.5  
ipv4.dns-search: example.com  
ipv4.dns-options: (기본값)  
ipv4.dns-priority: 0  
ipv4.addresses: 192.168.181.11/24  
ipv4.gateway: 192.168.181.2  
ipv4.routes:  
ipv4.route-metric: -1  
ipv4.ignore-auto-routes: no  
ipv4.ignore-auto-dns: no  
ipv4.dhcp-client-id: --  
ipv4.dhcp-timeout: 0  
ipv4.dhcp-send-hostname: yes  
ipv4.dhcp-hostname: --  
ipv4.dhcp-fqdn: --  
ipv4.never-default: no  
ipv4.may-fail: yes  
ipv4.dad-timeout: -1(기본값)

node1 노드

/etc/resolv.conf

# Generated by NetworkManager
search example.com
nameserver 192.168.181.5

eth0 정보

['ipv4' 설정 값]  
ipv4.method: manual  
ipv4.dns: 192.168.181.5  
ipv4.dns-search: example.com  
ipv4.dns-options: (기본값)  
ipv4.dns-priority: 0  
ipv4.addresses: 192.168.181.21/24  
ipv4.gateway: 192.168.181.2  
ipv4.routes:  
ipv4.route-metric: -1  
ipv4.ignore-auto-routes: no  
ipv4.ignore-auto-dns: no  
ipv4.dhcp-client-id: --  
ipv4.dhcp-timeout: 0  
ipv4.dhcp-send-hostname: yes  
ipv4.dhcp-hostname: --  
ipv4.dhcp-fqdn: --  
ipv4.never-default: no  
ipv4.may-fail: yes  
ipv4.dad-timeout: -1(기본값)

설치 후

master1 노드 분석

OCP 설치 중 발생되는 변경

  • OCP 설치 후 master1 노드에 dnsmasq DNS 서버(53)와 skyDNS DNS 서버(8053)가 실행 됨
  • OCP 설치 후 resolv.conf 정보가 변경됨
  • OCP 설치 후 원래 nameserver “192.168.181.5”는 마스터 노드 자신의 IP로 변경됨, OCP가 설치 중 마스터 서버에 강제로 dnsmasq DNS 서버를 설치하기 때문임.
  • OCP 설치 후 NetworkManager가 기동하는 99-origin-dns.sh 파일이 /etc/NetworkManager/dispatcher.d/에 추가됨
  • 원래 마스터 서버의 nameserver 정보가 이동되는 위치는 아래 문서 참조

/etc/resolv.conf

# Generated by NetworkManager
search example.com
nameserver 192.168.181.21
\# nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.sh

/etc/dnsmasq.conf

…
# Include another lot of configuration options.
#conf-file=/etc/dnsmasq.more.conf
conf-dir=/etc/dnsmasq.d
  • OCP 설치 후 dnsmasq 서비스가 참조하는 아래 파일이 생성됨

/etc/dnsmasq.d/origin-dns.conf

no-resolv
domain-needed
server=/cluster.local/172.30.0.1
  • no-resolv: OCP DNS 메커니즘에서는 node 서버의 resolv.conf 는 사용하지 않음
  • domain-needed: 도메인 이름 없는 DNS 질의는 허용하지 않음
  • server=/cluster.local/172.30.0.1 : cluster.local 의 와일드 카드 주소는 172.30.0.1 임

Master 서버에서 OCP 설치 전 사용된 DNS 주소는 OCP 설치 후 2차 DNS 질의 주소가 됨

/etc/dnsmasq.d/origin-upstream-dns.conf

server=192.168.181.5

node1 노드 분석

  • node1 서버에는 dnsmasq DNS 서버(53)만 실행 됨
  • resolv.conf 정보가 변경됨
  • OCP 설치 후 원래 node 서버의 nameserver “192.168.181.5”는 노드 서버 자신의 IP로 변경됨, OCP가 설치 중 노드 서버에 강제로 dnsmasq DNS 서버를 설치하기 때문임.
  • OCP 설치 후 NetworkManager가 기동하는 99-origin-dns.sh 파일이 /etc/NetworkManager/dispatcher.d/에 추가됨
  • 원래 노드 서버의 nameserver 정보가 이동되는 위치는 아래 문서 참조

/etc/resolv.conf

# Generated by NetworkManager
search example.com
nameserver 192.168.181.21
# nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.sh

/etc/dnsmasq.conf

…
# Include another lot of configuration options.
#conf-file=/etc/dnsmasq.more.conf
conf-dir=/etc/dnsmasq.d
  • OCP 설치 후 dnsmasq 서비스가 참조하는 아래 파일이 생성됨

/etc/dnsmasq.d/origin-dns.conf

no-resolv
domain-needed
server=/cluster.local/172.30.0.1
  • no-resolv: OCP DNS 메커니즘에서는 node 서버의 resolv.conf 는 사용하지 않음
  • domain-needed: 도메인 이름 없는 DNS 질의는 허용하지 않음
  • server=/cluster.local/172.30.0.1 : cluster.local 의 와일드 카드 주소는 172.30.0.1 임
  • Master 서버에서 OCP 설치 전 사용된 DNS 주소는 OCP 설치 후에는 2차 DNS 질의 주소가 됨

/etc/dnsmasq.d/origin-upstream-dns.conf

server=192.168.181.5

POD DNS 분석

OCP 설치 후 lab7 프로젝트에 실성한 pod의 resolv.conf 는 다음과 같습니다.

/etc/resolv.conf

search lab7.svc.cluster.local svc.cluster.local cluster.local  example.com
nameserver 192.168.181.21
nameserver 192.168.181.21  
options ndots:5
  • 첫번째 nameserver는 /etc/origin/node/node-config.yaml 파일에 지정된 dnsIP의 값에서 유래합니다. node-config.yaml는 OCP 설치 과정에서 생성되는 것 같습니다.
  • 두번째 nameserver는 node 서버의 resolv.conf에서 유래합니다. 그런데 여기서 문제는 OCP 설치 전 노드 서버의 resolv.conf 에서 유래하는 것이 아니라, OCP 설치 후 변경된 노드 서버의 resolv.conf에서 유래함으로 첫번째 nameserver와 동일한 IP 주소를 갖는다는 점입니다. 합리적으로 OCP 설치 전 노드 서버 nameserver 정보가 입력돼야 할 것인데, OCP 설치 과정에서 변형한 nameserver 정보가 다시 입력된다는 것은 논리적으로 이상합니다. 노드 서버의 dnsmasq 도 OCP가 설치한 서비스이고 DNS 이름 검색에도 참여 합니다.
  • lab7.svc.cluster.local 는 pod 가 실행되는 프로젝트에서 유래합니다. 이 예는 lab7 프로젝트 내 생성한 pod 이므로 search 항목에 lab7.svc.cluster.local 가 포함되었습니다.
  • svc.cluster.local cluster.local 는 node-config.yaml의 cluster.local 에 따라 자동 추가되는 domain name 항목입니다.
  • example.com 은 node 서버의 resolve.conf에서 유래한 domain name 항목입니다. 이 항목은 사설 IP의 기본 domain 이름으로 활용됩니다.
  • OpenShift Container Platform 3.5 Installation and Configuration page 17을 참조하여 주십시오.

내부 Service IP 주소 얻기

  1. Pod 내 애플리케이션이 “registry-console.default” 이름의 IP 주소를 시스템 콜을 이용해 요청한다고 가정합니다. 이 경우 registry-console 는 Pod 이름이고 default는 프로젝트 이름입니다.

  2. Pod 의 resolv.conf 에 등록되는 정보는 다음과 같습니다.

    1. 192.168.181.21(1차 nameserver) : Node 서버
    2. /etc/origin/node/node-conf.yaml 의 dnsIP 에서 유래
    3. 192.168.181.21(2차 nameserver) : Node 서버 /etc/resolv.conf 의 namesever 에서 유래
    4. 첫번째 search : pod project name + svc + Node 서버 /etc/origin/node/node-conf.yaml 의 dnsDomain (cluster.local) 에서 유래
    5. 두번째 search: svc + Node 서버 /etc/origin/node/node-conf.yaml 의 dnsDomain (cluster.local) 에서 유래
    6. 세번째 search: Node 서버 /etc/origin/node/node-conf.yaml 의 dnsDomain (cluster.local) 에서 유래
    7. 네번째 search: Node 서버 /etc/resolv.conf 의 search (example.com) 에서 유래

  3. Pod 시스템은 애플리케이션에서 요청 받은 DNS 질의(registry-console.default)를 Pod 의 resolv.conf search 설정에 따라 다음 이름으로 DNS 이름을 조합하여 Node 서버(192.168.181.21)의 dnsmasq 에게 아래 목록의 DNS 이름들을 질의합니다.

    1. registry-console.default.lab7.svc.cluster.local
    2. registry-console.default.svc.cluster.local
    3. registry-console.default.cluster.local
    4. registry-console.default.example.com

  4. Node 서버(192.168.181.21)의 dnsmasq는 캐시에 없는 경우 cluster.local 로 종료되는 DNS 질의는 dnsmasq.conf의 와일드카드가 cluster.local 을 가리키는 kubernetes(172.30.0.1) 서비스로 다시 질의합니다.

  5. kubernetes(172.30.0.1:53) 서비스는 SkyDNS 서버(192.168.181.11:8053)로 패킷을 포워딩합니다.

  6. SkyDNS 서버(192.168.181.11:8053)는 kubernetes(172.30.0.1) 서비스에게 질의들 중 부합하는 “registry-console.default.svc.cluster.local” 의 IP 주소 172.30.145.119 를 응답합니다.

  7. kubernetes(172.30.0.1) 서비스는 Pod(192.168.181.21) dnsmasq DNS 서버에게 결과를 반환합니다.

  8. Pod(192.168.181.21) dnsmasq DNS 서버는 Pod 애플리케이션에게 “registry-console.default” 의 응답 IP 주소 172.30.145.119를 반환합니다.

  9. OCP 클러스터의 kubernetes 서비스는 다음과 같이 같습니다.

$ oc describe svc -n default kubernetes
Name: kubernetes
Namespace: default
Labels: component=apiserver
provider=kubernetes
Selector: <none>
Type: ClusterIP
IP: 172.30.0.1
Port: https 443/TCP
Endpoints: 192.168.181.11:8443
Port: dns 53/UDP
Endpoints: 192.168.181.11:8053
Port: dns-tcp 53/TCP
Endpoints: 192.168.181.11:8053
Session Affinity: ClientIP

참고)
OpenShift DNS
DNS Pods and Services

외부 IP 주소 얻기

  1. Pod 내 애플리케이션이 “master1.example.com” 이름의 사설 DNS IP 주소를 시스템 콜을 이용해 요청한다고 가정합니다.
  2. 애플리케이션의 DNS 질의 도메인이 Pod 의 resolv.conf 의 search 에 나열된 example.com 이 포함되므로 Pod 는 Node 서버(192.168.181.21)의 dnsmasq 에게 즉시 DNS 이름을 질의합니다.
  3. Node 서버(192.168.181.21)의 dnsmasq는 요청 질의의 결과가 캐시나 설정(/etc/hosts)에 없는 경우 DNS 질의를 Node 서버(192.168.181.21)의 origin-upstream-dns.conf 에 지정된 Upstream DNS 서버(192.168.181.5)에 다시 질의합니다.
  4. Upstream DNS 서버(192.168.181.5)(ns 서버)의 dnsmasq 는 자신의 DNS 캐시나 설정(/etc/hosts)을 참조해 “master1.example.com” 의 IP 주소 192.168.181.11 을 Pod(192.168.181.21) dnsmasq 에게 반환합니다.
  5. Pod(192.168.181.21) dnsmasq 는 Pod 에게 “master1.example.com” 의 응답 IP 주소 192.168.181.11를 반환합니다.
  6. Pod 는 애플리케이션에게 IP 주소 192.168.181.11 를 반환합니다.
  7. 찾을 수 없는 경우 Upstream DNS 서버(192.168.181.5)의 resolv.conf 등 나열된 Public DNS(8.8.8.8) 서버 등에 다시 질의합니다.
시간: 댓글 없음:
피드 구독하기: 글 (Atom)