2.2. 환경 요구 사항
다음 섹션에서는 OpenShift Container Platform 구성이 포함된 환경의 요구 사항을 정의합니다. 여기에는 Git 리포지토리 액세스, 스토리지 및 클라우드 인프라 공급자와 같은 외부 서비스에 대한 네트워킹 고려 사항 및 액세스가 포함됩니다.
2.2.1. DNS 요구 사항
OpenShift Container Platform에는 환경에 완전히 작동하는 DNS 서버가 필요합니다. 이는 DNS 소프트웨어를 실행하는 별도의 호스트이며 플랫폼에서 실행되는 호스트 및 컨테이너에 이름 확인을 제공할 수 있습니다.
각 호스트의 /etc/hosts 파일에 항목을 추가하는 것만으로는 충분하지 않습니다. 이 파일은 플랫폼에서 실행 중인 컨테이너에 복사되지 않습니다.
OpenShift Container Platform의 주요 구성 요소는 컨테이너 내부에서 실행되며 이름 확인을 위해 다음 프로세스를 사용합니다.
- 기본적으로 컨테이너는 호스트에서 DNS 구성 파일(/etc/resolv.conf)을 수신합니다.
- 그러면 OpenShift Container Platform에서 Pod의 첫 번째 이름 서버를 노드의 IP 주소로 설정합니다.
OpenShift Container Platform 3.2부터 dnsmasq 는 모든 마스터 및 노드에 자동으로 구성됩니다. Pod는 노드를 DNS로 사용하고 노드는 요청을 전달합니다. 기본적으로 dnsmasq 는 포트 53에서 수신 대기하도록 노드에 구성되므로 노드는 다른 유형의 DNS 애플리케이션을 실행할 수 없습니다.
NetworkManager 는 dnsmasq 를 DNS IP 주소로 채우려면 시스템에서 자동으로 네트워크에 연결할 수 있도록 감지 및 구성을 제공하는 프로그램이 필요합니다.
NM_CONTROLLED
는 기본적으로 yes
로 설정됩니다. NM_CONTROLLED
가 no
로 설정된 경우 NetworkManager 디스패치 스크립트에서 관련 origin-upstream-dns.conf dnsmasq 파일을 생성하지 않으며 dnsmasq를 수동으로 구성해야 합니다.
마찬가지로, PEERDNS
매개변수가 네트워크 스크립트에서 no
로 설정된 경우(예: /etc/sysconfig/network-scripts/ifcfg-em1 )는 생성되지 않으며 Ansible 설치가 실패합니다. PEERDNS
설정이 yes
로 설정되어 있는지 확인합니다.
다음은 DNS 레코드의 예입니다.
master1 A 10.64.33.100 master2 A 10.64.33.103 node1 A 10.64.33.101 node2 A 10.64.33.102
DNS 환경이 제대로 작동하지 않는 경우 다음과 같이 오류가 발생할 수 있습니다.
- 참조 Ansible 기반 스크립트를 통한 제품 설치
- 인프라 컨테이너(registry, 라우터) 배포
- IP 주소를 통해 액세스할 수 없으므로 OpenShift Container Platform 웹 콘솔에 대한 액세스 권한
2.2.1.1. DNS를 사용하도록 호스트 구성
해당 환경의 각 호스트가 DNS 서버의 호스트 이름을 확인하도록 구성되어 있는지 확인합니다. 호스트의 DNS 확인 구성은 DHCP가 활성화되어 있는지 여부에 따라 다릅니다. DHCP가 있는 경우:
- 비활성화한 다음 네트워크 인터페이스를 정적으로 구성하고 NetworkManager에 DNS 이름 서버를 추가합니다.
- 그런 다음 NetworkManager 디스패치 스크립트는 DHCP 구성에 따라 DNS를 자동으로 구성합니다.
DNS 서버에서 호스트를 확인할 수 있는지 확인하려면 다음을 수행하십시오.
/etc/resolv.conf 의 내용을 확인합니다.
$ cat /etc/resolv.conf # Generated by NetworkManager search example.com nameserver 10.64.33.1 # nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.sh
이 예에서 10.64.33.1은 DNS 서버의 주소입니다.
/etc/resolv.conf 에 나열된 DNS 서버가 OpenShift Container Platform 환경에 있는 모든 마스터 및 노드의 IP 주소로 호스트 이름을 확인할 수 있는지 테스트합니다.
$ dig <node_hostname> @<IP_address> +short
예를 들면 다음과 같습니다.
$ dig master.example.com @10.64.33.1 +short 10.64.33.100 $ dig node1.example.com @10.64.33.1 +short 10.64.33.101
2.2.1.2. DNS 와일드 카드 구성
선택적으로 라우터를 사용하도록 와일드카드를 구성하여 새 경로를 추가할 때 DNS 구성을 업데이트할 필요가 없습니다. 라우터에 와일드카드를 구성하는 경우 Ansible 인벤토리 파일을 구성할 때 openshift_master_default_subdomain
매개변수를 이 값으로 설정합니다.
DNS 영역의 와일드카드는 궁극적으로 OpenShift Container Platform 라우터 의 IP 주소로 확인되어야 합니다.
예를 들어 TTL(Time-to-live) 값이 낮은 cloudapps 에 와일드카드 DNS 항목을 만들고 라우터가 배포될 호스트의 공용 IP 주소를 가리킵니다.
*.cloudapps.example.com. 300 IN A 192.168.133.2
각 노드 호스트의 /etc/resolv.conf 파일에서 와일드카드 항목이 있는 DNS 서버가 네임서버로 나열되지 않거나 와일드카드 도메인이 검색 목록에 나열되어 있지 않은지 확인합니다. 그렇지 않으면 OpenShift Container Platform에서 관리하는 컨테이너가 호스트 이름을 올바르게 확인하지 못할 수 있습니다.
2.2.1.3. 노드 호스트 이름 구성
클라우드 공급자와 통합되지 않은 클러스터를 설정하면 노드의 호스트 이름을 올바르게 설정해야 합니다. 각 노드의 호스트 이름을 확인할 수 있어야 하며 각 노드는 서로 연결할 수 있어야 합니다.
노드가 다른 노드에 도달할 수 있는지 확인하려면 다음을 수행합니다.
한 노드에서 호스트 이름을 가져옵니다.
$ hostname master-1.example.com
동일한 노드에서 호스트의 정규화된 도메인 이름을 가져옵니다.
$ hostname -f master-1.example.com
다른 노드에서 첫 번째 노드에 연결할 수 있는지 확인합니다.
$ ping master-1.example.com -c 1 PING master-1.example.com (172.16.122.9) 56(84) bytes of data. 64 bytes from master-1.example.com (172.16.122.9): icmp_seq=1 ttl=64 time=0.319 ms --- master-1.example.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.319/0.319/0.319/0.000 ms