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

OpenShift Container Platform 배포의 경우 다음 구성 요소에 DNS 이름을 확인해야 합니다.

Kubernetes API
OpenShift Container Platform 애플리케이션 와일드카드
부트스트랩, 컨트롤 플레인 및 컴퓨팅 시스템

Kubernetes API, 부트스트랩 시스템, 컨트롤 플레인 시스템 및 컴퓨팅 시스템에 대한 역방향 DNS 확인이 필요합니다.

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

참고

DHCP 서버를 사용하여 각 클러스터 노드에 호스트 이름을 제공하는 것이 좋습니다. 자세한 내용은 사용자 프로비저닝 인프라 섹션에 대한 DHCP 권장 사항 섹션을 참조하십시오.

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

표 5.4. 필수 DNS 레코드
구성 요소	레코드	설명
Kubernetes API	`api.<cluster_name>.<base_domain>.`	API 로드 밸런서를 식별하는 DNS A/AAAA 또는 CNAME 레코드와 DNS PTR 레코드입니다. 이 레코드는 클러스터 외부의 클라이언트와 클러스터 내의 모든 노드에서 확인할 수 있어야 합니다.
Kubernetes API	`api-int.<cluster_name>.<base_domain>.`	내부적으로 API 로드 밸런서를 식별하는 DNS A/AAAA 또는 CNAME 레코드와 DNS PTR 레코드입니다. 이 레코드는 클러스터 내의 모든 노드에서 확인할 수 있어야 합니다. 중요 API 서버는 Kubernetes에 기록된 호스트 이름으로 작업자 노드를 확인할 수 있어야 합니다. API 서버가 노드 이름을 확인할 수 없는 경우 프록시된 API 호출이 실패할 수 있으며 pod에서 로그를 검색할 수 없습니다.
라우트	`*.apps.<cluster_name>.<base_domain>.`	애플리케이션 인그레스 로드 밸런서를 참조하는 와일드카드 DNS A/AAA 또는 CNAME 레코드입니다. 애플리케이션 인그레스 로드 밸런서는 Ingress 컨트롤러 Pod를 실행하는 머신을 대상으로 합니다. Ingress 컨트롤러 Pod는 기본적으로 컴퓨팅 머신에서 실행됩니다. 이 레코드는 클러스터 외부의 클라이언트와 클러스터 내의 모든 노드에서 확인할 수 있어야 합니다. 예를 들어 `console-openshift-console.apps.<cluster_name>.<base_domain>`은 OpenShift Container Platform 콘솔의 와일드카드 경로로 사용됩니다.
부트스트랩 시스템	`bootstrap.<cluster_name>.<base_domain>.`	부트스트랩 머신을 식별하는 DNS A/AAAA 또는 CNAME 레코드와 DNS PTR 레코드입니다. 이 레코드는 클러스터 내의 노드에서 확인할 수 있어야 합니다.
컨트롤 플레인 머신	`<control_plane><n>.<cluster_name>.<base_domain>.`	컨트롤 플레인 노드의 각 머신을 식별하는 DNS A/AAAA 또는 CNAME 레코드와 DNS PTR 레코드입니다. 이 레코드는 클러스터 내의 노드에서 확인할 수 있어야 합니다.
컴퓨팅 머신	`<compute><n>.<cluster_name>.<base_domain>.`	작업자 노드의 각 머신을 식별하는 DNS A/AAAA 또는 CNAME 레코드와 DNS PTR 레코드입니다. 이 레코드는 클러스터 내의 노드에서 확인할 수 있어야 합니다.

참고

OpenShift Container Platform 4.4 이상에서는 DNS 구성에서 etcd 호스트 및 SRV 레코드를 지정할 필요가 없습니다.

작은 정보

dig 명령을 사용하여 이름과 역방향 이름을 확인할 수 있습니다. 자세한 검증 단계는 사용자 프로비저닝 인프라의 DNS 확인 섹션을 참조하십시오.

5.7.1. 사용자 프로비저닝 클러스터의 DNS 구성 예

이 섹션에서는 사용자 프로비저닝 인프라에 OpenShift Container Platform을 배포하기 위한 DNS 요구 사항을 충족하는 A 및 PTR 레코드 구성 샘플을 제공합니다. 샘플은 하나의 DNS 솔루션을 선택하기 위한 조언을 제공하기 위한 것이 아닙니다.

이 예제에서 클러스터 이름은 ocp4이고 기본 도메인은 example.com입니다.

사용자 프로비저닝 클러스터의 DNS A 레코드 구성 예

다음 BIND 영역 파일의 예제에서는 사용자가 프로비저닝한 클러스터의 이름 확인을 위한 샘플 A 레코드를 보여줍니다.

