10.2. 사전 요구 사항

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

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

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

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

10.2.1. 노드 요구 사항

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

  • CPU 아키텍처: 모든 노드는 x86_64 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 네트워크를 사용하는 것이 기본 구성입니다.
  • 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를 지원하지 않습니다.

10.2.2. 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(네트워크 인터페이스 컨트롤러)를 지원하는지 확인합니다.

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

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

표 10.1. Redfish Virtual Media의 펌웨어 호환성

하드웨어모델관리펌웨어 버전

HP

10세대

iLO5

2.63 이상

Dell

14세대

iDRAC 9

v4.20.20.20 - v4.40.00.00만

13세대

iDRAC 8

v2.75.75.75 이상

참고

Red Hat은 펌웨어, 하드웨어 또는 기타 타사 구성 요소의 모든 조합을 테스트하지 않습니다. 타사 지원에 대한 자세한 내용은 Red Hat 타사 지원 정책 을 참조하십시오.

펌웨어 업데이트에 대한 정보는 노드의 하드웨어 설명서를 참조하거나 하드웨어 공급 업체에 문의하십시오.

HP 서버의 경우 Ironic은 가상 미디어에서 iLO4를 지원하지 않기 때문에 iLO4를 실행하는 9세대 시스템에서 Redfish 가상 미디어가 지원되지 않습니다.

Dell 서버의 경우 OpenShift Container Platform 클러스터 노드에 iDRAC 콘솔을 통해 AutoAttach가 활성화되어 있는지 확인합니다. 메뉴 경로는 구성가상 미디어연결 모드자동 연결입니다 . iDRAC 9 펌웨어 버전 04.40.00.00 을 사용하면 가상 콘솔 플러그인이 기본적으로 eHTML5 로 설정되어 InsertVirtualMedia 워크플로우에 문제가 발생합니다. 이 문제를 방지하려면 플러그인을 HTML5로 설정합니다. 메뉴 경로는 설정가상 콘솔플러그인 유형HTML5입니다.

중요

노드 펌웨어가 가상 미디어와 함께 설치하는 버전 아래에 있는 경우 설치 관리자는 노드에 설치를 시작하지 않습니다.

10.2.4. 네트워크 요구 사항

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

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

10.2.4.1. 네트워크 MTU 증가

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

10.2.4.2. NIC 설정

OpenShift Container Platform은 다음 두 가지 네트워크를 사용하여 배포합니다.

  • provisioning: provisioning 네트워크는 OpenShift Container Platform 클러스터의 일부인 각 노드에서 기본 운영 체제를 프로비저닝하는데 사용되는 선택 옵션인 라우팅할 수 없는 네트워크입니다. 각 클러스터 노드에서 provisioning 네트워크의 네트워크 인터페이스에는 PXE 부팅으로 구성된 BIOS 또는 UEFI가 있어야 합니다.

    provisioningNetworkInterface 구성 설정은 컨트롤 플레인 노드에서 프로비저닝 네트워크 NIC 이름을 지정합니다. 이 이름은 컨트롤 플레인 노드에서 동일해야 합니다. bootMACAddress 구성 설정은 provisioning 네트워크의 각 노드에서 특정 NIC를 지정하는 방법을 제공합니다 .

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

  • baremetal: baremetal 네트워크는 라우팅 가능한 네트워크입니다. NIC가 provisioning 네트워크를 사용하도록 구성되지 않은 경우 baremetal 네트워크와 인터페이스하는 데 NIC를 사용할 수 있습니다 .
중요

VLAN을 사용하는 경우 각 NIC는 적절한 네트워크에 해당하는 별도의 VLAN에 있어야 합니다.

10.2.4.3. DNS 요구 사항

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

<cluster_name>.<base_domain>

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

test-cluster.example.com

OpenShift Container Platform에는 클러스터 멤버십 정보를 사용하여 A/AAAA 레코드를 생성하는 기능이 포함되어 있습니다. 이렇게 하면 노드 이름이 해당 IP 주소로 확인됩니다. 노드가 API에 등록되면 클러스터에서 CoreDNS-mDNS를 사용하지 않고 노드 정보를 분산할 수 있습니다. 그러면 멀티캐스트 DNS와 연결된 네트워크 트래픽이 제거됩니다.

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

표 10.2. 필수 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 확인을 확인할 수 있습니다.

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

10.2.4.5. DHCP 서버를 사용하여 노드의 IP 주소 예약

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

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

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

일부 관리자는 각 노드의 IP 주소가 DHCP 서버에서 일정하게 유지되도록 고정 IP 주소를 사용하는 것을 선호합니다. OpenShift Container Platform 클러스터에서 고정 IP 주소를 사용하려면 무한 리스로 IP 주소를 예약합니다. 배포 중에 설치 프로그램은 DHCP에서 할당된 주소에서 고정 IP 주소로 NIC를 재구성합니다. 무한이 아닌 DHCP 리스가 있는 NIC는 DHCP를 사용하도록 설정되어 있습니다.

무한 리스로 IP 주소를 설정하는 것은 Machine Config Operator를 사용하여 배포된 네트워크 구성과 호환되지 않습니다.

DHCP 서버가 무한 리스를 제공할 수 있는지 확인

