OpenShift Container Platform 용 지원되는 설치 관리자 (2024)

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

• 호스팅: 지원 설치 관리자 호스트:

  • Ignition 파일
  • 설치 구성
  • 검색 ISO
  • 설치 프로그램

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

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

• 사전 설치 검증: 지원 설치 관리자는 설치 전에 구성을 검증하여 높은 성공 가능성을 보장합니다. 검증에는 다음이 포함됩니다.

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

• 고가용성 OpenShift Container Platform 또는 SNO(Single Node OpenShift)
• 완전한 플랫폼 통합 또는 통합이 없는 기타 가상화 플랫폼이 있는 베어 메탈 또는 vSphere의 OpenShift Container Platform
• 선택 옵션으로 OpenShift Virtualization 및 OpenShift Data Foundation (이전 OpenShift Container Storage)

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

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

프로세스

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 이상만 지원됩니다.
   • 혼합 아키텍처 클러스터 설치의 경우 OpenShift Container Platform 버전 4.12 이상을 선택하고 -multi 옵션을 사용합니다. 혼합 아키텍처 클러스터 설치에 대한 자세한 내용은 추가 리소스를 참조하십시오.

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

    참고

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

11. 선택 사항: 지원 설치 프로그램에 이미 계정에 연결된 풀 시크릿이 있습니다. 다른 풀 시크릿을 사용하려면 풀 시크릿 편집을 선택합니다.

12. 선택 사항: 타사 플랫폼에 OpenShift Container Platform을 설치하는 경우 외부 파트 플랫폼 목록과 통합 플랫폼을 선택합니다. 유효한 값은 Nutanix,vSphere 또는 Oracle Cloud Infrastructure 입니다. 지원 설치 관리자의 기본값은 플랫폼 통합이 없습니다.

    참고

    각 외부 파트너 통합에 대한 자세한 내용은 추가 리소스 를 참조하십시오.

    중요

    Supported Installer는 OpenShift Container Platform 4.14 이상에서 Oracle Cloud Infrastructure (OCI) 통합을 지원합니다. OpenShift Container Platform 4.14의 경우 OCI 통합은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

    Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 - 지원 범위를 참조하십시오.

13. 선택 사항: 지원 설치 관리자는 기본적으로 x86_64 CPU 아키텍처를 사용합니다. 다른 아키텍처에 OpenShift Container Platform을 설치하는 경우 사용할 해당 아키텍처를 선택합니다. 유효한 값은 arm64,ppc64le 및 s390x 입니다. 일부 기능은 arm64,ppc64le 및 s390x CPU 아키텍처에서는 사용할 수 없습니다.

    중요

    혼합 아키텍처 클러스터 설치의 경우 기본 x86_64 아키텍처를 사용합니다. 혼합 아키텍처 클러스터 설치에 대한 자세한 내용은 추가 리소스를 참조하십시오.

14. 선택 사항: 지원 설치 프로그램은 기본적으로 DHCP 네트워킹으로 설정됩니다. DHCP 예약 대신 클러스터 노드에 고정 IP 구성, 브리지 또는 본딩을 사용하는 경우 고정 IP, 브리지 및 본딩 을 선택합니다.

    참고

    OCI(Oracle Cloud Infrastructure)의 OpenShift Container Platform 설치에는 고정 IP 구성이 지원되지 않습니다.

15. 선택 사항: 설치 디스크의 암호화를 활성화하려면 설치 디스크의 암호화를 활성화하려면 설치 디스크의 암호화를 사용하려면 컨트롤 플레인 노드인 worker를 단일 노드 OpenShift로 선택할 수 있습니다. 다중 노드 클러스터의 경우 컨트롤 플레인 노드를 선택하여 컨트롤 플레인 노드 설치 디스크를 암호화하고 작업자를 선택하여 작업자 노드 설치 디스크를 암호화할 수 있습니다.

추가 리소스

• 선택 사항: Nutanix에 설치
• 선택 사항: vSphere에 설치

프로세스

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 주소 및 인터페이스 이름을 추가합니다.

추가 리소스

• NMState 버전 2.1.4

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

프로세스

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

추가 리소스

• OpenShift Virtualization Operator 설치
• MC(Multicluster Engine) Operator 설치
• OpenShift Data Foundation Operator 설치

프로세스

1. 호스트 추가 버튼을 클릭하고 프로비저닝 유형을 선택합니다.

   1. 최소 이미지 파일: 가상 미디어를 사용하여 프로비저닝 하여 부팅에 필요한 데이터를 가져올 작은 이미지를 다운로드합니다. 노드에는 가상 미디어 기능이 있어야 합니다. 이 방법은 x86_64 및 arm64 아키텍처에 권장되는 방법입니다.
   2. Full image file: Provision with physical media 를 선택하여 더 큰 전체 이미지를 다운로드합니다. 이는 RHEL KVM을 사용하여 설치할 때 ppc64le 아키텍처 및 s390x 아키텍처에 권장되는 방법입니다.

   3. iPXE를 사용하여 호스트를 부팅하려면 네트워크 서버에서 iPXE: Provision 을 선택합니다.

      참고

      • RHEL KVM에 설치하는 경우 경우에 따라 KVM 호스트의 VM이 처음 부팅 시 재부팅되지 않으므로 수동으로 다시 시작해야 합니다.
      • Oracle Cloud Infrastructure에 OpenShift Container Platform을 설치하는 경우 최소 이미지 파일: Provision with virtual media 를 선택합니다.
2. 선택 사항: 클러스터 호스트가 프록시를 사용해야 하는 방화벽 뒤에 있는 경우 클러스터 전체 프록시 설정 구성 을 선택합니다. 프록시 서버의 HTTP 및 HTTPS URL에 대한 사용자 이름, 암호, IP 주소 및 포트를 입력합니다.

