Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

3.2. 사전 요구 사항

OpenShift Container Platform 설치 프로그램으로 프로비저닝된 설치에는 다음이 필요합니다.

  1. Red Hat Enterprise Linux(RHEL) 9.x가 설치된 프로비저너 노드 하나. 설치 후 프로비저너를 제거할 수 있습니다.
  2. 컨트롤 플레인 노드 세 개
  3. 각 노드의 베이스 보드 관리 컨트롤러 (BMC) 액세스

  4. 하나 이상의 네트워크:

    1. 라우팅 가능한 필수 네트워크 1개
    2. 선택적 프로비저닝 네트워크 1개
    3. 선택적 관리 네트워크 1개

OpenShift Container Platform 설치 프로그램으로 프로비저닝 설치를 시작하기 전에 하드웨어 환경이 다음 요구 사항을 충족하는지 확인합니다.

3.2.1. 노드 요구 사항
링크 복사

설치 프로그램에서 제공하는 설치에는 여러 하드웨어 노드 요구 사항이 있습니다.

  • CPU 아키텍처: 모든 노드는 x86_64 또는 aarch64 CPU 아키텍처를 사용해야 합니다.
  • 유사한 노드: Red Hat은 노드가 역할별로 동일한 구성을 지정할 것을 권장합니다. 즉, Red Hat은 동일한 CPU, 메모리, 스토리지 설정의 브랜드 및 모델의 노드를 사용할 것을 권장하고 있습니다.
  • 베이스 보드 관리 컨트롤러 : provisioner 노드는 각 OpenShift Container Platform 클러스터 노드의 베이스 보드 관리 컨트롤러 (BMC)에 액세스할 수 있습니다. IPMI, Redfish 또는 전용 프로토콜을 사용할 수 있습니다.
  • 최근 생성: 노드는 최근 생성된 노드여야합니다. 설치 프로그램에서 제공하는 설치는 노드간에 호환되어야 하는 BMC 프로토콜을 사용합니다. 또한 RHEL 8에는 RAID 컨트롤러 용 최신 드라이버가 포함되어 있습니다. 노드가 RHEL 8을 실행하기 위해 provisioner 노드를 지원하고 RHCOS 8을 실행하기 위해 컨트롤 플레인 및 작업자 노드를 지원하기에 충분한 지 확인합니다.
  • 레지스트리 노드: (선택 사항) 연결이 끊어진 미러링된 레지스트리를 설정하는 경우 레지스트리가 자체 노드에 상주하는 것이 좋습니다.
  • 프로비저너 노드 : 설치 프로그램이 제공하는 설치에는 하나의 provisioner 노드가 필요합니다.
  • 컨트롤 플레인: 설치 프로그램에서 프로비저닝한 설치에는 고가용성을 위해 3 개의 컨트롤 플레인 노드가 필요합니다. 컨트롤 플레인 노드 3개만 사용하여 OpenShift Container Platform 클러스터를 배포하여 컨트롤 플레인 노드를 작업자 노드로 예약할 수 있습니다. 소규모 클러스터는 개발, 프로덕션 및 테스트 중에 관리자와 개발자에게 더 많은 리소스를 제공합니다.

  • 작업자 노드: 필수는 아니지만 일반적인 프로덕션 클러스터에는 두 개 이상의 작업자 노드가 있습니다.

    중요

    클러스터가 성능 저하된 상태로 라우터 및 인그레스 트래픽으로 배포되므로 하나의 작업자 노드로만 클러스터를 배포하지 마십시오.

  • 네트워크 인터페이스: 각 노드에는 라우팅 가능한 baremetal 네트워크에 대해 하나 이상의 네트워크 인터페이스가 있어야 합니다. 배포에 provisioning 네트워크를 사용할 때 각 노드에는 provisioning 네트워크에 대해 하나의 네트워크 인터페이스가 있어야합니다. provisioning 네트워크를 사용하는 것이 기본 구성입니다.

    참고

    동일한 서브넷의 NIC(네트워크 카드) 하나만 게이트웨이를 통해 트래픽을 라우팅할 수 있습니다. 기본적으로 ARP(Address Resolution Protocol)는 가장 낮은 번호의 NIC를 사용합니다. 동일한 서브넷의 각 노드에 대해 단일 NIC를 사용하여 네트워크 로드 밸런싱이 예상대로 작동하는지 확인합니다. 동일한 서브넷의 노드에 여러 NIC를 사용하는 경우 단일 본딩 또는 팀 인터페이스를 사용합니다. 그런 다음 별칭 IP 주소 형식으로 해당 인터페이스에 다른 IP 주소를 추가합니다. 네트워크 인터페이스 수준에서 내결함성 또는 로드 밸런싱이 필요한 경우 본딩 또는 팀 인터페이스에서 별칭 IP 주소를 사용합니다. 또는 동일한 서브넷에서 보조 NIC를 비활성화하거나 IP 주소가 없는지 확인할 수 있습니다.

  • UEFI (Unified Extensible Firmware Interface): 설치 프로그램이 프로비저닝한 설치에는 provisioning 네트워크에서 IPv6 주소를 사용하는 경우 모든 OpenShift Container Platform 노드에서 UEFI 부팅이 필요합니다. 또한 provisioning 네트워크 NIC에서 IPv6 프로토콜을 사용하도록 UEFI 장치 PXE 설정을 설정해야하지만 provisioning 네트워크를 생략하면 이 요구 사항이 제거됩니다.

    중요

    ISO 이미지와 같은 가상 미디어에서 설치를 시작할 때 이전 UEFI 부팅 테이블 항목을 모두 삭제합니다. 부팅 테이블에 펌웨어에서 제공하는 일반 항목이 아닌 항목이 포함된 경우 설치에 실패할 수 있습니다.

  • Secure Boot: Secure Boot가 활성화된 노드를 사용하려면 UEFI 펌웨어 드라이버, EFI 애플리케이션 및 운영 체제와 같은 신뢰할 수 있는 소프트웨어에서만 노드를 부팅해야 합니다. Secure Boot를 사용하여 수동으로 배포하거나 관리할 수 있습니다.

    1. 수동형: Secure Boot를 사용하여 OpenShift Container Platform 클러스터를 수동으로 배포하려면 각 컨트롤 플레인 노드와 각 작업자 노드에서 UEFI 부팅 모드 및 Secure Boot를 활성화해야 합니다. Red Hat은 설치 관리자 프로비저닝 설치에서 Redfish 가상 미디어를 사용하는 경우에만 수동으로 활성화된 UEFI 및 Secure Boot를 사용하여 Secure Boot를 지원합니다. 자세한 내용은 "노드 구성" 섹션의 "Secure Boot을 위해 수동으로 노드 구성"을 참조하십시오.

    2. 관리형: Secure Boot를 사용하여 OpenShift Container Platform 클러스터를 배포하려면 install-config.yaml 파일에서 bootMode 값을 UEFISecureBoot로 설정해야 합니다. Red Hat은 펌웨어 버전 2.75.75.75 이상을 실행하는 10세대 HPE 하드웨어와 13세대 Dell 하드웨어에 대한 관리형 Secure Boot를 사용하는 설치 관리자 프로비저닝 설치를 지원합니다. 관리형 Secure Boot를 사용하여 배포하는 경우 Redfish 가상 미디어가 필요하지 않습니다. 자세한 내용은 "OpenShift 설치를 위한 환경 설정" 섹션의 "관리형 Secure Boot 구성"을 참조하십시오.

      참고

      Red Hat은 Secure Boot의 자체 생성 키 또는 기타 키 관리를 지원하지 않습니다.

