프로세스

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. 선택 사항: 설치에 포함할 사용자 정의 매니페스트 가 하나 이상 있는 경우 사용자 정의 매니페스트 포함을 선택합니다. 사용자 정의 매니페스트에는 현재 지원 설치 관리자에서 지원되지 않는 추가 구성이 포함되어 있습니다. 확인란을 선택하면 매니페스트를 업로드하는 마법사에 사용자 정의 매니페스트 페이지가 추가됩니다.

    중요

    • Oracle Cloud Infrastructure(OCI) 타사 플랫폼에 OpenShift Container Platform을 설치하는 경우 Oracle에서 제공하는 사용자 정의 매니페스트를 추가해야 합니다.
    • 사용자 정의 매니페스트를 이미 추가한 경우 사용자 정의 매니페스트 포함 상자를 선택 해제하면 모두 자동으로 삭제됩니다. 삭제를 확인하라는 메시지가 표시됩니다.

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

    참고

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

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

프로세스

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

프로세스

1. 다음 옵션에서 하나 이상을 선택합니다.

   • Install OpenShift Virtualization
   • 다중 클러스터 엔진 설치
   • Install OpenShift Data Foundation
   • 논리 볼륨 관리자 설치
2. 다음을 클릭합니다.

프로세스

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

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

   3. iPXE를 사용하여 호스트를 부팅하려면 네트워크 서버에서 iPXE: Provision 을 선택합니다. 이는 z/VM 노드가 있는 IBM Z에 권장되는 방법입니다. ISO 부팅은 RHEL KVM 설치에 권장되는 방법입니다.

      참고

      • 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 스크립트를 사용하여 호스트를 부팅합니다.

프로세스

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

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

   참고

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

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

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

   참고

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

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

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

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

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

프로세스

1. 마법사의 스토리지 페이지로 이동합니다.
2. 연결된 스토리지 디스크를 표시하도록 호스트를 확장합니다.
3. Role 목록에서 Installation disk 를 선택합니다.
4. 모든 스토리지 디스크가 Ready 상태로 돌아가면 다음 단계로 이동합니다.

프로세스

1. 마법사의 스토리지 페이지로 이동합니다.
2. 연결된 스토리지 디스크를 표시하도록 호스트를 확장합니다.
3. 디스크에 대한 지우기 형식.
4. 모든 스토리지 디스크가 Ready 상태로 돌아가면 다음 단계로 이동합니다.

프로세스

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)입니다. OpenShift Container Platform 4.15 이상 릴리스에서는 SDN(소프트웨어 정의 네트워킹) 이 지원되지 않습니다.

프로세스

1. 마법사의 클러스터 세부 정보 페이지에서 사용자 정의 매니페스트 포함 확인란을 선택합니다.
2. 사용자 정의 매니페스트 페이지의 폴더 필드에서 사용자 정의 매니페스트 파일을 저장할 지원 설치 관리자 폴더를 선택합니다. 옵션에는 openshift 또는 manifest 가 포함됩니다.
3. Filename 필드에 확장을 포함하여 매니페스트 파일의 이름을 입력합니다. 예를 들면 manifest1.json 또는 multiple1.yaml 입니다.
4. Content 에서 Upload 아이콘 또는 찾아보기 를 클릭하여 파일을 업로드합니다. 또는 파일을 파일 시스템의 Content (콘텐츠) 필드로 드래그합니다.
5. 다른 매니페스트를 업로드하려면 다른 매니페스트 추가 를 클릭하고 프로세스를 반복합니다. 이렇게 하면 이전에 업로드한 매니페스트가 저장됩니다.
6. 다음을 클릭하여 모든 매니페스트를 저장하고 검토 및 생성 페이지로 이동합니다. 업로드된 사용자 정의 매니페스트는 사용자 정의 매니페스트 아래에 나열됩니다.

프로세스