3. 선택 사항: core 사용자로 클러스터 노드에 연결할 수 있도록 SSH 공개 키를 추가합니다. 클러스터 노드에 로그인하면 설치 중에 디버깅 정보를 제공할 수 있습니다.

   중요

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

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

추가 리소스

• 추가 세부 정보를 위해 검색 이미지 구성.
• 자세한 내용은 검색 이미지로 호스트 부팅.
• Red Hat Enterprise Linux 9 - 추가 세부 사항을 위해 가상화 구성 및 관리.
• 자세한 내용은 VIOS Media Repository/Virtual Media Library를 구성하는 방법
• UI를 사용하여 Nutanix에 호스트 추가
• vSphere에 호스트 추가

프로세스

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

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

   참고

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

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

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

   참고

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

3. 호스트의 옵션 ( Cryostat) 메뉴에서 필요한 경우 호스트 이벤트 보기를 선택합니다. 목록의 이벤트는 순차적으로 표시됩니다.

4. 멀티 호스트 클러스터의 경우 호스트 이름 옆에 있는 역할 열에서 메뉴를 클릭하여 호스트의 역할을 변경할 수 있습니다.

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

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

프로세스

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

추가 리소스

• 호스트 구성

프로세스

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

   • 클러스터 관리형 네트워킹: 클러스터 관리 네트워킹을 선택하면 지원 관리자가 API 및 Ingress VIP 주소를 관리하기 위한 keepalived 및 VRRP(Virtual Router Redundancy Protocol)를 포함한 표준 네트워크 토폴로지를 구성합니다.

     참고

     • 현재 Cluster-Managed Networking은 IBM zSystems 및 IBM Power in OpenShift Container Platform 버전 4.13에서 지원되지 않습니다.
     • OCI(Oracle Cloud Infrastructure)는 사용자 관리 네트워킹 구성만 있는 OpenShift Container Platform 4.14에서 사용할 수 있습니다.
   • 사용자 관리형 네트워킹: 사용자 관리 네트워킹을 선택하면 비표준 네트워크 토폴로지를 사용하여 OpenShift Container Platform을 배포할 수 있습니다. 예를 들어 keepalived 및 VRRP 대신 외부 로드 밸런서를 사용하여 배포하려는 경우 또는 여러 별도의 L2 네트워크 세그먼트에 클러스터 노드를 배포하려는 경우입니다.

2. 클러스터 관리 네트워킹의 경우 다음 설정을 구성합니다.

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

3. 사용자 관리 네트워킹의 경우 다음 설정을 구성합니다.

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

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

4. 선택 사항: 고급 네트워킹 사용을 선택하여 다음과 같은 고급 네트워킹 속성을 구성합니다.

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

추가 리소스

• 네트워크 구성

추가 리소스

• 사전 설치 검증

프로세스

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

사전 요구 사항

• 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. 설치 후 플랫폼 통합 단계를 완료합니다.

추가 리소스

• Nutanix 설치 후 구성
• vSphere 설치 후 구성

사전 요구 사항

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

프로세스

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

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}"

사전 요구 사항

• (선택 사항) 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)

2. 경로에서 생성하는 방법 중 하나에 스크립트를 생성합니다. 예를 들면 다음과 같습니다.

   $ 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" \)

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

3. 파일 모드를 변경하여 실행 가능하게 만듭니다.

   $ chmod +x ~/.local/bin/refresh-token

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

   $ source refresh-token

5. 다음 명령을 실행하여 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" }}

이전