예 5.1. 샘플 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.example.com.		IN	A	192.168.1.5
smtp.example.com.		IN	A	192.168.1.5
;
helper.example.com.		IN	A	192.168.1.5
helper.ocp4.example.com.	IN	A	192.168.1.5
;
api.ocp4.example.com.		IN	A	192.168.1.5 1
api-int.ocp4.example.com.	IN	A	192.168.1.5 2
;
*.apps.ocp4.example.com.	IN	A	192.168.1.5 3
;
bootstrap.ocp4.example.com.	IN	A	192.168.1.96 4
;
control-plane0.ocp4.example.com.	IN	A	192.168.1.97 5
control-plane1.ocp4.example.com.	IN	A	192.168.1.98 6
control-plane2.ocp4.example.com.	IN	A	192.168.1.99 7
;
compute0.ocp4.example.com.	IN	A	192.168.1.11 8
compute1.ocp4.example.com.	IN	A	192.168.1.7 9
;
;EOF

1: Kubernetes API의 이름 확인을 제공합니다. 레코드는 API 로드 밸런서의 IP 주소를 나타냅니다.
2: Kubernetes API의 이름 확인을 제공합니다. 레코드는 API 로드 밸런서의 IP 주소를 참조하며 내부 클러스터 통신에 사용됩니다.
3: 와일드카드 경로의 이름 확인을 제공합니다. 레코드는 애플리케이션 인그레스 로드 밸런서의 IP 주소를 나타냅니다. 애플리케이션 인그레스 로드 밸런서는 Ingress 컨트롤러 Pod를 실행하는 머신을 대상으로 합니다. Ingress 컨트롤러 Pod는 기본적으로 컴퓨팅 머신에서 실행됩니다.
참고
이 예제에서는 Kubernetes API 및 애플리케이션 인그레스 트래픽에 동일한 로드 밸런서를 사용합니다. 프로덕션 시나리오에서는 각각에 대해 개별적으로 로드 밸런서 인프라를 확장할 수 있도록 API 및 애플리케이션 인그레스 로드 밸런서를 별도로 배포할 수 있습니다.
4: 부트스트랩 시스템의 이름 확인을 제공합니다.
5 6 7: 컨트롤 플레인 시스템의 이름 확인을 제공합니다.
8 9: 컴퓨팅 시스템의 이름 확인을 제공합니다.

사용자 프로비저닝 클러스터의 DNS PTR 레코드 구성 예

다음 예제 BIND 영역 파일은 사용자 프로비저닝 클러스터의 역방향 이름 확인을 위한 샘플 PTR 레코드를 보여줍니다.

예 5.2. 역방향 레코드의 샘플 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.
;
5.1.168.192.in-addr.arpa.	IN	PTR	api.ocp4.example.com. 1
5.1.168.192.in-addr.arpa.	IN	PTR	api-int.ocp4.example.com. 2
;
96.1.168.192.in-addr.arpa.	IN	PTR	bootstrap.ocp4.example.com. 3
;
97.1.168.192.in-addr.arpa.	IN	PTR	control-plane0.ocp4.example.com. 4
98.1.168.192.in-addr.arpa.	IN	PTR	control-plane1.ocp4.example.com. 5
99.1.168.192.in-addr.arpa.	IN	PTR	control-plane2.ocp4.example.com. 6
;
11.1.168.192.in-addr.arpa.	IN	PTR	compute0.ocp4.example.com. 7
7.1.168.192.in-addr.arpa.	IN	PTR	compute1.ocp4.example.com. 8
;
;EOF

1: Kubernetes API의 역방향 DNS 확인을 제공합니다. PTR 레코드는 API 로드 밸런서의 레코드 이름을 참조합니다.
2: Kubernetes API의 역방향 DNS 확인을 제공합니다. PTR 레코드는 API 로드 밸런서의 레코드 이름을 참조하며 내부 클러스터 통신에 사용됩니다.
3: 부트스트랩 시스템의 역방향 DNS 확인을 제공합니다.
4 5 6: 컨트롤 플레인 시스템의 역방향 DNS 확인을 제공합니다.
7 8: 컴퓨팅 시스템의 역방향 DNS 확인을 제공합니다.

참고

OpenShift Container Platform 애플리케이션 와일드카드에는 PTR 레코드가 필요하지 않습니다.

5.7.2. 사용자 프로비저닝 인프라에 대한 로드 밸런싱 요구사항

OpenShift Container Platform을 설치하기 전에 API 및 애플리케이션 인그레스 로드 밸런싱 인프라를 프로비저닝해야 합니다. 프로덕션 시나리오에서는 각각에 대해 개별적으로 로드 밸런서 인프라를 확장할 수 있도록 API 및 애플리케이션 인그레스 로드 밸런서를 별도로 배포할 수 있습니다.

