지원되는 OpenShift Container Platform 설치 프로그램

Assisted Installer for OpenShift Container Platform 2022

지원되는 설치 관리자 사용자 가이드

Red Hat Customer Content Services

초록

지원 설치 관리자 및 사용에 대한 정보

1장. 지원 설치 관리자를 사용하여 온프레미스 클러스터 설치

지원 설치 관리자를 사용하여 온프레미스 하드웨어 또는 온프레미스 VM에 OpenShift Container Platform을 설치할 수 있습니다. 지원 설치 관리자를 사용하여 OpenShift Container Platform을 설치하면 x86_64,ppc64le,s390xarm64 CPU 아키텍처가 지원됩니다.

참고

현재 IBM zSystems(s390x)에 OpenShift Container Platform을 설치하는 것은 RHEL KVM 설치에서만 지원됩니다.

1.1. 지원 설치 관리자 사용

OpenShift Container Platform 지원 설치 프로그램은 Red Hat Hybrid Cloud Console 에서 제공되는 사용자 친화적인 설치 솔루션입니다. 지원 설치 프로그램은 베어 메탈 및 vSphere 인프라에 중점을 두고 있는 다양한 배포 플랫폼을 지원합니다.

지원 설치 관리자는 설치 기능을 서비스로 제공합니다. 이 SaaS(Software-as-a-Service) 접근 방식은 다음과 같은 이점이 있습니다.

  • 웹 사용자 인터페이스: 웹 사용자 인터페이스는 사용자가 수동으로 설치 구성 파일을 생성할 필요 없이 클러스터 설치를 수행합니다.
  • 부트스트랩 노드가 없음: 지원 설치 프로그램으로 설치할 때 부트스트랩 노드가 필요하지 않습니다. 부트스트랩 프로세스는 클러스터 내의 노드에서 실행됩니다.
  • 호스팅: 지원 설치 관리자 호스트:

    • Ignition 파일
    • 설치 구성
    • 검색 ISO
    • 설치 프로그램
  • 간소화된 설치 워크플로: 배포에 OpenShift Container Platform에 대한 심층적인 지식이 필요하지 않습니다. 지원 설치 관리자는 적절한 기본값을 제공하고 다음과 같은 설치 프로그램을 서비스로 제공합니다.

    • OpenShift Container Platform 설치 프로그램을 로컬에서 설치 및 실행할 필요가 없습니다.
    • 최신 테스트된 z-stream 릴리스까지 설치 프로그램의 최신 버전을 확인합니다. 필요한 경우 이전 버전은 계속 사용할 수 있습니다.
    • OpenShift Container Platform 설치 프로그램을 로컬로 실행할 필요 없이 API를 사용하여 빌드 자동화를 활성화합니다.
  • 고급 네트워킹: 지원 설치 프로그램은 SDN 및 OVN을 사용한 IPv4 네트워킹, OVN을 사용하는 IPv6 및 듀얼 스택 네트워킹, NMState 기반 고정 IP 주소 지정, HTTP/S 프록시를 지원합니다. OVN은 OpenShift Container Platform 4.12 이상 릴리스의 기본 CNI(Container Network Interface)이지만 SDN을 사용하도록 전환할 수 있습니다.
  • 설치 사전 검증: 지원 설치 관리자는 설치 전에 구성을 검증하여 높은 성공 가능성을 보장합니다. 검증에는 다음이 포함됩니다.

    • 네트워크 연결 확인
    • 충분한 네트워크 대역폭 확인
    • 레지스트리에 대한 연결 확인
    • 업스트림 DNS가 필요한 도메인 이름을 확인할 수 있는지 확인
    • 클러스터 노드 간 시간 동기화 보장
    • 클러스터 노드가 최소 하드웨어 요구 사항을 충족하는지 확인
    • 설치 구성 매개변수 검증
  • REST API: 지원 설치 프로그램에는 자동화를 활성화하는 REST API가 있습니다.

지원 설치 관리자는 선택적 HTTP/S 프록시를 포함하여 연결된 환경의 온프레미스에 OpenShift Container Platform을 설치할 수 있도록 지원합니다. 다음을 설치할 수 있습니다.

  • 고가용성 OpenShift Container Platform 또는 Single Node OpenShift (SNO)
  • 전체 플랫폼 통합 또는 기타 가상화 플랫폼이 있는 베어 메탈 또는 vSphere의 OpenShift Container Platform
  • 필요한 경우 OpenShift Virtualization 및 OpenShift Data Foundation (이전 OpenShift Container Storage)

사용자 인터페이스는 자동화가 없거나 필요하지 않은 직관적인 대화형 워크플로우를 제공합니다. 사용자는 REST API를 사용하여 설치를 자동화할 수도 있습니다.

지원 설치 프로그램으로 OpenShift Container Platform 클러스터를 생성하려면 Install OpenShift with the Assisted Installer 를 참조하십시오.

1.2. 지원 설치 관리자의 API 지원

지원 설치 관리자에 지원되는 API는 사용 중단 공지 후 최소 3개월 동안 안정적입니다.

2장. 지원 설치 관리자를 사용하여 설치 준비

클러스터를 설치하기 전에 클러스터 노드와 네트워크가 요구사항을 충족하는지 확인해야 합니다.

2.1. 사전 요구 사항

  • OpenShift Container Platform 설치 및 업데이트 프로세스에 대한 세부 사항을 검토하셨습니다.
  • 클러스터 설치 방법 선택 및 사용자를 위한 준비에 대한 문서를 읽습니다.
  • 방화벽을 사용하는 경우 지원 설치 프로그램이 작동하는 데 필요한 리소스에 액세스할 수 있도록 방화벽을 구성해야 합니다.

2.2. 지원되는 설치 관리자 사전 요구 사항

지원 설치 관리자는 설치에 성공하기 위해 다음과 같은 사전 요구 사항의 유효성을 검사합니다.

2.2.1. CPU 아키텍처

지원 설치 프로그램은 다음 CPU 아키텍처에서 지원됩니다.

  • x86_64
  • arm64
  • ppc64le
  • s390x

2.2.2. 하드웨어

지원 설치 관리자에는 CPU 코어 8개, 16.00GiB RAM, 100GB 디스크 크기가 있는 하나의 호스트가 필요합니다.

컨트롤 플레인의 경우 호스트에 다음과 같은 리소스가 있어야 합니다.

  • 4개의 CPU 코어
  • 16.00GiB RAM
  • 100GB 스토리지
  • etcd wal_fsync_duration_seconds의 경우 10MS 쓰기 속도 또는 그 이하

작업자의 경우 각 호스트에는 다음과 같은 리소스가 있어야 합니다.

  • 2개의 CPU 코어
  • 8.00GiB RAM
  • 100GB 스토리지

vMware 유형의 호스트의 경우 platform이 vSphere가 아닌 경우에도 clusterSet disk.enableUUIDtrue 로 설정합니다.

2.2.3. 네트워킹

네트워크는 다음 요구 사항을 충족해야 합니다.

  • 고정 IP 주소를 사용하지 않는 한 DHCP 서버.
  • 기본 도메인 이름입니다. 다음 요구 사항이 충족되었는지 확인해야 합니다.

    • *.<cluster_name>.<base_domain >과 같은 와일드카드가 없거나 설치가 진행되지 않습니다.
    • api.<cluster_name>.<base_domain>의 DNS A/AAAA 레코드입니다.
    • *.apps.<cluster_name>.<base_domain > 에 와일드카드가 있는 DNS A/AAAA 레코드입니다.
  • 방화벽 외부의 사용자가 oc CLI 툴을 통해 클러스터에 액세스할 수 있도록 하려면 API URL에 대해 포트 6443 이 열립니다.
  • 방화벽 외부의 사용자가 콘솔에 액세스할 수 있도록 하려면 콘솔에 대해 포트 443 이 열립니다.
  • 사용자 관리 네트워킹을 사용할 때 클러스터의 각 노드에 대한 DNS A/AAAA 레코드가 진행되지 않거나 설치가 진행되지 않습니다. 클러스터에 연결하기 위해 설치가 완료된 후 클러스터 관리 네트워킹을 사용하는 경우 클러스터의 각 노드에 DNS A/AAAA 레코드가 필요하지만 Cluster Managed Networking을 사용할 때 A/AAAA 레코드 없이 설치할 수 있습니다.
  • 고정 IP 주소를 사용할 때 사전 설정된 호스트 이름으로 부팅하려는 경우 클러스터의 각 노드에 대한 DNS PTR 레코드입니다. 그렇지 않으면 지원 설치 관리자에 노드의 이름을 네트워크 인터페이스 MAC 주소로 변경할 고정 IP 주소를 사용할 때 자동 노드 이름 변경 기능이 있습니다.
중요

최상위 도메인 등록 기관의 DNS A/AAAA 레코드 설정은 업데이트하는 데 상당한 시간이 걸릴 수 있습니다. 설치 지연을 방지하기 위해 설치 전에 A/AAAA 레코드 DNS 설정이 작동하는지 확인합니다.

OpenShift Container Platform 클러스터 네트워크도 다음 요구사항을 충족해야 합니다.

  • 모든 클러스터 노드 간 연결
  • 인터넷에 각 노드의 연결
  • 클러스터 노드 간 시간 동기화를 위해 NTP 서버에 액세스

2.2.4. 사전 진행 검증

지원 설치 관리자는 복잡한 설치 후 문제 해결을 제거하여 클러스터가 설치 전에 사전 요구 사항을 충족하는지 확인하므로 시간과 노력을 많이 절약할 수 있습니다. 노드에 소프트웨어를 설치하기 전에 지원 설치 프로그램은 다음 검증을 수행합니다.

  • 네트워크 연결 확인
  • 충분한 네트워크 대역폭 확인
  • 레지스트리에 대한 연결 확인
  • 모든 업스트림 DNS가 필요한 도메인 이름을 확인할 수 있는지 확인합니다.
  • 클러스터 노드 간 시간 동기화 보장
  • 클러스터 노드가 최소 하드웨어 요구 사항을 충족하는지 확인합니다.
  • 설치 구성 매개변수 검증

지원 설치 프로그램이 진행 중인 요구 사항을 성공적으로 확인하지 않으면 설치가 진행되지 않습니다.

3장. 지원 설치 관리자 UI로 설치

클러스터 노드 및 네트워크 요구 사항이 충족되는지 확인한 후 클러스터 설치를 시작할 수 있습니다.

3.1. 사전 설치 고려 사항

지원 설치 관리자를 사용하여 OpenShift Container Platform을 설치하기 전에 다음과 같은 구성 옵션을 고려해야 합니다.

  • 사용할 기본 도메인
  • 설치할 OpenShift Container Platform 제품 버전
  • 전체 클러스터 또는 단일 노드 OpenShift 설치 여부
  • DHCP 서버 또는 정적 네트워크 구성 사용 여부
  • IPv4 또는 듀얼 스택 네트워킹 사용 여부
  • OpenShift Virtualization 설치 여부
  • Red Hat OpenShift Data Foundation 설치 여부
  • 다중 클러스터 엔진 설치 여부
  • vSphere 또는 Nutanix에 설치할 때 플랫폼과 통합할지 여부

3.2. 클러스터 세부 정보 설정

지원 설치 관리자 웹 사용자 인터페이스를 사용하여 클러스터를 생성하려면 다음 절차를 사용하십시오.

절차

  1. Red Hat Hybrid Cloud Console 에 로그인합니다.
  2. Red Hat OpenShift 타일에서 애플리케이션 스케일링을 클릭합니다.
  3. 메뉴에서 클러스터를 클릭합니다.
  4. 클러스터 생성을 클릭합니다.
  5. Datacenter 탭을 클릭합니다.
  6. 지원 설치 관리자에서 클러스터 생성을 클릭합니다.
  7. 클러스터 이름 필드에 클러스터 이름을 입력합니다.
  8. Base domain 필드에 클러스터의 기본 도메인을 입력합니다. 클러스터의 모든 하위 도메인은 이 기본 도메인을 사용합니다.

    참고

    기본 도메인은 유효한 DNS 이름이어야 합니다. 기본 도메인에 대해 와일드카드 도메인이 설정되어 있지 않아야 합니다.

  9. 설치할 OpenShift Container Platform 버전을 선택합니다.

    참고

    IBM Power 및 IBM zSystems 플랫폼의 경우 OpenShift Container Platform 버전 4.13 이상만 지원됩니다.

  10. 선택사항: 단일 노드에 OpenShift Container Platform을 설치하려면 Install single node Openshift (SNO) 를 선택합니다.

    참고

    현재 SNO는 IBM zSystems 및 IBM Power 플랫폼에서 지원되지 않습니다.

  11. 선택 사항: 지원 설치 프로그램에 이미 계정에 풀 시크릿이 연결되어 있습니다. 다른 풀 시크릿을 사용하려면 Edit pull secret 을 선택합니다.
  12. 선택사항: 지원 설치 관리자의 기본값은 x86_64 CPU 아키텍처를 사용합니다. 다른 아키텍처에 OpenShift Container Platform을 설치하는 경우 사용할 해당 아키텍처를 선택합니다. 유효한 값은 arm64,ppc64les390x 입니다. 일부 기능은 arm64,ppc64les390x CPU 아키텍처에서는 사용할 수 없습니다.
  13. 선택사항: 지원 설치 관리자의 기본값은 DHCP 네트워킹입니다. DHCP 예약 대신 클러스터 노드의 고정 IP 구성, 브리지 또는 본딩을 사용하는 경우 고정 IP, 브리지 및 본딩을 선택합니다.
  14. 선택 사항: 설치 디스크의 암호화를 활성화하려면 설치 디스크 의 암호화를 활성화 하면 컨트롤 플레인 노드를 선택하고 단일 노드 OpenShift의 작업자 를 선택할 수 있습니다. 다중 노드 클러스터의 경우 컨트롤 플레인 노드를 선택하여 컨트롤 플레인 노드 설치 디스크를 암호화하고 Workers 를 선택하여 작업자 노드 설치 디스크를 암호화할 수 있습니다.
중요

기본 도메인, SNO 확인란, CPU 아키텍처, 호스트의 네트워크 구성 또는 설치가 시작된 후 디스크 암호화를 변경할 수 없습니다.

3.3. 선택사항: 정적 네트워크 구성

지원 설치 관리자는 SDN 및 OVN을 사용한 IPv4 네트워킹을 지원하며 OVN을 사용하는 IPv6 및 듀얼 스택 네트워킹만 지원합니다. 지원 설치 관리자는 IP 주소/MAC 주소 매핑을 사용하여 정적 네트워크 인터페이스를 사용하여 네트워크 구성을 지원합니다. 또한 지원 설치 관리자는 호스트에 대한 선언적 네트워크 관리자 API인 NMState 라이브러리를 사용하여 호스트 네트워크 인터페이스 구성을 지원합니다. NMState를 사용하여 고정 IP 주소 지정, 본딩, VLAN 및 기타 고급 네트워킹 기능이 있는 호스트를 배포할 수 있습니다. 먼저 네트워크 전체 구성을 설정해야 합니다. 그런 다음 각 호스트에 대해 호스트별 구성을 생성해야 합니다.

참고

z/VM을 사용하여 IBM Z에 설치하는 경우 정적 네트워크 및 NMState에 대해 z/VM 노드 및 vSwitch가 올바르게 구성되었는지 확인합니다. 또한 z/VM 노드에는 MAC 주소 풀로 인해 NMState에 문제가 발생할 수 있으므로 고정된 MAC 주소가 할당되어 있어야 합니다.

절차

  1. 인터넷 프로토콜 버전을 선택합니다. 유효한 옵션은 IPv4듀얼 스택 입니다.
  2. 클러스터 호스트가 공유 VLAN에 있는 경우 VLAN ID를 입력합니다.
  3. 네트워크 전체 IP 주소를 입력합니다. 듀얼 스택 네트워킹을 선택한 경우 IPv4 및 IPv6 주소를 모두 입력해야 합니다.

    1. CIDR 표기법으로 클러스터 네트워크의 IP 주소 범위를 입력합니다.
    2. 기본 게이트웨이 IP 주소를 입력합니다.
    3. DNS 서버 IP 주소를 입력합니다.
  4. 호스트별 구성을 입력합니다.

    1. 단일 네트워크 인터페이스를 사용하는 고정 IP 주소만 설정하는 경우 양식 보기를 사용하여 각 호스트의 IP 주소와 MAC 주소를 입력합니다.
    2. 여러 인터페이스, 본딩 또는 기타 고급 네트워킹 기능을 사용하는 경우 YAML 보기를 사용하고 NMState 구문을 사용하는 각 호스트에 대해 원하는 네트워크 상태를 입력합니다. 그런 다음 네트워크 구성에 사용된 각 호스트 인터페이스의 MAC 주소 및 인터페이스 이름을 추가합니다.

추가 리소스

3.4. Operator 구성

지원 설치 프로그램은 특정 Operator가 구성된 상태에서 설치할 수 있습니다. Operator는 다음과 같습니다.

  • OpenShift Virtualization
  • Kubernetes용 MCCE(Multicluster Engine)
  • OpenShift Data Foundation
  • LVM(Logical Volume Manager) 스토리지
중요

하드웨어 요구 사항, 스토리지 고려 사항, 상호 종속 항목 및 추가 설치 지침과 함께 각 Operator에 대한 자세한 설명은 추가 리소스를 참조하십시오.

이 단계는 선택 사항입니다. Operator를 선택하지 않고 설치를 완료할 수 있습니다.

절차

  1. OpenShift Virtualization을 설치하려면 OpenShift Virtualization 설치를 선택합니다.
  2. MCCE(Multicluster Engine)를 설치하려면 다중 클러스터 엔진 설치를 선택합니다.
  3. OpenShift Data Foundation을 설치하려면 OpenShift Data Foundation 설치를 선택합니다.
  4. 논리 볼륨 관리자를 설치하려면 Install Logical Volume Manager 를 선택합니다.
  5. 다음을 클릭하여 다음 단계를 진행합니다.

3.5. 클러스터에 호스트 추가

클러스터에 하나 이상의 호스트를 추가해야 합니다. 클러스터에 호스트를 추가하려면 검색 ISO를 생성해야 합니다. 검색 ISO는 에이전트를 사용하여 RHCOS(Red Hat Enterprise Linux CoreOS) in-memory를 실행합니다.

클러스터의 각 호스트에 대해 다음 절차를 수행합니다.

절차

  1. 호스트 추가 버튼을 클릭하고 설치 미디어를 선택합니다.

    1. Minimal image file: Provision with virtual media 를 선택하여 부팅에 필요한 데이터를 가져올 작은 이미지를 다운로드합니다. 노드에는 가상 미디어 기능이 있어야 합니다. 이 방법은 x86_64arm64 아키텍처에 권장되는 방법입니다.
    2. Full image file: Provision with physical media 를 선택하여 더 큰 전체 이미지를 다운로드합니다. 이는 ppc64le 아키텍처에 권장되는 방법입니다.
    3. iPXE: Provision을 네트워크 서버에서 선택하여 iPXE를 사용하여 호스트를 부팅합니다. 이 방법은 s390x 아키텍처에 권장되는 방법입니다.

      참고

      RHEL KVM에 iPXE를 사용하여 설치하는 경우 경우에 따라 KVM 호스트의 VM이 처음 부팅될 때 재부팅되지 않으므로 수동으로 시작해야 합니다.

  2. 선택 사항: 클러스터 호스트가 프록시를 사용해야 하는 방화벽 뒤에 있는 경우 클러스터 전체 프록시 설정 구성을 선택합니다. 프록시 서버의 HTTP 및 HTTPS URL에 대한 사용자 이름, 암호, IP 주소 및 포트를 입력합니다.
  3. 선택 사항: core 사용자로 클러스터 노드에 연결할 수 있도록 SSH 공개 키를 추가합니다. 클러스터 노드에 로그인하면 설치 중에 디버깅 정보를 제공할 수 있습니다.

    중요

    재해 복구 및 디버깅이 필요한 프로덕션 환경에서는이 단계를 생략하지 마십시오.

    1. 로컬 시스템에 기존 SSH 키 쌍이 없는 경우 클러스터 노드 SSH 액세스에 대한 키 쌍 생성 단계를 따르십시오.
    2. SSH 공개 키 필드에서 찾아보기 를 클릭하여 SSH 공개 키가 포함된 id_rsa.pub 파일을 업로드합니다. 또는 파일을 파일 관리자의 필드로 끌어다 놓습니다. 파일 관리자에서 파일을 보려면 메뉴에서 숨겨진 파일 표시를 선택합니다.
  4. 선택 사항: 클러스터 호스트가 재암호화 MITM(man-in-the-middle) 프록시를 사용하는 네트워크에 있거나 클러스터가 컨테이너 이미지 레지스트리와 같은 다른 용도로 인증서를 신뢰해야 하는 경우 클러스터 전체에서 신뢰할 수 있는 인증서 구성을 선택합니다. X.509 형식으로 추가 인증서를 추가합니다.
  5. 필요한 경우 검색 이미지를 구성합니다.
  6. 선택 사항: 플랫폼에 설치하고 플랫폼과 통합 하려면 가상화 플랫폼과 통합을 선택합니다. 모든 호스트를 부팅하고 호스트 인벤토리에 표시되는지 확인해야 합니다. 모든 호스트가 동일한 플랫폼에 있어야 합니다.
  7. Discovery ISO 생성을 클릭하거나 스크립트 파일 생성을 클릭합니다.
  8. 검색 ISO 또는 iPXE 스크립트를 다운로드합니다.
  9. 검색 이미지 또는 iPXE 스크립트를 사용하여 호스트를 부팅합니다.

3.6. 호스트 구성

검색 ISO로 호스트를 부팅하면 호스트가 페이지 하단에 있는 테이블에 표시됩니다. 선택 옵션으로 각 호스트의 호스트 이름과 역할을 구성할 수 있습니다. 필요한 경우 호스트를 삭제할 수도 있습니다.

절차

  1. 호스트의 Options (Options) 메뉴에서 Change hostname 을 선택합니다. 필요한 경우 호스트의 새 이름을 입력하고 변경을 클릭합니다. 각 호스트에 유효한 고유한 호스트 이름이 있는지 확인해야 합니다.

    또는 작업 목록에서 호스트 이름 변경을 선택하여 선택한 여러 호스트의 이름을 변경합니다. 호스트 이름 변경 대화 상자에서 새 이름을 입력하고 {{n}} 를 포함하여 각 호스트 이름을 고유하게 설정합니다. 그런 다음 변경을 클릭합니다.

    참고

    사용자가 입력할 때 프리뷰 창에서 새 이름이 나타나는 것을 확인할 수 있습니다. 호스트당 한 자리 증분을 제외하고 선택한 모든 호스트에 대해 이름이 동일합니다.

  2. Options (Options) 메뉴에서 Delete host 를 선택하여 호스트를 삭제할 수 있습니다. 삭제를 클릭하여 삭제를 확인합니다.

    또는 Actions 목록에서 Delete 를 선택하여 선택한 여러 호스트를 동시에 삭제합니다. 그런 다음 호스트 삭제를 클릭합니다.

    참고

    일반 배포에서 클러스터에 3개 이상의 호스트가 있을 수 있으며, 이 중 세 개는 컨트롤 플레인 호스트여야 합니다. 컨트롤 플레인이라고도 하는 호스트를 삭제하거나 두 개의 호스트만 남아 있는 경우 시스템이 준비되지 않았음이라는 메시지가 표시됩니다. 호스트를 복원하려면 검색 ISO에서 호스트를 재부팅해야 합니다.

  3. 호스트의 Options (Options) 메뉴에서 선택적으로 호스트 이벤트 보기 를 선택합니다. 목록에 있는 이벤트는 순서대로 표시됩니다.
  4. 멀티 호스트 클러스터의 경우 호스트 이름 옆에 있는 Role 열에서 메뉴를 클릭하여 호스트의 역할을 변경할 수 있습니다.

    역할을 선택하지 않으면 지원 설치 프로그램이 자동으로 역할을 할당합니다. 컨트롤 플레인 노드의 최소 하드웨어 요구 사항은 작업자 노드를 초과합니다. 호스트에 역할을 할당하는 경우 최소 하드웨어 요구 사항을 충족하는 호스트에 컨트롤 플레인 역할을 할당해야 합니다.

  5. Status (상태) 링크를 클릭하여 호스트에 대한 하드웨어, 네트워크 및 Operator 검증을 확인합니다.
  6. 호스트 이름 왼쪽에 있는 화살표를 클릭하여 호스트 세부 정보를 확장합니다.

모든 클러스터 호스트가 Ready 상태로 표시되면 다음 단계를 진행합니다.

3.7. 스토리지 디스크 구성

클러스터 호스트를 검색하고 구성한 후 선택적으로 각 호스트에 대한 스토리지 디스크를 구성할 수 있습니다.

여기에서 가능한 모든 호스트 구성은 호스트 구성 섹션에서 설명합니다. 링크는 아래 추가 리소스를 참조하십시오.

절차

  1. 호스트 이름 옆에 있는 확인란의 왼쪽에 있는 를 클릭하여 해당 호스트의 스토리지 디스크를 표시합니다.
  2. 호스트에 대한 스토리지 디스크가 여러 개인 경우 설치 디스크 역할을 할 다른 디스크를 선택할 수 있습니다. 디스크의 Role 드롭다운 목록을 클릭한 다음 Installation disk 를 선택합니다. 이전 설치 디스크의 역할이 None 으로 변경됩니다.
  3. 부팅 가능한 모든 디스크는 기본적으로 설치 중에 CDROM과 같은 읽기 전용 디스크를 제외하고 다시 포맷하기 위해 표시됩니다. 디스크가 다시 포맷되지 않도록 형식 확인란을 선택 취소합니다. 설치 디스크를 다시 포맷해야 합니다. 진행하기 전에 중요한 데이터를 백업하십시오.

모든 디스크 드라이브가 Ready 상태로 표시되면 다음 단계를 진행합니다.

추가 리소스

3.8. 네트워킹 구성

OpenShift Container Platform을 설치하기 전에 클러스터 네트워크를 구성해야 합니다.

절차

  1. 네트워킹 페이지에서 아직 선택하지 않은 경우 다음 중 하나를 선택합니다.

    • 클러스터 관리 네트워킹: 클러스터 관리 네트워킹을 선택하면 지원 설치 프로그램이 API 및 Ingress VIP 주소를 관리하기 위한 keepalived 및 VRRP(Virtual Router Redundancy Protocol)를 비롯한 표준 네트워크 토폴로지를 구성합니다.

      참고

      현재 Cluster-Managed Networking은 IBM zSystems 및 IBM Power in OpenShift Container Platform 버전 4.13에서 지원되지 않습니다.

    • 사용자 관리 네트워킹: 사용자 관리 네트워킹을 선택하면 비표준 네트워크 토폴로지를 사용하여 OpenShift Container Platform을 배포할 수 있습니다. 예를 들어 keepalived 및 VRRP 대신 외부 로드 밸런서로 배포하거나 여러 개별 L2 네트워크 세그먼트에 클러스터 노드를 배포하려는 경우.
  2. 클러스터 관리 네트워킹의 경우 다음 설정을 구성합니다.

    1. 시스템 네트워크를 정의합니다. 기본 네트워크를 사용하거나 서브넷을 선택할 수 있습니다.
    2. API 가상 IP 를 정의합니다. API 가상 IP는 모든 사용자가 상호 작용하고 플랫폼을 구성할 수 있는 끝점을 제공합니다.
    3. Ingress 가상 IP 를 정의합니다. Ingress 가상 IP는 클러스터 외부에서 이동하는 애플리케이션 트래픽에 대한 끝점을 제공합니다.
  3. 사용자 관리 네트워킹의 경우 다음 설정을 구성합니다.

    1. 네트워킹 스택 유형을 선택합니다.

      • IPv4: 호스트가 IPv4 만 사용하는 경우 이 유형을 선택합니다.
      • Dual-stack: 호스트가 IPv6와 함께 IPv4를 사용하는 경우 듀얼 스택을 선택할 수 있습니다.
    2. 시스템 네트워크를 정의합니다. 기본 네트워크를 사용하거나 서브넷을 선택할 수 있습니다.
    3. API 가상 IP 를 정의합니다. API 가상 IP는 모든 사용자가 상호 작용하고 플랫폼을 구성할 수 있는 끝점을 제공합니다.
    4. Ingress 가상 IP 를 정의합니다. Ingress 가상 IP는 클러스터 외부에서 이동하는 애플리케이션 트래픽에 대한 끝점을 제공합니다.
    5. 선택 사항: DHCP 서버를 통해 IP 할당을 선택하여 DHCP 서버를 사용하여 API IPIngress IP 를 자동으로 할당할 수 있습니다.
  4. 선택 사항: 고급 네트워킹 사용을 선택하여 다음 고급 네트워킹 속성을 구성합니다.

    • 클러스터 네트워크 CIDR: Pod IP 주소가 할당되는 IP 주소 블록을 정의합니다.
    • 클러스터 네트워크 호스트 접두사: 각 노드에 할당할 서브넷 접두사 길이를 정의합니다.
    • Service network CIDR: 서비스 IP 주소에 사용할 IP 주소를 정의합니다.
    • 네트워크 유형: 표준 네트워킹의 경우 SDN(소프트웨어 정의 네트워킹) 또는 IPv6, 듀얼 스택 네트워킹 및 통신 기능에 대해 OVN(Open Virtual Networking) 을 선택합니다. OpenShift Container Platform 4.12 이상 릴리스에서는 OVN이 기본 CNI(Container Network Interface)입니다.