3.2.2. 클러스터 설치를 위한 최소 리소스 요구 사항
링크 복사

각 클러스터 시스템이 다음과 같은 최소 요구사항을 충족해야 합니다.

Expand
표 3.1. 최소 리소스 요구사항
머신운영 체제CPU [1]RAM스토리지초당 입력/출력(IOPS)[2]

부트스트랩

RHEL 8

4

16GB

100GB

300

컨트롤 플레인

RHCOS

4

16GB

100GB

300

Compute

RHCOS

2

8GB

100GB

300

  1. 동시 멀티스레딩(SMT) 또는 하이퍼 스레딩이 활성화되지 않은 경우 하나의 CPU가 하나의 물리적 코어와 동일합니다. 활성화하면 다음 공식을 사용하여 해당 비율을 계산합니다. (코어당 스레드 수 × 코어 수) × 소켓 = CPU입니다.
  2. OpenShift Container Platform 및 Kubernetes는 디스크 성능에 민감하며 특히 컨트롤 플레인 노드의 etcd에 더 빠른 스토리지를 사용하는 것이 좋습니다. 많은 클라우드 플랫폼에서 스토리지 크기와 IOPS를 함께 확장되므로 충분한 성능을 얻으려면 스토리지 볼륨을 과도하게 할당해야 할 수 있습니다.
참고