1. 폴더를 변경하려면 폴더 목록에서 매니페스트의 다른 폴더 를 선택합니다.
2. 파일 이름을 수정하려면 파일 이름 필드에 매니페스트의 새 이름을 입력합니다.
3. 매니페스트를 덮어쓰려면 새 매니페스트를 동일한 폴더에 파일 이름으로 저장합니다.
4. 매니페스트를 파일 시스템에 파일로 저장하려면 다운로드 아이콘을 클릭합니다.
5. 매니페스트를 복사하려면 Copy to clipboard 아이콘을 클릭합니다.
6. 변경 사항을 적용하려면 Add another manifest 또는 Next 를 클릭합니다.

프로세스

1. 사용자 정의 매니페스트 페이지로 이동합니다.
2. 매니페스트 이름 위로 마우스를 가져가면 삭제 (minus) 아이콘이 표시됩니다.
3. 아이콘을 클릭한 다음 대화 상자에서 삭제 를 클릭합니다.

프로세스

1. 마법사의 클러스터 세부 정보 페이지로 이동합니다.
2. 사용자 정의 매니페스트 포함 확인란을 지웁니다.
3. 사용자 정의 매니페스트 제거 대화 상자에서 제거를 클릭합니다.

프로세스

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

프로세스

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

프로세스

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

3. 로드 토큰 을 클릭합니다.

   중요

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

4. API 토큰 섹션에서 오프라인 토큰을 복사합니다.

5. 터미널에서 오프라인 토큰을 OFFLINE_TOKEN 변수로 설정합니다.

   $ export OFFLINE_TOKEN=<copied_token>

   작은 정보

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

6. (선택 사항) OFFLINE_TOKEN 변수 정의를 확인합니다.

   $ echo ${OFFLINE_TOKEN}

프로세스

1. 명령줄 터미널에서 OFFLINE_TOKEN 을 사용하여 API_TOKEN 변수를 설정하여 사용자를 검증합니다.

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

2. API_TOKEN 변수 정의를 확인합니다.

   $ echo ${API_TOKEN}

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

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

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

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

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

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

   $ source refresh-token

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

프로세스

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

6. PULL_SECRET 변수 정의를 확인합니다.

   $ echo ${PULL_SECRET}

프로세스

1. 터미널의 root 사용자가 SSH 공개 키를 가져옵니다.

   $ cat /root/.ssh/id_rsa.pub

2. SSH 공개 키를 CLUSTER_SSHKEY 변수로 설정합니다.

   $ CLUSTER_SSHKEY=<downloaded_ssh_key>

3. CLUSTER_SSHKEY 변수 정의를 확인합니다.

   $ echo ${CLUSTER_SSHKEY}

프로세스

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 Container Platform 클러스터를 나타내거나 단일 노드 OpenShift 클러스터를 나타내는 None 을 사용합니다. full 은 여러 마스터 노드를 통해 고가용성 클러스터를 설치하고 설치된 클러스터의 가용성을 보장합니다. 어느 하나도 하나의 노드에 전체 클러스터를 설치하지 않습니다.

   2. 선택 사항: JSON 파일에 구성을 작성한 다음 요청에서 참조하여 새 클러스터를 등록할 수 있습니다.

      cat << EOF > cluster.json
      {
        "name": "testcluster",
        "openshift_version": "4.11",
        "high_availability_mode": "<cluster_type>", 1
        "base_dns_domain": "example.com",
        "network_type": "examplenetwork",
        "cluster_network_cidr":"11.111.1.0/14"
        "cluster_network_host_prefix": 11,
        "service_network_cidr": "111.11.1.0/16",
        "api_vips":[{"ip": ""}],
        "ingress_vips": [{"ip": ""}],
        "vip_dhcp_allocation": false,
        "additional_ntp_source": "clock.redhat.com,clock2.redhat.com",
        "ssh_public_key": "$CLUSTER_SSHKEY",
        "pull_secret": $PULL_SECRET
      }
      EOF

      참고

      1

      기본값 Full 을 사용하여 다중 노드 OpenShift Container Platform 클러스터를 나타내거나 단일 노드 OpenShift 클러스터를 나타내는 None 을 사용합니다. full 은 여러 마스터 노드를 통해 고가용성 클러스터를 설치하고 설치된 클러스터의 가용성을 보장합니다. 어느 하나도 하나의 노드에 전체 클러스터를 설치하지 않습니다.

      $ 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