참고

RHEL(Red Hat Enterprise Linux) 인스턴스를 사용하여 API 및 애플리케이션 인그레스 로드 밸런서를 배포하려면 RHEL 서브스크립션을 별도로 구입해야 합니다.

로드 밸런서 인프라는 다음 요구 사항을 충족해야 합니다.

API 로드 밸런서: 플랫폼과 상호 작용하고 플랫폼을 구성할 수 있도록 사용자(인간과 시스템 모두)에게 공통 끝점을 제공합니다. 다음 조건을 설정합니다.

Layer 4 로드 밸런싱 전용입니다. 원시 TCP 또는 SSL Passthrough 모드라고 할 수 있습니다.
스테이트리스 로드 밸런싱 알고리즘입니다. 옵션은 로드 밸런서 구현에 따라 달라집니다.

중요

API 로드 밸런서에 대한 세션 지속성을 구성하지 마십시오. Kubernetes API 서버에 대한 세션 지속성을 구성하면 성능 문제가 OpenShift Container Platform 클러스터의 초과 애플리케이션 트래픽 및 클러스터 내에서 실행되는 Kubernetes API가 발생하지 않을 수 있습니다.

로드 밸런서의 전면과 후면 모두에서 다음 포트를 구성하십시오.

표 5.5. API 로드 밸런서
포트	백엔드 시스템(풀 멤버)	내부	외부	설명
`6443`	부트스트랩 및 컨트롤 플레인. 부트스트랩 시스템이 클러스터 컨트롤 플레인을 초기화한 후 로드 밸런서에서 부트스트랩 시스템을 제거합니다. API 서버 상태 검사 프로브에 대한 `/readyz` 끝점을 구성해야 합니다.	X	X	Kubernetes API 서버
`22623`	부트스트랩 및 컨트롤 플레인. 부트스트랩 시스템이 클러스터 컨트롤 플레인을 초기화한 후 로드 밸런서에서 부트스트랩 시스템을 제거합니다.	X		시스템 구성 서버

참고

API 서버가 /readyz 엔드포인트를 해제하는 시점부터 풀에서 API 서버 인스턴스가 제거되는 시점까지 시간이 30초를 넘지 않도록 로드 밸런서를 구성해야 합니다. /readyz가 오류를 반환하거나 정상 상태가 된 후 정해진 시간 안에 끝점이 제거 또는 추가되어야 합니다. 5초 또는 10초의 프로빙 주기(두 번의 성공적인 요청은 정상 상태, 세 번의 요청은 비정상 상태)는 충분한 테스트를 거친 값입니다.

애플리케이션 인그레스 로드 밸런서: 클러스터 외부에서 유입되는 애플리케이션 트래픽에 대한 수신 지점을 제공합니다. 인그레스 라우터에 대한 작업 구성이 OpenShift Container Platform 클러스터에 필요합니다.

다음 조건을 설정합니다.

Layer 4 로드 밸런싱 전용입니다. 원시 TCP 또는 SSL Passthrough 모드라고 할 수 있습니다.
사용 가능한 옵션과 플랫폼에서 호스팅되는 애플리케이션 유형에 따라 연결 기반 또는 세션 기반 지속성이 권장됩니다.

작은 정보

애플리케이션 Ingress 로드 밸런서에서 클라이언트의 실제 IP 주소를 확인할 수 있는 경우 소스 IP 기반 세션 지속성을 활성화하면 엔드 투 엔드 TLS 암호화를 사용하는 애플리케이션의 성능을 향상시킬 수 있습니다.

로드 밸런서의 전면과 후면 모두에서 다음 포트를 구성하십시오.

표 5.6. 애플리케이션 인그레스 로드 밸런서
포트	백엔드 시스템(풀 멤버)	내부	외부	설명
`443`	기본적으로 인그레스 컨트롤러 pod, 컴퓨팅 또는 작업자를 실행하는 시스템입니다.	X	X	HTTPS 트래픽
`80`	기본적으로 인그레스 컨트롤러 pod, 컴퓨팅 또는 작업자를 실행하는 시스템입니다.	X	X	HTTP 트래픽

참고

컴퓨팅 노드가 0인 3-노드 클러스터를 배포하는 경우 Ingress 컨트롤러 Pod는 컨트롤 플레인 노드에서 실행됩니다. 3-노드 클러스터 배포에서 HTTP 및 HTTPS 트래픽을 컨트롤 플레인 노드로 라우팅하도록 애플리케이션 인그레스 로드 밸런서를 구성해야 합니다.