OpenShift Container Platform 버전 4.19의 경우 RHCOS는 마이크로 아키텍처 요구 사항을 업데이트하는 RHEL 버전 9.6을 기반으로 합니다. 다음 목록에는 각 아키텍처에 필요한 최소 명령 세트 아키텍처(ISA)가 포함되어 있습니다.

  • x86-64 아키텍처에는 x86-64-v2 ISA가 필요합니다.
  • ARM64 아키텍처에는 ARMv8.0-A ISA가 필요합니다.
  • IBM Power 아키텍처에는 Power 9 ISA가 필요합니다.
  • s390x 아키텍처에는 z14 ISA가 필요합니다.

자세한 내용은 아키텍처 (RHEL 문서)를 참조하십시오.

플랫폼의 인스턴스 유형이 클러스터 머신의 최소 요구 사항을 충족하는 경우 OpenShift Container Platform에서 사용할 수 있습니다.

3.2.3. OpenShift Virtualization을 위한 베어 메탈 클러스터 계획
링크 복사

OpenShift Virtualization을 사용하는 경우 베어 메탈 클러스터를 설치하기 전에 여러 요구 사항을 알고 있어야 합니다.

  • 실시간 마이그레이션 기능을 사용하려면 클러스터 설치 시 여러 개의 작업자 노드가 있어야 합니다. 이는 실시간 마이그레이션에 클러스터 수준 HA(고가용성) 플래그를 true로 설정해야 하기 때문입니다. HA 플래그는 클러스터가 설치될 때 설정되며 나중에 변경할 수 없습니다. 클러스터를 설치할 때 두 개 미만의 작업자 노드가 정의되어 있는 경우 클러스터 수명 동안 HA 플래그가 false로 설정됩니다.

    참고

    단일 노드 클러스터에 OpenShift Virtualization을 설치할 수 있지만 단일 노드 OpenShift는 고가용성을 지원하지 않습니다.

  • 실시간 마이그레이션에는 공유 스토리지가 필요합니다. OpenShift Virtualization용 스토리지는 RWX(ReadWriteMany) 액세스 모드를 지원하고 사용해야 합니다.
  • SR-IOV(Single Root I/O Virtualization)를 사용하려는 경우 OpenShift Container Platform에서 NIC(네트워크 인터페이스 컨트롤러)를 지원하는지 확인합니다.

3.2.4. 가상 미디어를 사용하여 설치를 위한 펌웨어 요구 사항
링크 복사

설치 관리자 프로비저닝 OpenShift Container Platform 클러스터의 설치 프로그램은 Redfish 가상 미디어와의 하드웨어 및 펌웨어 호환성을 검증합니다. 노드 펌웨어가 호환되지 않는 경우 설치 프로그램이 노드에 설치를 시작하지 않습니다. 다음 표에는 Redfish 가상 미디어를 사용하여 배포된 설치 관리자 프로비저닝 OpenShift Container Platform 클러스터에서 테스트 및 검증된 최소 펌웨어 버전이 나열되어 있습니다.

참고

Red Hat은 펌웨어, 하드웨어 또는 기타 타사 구성 요소의 모든 조합을 테스트하지 않습니다. 타사 지원에 대한 자세한 내용은 Red Hat 타사 지원 정책을 참조하십시오. 펌웨어 업데이트에 대한 자세한 내용은 노드의 하드웨어 설명서를 참조하거나 하드웨어 벤더에 문의하십시오.

Expand
표 3.2. Redfish 가상 미디어를 사용한 HP 하드웨어의 펌웨어 호환성
모델관리펌웨어 버전

11세대

iLO6

6.5 이상

10세대

iLO5

6.5 이상

Expand
표 3.3. Redfish 가상 미디어를 사용하여 Dell 하드웨어의 펌웨어 호환성
모델관리펌웨어 버전

16세대

iDRAC 9

v7.10.70.00

15세대

iDRAC 9

v6.10.30.00, v7.10.50.00 및 v7.10.70.00

14세대

iDRAC 9

v6.10.30.00

Expand
표 3.4. Redfish 가상 미디어를 사용한 Cisco UCS 하드웨어의 펌웨어 호환성
모델관리펌웨어 버전

UCS X-Series 서버

Intersight Managed Mode

6.5 이상

FI-Attached UCS C-Series 서버

Intersight Managed Mode

6.5 이상

독립형 UCS C-Series 서버

독립 실행형 / Intersight

6.5 이상

참고

항상 서버가 UCSHCL 에서 RHCOS(Red Hat Enterprise Linux CoreOS)를 지원하는지 확인합니다.

