5.2.4.2. 사용자 프로비저닝 DNS 요구사항

DNS는 이름 확인 및 역방향 이름 확인에 사용됩니다. DNS A/AAAA 또는 CNAME 레코드는 이름 확인에 사용되며 PTR 레코드는 역방향 이름 확인에 사용됩니다. RHCOS (Red Hat Enterprise Linux CoreOS)는 역방향 레코드를 사용하여 모든 노드의 호스트 이름을 설정하기 때문에 역방향 레코드가 중요합니다. 또한 역방향 레코드는 OpenShift Container Platform이 작동하는 데 필요한 인증서 서명 요청 (CSR)을 생성하는 데 사용됩니다.

사용자 프로비저닝 인프라를 사용하는 OpenShift Container Platform 클러스터에는 다음과 같은 DNS 레코드가 필요합니다. 각 레코드에서 <cluster_name>은 클러스터 이름이고 <base_domain>install-config.yaml 파일에서 지정하는 클러스터 기반 도메인입니다. 전체 DNS 레코드는 <component>.<cluster_name>.<base_domain> 형식입니다.

표 5.19. 필수 DNS 레코드

구성 요소레코드설명

Kubernetes API

api.<cluster_name>.<base_domain>.

DNS A/AAAA 또는 CNAME 레코드와 DNS PTR 레코드를 추가하여 컨트롤 플레인 시스템의 로드 밸런서를 식별합니다. 이 레코드는 클러스터 외부의 클라이언트와 클러스터 내의 모든 노드에서 확인할 수 있어야 합니다.

api-int.<cluster_name>.<base_domain>.

DNS A/AAAA 또는 CNAME 레코드와 DNS PTR 레코드를 추가하여 컨트롤 플레인 시스템의 로드 밸런서를 식별합니다. 이 레코드는 클러스터 내의 모든 노드에서 확인할 수 있어야 합니다.

중요

API 서버는 Kubernetes에 기록된 호스트 이름으로 작업자 노드를 확인할 수 있어야 합니다. API 서버가 노드 이름을 확인할 수 없는 경우 프록시된 API 호출이 실패할 수 있으며 pod에서 로그를 검색할 수 없습니다.

라우트

*.apps.<cluster_name>.<base_domain>.

기본적으로 작업자 노드인 인그레스 라우터 pod를 실행하는 시스템을 대상으로 하는 로드 밸런서를 참조하는 와일드카드 DNS A/AAAA 또는 CNAME 레코드를 추가합니다. 이 레코드는 클러스터 외부의 클라이언트와 클러스터 내의 모든 노드에서 확인할 수 있어야 합니다.

부트스트랩

bootstrap.<cluster_name>.<base_domain>.

DNS A/AAAA 또는 CNAME 레코드와 DNS PTR 레코드를 추가하여 부트스트랩 머신을 식별합니다. 이 레코드는 클러스터 내의 노드에서 확인할 수 있어야 합니다.

마스터 호스트

<master><n>.<cluster_name>.<base_domain>.

컨트롤 플레인 노드 (마스터 노드라고도 함)의 각 머신을 식별하는 DNS A/AAAA 또는 CNAME 레코드와 DNS PTR 레코드입니다. 이 레코드는 클러스터 내의 노드에서 확인할 수 있어야 합니다.

작업자 호스트

<worker><n>.<cluster_name>.<base_domain>.

DNS A/AAAA 또는 CNAME 레코드와 DNS PTR 레코드를 추가하여 작업자 노드의 각 머신을 식별합니다. 이 레코드는 클러스터 내의 노드에서 확인할 수 있어야 합니다.

작은 정보

nslookup <hostname> 명령을 사용하여 이름을 확인할 수 있습니다. dig -x <ip_address> 명령을 사용하여 PTR 레코드에 대한 역방향 이름을 확인할 수 있습니다.

다음 BIND 영역 파일의 예제에서는 이름 확인을 위한 샘플 A 레코드를 보여줍니다. 이 예제의 목적은 필요한 레코드를 표시하는 것입니다. 이 예제에서는 특정 이름 확인 서비스를 선택하기 위한 조언을 제공하는 것을 목적으로 하지 않습니다.

예 5.3. 샘플 DNS 영역 데이터베이스

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
	IN	MX 10	smtp.example.com.
;
;
ns1	IN	A	192.168.1.5
smtp	IN	A	192.168.1.5
;
helper	IN	A	192.168.1.5
helper.ocp4	IN	A	192.168.1.5
;
; The api identifies the IP of your load balancer.
api.ocp4		IN	A	192.168.1.5
api-int.ocp4		IN	A	192.168.1.5
;
; The wildcard also identifies the load balancer.
*.apps.ocp4		IN	A	192.168.1.5
;
; Create an entry for the bootstrap host.
bootstrap.ocp4	IN	A	192.168.1.96
;
; Create entries for the master hosts.
master0.ocp4		IN	A	192.168.1.97
master1.ocp4		IN	A	192.168.1.98
master2.ocp4		IN	A	192.168.1.99
;
; Create entries for the worker hosts.
worker0.ocp4		IN	A	192.168.1.11
worker1.ocp4		IN	A	192.168.1.7
;
;EOF

다음 예제 BIND 영역 파일은 역방향 이름 확인을 위한 샘플 PTR 레코드를 보여줍니다.

예 5.4. 역방향 레코드의 샘플 DNS 영역 데이터베이스

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
;
; The syntax is "last octet" and the host must have an FQDN
; with a trailing dot.
97	IN	PTR	master0.ocp4.example.com.
98	IN	PTR	master1.ocp4.example.com.
99	IN	PTR	master2.ocp4.example.com.
;
96	IN	PTR	bootstrap.ocp4.example.com.
;
5	IN	PTR	api.ocp4.example.com.
5	IN	PTR	api-int.ocp4.example.com.
;
11	IN	PTR	worker0.ocp4.example.com.
7	IN	PTR	worker1.ocp4.example.com.
;
;EOF