추가 리소스

3.9. 설치 전 검증

지원 설치 관리자는 복잡한 설치 후 문제 해결을 제거하여 클러스터가 설치 전에 사전 요구 사항을 충족하는지 확인하므로 시간과 노력을 많이 절약할 수 있습니다. 클러스터를 설치하기 전에 클러스터와 각 호스트가 설치 사전 검증을 통과했는지 확인합니다.

추가 리소스

3.10. 클러스터 설치

구성을 완료한 후 모든 노드가 준비 상태가 되면 설치를 시작할 수 있습니다. 설치 프로세스는 상당한 시간이 소요되며 지원 설치 관리자 웹 콘솔에서 설치를 모니터링할 수 있습니다. 노드는 설치 중에 재부팅되고 설치 후 초기화됩니다.

절차

  1. Starte gin installation 을 누릅니다.
  2. Host Inventory (호스트 인벤토리) 목록의 Status (상태) 열에서 링크를 클릭하여 특정 호스트의 설치 상태를 확인합니다.

3.11. 설치 완료

클러스터를 설치하고 초기화한 후 지원 설치 프로그램은 설치가 완료되었음을 나타냅니다. 지원 설치 프로그램에서는 콘솔 URL, kubeadmin 사용자 이름 및 암호, kubeconfig 파일을 제공합니다. 또한 지원 설치 관리자는 OpenShift Container Platform 버전, 기본 도메인, CPU 아키텍처, API 및 Ingress IP 주소, 클러스터 및 서비스 네트워크 IP 주소를 포함한 클러스터 세부 정보를 제공합니다.

사전 요구 사항

  • oc CLI 툴을 설치했습니다.

절차

  1. kubeadmin 사용자 이름 및 암호를 복사합니다.
  2. kubeconfig 파일을 다운로드하여 작업 디렉터리 아래의 auth 디렉터리에 복사합니다.

    $ mkdir -p <working_directory>/auth
    $ cp kubeadmin <working_directory>/auth
    참고

    kubeconfig 파일은 설치를 완료한 후 24시간 동안 다운로드할 수 있습니다.

  3. kubeconfig 파일을 환경에 추가합니다.

    $ export KUBECONFIG=<your working directory>/auth/kubeconfig
  4. oc CLI 툴로 로그인합니다.

    $ oc login -u kubeadmin -p <password>

    & lt;password >를 kubeadmin 사용자의 암호로 바꿉니다.

  5. 웹 콘솔 URL을 클릭하거나 OpenShift 콘솔 시작을 클릭하여 콘솔을 엽니다.
  6. kubeadmin 사용자 이름 및 암호를 입력합니다. OpenShift Container Platform 콘솔의 지침에 따라 ID 공급자를 구성하고 경고 수신자를 구성합니다.
  7. OpenShift Container Platform 콘솔의 북마크를 추가합니다.
  8. 설치 후 플랫폼 통합 단계를 완료합니다.

4장. 지원 설치 관리자 API로 설치

클러스터 노드 및 네트워크 요구 사항이 충족되는지 확인한 후 지원 설치 관리자 API를 사용하여 클러스터 설치를 시작할 수 있습니다. API를 사용하려면 다음 절차를 수행해야 합니다.

  • API 인증을 설정합니다.
  • 풀 시크릿을 구성합니다.
  • 새 클러스터 정의를 등록합니다.
  • 클러스터의 인프라 환경을 생성합니다.

이러한 단계를 수행한 후에는 클러스터 정의를 수정하고, 검색 ISO를 생성하고, 호스트를 클러스터에 추가하고, 클러스터를 설치할 수 있습니다. 이 문서는 지원 설치 관리자 API의 모든 끝점을 다루지는 않지만 API 뷰어 또는 swagger.yaml 파일의 모든 끝점을 검토할 수 있습니다.

4.1. 선택사항: OpenShift Cluster Manager CLI 설치

OpenShift Cluster Manager(ocm) CLI 툴을 사용하면 명령줄에서 OpenShift Cluster Manager와 상호 작용할 수 있습니다. REST GET, POST, PATCH 및 DELETE 작업을 실행하고 API 토큰을 생성하고 다른 기능 간에 클러스터를 나열할 수 있습니다.

중요

OpenShift Cluster Manager CLI는 개발자 프리뷰 기능 전용입니다. 개발자 프리뷰 기능은 Red Hat에서 어떤 방식으로든 지원하지 않으며 완전한 기능이나 프로덕션에 준비되지 않습니다. 프로덕션 또는 비즈니스 크리티컬 워크로드에는 개발자 프리뷰 기능을 사용하지 마십시오. 개발자 프리뷰 기능을 사용하면 Red Hat 제품에 포함될 수 있는 제품 기능을 미리 미리 액세스할 수 있으므로 고객은 개발 과정에서 기능을 테스트하고 피드백을 제공할 수 있습니다. 이러한 기능에는 문서가 없을 수 있으며 언제든지 변경 또는 제거가 적용되며 테스트가 제한됩니다. Red Hat은 관련 SLA 없이 개발자 프리뷰 기능에 대한 피드백을 제출할 수 있는 방법을 제공할 수 있습니다.

사전 요구 사항

  • jq 를 설치합니다.
  • 클러스터 생성 권한이 있는 사용자로 OpenShift Cluster Manager 에 로그인합니다.

절차

  1. 메뉴에서 OpenShift 를 클릭합니다.
  2. 하위 메뉴에서 다운로드를 클릭합니다.
  3. OpenShift Cluster Manager API 토큰 의 토큰 섹션에서 API 토큰 보기 를 클릭합니다.
  4. 토큰 로드 를 클릭합니다.

    중요

    팝업 차단기를 비활성화합니다.

  5. API 토큰 섹션에서 오프라인 토큰을 복사합니다.
  6. 터미널에서 오프라인 토큰을 OFFLINE_TOKEN 변수로 설정합니다.

    $ export OFFLINE_TOKEN=<copied_api_token>
    작은 정보

    오프라인 토큰을 영구적으로 만들려면 프로필에 추가합니다.

  7. ocm CLI 다운로드를 클릭합니다.
  8. 다운로드한 파일을 경로에 복사합니다. 예를 들어 파일을 /usr/bin 또는 ~/.local/bin 에 복사하고 ocm 심볼릭 링크를 만듭니다.
  9. 인증 명령을 복사하여 터미널에 붙여넣고 Enter 키를 눌러 로그인하십시오.

    $ ocm login --token="${OFFLINE_TOKEN}"

4.2. REST API를 사용한 인증

API 호출에는 API 토큰을 사용한 인증이 필요합니다. API_TOKEN 을 변수 이름으로 사용하는 경우 REST API로 인증하기 위해 API 호출에 -H "Authorization: Bearer ${API_TOKEN}" 를 추가합니다.

참고

API 토큰은 15분 후에 만료됩니다.

사전 요구 사항

  • (선택 사항) OpenShift Cluster Manager (ocm) CLI 도구를 설치했습니다.

절차

  1. OFFLINE_TOKEN 을 사용하여 API_TOKEN 변수를 설정하여 사용자를 검증합니다.

    1. (선택 사항) 명령줄 터미널에서 다음 명령을 실행합니다.

      $ export API_TOKEN=$( \
        curl \
        --silent \
        --header "Accept: application/json" \
        --header "Content-Type: application/x-www-form-urlencoded" \
        --data-urlencode "grant_type=refresh_token" \
        --data-urlencode "client_id=cloud-services" \
        --data-urlencode "refresh_token=${OFFLINE_TOKEN}" \
        "https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token" \
        | jq --raw-output ".access_token" \
      )
    2. (선택 사항) 명령줄 터미널에서 ocm 클라이언트에 로그인합니다.

      $ ocm login --token="${OFFLINE_TOKEN}"

      그런 다음 API 토큰을 생성합니다.

      $ export API_TOKEN=$(ocm token)
  1. 토큰 생성 방법 중 하나의 경로에 스크립트를 생성합니다. 예를 들면 다음과 같습니다.

    $ vim ~/.local/bin/refresh-token
    export API_TOKEN=$( \
      curl \
      --silent \
      --header "Accept: application/json" \
      --header "Content-Type: application/x-www-form-urlencoded" \
      --data-urlencode "grant_type=refresh_token" \
      --data-urlencode "client_id=cloud-services" \
      --data-urlencode "refresh_token=${OFFLINE_TOKEN}" \
      "https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token" \
      | jq --raw-output ".access_token" \
    )

    그런 다음 파일을 저장합니다.

  2. 파일 모드를 변경하여 실행 가능하게 합니다.

    $ chmod +x ~/.local/bin/refresh-token
  3. API 토큰을 새로 고칩니다.

    $ source refresh-token
  4. 다음 명령을 실행하여 API에 액세스할 수 있는지 확인합니다.

    $ curl -s https://api.openshift.com/api/assisted-install/v2/component-versions -H "Authorization: Bearer ${API_TOKEN}" | jq

    출력 예

    {
      "release_tag": "v2.11.3",
      "versions": {
        "assisted-installer": "registry.redhat.io/rhai-tech-preview/assisted-installer-rhel8:v1.0.0-211",
        "assisted-installer-controller": "registry.redhat.io/rhai-tech-preview/assisted-installer-reporter-rhel8:v1.0.0-266",
        "assisted-installer-service": "quay.io/app-sre/assisted-service:78d113a",
        "discovery-agent": "registry.redhat.io/rhai-tech-preview/assisted-installer-agent-rhel8:v1.0.0-195"
      }
    }

4.3. 풀 시크릿 구성

대부분의 지원 설치 관리자 API 호출에는 풀 시크릿이 필요합니다. API 호출에서 참조할 수 있도록 파일에 풀 시크릿을 다운로드합니다. 가져오기 보안은 요청의 JSON 오브젝트에 값으로 포함될 JSON 오브젝트입니다. 따옴표를 이스케이프하려면 가져오기 시크릿 JSON을 포맷해야 합니다. 예를 들면 다음과 같습니다.

before