3.2.5. 베어 메탈에 대한 Cryostat-SI 하드웨어 요구 사항
링크 복사

베어 메탈에 N-SI(Network Controller Sideband Interface)를 사용하여 OpenShift Container Platform 4.19 이상을 배포하려면 BMC(Baseboard Management Controller) 및 NIC(네트워크 인터페이스 카드)가 있는 하드웨어를 사용해야 합니다. Cryostat-SI를 사용하면 BMC에서 호스트와 시스템 NIC를 공유할 수 있으므로 전원 끄기 중 BMC 연결 손실을 방지하기 위해 DisablePowerOff 기능이 필요합니다.

Expand
표 3.5. Cryostat-SI의 서버 호환성
vendor모델생성관리

Dell

PowerEdge

14세대 이상

iDRAC 9 이상(Redfish, IPMI, racadm, WS-MAN)

HPE

Cryostat

10세대 이상

ILO 5 이상(Redfish, IPMI, iLO RESTful API)

Cryostat

ThinkSystem SR

1세대 이상

XCaddity Controller (Redfish, IPMI, 전용 API)

Supermicro

슈퍼 서버

X11 시리즈 이상

Supermicro BMC (Redfish, IPMI, 전용 웹/CLI)

Intel

서버 시스템

S2600BP 이상

Intel BMC(Redfish, IPMI, 독점 API)

Fujitsu

PRIMERGY

M4 시리즈 이상

iRMC S5 이상(Redfish, IPMI, 독점 웹/CLI)

Cisco

UCS C-Series

M5 시리즈 이상

Cisco IMC(Redfish, IPMI, 전용 XML API)

Expand
표 3.6. Cryostat-SI에 대해 호환되는 네트워크 인터페이스 카드(NIC)
vendor모델사양

Broadcom

NetXtreme BCM5720, BCM57416, BCM57504

Gigabit 및 10/25/100GbE, RMII sideband는 Redfish, IPMI 및 벤더 프로토콜을 지원합니다.

Intel

I210, X710, XXV710, E810

Gigabit - 100GbE, RMII 및 SMBus sideband는 Redfish, IPMI 및 벤더 프로토콜을 지원합니다.

NVIDIA

ConnectX-5, ConnectX-6, ConnectX-7

25/50/100/200/400GbE, RMII 사이드 대역폭은 Redfish, IPMI 및 NVIDIA BMC API를 지원합니다.

NVIDIA

Bluefield-2 이상

200/400GbE는 Redfish, IPMI 및 NVIDIA BMC API를 지원합니다.

Marvell/Cavium

ThunderX CN88xx, FastLinQ QL41000

10/25/50GbE, RMII 사이드 대역폭은 Redfish, IPMI 및 벤더 프로토콜을 지원합니다.

Mellanox(NVIDIA)

MCX4121A-ACAT, MCX512A-ACAT

10/25/50GbE, RMII 사이드 대역폭은 Redfish, IPMI 및 Mellanox API를 지원합니다.

참고

BMC, NIC 및 펌웨어 구성에 따라 호환성이 달라지므로 공급 업체 문서에서 Cryostat-SI 지원을 확인합니다. Cryostat-SI NIC에는 공유 NIC 기능을 활성화하기 위해 호환되는 BMC가 필요합니다.

3.2.6. 네트워크 요구 사항
링크 복사

OpenShift Container Platform의 설치 프로그램 프로비저닝 설치에는 몇 가지 네트워크 요구 사항이 있습니다. 첫째, 설치 프로그램 제공 설치에는 각 베어 메탈 노드에서 운영 체제를 프로비저닝하기 위한 선택적 라우팅 불가 provisioning 네트워크가 필요합니다. 그리고 설치 프로그램에서 프로비저닝하는 설치에는 라우팅 가능한 baremetal 네트워크가 포함됩니다.

설치 프로그램에서 제공하는 네트워킹
View larger image
설치 프로그램에서 제공하는 네트워킹

3.2.6.1. 필요한 포트가 열려 있는지 확인
링크 복사

설치 관리자가 프로비저닝한 설치를 완료하려면 특정 포트가 클러스터 노드 간에 열려 있어야 합니다. 멀리 엣지 작업자 노드에 별도의 서브넷을 사용하는 것과 같은 특정 상황에서는 이러한 서브넷의 노드가 다음과 같은 필수 포트의 다른 서브넷의 노드와 통신할 수 있는지 확인해야 합니다.

Expand
표 3.7. 필수 포트
포트설명

67,68