프로세스

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

   $ source refresh-token

2. 클러스터를 수정합니다. 예를 들어 SSH 키를 변경합니다.

   $ 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

프로세스

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",
       "pull_secret": $PULL_SECRET,
       "proxy": {
          "http_proxy": "",
          "https_proxy": "",
          "no_proxy": ""
        },
        "ssh_authorized_key": "$CLUSTER_SSHKEY",
        "image_type": "full-iso",
        "cluster_id": "${CLUSTER_ID}",
        "openshift_version": "4.11"
      }
      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

프로세스

1. 필요한 경우 검색 이미지를 구성합니다. 자세한 내용은 검색 이미지 구성을 참조하십시오.

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

   출력 예

   {
     "expires_at": "2024-02-07T20:20:23.000Z",
     "url": "https://api.openshift.com/api/assisted-images/bytoken/<TOKEN>/<OCP_VERSION>/<CPU_ARCHITECTURE>/<FULL_OR_MINIMAL_IMAGE>.iso"
   }

4. 검색 이미지를 다운로드합니다.

   $ wget -O discovery.iso <url>

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

5. 검색 이미지를 사용하여 호스트를 부팅합니다.
6. 호스트에 역할을 할당합니다.

프로세스

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. 호스트를 수정합니다.

   $ 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. 사용자 정의 매니페스트 파일을 생성합니다.
2. 파일 형식에 적절한 확장자를 사용하여 사용자 정의 매니페스트 파일을 저장합니다.

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

   $ source refresh-token

4. 다음 명령을 실행하여 사용자 정의 매니페스트를 클러스터에 추가합니다.

   $ curl -X POST "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/manifests" \
       -H "Authorization: Bearer $API_TOKEN" \
       -H "Content-Type: application/json" \
       -d '{
               "file_name":"manifest.json",
               "folder":"manifests",
               "content":"'"$(base64 -w 0 ~/manifest.json)"'"
       }' | jq

   manifest.json 을 매니페스트 파일 이름으로 교체합니다. manifest.json 의 두 번째 인스턴스는 파일 경로입니다. 경로가 올바른지 확인합니다.

   출력 예

   {
     "file_name": "manifest.json",
     "folder": "manifests"
   }

   참고

   base64 -w 0 명령은 매니페스트를 문자열로 작성하고 반환을 생략합니다. 반환을 사용하여 인코딩하면 예외가 발생합니다.

5. 지원 설치 프로그램이 매니페스트를 추가했는지 확인합니다.

   curl -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/manifests/files?folder=manifests&file_name=manifest.json" -H "Authorization: Bearer $API_TOKEN"

   manifest.json 을 매니페스트 파일 이름으로 교체합니다.

프로세스

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

프로세스

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

프로세스

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

프로세스

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

프로세스

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