{"auths":{"cloud.openshift.com": ...

{\"auths\":{\"cloud.openshift.com\": ...

절차

  1. 메뉴에서 OpenShift 를 클릭합니다.
  2. 하위 메뉴에서 다운로드를 클릭합니다.
  3. Pull secret 아래의 토큰 섹션에서 다운로드를 클릭합니다.
  4. 쉘 변수의 풀 시크릿을 사용하려면 다음 명령을 실행합니다.

    $ export PULL_SECRET=$(cat ~/Downloads/pull-secret.txt | jq -R .)
  5. jq 를 사용하여 풀 시크릿 파일을 슬루프하려면 pull_secret 변수에서 참조하고 값을 tojson 으로 파이핑하여 올바르게 이스케이프된 JSON으로 포맷되도록 합니다. 예를 들면 다음과 같습니다.

    $ curl https://api.openshift.com/api/assisted-install/v2/clusters \
    -H "Authorization: Bearer ${API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d "$(jq --null-input \
            --slurpfile pull_secret ~/Downloads/pull-secret.txt ' 1
        {
            "name": "testcluster",
            "high_availability_mode": "None",
            "openshift_version": "4.11",
            "pull_secret": $pull_secret[0] | tojson, 2
            "base_dns_domain": "example.com"
        }
    ')"
    1
    풀 시크릿 파일을 슬루프합니다.
    2
    가져오기 시크릿을 포맷하여 JSON 형식을 이스케이프합니다.

4.4. 새 클러스터 등록

API에 새 클러스터 정의를 등록하려면 /v2/clusters 끝점을 사용합니다. 새 클러스터를 등록하려면 다음 설정이 필요합니다.

  • name
  • openshift-version
  • pull_secret
  • cpu_architecture

새 클러스터를 등록할 때 설정할 수 있는 필드에 대한 자세한 내용은 API 뷰어cluster-create-params 모델을 참조하십시오. olm_operators 필드를 설정할 때 Operator 설치에 대한 자세한 내용은 추가 리소스 를 참조하십시오.

클러스터 정의를 생성한 후 클러스터 정의를 수정하고 추가 설정에 대한 값을 제공할 수 있습니다. 클러스터 수정에 대한 자세한 내용은 추가 리소스 를 참조하십시오.

사전 요구 사항

  • 유효한 API_TOKEN 을 생성했습니다. 토큰은 15분마다 만료됩니다.
  • 풀 시크릿을 다운로드했습니다.
  • 선택 사항: $PULL_SECRET 변수에 풀 시크릿을 할당했습니다.

절차

  1. API 토큰을 새로 고칩니다.

    $ source refresh-token
  2. 새 클러스터를 등록합니다.

    1. 선택 사항: 요청에 풀 시크릿 파일을 슬리핑하여 새 클러스터를 등록할 수 있습니다.

      $ curl -s -X POST https://api.openshift.com/api/assisted-install/v2/clusters \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d "$(jq --null-input \
          --slurpfile pull_secret ~/Downloads/pull-secret.txt '
      {
          "name": "testcluster",
          "openshift_version": "4.11",
          "cpu_architecture" : "<architecture_name>" 1
          "high_availability_mode": <cluster_type>, 2
          "base_dns_domain": "example.com",
          "pull_secret": $pull_secret[0] | tojson
      }
      ')" | jq '.id'
      참고
      1
      다음 값 중 하나를 사용합니다. x86_64,arm64,ppc64le,s390x,multi.
      2
      full 기본값을 사용하여 다중 노드 OpenShift 클러스터를 나타내거나 단일 노드 OpenShift 클러스터를 나타내는 none 을 사용합니다.
    2. 선택 사항: 새 클러스터를 JSON 파일에 작성한 다음 요청에서 참조하여 새 클러스터를 등록할 수 있습니다.

      cat << EOF > cluster.json
      {
        "name": "testcluster",
        "openshift_version": "4.11",
        "high_availability_mode": "<cluster_type>",
        "base_dns_domain": "example.com",
        "pull_secret": $PULL_SECRET
      }
      EOF
      $ curl -s -X POST "https://api.openshift.com/api/assisted-install/v2/clusters" \
        -d @./cluster.json \
        -H "Content-Type: application/json" \
        -H "Authorization: Bearer $API_TOKEN" \
        | jq '.id'
  3. 반환된 cluster_idCLUSTER_ID 변수에 할당하고 이를 내보냅니다.

    $ export CLUSTER_ID=<cluster_id>
    참고

    터미널 세션을 닫는 경우 CLUSTER_ID 변수를 새 터미널 세션에서 다시 내보내야 합니다.

  4. 새 클러스터의 상태를 확인합니다.

    $ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID" \
      -H "Content-Type: application/json" \
      -H "Authorization: Bearer $API_TOKEN" \
      | jq

새 클러스터 정의를 등록한 후 클러스터의 인프라 환경을 생성합니다.

참고

인프라 환경을 생성할 때까지 지원 설치 관리자 사용자 인터페이스에서 클러스터 구성 설정을 확인할 수 없습니다.

4.5. 클러스터 수정

API를 사용하여 클러스터 정의를 수정하려면 /v2/clusters/{cluster_id} 끝점을 사용합니다. 클러스터 리소스 수정은 네트워크 유형 변경 또는 사용자 관리 네트워킹 활성화와 같은 설정을 추가하는 일반적인 작업입니다. 클러스터 정의를 수정할 때 설정할 수 있는 필드에 대한 자세한 내용은 API 뷰어v2-cluster-update-params 모델을 참조하십시오. 클러스터 내에서 Operator 정의에 대한 자세한 내용은 Operator 설치 및 수정 을 참조하십시오.

사전 요구 사항

  • 새 클러스터 리소스가 생성되어 있습니다.

절차

  1. API 토큰을 새로 고칩니다.

    $ source refresh-token
  2. 클러스터를 수정합니다. 예를 들면 다음과 같습니다.

    $ curl https://api.openshift.com/api/assisted-install/v2/clusters/${CLUSTER_ID} \
    -X PATCH \
    -H "Authorization: Bearer ${API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d '
    {
        "ssh_public_key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDZrD4LMkAEeoU2vShhF8VM+cCZtVRgB7tqtsMxms2q3TOJZAgfuqReKYWm+OLOZTD+DO3Hn1pah/mU3u7uJfTUg4wEX0Le8zBu9xJVym0BVmSFkzHfIJVTn6SfZ81NqcalisGWkpmkKXVCdnVAX6RsbHfpGKk9YPQarmRCn5KzkelJK4hrSWpBPjdzkFXaIpf64JBZtew9XVYA3QeXkIcFuq7NBuUH9BonroPEmIXNOa41PUP1IWq3mERNgzHZiuU8Ks/pFuU5HCMvv4qbTOIhiig7vidImHPpqYT/TCkuVi5w0ZZgkkBeLnxWxH0ldrfzgFBYAxnpTU8Ih/4VhG538Ix1hxPaM6cXds2ic71mBbtbSrk+zjtNPaeYk1O7UpcCw4jjHspU/rVV/DY51D5gSiiuaFPBMucnYPgUxy4FMBFfGrmGLIzTKiLzcz0DiSz1jBeTQOX++1nz+KDLBD8CPdi5k4dq7lLkapRk85qdEvgaG5RlHMSPSS3wDrQ51fD8= user@hostname"
    }
    ' | jq

4.6. 새 인프라 환경 등록

지원 설치 관리자 API에 새 클러스터 정의를 등록한 후 v2/infra-envs 끝점을 사용하여 인프라 환경을 생성합니다. 새 인프라 환경을 등록하려면 다음 설정이 필요합니다.

  • name
  • pull_secret
  • cpu_architecture

새 인프라 환경을 등록할 때 설정할 수 있는 필드에 대한 자세한 내용은 API 뷰어infra-env-create-params 모델을 참조하십시오. 인프라 환경을 생성한 후 수정할 수 있습니다. 새 인프라 환경을 생성할 때 cluster_id 를 포함하는 것이 좋습니다. cluster_id 는 인프라 환경을 클러스터 정의와 연결합니다. 새 인프라 환경을 생성할 때 지원 설치 관리자도 검색 ISO를 생성합니다.

사전 요구 사항

  • 유효한 API_TOKEN 을 생성했습니다. 토큰은 15분마다 만료됩니다.
  • 풀 시크릿을 다운로드했습니다.
  • 선택 사항: 새 클러스터 정의를 등록하고 cluster_id 를 내보냈습니다.

절차

  1. API 토큰을 새로 고칩니다.

    $ source refresh-token
  2. 새 인프라 환경을 등록합니다. 클러스터 이름을 포함한 이름을 지정합니다. 이 예제에서는 인프라 환경을 클러스터 리소스와 연결하는 클러스터 ID를 제공합니다. 다음 예제에서는 image_type 을 지정합니다. full-iso 또는 minimal-iso 를 지정할 수 있습니다. 기본값은 minimal-iso 입니다.

    1. 선택 사항: 요청에 풀 시크릿 파일을 슬루핑하여 새 인프라 환경을 등록할 수 있습니다.

      $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d "$(jq --null-input \
        --slurpfile pull_secret ~/Downloads/pull-secret.txt \
        --arg cluster_id ${CLUSTER_ID} '
          {
            "name": "testcluster-infra-env",
            "image_type":"full-iso",
            "cluster_id": $cluster_id,
            "cpu_architecture" : "<architecture_name>" 1
            "pull_secret": $pull_secret[0] | tojson
          }
      ')" | jq '.id'
      참고
      1
      유효한 값을 나타냅니다. x86_64, arm64, ppc64le, s390x, multi
    2. 선택 사항: JSON 파일에 구성을 작성한 다음 요청에서 참조하여 새 인프라 환경을 등록할 수 있습니다.

      $ cat << EOF > infra-envs.json
      {
       "name": "testcluster-infra-env",
       "image_type": "full-iso",
       "cluster_id": "$CLUSTER_ID",
       "pull_secret": $PULL_SECRET
      }
      EOF
      $ curl -s -X POST "https://api.openshift.com/api/assisted-install/v2/infra-envs" \
       -d @./infra-envs.json \
       -H "Content-Type: application/json" \
       -H "Authorization: Bearer $API_TOKEN" \
       | jq '.id'
  3. 반환된 ID를 INFRA_ENV_ID 변수에 할당하고 이를 내보냅니다.

    $ export INFRA_ENV_ID=<id>
참고

인프라 환경을 생성하여 cluster_id 를 통해 클러스터 정의에 연결하면 지원 설치 관리자 웹 사용자 인터페이스에서 클러스터 설정을 확인할 수 있습니다. 터미널 세션을 닫는 경우 새 터미널 세션에서 ID 다시 내보내야 합니다.

4.7. 인프라 환경 수정

/v2/infra-envs/{infra_env_id} 끝점을 사용하여 인프라 환경을 수정할 수 있습니다. 인프라 환경 수정은 네트워킹, SSH 키 또는 Ignition 구성 덮어쓰기와 같은 설정을 추가하는 일반적인 작업입니다.

인프라 환경을 수정할 때 설정할 수 있는 필드에 대한 자세한 내용은 API 뷰어infra-env-update-params 모델을 참조하십시오. 새로운 인프라 환경을 수정할 때 지원 설치 관리자도 검색 ISO를 다시 생성합니다.

사전 요구 사항

  • 새 인프라 환경을 생성했습니다.

절차

  1. API 토큰을 새로 고칩니다.

    $ source refresh-token
  2. 인프라 환경을 변경합니다.

    $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID} \
    -X PATCH \
    -H "Authorization: Bearer ${API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d "$(jq --null-input \
      --slurpfile pull_secret ~/Downloads/pull-secret.txt '
        {
          "image_type":"minimal-iso",
          "pull_secret": $pull_secret[0] | tojson
        }
    ')" | jq

4.8. 호스트 추가

클러스터 리소스 및 인프라 환경을 구성한 후 검색 ISO 이미지를 다운로드합니다. 다음 두 가지 이미지에서 선택할 수 있습니다.

  • 전체 ISO 이미지: 부팅이 자체적으로 포함되어야 할 때 전체 ISO 이미지를 사용합니다. 이미지에는 지원 설치 관리자 에이전트를 부팅하고 시작하는 데 필요한 모든 항목이 포함되어 있습니다. ISO 이미지의 크기는 약 1GB입니다.
  • 최소 ISO 이미지: 가상 미디어 연결을 통한 대역폭이 제한된 경우 최소 ISO 이미지를 사용합니다. 이 설정은 기본 설정입니다. 이미지에는 네트워킹으로 호스트를 부팅하는 데 필요한 항목만 포함됩니다. 대부분의 콘텐츠는 부팅 시 다운로드됩니다. ISO 이미지의 크기는 약 100MB입니다.
  • iPXE: 's390x' 아키텍처에 권장되는 방법입니다.

두 이미지 모두 동일한 설치 절차를 수행합니다. 이미지 유형을 변경하려면 이 절차를 수행하기 전에 인프라 환경에서 image_type 설정을 변경합니다.

사전 요구 사항

  • 클러스터를 생성했습니다.
  • 인프라 환경을 생성했습니다.
  • 구성을 완료했습니다.
  • 클러스터 호스트가 프록시를 사용해야 하는 방화벽 뒤에 있는 경우 프록시 서버의 HTTP 및 HTTPS URL에 대한 사용자 이름, 암호, IP 주소 및 포트를 구성한 것입니다.
  • 이미지 유형을 선택했거나 기본값 minimal-iso 를 사용합니다.

절차

  1. 필요한 경우 검색 이미지를 구성합니다. iPXE를 사용하여 호스트 부팅을참조하십시오.
  2. API 토큰을 새로 고칩니다.

    $ source refresh-token
  3. 다운로드 URL을 가져옵니다.

    $ curl -H "Authorization: Bearer ${API_TOKEN}" \
    https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/downloads/image-url
  4. 검색 이미지를 다운로드합니다.

    $ wget -O discovery.iso '<url>'

    & lt;url& gt;을 이전 단계의 다운로드 URL로 바꿉니다.

  5. 검색 이미지를 사용하여 호스트를 부팅합니다. 플랫폼에 설치하고 플랫폼과 통합하려는 경우 자세한 내용은 다음 추가 리소스를 참조하십시오.
  6. 호스트에 역할을 할당합니다.

4.9. 호스트 수정

호스트를 추가한 후 필요에 따라 호스트를 수정합니다. 가장 일반적인 수정 사항은 host_namehost_role 매개 변수입니다.

/v2/infra-envs/{infra_env_id}/hosts/{host_id} 엔드포인트를 사용하여 호스트를 수정할 수 있습니다. 호스트를 수정할 때 설정할 수 있는 필드에 대한 자세한 내용은 API 뷰어host-update-params 모델을 참조하십시오.

호스트는 다음 두 가지 역할 중 하나일 수 있습니다.

  • master: 마스터 역할이 있는 호스트가 컨트롤 플레인 호스트로 작동합니다.
  • worker: 작업자 역할이 있는 호스트가 작업자 호스트로 작동합니다.

기본적으로 지원 설치 관리자는 호스트를 자동 할당 으로 설정합니다. 즉, 설치 프로그램이 호스트가 마스터 또는 작업자 역할인지 여부를 자동으로 결정합니다. 다음 절차에 따라 호스트의 역할을 설정합니다.

사전 요구 사항

  • 클러스터에 호스트를 추가했습니다.

절차

  1. API 토큰을 새로 고칩니다.

    $ source refresh-token
  2. 호스트 ID를 가져옵니다.

    $ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID" \
    --header "Content-Type: application/json" \
      -H "Authorization: Bearer $API_TOKEN" \
    | jq '.host_networks[].host_ids'
  3. z/VM이 있는 IBM Z(s390x)에 설치하려면 추가 커널 인수가 필요합니다.

    1. 일치하는 노드의 hostID를 검색하려면 다음 명령을 실행합니다.

      curl https://api.openshift.com/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts -H "Authorization: Bearer ${API_TOKEN}" | jq '.[]|[.id,.requested_hostname] | join("|")'
    2. 필요한 커널 인수를 지정하려면 다음 명령을 실행합니다.

      curl https://api.stage.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/$1/installer-args \
      -X PATCH \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d '
      {
      "args": [
      "--append-karg", "rd.neednet=1",
      "--append-karg", "ip=10.14.6.3::10.14.6.1:255.255.255.0:master-0.boea3e06.lnxero1.boe:encbdd0:none",
      "--append-karg", "nameserver=10.14.6.1",
      "--append-karg", "ip=[fd00::3]::[fd00::1]:64::encbdd0:none",
      "--append-karg", "nameserver=[fd00::1]",
      "--append-karg", "zfcp.allow_lun_scan=0",
      "--append-karg", "rd.znet=qeth,0.0.bdd0,0.0.bdd1,0.0.bdd2,layer2=1",
      "--append-karg", "rd.dasd=0.0.5235"
      ]
      }
      ' | jq
      참고

      각 호스트에는 특정 커널 인수가 있을 수 있습니다.

      출력 예

      [
        "1062663e-7989-8b2d-7fbb-e6f4d5bb28e5"
      ]

  4. 호스트를 수정합니다.

    $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/<host_id> \ 1
    -X PATCH \
    -H "Authorization: Bearer ${API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d '
        {
          "host_role":"worker"
          "host_name" : "worker-1"
        }
    ' | jq
    1
    & lt;host_id& gt;를 호스트 ID로 바꿉니다.

4.10. 설치 전 검증

지원 설치 관리자는 복잡한 설치 후 문제 해결을 제거하여 클러스터가 설치 전에 사전 요구 사항을 충족하는지 확인하므로 시간과 노력을 많이 절약할 수 있습니다. 클러스터를 설치하기 전에 클러스터와 각 호스트가 설치 사전 검증을 통과했는지 확인합니다.

추가 리소스

4.11. 클러스터 설치

클러스터가 과거의 검증을 호스팅하면 클러스터를 설치할 수 있습니다.

사전 요구 사항

  • 클러스터 및 인프라 환경을 생성했습니다.
  • 인프라 환경에 호스트를 추가했습니다.
  • 호스트가 검증을 통과했습니다.

절차

  1. API 토큰을 새로 고칩니다.

    $ source refresh-token
  2. 클러스터를 설치합니다.

    $ curl -H "Authorization: Bearer $API_TOKEN" \
    -X POST \
    https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/actions/install | jq
  3. 설치 후 플랫폼 통합 단계를 완료합니다.

5장. 선택 사항: 디스크 암호화 활성화

TPM v2 또는 Tang 암호화 모드를 사용하여 설치 디스크의 암호화를 활성화할 수 있습니다.

참고

경우에 따라 베어 메탈 호스트의 펌웨어에서 TPM 디스크 암호화를 활성화한 다음 지원 설치 프로그램으로 생성하는 ISO에서 부팅하면 클러스터 배포가 중단될 수 있습니다. 이는 호스트에 이전 설치의 TPM 암호화 키가 남아 있는 경우 발생할 수 있습니다. 자세한 내용은 BZ#2011634 에서 참조하십시오. 이 문제가 발생하면 Red Hat 지원에 문의하십시오.

5.1. TPM v2 암호화 활성화

사전 요구 사항

  • 각 호스트의 BIOS에서 TPM v2 암호화가 활성화되어 있는지 확인합니다. 대부분의 Dell 시스템에는 이 작업이 필요합니다. 컴퓨터 설명서를 확인하십시오. 지원 설치 프로그램은 또한 TPM이 펌웨어에서 활성화되어 있는지 확인합니다. 자세한 내용은 지원 설치 관리자 API디스크 등록 모델을 참조하십시오.
중요

TPM v2 암호화 칩이 각 노드에 설치되어 있고 펌웨어에서 활성화되어 있는지 확인합니다.

절차

  1. 선택 사항: UI를 사용하여 사용자 인터페이스 마법사의 클러스터 세부 정보 단계에서 컨트롤 플레인 노드, 작업자 또는 둘 다에서 TPM v2 암호화를 사용하도록 선택합니다.
  2. 선택 사항: API를 사용하여 "호스트 수정" 절차를 따르십시오. disk_encryption.enable_on 설정을 모든,masters 또는 workers 로 설정합니다. disk_encryption.mode 설정을 tpmv2 로 설정합니다.

    1. API 토큰을 새로 고칩니다.

      $ source refresh-token
    2. TPM v2 암호화를 활성화합니다.

      $ curl https://api.openshift.com/api/assisted-install/v2/clusters/${CLUSTER_ID} \
      -X PATCH \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d '
      {
        "disk_encryption": {
          "enable_on": "none",
          "mode": "tpmv2"
        }
      }
      ' | jq

      enable_on 의 유효한 설정은 모두,master,worker, none 입니다.

5.2. Tang 암호화 활성화

사전 요구 사항

  • Tang 교환 키의 지문을 생성하는 데 사용할 수 있는 RHEL (Red Hat Enterprise Linux) 8 시스템에 액세스할 수 있습니다.

절차

  1. Tang 서버를 설정하거나 기존 서버에 액세스합니다. 자세한 내용은 Network-bound disk encryption에서 참조하십시오. 여러 Tang 서버를 설정할 수 있지만 지원 설치 프로그램은 설치 중에 모든 서버에 연결할 수 있어야 합니다.
  2. Tang 서버에서 tang-show-keys 를 사용하여 Tang 서버의 지문을 검색합니다.

    $ tang-show-keys <port>

    선택 사항: & lt;port& gt;를 포트 번호로 바꿉니다. 기본 포트 번호는 80 입니다.

    지문 예

    1gYTN_LpU9ZMB35yn5IbADY5OQ0

  3. 선택 사항: jose 를 사용하여 Tang 서버의 지문을 검색합니다.

    1. jose 가 Tang 서버에 설치되어 있는지 확인합니다.

      $ sudo dnf install jose
    2. Tang 서버에서 jose 를 사용하여 지문을 검색합니다.

      $ sudo jose jwk thp -i /var/db/tang/<public_key>.jwk

      & lt;public_key >를 Tang 서버의 공개 교환 키로 바꿉니다.

      지문 예

      1gYTN_LpU9ZMB35yn5IbADY5OQ0

  4. 선택 사항: 사용자 인터페이스 마법사의 클러스터 세부 정보 단계에서 컨트롤 플레인 노드, 작업자 또는 둘 다에서 Tang 암호화를 사용하도록 선택합니다. Tang 서버의 URL과 지문을 입력해야 합니다.
  5. 선택 사항: API를 사용하여 "호스트 수정" 절차를 따르십시오.

    1. API 토큰을 새로 고칩니다.

      $ source refresh-token
    2. disk_encryption.enable_on 설정을 모든,masters 또는 workers 로 설정합니다. disk_encryption.mode 설정을 10.0.0.1으로 설정합니다. 하나 이상의 Tang 서버에 대한 URL 및 지문 세부 정보를 제공하도록 disk_encyrption.tang_servers 를 설정합니다.

      $ curl https://api.openshift.com/api/assisted-install/v2/clusters/${CLUSTER_ID} \
      -X PATCH \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d '
      {
        "disk_encryption": {
          "enable_on": "all",
          "mode": "tang",
          "tang_servers": "[{\"url\":\"http://tang.example.com:7500\",\"thumbprint\":\"PLjNyRdGw03zlRoGjQYMahSZGu9\"},{\"url\":\"http://tang2.example.com:7500\",\"thumbprint\":\"XYjNyRdGw03zlRoGjQYMahSZGu3\"}]"
        }
      }
      ' | jq

      enable_on 의 유효한 설정은 모두,master,worker, none 입니다. CloudEvent _servers 값 내에서 오브젝트 내에서 따옴표를 주석 처리합니다.

5.3. 추가 리소스

6장. 선택사항: Operator 설치 및 수정

지원 설치 관리자는 UI 또는 API에서 기본 구성으로 선택한 Operator를 설치할 수 있습니다. 고급 옵션이 필요한 경우 클러스터를 설치한 후 원하는 Operator를 설치합니다.

지원 설치 관리자는 선택한 Operator의 설치를 클러스터 설치의 일부로 모니터링하고 상태를 보고합니다. 설치 중에 하나 이상의 Operator에 오류가 발생하면 지원 설치 관리자에서 하나 이상의 Operator를 설치하지 못한 경고와 함께 클러스터 설치가 완료되었다고 보고합니다.

지원 설치 관리자 UI 또는 API를 사용하여 클러스터 정의를 설치하거나 수정할 때 설정할 수 있는 Operator의 아래 섹션을 참조하십시오. OpenShift Container Platform 클러스터 설치에 대한 전체 지침은 각각 지원 설치 관리자 UI 로 설치 또는 지원 설치 설치에서 참조하십시오.

6.1. Operator 설치

지원 설치 관리자 UI를 사용하여ng Operator를 설치할 때 마법사의 Operator 페이지에서 Operator 를 선택합니다. 지원 설치 관리자 API를 사용하여 Operator를 설치할 때 /v2/clusters 끝점에서 POST 메서드를 사용합니다.

6.1.1. OpenShift Virtualization 설치

클러스터를 구성할 때 OpenShift Virtualization 을 활성화할 수 있습니다.

참고

현재 OpenShift Virtualization은 IBM zSystems 및 IBM Power에서 지원되지 않습니다.

활성화된 경우 지원 설치 관리자:

  1. 환경이 아래에 설명된 사전 요구 사항을 충족하는지 확인합니다.
  2. 다음과 같이 가상 머신 스토리지를 구성합니다.

    1. 단일 노드 OpenShift 클러스터 버전 4.10 이상의 경우 지원 설치 프로그램은 hostpath 프로비전 프로그램을 구성합니다.
    2. 이전 버전의 단일 노드 OpenShift 클러스터의 경우 지원 설치 프로그램은 Local Storage Operator 를 구성합니다.
    3. 다중 노드 클러스터의 경우 지원 설치 관리자는 OpenShift Data Foundation을 구성합니다.

사전 요구 사항

  • RHEL (Red Hat Enterprise Linux) 8에서 지원
  • Intel 64 또는 AMD64 CPU 확장 지원
  • Intel Virtualization Technology 또는 AMD-V 하드웨어 가상화 확장 가능
  • NX (no execute) 플래그 활성화

절차

  1. 지원 설치 관리자 UI를 사용하는 경우:

    • 마법사의 Operator 단계에서 OpenShift Virtualization 설치 확인란을 활성화합니다.
  2. 지원 설치 관리자 API를 사용하는 경우:

    • 새 클러스터를 등록할 때 "olm_operators: [{"name": "cnv"}]" 문을 추가합니다.

      참고

      CNV는 컨테이너 네이티브 가상화를 나타냅니다.

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

      $ curl -s -X POST https://api.openshift.com/api/assisted-install/v2/clusters \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d "$(jq --null-input \
         --slurpfile pull_secret ~/Downloads/pull-secret.txt '
      {
         "name": "testcluster",
         "openshift_version": "4.11",
         "cpu_architecture" : "x86_64",
         "base_dns_domain": "example.com",
         "olm_operators: [{"name": "cnv"}]"
         "pull_secret": $pull_secret[0] | tojson
      }
      ')" | jq '.id'

추가 리소스

  • OpenShift Virtualization용 클러스터 준비에 대한 자세한 내용은 OpenShift 설명서 를 참조하십시오.

6.1.2. MCCE(Multicluster Engine) 설치

클러스터를 구성할 때 MCCE (Multicluster Engine) Operator를 활성화할 수 있습니다. MC(Multicluster Engine) Operator를 사용하면 현재 설치 중인 클러스터에서 추가 클러스터를 설치할 수 있습니다.

사전 요구 사항

  • OpenShift 버전 4.10 이상
  • 멀티 노드 OpenShift 클러스터에 4개의 CPU 코어 및 16GB의 RAM이 추가로 제공됩니다.
  • 단일 노드 OpenShift 클러스터의 경우 추가 8 CPU 코어 및 32GB RAM

스토리지 고려 사항

설치하기 전에 멀티 클러스터 엔진에서 클러스터를 관리하는 데 필요한 스토리지를 고려해야 합니다. 스토리지 자동화를 위해 다음 시나리오 중 하나를 선택할 수 있습니다.

  • 다중 노드 클러스터에 ODF(OpenShift Data Foundation)를 설치합니다. ODF는 클러스터에 권장되는 스토리지이지만 추가 서브스크립션이 필요합니다. 자세한 내용은 이 장의 OpenShift Data Foundation 설치를 참조하십시오.
  • 단일 노드 OpenShift(SNO) 클러스터에 LVMS(Logical Volume Management Storage)를 설치합니다.
  • 스토리지를 구성하지 않고 다중 노드 클러스터에 다중 클러스터 엔진을 설치합니다. 그런 다음 선택한 스토리지를 구성하고 설치 후 CIM(Central Infrastructure Management) 서비스를 활성화합니다. 자세한 내용은 이 장의 추가 리소스 를 참조하십시오.

절차

  1. 지원 설치 관리자 UI를 사용하는 경우:

    • 마법사의 Operator 단계에서 다중 클러스터 엔진 설치 확인란을 활성화합니다.
  2. 지원 설치 관리자 API를 사용하는 경우:

    • 새 클러스터를 등록할 때 "olm_operators: [{"name": "mce"}]" 문을 사용합니다. 예를 들면 다음과 같습니다.

      $ curl -s -X POST https://api.openshift.com/api/assisted-install/v2/clusters \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d "$(jq --null-input \
          --slurpfile pull_secret ~/Downloads/pull-secret.txt '
      {
          "name": "testcluster",
          "openshift_version": "4.11",
          "cpu_architecture" : "x86_64"
          "base_dns_domain": "example.com",
          "olm_operators: [{"name": "mce"}]",
          "pull_secret": $pull_secret[0] | tojson
      }
      ')" | jq '.id'

설치 후 단계

추가 리소스

6.1.3. OpenShift Data Foundation 설치

클러스터를 구성할 때 OpenShift Data Foundation 을 활성화할 수 있습니다. 활성화된 경우 지원 설치 관리자:

  1. 환경이 아래에 설명된 사전 요구 사항을 충족하는지 확인합니다. 디스크 장치가 다시 포맷되었는지 확인하지 않으므로 시작하기 전에 확인해야 합니다.
  2. 사용 가능한 모든 디스크를 사용하도록 스토리지를 구성합니다.

OpenShift Data Foundation을 활성화하면 지원 설치 프로그램은 OpenShift Data Foundation과 함께 사용할 수 있는 모든 디스크를 지정하는 StorageCluster 리소스를 생성합니다. 다른 구성이 필요한 경우 클러스터를 설치한 후 구성을 수정하거나 클러스터를 설치한 후 Operator를 설치합니다.

사전 요구 사항

  • 클러스터는 3노드 OpenShift 클러스터이거나 작업자 노드가 3개 이상 있습니다.
  • 각 호스트에는 최소 25GB의 설치 이외의 디스크가 하나 이상 있습니다.
  • 사용하는 디스크 장치는 비어 있어야 합니다. 디스크에는 물리 볼륨(PV), 볼륨 그룹(VG) 또는 논리 볼륨(LV)이 없어야 합니다.
  • 각 호스트에는 다른 CPU 요구 사항 외에 표준 클러스터의 경우 3노드 OpenShift 또는 8 CPU 코어에 대해 6개의 CPU 코어가 있습니다.
  • 각 호스트에는 다른 RAM 요구 사항 외에 19GiB RAM이 있습니다.
  • 각 호스트에는 다른 CPU 및 RAM 요구 사항 외에 스토리지 디스크당 2개의 CPU 코어와 5GiB RAM이 있습니다.
  • 각 호스트에 컨트롤 플레인 또는 작업자 역할을 할당했습니다(자동 할당되지 않음).

절차

  1. 지원 설치 관리자 UI를 사용하는 경우:

    • 마법사의 Operator 단계에서 OpenShift Data Foundation 설치 확인란을 활성화합니다.
  2. 지원 설치 관리자 API를 사용하는 경우:

    • 새 클러스터를 등록할 때 "olm_operators: [{"name": "odf"}]" 문을 추가합니다. 예를 들면 다음과 같습니다.

      $ curl -s -X POST https://api.openshift.com/api/assisted-install/v2/clusters \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d "$(jq --null-input \
         --slurpfile pull_secret ~/Downloads/pull-secret.txt '
      {
         "name": "testcluster",
         "openshift_version": "4.11",
         "cpu_architecture" : "x86_64",
         "base_dns_domain": "example.com",
         "olm_operators: [{"name": "odf"}]",
         "pull_secret": $pull_secret[0] | tojson
      }
      ')" | jq '.id'

추가 리소스

  • OpenShift Data Foundation에 대한 자세한 내용은 OpenShift 설명서 를 참조하십시오.

6.1.4. 논리 볼륨 관리자 스토리지 설치

클러스터를 구성할 때 단일 노드 OpenShift 클러스터에서 LVMS(Logical Volume Manager Storage) Operator를 활성화할 수 있습니다. LVMS Operator를 설치하면 로컬 스토리지를 동적으로 프로비저닝할 수 있습니다.

사전 요구 사항

  • 버전 4.11 이상으로 설치된 단일 노드 OpenShift 클러스터
  • 설치되지 않은 디스크가 하나 이상
  • CPU 코어 1개와 400MB의 RAM( 4.13 이전 버전용 1200MB RAM)

절차

  1. 지원 설치 관리자 UI를 사용하는 경우:

    • 마법사의 Operator 단계에서 Install Logical Volume Manager Storage 확인란을 활성화합니다.
  2. 지원 설치 관리자 API를 사용하는 경우:

    • 새 클러스터를 등록할 때 olm_operators: [{"name": "lvm"}] 문을 사용합니다. 예를 들면 다음과 같습니다.

      $ curl -s -X POST https://api.openshift.com/api/assisted-install/v2/clusters \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d "$(jq --null-input \
         --slurpfile pull_secret ~/Downloads/pull-secret.txt '
      {
         "name": "testcluster",
         "openshift_version": "4.14",
         "cpu_architecture" : "x86_64",
         "base_dns_domain": "example.com",
         "olm_operators: [{"name": "lvm"}]"
         "pull_secret": $pull_secret[0] | tojson
      }
      ')" | jq '.id'

추가 리소스

6.2. Operator 수정

지원 설치 관리자에서는 이전 설치 단계의 일부로 이미 등록된 클러스터 리소스의 Operator를 추가하거나 제거할 수 있습니다. 이는 OpenShift Container Platform 설치를 시작하기 전에만 가능합니다.

정의된 Operator를 수정하려면 다음을 수행합니다.

  • 지원 설치 관리자 UI를 사용하는 경우 마법사의 Operator 페이지로 이동하여 선택을 수정합니다. 자세한 내용은 이 섹션에서 Operator 설치를 참조하십시오.
  • 지원 설치 프로그램 API를 사용하는 경우 /v2/clusters/{cluster_id} 엔드포인트에 PATCH 방법을 사용하여 필요한 Operator 정의를 설정합니다.

사전 요구 사항

  • 새 클러스터 리소스가 생성되어 있습니다.

절차

  1. API 토큰을 새로 고칩니다.

    $ source refresh-token
  2. 다음과 같이 기존 클러스터를 나열하여 CLUSTER_ID 변수를 식별합니다.

    $ curl -s https://api.openshift.com/api/assisted-install/v2/clusters -H "Authorization: Bearer ${API_TOKEN}" | jq '[ .[] | { "name": .name, "id": .id } ]'

    샘플 출력

    [
      {
        "name": "lvmtest",
        "id": "475358f9-ed3a-442f-ab9e-48fd68bc8188" 1
      },
      {
        "name": "mcetest",
        "id": "b5259f97-be09-430e-b5eb-d78420ee509a"
      }
    ]

    참고
    1
    id 값은 < cluster_id>입니다.
  3. 반환된 &lt ;cluster_id& gt;를 CLUSTER_ID 변수에 할당하고 내보냅니다.

    $ export CLUSTER_ID=<cluster_id>
  4. 새 Operator로 클러스터를 업데이트합니다.

    $ curl https://api.openshift.com/api/assisted-install/v2/clusters/${CLUSTER_ID} \
    -X PATCH \
    -H "Authorization: Bearer ${API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d '
    {
        "olm_operators": [{"name": "mce"}, {"name": "cnv"}], 1
    }
    ' | jq '.id'
    참고
    1
    Operator가 설치됨을 나타냅니다. 유효한 값에는 mce,cnv,lvm, odf 가 포함됩니다. 이전에 설치한 Operator를 제거하려면 값 목록에서 제외합니다. 이전에 설치한 모든 Operator를 제거하려면 "olm_operators": [] 를 입력합니다.

    샘플 출력

    {
      <various cluster properties>,
      "monitored_operators": [
        {
          "cluster_id": "b5259f97-be09-430e-b5eb-d78420ee509a",
          "name": "console",
          "operator_type": "builtin",
          "status_updated_at": "0001-01-01T00:00:00.000Z",
          "timeout_seconds": 3600
        },
        {
          "cluster_id": "b5259f97-be09-430e-b5eb-d78420ee509a",
          "name": "cvo",
          "operator_type": "builtin",
          "status_updated_at": "0001-01-01T00:00:00.000Z",
          "timeout_seconds": 3600
        },
        {
          "cluster_id": "b5259f97-be09-430e-b5eb-d78420ee509a",
          "name": "mce",
          "namespace": "multicluster-engine",
          "operator_type": "olm",
          "status_updated_at": "0001-01-01T00:00:00.000Z",
          "subscription_name": "multicluster-engine",
          "timeout_seconds": 3600
        },
        {
          "cluster_id": "b5259f97-be09-430e-b5eb-d78420ee509a",
          "name": "cnv",
          "namespace": "openshift-cnv",
          "operator_type": "olm",
          "status_updated_at": "0001-01-01T00:00:00.000Z",
          "subscription_name": "hco-operatorhub",
          "timeout_seconds": 3600
        },
        {
          "cluster_id": "b5259f97-be09-430e-b5eb-d78420ee509a",
          "name": "lvm",
          "namespace": "openshift-local-storage",
          "operator_type": "olm",
          "status_updated_at": "0001-01-01T00:00:00.000Z",
          "subscription_name": "local-storage-operator",
          "timeout_seconds": 4200
        }
      ],
      <more cluster properties>

    참고

    출력은 새 클러스터 상태에 대한 설명입니다. 출력의 monitored_operators 속성에는 다음 두 가지 유형의 Operator가 포함되어 있습니다.

    • "operator_type": "builtin ": 이 유형의 Operator는 OpenShift Container Platform의 통합 부분입니다.
    • "operator_type": "olm ": 이 유형의 Operator는 사용자가 수동으로 추가하거나 종속성으로 인해 자동으로 추가됩니다. 이 예제에서는 cnv Operator에 필요하므로 lso Operator가 자동으로 추가되었습니다.

7장. 검색 이미지 구성

지원 설치 관리자는 초기 이미지를 사용하여 OpenShift Container Platform을 설치하기 전에 하드웨어 및 네트워크 검증을 수행하는 에이전트를 실행합니다. Ignition 을 사용하여 검색 이미지를 사용자 지정할 수 있습니다.

참고

검색 이미지에 대한 수정은 시스템에서 유지되지 않습니다.

7.1. Ignition 구성 파일 생성

Ignition은 임시 초기 루트 파일 시스템인 initramfs 의 일부인 낮은 수준의 시스템 구성 유틸리티입니다. Ignition이 첫 번째 부팅에서 실행되면 Ignition 구성 파일에서 구성 데이터를 찾아 switch_root 가 호출되기 전에 호스트에 적용하여 호스트의 루트 파일 시스템을 피벗합니다.

Ignition은 JSON 구성 사양 파일을 사용하여 첫 번째 부팅에서 발생하는 변경 사항 세트를 나타냅니다.

중요

3.2 이상의 Ignition 버전은 지원되지 않으며 오류가 발생합니다.

절차

  1. Ignition 파일을 생성하고 구성 사양 버전을 지정합니다.

    $ vim ~/ignition.conf
    {
      "ignition": { "version": "3.1.0" }
    }
  2. Ignition 파일에 구성 데이터를 추가합니다. 예를 들어 core 사용자에 암호를 추가합니다.

    1. 암호 해시를 생성합니다.

      $ openssl passwd -6
    2. 생성된 암호 해시를 core 사용자에게 추가합니다.

      {
        "ignition": { "version": "3.1.0" },
        "passwd": {
          "users": [
            {
              "name": "core",
              "passwordHash": "$6$spam$M5LGSMGyVD.9XOboxcwrsnwNdF4irpJdAWy.1Ry55syyUiUssIzIAHaOrUHr2zg6ruD8YNBPW9kW0H8EnKXyc1"
            }
          ]
        }
      }
  3. Ignition 파일을 저장하고 IGNITION_FILE 변수로 내보냅니다.

    $ export IGNITION_FILE=~/ignition.conf

7.2. Ignition을 사용하여 검색 이미지 수정

Ignition 구성 파일을 생성한 후에는 지원 설치 관리자 API를 사용하여 인프라 환경에 패치하여 검색 이미지를 수정할 수 있습니다.

사전 요구 사항

  • UI를 사용하여 클러스터를 생성한 경우 API 인증을 설정해야 합니다.
  • 인프라 환경이 있고 인프라 환경 ID를 INFRA_ENV_ID 변수로 내보낸 것입니다.
  • 유효한 Ignition 파일이 있고 파일 이름을 $IGNITION_FILE 로 내보냈습니다.

절차

  1. ignition_config_override JSON 오브젝트를 생성하고 파일로 리디렉션합니다.

    $ jq -n \
      --arg IGNITION "$(jq -c . $IGNITION_FILE)" \
      '{ignition_config_override: $IGNITION}' \
      > discovery_ignition.json
  2. API 토큰을 새로 고칩니다.

    $ source refresh-token
  3. 인프라 환경을 패치합니다.

    $ curl \
      --header "Authorization: Bearer $API_TOKEN" \
      --header "Content-Type: application/json" \
      -XPATCH \
      -d @discovery_ignition.json \
      https://api.openshift.com/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID | jq

    ignition_config_override 오브젝트는 Ignition 파일을 참조합니다.

  4. 업데이트된 검색 이미지를 다운로드합니다.

8장. 검색 이미지를 사용하여 호스트 부팅

지원 설치 관리자는 초기 이미지를 사용하여 OpenShift Container Platform을 설치하기 전에 하드웨어 및 네트워크 검증을 수행하는 에이전트를 실행합니다. 다음 세 가지 방법을 사용하여 검색 이미지로 호스트를 부팅할 수 있습니다.

  • USB 드라이브
  • RedFish 가상 미디어
  • iPXE

8.1. USB 드라이브에서 ISO 이미지 생성

검색 ISO 이미지가 포함된 USB 드라이브를 사용하여 지원 설치 관리자 에이전트를 설치할 수 있습니다. USB 드라이브로 호스트를 시작하면 소프트웨어 설치를 위한 호스트가 준비됩니다.

절차

  1. 관리 호스트에서 USB 드라이브를 USB 포트에 삽입합니다.
  2. ISO 이미지를 USB 드라이브에 복사합니다. 예를 들면 다음과 같습니다.

    # dd if=<path_to_iso> of=<path_to_usb> status=progress

    다음과 같습니다.

    <path_to_iso>
    다운로드한 검색 ISO 파일의 상대 경로입니다(예: discovery.iso ).
    <path_to_usb>

    연결된 USB 드라이브의 위치입니다(예: /dev/sdb ).

    ISO를 USB 드라이브에 복사한 후 USB 드라이브를 사용하여 클러스터 호스트에 지원 설치 프로그램 에이전트를 설치할 수 있습니다.

8.2. USB 드라이브 부팅

부팅 가능한 USB 드라이브를 사용하여 지원 설치 관리자에 노드를 등록하려면 다음 절차를 사용하십시오.

절차

  1. RHCOS 검색 ISO USB 드라이브를 대상 호스트에 삽입합니다.
  2. 연결된 검색 ISO에서 부팅한 다음 서버를 재부팅하도록 서버 펌웨어 설정에서 부팅 순서를 구성합니다.
  3. 호스트가 부팅될 때까지 기다립니다.

    1. UI 설치의 경우 관리 호스트에서 브라우저로 돌아갑니다. 검색된 호스트 목록에 호스트가 표시될 때까지 기다립니다.
    2. API 설치의 경우 토큰을 새로 고치고 활성화된 호스트 수를 확인하고 호스트 ID를 수집합니다.

      $ source refresh-token
      $ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID" \
      --header "Content-Type: application/json" \
        -H "Authorization: Bearer $API_TOKEN" \
      | jq '.enabled_host_count'
      $ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID" \
      --header "Content-Type: application/json" \
        -H "Authorization: Bearer $API_TOKEN" \
      | jq '.host_networks[].host_ids'

      출력 예

      [
        "1062663e-7989-8b2d-7fbb-e6f4d5bb28e5"
      ]

8.3. Redfish API를 사용하여 HTTP 호스팅 ISO 이미지에서 부팅

Redfish BMC(Baseboard Management Controller) API를 사용하여 설치한 ISO를 사용하여 네트워크에서 호스트를 프로비저닝할 수 있습니다.

사전 요구 사항

  • 설치 RHCOS(Red Hat Enterprise Linux CoreOS) ISO를 다운로드합니다.

절차

  1. ISO 파일을 네트워크에서 액세스할 수 있는 HTTP 서버에 복사합니다.
  2. 호스트된 ISO 파일에서 호스트를 부팅합니다. 예를 들면 다음과 같습니다.

    1. 다음 명령을 실행하여 호스팅된 ISO를 VirtualMedia 부팅 미디어로 설정하려면 redfish API를 호출합니다.

      $ curl -k -u <bmc_username>:<bmc_password> \
      -d '{"Image":"<hosted_iso_file>", "Inserted": true}' \
      -H "Content-Type: application/json" \
      -X POST <host_bmc_address>/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia

      다음과 같습니다.

      <bmc_username>:<bmc_password>
      는 대상 호스트 BMC의 사용자 이름 및 암호입니다.
      <hosted_iso_file>
      호스트 설치 ISO의 URL입니다(예: http://webserver.example.com/rhcos-live-minimal.iso ). 대상 호스트 시스템에서 ISO에 액세스할 수 있어야 합니다.
      <host_bmc_address>
      대상 호스트 시스템의 BMC IP 주소입니다.
    2. 다음 명령을 실행하여 VirtualMedia 장치에서 부팅하도록 호스트를 설정합니다.

      $ curl -k -u <bmc_username>:<bmc_password> \
      -X PATCH -H 'Content-Type: application/json' \
      -d '{"Boot": {"BootSourceOverrideTarget": "Cd", "BootSourceOverrideMode": "UEFI", "BootSourceOverrideEnabled": "Once"}}' \
      <host_bmc_address>/redfish/v1/Systems/System.Embedded.1
    3. 호스트를 재부팅합니다.

      $ curl -k -u <bmc_username>:<bmc_password> \
      -d '{"ResetType": "ForceRestart"}' \
      -H 'Content-type: application/json' \
      -X POST <host_bmc_address>/redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset
    4. 선택 사항: 호스트의 전원이 꺼지면 {"ResetType": "On"} 스위치를 사용하여 부팅할 수 있습니다. 다음 명령을 실행합니다.

      $ curl -k -u <bmc_username>:<bmc_password> \
      -d '{"ResetType": "On"}' -H 'Content-type: application/json' \
      -X POST <host_bmc_address>/redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset

8.4. iPXE를 사용하여 호스트 부팅

지원 설치 프로그램은 인프라 환경에 대한 검색 이미지를 부팅하는 데 필요한 모든 아티팩트를 포함하는 iPXE 스크립트를 제공합니다. iPXE의 현재 HTTPS 구현의 제한으로 인해 필요한 아티팩트를 다운로드하여 HTTP 서버에 노출하는 것이 좋습니다. 현재 iPXE가 HTTPS 프로토콜을 지원하더라도 지원되는 알고리즘은 오래되어 권장되지 않습니다.

지원되는 암호화의 전체 목록은 https://ipxe.org/crypto 에 있습니다.

사전 요구 사항

  • API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.
  • 쉘에서 $INFRA_ENV_ID 로 내보낸 인프라 환경 ID가 있어야 합니다.
  • API에 액세스할 때 사용할 자격 증명이 있고 쉘에서 $API_TOKEN 으로 토큰을 내보냈습니다.
  • 이미지를 호스팅할 HTTP 서버가 있습니다.
참고

UI를 통해 구성할 때 $INFRA_ENV_ID$API_TOKEN 변수가 이미 제공됩니다.

참고

IBM Power는 PXE만 지원합니다. 필요한 PXE만 지원합니다. /var/lib/tftpboot에 grub2 를 설치했습니다. PXE용 DHCP 및 TFTP를 설치했습니다.

절차

  1. UI에서 iPXE 스크립트를 직접 다운로드하거나 지원 설치 관리자에서 iPXE 스크립트를 가져옵니다.

    $ curl \
      --silent \
      --header "Authorization: Bearer $API_TOKEN" \
      https://api.openshift.com/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/downloads/files?file_name=ipxe-script > ipxe-script

    예제

    #!ipxe
    initrd --name initrd http://api.openshift.com/api/assisted-images/images/<infra_env_id>/pxe-initrd?arch=x86_64&image_token=<token_string>&version=4.10
    kernel http://api.openshift.com/api/assisted-images/boot-artifacts/kernel?arch=x86_64&version=4.10 initrd=initrd coreos.live.rootfs_url=http://api.openshift.com/api/assisted-images/boot-artifacts/rootfs?arch=x86_64&version=4.10 random.trust_cpu=on rd.luks.options=discard ignition.firstboot ignition.platform.id=metal console=tty1 console=ttyS1,115200n8 coreos.inst.persistent-kargs="console=tty1 console=ttyS1,115200n8"
    boot

  2. ipxe-script 에서 URL을 추출하여 필요한 아티팩트를 다운로드합니다.

    1. 초기 RAM 디스크를 다운로드합니다.

      $ awk '/^initrd /{print $NF}' ipxe-script | curl -o initrd.img
    2. Linux 커널을 다운로드합니다.

      $ awk '/^kernel /{print $2}' ipxe-script | curl -o kernel
    3. 루트 파일 시스템을 다운로드합니다.

      $ grep ^kernel ipxe-script | xargs -n1| grep ^coreos.live.rootfs_url | cut -d = -f 2- | curl -o rootfs.img
  3. 로컬 HTTP 서버와 일치하도록 ipxe-script' 의 다른 아티팩트로 URL을 변경합니다. 예를 들면 다음과 같습니다.

    #!ipxe
    set webserver http://192.168.0.1
    initrd --name initrd $webserver/initrd.img
    kernel $webserver/kernel initrd=initrd coreos.live.rootfs_url=$webserver/rootfs.img random.trust_cpu=on rd.luks.options=discard ignition.firstboot ignition.platform.id=metal console=tty1 console=ttyS1,115200n8 coreos.inst.persistent-kargs="console=tty1 console=ttyS1,115200n8"
    boot
  4. 선택 사항: IBM zSystems에 RHEL KVM을 사용하여 설치할 때 추가 커널 인수를 지정하여 호스트를 부팅해야 합니다.

    random.trust_cpu=on rd.luks.options=discard ignition.firstboot ignition.platform.id=metal console=tty1 console=ttyS1,115200n8 coreos.inst.persistent-kargs="console=tty1 console=ttyS1,115200n8
    참고

    RHEL KVM에 iPXE를 사용하여 설치하는 경우 경우에 따라 VM 호스트의 VM이 첫 번째 부팅 시 재부팅되지 않으므로 수동으로 시작해야 합니다.

  5. 선택 사항: IBM Power에 설치할 때 다음과 같이 intramfs, kernel 및 root를 다운로드해야 합니다.

    1. initrd.img 및 kernel.img를 PXE 디렉터리 '/var/lib/tftpboot/rhcos'로 복사합니다.
    2. rootfs.img를 HTTPD 디렉터리 '/var/www/html/install '에 복사합니다.
    3. '/var/lib/tftpboot/boot/grub2/grub.cfg ':

      if [ ${net_default_mac} == fa:1d:67:35:13:20 ]; then
      default=0
      fallback=1
      timeout=1
      menuentry "CoreOS (BIOS)" {
      echo "Loading kernel"
      linux "/rhcos/kernel.img" ip=dhcp rd.neednet=1 ignition.platform.id=metal ignition.firstboot coreos.live.rootfs_url=http://9.114.98.8:8000/install/rootfs.img
      echo "Loading initrd"
      initrd "/rhcos/initrd.img"
      }
      fi

9장. 호스트에 역할 할당

검색된 호스트에 역할을 할당할 수 있습니다. 이러한 역할은 클러스터 내에서 호스트의 기능을 정의합니다. 역할은 표준 Kubernetes 유형( 컨트롤 플레인(마스터) 또는 작업자 ) 중 하나일 수 있습니다.

호스트는 선택한 역할에 대한 최소 요구사항을 충족해야 합니다. 이 문서의 사전 요구 사항 섹션을 참조하거나 사전 진행 요구 사항 API를 사용하여 하드웨어 요구 사항을 확인할 수 있습니다.

역할을 선택하지 않으면 시스템에서 사용자를 위한 역할을 선택합니다. 설치를 시작하기 전에 언제든지 역할을 변경할 수 있습니다.

9.1. UI를 사용하여 역할 선택

호스트가 검색을 완료한 후 역할을 선택할 수 있습니다.

절차

  1. Host Discovery (호스트 검색) 탭으로 이동하여 Host Inventory (호스트 인벤토리) 테이블까지 아래로 스크롤합니다.
  2. 필요한 호스트의 자동 할당 드롭다운을 선택합니다.

    1. 컨트롤 플레인 노드를 선택하여 이 호스트에 컨트롤 플레인 역할을 할당합니다.
    2. 이 호스트에 작업자 역할을 할당하려면 Worker 를 선택합니다.
  3. 검증 상태를 확인합니다.

9.2. API를 사용하여 역할 선택

/v2/infra-envs/{infra_env_id}/hosts/{host_id} 끝점을 사용하여 호스트의 역할을 선택할 수 있습니다. 호스트는 다음 두 가지 역할 중 하나일 수 있습니다.

  • master: 마스터 역할이 있는 호스트가 컨트롤 플레인 호스트로 작동합니다.
  • worker: 작업자 역할이 있는 호스트가 작업자 호스트로 작동합니다.

기본적으로 지원 설치 관리자는 호스트를 자동 할당으로 설정합니다. 즉, 설치 프로그램이 호스트가 마스터 또는 작업자 역할인지 자동으로 결정됩니다. 이 절차를 사용하여 호스트의 역할을 설정합니다.

사전 요구 사항

  • 클러스터에 호스트를 추가했습니다.

절차

  1. API 토큰을 새로 고칩니다.

    $ source refresh-token
  2. 호스트 ID를 가져옵니다.

    $ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID" \
    --header "Content-Type: application/json" \
      -H "Authorization: Bearer $API_TOKEN" \
    | jq '.host_networks[].host_ids'

    출력 예

    [
      "1062663e-7989-8b2d-7fbb-e6f4d5bb28e5"
    ]

  3. host_role 설정을 수정합니다.

    $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/<host_id> \
    -X PATCH \
    -H "Authorization: Bearer ${API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d '
        {
          "host_role":"worker"
        }
    ' | jq

    & lt;host_id& gt;를 호스트 ID로 바꿉니다.

9.3. 자동 할당 역할

지원되는 설치 관리자에서 역할을 직접 할당하지 않는 경우 호스트에 대해 자동으로 역할을 선택합니다. 역할 선택 메커니즘은 호스트의 메모리, CPU 및 디스크 공간을 제공합니다. 컨트롤 플레인 노드의 최소 요구사항을 충족하는 3개의 가장 약한 호스트에 컨트롤 플레인 역할을 할당하는 것을 목표로 합니다. 다른 모든 호스트는 기본적으로 작업자 노드로 설정됩니다. 목표는 컨트롤 플레인을 실행하고 실제 워크로드를 실행하기 위해 용량 집약적인 호스트를 예약하기에 충분한 리소스를 제공하는 것입니다.

설치 전 언제든지 자동 할당 결정을 재정의할 수 있습니다.

검증을 통해 자동 선택이 유효한지 확인합니다.

9.4. 추가 리소스

사전 요구 사항

10장. 설치 전 검증

10.1. 사전 설치 검증 정의

지원 설치 프로그램은 클러스터를 최대한 단순하고 효율적으로 오류가 없이 설치하는 것을 목표로 합니다. 지원 설치 관리자는 설치를 시작하기 전에 구성 및 수집된 Telemetry에 대한 검증 검사를 수행합니다.

지원 설치 관리자는 설치 전에 제공한 정보(예: 컨트롤 플레인 토폴로지, 네트워크 구성 및 호스트 이름)를 사용합니다. 또한 설치하려는 호스트에서 실시간 Telemetry를 사용합니다.

호스트가 검색 ISO를 부팅하면 호스트에서 에이전트가 시작됩니다. 에이전트는 호스트 상태에 대한 정보를 지원 설치 관리자에 보냅니다.

지원 설치 관리자는 이 모든 정보를 사용하여 실시간 설치 검증을 계산합니다. 모든 검증은 설치를 차단하거나 차단하지 않는 것입니다.

10.2. 검증 차단 및 차단

검증을 차단하면 설치 진행이 방지됩니다. 즉, 문제를 해결하고 진행하기 전에 차단 검증을 전달해야 합니다.

비 차단 검증은 경고이며 문제가 발생할 수 있는 사항을 알려줍니다.

10.3. 검증 유형

지원 설치 관리자는 다음 두 가지 유형의 검증을 수행합니다.

호스트

호스트 검증은 지정된 호스트의 구성이 설치에 유효한지 확인합니다.

Cluster

클러스터 검증은 전체 클러스터의 구성이 설치에 유효한지 확인합니다.

10.4. 호스트 검증

10.4.1. REST API를 사용하여 호스트 검증 가져오기

참고

웹 기반 UI를 사용하는 경우 이러한 검증의 대부분은 이름으로 표시되지 않습니다. 레이블과 일치하는 검증 목록을 가져오려면 다음 절차를 사용하십시오.

사전 요구 사항

  • jq 유틸리티를 설치했습니다.
  • API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.
  • 검색 ISO로 호스트가 부팅됨
  • CLUSTER_ID 로 쉘에 클러스터 ID를 내보내고 있어야 합니다.
  • API에 액세스할 때 사용할 인증 정보가 있고 쉘에서 토큰을 API_TOKEN 로 내보낸 것입니다.

프로시저

  1. API 토큰을 새로 고칩니다.

    $ source refresh-token
  2. 모든 호스트에 대한 모든 검증을 가져옵니다.

    $ curl \
      --silent \
      --header "Authorization: Bearer $API_TOKEN" \
      https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/hosts \
      | jq -r .[].validations_info \
      | jq 'map(.[])'
  3. 모든 호스트에 대해 바이패스(passing)를 가져옵니다.

    $ curl \
      --silent \
      --header "Authorization: Bearer $API_TOKEN" \
      https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/hosts \
      | jq -r .[].validations_info \
      | jq 'map(.[]) | map(select(.status=="failure" or .status=="pending")) | select(length>0)'

10.4.2. 호스트 검증 세부 정보

매개변수검증 유형설명

연결

비차단(Non-blocking)

호스트가 최근에 지원 설치 관리자와 통신했는지 확인합니다.

has-inventory

비차단(Non-blocking)

지원 설치 프로그램이 호스트에서 인벤토리를 수신했는지 확인합니다.

has-min-cpu-cores

비차단(Non-blocking)

CPU 코어 수가 최소 요구사항을 충족하는지 확인합니다.

has-min-memory

비차단(Non-blocking)

메모리 양이 최소 요구 사항을 충족하는지 확인합니다.

has-min-valid-disks

비차단(Non-blocking)

사용 가능한 디스크가 자격 기준을 충족하는지 확인합니다.

has-cpu-cores-for-role

차단

코어 수가 호스트 역할에 대한 최소 요구사항을 충족하는지 확인합니다.

has-memory-for-role

차단

메모리 양이 호스트 역할에 대한 최소 요구사항을 충족하는지 확인합니다.

ignition-downloadable

차단

2일 차 호스트의 경우 호스트에서 1일 차 클러스터에서 ignition 구성을 다운로드할 수 있는지 확인합니다.

belongs-to-majority-group

차단

대부분의 그룹은 클러스터에서 가장 큰 전체-mesh 연결 그룹이며, 모든 멤버가 다른 모든 멤버와 통신할 수 있습니다. 이 검증은 다중 노드 1 클러스터의 호스트가 대다수 그룹에 있는지 확인합니다.

valid-platform-network-settings

차단

플랫폼이 네트워크 설정에 유효한지 확인합니다.

ntp-synced

비차단(Non-blocking)

NTP 서버가 호스트의 시간을 동기화하는 데 성공적으로 사용되는지 확인합니다.

container-images-available

비차단(Non-blocking)

이미지 레지스트리에서 컨테이너 이미지를 가져왔는지 확인합니다.

sufficient-installation-disk-speed

차단

이전 설치의 디스크 속도 메트릭이 있는 경우 요구 사항을 충족하는지 확인합니다.

sufficient-network-latency-requirement-for-role

차단

클러스터의 호스트 간 평균 네트워크 대기 시간이 요구 사항을 충족하는지 확인합니다.

sufficient-packet-loss-requirement-for-role

차단

클러스터의 호스트 간 네트워크 패킷 손실이 요구 사항을 충족하는지 확인합니다.

has-default-route

차단

호스트에 기본 경로가 구성되어 있는지 확인합니다.

api-domain-name-resolved-correctly

차단

사용자 관리 네트워킹이 있는 다중 노드 클러스터의 경우 호스트에서 클러스터의 API 도메인 이름을 확인할 수 있는지 확인합니다.

api-int-domain-name-resolved-correctly

차단

사용자 관리 네트워킹이 있는 다중 노드 클러스터의 경우 호스트가 클러스터의 내부 API 도메인 이름을 확인할 수 있는지 확인합니다.

apps-domain-name-resolved-correctly

차단

사용자 관리 네트워킹이 있는 다중 노드 클러스터의 경우 호스트가 클러스터의 내부 앱 도메인 이름을 확인할 수 있는지 확인합니다.

compatible-with-cluster-platform

비차단(Non-blocking)

호스트가 클러스터 플랫폼과 호환되는지 확인

dns-wildcard-not-configured

차단

와일드카드 DNS *.<cluster_name>.<base_domain>이 구성되지 않았는지 확인합니다. OpenShift에 알려진 문제가 발생하기 때문입니다.

disk-encryption-requirements-satisfied

비차단(Non-blocking)

구성된 호스트 및 디스크 암호화 유형이 요구 사항을 충족하는지 확인합니다.

non-overlapping-subnets

차단

이 호스트에 겹치는 서브넷이 없는지 확인합니다.

hostname-unique

차단

호스트 이름이 클러스터에서 고유한지 확인합니다.

hostname-valid

차단

호스트 이름의 유효성을 확인합니다. 즉, 호스트 이름의 일반 형식과 일치하며 허용되지 않습니다.

belongs-to-machine-cidr

차단

호스트 IP가 시스템 CIDR의 주소 범위에 있는지 확인합니다.

lso-requirements-satisfied

차단

클러스터가 Local Storage Operator의 요구 사항을 충족하는지 확인합니다.

odf-requirements-satisfied

차단

클러스터가 Openshift Data Foundation Operator의 요구 사항을 충족하는지 확인합니다.

  • 클러스터에는 최소 3개의 호스트가 있습니다.
  • 클러스터에는 마스터가 3개 또는 최소 3개의 작업자가 있습니다.
  • 클러스터에는 3개의 적격 디스크가 있으며 각 호스트에는 적합한 디스크가 있어야 합니다.
  • 호스트 역할은 호스트가 세 개 이상인 클러스터의 "자동 할당"이 아니어야 합니다.

cnv-requirements-satisfied

차단

클러스터가 Container Native Virtualization의 요구 사항을 충족하는지 확인합니다.

  • 호스트의 BIOS에 CPU 가상화가 활성화되어 있어야 합니다.
  • 호스트에는 컨테이너 네이티브 가상화에 사용할 수 있는 충분한 CPU 코어 및 RAM이 있어야 합니다.
  • 필요한 경우 호스트 경로 프로비저닝 프로그램의 유효성을 검사합니다.

lvm-requirements-satisfied

차단

클러스터가 Logical Volume Manager Operator의 요구 사항을 충족하는지 확인합니다.

  • host에 분할되지 않고 포맷되지 않은 추가 빈 디스크가 하나 이상 있습니다.

vsphere-disk-uuid-enabled

비차단(Non-blocking)

유효한 각 디스크가 disk.EnableUUIDtrue 로 설정했는지 확인합니다. VSphere에서 이 경우 각 디스크에 UUID가 있습니다.

compatible-agent

차단

검색 에이전트 버전이 에이전트 Docker 이미지 버전과 호환되는지 확인합니다.

no-skip-installation-disk

차단

설치 디스크가 디스크 포맷을 건너뛰지 않는지 확인합니다.

no-skip-missing-disk

차단

포맷을 건너뛰도록 표시된 모든 디스크가 인벤토리에 있는지 확인합니다. 재부팅 시 디스크 ID가 변경될 수 있으며 이 검증으로 인해 발생한 문제가 발생하지 않습니다.

Media-connected

차단

호스트에 대한 설치 미디어의 연결을 확인합니다.

machine-cidr-defined

비차단(Non-blocking)

클러스터의 시스템 네트워크 정의가 존재하는지 확인합니다.

id-platform-network-settings

차단

플랫폼이 네트워크 설정과 호환되는지 확인합니다. 일부 플랫폼은 단일 노드 Openshift를 설치하거나 사용자 관리 네트워킹을 사용하는 경우에만 허용됩니다.

10.5. 클러스터 검증

10.5.1. REST API를 사용하여 클러스터 검증 가져오기

참고: 웹 기반 UI를 사용하는 경우 이러한 검증 중 대다수가 이름으로 표시되지 않습니다. 레이블과 일치하는 검증 목록을 가져오려면 다음 절차를 사용하십시오.

사전 요구 사항

  • jq 유틸리티를 설치했습니다.
  • API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.
  • CLUSTER_ID 로 쉘에 클러스터 ID를 내보내고 있어야 합니다.
  • API에 액세스할 때 사용할 인증 정보가 있고 쉘에서 토큰을 API_TOKEN 로 내보낸 것입니다.

프로시저

  1. API 토큰을 새로 고칩니다.

    $ source refresh-token
  2. 모든 클러스터 검증을 가져옵니다.

    $ curl \
      --silent \
      --header "Authorization: Bearer $API_TOKEN" \
      https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID \
      | jq -r .validations_info \
      | jq 'map(.[])'
  3. 클러스터 검증을 통과하지 않음을 가져옵니다.

    $ curl \
      --silent \
      --header "Authorization: Bearer $API_TOKEN" \
      https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID \
      | jq -r .validations_info \
      | jq '. | map(.[] | select(.status=="failure" or .status=="pending")) | select(length>0)'

10.5.2. 클러스터 검증 세부 정보

매개변수검증 유형설명

machine-cidr-defined

비차단(Non-blocking)

클러스터의 시스템 네트워크 정의가 존재하는지 확인합니다.

cluster-cidr-defined

비차단(Non-blocking)

클러스터에 대한 클러스터 네트워크 정의가 존재하는지 확인합니다.

service-cidr-defined

비차단(Non-blocking)

클러스터의 서비스 네트워크 정의가 존재하는지 확인합니다.

no-cidrs-overlapping

차단

정의된 네트워크가 겹치지 않는지 확인합니다.

networks-same-address-families

차단

정의된 네트워크가 동일한 주소 제품군을 공유하는지 확인합니다(유효한 주소 제품군은 IPv4, IPv6)

network-prefix-valid

차단

클러스터 네트워크 접두사가 유효하고 모든 호스트에 충분한 주소 공간을 허용하는지 확인합니다.

machine-cidr-equals-to-calculated-cidr

차단

사용자 관리 네트워킹 클러스터의 경우 apiVIPs 또는 ingressVIPs 가 있는 경우 머신 CIDR의 멤버인지 확인합니다.

api-vips-defined

비차단(Non-blocking)

사용자 관리 네트워킹 클러스터의 경우 apiVIPs 가 존재하는지 확인합니다.

api-vips-valid

차단

사용자 관리 네트워킹 클러스터의 경우 apiVIPs 가 머신 CIDR에 속하고 사용되지 않는지 확인합니다.

ingress-vips-defined

차단

사용자 관리 네트워킹 클러스터의 경우 ingressVIPs 가 있는지 확인합니다.

ingress-vips-valid

비차단(Non-blocking)

사용자 관리 네트워킹 클러스터의 경우 ingressVIPs 가 머신 CIDR에 속하고 사용되지 않는지 확인합니다.

all-hosts-are-ready-to-install

차단

클러스터의 모든 호스트가 "설치 가능" 상태인지 확인합니다.

sufficient-masters-count

차단

이 검증은 다중 노드 클러스터에만 적용됩니다.

  • 클러스터에는 정확히 세 개의 마스터가 있어야 합니다.
  • 클러스터에 작업자 노드가 있는 경우 최소 2개의 작업자 노드가 있어야 합니다.

dns-domain-defined

비차단(Non-blocking)

클러스터의 기본 DNS 도메인이 있는지 확인합니다.

pull-secret-set

비차단(Non-blocking)

풀 시크릿이 있는지 확인합니다. 풀 시크릿이 유효한지 또는 권한이 있는지 확인하지 않습니다.

ntp-server-configured

차단

호스트 시계가 4분 이상 동기화되지 않는지 확인합니다.

lso-requirements-satisfied

차단

클러스터가 Local Storage Operator의 요구 사항을 충족하는지 확인합니다.

odf-requirements-satisfied

차단

클러스터가 Openshift Data Foundation Operator의 요구 사항을 충족하는지 확인합니다.

  • 클러스터에는 최소 3개의 호스트가 있습니다.
  • 클러스터에는 마스터가 3개 또는 최소 3개의 작업자가 있습니다.
  • 클러스터에는 3개의 적격 디스크가 있으며 각 호스트에는 적합한 디스크가 있어야 합니다.

cnv-requirements-satisfied

차단

클러스터가 Container Native Virtualization의 요구 사항을 충족하는지 확인합니다.

  • 클러스터의 CPU 아키텍처는 x86입니다.

lvm-requirements-satisfied

차단

클러스터가 Logical Volume Manager Operator의 요구 사항을 충족하는지 확인합니다.

  • 클러스터는 단일 노드여야 합니다.
  • 클러스터는 Openshift >= 4.11.0을 실행해야 합니다.

network-type-valid

차단

네트워크 유형이 존재하는 경우 유효성을 검사합니다.

  • 네트워크 유형은 OpenshiftSDN 또는 OVNKubernetes여야 합니다.
  • OpenShiftSDN은 IPv6 또는 단일 노드 Openshift를 지원하지 않습니다.
  • OVNKubernetes는 VIP DHCP 할당을 지원하지 않습니다.

11장. 네트워크 구성

이 섹션에서는 지원 설치 관리자를 사용한 네트워크 구성의 기본 사항에 대해 설명합니다.

11.1. 클러스터 네트워킹

OpenShift에서 사용하는 다양한 네트워크 유형 및 주소가 있으며 아래 표에 나열되어 있습니다.

유형DNS설명

clusterNetwork

 

Pod IP 주소가 할당되는 IP 주소 풀입니다.

serviceNetwork

 

서비스의 IP 주소 풀입니다.

machineNetwork

 

클러스터를 형성하는 시스템의 IP 주소 블록입니다.

apiVIP

api.<clustername.clusterdomain>

API 통신에 사용할 VIP입니다. 이 설정은 기본 이름이 올바르게 확인되도록 DNS에서 지정되거나 사전에 설정해야 합니다. 듀얼 스택 네트워킹을 사용하여 배포하는 경우 IPv4 주소여야 합니다.

apiVIPs

api.<clustername.clusterdomain>

API 통신에 사용할 VIP입니다. 이 설정은 기본 이름이 올바르게 확인되도록 DNS에서 지정되거나 사전에 설정해야 합니다. 듀얼 스택 네트워킹을 사용하는 경우 첫 번째 주소는 IPv4 주소여야 하며 두 번째 주소는 IPv6 주소여야 합니다. apiVIP 설정도 설정해야 합니다.

ingressVIP

*.apps.<clustername.clusterdomain>

Ingress 트래픽에 사용할 VIP입니다. 듀얼 스택 네트워킹을 사용하여 배포하는 경우 IPv4 주소여야 합니다.

ingressVIPs

*.apps.<clustername.clusterdomain>

Ingress 트래픽에 사용할 VIP입니다. 듀얼 스택 네트워킹을 사용하여 배포하는 경우 첫 번째 주소는 IPv4 주소여야 하며 두 번째 주소는 IPv6 주소여야 합니다. ingressVIP 설정도 설정해야 합니다.

참고

OpenShift Container Platform 4.12에는 듀얼 스택 네트워킹에 대해 여러 IP 주소를 수락하기 위해 새로운 apiVIPsingressVIPs 설정이 도입되었습니다. 듀얼 스택 네트워킹을 사용하는 경우 첫 번째 IP 주소는 IPv4 주소여야 하며 두 번째 IP 주소는 IPv6 주소여야 합니다. 새 설정은 apiVIPIngressVIP 를 대체하지만 API를 사용하여 구성을 수정할 때 새 설정과 이전 설정을 모두 설정해야 합니다.

원하는 네트워크 스택에 따라 다양한 네트워크 컨트롤러를 선택할 수 있습니다. 현재 지원 서비스는 다음 구성 중 하나를 사용하여 OpenShift Container Platform 클러스터를 배포할 수 있습니다.

  • IPv4
  • IPv6
  • 듀얼 스택(IPv4 + IPv6)

지원되는 네트워크 컨트롤러는 선택한 스택에 따라 다르며 아래 표에 요약되어 있습니다. 자세한 CNI(Container Network Interface) 네트워크 공급자 기능 비교의 경우 OCP 네트워킹 설명서 를 참조하십시오.

스택SDNOVN

IPv4

제공됨

제공됨

IPv6

없음

제공됨

듀얼 스택

없음

제공됨

참고

OVN은 OpenShift Container Platform 4.12 이상 릴리스의 기본 CNI(Container Network Interface)입니다.

11.1.1. 제한

11.1.1.1. SDN

  • SNO(Single Node OpenShift)에서는 SDN 컨트롤러가 지원되지 않습니다.
  • SDN 컨트롤러는 IPv6를 지원하지 않습니다.

11.1.1.2. OVN-Kubernetes

OCP 문서의 OVN-Kubernetes 제한 사항 섹션을 참조하십시오.

11.1.2. 클러스터 네트워크

클러스터 네트워크는 클러스터에 배포된 모든 Pod가 해당 IP 주소를 가져오는 네트워크입니다. 워크로드를 클러스터를 구성하는 여러 노드에 걸쳐 존재할 수 있으므로 네트워크 공급자가 Pod의 IP 주소를 기반으로 개별 노드를 쉽게 찾을 수 있어야 합니다. 이를 위해 clusterNetwork.cidrclusterNetwork.hostPrefix 에 정의된 크기의 서브넷으로 추가로 분할됩니다.

호스트 접두사는 클러스터의 각 개별 노드에 할당된 서브넷의 길이를 지정합니다. 클러스터가 다중 노드 클러스터에 주소를 할당하는 방법의 예입니다.

---
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
---

위 스니펫을 사용하여 3-노드 클러스터를 생성하면 다음과 같은 네트워크 토폴로지가 생성될 수 있습니다.

  • 노드 #1에 예약된 Pod는 10.128.0.0/23에서 IP를 가져옵니다.
  • #2 노드에 예약된 Pod는 10.128.2.0/23에서 IP를 가져옵니다.
  • 노드 #3에 예약된 Pod는 10.128.4.0/23에서 IP를 가져옵니다.

OVN-K8s 내부를 설명하는 것은 이 문서에 포함되지 않지만, 위에서 설명한 패턴은 Pod와 해당 노드 간에 큰 매핑 목록을 유지하지 않고 다른 노드 간에 Pod-to-Pod 트래픽을 라우팅하는 방법을 제공합니다.

11.1.3. 머신 네트워크

시스템 네트워크는 클러스터를 구성하여 서로 통신하도록 구성하는 모든 호스트에서 사용하는 네트워크입니다. API 및 Ingress VIP를 포함해야 하는 서브넷이기도 합니다.

11.1.4. 다중 노드 클러스터와 비교하여 SNO

단일 노드 OpenShift 또는 다중 노드 클러스터를 배포하는지 여부에 따라 다른 값이 필요합니다. 아래 표는 이에 대해 자세히 설명합니다.

매개변수SNODHCP 모드를 사용하는 다중 노드 클러스터DHCP 모드가 없는 다중 노드 클러스터

clusterNetwork

필수 항목

필수 항목

필수 항목

serviceNetwork

필수 항목

필수 항목

필수 항목

machineNetwork

자동 할당 가능 (*)

자동 할당 가능 (*)

자동 할당 가능 (*)

apiVIP

허용되지 않음

허용되지 않음

필수 항목

apiVIPs

허용되지 않음

허용되지 않음

4.12 이상 릴리스에서 필수

ingressVIP

허용되지 않음

허용되지 않음

필수 항목

ingressVIPs

허용되지 않음

허용되지 않음

4.12 이상 릴리스에서 필수

*) 단일 호스트 네트워크만 있는 경우 머신 네트워크 CIDR의 자동 할당이 수행됩니다. 그렇지 않으면 명시적으로 지정해야 합니다.

11.1.5. Air-gapped 환경

인터넷 액세스 없이 클러스터를 배포하는 워크플로에는 이 문서의 범위를 벗어나는 사전 요구 사항이 있습니다. Zero 10.0.0.1 Provisioning 일부 정보를 보려면 Git 리포지토리를 하드 방식으로 프로비저닝하는 것을 참조할 수 있습니다.

11.2. DHCP VIP 할당

VIP DHCP 할당은 사용자가 DHCP 서버에서 해당 IP 주소를 자동으로 할당하는 기능을 활용하여 API 및 Ingress에 대한 가상 IP를 수동으로 제공하는 요구 사항을 건너뛸 수 있는 기능입니다.

클러스터 구성에서 api_vipsingress_vips 를 사용하는 대신 기능을 활성화하면 서비스는 리스 할당 요청을 보내고 응답에 따라 VIP를 사용합니다. 이 서비스는 Machine Network에서 IP 주소를 할당합니다.

이는 OpenShift Container Platform 기능이 아니며 설정을 더 쉽게 만들기 위해 지원 서비스에 구현되어 있습니다.

11.2.1. 자동 할당을 활성화하는 페이로드 예

---
{
  "vip_dhcp_allocation": true,
  "network_type": "OVNKubernetes",
  "user_managed_networking": false,
  "cluster_networks": [
    {
      "cidr": "10.128.0.0/14",
      "host_prefix": 23
    }
  ],
  "service_networks": [
    {
      "cidr": "172.30.0.0/16"
    }
  ],
  "machine_networks": [
    {
      "cidr": "192.168.127.0/24"
    }
  ]
}
---

11.2.2. 자동 할당을 비활성화하는 페이로드 예

---
{
  "api_vip": "192.168.127.100",
  "api_vips": [
    {
        "ip": "192.168.127.100"
    }
  ],
  "ingress_vip": "192.168.127.101",
  "ingress_vips": [
    {
        "ip": "192.168.127.101"
    }
  ],
  "vip_dhcp_allocation": false,
  "network_type": "OVNKubernetes",
  "user_managed_networking": false,
  "cluster_networks": [
    {
      "cidr": "10.128.0.0/14",
      "host_prefix": 23
    }
  ],
  "service_networks": [
    {
      "cidr": "172.30.0.0/16"
    }
  ]
}
---
참고

OpenShift Container Platform 4.12에서는 레거시 api_vipingress_vip 설정과 새 api_vipsingress_vips 설정을 모두 설정해야 합니다.

11.3. 추가 리소스

11.4. User Managed Networking과 Cluster Managed Networking의 차이점

사용자 관리 네트워킹은 비표준 네트워크 토폴로지를 사용하는 고객이 OpenShift Container Platform 클러스터를 배포할 수 있는 지원 설치 관리자의 기능입니다. 예를 들면 다음과 같습니다.

  • VIP 주소를 처리하기 위해 keepalived 및 VRRP를 사용하지 않으려는 외부 로드 밸런서가 있는 고객.
  • 여러 다른 L2 네트워크 세그먼트에 분산된 클러스터 노드를 사용한 배포.

11.4.1. 검증

지원 설치 관리자에서 설치를 시작하기 전에 다양한 네트워크 검증이 수행됩니다. User Managed Networking을 활성화하면 다음과 같은 검증이 변경됩니다.

  • L2 검사(ARP) 대신 L3 연결 검사(ICMP) 수행

11.5. 정적 네트워크 구성

검색 ISO를 생성하거나 업데이트할 때 정적 네트워크 구성을 사용할 수 있습니다.

11.5.1. 사전 요구 사항

  • NMState 에 대해 잘 알고 있습니다.

11.5.2. NMState 구성

YAML 형식의 NMState 파일은 호스트에 대해 원하는 네트워크 구성을 지정합니다. 검색 시 인터페이스의 실제 이름으로 대체되는 인터페이스의 논리 이름이 있습니다.

11.5.2.1. NMState 구성 예

---
dns-resolver:
  config:
    server:
    - 192.168.126.1
interfaces:
- ipv4:
    address:
    - ip: 192.168.126.30
      prefix-length: 24
    dhcp: false
    enabled: true
  name: eth0
  state: up
  type: ethernet
- ipv4:
    address:
    - ip: 192.168.141.30
      prefix-length: 24
    dhcp: false
    enabled: true
  name: eth1
  state: up
  type: ethernet
routes:
  config:
  - destination: 0.0.0.0/0
    next-hop-address: 192.168.126.1
    next-hop-interface: eth0
    table-id: 254
---

11.5.3. MAC 인터페이스 매핑

MAC 인터페이스 맵은 호스트에 있는 실제 인터페이스를 사용하여 NMState 구성에 정의된 논리 인터페이스를 매핑하는 속성입니다.

매핑은 항상 호스트에 있는 물리적 인터페이스를 사용해야 합니다. 예를 들어 NMState 구성에서 본딩 또는 VLAN을 정의하는 경우 매핑에는 상위 인터페이스에 대한 항목만 포함되어야 합니다.

11.5.3.1. MAC 인터페이스 매핑 예

---
mac_interface_map: [
    {
      mac_address: 02:00:00:2c:23:a5,
      logical_nic_name: eth0
    },
    {
      mac_address: 02:00:00:68:73:dc,
      logical_nic_name: eth1
    }
]
---

11.5.4. 추가 NMState 구성 예

아래 예제는 부분 구성만 표시합니다. 이는 그대로 사용할 수 없으며 항상 사용할 환경에 맞게 조정해야 합니다. 잘못 사용된 경우 네트워크 연결이 없는 머신을 남겨 둘 수 있습니다.

11.5.4.1. 태그가 지정된 VLAN

---
    interfaces:
    - ipv4:
        address:
        - ip: 192.168.143.15
          prefix-length: 24
        dhcp: false
        enabled: true
      ipv6:
        enabled: false
      name: eth0.404
      state: up
      type: vlan
      vlan:
        base-iface: eth0
        id: 404
---

11.5.4.2. 네트워크 본딩

---
    interfaces:
    - ipv4:
        address:
        - ip: 192.168.138.15
          prefix-length: 24
        dhcp: false
        enabled: true
      ipv6:
        enabled: false
      link-aggregation:
        mode: active-backup
        options:
          all_slaves_active: delivered
          miimon: "140"
        slaves:
        - eth0
        - eth1
      name: bond0
      state: up
      type: bond
---

11.6. API를 사용하여 정적 네트워크 구성 적용

지원 설치 관리자 API를 사용하여 정적 네트워크 구성을 적용할 수 있습니다.

사전 요구 사항

  1. API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.
  2. 쉘에서 $INFRA_ENV_ID 로 내보낸 인프라 환경 ID가 있어야 합니다.
  3. API에 액세스할 때 사용할 자격 증명이 있고 쉘에서 $API_TOKEN 으로 토큰을 내보냈습니다.
  4. server-a.yamlserver-b.yaml 로 사용 가능한 정적 네트워크 구성이 있는 YAML 파일이 있습니다.

절차

  1. API 요청을 사용하여 임시 파일 /tmp/request-body.txt 를 만듭니다.

    ---
    jq -n --arg NMSTATE_YAML1 "$(cat server-a.yaml)" --arg NMSTATE_YAML2 "$(cat server-b.yaml)" \
    '{
      "static_network_config": [
        {
          "network_yaml": $NMSTATE_YAML1,
          "mac_interface_map": [{"mac_address": "02:00:00:2c:23:a5", "logical_nic_name": "eth0"}, {"mac_address": "02:00:00:68:73:dc", "logical_nic_name": "eth1"}]
        },
        {
          "network_yaml": $NMSTATE_YAML2,
          "mac_interface_map": [{"mac_address": "02:00:00:9f:85:eb", "logical_nic_name": "eth1"}, {"mac_address": "02:00:00:c8:be:9b", "logical_nic_name": "eth0"}]
         }
      ]
    }' >> /tmp/request-body.txt
    ---
  2. API 토큰을 새로 고칩니다.

    $ source refresh-token
  3. 지원 서비스 API 끝점에 요청을 보냅니다.

    ---
    curl -H "Content-Type: application/json" \
    -X PATCH -d @/tmp/request-body.txt \
    -H "Authorization: Bearer ${API_TOKEN}" \
    https://api.openshift.com/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID
    ---

11.7. 추가 리소스

11.8. 듀얼 스택 네트워킹으로 변환

듀얼 스택 IPv4/IPv6 구성을 사용하면 IPv4 및 IPv6 서브넷에 상주하는 포드가 있는 클러스터를 배포할 수 있습니다.

11.8.1. 사전 요구 사항

11.8.2. 단일 노드 OpenShift의 페이로드 예

---
{
  "network_type": "OVNKubernetes",
  "user_managed_networking": false,
  "cluster_networks": [
    {
      "cidr": "10.128.0.0/14",
      "host_prefix": 23
    },
    {
      "cidr": "fd01::/48",
      "host_prefix": 64
    }
  ],
  "service_networks": [
    {"cidr": "172.30.0.0/16"}, {"cidr": "fd02::/112"}
  ],
  "machine_networks": [
    {"cidr": "192.168.127.0/24"},{"cidr": "1001:db8::/120"}
  ]
}
---

11.8.3. 많은 노드로 구성된 OpenShift Container Platform 클러스터의 페이로드 예

---
{
  "vip_dhcp_allocation": false,
  "network_type": "OVNKubernetes",
  "user_managed_networking": false,
  "api_vip": "192.168.127.100",
  "api_vips": [
     {
        "ip": "192.168.127.100"
     },
     {
        "ip": "2001:0db8:85a3:0000:0000:8a2e:0370:7334"
     }
  ],
  "ingress_vip": "192.168.127.101",
  "ingress_vips": [
     {
        "ip": "192.168.127.101"
     },
     {
        "ip": "2001:0db8:85a3:0000:0000:8a2e:0370:7335"
     }
  ],
  "cluster_networks": [
    {
      "cidr": "10.128.0.0/14",
      "host_prefix": 23
    },
    {
      "cidr": "fd01::/48",
      "host_prefix": 64
    }
  ],
  "service_networks": [
    {"cidr": "172.30.0.0/16"}, {"cidr": "fd02::/112"}
  ],
  "machine_networks": [
    {"cidr": "192.168.127.0/24"},{"cidr": "1001:db8::/120"}
  ]
}
---

11.8.4. 제한

api_vip IP 주소와 ingress_vip IP 주소 설정은 IPv4 주소여야 하는 듀얼 스택 네트워킹을 사용할 때 기본 IP 주소 제품군이어야 합니다. 현재 Red Hat은 IPv6를 사용한 듀얼 스택 VIP 또는 듀얼 스택 네트워킹을 기본 IP 주소 제품군으로 지원하지 않습니다. Red Hat은 IPv4를 기본 IP 주소 제품군으로 사용하는 듀얼 스택 네트워킹을 보조 IP 주소 제품군으로 지원합니다. 따라서 IP 주소 값을 입력할 때 IPv6 항목 앞에 IPv4 항목을 배치해야 합니다.

OpenShift Container Platform 4.12에서는 VIP 주소에서 듀얼 스택 네트워킹을 사용하려면 레거시 api_vipingress_vip 설정과 새 api_vipsingress_vips 설정을 모두 설정해야 합니다. 레거시 api_vipingress_vip 설정은 각각 하나의 값만 사용하므로 IPv4 주소여야 합니다.

11.9. 추가 리소스

12장. 클러스터 확장

사용자 인터페이스 또는 API를 사용하여 호스트를 추가하여 지원 설치 관리자로 설치된 클러스터를 확장할 수 있습니다.

12.1. 사전 요구 사항

  • 지원 설치 프로그램 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)를 설치해야 합니다.
  • 작업자 노드를 추가하는 클러스터에 필요한 모든 DNS 레코드가 있는지 확인합니다.
  • 여러 CPU 아키텍처가 있는 클러스터에 작업자 노드를 추가하는 경우 아키텍처가 multi 로 설정되어 있는지 확인해야 합니다.

12.2. 여러 아키텍처 확인

여러 아키텍처가 있는 클러스터에 노드를 추가할 때 아키텍처 설정이 multi 로 설정되어 있는지 확인합니다.

절차

  1. CLI를 사용하여 클러스터에 로그인합니다.
  2. 아키텍처 설정을 확인합니다.

    $ oc adm release info -o json | jq .metadata.metadata

    architecture 설정이 'multi'로 설정되어 있는지 확인합니다.

    {
      "release.openshift.io/architecture": "multi"
    }

12.3. UI로 호스트 추가

지원 설치 관리자를 사용하여 생성된 클러스터에 호스트를 추가할 수 있습니다.

중요

지원 설치 관리자 클러스터에 호스트를 추가하는 것은 OpenShift Container Platform 버전 4.11 이상을 실행하는 클러스터에서만 지원됩니다.

절차

  1. OpenShift Cluster Manager 에 로그인하고 확장할 클러스터를 클릭합니다.
  2. 호스트 추가를 클릭하고 새 호스트에 대한 검색 ISO를 다운로드하여 SSH 공개 키를 추가하고 필요에 따라 클러스터 전체 프록시 설정을 구성합니다.
  3. 선택 사항: 필요에 따라 Ignition 파일을 수정합니다.
  4. 검색 ISO를 사용하여 대상 호스트를 부팅하고 콘솔에서 호스트를 검색할 때까지 기다립니다.
  5. 호스트 역할을 선택합니다. 작업자 또는 컨트롤 플레인 호스트일 수 있습니다.
  6. 설치를 시작합니다.
  7. 설치가 진행되면 설치에 호스트에 대한 보류 중인 인증서 서명 요청(CSR)이 생성됩니다. 메시지가 표시되면 보류 중인 CSR을 승인하여 설치를 완료합니다.

    호스트가 정상적으로 설치되면 클러스터 웹 콘솔에 호스트로 나열됩니다.

중요

새 호스트는 원래 클러스터와 동일한 방법을 사용하여 암호화됩니다.

12.4. API를 사용하여 호스트 추가

지원 설치 관리자 REST API를 사용하여 클러스터에 호스트를 추가할 수 있습니다.

사전 요구 사항

  • OpenShift Cluster Manager CLI(ocm)를 설치합니다.
  • 클러스터 생성 권한이 있는 사용자로 OpenShift Cluster Manager 에 로그인합니다.
  • jq 를 설치합니다.
  • 확장하려는 클러스터에 필요한 모든 DNS 레코드가 있는지 확인합니다.

절차

  1. 지원 설치 관리자 REST API에 대해 인증하고 세션에 대한 API 토큰을 생성합니다. 생성된 토큰은 15분 동안만 유효합니다.
  2. 다음 명령을 실행하여 $API_URL 변수를 설정합니다.

    $ export API_URL=<api_url> 1
    1
    & lt;api_url& gt;을 지원 설치 관리자 API URL로 바꿉니다(예: https://api.openshift.com) .
  3. 다음 명령을 실행하여 클러스터를 가져옵니다.

    1. $CLUSTER_ID 변수를 설정합니다. 클러스터에 로그인하고 다음 명령을 실행합니다.

      $ export CLUSTER_ID=$(oc get clusterversion -o jsonpath='{.items[].spec.clusterID}')
    2. 클러스터를 가져오는 데 사용되는 $CLUSTER_REQUEST 변수를 설정합니다.

      $ export CLUSTER_REQUEST=$(jq --null-input --arg openshift_cluster_id "$CLUSTER_ID" '{
        "api_vip_dnsname": "<api_vip>", 1
        "openshift_cluster_id": $CLUSTER_ID,
        "name": "<openshift_cluster_name>" 2
      }')
      1
      & lt;api_vip >를 클러스터 API 서버의 호스트 이름으로 바꿉니다. API 서버의 DNS 도메인 또는 호스트가 도달할 수 있는 단일 노드의 IP 주소일 수 있습니다. 예를 들면 api.compute-1.example.com 입니다.
      2
      & lt;openshift_cluster_name& gt;을 클러스터의 일반 텍스트 이름으로 바꿉니다. 클러스터 이름은 Day 1 클러스터 설치 중에 설정된 클러스터 이름과 일치해야 합니다.
    3. 클러스터를 가져와서 $CLUSTER_ID 변수를 설정합니다. 다음 명령을 실행합니다.

      $ CLUSTER_ID=$(curl "$API_URL/api/assisted-install/v2/clusters/import" -H "Authorization: Bearer ${API_TOKEN}" -H 'accept: application/json' -H 'Content-Type: application/json' \
        -d "$CLUSTER_REQUEST" | tee /dev/stderr | jq -r '.id')
  4. 클러스터에 대한 InfraEnv 리소스를 생성하고 다음 명령을 실행하여 $INFRA_ENV_ID 변수를 설정합니다.

    1. console.redhat.com 의 Red Hat OpenShift Cluster Manager에서 풀 시크릿 파일을 다운로드합니다.
    2. $INFRA_ENV_REQUEST 변수를 설정합니다.

      export INFRA_ENV_REQUEST=$(jq --null-input \
          --slurpfile pull_secret <path_to_pull_secret_file> \1
          --arg ssh_pub_key "$(cat <path_to_ssh_pub_key>)" \2
          --arg cluster_id "$CLUSTER_ID" '{
        "name": "<infraenv_name>", 3
        "pull_secret": $pull_secret[0] | tojson,
        "cluster_id": $cluster_id,
        "ssh_authorized_key": $ssh_pub_key,
        "image_type": "<iso_image_type>" 4
      }')
      1
      < path_to_pull_secret_file >을 console.redhat.com 의 Red Hat OpenShift Cluster Manager에서 다운로드한 풀 시크릿이 포함된 로컬 파일의 경로로 바꿉니다.
      2
      & lt;path_to_ssh_pub_key >를 호스트에 액세스하는 데 필요한 공용 SSH 키의 경로로 바꿉니다. 이 값을 설정하지 않으면 검색 모드에서 호스트에 액세스할 수 없습니다.
      3
      & lt;infraenv_name& gt;을 InfraEnv 리소스의 일반 텍스트 이름으로 바꿉니다.
      4
      & lt;iso_image_type >을 full-iso 또는 minimal-iso 이미지 유형으로 바꿉니다.
    3. $INFRA_ENV_REQUEST/v2/infra-envs API에 게시하고 $INFRA_ENV_ID 변수를 설정합니다.

      $ INFRA_ENV_ID=$(curl "$API_URL/api/assisted-install/v2/infra-envs" -H "Authorization: Bearer ${API_TOKEN}" -H 'accept: application/json' -H 'Content-Type: application/json' -d "$INFRA_ENV_REQUEST" | tee /dev/stderr | jq -r '.id')
  5. 다음 명령을 실행하여 클러스터 호스트에 대한 검색 ISO의 URL을 가져옵니다.

    $ curl -s "$API_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID" -H "Authorization: Bearer ${API_TOKEN}" | jq -r '.download_url'

    출력 예

    https://api.openshift.com/api/assisted-images/images/41b91e72-c33e-42ee-b80f-b5c5bbf6431a?arch=x86_64&image_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2NTYwMjYzNzEsInN1YiI6IjQxYjkxZTcyLWMzM2UtNDJlZS1iODBmLWI1YzViYmY2NDMxYSJ9.1EX_VGaMNejMhrAvVRBS7PDPIQtbOOc8LtG8OukE1a4&type=minimal-iso&version=4.12

  6. ISO를 다운로드합니다.

    $ curl -L -s '<iso_url>' --output rhcos-live-minimal.iso 1
    1
    & lt;iso_url >을 이전 단계의 ISO URL로 바꿉니다.
  7. 다운로드한 rhcos-live-minimal.iso 에서 새 작업자 호스트를 부팅합니다.
  8. 설치되지 않은 클러스터에서 호스트 목록을 가져옵니다. 새 호스트가 표시될 때까지 다음 명령을 계속 실행하십시오.

    $ curl -s "$API_URL/api/assisted-install/v2/clusters/$CLUSTER_ID" -H "Authorization: Bearer ${API_TOKEN}" | jq -r '.hosts[] | select(.status != "installed").id'

    출력 예

    2294ba03-c264-4f11-ac08-2f1bb2f8c296

  9. 새 호스트의 $HOST_ID 변수를 설정합니다. 예를 들면 다음과 같습니다.

    $ HOST_ID=<host_id> 1
    1
    & lt;host_id& gt;를 이전 단계의 호스트 ID로 바꿉니다.
  10. 다음 명령을 실행하여 호스트를 설치할 준비가 되었는지 확인합니다.

    참고

    전체 jq 표현식을 포함하여 전체 명령을 복사해야 합니다.

    $ curl -s $API_URL/api/assisted-install/v2/clusters/$CLUSTER_ID -H "Authorization: Bearer ${API_TOKEN}" | jq '
    def host_name($host):
        if (.suggested_hostname // "") == "" then
            if (.inventory // "") == "" then
                "Unknown hostname, please wait"
            else
                .inventory | fromjson | .hostname
            end
        else
            .suggested_hostname
        end;
    
    def is_notable($validation):
        ["failure", "pending", "error"] | any(. == $validation.status);
    
    def notable_validations($validations_info):
        [
            $validations_info // "{}"
            | fromjson
            | to_entries[].value[]
            | select(is_notable(.))
        ];
    
    {
        "Hosts validations": {
            "Hosts": [
                .hosts[]
                | select(.status != "installed")
                | {
                    "id": .id,
                    "name": host_name(.),
                    "status": .status,
                    "notable_validations": notable_validations(.validations_info)
                }
            ]
        },
        "Cluster validations info": {
            "notable_validations": notable_validations(.validations_info)
        }
    }
    ' -r

    출력 예

    {
      "Hosts validations": {
        "Hosts": [
          {
            "id": "97ec378c-3568-460c-bc22-df54534ff08f",
            "name": "localhost.localdomain",
            "status": "insufficient",
            "notable_validations": [
              {
                "id": "ntp-synced",
                "status": "failure",
                "message": "Host couldn't synchronize with any NTP server"
              },
              {
                "id": "api-domain-name-resolved-correctly",
                "status": "error",
                "message": "Parse error for domain name resolutions result"
              },
              {
                "id": "api-int-domain-name-resolved-correctly",
                "status": "error",
                "message": "Parse error for domain name resolutions result"
              },
              {
                "id": "apps-domain-name-resolved-correctly",
                "status": "error",
                "message": "Parse error for domain name resolutions result"
              }
            ]
          }
        ]
      },
      "Cluster validations info": {
        "notable_validations": []
      }
    }

  11. 이전 명령에서 호스트가 준비되었다고 표시되면 다음 명령을 실행하여 /v2/infra-envs/{infra_env_id}/hosts/{host_id}/actions/install API를 사용하여 설치를 시작합니다.

    $ curl -X POST -s "$API_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts/$HOST_ID/actions/install"  -H "Authorization: Bearer ${API_TOKEN}"
  12. 설치가 진행되면 설치에 호스트에 대한 보류 중인 인증서 서명 요청(CSR)이 생성됩니다.

    중요

    설치를 완료하려면 CSR을 승인해야 합니다.

    다음 API 호출을 실행하여 클러스터 설치를 모니터링합니다.

    $ curl -s "$API_URL/api/assisted-install/v2/clusters/$CLUSTER_ID" -H "Authorization: Bearer ${API_TOKEN}" | jq '{
        "Cluster day-2 hosts":
            [
                .hosts[]
                | select(.status != "installed")
                | {id, requested_hostname, status, status_info, progress, status_updated_at, updated_at, infra_env_id, cluster_id, created_at}
            ]
    }'

    출력 예

    {
      "Cluster day-2 hosts": [
        {
          "id": "a1c52dde-3432-4f59-b2ae-0a530c851480",
          "requested_hostname": "control-plane-1",
          "status": "added-to-existing-cluster",
          "status_info": "Host has rebooted and no further updates will be posted. Please check console for progress and to possibly approve pending CSRs",
          "progress": {
            "current_stage": "Done",
            "installation_percentage": 100,
            "stage_started_at": "2022-07-08T10:56:20.476Z",
            "stage_updated_at": "2022-07-08T10:56:20.476Z"
          },
          "status_updated_at": "2022-07-08T10:56:20.476Z",
          "updated_at": "2022-07-08T10:57:15.306369Z",
          "infra_env_id": "b74ec0c3-d5b5-4717-a866-5b6854791bd3",
          "cluster_id": "8f721322-419d-4eed-aa5b-61b50ea586ae",
          "created_at": "2022-07-06T22:54:57.161614Z"
        }
      ]
    }

  13. 선택 사항: 다음 명령을 실행하여 클러스터의 모든 이벤트를 확인합니다.

    $ curl -s "$API_URL/api/assisted-install/v2/events?cluster_id=$CLUSTER_ID" -H "Authorization: Bearer ${API_TOKEN}" | jq -c '.[] | {severity, message, event_time, host_id}'

    출력 예

    {"severity":"info","message":"Host compute-0: updated status from insufficient to known (Host is ready to be installed)","event_time":"2022-07-08T11:21:46.346Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host compute-0: updated status from known to installing (Installation is in progress)","event_time":"2022-07-08T11:28:28.647Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host compute-0: updated status from installing to installing-in-progress (Starting installation)","event_time":"2022-07-08T11:28:52.068Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Uploaded logs for host compute-0 cluster 8f721322-419d-4eed-aa5b-61b50ea586ae","event_time":"2022-07-08T11:29:47.802Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host compute-0: updated status from installing-in-progress to added-to-existing-cluster (Host has rebooted and no further updates will be posted. Please check console for progress and to possibly approve pending CSRs)","event_time":"2022-07-08T11:29:48.259Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host: compute-0, reached installation stage Rebooting","event_time":"2022-07-08T11:29:48.261Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}

  14. 클러스터에 로그인하고 보류 중인 CSR을 승인하여 설치를 완료합니다.

검증

  • 새 호스트가 Ready: 상태의 클러스터에 성공적으로 추가되었는지 확인합니다.

    $ oc get nodes

    출력 예

    NAME                           STATUS   ROLES           AGE   VERSION
    control-plane-1.example.com    Ready    master,worker   56m   v1.25.0
    compute-1.example.com          Ready    worker          11m   v1.25.0

12.5. 정상 클러스터에 기본 컨트롤 플레인 노드 설치

다음 절차에서는 정상적인 OpenShift Container Platform 클러스터에 기본 컨트롤 플레인 노드를 설치하는 방법을 설명합니다.

클러스터가 비정상이면 추가 작업을 관리해야 관리할 수 있습니다. 자세한 내용은 비정상 클러스터에 기본 컨트롤 플레인 노드 설치를 참조하십시오.

사전 요구 사항

  • 올바른 etcd-operator 버전으로 OpenShift Container Platform 4.11 이상을 사용하고 있습니다.
  • 최소 3개의 노드가 있는 정상 클러스터가 설치되어 있습니다.
  • 단일 노드에 role: master할당되어 있습니다.

절차

  1. CSR 검토 및 승인

    1. CSR( CertificateSigningRequests )을 검토합니다.

      $ oc get csr | grep Pending

      출력 예

      csr-5sd59   8m19s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   <none>              Pending
      csr-xzqts   10s     kubernetes.io/kubelet-serving                 system:node:worker-6                                                   <none>              Pending

    2. 보류 중인 모든 CSR을 승인합니다.

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
      중요

      설치를 완료하려면 CSR을 승인해야 합니다.

  2. 기본 노드가 Ready 상태에 있는지 확인합니다.

    $ oc get nodes

    출력 예

    NAME       STATUS   ROLES    AGE     VERSION
    master-0   Ready    master   4h42m   v1.24.0+3882f8f
    worker-1   Ready    worker   4h29m   v1.24.0+3882f8f
    master-2   Ready    master   4h43m   v1.24.0+3882f8f
    master-3   Ready    master   4h27m   v1.24.0+3882f8f
    worker-4   Ready    worker   4h30m   v1.24.0+3882f8f
    master-5   Ready    master   105s    v1.24.0+3882f8f

    참고

    etcd-operator 에는 클러스터가 기능적인 Machine API로 실행될 때 새 노드를 참조하는 Machine Custom Resource(CR)가 필요합니다.

  3. Machine CR을 BareMetalHostNode:에 연결합니다.

    1. 고유한 .metadata.name 값을 사용하여 BareMetalHost CR을 생성합니다.

      apiVersion: metal3.io/v1alpha1
      kind: BareMetalHost
      metadata:
        name: custom-master3
        namespace: openshift-machine-api
        annotations:
      spec:
        automatedCleaningMode: metadata
        bootMACAddress: 00:00:00:00:00:02
        bootMode: UEFI
        customDeploy:
          method: install_coreos
        externallyProvisioned: true
        online: true
        userData:
          name: master-user-data-managed
          namespace: openshift-machine-api
      $ oc create -f <filename>
    2. BareMetalHost CR을 적용합니다.

      $ oc apply -f <filename>
    3. 고유한 .machine.name 값을 사용하여 Machine CR을 생성합니다.

      apiVersion: machine.openshift.io/v1beta1
      kind: Machine
      metadata:
        annotations:
          machine.openshift.io/instance-state: externally provisioned
          metal3.io/BareMetalHost: openshift-machine-api/custom-master3
        finalizers:
        - machine.machine.openshift.io
        generation: 3
        labels:
          machine.openshift.io/cluster-api-cluster: test-day2-1-6qv96
          machine.openshift.io/cluster-api-machine-role: master
          machine.openshift.io/cluster-api-machine-type: master
        name: custom-master3
        namespace: openshift-machine-api
      spec:
        metadata: {}
        providerSpec:
          value:
            apiVersion: baremetal.cluster.k8s.io/v1alpha1
            customDeploy:
              method: install_coreos
            hostSelector: {}
            image:
              checksum: ""
              url: ""
            kind: BareMetalMachineProviderSpec
            metadata:
              creationTimestamp: null
            userData:
              name: master-user-data-managed
      $ oc create -f <filename>
    4. Machine CR을 적용합니다.

      $ oc apply -f <filename>
    5. link-machine-and-node.sh 스크립트를 사용하여 BareMetalHost,Machine, Node 를 연결합니다.

      #!/bin/bash
      
      # Credit goes to https://bugzilla.redhat.com/show_bug.cgi?id=1801238.
      # This script will link Machine object and Node object. This is needed
      # in order to have IP address of the Node present in the status of the Machine.
      
      set -x
      set -e
      
      machine="$1"
      node="$2"
      
      if [ -z "$machine" -o -z "$node" ]; then
          echo "Usage: $0 MACHINE NODE"
          exit 1
      fi
      
      uid=$(echo $node | cut -f1 -d':')
      node_name=$(echo $node | cut -f2 -d':')
      
      oc proxy &
      proxy_pid=$!
      function kill_proxy {
          kill $proxy_pid
      }
      trap kill_proxy EXIT SIGINT
      
      HOST_PROXY_API_PATH="http://localhost:8001/apis/metal3.io/v1alpha1/namespaces/openshift-machine-api/baremetalhosts"
      
      function wait_for_json() {
          local name
          local url
          local curl_opts
          local timeout
      
          local start_time
          local curr_time
          local time_diff
      
          name="$1"
          url="$2"
          timeout="$3"
          shift 3
          curl_opts="$@"
          echo -n "Waiting for $name to respond"
          start_time=$(date +%s)
          until curl -g -X GET "$url" "${curl_opts[@]}" 2> /dev/null | jq '.' 2> /dev/null > /dev/null; do
              echo -n "."
              curr_time=$(date +%s)
              time_diff=$(($curr_time - $start_time))
              if [[ $time_diff -gt $timeout ]]; then
                  echo "\nTimed out waiting for $name"
                  return 1
              fi
              sleep 5
          done
          echo " Success!"
          return 0
      }
      wait_for_json oc_proxy "${HOST_PROXY_API_PATH}" 10 -H "Accept: application/json" -H "Content-Type: application/json"
      
      addresses=$(oc get node -n openshift-machine-api ${node_name} -o json | jq -c '.status.addresses')
      
      machine_data=$(oc get machine -n openshift-machine-api -o json ${machine})
      host=$(echo "$machine_data" | jq '.metadata.annotations["metal3.io/BareMetalHost"]' | cut -f2 -d/ | sed 's/"//g')
      
      if [ -z "$host" ]; then
          echo "Machine $machine is not linked to a host yet." 1>&2
          exit 1
      fi
      
      # The address structure on the host doesn't match the node, so extract
      # the values we want into separate variables so we can build the patch
      # we need.
      hostname=$(echo "${addresses}" | jq '.[] | select(. | .type == "Hostname") | .address' | sed 's/"//g')
      ipaddr=$(echo "${addresses}" | jq '.[] | select(. | .type == "InternalIP") | .address' | sed 's/"//g')
      
      host_patch='
      {
        "status": {
          "hardware": {
            "hostname": "'${hostname}'",
            "nics": [
              {
                "ip": "'${ipaddr}'",
                "mac": "00:00:00:00:00:00",
                "model": "unknown",
                "speedGbps": 10,
                "vlanId": 0,
                "pxe": true,
                "name": "eth1"
              }
            ],
            "systemVendor": {
              "manufacturer": "Red Hat",
              "productName": "product name",
              "serialNumber": ""
            },
            "firmware": {
              "bios": {
                "date": "04/01/2014",
                "vendor": "SeaBIOS",
                "version": "1.11.0-2.el7"
              }
            },
            "ramMebibytes": 0,
            "storage": [],
            "cpu": {
              "arch": "x86_64",
              "model": "Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz",
              "clockMegahertz": 2199.998,
              "count": 4,
              "flags": []
            }
          }
        }
      }
      '
      
      echo "PATCHING HOST"
      echo "${host_patch}" | jq .
      
      curl -s \
           -X PATCH \
           ${HOST_PROXY_API_PATH}/${host}/status \
           -H "Content-type: application/merge-patch+json" \
           -d "${host_patch}"
      
      oc get baremetalhost -n openshift-machine-api -o yaml "${host}"
      $ bash link-machine-and-node.sh custom-master3 worker-5
  4. etcd 멤버를 확인합니다.

    $ oc rsh -n openshift-etcd etcd-worker-2
    etcdctl member list -w table

    출력 예

    +--------+---------+--------+--------------+--------------+---------+
    |   ID   |  STATUS |  NAME  |  PEER ADDRS  | CLIENT ADDRS | LEARNER |
    +--------+---------+--------+--------------+--------------+---------+
    |2c18942f| started |worker-3|192.168.111.26|192.168.111.26|  false  |
    |61e2a860| started |worker-2|192.168.111.25|192.168.111.25|  false  |
    |ead4f280| started |worker-5|192.168.111.28|192.168.111.28|  false  |
    +--------+---------+--------+--------------+--------------+---------+

  5. etcd-operator 구성이 모든 노드에 적용되는지 확인합니다.

    $ oc get clusteroperator etcd

    출력 예

    NAME   VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    etcd   4.11.5    True        False         False      5h54m

  6. etcd-operator 상태를 확인합니다.

    $ oc rsh -n openshift-etcd etcd-worker-0
    etcdctl endpoint health

    출력 예

    192.168.111.26 is healthy: committed proposal: took = 11.297561ms
    192.168.111.25 is healthy: committed proposal: took = 13.892416ms
    192.168.111.28 is healthy: committed proposal: took = 11.870755ms

  7. 노드 상태를 확인합니다.

    $ oc get Nodes

    출력 예

    NAME       STATUS   ROLES    AGE     VERSION
    master-0   Ready    master   6h20m   v1.24.0+3882f8f
    worker-1   Ready    worker   6h7m    v1.24.0+3882f8f
    master-2   Ready    master   6h20m   v1.24.0+3882f8f
    master-3   Ready    master   6h4m    v1.24.0+3882f8f
    worker-4   Ready    worker   6h7m    v1.24.0+3882f8f
    master-5   Ready    master   99m     v1.24.0+3882f8f

  8. ClusterOperators 상태를 확인합니다.

    $ oc get ClusterOperators

    출력 예

    NAME                                      VERSION AVAILABLE PROGRESSING DEGRADED SINCE MSG
    authentication                            4.11.5  True      False       False    5h57m
    baremetal                                 4.11.5  True      False       False    6h19m
    cloud-controller-manager                  4.11.5  True      False       False    6h20m
    cloud-credential                          4.11.5  True      False       False    6h23m
    cluster-autoscaler                        4.11.5  True      False       False    6h18m
    config-operator                           4.11.5  True      False       False    6h19m
    console                                   4.11.5  True      False       False    6h4m
    csi-snapshot-controller                   4.11.5  True      False       False    6h19m
    dns                                       4.11.5  True      False       False    6h18m
    etcd                                      4.11.5  True      False       False    6h17m
    image-registry                            4.11.5  True      False       False    6h7m
    ingress                                   4.11.5  True      False       False    6h6m
    insights                                  4.11.5  True      False       False    6h12m
    kube-apiserver                            4.11.5  True      False       False    6h16m
    kube-controller-manager                   4.11.5  True      False       False    6h16m
    kube-scheduler                            4.11.5  True      False       False    6h16m
    kube-storage-version-migrator             4.11.5  True      False       False    6h19m
    machine-api                               4.11.5  True      False       False    6h15m
    machine-approver                          4.11.5  True      False       False    6h19m
    machine-config                            4.11.5  True      False       False    6h18m
    marketplace                               4.11.5  True      False       False    6h18m
    monitoring                                4.11.5  True      False       False    6h4m
    network                                   4.11.5  True      False       False    6h20m
    node-tuning                               4.11.5  True      False       False    6h18m
    openshift-apiserver                       4.11.5  True      False       False    6h8m
    openshift-controller-manager              4.11.5  True      False       False    6h7m
    openshift-samples                         4.11.5  True      False       False    6h12m
    operator-lifecycle-manager                4.11.5  True      False       False    6h18m
    operator-lifecycle-manager-catalog        4.11.5  True      False       False    6h19m
    operator-lifecycle-manager-pkgsvr         4.11.5  True      False       False    6h12m
    service-ca                                4.11.5  True      False       False    6h19m
    storage                                   4.11.5  True      False       False    6h19m

  9. ClusterVersion 확인 :

    $ oc get ClusterVersion

    출력 예

    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
    version   4.11.5    True        False         5h57m   Cluster version is 4.11.5

  10. 이전 컨트롤 플레인 노드를 제거합니다.

    1. BareMetalHost CR을 삭제합니다.

      $ oc delete bmh -n openshift-machine-api custom-master3
    2. Machine 이 비정상인지 확인합니다.

      $ oc get machine -A

      출력 예

      NAMESPACE              NAME                              PHASE    AGE
      openshift-machine-api  custom-master3                    Running  14h
      openshift-machine-api  test-day2-1-6qv96-master-0        Failed   20h
      openshift-machine-api  test-day2-1-6qv96-master-1        Running  20h
      openshift-machine-api  test-day2-1-6qv96-master-2        Running  20h
      openshift-machine-api  test-day2-1-6qv96-worker-0-8w7vr  Running  19h
      openshift-machine-api  test-day2-1-6qv96-worker-0-rxddj  Running  19h

    3. Machine CR을 삭제합니다.

      $ oc delete machine -n openshift-machine-api   test-day2-1-6qv96-master-0
      machine.machine.openshift.io "test-day2-1-6qv96-master-0" deleted
    4. Node CR 제거를 확인합니다.

      $ oc get nodes

      출력 예

      NAME       STATUS   ROLES    AGE   VERSION
      worker-1   Ready    worker   19h   v1.24.0+3882f8f
      master-2   Ready    master   20h   v1.24.0+3882f8f
      master-3   Ready    master   19h   v1.24.0+3882f8f
      worker-4   Ready    worker   19h   v1.24.0+3882f8f
      master-5   Ready    master   15h   v1.24.0+3882f8f

  11. etcd-operator 로그를 확인하여 etcd 클러스터의 상태를 확인합니다.

    $ oc logs -n openshift-etcd-operator etcd-operator-8668df65d-lvpjf

    출력 예

    E0927 07:53:10.597523       1 base_controller.go:272] ClusterMemberRemovalController reconciliation failed: cannot remove member: 192.168.111.23 because it is reported as healthy but it doesn't have a machine nor a node resource

  12. etcd-operator 가 클러스터 멤버를 조정할 수 있도록 물리적 머신을 제거합니다.

    $ oc rsh -n openshift-etcd etcd-worker-2
    etcdctl member list -w table; etcdctl endpoint health

    출력 예

    +--------+---------+--------+--------------+--------------+---------+
    |   ID   |  STATUS |  NAME  |  PEER ADDRS  | CLIENT ADDRS | LEARNER |
    +--------+---------+--------+--------------+--------------+---------+
    |2c18942f| started |worker-3|192.168.111.26|192.168.111.26|  false  |
    |61e2a860| started |worker-2|192.168.111.25|192.168.111.25|  false  |
    |ead4f280| started |worker-5|192.168.111.28|192.168.111.28|  false  |
    +--------+---------+--------+--------------+--------------+---------+
    192.168.111.26 is healthy: committed proposal: took = 10.458132ms
    192.168.111.25 is healthy: committed proposal: took = 11.047349ms
    192.168.111.28 is healthy: committed proposal: took = 11.414402ms

12.6. 비정상 클러스터에 기본 컨트롤 플레인 노드 설치

다음 절차에서는 비정상 OpenShift Container Platform 클러스터에 기본 컨트롤 플레인 노드를 설치하는 방법을 설명합니다.

사전 요구 사항

  • 올바른 etcd-operator 버전으로 OpenShift Container Platform 4.11 이상을 사용하고 있습니다.
  • 최소 두 개의 노드가 있는 정상 클러스터가 설치되어 있습니다.
  • Day 2 컨트롤 플레인을 생성했습니다.
  • 단일 노드에 role: master할당되어 있습니다.

절차

  1. 클러스터의 초기 상태를 확인합니다.

    $ oc get nodes

    출력 예

    NAME       STATUS     ROLES    AGE   VERSION
    worker-1   Ready      worker   20h   v1.24.0+3882f8f
    master-2   NotReady   master   20h   v1.24.0+3882f8f
    master-3   Ready      master   20h   v1.24.0+3882f8f
    worker-4   Ready      worker   20h   v1.24.0+3882f8f
    master-5   Ready      master   15h   v1.24.0+3882f8f

  2. etcd-operator 에서 클러스터를 비정상으로 탐지하는지 확인합니다.

    $ oc logs -n openshift-etcd-operator etcd-operator-8668df65d-lvpjf

    출력 예

    E0927 08:24:23.983733       1 base_controller.go:272] DefragController reconciliation failed: cluster is unhealthy: 2 of 3 members are available, worker-2 is unhealthy

  3. etcdctl 멤버를 확인합니다.

    $ oc rsh -n openshift-etcd etcd-worker-3
    etcdctl member list -w table

    출력 예

    +--------+---------+--------+--------------+--------------+---------+
    |   ID   | STATUS  |  NAME  |  PEER ADDRS  | CLIENT ADDRS | LEARNER |
    +--------+---------+--------+--------------+--------------+---------+
    |2c18942f| started |worker-3|192.168.111.26|192.168.111.26|  false  |
    |61e2a860| started |worker-2|192.168.111.25|192.168.111.25|  false  |
    |ead4f280| started |worker-5|192.168.111.28|192.168.111.28|  false  |
    +--------+---------+--------+--------------+--------------+---------+

  4. etcdctl 에서 클러스터의 비정상 멤버를 보고하는지 확인합니다.

    $ etcdctl endpoint health

    출력 예

    {"level":"warn","ts":"2022-09-27T08:25:35.953Z","logger":"client","caller":"v3/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc000680380/192.168.111.25","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = latest balancer error: last connection error: connection error: desc = \"transport: Error while dialing dial tcp 192.168.111.25: connect: no route to host\""}
    192.168.111.28 is healthy: committed proposal: took = 12.465641ms
    192.168.111.26 is healthy: committed proposal: took = 12.297059ms
    192.168.111.25 is unhealthy: failed to commit proposal: context deadline exceeded
    Error: unhealthy cluster

  5. Machine 사용자 정의 리소스를 삭제하여 비정상 컨트롤 플레인을 제거합니다.

    $ oc delete machine -n openshift-machine-api test-day2-1-6qv96-master-2
    참고

    비정상 클러스터를 성공적으로 실행할 수 없는 경우 머신노드 사용자 정의 리소스(CR)는 삭제되지 않습니다.

  6. etcd-operator 가 비정상 머신을 제거하지 않았는지 확인합니다.

    $ oc logs -n openshift-etcd-operator etcd-operator-8668df65d-lvpjf -f

    출력 예

    I0927 08:58:41.249222       1 machinedeletionhooks.go:135] skip removing the deletion hook from machine test-day2-1-6qv96-master-2 since its member is still present with any of: [{InternalIP } {InternalIP 192.168.111.26}]

  7. 비정상적인 etcdctl 멤버를 수동으로 제거하십시오.

    $ oc rsh -n openshift-etcd etcd-worker-3\
    etcdctl member list -w table

    출력 예

    +--------+---------+--------+--------------+--------------+---------+
    |   ID   |  STATUS |  NAME  |  PEER ADDRS  | CLIENT ADDRS | LEARNER |
    +--------+---------+--------+--------------+--------------+---------+
    |2c18942f| started |worker-3|192.168.111.26|192.168.111.26|  false  |
    |61e2a860| started |worker-2|192.168.111.25|192.168.111.25|  false  |
    |ead4f280| started |worker-5|192.168.111.28|192.168.111.28|  false  |
    +--------+---------+--------+--------------+--------------+---------+

  8. etcdctl 에서 클러스터의 비정상 멤버를 보고하는지 확인합니다.

    $ etcdctl endpoint health

    출력 예

    {"level":"warn","ts":"2022-09-27T10:31:07.227Z","logger":"client","caller":"v3/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc0000d6e00/192.168.111.25","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = latest balancer error: last connection error: connection error: desc = \"transport: Error while dialing dial tcp 192.168.111.25: connect: no route to host\""}
    192.168.111.28 is healthy: committed proposal: took = 13.038278ms
    192.168.111.26 is healthy: committed proposal: took = 12.950355ms
    192.168.111.25 is unhealthy: failed to commit proposal: context deadline exceeded
    Error: unhealthy cluster

  9. etcdctl 멤버 사용자 정의 리소스를 삭제하여 비정상 클러스터를 제거합니다.

    $ etcdctl member remove 61e2a86084aafa62

    출력 예

    Member 61e2a86084aafa62 removed from cluster 6881c977b97990d7

  10. 다음 명령을 실행하여 etcdctl 의 멤버를 확인합니다.

    $ etcdctl member list -w table

    출력 예

    +----------+---------+--------+--------------+--------------+-------+
    |    ID    | STATUS  |  NAME  |  PEER ADDRS  | CLIENT ADDRS |LEARNER|
    +----------+---------+--------+--------------+--------------+-------+
    | 2c18942f | started |worker-3|192.168.111.26|192.168.111.26| false |
    | ead4f280 | started |worker-5|192.168.111.28|192.168.111.28| false |
    +----------+---------+--------+--------------+--------------+-------+

  11. 인증서 서명 요청 검토 및 승인

    1. CSR(인증서 서명 요청)을 검토합니다.

      $ oc get csr | grep Pending

      출력 예

      csr-5sd59   8m19s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   <none>              Pending
      csr-xzqts   10s     kubernetes.io/kubelet-serving                 system:node:worker-6                                                   <none>              Pending

    2. 보류 중인 모든 CSR을 승인합니다.

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
      참고

      설치를 완료하려면 CSR을 승인해야 합니다.

  12. 컨트롤 플레인 노드의 준비 상태를 확인합니다.

    $ oc get nodes

    출력 예

    NAME       STATUS   ROLES    AGE     VERSION
    worker-1   Ready    worker   22h     v1.24.0+3882f8f
    master-3   Ready    master   22h     v1.24.0+3882f8f
    worker-4   Ready    worker   22h     v1.24.0+3882f8f
    master-5   Ready    master   17h     v1.24.0+3882f8f
    master-6   Ready    master   2m52s   v1.24.0+3882f8f

  13. 시스템 , 노드 BareMetalHost 사용자 정의 리소스를 검증합니다.

    etcd-operator 를 사용하려면 클러스터가 작동하는 머신 API로 실행되는 경우 Machine CR이 있어야 합니다. 머신 CR은 실행 중 단계에서 표시됩니다.

  14. BareMetalHost노드 와 연결된 머신 사용자 정의 리소스를 생성합니다.

    새로 추가된 노드를 참조하는 머신 CR이 있는지 확인합니다.

    중요

    boot-it-yourself는 BareMetalHostMachine CR을 생성하지 않으므로 생성해야 합니다. BareMetalHostMachine CR을 생성하지 않으면 etcd-operator 를 실행할 때 오류가 생성됩니다.

  15. BareMetalHost 사용자 정의 리소스를 추가합니다.

    $ oc create bmh -n openshift-machine-api custom-master3
  16. 머신 사용자 정의 리소스 추가:

    $ oc create machine -n openshift-machine-api custom-master3
  17. link-machine-and-node.sh 스크립트를 실행하여 BareMetalHost,Machine, Node 를 연결합니다.

    #!/bin/bash
    
    # Credit goes to https://bugzilla.redhat.com/show_bug.cgi?id=1801238.
    # This script will link Machine object and Node object. This is needed
    # in order to have IP address of the Node present in the status of the Machine.
    
    set -x
    set -e
    
    machine="$1"
    node="$2"
    
    if [ -z "$machine" -o -z "$node" ]; then
        echo "Usage: $0 MACHINE NODE"
        exit 1
    fi
    
    uid=$(echo $node | cut -f1 -d':')
    node_name=$(echo $node | cut -f2 -d':')
    
    oc proxy &
    proxy_pid=$!
    function kill_proxy {
        kill $proxy_pid
    }
    trap kill_proxy EXIT SIGINT
    
    HOST_PROXY_API_PATH="http://localhost:8001/apis/metal3.io/v1alpha1/namespaces/openshift-machine-api/baremetalhosts"
    
    function wait_for_json() {
        local name
        local url
        local curl_opts
        local timeout
    
        local start_time
        local curr_time
        local time_diff
    
        name="$1"
        url="$2"
        timeout="$3"
        shift 3
        curl_opts="$@"
        echo -n "Waiting for $name to respond"
        start_time=$(date +%s)
        until curl -g -X GET "$url" "${curl_opts[@]}" 2> /dev/null | jq '.' 2> /dev/null > /dev/null; do
            echo -n "."
            curr_time=$(date +%s)
            time_diff=$(($curr_time - $start_time))
            if [[ $time_diff -gt $timeout ]]; then
                echo "\nTimed out waiting for $name"
                return 1
            fi
            sleep 5
        done
        echo " Success!"
        return 0
    }
    wait_for_json oc_proxy "${HOST_PROXY_API_PATH}" 10 -H "Accept: application/json" -H "Content-Type: application/json"
    
    addresses=$(oc get node -n openshift-machine-api ${node_name} -o json | jq -c '.status.addresses')
    
    machine_data=$(oc get machine -n openshift-machine-api -o json ${machine})
    host=$(echo "$machine_data" | jq '.metadata.annotations["metal3.io/BareMetalHost"]' | cut -f2 -d/ | sed 's/"//g')
    
    if [ -z "$host" ]; then
        echo "Machine $machine is not linked to a host yet." 1>&2
        exit 1
    fi
    
    # The address structure on the host doesn't match the node, so extract
    # the values we want into separate variables so we can build the patch
    # we need.
    hostname=$(echo "${addresses}" | jq '.[] | select(. | .type == "Hostname") | .address' | sed 's/"//g')
    ipaddr=$(echo "${addresses}" | jq '.[] | select(. | .type == "InternalIP") | .address' | sed 's/"//g')
    
    host_patch='
    {
      "status": {
        "hardware": {
          "hostname": "'${hostname}'",
          "nics": [
            {
              "ip": "'${ipaddr}'",
              "mac": "00:00:00:00:00:00",
              "model": "unknown",
              "speedGbps": 10,
              "vlanId": 0,
              "pxe": true,
              "name": "eth1"
            }
          ],
          "systemVendor": {
            "manufacturer": "Red Hat",
            "productName": "product name",
            "serialNumber": ""
          },
          "firmware": {
            "bios": {
              "date": "04/01/2014",
              "vendor": "SeaBIOS",
              "version": "1.11.0-2.el7"
            }
          },
          "ramMebibytes": 0,
          "storage": [],
          "cpu": {
            "arch": "x86_64",
            "model": "Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz",
            "clockMegahertz": 2199.998,
            "count": 4,
            "flags": []
          }
        }
      }
    }
    '
    
    echo "PATCHING HOST"
    echo "${host_patch}" | jq .
    
    curl -s \
         -X PATCH \
         ${HOST_PROXY_API_PATH}/${host}/status \
         -H "Content-type: application/merge-patch+json" \
         -d "${host_patch}"
    
    oc get baremetalhost -n openshift-machine-api -o yaml "${host}"
    $ bash link-machine-and-node.sh custom-master3 worker-3
  18. 다음 명령을 실행하여 etcdctl 의 멤버를 확인합니다.

    $ oc rsh -n openshift-etcd etcd-worker-3
    etcdctl member list -w table

    출력 예

    +---------+-------+--------+--------------+--------------+-------+
    |   ID    | STATUS|  NAME  |   PEER ADDRS | CLIENT ADDRS |LEARNER|
    +---------+-------+--------+--------------+--------------+-------+
    | 2c18942f|started|worker-3|192.168.111.26|192.168.111.26| false |
    | ead4f280|started|worker-5|192.168.111.28|192.168.111.28| false |
    | 79153c5a|started|worker-6|192.168.111.29|192.168.111.29| false |
    +---------+-------+--------+--------------+--------------+-------+

  19. etcd Operator가 모든 노드를 구성했는지 확인합니다.

    $ oc get clusteroperator etcd

    출력 예

    NAME   VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    etcd   4.11.5    True        False         False      22h

  20. etcdctl 의 상태 확인 :

    $ oc rsh -n openshift-etcd etcd-worker-3
    etcdctl endpoint health

    출력 예

    192.168.111.26 is healthy: committed proposal: took = 9.105375ms
    192.168.111.28 is healthy: committed proposal: took = 9.15205ms
    192.168.111.29 is healthy: committed proposal: took = 10.277577ms

  21. 노드의 상태를 확인합니다.

    $ oc get Nodes

    출력 예

    NAME       STATUS   ROLES    AGE   VERSION
    worker-1   Ready    worker   22h   v1.24.0+3882f8f
    master-3   Ready    master   22h   v1.24.0+3882f8f
    worker-4   Ready    worker   22h   v1.24.0+3882f8f
    master-5   Ready    master   18h   v1.24.0+3882f8f
    master-6   Ready    master   40m   v1.24.0+3882f8f

  22. ClusterOperators 의 상태를 확인합니다.

    $ oc get ClusterOperators

    출력 예

    NAME                               VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                     4.11.5    True        False         False      150m
    baremetal                          4.11.5    True        False         False      22h
    cloud-controller-manager           4.11.5    True        False         False      22h
    cloud-credential                   4.11.5    True        False         False      22h
    cluster-autoscaler                 4.11.5    True        False         False      22h
    config-operator                    4.11.5    True        False         False      22h
    console                            4.11.5    True        False         False      145m
    csi-snapshot-controller            4.11.5    True        False         False      22h
    dns                                4.11.5    True        False         False      22h
    etcd                               4.11.5    True        False         False      22h
    image-registry                     4.11.5    True        False         False      22h
    ingress                            4.11.5    True        False         False      22h
    insights                           4.11.5    True        False         False      22h
    kube-apiserver                     4.11.5    True        False         False      22h
    kube-controller-manager            4.11.5    True        False         False      22h
    kube-scheduler                     4.11.5    True        False         False      22h
    kube-storage-version-migrator      4.11.5    True        False         False      148m
    machine-api                        4.11.5    True        False         False      22h
    machine-approver                   4.11.5    True        False         False      22h
    machine-config                     4.11.5    True        False         False      110m
    marketplace                        4.11.5    True        False         False      22h
    monitoring                         4.11.5    True        False         False      22h
    network                            4.11.5    True        False         False      22h
    node-tuning                        4.11.5    True        False         False      22h
    openshift-apiserver                4.11.5    True        False         False      163m
    openshift-controller-manager       4.11.5    True        False         False      22h
    openshift-samples                  4.11.5    True        False         False      22h
    operator-lifecycle-manager         4.11.5    True        False         False      22h
    operator-lifecycle-manager-catalog 4.11.5    True        False         False      22h
    operator-lifecycle-manager-pkgsvr  4.11.5    True        False         False      22h
    service-ca                         4.11.5    True        False         False      22h
    storage                            4.11.5    True        False         False      22h

  23. ClusterVersion 확인 :

    $ oc get ClusterVersion

    출력 예

    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
    version   4.11.5    True        False         22h     Cluster version is 4.11.5

12.7. 추가 리소스

13장. 선택 사항: Nutanix에 설치

Nutanix에 OpenShift Container Platform을 설치하는 경우 지원 설치 관리자는 OpenShift Container Platform 클러스터를 Nutanix에 노출하고 Nutanix 컨테이너 인터페이스 (CSI)를 사용하여 자동 스케일링 및 동적으로 스토리지 컨테이너를 프로비저닝하는 Nutanix 플랫폼과 통합할 수 있습니다.

13.1. UI를 사용하여 Nutanix에 호스트 추가

UI(사용자 인터페이스)를 사용하여 Nutanix에 호스트를 추가하려면 지원 설치 관리자에서 검색 이미지 ISO를 생성합니다. 최소 검색 이미지 ISO를 사용합니다. 이 설정은 기본 설정입니다. 이미지에는 네트워킹으로 호스트를 부팅하는 데 필요한 항목만 포함됩니다. 대부분의 콘텐츠는 부팅 시 다운로드됩니다. ISO 이미지의 크기는 약 100MB입니다.

이 작업이 완료되면 Nutanix 플랫폼에 대한 이미지를 생성하고 Nutanix 가상 머신을 생성해야 합니다.

사전 요구 사항

  • 지원 설치 관리자 UI에 클러스터 프로필을 생성했습니다.
  • Nutanix 클러스터 환경을 설정하고 클러스터 이름과 서브넷 이름을 적어 둡니다.

절차

  1. 호스트 검색에서 호스트 추가 버튼을 클릭하고 설치 미디어를 선택합니다.
  2. Minimal image file: Provision with virtual media 를 선택하여 부팅에 필요한 데이터를 가져올 작은 이미지를 다운로드합니다.
  3. 선택 사항: core 사용자로 Nutanix VM에 연결할 수 있도록 SSH 공개 키를 추가합니다. 클러스터 호스트에 로그인하면 설치 중에 디버깅 정보를 제공할 수 있습니다.

    1. 로컬 시스템에 기존 SSH 키 쌍이 없는 경우 클러스터 노드 SSH 액세스에 대한 키 쌍 생성 단계를 따르십시오.
    2. SSH 공개 키 필드에서 찾아보기 를 클릭하여 SSH 공개 키가 포함된 id_rsa.pub 파일을 업로드합니다. 또는 파일을 파일 관리자의 필드로 끌어다 놓습니다. 파일 관리자에서 파일을 보려면 메뉴에서 숨겨진 파일 표시를 선택합니다.
  4. 선택 사항: 클러스터 호스트가 프록시를 사용해야 하는 방화벽 뒤에 있는 경우 클러스터 전체 프록시 설정 구성을 선택합니다. 프록시 서버의 HTTP 및 HTTPS URL에 대한 사용자 이름, 암호, IP 주소 및 포트를 입력합니다.
  5. 선택 사항: Ignition 파일로 부팅하려면 검색 이미지를 구성합니다. 자세한 내용은 검색 이미지 구성을 참조하십시오.
  6. Discovery ISO 생성을 클릭합니다.
  7. Discovery ISO URL 을 복사합니다.
  8. Nutanix Prism UI에서 지침에 따라 지원 설치 관리자에서 검색 이미지를 업로드합니다.
  9. Nutanix Prism UI에서 Prism Central을 통해 컨트롤 플레인 (마스터) VM을 생성합니다.

    1. 이름을 입력합니다. 예를 들면 control-plane 또는 master 입니다.
    2. VM 수를 입력합니다. 컨트롤 플레인에는 3이어야 합니다.
    3. 나머지 설정이 컨트롤 플레인 호스트의 최소 요구 사항을 충족하는지 확인합니다.
  10. Nutanix Prism UI에서 Prism Central을 통해 작업자 VM을 생성합니다.

    1. 이름을 입력합니다. 예를 들면 worker 입니다.
    2. VM 수를 입력합니다. 작업자 노드가 2개 이상 생성해야 합니다.
    3. 나머지 설정이 작업자 호스트의 최소 요구 사항을 충족하는지 확인합니다.
  11. 지원 설치 관리자 사용자 인터페이스로 돌아가서 지원 설치 프로그램이 호스트를 검색하고 각각 Ready 상태가 될 때까지 기다립니다.
  12. Nutanix 와의 통합을 활성화하려면 가상화 플랫폼과 통합하십시오.
  13. 설치 절차를 계속합니다.

13.2. API를 사용하여 Nutanix에 호스트 추가

API를 사용하여 Nutanix에 호스트를 추가하려면 지원 설치 관리자에서 검색 이미지 ISO를 생성합니다. 최소 검색 이미지 ISO를 사용합니다. 이 설정은 기본 설정입니다. 이미지에는 네트워킹으로 호스트를 부팅하는 데 필요한 항목만 포함됩니다. 대부분의 콘텐츠는 부팅 시 다운로드됩니다. ISO 이미지의 크기는 약 100MB입니다.

이 작업이 완료되면 Nutanix 플랫폼에 대한 이미지를 생성하고 Nutanix 가상 머신을 생성해야 합니다.

사전 요구 사항

  • 지원 설치 관리자 API 인증을 설정했습니다.
  • 지원 설치 관리자 클러스터 프로필이 생성되어 있습니다.
  • 지원 설치 관리자 인프라 환경이 생성되어 있습니다.
  • 쉘에서 $INFRA_ENV_ID 로 내보낸 인프라 환경 ID가 있어야 합니다.
  • 지원 설치 관리자 클러스터 구성을 완료했습니다.
  • Nutanix 클러스터 환경을 설정하고 클러스터 이름과 서브넷 이름을 적어 둡니다.

절차

  1. ignition 파일로 부팅하려면 검색 이미지를 구성합니다.
  2. 환경 변수를 저장할 Nutanix 클러스터 구성 파일을 생성합니다.

    $ touch ~/nutanix-cluster-env.sh
    $ chmod +x ~/nutanix-cluster-env.sh

    새 터미널 세션을 시작해야 하는 경우 환경 변수를 쉽게 다시 로드할 수 있습니다. 예를 들면 다음과 같습니다.

    $ source ~/nutanix-cluster-env.sh
  3. 구성 파일의 NTX_CLUSTER_NAME 환경 변수에 Nutanix 클러스터의 이름을 NTX_CLUSTER_NAME 에 할당합니다.

    $ cat << EOF >> ~/nutanix-cluster-env.sh
    export NTX_CLUSTER_NAME=<cluster_name>
    EOF

    & lt;cluster_name >을 Nutanix 클러스터 이름으로 바꿉니다.

  4. 구성 파일의 NTX_SUBNET_NAME 환경 변수에 Nutanix 클러스터의 서브넷 이름을 할당합니다.

    $ cat << EOF >> ~/nutanix-cluster-env.sh
    export NTX_SUBNET_NAME=<subnet_name>
    EOF

    & lt;subnet_name >을 Nutanix 클러스터 서브넷 이름으로 바꿉니다.

  5. API 토큰을 새로 고칩니다.

    $ source refresh-token
  6. 다운로드 URL을 가져옵니다.

    $ curl -H "Authorization: Bearer ${API_TOKEN}" \
    https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/downloads/image-url
  7. Nutanix 이미지 구성 파일을 생성합니다.

    $ cat << EOF > create-image.json
    {
      "spec": {
        "name": "ocp_ai_discovery_image.iso",
        "description": "ocp_ai_discovery_image.iso",
        "resources": {
          "architecture": "X86_64",
          "image_type": "ISO_IMAGE",
          "source_uri": "<image_url>",
          "source_options": {
            "allow_insecure_connection": true
          }
        }
      },
      "metadata": {
        "spec_version": 3,
        "kind": "image"
      }
    }
    EOF

    & lt;image_url& gt;을 이전 단계에서 다운로드한 이미지 URL로 바꿉니다.

  8. Nutanix 이미지를 생성합니다.

    $ curl  -k -u <user>:'<password>' -X 'POST' \
    'https://<domain-or-ip>:<port>/api/nutanix/v3/images \
      -H 'accept: application/json' \
      -H 'Content-Type: application/json' \
      -d @./create-image.json | jq '.metadata.uuid'

    &lt ;user& gt;를 Nutanix 사용자 이름으로 바꿉니다. '<password>' 를 Nutanix 암호로 바꿉니다. & lt;domain-or-ip >를 Nutanix underform의 도메인 이름 또는 IP 주소로 바꿉니다. & lt;port& gt;를 Nutanix 서버의 포트로 바꿉니다. 포트 기본값은 9440 입니다.

  9. 반환된 UUID를 구성 파일의 NTX_IMAGE_UUID 환경 변수에 할당합니다.

    $ cat << EOF >> ~/nutanix-cluster-env.sh
    export NTX_IMAGE_UUID=<uuid>
    EOF
  10. Nutanix 클러스터 UUID를 가져옵니다.

    $ curl -k -u <user>:'<password>' -X 'POST' \
      'https://<domain-or-ip>:<port>/api/nutanix/v3/clusters/list' \
      -H 'accept: application/json' \
      -H 'Content-Type: application/json' \
      -d '{
      "kind": "cluster"
    }'  | jq '.entities[] | select(.spec.name=="<nutanix_cluster_name>") | .metadata.uuid'

    &lt ;user& gt;를 Nutanix 사용자 이름으로 바꿉니다. '<password>' 를 Nutanix 암호로 바꿉니다. & lt;domain-or-ip >를 Nutanix underform의 도메인 이름 또는 IP 주소로 바꿉니다. & lt;port& gt;를 Nutanix 서버의 포트로 바꿉니다. 포트 기본값은 9440 입니다. & lt;nutanix_cluster_name& gt;을 Nutanix 클러스터 이름으로 바꿉니다.

  11. 반환된 Nutanix 클러스터 UUID를 구성 파일의 NTX_CLUSTER_UUID 환경 변수에 할당합니다.

    $ cat << EOF >> ~/nutanix-cluster-env.sh
    export NTX_CLUSTER_UUID=<uuid>
    EOF

    & lt;uuid& gt;를 Nutanix 클러스터의 반환된 UUID로 바꿉니다.

  12. Nutanix 클러스터의 서브넷 UUID를 가져옵니다.

    $ curl -k -u <user>:'<password>' -X 'POST' \
      'https://<domain-or-ip>:<port>/api/nutanix/v3/subnets/list' \
      -H 'accept: application/json' \
      -H 'Content-Type: application/json' \
      -d '{
      "kind": "subnet",
      "filter": "name==<subnet_name>"
    }' | jq '.entities[].metadata.uuid'

    &lt ;user& gt;를 Nutanix 사용자 이름으로 바꿉니다. '<password>' 를 Nutanix 암호로 바꿉니다. & lt;domain-or-ip >를 Nutanix underform의 도메인 이름 또는 IP 주소로 바꿉니다. & lt;port& gt;를 Nutanix 서버의 포트로 바꿉니다. 포트 기본값은 9440 입니다. & lt;subnet_name >을 클러스터 서브넷 이름으로 바꿉니다.

  13. 반환된 Nutanix 서브넷 UUID를 구성 파일의 NTX_CLUSTER_UUID 환경 변수에 할당합니다.

    $ cat << EOF >> ~/nutanix-cluster-env.sh
    export NTX_SUBNET_UUID=<uuid>
    EOF

    & lt;uuid& gt;를 클러스터 서브넷의 반환된 UUID로 바꿉니다.

  14. Nutanix 환경 변수가 설정되어 있는지 확인합니다.

    $ source ~/nutanix-cluster-env.sh
  15. 각 Nutanix 호스트에 대한 VM 구성 파일을 생성합니다. 컨트롤 플레인 (마스터) VM과 두 개 이상의 작업자 VM을 생성합니다. 예를 들면 다음과 같습니다.

    $ touch create-master-0.json
    $ cat << EOF > create-master-0.json
    {
       "spec": {
          "name": "<host_name>",
          "resources": {
             "power_state": "ON",
             "num_vcpus_per_socket": 1,
             "num_sockets": 16,
             "memory_size_mib": 32768,
             "disk_list": [
                {
                   "disk_size_mib": 122880,
                   "device_properties": {
                      "device_type": "DISK"
                   }
                },
                {
                   "device_properties": {
                      "device_type": "CDROM"
                   },
                   "data_source_reference": {
                     "kind": "image",
                     "uuid": "$NTX_IMAGE_UUID"
                  }
                }
             ],
             "nic_list": [
                {
                   "nic_type": "NORMAL_NIC",
                   "is_connected": true,
                   "ip_endpoint_list": [
                      {
                         "ip_type": "DHCP"
                      }
                   ],
                   "subnet_reference": {
                      "kind": "subnet",
                      "name": "$NTX_SUBNET_NAME",
                      "uuid": "$NTX_SUBNET_UUID"
                   }
                }
             ],
             "guest_tools": {
                "nutanix_guest_tools": {
                   "state": "ENABLED",
                   "iso_mount_state": "MOUNTED"
                }
             }
          },
          "cluster_reference": {
             "kind": "cluster",
             "name": "$NTX_CLUSTER_NAME",
             "uuid": "$NTX_CLUSTER_UUID"
          }
       },
       "api_version": "3.1.0",
       "metadata": {
          "kind": "vm"
       }
    }
    EOF

    & lt;host_name >을 호스트 이름으로 바꿉니다.

  16. 각 Nutanix 가상 머신을 부팅합니다.

    $ curl -k -u <user>:'<password>' -X 'POST' \
      'https://<domain-or-ip>:<port>/api/nutanix/v3/vms' \
      -H 'accept: application/json' \
      -H 'Content-Type: application/json' \
      -d @./<vm_config_file_name> | jq '.metadata.uuid'

    &lt ;user& gt;를 Nutanix 사용자 이름으로 바꿉니다. '<password>' 를 Nutanix 암호로 바꿉니다. & lt;domain-or-ip >를 Nutanix underform의 도메인 이름 또는 IP 주소로 바꿉니다. & lt;port& gt;를 Nutanix 서버의 포트로 바꿉니다. 포트 기본값은 9440 입니다. & lt;vm_config_file_name& gt;을 VM 구성 파일의 이름으로 바꿉니다.

  17. 반환된 VM UUID를 구성 파일의 고유한 환경 변수에 할당합니다.

    $ cat << EOF >> ~/nutanix-cluster-env.sh
    export NTX_MASTER_0_UUID=<uuid>
    EOF

    & lt;uuid& gt;를 VM의 반환된 UUID로 바꿉니다.

    참고

    환경 변수에는 각 VM마다 고유한 이름이 있어야 합니다.

  18. 지원 설치 프로그램이 각 VM을 검색하고 검증을 통과할 때까지 기다립니다.

    $ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID"
    --header "Content-Type: application/json"
    -H "Authorization: Bearer $API_TOKEN"
    | jq '.enabled_host_count'
  19. Nutanix와의 통합을 활성화하도록 클러스터 정의를 수정합니다.

    $ curl https://api.openshift.com/api/assisted-install/v2/clusters/${CLUSTER_ID} \
    -X PATCH \
    -H "Authorization: Bearer ${API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d '
    {
        "platform_type":"nutanix"
    }
    ' | jq
  20. 설치 절차를 계속합니다.

13.3. Nutanix 설치 후 구성

아래 단계에 따라 OpenShift Container Platform과 Nutanix 클라우드 공급자의 통합을 완료하고 검증하십시오.

사전 요구 사항

  • 지원 설치 프로그램이 클러스터 설치를 성공적으로 완료했습니다.
  • 클러스터가 console.redhat.com 에 연결되어 있습니다.
  • Red Hat OpenShift Container Platform 명령줄 인터페이스에 액세스할 수 있습니다.

13.3.1. Nutanix 구성 설정 업데이트

지원 설치 관리자를 사용하여 Nutanix 플랫폼에 OpenShift Container Platform을 설치한 후 다음 Nutanix 구성 설정을 수동으로 업데이트해야 합니다.

  • <prismcentral_username& gt; : Nutanix Prism Central 사용자 이름.
  • <prismcentral_password > : Nutanix Prism Central 암호.
  • <prismcentral_address > : Nutanix Prism Central 주소입니다.
  • <prismcentral_port > : Nutanix Prism 중앙 포트입니다.
  • <prismelement_username& gt; : Nutanix Prism Element 사용자 이름.
  • <prismelement_password > : Nutanix Prism Element 암호.
  • <prismelement_address > : Nutanix Prism Element 주소
  • <prismelement_port > : Nutanix Prism Element 포트입니다.
  • <prismelement_clustername& gt; : Nutanix Prism Element 클러스터 이름입니다.
  • <nutanix_storage_container > : Nutanix Prism 스토리지 컨테이너

절차

  1. OpenShift Container Platform 명령줄 인터페이스에서 Nutanix 클러스터 구성 설정을 업데이트합니다.

    $ oc patch infrastructure/cluster --type=merge --patch-file=/dev/stdin <<-EOF
    {
      "spec": {
        "platformSpec": {
          "nutanix": {
            "prismCentral": {
              "address": "<prismcentral_address>",
              "port": <prismcentral_port>
            },
            "prismElements": [
              {
                "endpoint": {
                  "address": "<prismelement_address>",
                  "port": <prismelement_port>
                },
                "name": "<prismelement_clustername>"
              }
            ]
          },
          "type": "Nutanix"
        }
      }
    }
    EOF

    샘플 출력

    infrastructure.config.openshift.io/cluster patched

    자세한 내용은 Nutanix에서 머신 세트 생성 을 참조하십시오.

  2. Nutanix 시크릿을 생성합니다.

    $ cat <<EOF | oc create -f -
    apiVersion: v1
    kind: Secret
    metadata:
       name: nutanix-credentials
       namespace: openshift-machine-api
    type: Opaque
    stringData:
      credentials: |
    [{"type":"basic_auth","data":{"prismCentral":{"username":"${<prismcentral_username>}","password":"${<prismcentral_password>}"},"prismElements":null}}]
    EOF

    샘플 출력

    secret/nutanix-credentials created

  3. OpenShift Container Platform 버전 4.13 이상을 설치할 때 Nutanix 클라우드 공급자 구성을 업데이트합니다.

    1. Nutanix 클라우드 공급자 구성 YAML 파일을 가져옵니다.

      $ oc get cm cloud-provider-config -o yaml -n openshift-config > cloud-provider-config-backup.yaml
    2. 구성 파일의 백업을 생성합니다.

      $ cp cloud-provider-config_backup.yaml cloud-provider-config.yaml
    3. 구성 YAML 파일을 엽니다.

      $ vi cloud-provider-config.yaml
    4. 다음과 같이 구성 YAML 파일을 편집합니다.

      kind: ConfigMap
      apiVersion: v1
      metadata:
        name: cloud-provider-config
        namespace: openshift-config
      data:
        config: |
          {
          	"prismCentral": {
          		"address": "<prismcentral_address>",
          		"port":<prismcentral_port>,
          		"credentialRef": {
          		   "kind": "Secret",
          		   "name": "nutanix-credentials",
          		   "namespace": "openshift-cloud-controller-manager"
          		}
          	},
          	"topologyDiscovery": {
          		"type": "Prism",
          		"topologyCategories": null
          	},
          	"enableCustomLabeling": true
          }
    5. 구성 업데이트를 적용합니다.

      $ oc apply -f cloud-provider-config.yaml

      샘플 출력

      Warning: resource configmaps/cloud-provider-config is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by oc apply. oc apply should only be used on resources created declaratively by either oc create --save-config or oc apply. The missing annotation will be patched automatically.
      
      configmap/cloud-provider-config configured

13.3.2. Nutanix CSI Operator group 생성

Nutanix CSI Operator에 대한 Operator 그룹을 생성합니다.

참고

Operator 그룹 및 관련 개념에 대한 설명은 추가 리소스일반 Operator 프레임워크 약관 을 참조하십시오.

절차

  1. Nutanix CSI Operator 그룹 YAML 파일을 엽니다.

    $ vi openshift-cluster-csi-drivers-operator-group.yaml
  2. 다음과 같이 YAML 파일을 편집합니다.

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      generateName: openshift-cluster-csi-drivers
      namespace: openshift-cluster-csi-drivers
    spec:
      targetNamespaces:
      - openshift-cluster-csi-drivers
      upgradeStrategy: Default
  3. Operator 그룹을 생성합니다.

    $ oc create -f openshift-cluster-csi-drivers-operator-group.yaml

    샘플 출력

    operatorgroup.operators.coreos.com/openshift-cluster-csi-driversjw9cd created

13.3.3. Nutanix CSI Operator 설치

Kubernetes용 Nutanix CSI(Container Storage Interface) Operator는 Nutanix CSI 드라이버를 배포하고 관리합니다.

참고

Red Hat OpenShift Container Platform을 통해 이 단계를 수행하는 방법에 대한 자세한 내용은 추가 리소스에서 Nutanix CSI Operator 문서의 Operator 설치 섹션을 참조하십시오.

절차

  1. Nutanix CSI Operator YAML 파일의 매개변수 값을 가져옵니다.

    1. Nutanix CSI Operator가 있는지 확인합니다.

      $ oc get packagemanifests | grep nutanix

      샘플 출력

      nutanixcsioperator   Certified Operators   129m

    2. Operator의 기본 채널을 BASH 변수에 할당합니다.

      $ DEFAULT_CHANNEL=$(oc get packagemanifests nutanixcsioperator -o jsonpath={.status.defaultChannel})
    3. Operator의 시작 CSV(클러스터 서비스 버전)를 BASH 변수에 할당합니다.

      $ STARTING_CSV=$(oc get packagemanifests nutanixcsioperator -o jsonpath=\{.status.channels[*].currentCSV\})
    4. 서브스크립션의 카탈로그 소스를 BASH 변수에 할당합니다.

      $ CATALOG_SOURCE=$(oc get packagemanifests nutanixcsioperator -o jsonpath=\{.status.catalogSource\})
    5. Nutanix CSI Operator 소스 네임스페이스를 BASH 변수에 할당합니다.

      $ SOURCE_NAMESPACE=$(oc get packagemanifests nutanixcsioperator -o jsonpath=\{.status.catalogSourceNamespace\})
  2. BASH 변수를 사용하여 Nutanix CSI Operator YAML 파일을 생성합니다.

    $ cat << EOF > nutanixcsioperator.yaml
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: nutanixcsioperator
      namespace: openshift-cluster-csi-drivers
    spec:
      channel: $DEFAULT_CHANNEL
      installPlanApproval: Automatic
      name: nutanixcsioperator
      source: $CATALOG_SOURCE
      sourceNamespace: $SOURCE_NAMESPACE
      startingCSV: $STARTING_CSV
    EOF
  3. CSI Nutanix Operator를 생성합니다.

    $ oc apply -f nutanixcsioperator.yaml

    샘플 출력

    subscription.operators.coreos.com/nutanixcsioperator created

  4. Operator 서브스크립션 상태가 AtLatestKnown 으로 변경될 때까지 다음 명령을 실행합니다. 이는 Operator 서브스크립션이 생성되었으며 시간이 걸릴 수 있음을 나타냅니다.

    $ oc get subscription nutanixcsioperator -n openshift-cluster-csi-drivers -o 'jsonpath={..status.state}'

13.3.4. Nutanix CSI 스토리지 드라이버 배포

Kubernetes용 Nutanix CSI(Container Storage Interface) 드라이버는 상태 저장 애플리케이션을 위한 확장 가능하고 영구 스토리지를 제공합니다.

참고

Red Hat OpenShift Container Platform을 통해 이 단계를 수행하는 방법에 대한 자세한 내용은 추가 리소스 Nutanix CSI Operator 문서의 Operator 섹션을 사용하여 CSI 드라이버 설치 섹션을 참조하십시오.

절차

  1. 드라이버를 배포할 NutanixCsiStorage 리소스를 생성합니다.

    $ cat <<EOF | oc create -f -
    apiVersion: crd.nutanix.com/v1alpha1
    kind: NutanixCsiStorage
    metadata:
      name: nutanixcsistorage
      namespace: openshift-cluster-csi-drivers
    spec: {}
    EOF

    샘플 출력

    snutanixcsistorage.crd.nutanix.com/nutanixcsistorage created

  2. CSI 스토리지 드라이버에 대한 Nutanix 시크릿 YAML 파일을 생성합니다.

    $ cat <<EOF | oc create -f -
    apiVersion: v1
    kind: Secret
    metadata:
      name: ntnx-secret
      namespace: openshift-cluster-csi-drivers
    stringData:
      # prism-element-ip:prism-port:admin:password
      key: <prismelement_address:prismelement_port:prismcentral_username:prismcentral_password> 1
    EOF
    참고
    1
    동일한 형식을 유지하면서 이러한 매개변수를 실제 값으로 바꿉니다.

    샘플 출력

    secret/nutanix-secret created

13.3.5. 설치 후 구성 검증

다음 단계를 실행하여 구성을 검증합니다.

절차

  1. 스토리지 클래스를 생성할 수 있는지 확인합니다.

    $ cat <<EOF | oc create -f -
    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
      name: nutanix-volume
      annotations:
        storageclass.kubernetes.io/is-default-class: 'true'
    provisioner: csi.nutanix.com
    parameters:
      csi.storage.k8s.io/fstype: ext4
      csi.storage.k8s.io/provisioner-secret-namespace: openshift-cluster-csi-drivers
      csi.storage.k8s.io/provisioner-secret-name: ntnx-secret
      storageContainer: <nutanix_storage_container> 1
      csi.storage.k8s.io/controller-expand-secret-name: ntnx-secret
      csi.storage.k8s.io/node-publish-secret-namespace: openshift-cluster-csi-drivers
      storageType: NutanixVolumes
      csi.storage.k8s.io/node-publish-secret-name: ntnx-secret
      csi.storage.k8s.io/controller-expand-secret-namespace: openshift-cluster-csi-drivers
    reclaimPolicy: Delete
    allowVolumeExpansion: true
    volumeBindingMode: Immediate
    EOF
    참고
    1
    Nutanix_storage_container>는 Nutanix 구성에서 <nutanix_storage_container>를 사용합니다(예: SelfServiceContainer).

    샘플 출력

    storageclass.storage.k8s.io/nutanix-volume created

  2. Nutanix PVC(영구 볼륨 클레임)를 생성할 수 있는지 확인합니다.

    1. PVC(영구 볼륨 클레임)를 생성합니다.

      $ cat <<EOF | oc create -f -
      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: nutanix-volume-pvc
        namespace: openshift-cluster-csi-drivers
        annotations:
          volume.beta.kubernetes.io/storage-provisioner: csi.nutanix.com
          volume.kubernetes.io/storage-provisioner: csi.nutanix.com
        finalizers:
          - kubernetes.io/pvc-protection
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi
        storageClassName: nutanix-volume
        volumeMode: Filesystem
      EOF

      샘플 출력

      persistentvolumeclaim/nutanix-volume-pvc created

    2. PVC(영구 볼륨 클레임) 상태가 Bound인지 확인합니다.

      $ oc get pvc -n openshift-cluster-csi-drivers

      샘플 출력

      NAME                 STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS     AGE
      nutanix-volume-pvc   Bound                                        nutanix-volume   52s

14장. 선택사항: vSphere에 설치

vSphere에 OpenShift Container Platform을 설치하는 경우 지원 설치 관리자는 OpenShift Container Platform 클러스터를 vSphere에 노출하고 자동 스케일링을 활성화하는 vSphere 플랫폼과 통합할 수 있습니다.

14.1. vSphere에 호스트 추가

온라인 vSphere 클라이언트 또는 govc vSphere CLI 툴을 사용하여 지원 설치 관리자 클러스터에 호스트를 추가할 수 있습니다. 다음 절차에서는 govc CLI 툴을 사용하여 호스트를 추가하는 방법을 보여줍니다. 온라인 vSphere Client를 사용하려면 vSphere 설명서를 참조하십시오.

vSphere govc CLI를 사용하여 vSphere에 호스트를 추가하려면 지원 설치 관리자에서 검색 이미지 ISO를 생성합니다. 최소 검색 이미지 ISO는 기본 설정입니다. 이 이미지에는 네트워킹으로 호스트를 부팅하는 데 필요한 항목만 포함됩니다. 대부분의 콘텐츠는 부팅 시 다운로드됩니다. ISO 이미지의 크기는 약 100MB입니다.

이 작업이 완료되면 vSphere 플랫폼의 이미지를 생성하고 vSphere 가상 머신을 생성해야 합니다.

사전 요구 사항

  • vSphere 7.0.2 이상을 사용하고 있습니다.
  • vSphere govc CLI 툴이 설치되어 구성되어 있습니다.
  • vSphere에서 clusterSet disk.enableUUIDtrue 로 설정해야 합니다.
  • 지원 설치 프로그램 UI에서 클러스터를 생성했거나
  • 다음이 있습니다.

    • API를 사용하여 지원 설치 관리자 클러스터 프로필 및 인프라 환경을 생성했습니다.
    • 쉘의 인프라 환경 ID를 $INFRA_ENV_ID 로 내보냅니다.
    • 설정을 완료합니다.

절차

  1. ignition 파일로 부팅하려면 검색 이미지를 구성합니다.
  2. 지원 설치 관리자 UI에서 ISO를 생성하고 다운로드합니다.

    1. 호스트 검색에서 호스트 추가 버튼을 클릭하고 설치 미디어를 선택합니다.
    2. Minimal image file: Provision with virtual media 를 선택하여 부팅에 필요한 데이터를 가져올 작은 이미지를 다운로드합니다.
    3. core 사용자로 vSphere VM에 연결할 수 있도록 SSH 공개 키를 추가합니다. 클러스터 호스트에 로그인하면 설치 중에 디버깅 정보를 제공할 수 있습니다.

      1. 로컬 시스템에 기존 SSH 키 쌍이 없는 경우 클러스터 노드 SSH 액세스에 대한 키 쌍 생성 단계를 따르십시오.
      2. SSH 공개 키 필드에서 찾아보기 를 클릭하여 SSH 공개 키가 포함된 id_rsa.pub 파일을 업로드합니다. 또는 파일을 파일 관리자의 필드로 끌어다 놓습니다. 파일 관리자에서 파일을 보려면 메뉴에서 숨겨진 파일 표시를 선택합니다.
    4. 선택 사항: 클러스터 호스트가 프록시를 사용해야 하는 방화벽 뒤에 있는 경우 클러스터 전체 프록시 설정 구성을 선택합니다. 프록시 서버의 HTTP 및 HTTPS URL에 대한 사용자 이름, 암호, IP 주소 및 포트를 입력합니다.
    5. 선택 사항: 클러스터 호스트가 재암호화 MITM(man-in-the-middle) 프록시를 사용하는 네트워크에 있거나 클러스터가 컨테이너 이미지 레지스트리와 같은 다른 용도로 인증서를 신뢰해야 하는 경우 클러스터 전체에서 신뢰할 수 있는 인증서 구성을 선택하고 추가 인증서를 추가해야 합니다.
    6. 선택 사항: Ignition 파일로 부팅하려면 검색 이미지를 구성합니다. 자세한 내용은 검색 이미지 구성을 참조하십시오.
    7. Discovery ISO 생성을 클릭합니다.
    8. Discovery ISO URL 을 복사합니다.
    9. 검색 ISO를 다운로드합니다.

      $ wget - O vsphere-discovery-image.iso <discovery_url>

      & lt;discovery_url& gt;을 이전 단계의 URL로 바꿉니다.

  3. 명령줄에서 기존 가상 머신의 전원을 끄고 삭제합니다.

    $ for VM in $(/usr/local/bin/govc ls /<datacenter>/vm/<folder_name>)
    do
     	/usr/local/bin/govc vm.power -off $VM
     	/usr/local/bin/govc vm.destroy $VM
    done

    & lt;datacenter& gt;를 데이터 센터 이름으로 바꿉니다. & lt;folder_name >을 VM 인벤토리 폴더의 이름으로 바꿉니다.

  4. 데이터 저장소에서 기존 ISO 이미지를 제거합니다(있는 경우).

    $ govc datastore.rm -ds <iso_datastore> <image>

    & lt;iso_datastore >를 데이터 저장소 이름으로 교체합니다. 이미지를 ISO 이미지의 이름으로 바꿉니다.

  5. 지원 설치 관리자 검색 ISO를 업로드합니다.

    $ govc datastore.upload -ds <iso_datastore>  vsphere-discovery-image.iso

    & lt;iso_datastore >를 데이터 저장소 이름으로 교체합니다.

    참고

    클러스터의 모든 노드는 검색 이미지에서 부팅해야 합니다.

  6. 컨트롤 플레인 (마스터) 노드 세 개를 부팅합니다.

    $ govc vm.create -net.adapter <network_adapter_type> \
                     -disk.controller <disk_controller_type> \
                     -pool=<resource_pool> \
                     -c=16 \
                     -m=32768 \
                     -disk=120GB \
                     -disk-datastore=<datastore_file> \
                     -net.address="<nic_mac_address>" \
                     -iso-datastore=<iso_datastore> \
                     -iso="vsphere-discovery-image.iso" \
                     -folder="<inventory_folder>" \
                     <hostname>.<cluster_name>.example.com

    자세한 내용은 vm.create 을 참조하십시오.

    참고

    위 예제에서는 컨트롤 플레인 노드에 필요한 최소 리소스를 보여줍니다.

  7. 두 개 이상의 작업자 노드를 부팅합니다.

    $ govc vm.create -net.adapter <network_adapter_type> \
                     -disk.controller <disk_controller_type> \
                     -pool=<resource_pool> \
                     -c=4 \
                     -m=8192 \
                     -disk=120GB \
                     -disk-datastore=<datastore_file> \
                     -net.address="<nic_mac_address>" \
                     -iso-datastore=<iso_datastore> \
                     -iso="vsphere-discovery-image.iso" \
                     -folder="<inventory_folder>" \
                     <hostname>.<cluster_name>.example.com

    자세한 내용은 vm.create 을 참조하십시오.

    참고

    위 예제에서는 작업자 노드에 필요한 최소 리소스를 보여줍니다.

  8. VM이 실행 중인지 확인합니다.

    $  govc ls /<datacenter>/vm/<folder_name>

    & lt;datacenter& gt;를 데이터 센터 이름으로 바꿉니다. & lt;folder_name >을 VM 인벤토리 폴더의 이름으로 바꿉니다.

  9. 2분 후 VM을 종료합니다.

    $ for VM in $(govc ls /<datacenter>/vm/<folder_name>)
    do
         govc vm.power -s=true $VM
    done

    & lt;datacenter& gt;를 데이터 센터 이름으로 바꿉니다. & lt;folder_name >을 VM 인벤토리 폴더의 이름으로 바꿉니다.

  10. disk.enableUUID 설정을 TRUE 로 설정합니다.

    $ for VM in $(govc ls /<datacenter>/vm/<folder_name>)
    do
         govc vm.change -vm $VM -e disk.enableUUID=TRUE
    done

    & lt;datacenter& gt;를 데이터 센터 이름으로 바꿉니다. & lt;folder_name >을 VM 인벤토리 폴더의 이름으로 바꿉니다.

    참고

    vSphere로 자동 스케일링을 활성화하려면 모든 노드에서 disk.enableUUIDTRUE 로 설정해야 합니다.

  11. VM을 재시작합니다.

    $  for VM in $(govc ls /<datacenter>/vm/<folder_name>)
    do
         govc vm.power -on=true $VM
    done

    & lt;datacenter& gt;를 데이터 센터 이름으로 바꿉니다. & lt;folder_name >을 VM 인벤토리 폴더의 이름으로 바꿉니다.

  12. 지원 설치 관리자 사용자 인터페이스로 돌아가서 지원 설치 프로그램이 호스트를 검색하고 각각 Ready 상태가 될 때까지 기다립니다.
  13. vSphere 와의 통합을 활성화하려면 가상화 플랫폼과 통합하십시오.
  14. 필요한 경우 역할을 선택합니다.
  15. Networking 에서 DHCP 서버를 통한 IP 할당을 선택 해제합니다.
  16. API VIP 주소를 설정합니다.
  17. Ingress VIP 주소를 설정합니다.
  18. 설치 절차를 계속합니다.

14.2. CLI를 사용한 vSphere 설치 후 구성

플랫폼 통합 기능이 활성화된 vSphere에서 지원 설치 관리자를 사용하여 OpenShift Container Platform 클러스터를 설치한 후 다음 vSphere 구성 설정을 수동으로 업데이트해야 합니다.

  • vCenter 사용자 이름
  • vCenter 암호
  • vCenter 주소
  • vCenter 클러스터
  • 데이터 센터
  • 데이터 저장소
  • 폴더

사전 요구 사항

  • 지원 설치 프로그램이 클러스터 설치를 성공적으로 완료했습니다.
  • 클러스터가 console.redhat.com 에 연결되어 있습니다.

절차

  1. vCenter에 대한 base64로 인코딩된 사용자 이름 및 암호를 생성합니다.

    $ echo -n "<vcenter_username>" | base64 -w0

    &lt ;vcenter_username&gt;을 vCenter 사용자 이름으로 교체합니다.

    $ echo -n "<vcenter_password>" | base64 -w0

    & lt;vcenter_password&gt;를 vCenter 암호로 교체합니다.

  2. vSphere 인증 정보를 백업합니다.

    $ oc get secret vsphere-creds -o yaml -n kube-system > creds_backup.yaml
  3. vSphere 인증 정보를 편집합니다.

    $ cp creds_backup.yaml vsphere-creds.yaml
    $ vi vsphere-creds.yaml
    apiVersion: v1
    data:
      <vcenter_address>.username: <vcenter_username_encoded>
      <vcenter_address>.password: <vcenter_password_encoded>
    kind: Secret
    metadata:
      annotations:
        cloudcredential.openshift.io/mode: passthrough
      creationTimestamp: "2022-01-25T17:39:50Z"
      name: vsphere-creds
      namespace: kube-system
      resourceVersion: "2437"
      uid: 06971978-e3a5-4741-87f9-2ca3602f2658
    type: Opaque

    & lt;vcenter_address&gt;를 vCenter 주소로 바꿉니다. & lt;vcenter_username_encoded& gt;를 vSphere 사용자 이름의 base64 인코딩 버전으로 바꿉니다. & lt;vcenter_password_encoded >를 vSphere 암호 base64 인코딩 버전으로 바꿉니다.

  4. vSphere 인증 정보를 교체합니다.

    $ oc replace -f vsphere-creds.yaml
  5. kube-controller-manager Pod를 재배포합니다.

    $ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
  6. vSphere 클라우드 공급자 구성을 백업합니다.

    $ oc get cm cloud-provider-config -o yaml -n openshift-config > cloud-provider-config_backup.yaml
  7. 클라우드 공급자 구성을 편집합니다.

    $ cloud-provider-config_backup.yaml cloud-provider-config.yaml
    $ vi cloud-provider-config.yaml
    apiVersion: v1
    data:
      config: |
        [Global]
        secret-name = "vsphere-creds"
        secret-namespace = "kube-system"
        insecure-flag = "1"
    
        [Workspace]
        server = "<vcenter_address>"
        datacenter = "<datacenter>"
        default-datastore = "<datastore>"
        folder = "/<datacenter>/vm/<folder>"
    
        [VirtualCenter "<vcenter_address>"]
        datacenters = "<datacenter>"
    kind: ConfigMap
    metadata:
      creationTimestamp: "2022-01-25T17:40:49Z"
      name: cloud-provider-config
      namespace: openshift-config
      resourceVersion: "2070"
      uid: 80bb8618-bf25-442b-b023-b31311918507

    & lt;vcenter_address&gt;를 vCenter 주소로 바꿉니다. & lt;datacenter >를 데이터 센터 이름으로 교체합니다. & lt;datastore >를 데이터 저장소 이름으로 바꿉니다. & lt;folder& gt;를 클러스터 VM이 포함된 폴더로 바꿉니다.

  8. 클라우드 공급자 구성을 적용합니다.

    $ oc apply -f cloud-provider-config.yaml
  9. 초기화되지 않은 테인트가 있는 노드에 테인트를 적용합니다.

    중요

    OpenShift Container Platform 4.13 이상을 설치하는 경우 9~12단계를 따르십시오.

    1. 테인트할 노드를 식별합니다.

      $ oc get nodes
    2. 각 노드에 대해 다음 명령을 실행합니다.

      $ oc adm taint node <node_name> node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule

      & lt;node_name >을 노드 이름으로 바꿉니다.

    예제

    $ oc get nodes
    NAME                STATUS   ROLES                  AGE   VERSION
    master-0   Ready    control-plane,master   45h   v1.26.3+379cd9f
    master-1   Ready    control-plane,master   45h   v1.26.3+379cd9f
    worker-0   Ready    worker                 45h   v1.26.3+379cd9f
    worker-1   Ready    worker                 45h   v1.26.3+379cd9f
    master-2   Ready    control-plane,master   45h   v1.26.3+379cd9f
    
    $ oc adm taint node master-0 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule
    $ oc adm taint node master-1 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule
    $ oc adm taint node master-2 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule
    $ oc adm taint node worker-0 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule
    $ oc adm taint node worker-1 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule

  10. 인프라 구성을 백업합니다.

    $ oc get infrastructures.config.openshift.io -o yaml > infrastructures.config.openshift.io.yaml.backup
  11. 인프라 구성을 편집합니다.

    $ cp infrastructures.config.openshift.io.yaml.backup infrastructures.config.openshift.io.yaml
    $ vi infrastructures.config.openshift.io.yaml
    apiVersion: v1
    items:
    - apiVersion: config.openshift.io/v1
      kind: Infrastructure
      metadata:
        creationTimestamp: "2023-05-07T10:19:55Z"
        generation: 1
        name: cluster
        resourceVersion: "536"
        uid: e8a5742c-6d15-44e6-8a9e-064b26ab347d
      spec:
        cloudConfig:
          key: config
          name: cloud-provider-config
        platformSpec:
          type: VSphere
          vsphere:
            failureDomains:
            - name: assisted-generated-failure-domain
              region: assisted-generated-region
              server: <vcenter_address>
              topology:
                computeCluster: /<data_center>/host/<vcenter_cluster>
                datacenter: <data_center>
                datastore: /<data_center>/datastore/<datastore>
                folder: "/<data_center>/path/to/folder"
                networks:
                - "VM Network"
                resourcePool: /<data_center>/host/<vcenter_cluster>/Resources
              zone: assisted-generated-zone
            nodeNetworking:
              external: {}
              internal: {}
            vcenters:
            - datacenters:
              - <data_center>
              server: <vcenter_address>
    
    kind: List
    metadata:
      resourceVersion: ""

    & lt;vcenter_address&gt;를 vCenter 주소로 바꿉니다. & lt;datacenter >를 vCenter 데이터 센터의 이름으로 바꿉니다. & lt;datastore& gt;를 vCenter 데이터 저장소의 이름으로 바꿉니다. & lt;folder& gt;를 클러스터 VM이 포함된 폴더로 바꿉니다. & lt;vcenter_cluster& gt;를 OpenShift Container Platform이 설치된 vSphere vCenter 클러스터로 바꿉니다.

  12. 인프라 구성을 적용합니다.

    $ oc apply -f infrastructures.config.openshift.io.yaml --overwrite=true

14.3. UI를 사용한 vSphere 설치 후 구성

플랫폼 통합 기능이 활성화된 vSphere에서 지원 설치 관리자를 사용하여 OpenShift Container Platform 클러스터를 설치한 후 다음 vSphere 구성 설정을 수동으로 업데이트해야 합니다.

  • vCenter 주소
  • vCenter 클러스터
  • vCenter 사용자 이름
  • vCenter 암호
  • 데이터 센터
  • 기본 데이터 저장소
  • 가상 머신 폴더

사전 요구 사항

  • 지원 설치 프로그램이 클러스터 설치를 성공적으로 완료했습니다.
  • 클러스터가 console.redhat.com 에 연결되어 있습니다.

절차

  1. 관리자 관점에서 홈 → 개요 로 이동합니다.
  2. 상태 에서 vSphere 연결을 클릭하여 vSphere 연결 구성 마법사를 엽니다.
  3. vCenter 필드에 vSphere vCenter 서버의 네트워크 주소를 입력합니다. 도메인 이름 또는 IP 주소일 수 있습니다. vSphere 웹 클라이언트 URL(예: https://[your_vCenter_address]/ui )에 나타납니다.
  4. vCenter 클러스터 필드에 OpenShift Container Platform이 설치된 vSphere vCenter 클러스터의 이름을 입력합니다.

    중요

    이 단계는 OpenShift Container Platform 4.13 이상을 설치한 경우 필수입니다.

  5. Username 필드에 vSphere vCenter 사용자 이름을 입력합니다.
  6. 암호 필드에 vSphere vCenter 암호를 입력합니다.

    주의

    시스템은 클러스터의 kube-system 네임스페이스에 vsphere-creds 시크릿에 사용자 이름과 암호를 저장합니다. 잘못된 vCenter 사용자 이름 또는 암호를 사용하면 클러스터 노드를 예약할 수 없습니다.

  7. Datacenter 필드에 클러스터를 호스팅하는 데 사용되는 가상 머신이 포함된 vSphere 데이터 센터의 이름을 입력합니다(예: SDDC-Datacenter ).
  8. Default 데이터 저장소 필드에 영구 데이터 볼륨을 저장하는 vSphere 데이터 저장소를 입력합니다(예: /SDDC-Datacenter/datastore/datastore/datastore ).

    주의

    구성이 저장된 후 vSphere 데이터 센터 또는 기본 데이터 저장소를 업데이트한 후 활성 vSphere PersistentVolumes 를 분리합니다.

  9. 가상 머신 폴더 필드에 클러스터의 가상 머신이 포함된 데이터 센터 폴더(예: /SDDC-Datacenter/vm/ci-ln-hjg4vg2-c61657-t2gzr )를 입력합니다. OpenShift Container Platform 설치가 성공하려면 클러스터를 구성하는 모든 가상 머신이 단일 데이터 센터 폴더에 있어야 합니다.
  10. Save Configuration 을 클릭합니다. 이렇게 하면 openshift-config 네임스페이스에서 cloud-provider-config 파일이 업데이트되고 구성 프로세스가 시작됩니다.
  11. vSphere 연결 구성 마법사를 다시 열고 모니터된 Operator 패널을 확장합니다. Operator의 상태가 Progressing 또는 Healthy 인지 확인합니다.

검증

연결 구성 프로세스는 Operator 상태 및 컨트롤 플레인 노드를 업데이트합니다. 완료하는 데 약 1 시간이 걸립니다. 구성 프로세스 중에 노드가 재부팅됩니다. 이전에는 바인딩된 PersistentVolumeClaims 오브젝트가 연결이 끊어질 수 있었습니다.

다음 단계에 따라 구성 프로세스를 모니터링합니다.

  1. 구성 프로세스가 성공적으로 완료되었는지 확인합니다.

    1. OpenShift Container Platform 관리자 화면에서 홈 → 개요 로 이동합니다.
    2. Status (상태)에서 Operators 를 클릭합니다. 모든 Operator 상태가 Progressing 에서 All succeeded 로 변경될 때까지 기다립니다. 실패 상태는 구성이 실패했음을 나타냅니다.
    3. 상태에서 컨트롤 플레인 을 클릭합니다. 모든 컨트롤 Pane 구성 요소의 응답 속도가 100%로 반환될 때까지 기다립니다. 실패한 컨트롤 플레인 구성 요소는 구성이 실패했음을 나타냅니다.

    오류가 발생하면 연결 설정 중 하나 이상이 올바르지 않음을 나타냅니다. vSphere 연결 구성 마법사에서 설정을 변경하고 구성을 다시 저장합니다.

  2. 다음 단계를 수행하여 PersistentVolumeClaims 오브젝트를 바인딩할 수 있는지 확인합니다.

    1. 다음 YAML을 사용하여 StorageClass 오브젝트를 생성합니다.

      kind: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
       name: vsphere-sc
      provisioner: kubernetes.io/vsphere-volume
      parameters:
       datastore: YOURVCENTERDATASTORE
       diskformat: thin
      reclaimPolicy: Delete
      volumeBindingMode: Immediate
    2. 다음 YAML을 사용하여 PersistentVolumeClaims 오브젝트를 생성합니다.

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
       name: test-pvc
       namespace: openshift-config
       annotations:
         volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume
       finalizers:
         - kubernetes.io/pvc-protection
      spec:
       accessModes:
         - ReadWriteOnce
       resources:
         requests:
          storage: 10Gi
       storageClassName: vsphere-sc
       volumeMode: Filesystem

    자세한 내용은 OpenShift Container Platform 설명서의 동적 프로비저닝 을 참조하십시오. PersistentVolumeClaims 오브젝트의 문제를 해결하려면 OpenShift Container Platform UI의 관리자 화면에서 스토리지PersistentVolumeClaims 로 이동합니다.

15장. 문제 해결

지원 설치 프로그램이 설치를 시작할 수 없거나 클러스터가 제대로 설치되지 않는 경우가 있습니다. 이러한 이벤트에서는 가능한 오류 모드와 오류 문제를 해결하는 방법을 이해하는 것이 도움이 됩니다.

15.1. 사전 요구 사항

  • API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.

15.2. 검색 ISO 문제 해결

지원 설치 관리자는 ISO 이미지를 사용하여 호스트를 클러스터에 등록하고 OpenShift를 설치하기 전에 하드웨어 및 네트워크 검증을 수행하는 에이전트를 실행합니다. 다음 절차에 따라 호스트 검색과 관련된 문제를 해결할 수 있습니다.

검색 ISO 이미지로 호스트를 시작하면 지원 설치 프로그램이 호스트를 검색하여 지원 서비스 UI에 표시합니다.

자세한 내용은 검색 이미지 구성을 참조하십시오.

15.3. 최소 ISO 이미지

가상 미디어 연결을 통한 대역폭이 제한될 때 최소 ISO 이미지를 사용해야 합니다. 여기에는 네트워킹으로 호스트를 부팅하는 데 필요한 항목만 포함됩니다. 대부분의 콘텐츠는 부팅 시 다운로드됩니다. 결과 ISO 이미지는 전체 ISO 이미지의 경우 1GB와 비교하여 약 100MB 크기입니다.

15.3.1. 최소 ISO 부팅 실패 문제 해결

환경에 지원 설치 관리자 서비스에 액세스하기 위해 정적 네트워크 구성이 필요한 경우 해당 구성에 대한 모든 문제가 Minimal ISO가 제대로 부팅되지 않을 수 있습니다. 부팅 화면에 호스트가 루트 파일 시스템 이미지를 다운로드하지 못한 것으로 표시되면 추가 네트워크 구성이 올바른지 확인합니다. 전체 ISO 이미지로 전환하면 더 쉽게 디버깅할 수 있습니다.

rootfs 다운로드 실패의 예

screenshot of failing root file system image download

15.4. 검색 에이전트가 실행 중인지 확인

사전 요구 사항

  • API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.
  • 인프라 환경 검색 ISO로 호스트를 부팅했으며 호스트가 등록하지 못했습니다.
  • 호스트에 대한 ssh 액세스 권한이 있습니다.
  • 암호 없이 시스템에 SSH로 연결할 수 있도록 Discovery ISO를 생성하기 전에 "호스트 추가" 대화 상자에 SSH 공개 키를 제공했습니다.

절차

  1. 호스트 시스템의 전원이 켜져 있는지 확인합니다.
  2. DHCP 네트워킹을 선택한 경우 DHCP 서버가 활성화되어 있는지 확인합니다.
  3. 고정 IP, 브리지 및 본딩 네트워킹을 선택한 경우 구성이 올바른지 확인합니다.
  4. SSH, BMC와 같은 콘솔 또는 가상 머신 콘솔을 사용하여 호스트 머신에 액세스할 수 있는지 확인합니다.

    $ ssh core@<host_ip_address>

    기본 디렉터리에 저장되지 않는 경우 -i 매개변수를 사용하여 개인 키 파일을 지정할 수 있습니다.

    $ ssh -i <ssh_private_key_file> core@<host_ip_address>

    호스트에 ssh를 사용하지 않으면 부팅 중에 호스트가 실패하거나 네트워크를 구성하지 못했습니다.

    로그인 시 다음 메시지가 표시됩니다.

    login 예

    screenshot of assisted iso login message 이 메시지가 표시되지 않으면 호스트가 assisted-installer ISO로 부팅되지 않았음을 의미합니다. 부팅 순서를 올바르게 구성했는지 확인합니다(호스트가 live-ISO에서 한 번 부팅되어야 함).

  5. 에이전트 서비스 로그를 확인합니다.

    $ sudo journalctl -u agent.service

    다음 예에서 오류는 네트워크 문제가 있음을 나타냅니다.

    에이전트 서비스 로그의 에이전트 서비스 로그 스크린샷의 예

    screenshot of agent service log

    에이전트 이미지를 가져오는 데 오류가 발생하면 프록시 설정을 확인합니다. 호스트가 네트워크에 연결되어 있는지 확인합니다. nmcli 를 사용하여 네트워크 구성에 대한 추가 정보를 가져올 수 있습니다.

15.5. 에이전트가 assisted-service에 액세스할 수 있는지 확인

사전 요구 사항

  • API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.
  • 인프라 환경 검색 ISO로 호스트를 부팅했으며 호스트가 등록하지 못했습니다.
  • 검색 에이전트가 실행 중인지 확인했습니다.

절차

  • 에이전트 로그를 확인하여 에이전트가 지원 서비스에 액세스할 수 있는지 확인합니다.

    $ sudo journalctl TAG=agent

    다음 예의 오류는 에이전트가 지원 서비스에 액세스하지 못했음을 나타냅니다.

    에이전트 로그 예

    screenshot of the agent log failing to access the Assisted Service

    클러스터에 대해 구성한 프록시 설정을 확인합니다. 구성된 경우 프록시에서 지원 서비스 URL에 대한 액세스를 허용해야 합니다.

15.6. 호스트의 부팅 순서 수정

Discovery Image의 일부로 실행되는 설치가 완료되면 지원 설치 관리자에서 호스트를 재부팅합니다.  계속 클러스터를 형성하려면 호스트가 설치 디스크에서 부팅되어야 합니다.  호스트의 부팅 순서를 올바르게 구성하지 않은 경우 대신 다른 디스크에서 부팅되어 설치를 중단합니다.

호스트가 검색 이미지를 다시 부팅하면 지원 설치 프로그램이 즉시 이 이벤트를 감지하고 호스트의 상태를 보류 중인 사용자 작업 설치 로 설정합니다.  또는 지원 설치 프로그램이 할당된 시간 내에 호스트가 올바른 디스크를 부팅했는지 감지하지 못하면 이 호스트 상태도 설정됩니다.

절차

  • 호스트를 재부팅하고 설치 디스크에서 부팅하도록 부팅 순서를 설정합니다. 설치 디스크를 선택하지 않은 경우 지원 설치 프로그램이 사용자를 위해 선택한 디스크를 선택했습니다. 선택한 설치 디스크를 보려면 호스트 인벤토리에서 호스트 정보를 확장하고 "설치 디스크" 역할이 있는지 확인합니다.

15.7. 부분적으로 필요한 설치 해결

지원 설치 프로그램이 오류가 발생하더라도 성공적으로 설치를 선언하는 경우가 있습니다.

  • OLM Operator를 설치하도록 요청했는데 설치 실패가 하나 이상 실패한 경우 클러스터 콘솔에 로그인하여 오류를 해결합니다.
  • 두 개 이상의 작업자 노드를 설치하도록 요청했지만 하나 이상의 작업자를 설치에 실패한 경우 두 개 이상의 성공으로 구성된 작업자를 설치된 클러스터에 추가합니다.

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.