프로비저닝 네트워크를 사용하는 경우 클러스터 노드는 포트 67 및 68 을 사용하여 프로비저닝 네트워크 인터페이스를 통해 dnsmasq DHCP 서버에 액세스합니다.

69

provisioning 네트워크를 사용하는 경우 클러스터 노드는 provisioning 네트워크 인터페이스를 사용하여 포트 69 의 TFTP 서버와 통신합니다. TFTP 서버는 부트스트랩 VM에서 실행됩니다. 부트스트랩 VM은 프로비저너 노드에서 실행됩니다.

80

이미지 캐싱 옵션을 사용하지 않는 경우 또는 가상 미디어를 사용하는 경우 프로비저너 노드에 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 프로비저너 노드에서 클러스터 노드로 스트리밍하려면 baremetal 머신 네트워크 인터페이스에 포트 80 이 열려 있어야 합니다.

123

클러스터 노드는 baremetal 시스템 네트워크를 사용하여 포트 123 의 NTP 서버에 액세스해야 합니다.

5050

Ironic Inspector API는 컨트롤 플레인 노드에서 실행되며 포트 5050 에서 수신 대기합니다. Inspector API는 하드웨어 인트로스펙션을 담당하며 베어 메탈 노드의 하드웨어 특성에 대한 정보를 수집합니다.

5051

포트 5050 은 포트 5051 을 프록시로 사용합니다.

6180

가상 미디어를 사용하여 배포하고 TLS를 사용하지 않는 경우 작업자 노드의 BMC(Baseboard Management Controller)가 RHCOS 이미지에 액세스할 수 있도록 프로비저너 노드와 컨트롤 플레인 노드에는 baremetal 머신 네트워크 인터페이스에 포트 6180 이 열려 있어야 합니다. OpenShift Container Platform 4.13부터 기본 HTTP 포트는 6180 입니다.

6183

가상 미디어를 사용하여 배포하고 TLS를 사용하는 경우 작업자 노드의 BMC가 RHCOS 이미지에 액세스할 수 있도록 프로비저너 노드와 컨트롤 플레인 노드에 포트 6183 이 baremetal 머신 네트워크 인터페이스에 열려 있어야 합니다.

6385

Ironic API 서버는 처음에 부트스트랩 VM에서 실행되고 나중에 컨트롤 플레인 노드에서 실행되며 포트 6385 에서 수신 대기합니다. Ironic API를 사용하면 클라이언트는 새 노드 등록, 전원 상태 관리, 이미지 배포, 하드웨어 정리 등의 작업을 포함하여 베어 메탈 노드 프로비저닝 및 관리를 위해 Ironic과 상호 작용할 수 있습니다.

6388

포트 6385 은 포트 6388 을 프록시로 사용합니다.

8080

TLS 없이 이미지 캐싱을 사용하는 경우, 프로비저너 노드에서 포트 8080 을 열고 클러스터 노드의 BMC 인터페이스에서 액세스할 수 있어야 합니다.

8083

TLS와 함께 이미지 캐싱 옵션을 사용하는 경우 8083 포트를 프로비저너 노드에서 열고 클러스터 노드의 BMC 인터페이스에서 액세스할 수 있어야 합니다.

9999

기본적으로 Ironic Python Agent(IPA)는 Ironic conductor 서비스에서 API 호출을 위해 TCP 포트 9999 에서 수신 대기합니다. IPA가 실행 중인 베어 메탈 노드 간 통신과 Ironic conductor 서비스는 이 포트를 사용합니다.

3.2.6.2. 네트워크 MTU 증가
링크 복사

OpenShift Container Platform을 배포하기 전에 네트워크 최대 전송 단위(MTU)를 1500 이상으로 늘립니다. MTU가 1500 미만이면 노드를 부팅하는 데 사용되는 Ironic 이미지가 Ironic 검사기 Pod와 통신하지 못할 수 있으며 검사가 실패합니다. 이 경우 노드에 설치할 수 없기 때문에 설치가 중지됩니다.

3.2.6.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에 있어야 합니다.

3.2.6.4. DNS 요구 사항
링크 복사

클라이언트는 baremetal 네트워크를 통해 OpenShift Container Platform 클러스터 노드에 액세스합니다. 네트워크 관리자는 정식 이름 확장이 클러스터 이름인 하위 도메인 또는 하위 영역을 구성해야 합니다. 

<cluster_name>.<base_domain>
Copy to Clipboard Toggle word wrap

예를 들면 다음과 같습니다. 

test-cluster.example.com
Copy to Clipboard Toggle word wrap

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> 형식입니다.

