2.5. 네트워크 요구 사항
OpenShift Container Platform의 설치 관리자 프로비저닝 설치에는 여러 네트워크 요구 사항이 필요합니다. 첫째, 설치 프로그램 제공 설치에는 각 베어 메탈 노드에서 운영 체제를 프로비저닝하기 위한 선택적 라우팅 불가 provisioning 네트워크가 필요합니다. 그리고 설치 프로그램에서 프로비저닝하는 설치에는 라우팅 가능한 baremetal 네트워크가 포함됩니다.
2.5.1. 필요한 포트가 열려 있는지 확인 링크 복사링크가 클립보드에 복사되었습니다!
설치 관리자가 프로비저닝한 설치를 완료하려면 특정 포트가 클러스터 노드 간에 열려 있어야 합니다. 멀리 엣지 작업자 노드에 별도의 서브넷을 사용하는 것과 같은 특정 상황에서는 이러한 서브넷의 노드가 다음과 같은 필수 포트의 다른 서브넷의 노드와 통신할 수 있는지 확인해야 합니다.
| 포트 | 설명 |
|---|---|
|
|
프로비저닝 네트워크를 사용하는 경우 클러스터 노드는 포트 |
|
|
provisioning 네트워크를 사용하는 경우 클러스터 노드는 provisioning 네트워크 인터페이스를 사용하여 포트 |
|
|
이미지 캐싱 옵션을 사용하지 않는 경우 또는 가상 미디어를 사용하는 경우 프로비저너 노드에 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 프로비저너 노드에서 클러스터 노드로 스트리밍하려면 |
|
|
클러스터 노드는 |
|
|
Ironic Inspector API는 컨트롤 플레인 노드에서 실행되며 포트 |
|
|
포트 |
|
|
가상 미디어를 사용하여 배포하고 TLS를 사용하지 않는 경우 작업자 노드의 BMC(Baseboard Management Controller)가 RHCOS 이미지에 액세스할 수 있도록 프로비저너 노드와 컨트롤 플레인 노드에는 |
|
|
가상 미디어를 사용하여 배포하고 TLS를 사용하는 경우 작업자 노드의 BMC가 RHCOS 이미지에 액세스할 수 있도록 프로비저너 노드와 컨트롤 플레인 노드에 포트 |
|
|
Ironic API 서버는 처음에 부트스트랩 VM에서 실행되고 나중에 컨트롤 플레인 노드에서 실행되며 포트 |
|
|
포트 |
|
|
TLS 없이 이미지 캐싱을 사용하는 경우, 프로비저너 노드에서 포트 |
|
|
TLS와 함께 이미지 캐싱 옵션을 사용하는 경우 |
|
|
기본적으로 Ironic Python Agent(IPA)는 Ironic conductor 서비스에서 API 호출을 위해 TCP 포트 |
2.5.2. 네트워크 MTU 증가 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform을 배포하기 전에 네트워크 최대 전송 단위(MTU)를 1500 이상으로 늘립니다. MTU가 1500 미만이면 노드를 부팅하는 데 사용되는 Ironic 이미지가 Ironic 검사기 Pod와 통신하지 못할 수 있으며 검사가 실패합니다. 이 경우 노드에 설치할 수 없기 때문에 설치가 중지됩니다.
2.5.3. NIC 설정 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform은 다음 두 가지 네트워크를 사용하여 배포합니다.
provisioning:provisioning네트워크는 OpenShift Container Platform 클러스터의 일부인 각 노드에서 기본 운영 체제를 프로비저닝하는데 사용되는 선택 옵션인 라우팅할 수 없는 네트워크입니다. 각 클러스터 노드에서provisioning네트워크의 네트워크 인터페이스에는 PXE 부팅으로 구성된 BIOS 또는 UEFI가 있어야 합니다.provisioningNetworkInterface구성 설정은 컨트롤 플레인 노드에서 동일한provisioning네트워크 NIC 이름을 지정합니다.bootMACAddress구성 설정은provisioning네트워크에 대해 각 노드에서 특정 NIC를 지정하는 수단을 제공합니다.provisioning네트워크는 선택 사항이지만 PXE 부팅에는 필요합니다.provisioning네트워크없이 배포하는 경우redfish-virtualmedia또는idrac-virtualmedia와 같은 가상 미디어 BMC 주소 지정 옵션을 사용해야 합니다.-
baremetal:baremetal네트워크는 라우팅 가능한 네트워크입니다. NIC가provisioning네트워크를 사용하도록 구성되지 않은 경우 모든 NIC를 사용하여baremetal네트워크와 상호 작용할 수 있습니다.
VLAN을 사용하는 경우 각 NIC는 적절한 네트워크에 해당하는 별도의 VLAN에 있어야 합니다.
2.5.4. DNS 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
클라이언트는 baremetal 네트워크를 통해 OpenShift Container Platform 클러스터 노드에 액세스합니다. 네트워크 관리자는 정식 이름 확장이 클러스터 이름인 하위 도메인 또는 하위 영역을 구성해야 합니다.
<cluster_name>.<base_domain>
예를 들면 다음과 같습니다.
test-cluster.example.com
OpenShift Container Platform에는 클러스터 멤버십 정보를 사용하여 A/AAAA 레코드를 생성하는 기능이 포함되어 있습니다. 이렇게 하면 노드 이름이 해당 IP 주소로 확인됩니다. 노드가 API에 등록되면 클러스터에서 CoreDNS-mDNS를 사용하지 않고 노드 정보를 분산할 수 있습니다. 그러면 멀티캐스트 DNS와 연결된 네트워크 트래픽이 제거됩니다.
CoreDNS가 올바르게 작동하려면 업스트림 DNS 서버에 TCP 및 UDP 연결이 모두 필요합니다. 업스트림 DNS 서버가 OpenShift Container Platform 클러스터 노드에서 TCP 및 UDP 연결을 모두 수신할 수 있는지 확인합니다.
OpenShift Container Platform 배포의 경우 다음 구성 요소에 DNS 이름을 확인해야 합니다.
- Kubernetes API
- OpenShift Container Platform 애플리케이션 와일드카드 수신 API
A/AAAA 레코드는 이름 확인에 사용되며 PTR 레코드는 역방향 이름 확인에 사용됩니다. RHCOS(Red Hat Enterprise Linux CoreOS)는 역방향 레코드 또는 DHCP를 사용하여 모든 노드의 호스트 이름을 설정합니다.
설치 프로그램에서 제공하는 설치에는 클러스터 멤버십 정보를 사용하여 A/AAAA 레코드를 생성하는 기능이 포함됩니다. 이렇게 하면 노드 이름이 해당 IP 주소로 확인됩니다. 각 레코드에서 <cluster_name>은 클러스터 이름이고 <base_domain>은 install-config.yaml 파일에서 지정하는 기반 도메인입니다. 전체 DNS 레코드는 <component>.<cluster_name>.<base_domain> 형식입니다.
| 구성 요소 | 레코드 | 설명 |
|---|---|---|
| Kubernetes API |
| A/AAAA 레코드와 PTR 레코드는 API 로드 밸런서를 식별합니다. 이 레코드는 클러스터 외부의 클라이언트와 클러스터 내의 모든 노드에서 확인할 수 있어야 합니다. |
| 라우트 |
| 와일드카드 A/AAAA 레코드는 애플리케이션 인그레스 로드 밸런서를 나타냅니다. 애플리케이션 인그레스 로드 밸런서는 Ingress 컨트롤러 Pod를 실행하는 노드를 대상으로 합니다. Ingress 컨트롤러 Pod는 기본적으로 작업자 노드에서 실행됩니다. 이 레코드는 클러스터 외부의 클라이언트와 클러스터 내의 모든 노드에서 확인할 수 있어야 합니다.
예를 들어 |
dig 명령을 사용하여 DNS 확인을 확인할 수 있습니다.
2.5.5. DHCP(Dynamic Host Configuration Protocol) 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 설치 프로그램에서 제공하는 설치는 provisioning 네트워크에 DHCP가 활성화된 ironic-dnsmasq를 배포합니다. provisioningNetwork 구성 설정이 기본값인 managed로 설정된 경우 provisioning 네트워크에서 다른 DHCP 서버가 실행되고 있지 않아야 합니다. provisioning 네트워크에서 실행 중인 DHCP 서버가 있는 경우 install-config.yaml 파일에서 provisioningNetwork 구성 설정을 Unmanaged로 설정해야 합니다.
네트워크 관리자는 외부 DHCP 서버의 baremetal 네트워크에 대해 OpenShift Container Platform 클러스터의 각 노드에 대한 IP 주소를 예약해야 합니다.
2.5.6. DHCP 서버를 사용하여 노드의 IP 주소 예약 링크 복사링크가 클립보드에 복사되었습니다!
baremetal 네트워크의 경우 네트워크 관리자는 다음을 포함하여 여러 IP 주소를 예약해야 합니다.
두 개의 고유한 가상 IP 주소입니다.
- API 엔드 포인트에 대한 하나의 가상 IP 주소입니다.
- 와일드카드 인그레스 끝점에 대한 하나의 가상 IP 주소입니다.
- 프로비저너 노드 중 하나의 IP 주소.
- 각 컨트롤 플레인 노드에 대해 하나의 IP 주소입니다.
- 각 작업자 노드에 대해 하나의 IP 주소 (해당되는 경우)
일부 관리자는 각 노드의 IP 주소가 DHCP 서버에서 일정하게 유지되도록 고정 IP 주소를 사용하는 것을 선호합니다. NMState를 사용하여 고정 IP 주소를 구성하려면 "OpenShift 설치를 위한 환경 설정" 섹션의 "(선택 사항) 노드 네트워크 인터페이스 구성을 참조하십시오.
외부 로드 밸런싱 서비스와 컨트롤 플레인 노드는 동일한 L2 네트워크에서 실행해야 하며 VLAN을 사용하여 로드 밸런싱 서비스와 컨트롤 플레인 노드 간에 트래픽을 라우팅할 때 동일한 VLAN에서 실행해야 합니다.
스토리지 인터페이스에 DHCP 예약 또는 고정 IP가 필요합니다.
다음 표에서는 정규화된 도메인 이름의 구체적 구현을 제공합니다. API 및 이름 서버 주소는 표준 이름 확장으로 시작됩니다. 컨트롤 플레인 및 작업자 노드의 호스트 이름은 예외이므로 원하는 호스트 이름 지정 규칙을 사용할 수 있습니다.
| 사용법 | 호스트 이름 | IP |
|---|---|---|
| API |
|
|
| Ingress LB (apps) |
|
|
| Provisioner node |
|
|
| Control-plane-0 |
|
|
| Control-plane-1 |
|
|
| Control-plane-2 |
|
|
| Worker-0 |
|
|
| Worker-1 |
|
|
| Worker-n |
|
|
DHCP 예약을 생성하지 않으면 설치 프로그램에서 Kubernetes API 노드, 프로비저너 노드, 컨트롤 플레인 노드 및 작업자 노드의 호스트 이름을 설정하기 위해 역방향 DNS 확인이 필요합니다.
2.5.7. 프로비저너 노드 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
설치 구성에서 provisioner 노드의 MAC 주소를 지정해야 합니다. bootMacAddress 사양은 일반적으로 PXE 네트워크 부팅과 연결됩니다. 그러나 Ironic 프로비저닝 서비스에는 클러스터를 검사하는 동안 또는 클러스터에서 노드를 다시 배포하는 동안 노드를 식별하기 위해 bootMacAddress 사양이 필요합니다.
프로비저너 노드에는 네트워크 부팅, DHCP 및 DNS 확인 및 로컬 네트워크 통신을 위한 계층 2 연결이 필요합니다. 프로비저너 노드에는 가상 미디어 부팅을 위해 계층 3 연결이 필요합니다.
2.5.8. Network Time Protocol (NTP) 링크 복사링크가 클립보드에 복사되었습니다!
클러스터의 각 OpenShift Container Platform 노드는 NTP 서버에 액세스할 수 있습니다. OpenShift Container Platform 노드는 NTP를 사용하여 클럭을 동기화합니다. 예를 들어 클러스터 노드는 검증이 필요한 SSL/TLS 인증서를 사용하므로 노드 간 날짜와 시간이 동기화되지 않은 경우 실패할 수 있습니다.
각 클러스터 노드의 BIOS 설정에서 일관된 클럭 날짜 및 시간 형식을 정의하지 않으면 설치에 실패할 수 있습니다.
연결이 끊긴 클러스터에서 NTP 서버로 작동하도록 컨트롤 플레인 노드를 재구성하고 컨트롤 플레인 노드에서 시간을 검색하도록 작업자 노드를 재구성할 수 있습니다.
2.5.9. 대역 외 관리 IP 주소에 대한 포트 액세스 링크 복사링크가 클립보드에 복사되었습니다!
대역 외 관리 IP 주소는 노드와 별도의 네트워크에 있습니다. 대역 외 관리가 설치 중에 프로비저너 노드와 통신할 수 있도록 대역 외 관리 IP 주소에 프로비저너 노드 및 OpenShift Container Platform 컨트롤 플레인 노드의 포트 6180 에 대한 액세스 권한이 부여되어야 합니다. 예를 들어 Redfish를 사용하여 가상 미디어 설치에는 TLS 포트 6183 이 필요합니다.