{"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 형식을 이스케이프합니다.

• name
• openshift-version
• pull_secret
• cpu_architecture

사전 요구 사항

• 유효한 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. 혼합 아키텍처 클러스터의 경우 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_id 를 CLUSTER_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

추가 리소스

• 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

• name
• pull_secret
• cpu_architecture

사전 요구 사항

• 유효한 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>

사전 요구 사항

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

프로세스

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

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

사전 요구 사항

• 클러스터가 생성되어 있습니다.
• 인프라 환경을 생성했습니다.
• 구성을 완료했습니다.
• 클러스터 호스트가 프록시를 사용해야 하는 방화벽 뒤에 있는 경우 프록시 서버의 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. 호스트에 역할을 할당합니다.

추가 리소스

• 검색 이미지 구성
• 검색 이미지를 사용하여 호스트 부팅
• API를 사용하여 Nutanix에 호스트 추가
• vSphere에 호스트 추가
• 호스트에 역할 할당
• iPXE를 사용하여 호스트 부팅

• master: 마스터 역할이 있는 호스트는 컨트롤 플레인 호스트로 작동합니다.
• worker: 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로 바꿉니다.

추가 리소스

• 사전 설치 검증

사전 요구 사항

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

프로세스

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. 설치 후 플랫폼 통합 단계를 완료합니다.

추가 리소스

• Nutanix 설치 후 구성
• vSphere 설치 후 구성

사전 요구 사항

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

프로세스

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

사전 요구 사항

• 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 설정을 tang 로 설정합니다. disk_encyrption.tang_servers 를 설정하여 하나 이상의 Tang 서버에 대한 URL 및 지문 세부 정보를 제공합니다.

      $ 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 입니다. tang_servers 값 내에서 오브젝트 내의 따옴표를 주석 처리합니다.

• 호스트 수정

• 지원 설치 관리자 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가 자동으로 추가되었습니다.

프로세스

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

사전 요구 사항

• 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. 업데이트된 검색 이미지를 다운로드합니다.

프로세스

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 드라이브를 사용하여 클러스터 호스트에 지원 설치 관리자 에이전트를 설치할 수 있습니다.

프로세스

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"]

사전 요구 사항

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

프로세스

1. 네트워크에서 액세스할 수 있는 HTTP 서버에 ISO 파일을 복사합니다.

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

사전 요구 사항

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

프로세스

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

   예제

   #!ipxeinitrd --name initrd http://api.openshift.com/api/assisted-images/images/<infra_env_id>/pxe-initrd?arch=x86_64&image_token=<token_string>&version=4.10kernel 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을 변경합니다. 예를 들면 다음과 같습니다.

   #!ipxeset webserver http://192.168.0.1initrd --name initrd $webserver/initrd.imgkernel $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 ]; thendefault=0fallback=1timeout=1menuentry "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.imgecho "Loading initrd"initrd "/rhcos/initrd.img"}fi

프로세스

1. Host Discovery (호스트 검색) 탭으로 이동하여 Host Inventory (호스트 인벤토리) 테이블까지 아래로 스크롤합니다.

2. 필요한 호스트에 대해 자동 할당 드롭다운 을 선택합니다.

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

• master: 마스터 역할이 있는 호스트는 컨트롤 플레인 호스트로 작동합니다.
• worker: 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로 바꿉니다.

호스트

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

Cluster

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

• IPv4
• IPv6
• Dual-stack (IPv4 + IPv6)

• 베어 메탈 IPI 설명서에서 는 VIP 주소 구문에 대한 추가 설명을 제공합니다.

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

사전 요구 사항

1. API를 사용하여 인프라 환경을 생성했거나 UI를 사용하여 클러스터를 생성했습니다.
2. 쉘에서 인프라 환경 ID를 $INFRA_ENV_ID 로 내보내야 합니다.
3. API에 액세스할 때 사용할 인증 정보가 있으며 쉘에서 $API_TOKEN 으로 토큰을 내보냈습니다.
4. 정적 네트워크 구성을 server-a.yaml 및 server-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---

• UI를 사용하여 정적 네트워크 구성 적용

• OpenShift 네트워킹 이해
• OpenShift SDN - CNI 네트워크 공급자
• OVN-Kubernetes - CNI 네트워크 공급자
• 듀얼 스택 서비스 구성 시나리오
• 베어 메탈 OCP에 설치.
• CNO( Cluster Network Operator) 구성.

• 지원 설치 프로그램 클러스터에 액세스할 수 있어야 합니다.
• OpenShift CLI(oc)를 설치해야 합니다.
• 작업자 노드를 추가하는 클러스터에 필요한 모든 DNS 레코드가 있는지 확인합니다.
• 여러 CPU 아키텍처가 있는 클러스터에 작업자 노드를 추가하는 경우 아키텍처가 multi 로 설정되어 있는지 확인해야 합니다.
• arm 64,IBM Power 또는 IBM zSystems 컴퓨팅 노드를 기존 x86_64 클러스터에 추가하는 경우 혼합 아키텍처를 지원하는 플랫폼을 사용합니다. 자세한 내용은 혼합 아키텍처 클러스터설치를 참조하십시오.

추가 리소스

• 지원 설치 관리자 API로 설치
• 지원 설치 프로그램 UI로 설치
• 지원 설치 프로그램 API를 사용하여 호스트 추가
• 지원 설치 프로그램 UI로 호스트 추가

프로세스

1. CLI를 사용하여 클러스터에 로그인합니다.

2. 아키텍처 설정을 확인합니다.

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

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

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

프로세스

1. OpenShift Cluster Manager 에 로그인하고 확장할 클러스터를 클릭합니다.
2. 호스트 추가를 클릭하고 새 호스트의 검색 ISO를 다운로드하여 SSH 공개 키를 추가하고 필요에 따라 클러스터 전체 프록시 설정을 구성합니다.
3. 선택 사항: 필요에 따라 Ignition 파일을 수정합니다.
4. 검색 ISO를 사용하여 대상 호스트를 부팅하고 콘솔에서 호스트가 검색될 때까지 기다립니다.
5. 호스트 역할을 선택합니다. 작업자 또는 컨트롤 플레인 호스트일 수 있습니다.
6. 설치를 시작합니다.

7. 설치가 진행됨에 따라 설치에 호스트에 대해 보류 중인 인증서 서명 요청(CSR)이 생성됩니다. 메시지가 표시되면 보류 중인 CSR을 승인하여 설치를 완료합니다.

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

사전 요구 사항

• ocm(OpenShift Cluster Manager CLI)을 설치합니다.
• 클러스터 생성 권한이 있는 사용자로 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 의 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 VERSIONcontrol-plane-1.example.com Ready master,worker 56m v1.25.0compute-1.example.com Ready worker 11m v1.25.0

1. 다중 아키텍처 클러스터를 생성하고 등록합니다.
2. x86_64 인프라 환경을 생성하고 x86_64 용 ISO를 다운로드하고 컨트롤 플레인을 추가합니다. 컨트롤 플레인에는 x86_64 아키텍처가 있어야 합니다.
3. arm64,IBM Power 또는 IBM zSystems 인프라 환경을 생성하고 arm64,IBM Power 또는 IBM zSystems 용 ISO를 다운로드하고 작업자 노드를 추가합니다.

지원되는 플랫폼

아래 표에는 각 OpenShift Container Platform 버전에 대해 혼합 아키텍처 클러스터를 지원하는 플랫폼이 나열되어 있습니다. 설치 중인 버전에 적합한 플랫폼을 사용합니다.

주요 단계

1. API를 사용하여 OpenShift Container Platform을 설치하는 절차를 시작합니다. 자세한 내용은 추가 리소스 섹션에서 지원 설치 관리자 API를 사용하여 설치를 참조하십시오.

2. 설치의 "새 클러스터 등록" 단계에 도달하면 클러스터를 다중 아키텍처 클러스터로 등록합니다.

   $ 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": "<version-number>-multi", 1 "cpu_architecture" : "multi" 2 "high_availability_mode": "full" 3 "base_dns_domain": "example.com", "pull_secret": $pull_secret[0] | tojson}')" | jq '.id'

   참고

   1

   OpenShift 버전 번호에 multi- 옵션을 사용합니다(예: "4.12-multi" ).

   2

   CPU 아키텍처의 를 "multi" 로 설정합니다.

   3

   전체 값을 사용하여 Multi-Node OpenShift를 나타냅니다.

3. 설치의 "새 인프라 환경 등록" 단계에 도달하면 cpu_architecture 를 x86_64 로 설정합니다.

   $ 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" : "x86_64" "pull_secret": $pull_secret[0] | tojson }')" | jq '.id'

4. 설치의 "호스트 추가" 단계에 도달하면 host_role 을 master 로 설정합니다.

   참고

   자세한 내용은 추가 리소스 의 호스트에 역할 할당을 참조하십시오.

   $ 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":"master" }' | jq

5. x86_64 아키텍처의 검색 이미지를 다운로드합니다.
6. 생성된 검색 이미지를 사용하여 x86_64 아키텍처 호스트를 부팅합니다.
7. 설치를 시작하고 클러스터가 완전히 설치될 때까지 기다립니다.

8. 설치의 "새 인프라 환경 등록" 단계를 반복합니다. 이번에는 cpu_architecture 를 ppc64le (IBM Power의 경우), s390x (IBM Z용) 또는 arm64 중 하나로 설정합니다. 예를 들면 다음과 같습니다.

   $ 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.12", "cpu_architecture" : "arm64" "high_availability_mode": "full" "base_dns_domain": "example.com", "pull_secret": $pull_secret[0] | tojson}')" | jq '.id'

9. 설치의 "호스트 추가" 단계를 반복합니다. 이번에는 host_role 을 worker 로 설정합니다.

   참고

   자세한 내용은 추가 리소스 의 호스트에 역할 할당을 참조하십시오.

   $ 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

10. arm64,ppc64 le 또는 s390x 아키텍처의 검색 이미지를 다운로드합니다.
11. 생성된 검색 이미지를 사용하여 아키텍처 호스트를 부팅합니다.
12. 설치를 시작하고 클러스터가 완전히 설치될 때까지 기다립니다.

검증

• 다음 명령을 실행하여 클러스터에서 arm64,ppc64le 또는 s390x 작업자 노드를 확인합니다.

  $ oc get nodes -o wide

사전 요구 사항

• 올바른 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> Pendingcsr-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 VERSIONmaster-0 Ready master 4h42m v1.24.0+3882f8fworker-1 Ready worker 4h29m v1.24.0+3882f8fmaster-2 Ready master 4h43m v1.24.0+3882f8fmaster-3 Ready master 4h27m v1.24.0+3882f8fworker-4 Ready worker 4h30m v1.24.0+3882f8fmaster-5 Ready master 105s v1.24.0+3882f8f

   참고

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

3. Machine CR을 BareMetalHost 및 Node:에 연결합니다.

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

      apiVersion: metal3.io/v1alpha1kind: BareMetalHostmetadata: 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/v1beta1kind: Machinemetadata: 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-apispec: 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 -xset -emachine="$1"node="$2"if [ -z "$machine" -o -z "$node" ]; then echo "Usage: $0 MACHINE NODE" exit 1fiuid=$(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 SIGINTHOST_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 1fi# 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-2etcdctl 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 MESSAGEetcd 4.11.5 True False False 5h54m

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

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

   출력 예

   192.168.111.26 is healthy: committed proposal: took = 11.297561ms192.168.111.25 is healthy: committed proposal: took = 13.892416ms192.168.111.28 is healthy: committed proposal: took = 11.870755ms

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

   $ oc get Nodes

   출력 예

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

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

   $ oc get ClusterOperators

   출력 예

   NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MSGauthentication 4.11.5 True False False 5h57mbaremetal 4.11.5 True False False 6h19mcloud-controller-manager 4.11.5 True False False 6h20mcloud-credential 4.11.5 True False False 6h23mcluster-autoscaler 4.11.5 True False False 6h18mconfig-operator 4.11.5 True False False 6h19mconsole 4.11.5 True False False 6h4mcsi-snapshot-controller 4.11.5 True False False 6h19mdns 4.11.5 True False False 6h18metcd 4.11.5 True False False 6h17mimage-registry 4.11.5 True False False 6h7mingress 4.11.5 True False False 6h6minsights 4.11.5 True False False 6h12mkube-apiserver 4.11.5 True False False 6h16mkube-controller-manager 4.11.5 True False False 6h16mkube-scheduler 4.11.5 True False False 6h16mkube-storage-version-migrator 4.11.5 True False False 6h19mmachine-api 4.11.5 True False False 6h15mmachine-approver 4.11.5 True False False 6h19mmachine-config 4.11.5 True False False 6h18mmarketplace 4.11.5 True False False 6h18mmonitoring 4.11.5 True False False 6h4mnetwork 4.11.5 True False False 6h20mnode-tuning 4.11.5 True False False 6h18mopenshift-apiserver 4.11.5 True False False 6h8mopenshift-controller-manager 4.11.5 True False False 6h7mopenshift-samples 4.11.5 True False False 6h12moperator-lifecycle-manager 4.11.5 True False False 6h18moperator-lifecycle-manager-catalog 4.11.5 True False False 6h19moperator-lifecycle-manager-pkgsvr 4.11.5 True False False 6h12mservice-ca 4.11.5 True False False 6h19mstorage 4.11.5 True False False 6h19m

9. ClusterVersion 확인 :

   $ oc get ClusterVersion

   출력 예

   NAME VERSION AVAILABLE PROGRESSING SINCE STATUSversion 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 AGEopenshift-machine-api custom-master3 Running 14hopenshift-machine-api test-day2-1-6qv96-master-0 Failed 20hopenshift-machine-api test-day2-1-6qv96-master-1 Running 20hopenshift-machine-api test-day2-1-6qv96-master-2 Running 20hopenshift-machine-api test-day2-1-6qv96-worker-0-8w7vr Running 19hopenshift-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-0machine.machine.openshift.io "test-day2-1-6qv96-master-0" deleted

    4. Node CR 제거를 확인합니다.

       $ oc get nodes

       출력 예

       NAME STATUS ROLES AGE VERSIONworker-1 Ready worker 19h v1.24.0+3882f8fmaster-2 Ready master 20h v1.24.0+3882f8fmaster-3 Ready master 19h v1.24.0+3882f8fworker-4 Ready worker 19h v1.24.0+3882f8fmaster-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-2etcdctl 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.458132ms192.168.111.25 is healthy: committed proposal: took = 11.047349ms192.168.111.28 is healthy: committed proposal: took = 11.414402ms

추가 리소스

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

사전 요구 사항

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

프로세스

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

   $ oc get nodes

   출력 예

   NAME STATUS ROLES AGE VERSIONworker-1 Ready worker 20h v1.24.0+3882f8fmaster-2 NotReady master 20h v1.24.0+3882f8fmaster-3 Ready master 20h v1.24.0+3882f8fworker-4 Ready worker 20h v1.24.0+3882f8fmaster-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-3etcdctl 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.465641ms192.168.111.26 is healthy: committed proposal: took = 12.297059ms192.168.111.25 is unhealthy: failed to commit proposal: context deadline exceededError: 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.038278ms192.168.111.26 is healthy: committed proposal: took = 12.950355ms192.168.111.25 is unhealthy: failed to commit proposal: context deadline exceededError: 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> Pendingcsr-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 VERSIONworker-1 Ready worker 22h v1.24.0+3882f8fmaster-3 Ready master 22h v1.24.0+3882f8fworker-4 Ready worker 22h v1.24.0+3882f8fmaster-5 Ready master 17h v1.24.0+3882f8fmaster-6 Ready master 2m52s v1.24.0+3882f8f

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

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

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

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

    중요

    boot-it-yourself는 BareMetalHost 및 Machine CR을 생성하지 않으므로 생성해야 합니다. BareMetalHost 및 Machine 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 -xset -emachine="$1"node="$2"if [ -z "$machine" -o -z "$node" ]; then echo "Usage: $0 MACHINE NODE" exit 1fiuid=$(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 SIGINTHOST_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 1fi# 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-3etcdctl 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 SINCEetcd 4.11.5 True False False 22h

20. etcdctl 의 상태 확인 :

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

    출력 예

    192.168.111.26 is healthy: committed proposal: took = 9.105375ms192.168.111.28 is healthy: committed proposal: took = 9.15205ms192.168.111.29 is healthy: committed proposal: took = 10.277577ms

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

    $ oc get Nodes

    출력 예

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

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

    $ oc get ClusterOperators

    출력 예

    NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCEauthentication 4.11.5 True False False 150mbaremetal 4.11.5 True False False 22hcloud-controller-manager 4.11.5 True False False 22hcloud-credential 4.11.5 True False False 22hcluster-autoscaler 4.11.5 True False False 22hconfig-operator 4.11.5 True False False 22hconsole 4.11.5 True False False 145mcsi-snapshot-controller 4.11.5 True False False 22hdns 4.11.5 True False False 22hetcd 4.11.5 True False False 22himage-registry 4.11.5 True False False 22hingress 4.11.5 True False False 22hinsights 4.11.5 True False False 22hkube-apiserver 4.11.5 True False False 22hkube-controller-manager 4.11.5 True False False 22hkube-scheduler 4.11.5 True False False 22hkube-storage-version-migrator 4.11.5 True False False 148mmachine-api 4.11.5 True False False 22hmachine-approver 4.11.5 True False False 22hmachine-config 4.11.5 True False False 110mmarketplace 4.11.5 True False False 22hmonitoring 4.11.5 True False False 22hnetwork 4.11.5 True False False 22hnode-tuning 4.11.5 True False False 22hopenshift-apiserver 4.11.5 True False False 163mopenshift-controller-manager 4.11.5 True False False 22hopenshift-samples 4.11.5 True False False 22hoperator-lifecycle-manager 4.11.5 True False False 22hoperator-lifecycle-manager-catalog 4.11.5 True False False 22hoperator-lifecycle-manager-pkgsvr 4.11.5 True False False 22hservice-ca 4.11.5 True False False 22hstorage 4.11.5 True False False 22h

23. ClusterVersion 확인 :

    $ oc get ClusterVersion

    출력 예

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

• 정상 클러스터에 기본 컨트롤 플레인 노드 설치
• REST API로 인증

사전 요구 사항

• 지원 설치 프로그램 UI에서 클러스터 프로필을 생성했습니다.
• Nutanix 클러스터 환경이 설정되어 클러스터 이름과 서브넷 이름을 기록했습니다.

프로세스

1. 클러스터 세부 정보 의 외부 파트너 플랫폼 드롭다운 목록에서 Integrate를 선택합니다. 사용자 정의 매니페스트 포함 확인란은 선택 사항입니다.
2. 호스트 검색에서 호스트 추가 버튼을 클릭합니다.

3. 선택 사항: core 사용자로 Nutanix VM에 연결할 수 있도록 SSH 공개 키를 추가합니다. 클러스터 호스트에 로그인하면 설치 중에 디버깅 정보를 제공할 수 있습니다.

   1. 로컬 시스템에 기존 SSH 키 쌍이 없는 경우 클러스터 노드 SSH 액세스에 대한 키 쌍 생성 단계를 따르십시오.
   2. SSH 공개 키 필드에서 찾아보기 를 클릭하여 SSH 공개 키가 포함된 id_rsa.pub 파일을 업로드합니다. 또는 파일을 파일 관리자의 필드로 끌어다 놓습니다. 파일 관리자에서 파일을 보려면 메뉴에서 숨겨진 파일 표시를 선택합니다.

4. 원하는 프로비저닝 유형을 선택합니다.

   참고

   최소 이미지 파일: 가상 미디어를 사용하여 프로비저닝 하면 부팅에 필요한 데이터를 가져오는 작은 이미지가 다운로드됩니다.

5. 네트워킹 에서 클러스터 관리 네트워킹 을 선택합니다. Nutanix는 사용자 관리 네트워킹을 지원하지 않습니다.

   1. 선택 사항: 클러스터 호스트가 프록시를 사용해야 하는 방화벽 뒤에 있는 경우 클러스터 전체 프록시 설정 구성 을 선택합니다. 프록시 서버의 HTTP 및 HTTPS URL에 대한 사용자 이름, 암호, IP 주소 및 포트를 입력합니다.
   2. 선택 사항: 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. 설치 절차를 계속합니다.

사전 요구 사항

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

프로세스

1. Ignition 파일로 부팅하려면 검색 이미지를 구성합니다.

2. 환경 변수를 저장할 Nutanix 클러스터 구성 파일을 생성합니다.

   $ touch ~/nutanix-cluster-env.sh

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

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

   $ source ~/nutanix-cluster-env.sh

3. 구성 파일의 Nutanix 클러스터 이름을 NTX_CLUSTER_NAME 환경 변수에 할당합니다.

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

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

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

   $ cat << EOF >> ~/nutanix-cluster-env.shexport 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 plaform의 도메인 이름 또는 IP 주소로 바꿉니다. & lt;port >를 Nutanix 서버의 포트로 바꿉니다. 포트 기본값은 9440 입니다.

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

   $ cat << EOF >> ~/nutanix-cluster-env.shexport 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 plaform의 도메인 이름 또는 IP 주소로 바꿉니다. & lt;port >를 Nutanix 서버의 포트로 바꿉니다. 포트 기본값은 9440 입니다. & lt;nutanix_cluster_name& gt;을 Nutanix 클러스터 이름으로 바꿉니다.

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

    $ cat << EOF >> ~/nutanix-cluster-env.shexport 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 plaform의 도메인 이름 또는 IP 주소로 바꿉니다. & lt;port >를 Nutanix 서버의 포트로 바꿉니다. 포트 기본값은 9440 입니다. & lt;subnet_name >을 클러스터 서브넷 이름으로 바꿉니다.

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

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

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

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

    $ source ~/nutanix-cluster-env.sh

15. 각 Nutanix 호스트에 대한 VM 구성 파일을 생성합니다. 컨트롤 플레인(마스터) VM 3개와 작업자 VM 2개를 생성합니다. 예를 들면 다음과 같습니다.

    $ 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 plaform의 도메인 이름 또는 IP 주소로 바꿉니다. & lt;port >를 Nutanix 서버의 포트로 바꿉니다. 포트 기본값은 9440 입니다. & lt;vm_config_file_name& gt;을 VM 구성 파일의 이름으로 바꿉니다.

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

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

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

    참고

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

18. Assisted Installer가 각 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. 설치 절차를 계속합니다.

사전 요구 사항

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

사전 요구 사항

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

• 다음이 있습니다.

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

프로세스

1. Ignition 파일로 부팅하려면 검색 이미지를 구성합니다.
2. 클러스터 세부 정보 의 외부 파트너 플랫폼 드롭다운 목록에서 vSphere를 선택합니다. 사용자 정의 매니페스트 포함 확인란은 선택 사항입니다.
3. 호스트 검색에서 호스트 추가 버튼을 클릭하고 프로비저닝 유형을 선택합니다.

4. core 사용자로 vSphere VM에 연결할 수 있도록 SSH 공개 키를 추가합니다. 클러스터 호스트에 로그인하면 설치 중에 디버깅 정보를 제공할 수 있습니다.

   1. 로컬 시스템에 기존 SSH 키 쌍이 없는 경우 클러스터 노드 SSH 액세스에 대한 키 쌍 생성 단계를 따르십시오.
   2. SSH 공개 키 필드에서 찾아보기 를 클릭하여 SSH 공개 키가 포함된 id_rsa.pub 파일을 업로드합니다. 또는 파일을 파일 관리자의 필드로 끌어다 놓습니다. 파일 관리자에서 파일을 보려면 메뉴에서 숨겨진 파일 표시를 선택합니다.

5. 원하는 검색 이미지 ISO를 선택합니다.

   참고

   최소 이미지 파일: 가상 미디어를 사용하여 프로비저닝 하면 부팅에 필요한 데이터를 가져오는 작은 이미지가 다운로드됩니다.

6. 네트워킹 에서 클러스터 관리 네트워킹 또는 사용자 관리 네트워킹 을 선택합니다.

   1. 선택 사항: 클러스터 호스트가 프록시를 사용해야 하는 방화벽 뒤에 있는 경우 클러스터 전체 프록시 설정 구성 을 선택합니다. 프록시 서버의 HTTP 및 HTTPS URL에 대한 사용자 이름, 암호, IP 주소 및 포트를 입력합니다.
   2. 선택 사항: 클러스터 호스트가 MITTM(man-in-the-middle) 프록시를 다시 암호화한 네트워크에 있거나 클러스터가 컨테이너 이미지 레지스트리와 같은 다른 용도로 인증서를 신뢰해야 하는 경우 클러스터 전체에서 신뢰할 수 있는 인증서 구성 을 선택하고 추가 인증서를 추가합니다.
   3. 선택 사항: Ignition 파일로 부팅하려면 검색 이미지를 구성합니다. 자세한 내용은 검색 이미지 구성을 참조하십시오.
7. Discovery ISO 생성을 클릭합니다.
8. Discovery ISO URL 을 복사합니다.

9. 검색 ISO를 다운로드합니다.

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

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

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

    $ 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 $VMdone

    & lt;datacenter& gt;를 데이터 센터 이름으로 바꿉니다. & lt;folder_name& gt;을 VM 인벤토리 폴더의 이름으로 바꿉니다.

11. 데이터 저장소가 있는 경우 기존 ISO 이미지를 제거합니다.

    $ govc datastore.rm -ds <iso_datastore> <image>

    & lt;iso_datastore >를 데이터 저장소 이름으로 바꿉니다. 이미지를 ISO 이미지의 이름으로 교체합니다.

12. 지원 설치 관리자 검색 ISO를 업로드합니다.

    $ govc datastore.upload -ds <iso_datastore> vsphere-discovery-image.iso

    & lt;iso_datastore >를 데이터 저장소 이름으로 바꿉니다.

    참고

    클러스터의 모든 노드는 검색 이미지에서 부팅해야 합니다.

13. 세 개의 컨트롤 플레인 (마스터) 노드를 부팅합니다.

    $ 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 을 참조하십시오.

    참고

    위 예제에서는 컨트롤 플레인 노드에 필요한 최소 리소스를 보여줍니다.

14. 두 개 이상의 작업자 노드를 부팅합니다.

    $ 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 을 참조하십시오.

    참고

    위 예제에서는 작업자 노드에 필요한 최소 리소스를 보여줍니다.

15. VM이 실행 중인지 확인합니다.

    $ govc ls /<datacenter>/vm/<folder_name>

    & lt;datacenter& gt;를 데이터 센터 이름으로 바꿉니다. & lt;folder_name& gt;을 VM 인벤토리 폴더의 이름으로 바꿉니다.

16. 2분 후 VM을 종료합니다.

    $ for VM in $(govc ls /<datacenter>/vm/<folder_name>)do govc vm.power -s=true $VMdone

    & lt;datacenter& gt;를 데이터 센터 이름으로 바꿉니다. & lt;folder_name& gt;을 VM 인벤토리 폴더의 이름으로 바꿉니다.

17. disk.enableUUID 설정을 TRUE 로 설정합니다.

    $ for VM in $(govc ls /<datacenter>/vm/<folder_name>)do govc vm.change -vm $VM -e disk.enableUUID=TRUEdone

    & lt;datacenter& gt;를 데이터 센터 이름으로 바꿉니다. & lt;folder_name& gt;을 VM 인벤토리 폴더의 이름으로 바꿉니다.

    참고

    vSphere에서 자동 스케일링을 활성화하려면 모든 노드에서 disk.enableUUID 를 TRUE 로 설정해야 합니다.

18. VM을 다시 시작하십시오.

    $ for VM in $(govc ls /<datacenter>/vm/<folder_name>)do govc vm.power -on=true $VMdone

    & lt;datacenter& gt;를 데이터 센터 이름으로 바꿉니다. & lt;folder_name& gt;을 VM 인벤토리 폴더의 이름으로 바꿉니다.

19. 지원 설치 관리자 인터페이스로 돌아가서 지원 관리자가 호스트를 검색하고 각각에 Ready 상태가 될 때까지 기다립니다.
20. 필요한 경우 역할을 선택합니다.
21. 네트워킹 에서 DHCP 서버를 통해 IP 할당을 선택 해제합니다.
22. API VIP 주소를 설정합니다.
23. Ingress VIP 주소를 설정합니다.
24. 설치 절차를 계속합니다.

• vCenter 사용자 이름
• vCenter 암호
• vCenter 주소
• vCenter 클러스터
• 데이터 센터
• 데이터 저장소
• folder

사전 요구 사항

• 지원 설치 관리자에서 클러스터 설치를 성공적으로 완료했습니다.
• 클러스터가 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: v1data: <vcenter_address>.username: <vcenter_username_encoded> <vcenter_address>.password: <vcenter_password_encoded>kind: Secretmetadata: 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-2ca3602f2658type: Opaque

   & lt;vcenter_address&gt;를 vCenter 주소로 바꿉니다. & lt;vcenter_username_encoded& gt;를 vSphere 사용자 이름의 base64 인코딩 버전으로 바꿉니다. & lt;vcenter_password_encoded& gt;를 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: v1data: 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: ConfigMapmetadata: 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 nodesNAME STATUS ROLES AGE VERSIONmaster-0 Ready control-plane,master 45h v1.26.3+379cd9fmaster-1 Ready control-plane,master 45h v1.26.3+379cd9fworker-0 Ready worker 45h v1.26.3+379cd9fworker-1 Ready worker 45h v1.26.3+379cd9fmaster-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: v1items:- apiVersion: config.openshift.io/v1 kind: Infrastructure metadata: creationTimestamp: "2022-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: Listmetadata: 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

• vCenter 주소
• vCenter 클러스터
• vCenter 사용자 이름
• vCenter 암호
• 데이터 센터
• 기본 데이터 저장소
• 가상 머신 폴더

사전 요구 사항

• 지원 설치 관리자에서 클러스터 설치를 성공적으로 완료했습니다.
• 클러스터가 console.redhat.com 에 연결되어 있습니다.

프로세스

1. 관리자 화면에서 홈 → 개요 로 이동합니다.
2. Status 에서 vSphere connection 을 클릭하여 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 연결 구성 마법사를 다시 열고 Monitored operators 패널을 확장합니다. Operator의 상태가 Progressing 또는 Healthy 인지 확인합니다.

검증

연결 구성 프로세스는 Operator 상태 및 컨트롤 플레인 노드를 업데이트합니다. 완료하는 데 약 1 시간이 걸립니다. 구성 프로세스 중에 노드가 재부팅됩니다. 이전에는 바인딩된 PersistentVolumeClaims 오브젝트의 연결이 끊어졌을 수 있었습니다.

1. 구성 프로세스가 성공적으로 완료되었는지 확인합니다.

   1. OpenShift Container Platform 관리자 화면에서 홈 → 개요 로 이동합니다.
   2. Status (상태)에서 Operators 를 클릭합니다. 모든 Operator 상태가 Progressing 에서 All succeeded 로 변경될 때까지 기다립니다. Failed 상태는 구성이 실패했음을 나타냅니다.
   3. Status 에서 Control Plane 을 클릭합니다. 모든 컨트롤 창 구성 요소의 응답 속도가 100%로 돌아올 때까지 기다립니다. 실패한 컨트롤 플레인 구성 요소는 구성이 실패했음을 나타냅니다.

   오류가 발생하면 연결 설정 중 하나 이상이 올바르지 않음을 나타냅니다. vSphere 연결 구성 마법사에서 설정을 변경하고 구성 을 다시 저장합니다.

2. 다음 단계를 수행하여 PersistentVolumeClaims 오브젝트를 바인딩할 수 있는지 확인합니다.

   1. 다음 YAML을 사용하여 StorageClass 오브젝트를 생성합니다.

      kind: StorageClassapiVersion: storage.k8s.io/v1metadata: name: vsphere-scprovisioner: kubernetes.io/vsphere-volumeparameters: datastore: YOURVCENTERDATASTORE diskformat: thinreclaimPolicy: DeletevolumeBindingMode: Immediate

   2. 다음 YAML을 사용하여 PersistentVolumeClaims 오브젝트를 생성합니다.

      kind: PersistentVolumeClaimapiVersion: v1metadata: name: test-pvc namespace: openshift-config annotations: volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume finalizers: - kubernetes.io/pvc-protectionspec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: vsphere-sc volumeMode: Filesystem

   자세한 내용은 OpenShift Container Platform 설명서의 동적 프로비저닝 을 참조하십시오. PersistentVolumeClaims 오브젝트의 문제를 해결하려면 OpenShift Container Platform UI의 관리자 화면에서 스토리지 → PersistentVolumeClaims 로 이동합니다.

• API를 사용하여 인프라 환경을 생성했거나 UI를 사용하여 클러스터를 생성했습니다.

사전 요구 사항

• API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.
• 인프라 환경 검색 ISO를 사용하여 호스트를 부팅했으며 호스트는 등록하지 못했습니다.
• 호스트에 대한 ssh 액세스 권한이 있습니다.
• Discovery ISO를 생성하기 전에 "호스트 추가" 대화 상자에 SSH 공개 키를 제공하여 암호 없이 시스템에 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를 연결하지 못하면 부팅 중에 호스트가 실패하거나 네트워크를 구성하지 못했습니다.

   로그인 시 다음 메시지가 표시됩니다.

   로그인 예

   이 메시지가 표시되지 않으면 호스트가 assisted-installer ISO로 부팅되지 않았음을 의미합니다. 부팅 순서를 올바르게 구성해야 합니다(호스트가 live-ISO에서 한 번 부팅되어야 함).

5. 에이전트 서비스 로그를 확인합니다.

   $ sudo journalctl -u agent.service

   다음 예에서 오류에 네트워크 문제가 있음을 나타냅니다.

   에이전트 서비스 로그의 에이전트 서비스 로그 스크린샷 예

   

   에이전트 이미지를 가져오는 동안 오류가 발생하면 프록시 설정을 확인합니다. 호스트가 네트워크에 연결되어 있는지 확인합니다. nmcli 를 사용하여 네트워크 구성에 대한 추가 정보를 가져올 수 있습니다.

사전 요구 사항

• API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.
• 인프라 환경 검색 ISO를 사용하여 호스트를 부팅했으며 호스트는 등록하지 못했습니다.
• 검색 에이전트가 실행 중인지 확인합니다.

프로세스

• 에이전트 로그를 확인하여 에이전트가 지원 서비스에 액세스할 수 있는지 확인합니다.

  $ sudo journalctl TAG=agent

  다음 예제의 오류는 에이전트가 지원 서비스에 액세스하지 못했음을 나타냅니다.

  에이전트 로그의 예

  

  클러스터에 대해 구성한 프록시 설정을 확인합니다. 구성된 경우 프록시에서 지원 서비스 URL에 대한 액세스를 허용해야 합니다.

프로세스

• 호스트를 재부팅하고 설치 디스크에서 부팅되도록 부팅 순서를 설정합니다. 설치 디스크를 선택하지 않은 경우 지원 설치 관리자가 사용자를 위해 하나를 선택했습니다. 선택한 설치 디스크를 보려면 클릭하여 호스트 인벤토리에서 호스트 정보를 확장하고 "설치 디스크" 역할이 있는 디스크를 확인합니다.

• OLM Operator를 설치하도록 요청했는데 하나 이상의 설치 실패가 발생한 경우 클러스터 콘솔에 로그인하여 오류를 해결합니다.
• 두 개 이상의 작업자 노드를 설치하도록 요청했는데 두 개 이상의 작업자를 설치하지 못했지만 두 개 이상의 성공 경우 설치된 클러스터에 실패한 작업자를 추가합니다.