Expand
표 3.8. 필수 DNS 레코드
구성 요소레코드설명

Kubernetes API

api.<cluster_name>.<base_domain>.

A/AAAA 레코드와 PTR 레코드는 API 로드 밸런서를 식별합니다. 이 레코드는 클러스터 외부의 클라이언트와 클러스터 내의 모든 노드에서 확인할 수 있어야 합니다.

라우트

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

와일드카드 A/AAAA 레코드는 애플리케이션 인그레스 로드 밸런서를 나타냅니다. 애플리케이션 인그레스 로드 밸런서는 Ingress 컨트롤러 Pod를 실행하는 머신을 대상으로 합니다. Ingress 컨트롤러 Pod는 기본적으로 작업자 노드에서 실행됩니다. 이 레코드는 클러스터 외부의 클라이언트와 클러스터 내의 모든 노드에서 확인할 수 있어야 합니다.

예를 들어 console-openshift-console.apps.<cluster_name>.<base_domain>은 OpenShift Container Platform 콘솔의 와일드카드 경로로 사용됩니다.

작은 정보

dig 명령을 사용하여 DNS 확인을 확인할 수 있습니다.

3.2.6.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 주소를 예약해야 합니다.

3.2.6.6. DHCP 서버를 사용하여 노드의 IP 주소 예약
링크 복사

baremetal 네트워크의 경우 네트워크 관리자는 다음을 포함하여 여러 IP 주소를 예약해야 합니다.

  1. 두 개의 고유한 가상 IP 주소입니다.

    • API 엔드 포인트에 대한 하나의 가상 IP 주소입니다.
    • 와일드카드 인그레스 끝점에 대한 하나의 가상 IP 주소입니다.
  2. 프로비저너 노드 중 하나의 IP 주소.
  3. 각 컨트롤 플레인 노드에 대해 하나의 IP 주소입니다.
  4. 각 작업자 노드에 대해 하나의 IP 주소 (해당되는 경우)
고정 IP 주소가 되도록 IP 주소 예약

일부 관리자는 각 노드의 IP 주소가 DHCP 서버에서 일정하게 유지되도록 고정 IP 주소를 사용하는 것을 선호합니다. NMState를 사용하여 고정 IP 주소를 구성하려면 "OpenShift 설치를 위한 환경 설정" 섹션의 "(선택 사항) 노드 네트워크 인터페이스 구성을 참조하십시오.

외부 로드 밸런서와 컨트롤 플레인 노드 간 네트워킹

외부 로드 밸런싱 서비스와 컨트롤 플레인 노드는 동일한 L2 네트워크에서 실행해야 하며 VLAN을 사용하여 로드 밸런싱 서비스와 컨트롤 플레인 노드 간에 트래픽을 라우팅할 때 동일한 VLAN에서 실행해야 합니다.

중요

스토리지 인터페이스에 DHCP 예약 또는 고정 IP가 필요합니다.

다음 표에서는 정규화된 도메인 이름의 구체적 구현을 제공합니다. API 및 Nameserver 주소는 표준 이름 확장으로 시작됩니다. 컨트롤 플레인 및 작업자 노드의 호스트 이름은 예외이므로 원하는 호스트 이름 지정 규칙을 사용할 수 있습니다.

Expand
사용법호스트 이름IP

API

api.<cluster_name>.<base_domain>

<ip>

Ingress LB (apps)

*.apps.<cluster_name>.<base_domain>

<ip>

Provisioner node

provisioner.<cluster_name>.<base_domain>

<ip>

Control-plane-0

openshift-control-plane-0.<cluster_name>.<base_domain>

<ip>

Control-plane-0

openshift-control-plane-1.<cluster_name>-.<base_domain>

<ip>

Control-plane-0

openshift-control-plane-2.<cluster_name>.<base_domain>

<ip>

Worker-0

openshift-worker-0.<cluster_name>.<base_domain>

<ip>

Worker-1

openshift-worker-1.<cluster_name>.<base_domain>

<ip>

Worker-n

openshift-worker-n.<cluster_name>.<base_domain>

<ip>

참고

DHCP 예약을 생성하지 않으면 설치 프로그램에서 Kubernetes API 노드, 프로비저너 노드, 컨트롤 플레인 노드 및 작업자 노드에 대한 호스트 이름을 설정하기 위해 역방향 DNS 확인이 필요합니다.

3.2.6.7. 프로비저너 노드 요구 사항
링크 복사