DHCP 서버에서는 rfc2131 에서 지정하는 대로 무한 리스를 올바르게 설정하려면 4294967295초의 DHCP 만료 시간을 제공해야 합니다. DHCP 무한 리스 시간에 대해 더 적은 값을 반환하면 노드는 오류를 보고하고 노드에 대해 영구 IP가 설정되지 않습니다. RHEL 8에서는 dhcpd 가 무한 리스를 제공하지 않습니다. 프로비저너 노드를 사용하여 무한 리스 시간에 동적 IP 주소를 제공하려면 dhcpd 대신 dnsmasq 를 사용합니다.

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

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

배포 후 IP 주소를 수동으로 변경하지 마십시오.

배포 후 작업자 노드의 IP 주소를 수동으로 변경하지 마십시오. 배포 후 작업자 노드의 IP 주소를 변경하려면 작업자 노드를 예약 불가로 표시하고 pod를 비우고 노드를 삭제하고 새 IP 주소로 다시 생성해야 합니다. 자세한 내용은 "노드 작업"을 참조하십시오. 배포 후 컨트롤 플레인 노드의 IP 주소를 변경하려면 지원부에 문의하십시오.

스토리지 인터페이스에 DHCP 예약이 필요합니다.

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

사용법호스트 이름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>

Master-0

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

<ip>

Master-1

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

<ip>

Master-2

openshift-master-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 확인이 필요합니다.

10.2.4.6. Network Time Protocol (NTP)

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

중요

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

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

10.2.4.7. 상태 중심 네트워크 구성 요구 사항(기술 프리뷰)

OpenShift Container Platform은 kubernetes-nmstate를 사용하여 클러스터 노드의 보조 네트워크 인터페이스에 추가 설치 후 상태 기반 네트워크 구성을 지원합니다. 예를 들어 시스템 관리자는 스토리지 네트워크에 설치한 후 클러스터 노드에 보조 네트워크 인터페이스를 구성할 수 있습니다.

참고

pod를 예약하기 전에 설정이 수행되어야 합니다.

상태 중심 네트워크 구성에는 kubernetes-nmstate를 설치해야 하며 클러스터 노드에서 실행 중인 Network Manager도 필요합니다. 자세한 내용은 OpenShift Virtualization > Kubernetes NMState(기술 프리뷰)를 참조하십시오.

10.2.4.8. 대역 외 관리 IP 주소의 포트 액세스

대역 외 관리 IP 주소는 노드와 별도의 네트워크에 있습니다. 대역 외 관리가 설치 중에 프로비저닝 노드와 통신할 수 있도록 대역 외 관리 IP 주소에는 부트스트랩 호스트의 포트 80 및 OpenShift Container Platform 컨트롤 플레인 호스트의 포트 6180 에 대한 액세스 권한이 부여되어야 합니다.

10.2.5. 노드 설정

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

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

주의

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

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

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를 설치하려면 다음과 같이합니다.

PXE부팅 순서

NIC1 PXE 지원 provisioning 네트워크

1

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

2

참고

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

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

PXE부팅 순서

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

1

provisioning 네트워크없이 노드 설정

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

NIC네트워크VLAN

NICx

baremetal

<baremetal_vlan>

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

중요

프로비저닝 네트워크는 선택 사항이지만 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를 지원하지 않습니다.

Fujitsu iRMC의 호환성 지원 모듈 구성

CSM(호환성 지원 모듈) 구성은 UEFI 시스템과의 기존 BIOS 이전 버전과의 호환성을 지원합니다. Fujitsu iRMC를 사용하여 클러스터를 배포할 때 CSM을 구성해야 합니다. 그렇지 않으면 설치에 실패할 수 있습니다.

참고

특정 노드 유형에 대한 CSM 구성에 대한 자세한 내용은 노드의 하드웨어 가이드를 참조하십시오.

사전 요구 사항

  • Secure Boot Control을 비활성화했는지 확인합니다. 보안Secure Boot ConfigurationSecure Boot Control 에서 기능을 비활성화할 수 있습니다.

프로세스

  1. 노드를 부팅하고 BIOS 메뉴를 선택합니다.
  2. 고급 탭의 목록에서 CSM Configuration 을 선택합니다.
  3. Launch CSM 옵션을 활성화하고 다음 값을 설정합니다.

    항목

    부팅 옵션 필터

    UEFI 및 레거시

    PXE OpROM 정책 시작

    UEFI 전용

    Storage OpROM 정책 시작

    UEFI 전용

    기타 PCI 장치om 우선순위

    UEFI 전용

10.2.6. 대역 외 관리

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

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

대역 외 관리 설정은 이 문서에서 다루지 않습니다. 대역 외 관리를 위해 별도의 관리 네트워크를 설정하는 것이 좋습니다. 그러나 provisioning 네트워크 또는 baremetal 네트워크를 사용하는 것은 유효한 옵션입니다.

10.2.7. 설치에 필요한 데이터

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

  • 대역 외 관리 IP

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

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

  • NIC (프로비저닝) MAC 주소
  • NIC (baremetal) MAC 주소

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

  • NIC (baremetal) MAC 주소

10.2.8. 노드의 유효성 검사 체크리스트

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

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

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

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