프로세스

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입니다(예: https://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

프로세스

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

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

   예제

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

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

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

      $ awk '/^initrd /{print $NF}' ipxe-script | curl -o initrd.img

   2. linux 커널을 다운로드합니다.

      $ awk '/^kernel /{print $2}' ipxe-script | curl -o kernel

   3. 루트 파일 시스템을 다운로드합니다.

      $ grep ^kernel ipxe-script | xargs -n1| grep ^coreos.live.rootfs_url | cut -d = -f 2- | curl -o rootfs.img

3. 로컬 HTTP 서버와 일치하도록 ipxe-script' 의 다른 아티팩트로 URL을 변경합니다. 예를 들면 다음과 같습니다.

   #!ipxe
   set webserver http://192.168.0.1
   initrd --name initrd $webserver/initrd.img
   kernel $webserver/kernel initrd=initrd coreos.live.rootfs_url=$webserver/rootfs.img random.trust_cpu=on rd.luks.options=discard ignition.firstboot ignition.platform.id=metal console=tty1 console=ttyS1,115200n8 coreos.inst.persistent-kargs="console=tty1 console=ttyS1,115200n8"
   boot

4. 선택 사항: IBM zSystems에 RHEL KVM을 사용하여 설치할 때 추가 커널 인수를 지정하여 호스트를 부팅해야 합니다.

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

   참고

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

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

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

   3. '/var/lib/tftpboot/boot/grub2/grub.cfg ':

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

프로세스

1. Host Discovery (호스트 검색) 탭으로 이동하여 Host Inventory (호스트 인벤토리) 테이블까지 아래로 스크롤합니다.
2. 필요한 호스트에 대해 자동 할당 드롭다운 을 선택합니다.
3. 컨트롤 플레인 노드를 선택하여 이 호스트에 컨트롤 플레인 역할을 할당합니다.
4. Worker 를 선택하여 이 호스트에 작업자 역할을 할당합니다.
5. 검증 상태를 확인합니다.

프로세스

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로 바꿉니다.

사전 요구 사항

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

프로세스

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을 승인하여 설치를 완료합니다.

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

프로세스

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을 승인하여 설치를 완료합니다.

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

주요 단계

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 Container Platform 버전 번호에 multi- 옵션을 사용합니다(예: "4.12-multi" ).

   2

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

   3

   전체 값을 사용하여 Multi-Node OpenShift Container Platform을 표시합니다.

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. 설치를 시작하고 클러스터가 완전히 설치될 때까지 기다립니다.

프로세스

1. 보류 중인 CertificateSigningRequests (CSR)를 검색합니다.

   $ oc get csr | grep Pending

   출력 예

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

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

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

   중요

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

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

   $ oc get nodes

   출력 예

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

   참고

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

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

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

      apiVersion: metal3.io/v1alpha1
      kind: BareMetalHost
      metadata:
        name: custom-master3
        namespace: openshift-machine-api
        annotations:
      spec:
        automatedCleaningMode: metadata
        bootMACAddress: 00:00:00:00:00:02
        bootMode: UEFI
        customDeploy:
          method: install_coreos
        externallyProvisioned: true
        online: true
        userData:
          name: master-user-data-managed
          namespace: openshift-machine-api

      $ oc create -f <filename>

   2. BareMetalHost CR을 적용합니다.

      $ oc apply -f <filename>

   3. 고유한 .machine.name 값을 사용하여 Machine CR을 생성합니다.

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

      $ oc create -f <filename>

   4. Machine CR을 적용합니다.

      $ oc apply -f <filename>

   5. link-machine-and-node.sh 스크립트를 사용하여 BareMetalHost,Machine, Node 를 연결합니다.

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

      $ bash link-machine-and-node.sh custom-master3 worker-5

5. etcd 멤버를 확인합니다.

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

   출력 예

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

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

   $ oc get clusteroperator etcd

   출력 예

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

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

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

   출력 예

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

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

   $ oc get nodes

   출력 예

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

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

   $ oc get ClusterOperators

   출력 예

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

10. ClusterVersion 확인 :

    $ oc get ClusterVersion

    출력 예

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

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

    1. BareMetalHost CR을 삭제합니다.

       $ oc delete bmh -n openshift-machine-api custom-master3

    2. Machine 이 비정상인지 확인합니다.

       $ oc get machine -A

       출력 예

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

    3. Machine CR을 삭제합니다.

       $ oc delete machine -n openshift-machine-api   test-day2-1-6qv96-master-0
       machine.machine.openshift.io "test-day2-1-6qv96-master-0" deleted

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

       $ oc get nodes

       출력 예

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

12. 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

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

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

    출력 예

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

프로세스

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

   $ oc get nodes

   출력 예

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

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

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

   출력 예

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

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

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

   출력 예

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

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

   $ etcdctl endpoint health

   출력 예

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

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

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

   참고

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

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

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

   출력 예

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

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

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

   출력 예

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

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

   $ etcdctl endpoint health

   출력 예

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

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

   $ etcdctl member remove 61e2a86084aafa62

   출력 예

   Member 61e2a86084aafa62 removed from cluster 6881c977b97990d7

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

    $ etcdctl member list -w table

    출력 예

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

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

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

       $ oc get csr | grep Pending

       출력 예

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

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

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

       참고

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

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

    $ oc get nodes

    출력 예

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

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

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

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

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

    중요

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

    $ bash link-machine-and-node.sh custom-master3 worker-3

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

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

    출력 예

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

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

    $ oc get clusteroperator etcd

    출력 예

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

20. etcdctl 의 상태 확인 :

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

    출력 예

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

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

    $ oc get Nodes

    출력 예

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

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

    $ oc get ClusterOperators

    출력 예

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

23. ClusterVersion 확인 :

    $ oc get ClusterVersion

    출력 예

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

프로세스

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. 설치 절차를 계속합니다.

프로세스

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.sh
   export NTX_CLUSTER_NAME=<cluster_name>
   EOF

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

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

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

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

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

   $ source refresh-token

6. 다운로드 URL을 가져옵니다.

   $ curl -H "Authorization: Bearer ${API_TOKEN}" \
   https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/downloads/image-url

7. Nutanix 이미지 구성 파일을 생성합니다.

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

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

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

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

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

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

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

10. Nutanix 클러스터 UUID를 가져옵니다.

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

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

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

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

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

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

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

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

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

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

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

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

    $ source ~/nutanix-cluster-env.sh

15. 각 Nutanix 호스트에 대한 VM 구성 파일을 생성합니다. 컨트롤 플레인(마스터) VM 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.sh
    export 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. 설치 절차를 계속합니다.

프로세스

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 $VM
    done

    & 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 $VM
    done

    & 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=TRUE
    done

    & 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 $VM
    done

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

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

프로세스

1. vCenter의 base64로 인코딩된 사용자 이름 및 암호를 생성합니다.

   $ echo -n "<vcenter_username>" | base64 -w0

   &lt ;vcenter_username&gt;을 vCenter 사용자 이름으로 바꿉니다.

   $ echo -n "<vcenter_password>" | base64 -w0

   & lt;vcenter_password&gt;를 vCenter 암호로 바꿉니다.

2. vSphere 인증 정보를 백업합니다.

   $ oc get secret vsphere-creds -o yaml -n kube-system > creds_backup.yaml

3. vSphere 인증 정보를 편집합니다.

   $ cp creds_backup.yaml vsphere-creds.yaml

   $ vi vsphere-creds.yaml

   apiVersion: v1
   data:
     <vcenter_address>.username: <vcenter_username_encoded>
     <vcenter_address>.password: <vcenter_password_encoded>
   kind: Secret
   metadata:
     annotations:
       cloudcredential.openshift.io/mode: passthrough
     creationTimestamp: "2022-01-25T17:39:50Z"
     name: vsphere-creds
     namespace: kube-system
     resourceVersion: "2437"
     uid: 06971978-e3a5-4741-87f9-2ca3602f2658
   type: Opaque

   & lt;vcenter_address&gt;를 vCenter 주소로 바꿉니다. & lt;vcenter_username_encoded& gt;를 vSphere 사용자 이름의 base64 인코딩 버전으로 바꿉니다. & lt;vcenter_password_encoded& 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: v1
   data:
     config: |
       [Global]
       secret-name = "vsphere-creds"
       secret-namespace = "kube-system"
       insecure-flag = "1"
   
       [Workspace]
       server = "<vcenter_address>"
       datacenter = "<datacenter>"
       default-datastore = "<datastore>"
       folder = "/<datacenter>/vm/<folder>"
   
       [VirtualCenter "<vcenter_address>"]
       datacenters = "<datacenter>"
   kind: ConfigMap
   metadata:
     creationTimestamp: "2022-01-25T17:40:49Z"
     name: cloud-provider-config
     namespace: openshift-config
     resourceVersion: "2070"
     uid: 80bb8618-bf25-442b-b023-b31311918507

   & lt;vcenter_address&gt;를 vCenter 주소로 바꿉니다. & lt;datacenter >를 데이터 센터 이름으로 바꿉니다. & lt;datastore >를 데이터 저장소 이름으로 바꿉니다. & lt;folder& gt;를 클러스터 VM이 포함된 폴더로 바꿉니다.

8. 클라우드 공급자 구성을 적용합니다.

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

9. 초기화되지 않은 테인트가 있는 노드에 테인트를 적용합니다.

   중요

   OpenShift Container Platform 4.13 이상을 설치하는 경우 9~12단계를 따르십시오.

   1. 테인트할 노드를 식별합니다.

      $ oc get nodes

   2. 각 노드에 대해 다음 명령을 실행합니다.

      $ oc adm taint node <node_name> node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule

      & lt;node_name >을 노드 이름으로 바꿉니다.

   예제

   $ oc get nodes
   NAME                STATUS   ROLES                  AGE   VERSION
   master-0   Ready    control-plane,master   45h   v1.26.3+379cd9f
   master-1   Ready    control-plane,master   45h   v1.26.3+379cd9f
   worker-0   Ready    worker                 45h   v1.26.3+379cd9f
   worker-1   Ready    worker                 45h   v1.26.3+379cd9f
   master-2   Ready    control-plane,master   45h   v1.26.3+379cd9f
   
   $ oc adm taint node master-0 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule
   $ oc adm taint node master-1 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule
   $ oc adm taint node master-2 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule
   $ oc adm taint node worker-0 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule
   $ oc adm taint node worker-1 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule

10. 인프라 구성을 백업합니다.

    $ oc get infrastructures.config.openshift.io -o yaml > infrastructures.config.openshift.io.yaml.backup

11. 인프라 구성을 편집합니다.

    $ cp infrastructures.config.openshift.io.yaml.backup infrastructures.config.openshift.io.yaml

    $ vi infrastructures.config.openshift.io.yaml

    apiVersion: v1
    items:
    - apiVersion: config.openshift.io/v1
      kind: Infrastructure
      metadata:
        creationTimestamp: "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: List
    metadata:
      resourceVersion: ""

    & lt;vcenter_address&gt;를 vCenter 주소로 바꿉니다. & lt;datacenter >를 vCenter 데이터 센터의 이름으로 바꿉니다. & lt;datastore& gt;를 vCenter 데이터 저장소의 이름으로 바꿉니다. & lt;folder& gt;를 클러스터 VM이 포함된 폴더로 바꿉니다. & lt;vcenter_cluster& gt;를 OpenShift Container Platform이 설치된 vSphere vCenter 클러스터로 바꿉니다.

12. 인프라 구성을 적용합니다.

    $ oc apply -f infrastructures.config.openshift.io.yaml --overwrite=true

프로세스

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 인지 확인합니다.

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: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
       name: vsphere-sc
      provisioner: kubernetes.io/vsphere-volume
      parameters:
       datastore: YOURVCENTERDATASTORE
       diskformat: thin
      reclaimPolicy: Delete
      volumeBindingMode: Immediate

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

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
       name: test-pvc
       namespace: openshift-config
       annotations:
         volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume
       finalizers:
         - kubernetes.io/pvc-protection
      spec:
       accessModes:
         - ReadWriteOnce
       resources:
         requests:
          storage: 10Gi
       storageClassName: vsphere-sc
       volumeMode: Filesystem

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

프로세스

1. Red Hat Hybrid Cloud Console 에 로그인합니다.
2. 클러스터 생성을 클릭합니다.
3. 클러스터 유형 페이지에서 Datacenter 탭을 클릭합니다.
4. 지원 설치 관리자 섹션에서 클러스터 생성을 클릭합니다.

5. 클러스터 세부 정보 페이지에서 다음 필드를 완료합니다.

   1. Cluster name 필드에서 ocidemo 와 같은 클러스터 이름을 지정합니다.
   2. Base domain 필드에서 splat-oci.devcluster.openshift.com 과 같은 클러스터의 기본 도메인을 지정합니다. Compartment 및 영역을 생성한 후 OCI에서 기본 도메인을 가져옵니다.
   3. OpenShift 버전 필드에서 OpenShift 4.15 이상 버전을 지정합니다.
   4. CPU 아키텍처 필드에서 x86_64 또는 Arm64 를 지정합니다.
   5. 외부 파트너 플랫폼과의 통합 목록에서 Oracle Cloud Infrastructure 를 선택합니다. 사용자 정의 매니페스트 포함 확인란이 자동으로 선택됩니다.
6. 다음을 클릭합니다.
7. Operator 페이지에서 다음을 클릭합니다.

8. Host Discovery 페이지에서 다음 작업을 수행합니다.

   1. 호스트 추가 를 클릭하여 대화 상자를 표시합니다.
   2. SSH 공개 키 필드의 경우 로컬 시스템에서 공개 SSH 키를 업로드합니다. ssh-keygen 을 사용하여 SSH 키 쌍을 생성할 수 있습니다.
   3. Discovery ISO 생성 을 클릭하여 검색 이미지 ISO 파일을 생성합니다.
   4. 파일을 로컬 시스템으로 다운로드합니다. 그런 다음 Oracle Cloud Infrastructure의 버킷에 파일을 오브젝트로 업로드합니다.

프로세스

1. Red Hat Hybrid Cloud Console 에서 호스트 검색 페이지로 이동합니다.
2. 역할 열에서 대상 호스트 이름마다 컨트롤 플레인 노드 또는 작업자( 컨트롤 플레인 노드 또는 작업자 ) 역할을 할당합니다. 다음을 클릭합니다.
3. 스토리지 및 네트워킹 페이지에 대한 기본 설정을 수락합니다.
4. 다음을 클릭하여 사용자 정의 매니페스트 페이지로 이동합니다.
5. 폴더 필드에서 매니페스트 를 선택합니다.
6. 파일 이름 필드에 oci-ccm.yml 과 같은 값을 입력합니다.
7. 콘텐츠 섹션에서 찾아보기 를 클릭합니다. custom_ manifest/manifests/oci-ccm.yml 에 있는 CCM 매니페스트를 선택합니다.

8. 다른 매니페스트 추가를 클릭합니다. Oracle에서 제공하는 다음 매니페스트에 대해 동일한 단계를 반복합니다.

   • CSI 드라이버 매니페스트: custom_ manifest/manifests/oci-csi.yml.
   • CCM 머신 구성: custom_ manifest/openshift/machineconfig-ccm.yml.
   • CSI 드라이버 머신 구성: custom_ manifest/openshift/machineconfig-csi.yml.
9. OCI에서 OpenShift Container Platform 클러스터를 생성하려면 검토 및 생성 단계를 완료합니다.
10. 클러스터 설치를 클릭하여 클러스터 설치를 완료합니다.

프로세스

1. 클러스터의 IP 주소 및 도메인 이름을 확인합니다.

   1. 클러스터 하이퍼링크에 도달하는 데 사용되는 IP 또는 도메인 세트를 클릭합니다.
   2. Update cluster hostname 창에서 클러스터의 올바른 IP 주소 또는 도메인 이름을 입력합니다.
2. DNS 설정을 확인하여 DNS가 제공한 도메인을 확인할 수 있는지 확인합니다.
3. 포트 22624 가 모든 방화벽에서 열려 있는지 확인합니다.

4. 호스트의 에이전트 로그를 확인하여 에이전트가 SSH를 통해 지원 서비스에 액세스할 수 있는지 확인합니다.

   $ sudo journalctl TAG=agent

   참고

   자세한 내용은 에이전트가 지원 서비스에 액세스할 수 있는지 를 참조하십시오.