설치 구성에서 provisioner 노드의 MAC 주소를 지정해야 합니다. bootMacAddress 사양은 일반적으로 PXE 네트워크 부팅과 연결됩니다. 그러나 Ironic 프로비저닝 서비스에는 클러스터를 검사하는 동안 또는 클러스터에서 노드를 다시 배포하는 동안 노드를 식별하기 위해 bootMacAddress 사양이 필요합니다.

프로비저너 노드에는 네트워크 부팅, DHCP 및 DNS 확인 및 로컬 네트워크 통신을 위한 계층 2 연결이 필요합니다. 프로비저너 노드에는 가상 미디어 부팅을 위해 계층 3 연결이 필요합니다.

3.2.6.8. Network Time Protocol (NTP)
링크 복사

클러스터의 각 OpenShift Container Platform 노드는 NTP 서버에 액세스할 수 있습니다. OpenShift Container Platform 노드는 NTP를 사용하여 클럭을 동기화합니다. 예를 들어 클러스터 노드는 검증이 필요한 SSL 인증서를 사용하므로 노드 간 날짜와 시간이 동기화되지 않은 경우 인증서가 실패할 수 있습니다.

중요

각 클러스터 노드의 BIOS 설정에서 일관된 클럭 날짜 및 시간 형식을 정의하지 않으면 설치에 실패할 수 있습니다.

연결이 끊긴 클러스터에서 NTP 서버로 작동하도록 컨트롤 플레인 노드를 재구성하고 컨트롤 플레인 노드에서 시간을 검색하도록 작업자 노드를 재구성할 수 있습니다.

3.2.6.9. 대역 외 관리 IP 주소에 대한 포트 액세스
링크 복사

대역 외 관리 IP 주소는 노드와 별도의 네트워크에 있습니다. 대역 외 관리가 설치 중에 프로비저너 노드와 통신할 수 있도록 대역 외 관리 IP 주소에 프로비저너 노드 및 OpenShift Container Platform 컨트롤 플레인 노드의 포트 6180 에 대한 액세스 권한이 부여되어야 합니다. 예를 들어 Redfish를 사용하여 가상 미디어 설치에는 TLS 포트 6183 이 필요합니다.

3.2.7. 노드 설정
링크 복사

provisioning 네트워크를 사용할 때 노드 설정

클러스터의 각 노드는 적절한 설치를 위해 다음과 같은 설정이 필요합니다.

주의

노드간에 일치하지 않으면 설치에 실패합니다.

클러스터 노드에는 두 개 이상의 NIC가 포함될 수 있지만 설치 프로세스는 처음 두 개의 NIC에만 중점을 둡니다. 다음 표에서 NIC1은 OpenShift Container Platform 클러스터 설치에만 사용되는 라우팅 불가능한 네트워크(provisioning)입니다.

Expand
NIC네트워크VLAN

NIC1

provisioning

<provisioning_vlan>

NIC2

baremetal

<baremetal_vlan>

Provisioner 노드의 RHEL (Red Hat Enterprise Linux) 8.x 설치 프로세스는 다를 수 있습니다. 로컬 Satellite 서버 PXE 서버 PXE 지원 NIC2를 사용하여 Red Hat Enterprise Linux (RHEL) 8.x를 설치하려면 다음과 같이합니다.

Expand
PXE부팅 순서

NIC1 PXE 지원 provisioning 네트워크

1

NIC2 baremetal 네트워크 PXE 사용은 선택 사항입니다.

2

참고

다른 모든 NIC에서 PXE가 비활성화되어 있는지 확인합니다.

다음과 같이 컨트롤 플레인 및 작업자 노드를 설정합니다.

Expand
PXE부팅 순서

NIC1 PXE 활성화 (프로비저닝 네트워크)

1

provisioning 네트워크없이 노드 설정

설치 프로세스에는 하나의 NIC가 필요합니다.

Expand
NIC네트워크VLAN

NICx

baremetal

<baremetal_vlan>

NICx는 OpenShift Container Platform 클러스터 설치에 사용되는 라우팅 가능한 네트워크 (baremetal)이며 인터넷으로 라우팅될 수 있습니다.

중요

provisioning 네트워크는 선택 사항이지만 PXE 부팅에는 필요합니다. provisioning 네트워크없이 배포하는 경우 redfish-virtualmedia 또는 idrac-virtualmedia 와 같은 가상 미디어 BMC 주소 지정 옵션을 사용해야 합니다.

Secure Boot를 위해 노드를 수동으로 설정합니다.