5.7.2.1. 사용자 프로비저닝 클러스터의 로드 밸런서 구성 예

이 섹션에서는 사용자 프로비저닝 클러스터의 로드 밸런싱 요구 사항을 충족하는 API 및 애플리케이션 수신 로드 밸런서 구성 예를 제공합니다. 샘플은 HAProxy 로드 밸런서에 대한 /etc/haproxy/haproxy.cfg 구성입니다. 이 예제에서는 하나의 로드 밸런싱 솔루션을 선택하기 위한 조언을 제공하는 것을 목적으로 하지 않습니다.

이 예제에서는 Kubernetes API 및 애플리케이션 인그레스 트래픽에 동일한 로드 밸런서를 사용합니다. 프로덕션 시나리오에서는 각각에 대해 개별적으로 로드 밸런서 인프라를 확장할 수 있도록 API 및 애플리케이션 인그레스 로드 밸런서를 별도로 배포할 수 있습니다.

참고

HAProxy를 로드 밸런서로 사용하고 SELinux가 enforcing으로 설정된 경우 HAProxy 서비스가 setsebool -P haproxy_connect_any=1을 실행하여 구성된 TCP 포트에 바인딩할 수 있는지 확인해야 합니다.

예 5.3. API 및 애플리케이션 인그레스 로드 밸런서 구성 샘플

global
  log         127.0.0.1 local2
  pidfile     /var/run/haproxy.pid
  maxconn     4000
  daemon
defaults
  mode                    http
  log                     global
  option                  dontlognull
  option http-server-close
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000
listen api-server-6443 1
  bind *:6443
  mode tcp
  option  httpchk GET /readyz HTTP/1.0
  option  log-health-checks
  balance roundrobin
  server bootstrap bootstrap.ocp4.example.com:6443 verify none check check-ssl inter 10s fall 2 rise 3 backup 2
  server master0 master0.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master1 master1.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master2 master2.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
listen machine-config-server-22623 3
  bind *:22623
  mode tcp
  server bootstrap bootstrap.ocp4.example.com:22623 check inter 1s backup 4
  server master0 master0.ocp4.example.com:22623 check inter 1s
  server master1 master1.ocp4.example.com:22623 check inter 1s
  server master2 master2.ocp4.example.com:22623 check inter 1s
listen ingress-router-443 5
  bind *:443
  mode tcp
  balance source
  server worker0 worker0.ocp4.example.com:443 check inter 1s
  server worker1 worker1.ocp4.example.com:443 check inter 1s
listen ingress-router-80 6
  bind *:80
  mode tcp
  balance source
  server worker0 worker0.ocp4.example.com:80 check inter 1s
  server worker1 worker1.ocp4.example.com:80 check inter 1s

1: 포트 6443은 Kubernetes API 트래픽을 처리하고 컨트롤 플레인 시스템을 가리킵니다.
2 4: 부트스트랩 항목은 OpenShift Container Platform 클러스터 설치 전에 있어야 하며 부트스트랩 프로세스가 완료된 후 제거해야 합니다.
3: 포트 22623은 머신 구성 서버 트래픽을 처리하고 컨트롤 플레인 시스템을 가리킵니다.
5: 포트 443은 HTTPS 트래픽을 처리하고 Ingress 컨트롤러 Pod를 실행하는 시스템을 가리킵니다. Ingress 컨트롤러 Pod는 기본적으로 컴퓨팅 머신에서 실행됩니다.
6: 포트 80은 HTTP 트래픽을 처리하고 Ingress 컨트롤러 Pod를 실행하는 머신을 가리킵니다. Ingress 컨트롤러 Pod는 기본적으로 컴퓨팅 머신에서 실행됩니다.
참고
컴퓨팅 노드가 0인 3-노드 클러스터를 배포하는 경우 Ingress 컨트롤러 Pod는 컨트롤 플레인 노드에서 실행됩니다. 3-노드 클러스터 배포에서 HTTP 및 HTTPS 트래픽을 컨트롤 플레인 노드로 라우팅하도록 애플리케이션 인그레스 로드 밸런서를 구성해야 합니다.

작은 정보

HAProxy를 로드 밸런서로 사용하는 경우 HAProxy 노드에서 netstat -nltupe를 실행하여 haproxy 프로세스가 포트 6443, 22623, 443 및 80에서 수신 대기 중인지 확인할 수 있습니다.

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

5.7.1. 사용자 프로비저닝 클러스터의 DNS 구성 예

5.7.2. 사용자 프로비저닝 인프라에 대한 로드 밸런싱 요구사항

5.7.2.1. 사용자 프로비저닝 클러스터의 로드 밸런서 구성 예

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links