Secure Boot는 UEFI 펌웨어 드라이버, EFI 애플리케이션 및 운영 체제와 같은 신뢰할 수 있는 소프트웨어만 사용하는지 확인하지 않는 한 노드를 부팅하지 않습니다.

참고

Red Hat은 Redfish 가상 미디어를 사용하여 배포하는 경우에만 수동으로 구성된 Secure Boot를 지원합니다.

Secure Boot를 수동으로 활성화하려면 노드의 하드웨어 가이드를 참조하여 다음을 실행합니다.

프로세스

  1. 노드를 부팅하고 BIOS 메뉴를 입력합니다.
  2. 노드의 부팅 모드를 UEFI Enabled로 설정합니다.
  3. Secure Boot를 활성화합니다.
중요

Red Hat은 자체 생성되는 키가 있는 Secure Boot를 지원하지 않습니다.

3.2.8. 대역 외 관리
링크 복사

일반적으로 노드에는 베이스 보드 관리 컨트롤러 (BMC)에서 사용하는 추가 NIC가 있습니다. 이러한 BMC는 프로비저너 노드에서 액세스할 수 있어야 합니다.

각 노드는 대역 외 관리를 통해 액세스할 수 있어야합니다. 대역 외 관리 네트워크를 사용할 때 프로비저너 노드는 OpenShift Container Platform 4를 성공적으로 설치하기 위해 대역 외 관리 네트워크에 액세스해야 합니다.

대역 외 관리 설정은 이 문서에서 다루지 않습니다. 대역 외 관리를 위해 별도의 관리 네트워크를 사용하면 성능을 개선하고 보안을 향상시킬 수 있습니다. 그러나 프로비저닝 네트워크 또는 베어메탈 네트워크를 사용하는 것은 유효한 옵션입니다.

참고

부트스트랩 VM에는 최대 두 개의 네트워크 인터페이스가 있습니다. 대역 외 관리를 위해 별도의 관리 네트워크를 구성하고 provisioning 네트워크를 사용하는 경우 부트스트랩 VM은 네트워크 인터페이스 중 하나를 통해 관리 네트워크에 대한 액세스를 라우팅해야 합니다. 이 시나리오에서는 부트스트랩 VM이 세 개의 네트워크에 액세스할 수 있습니다.

  • 베어 메탈 네트워크
  • 프로비저닝 네트워크
  • 네트워크 인터페이스 중 하나를 통해 라우팅되는 관리 네트워크

3.2.9. 설치에 필요한 데이터
링크 복사

OpenShift Container Platform 클러스터를 설치하기 전에 모든 클러스터 노드에서 다음 정보를 수집하십시오.

  • 대역 외 관리 IP

    • 예

      • Dell (iDRAC) IP
      • HP (iLO) IP
      • Fujitsu (iRMC) IP

provisioning 네트워크를 사용하는 경우

  • NIC (provisioning) MAC 주소
  • NIC (baremetal) MAC 주소

provisioning 네트워크를 생략하는 경우

  • NIC (baremetal) MAC 주소

3.2.10. 노드의 유효성 검사 체크리스트
링크 복사

provisioning 네트워크를 사용하는 경우

  • ❏ NIC1 VLAN은 provisioning 네트워크에 대해 설정되어 있습니다.
  • provisioning 네트워크의 NIC1은 프로비저너, 컨트롤 플레인 (마스터) 및 작업자 노드에서 PXE를 지원합니다.
  • ❏ NIC2 VLAN은 baremetal 네트워크에 대해 설정되어 있습니다.
  • ❏ 다른 모든 NIC에서 PXE는 비활성화되어 있습니다.
  • kmod DNS는 API 및 Ingress 엔드포인트로 구성됩니다.
  • ❏ 컨트롤 플레인 및 작업자 노드가 설정되어 있습니다.
  • ❏ 모든 노드는 대역 외 관리를 통해 액세스할 수 있습니다.
  • kmod (선택 사항) 별도의 관리 네트워크가 생성되어 있습니다.
  • ❏ 설치에 필요한 데이터.

provisioning 네트워크를 생략하는 경우

  • ❏ kmod NIC1 VLAN은 baremetal 네트워크에 대해 설정되어 있습니다.
  • kmod DNS는 API 및 Ingress 엔드포인트로 구성됩니다.
  • ❏ 컨트롤 플레인 및 작업자 노드가 설정되어 있습니다.
  • ❏ 모든 노드는 대역 외 관리를 통해 액세스할 수 있습니다.
  • kmod (선택 사항) 별도의 관리 네트워크가 생성되어 있습니다.
  • ❏ 설치에 필요한 데이터.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat