지원되는 OpenShift Container Platform 설치 프로그램
지원되는 설치 관리자 사용자 가이드
초록
1장. 지원 설치 관리자를 사용하여 온프레미스 클러스터 설치
지원 설치 관리자를 사용하여 온프레미스 하드웨어 또는 온프레미스 VM에 OpenShift Container Platform을 설치할 수 있습니다. 지원 설치 관리자를 사용하여 OpenShift Container Platform을 설치하면 x86_64
,ppc64le
,s390x
및 arm64
CPU 아키텍처가 지원됩니다.
현재 IBM zSystems(s390x)에 OpenShift Container Platform을 설치하는 것은 RHEL KVM 설치에서만 지원됩니다.
1.1. 지원 설치 관리자 사용
OpenShift Container Platform 지원 설치 프로그램은 Red Hat Hybrid Cloud Console 에서 제공되는 사용자 친화적인 설치 솔루션입니다. 지원 설치 프로그램은 베어 메탈 및 vSphere 인프라에 중점을 두고 있는 다양한 배포 플랫폼을 지원합니다.
지원 설치 관리자는 설치 기능을 서비스로 제공합니다. 이 SaaS(Software-as-a-Service) 접근 방식은 다음과 같은 이점이 있습니다.
- 웹 사용자 인터페이스: 웹 사용자 인터페이스는 사용자가 수동으로 설치 구성 파일을 생성할 필요 없이 클러스터 설치를 수행합니다.
- 부트스트랩 노드가 없음: 지원 설치 프로그램으로 설치할 때 부트스트랩 노드가 필요하지 않습니다. 부트스트랩 프로세스는 클러스터 내의 노드에서 실행됩니다.
호스팅: 지원 설치 관리자 호스트:
- Ignition 파일
- 설치 구성
- 검색 ISO
- 설치 프로그램
간소화된 설치 워크플로: 배포에 OpenShift Container Platform에 대한 심층적인 지식이 필요하지 않습니다. 지원 설치 관리자는 적절한 기본값을 제공하고 다음과 같은 설치 프로그램을 서비스로 제공합니다.
- OpenShift Container Platform 설치 프로그램을 로컬에서 설치 및 실행할 필요가 없습니다.
- 최신 테스트된 z-stream 릴리스까지 설치 프로그램의 최신 버전을 확인합니다. 필요한 경우 이전 버전은 계속 사용할 수 있습니다.
- OpenShift Container Platform 설치 프로그램을 로컬로 실행할 필요 없이 API를 사용하여 빌드 자동화를 활성화합니다.
- 고급 네트워킹: 지원 설치 프로그램은 SDN 및 OVN을 사용한 IPv4 네트워킹, OVN을 사용하는 IPv6 및 듀얼 스택 네트워킹, NMState 기반 고정 IP 주소 지정, HTTP/S 프록시를 지원합니다. OVN은 OpenShift Container Platform 4.12 이상 릴리스의 기본 CNI(Container Network Interface)이지만 SDN을 사용하도록 전환할 수 있습니다.
설치 사전 검증: 지원 설치 관리자는 설치 전에 구성을 검증하여 높은 성공 가능성을 보장합니다. 검증에는 다음이 포함됩니다.
- 네트워크 연결 확인
- 충분한 네트워크 대역폭 확인
- 레지스트리에 대한 연결 확인
- 업스트림 DNS가 필요한 도메인 이름을 확인할 수 있는지 확인
- 클러스터 노드 간 시간 동기화 보장
- 클러스터 노드가 최소 하드웨어 요구 사항을 충족하는지 확인
- 설치 구성 매개변수 검증
- REST API: 지원 설치 프로그램에는 자동화를 활성화하는 REST API가 있습니다.
지원 설치 관리자는 선택적 HTTP/S 프록시를 포함하여 연결된 환경의 온프레미스에 OpenShift Container Platform을 설치할 수 있도록 지원합니다. 다음을 설치할 수 있습니다.
- 고가용성 OpenShift Container Platform 또는 Single Node OpenShift (SNO)
- 전체 플랫폼 통합 또는 기타 가상화 플랫폼이 있는 베어 메탈 또는 vSphere의 OpenShift Container Platform
- 필요한 경우 OpenShift Virtualization 및 OpenShift Data Foundation (이전 OpenShift Container Storage)
사용자 인터페이스는 자동화가 없거나 필요하지 않은 직관적인 대화형 워크플로우를 제공합니다. 사용자는 REST API를 사용하여 설치를 자동화할 수도 있습니다.
지원 설치 프로그램으로 OpenShift Container Platform 클러스터를 생성하려면 Install OpenShift with the Assisted Installer 를 참조하십시오.
1.2. 지원 설치 관리자의 API 지원
지원 설치 관리자에 지원되는 API는 사용 중단 공지 후 최소 3개월 동안 안정적입니다.
2장. 지원 설치 관리자를 사용하여 설치 준비
클러스터를 설치하기 전에 클러스터 노드와 네트워크가 요구사항을 충족하는지 확인해야 합니다.
2.1. 사전 요구 사항
- OpenShift Container Platform 설치 및 업데이트 프로세스에 대한 세부 사항을 검토하셨습니다.
- 클러스터 설치 방법 선택 및 사용자를 위한 준비에 대한 문서를 읽습니다.
- 방화벽을 사용하는 경우 지원 설치 프로그램이 작동하는 데 필요한 리소스에 액세스할 수 있도록 방화벽을 구성해야 합니다.
2.2. 지원되는 설치 관리자 사전 요구 사항
지원 설치 관리자는 설치에 성공하기 위해 다음과 같은 사전 요구 사항의 유효성을 검사합니다.
2.2.1. CPU 아키텍처
지원 설치 프로그램은 다음 CPU 아키텍처에서 지원됩니다.
- x86_64
- arm64
- ppc64le
- s390x
2.2.2. 하드웨어
지원 설치 관리자에는 CPU 코어 8개, 16.00GiB RAM, 100GB 디스크 크기가 있는 하나의 호스트가 필요합니다.
컨트롤 플레인의 경우 호스트에 다음과 같은 리소스가 있어야 합니다.
- 4개의 CPU 코어
- 16.00GiB RAM
- 100GB 스토리지
-
etcd
wal_fsync_duration_seconds
의 경우 10MS 쓰기 속도 또는 그 이하
작업자의 경우 각 호스트에는 다음과 같은 리소스가 있어야 합니다.
- 2개의 CPU 코어
- 8.00GiB RAM
- 100GB 스토리지
vMware
유형의 호스트의 경우 platform이 vSphere가 아닌 경우에도 clusterSet disk.enableUUID
를 true 로 설정합니다.
2.2.3. 네트워킹
네트워크는 다음 요구 사항을 충족해야 합니다.
- 고정 IP 주소를 사용하지 않는 한 DHCP 서버.
기본 도메인 이름입니다. 다음 요구 사항이 충족되었는지 확인해야 합니다.
-
*.<cluster_name>.<base_domain
>과 같은 와일드카드가 없거나 설치가 진행되지 않습니다. -
api.<cluster_name>.<base_domain>의 DNS A/AAAA 레코드입니다
. -
*.apps.<cluster_name>.<base_domain
> 에 와일드카드가 있는 DNS A/AAAA 레코드입니다.
-
-
방화벽 외부의 사용자가
oc
CLI 툴을 통해 클러스터에 액세스할 수 있도록 하려면 API URL에 대해 포트6443
이 열립니다. -
방화벽 외부의 사용자가 콘솔에 액세스할 수 있도록 하려면 콘솔에 대해 포트
443
이 열립니다. - 사용자 관리 네트워킹을 사용할 때 클러스터의 각 노드에 대한 DNS A/AAAA 레코드가 진행되지 않거나 설치가 진행되지 않습니다. 클러스터에 연결하기 위해 설치가 완료된 후 클러스터 관리 네트워킹을 사용하는 경우 클러스터의 각 노드에 DNS A/AAAA 레코드가 필요하지만 Cluster Managed Networking을 사용할 때 A/AAAA 레코드 없이 설치할 수 있습니다.
- 고정 IP 주소를 사용할 때 사전 설정된 호스트 이름으로 부팅하려는 경우 클러스터의 각 노드에 대한 DNS PTR 레코드입니다. 그렇지 않으면 지원 설치 관리자에 노드의 이름을 네트워크 인터페이스 MAC 주소로 변경할 고정 IP 주소를 사용할 때 자동 노드 이름 변경 기능이 있습니다.
최상위 도메인 등록 기관의 DNS A/AAAA 레코드 설정은 업데이트하는 데 상당한 시간이 걸릴 수 있습니다. 설치 지연을 방지하기 위해 설치 전에 A/AAAA 레코드 DNS 설정이 작동하는지 확인합니다.
OpenShift Container Platform 클러스터 네트워크도 다음 요구사항을 충족해야 합니다.
- 모든 클러스터 노드 간 연결
- 인터넷에 각 노드의 연결
- 클러스터 노드 간 시간 동기화를 위해 NTP 서버에 액세스
2.2.4. 사전 진행 검증
지원 설치 관리자는 복잡한 설치 후 문제 해결을 제거하여 클러스터가 설치 전에 사전 요구 사항을 충족하는지 확인하므로 시간과 노력을 많이 절약할 수 있습니다. 노드에 소프트웨어를 설치하기 전에 지원 설치 프로그램은 다음 검증을 수행합니다.
- 네트워크 연결 확인
- 충분한 네트워크 대역폭 확인
- 레지스트리에 대한 연결 확인
- 모든 업스트림 DNS가 필요한 도메인 이름을 확인할 수 있는지 확인합니다.
- 클러스터 노드 간 시간 동기화 보장
- 클러스터 노드가 최소 하드웨어 요구 사항을 충족하는지 확인합니다.
- 설치 구성 매개변수 검증
지원 설치 프로그램이 진행 중인 요구 사항을 성공적으로 확인하지 않으면 설치가 진행되지 않습니다.
3장. 지원 설치 관리자 UI로 설치
클러스터 노드 및 네트워크 요구 사항이 충족되는지 확인한 후 클러스터 설치를 시작할 수 있습니다.
3.1. 사전 설치 고려 사항
지원 설치 관리자를 사용하여 OpenShift Container Platform을 설치하기 전에 다음과 같은 구성 옵션을 고려해야 합니다.
- 사용할 기본 도메인
- 설치할 OpenShift Container Platform 제품 버전
- 전체 클러스터 또는 단일 노드 OpenShift 설치 여부
- DHCP 서버 또는 정적 네트워크 구성 사용 여부
- IPv4 또는 듀얼 스택 네트워킹 사용 여부
- OpenShift Virtualization 설치 여부
- Red Hat OpenShift Data Foundation 설치 여부
- 다중 클러스터 엔진 설치 여부
- vSphere 또는 Nutanix에 설치할 때 플랫폼과 통합할지 여부
Operator를 설치하려는 경우 Optional:Installing Operator의 관련 하드웨어 및 스토리지 요구 사항을 참조하십시오.
3.2. 클러스터 세부 정보 설정
지원 설치 관리자 웹 사용자 인터페이스를 사용하여 클러스터를 생성하려면 다음 절차를 사용하십시오.
절차
- Red Hat Hybrid Cloud Console 에 로그인합니다.
- Red Hat OpenShift 타일에서 애플리케이션 스케일링을 클릭합니다.
- 메뉴에서 클러스터를 클릭합니다.
- 클러스터 생성을 클릭합니다.
- Datacenter 탭을 클릭합니다.
- 지원 설치 관리자에서 클러스터 생성을 클릭합니다.
- 클러스터 이름 필드에 클러스터 이름을 입력합니다.
Base domain 필드에 클러스터의 기본 도메인을 입력합니다. 클러스터의 모든 하위 도메인은 이 기본 도메인을 사용합니다.
참고기본 도메인은 유효한 DNS 이름이어야 합니다. 기본 도메인에 대해 와일드카드 도메인이 설정되어 있지 않아야 합니다.
설치할 OpenShift Container Platform 버전을 선택합니다.
참고IBM Power 및 IBM zSystems 플랫폼의 경우 OpenShift Container Platform 버전 4.13 이상만 지원됩니다.
선택사항: 단일 노드에 OpenShift Container Platform을 설치하려면 Install single node Openshift (SNO) 를 선택합니다.
참고현재 SNO는 IBM zSystems 및 IBM Power 플랫폼에서 지원되지 않습니다.
- 선택 사항: 지원 설치 프로그램에 이미 계정에 풀 시크릿이 연결되어 있습니다. 다른 풀 시크릿을 사용하려면 Edit pull secret 을 선택합니다.
-
선택사항: 지원 설치 관리자의 기본값은
x86_64
CPU 아키텍처를 사용합니다. 다른 아키텍처에 OpenShift Container Platform을 설치하는 경우 사용할 해당 아키텍처를 선택합니다. 유효한 값은arm64
,ppc64le
및s390x
입니다. 일부 기능은arm64
,ppc64le
및s390x
CPU 아키텍처에서는 사용할 수 없습니다. - 선택사항: 지원 설치 관리자의 기본값은 DHCP 네트워킹입니다. DHCP 예약 대신 클러스터 노드의 고정 IP 구성, 브리지 또는 본딩을 사용하는 경우 고정 IP, 브리지 및 본딩을 선택합니다.
- 선택 사항: 설치 디스크의 암호화를 활성화하려면 설치 디스크 의 암호화를 활성화 하면 컨트롤 플레인 노드를 선택하고 단일 노드 OpenShift의 작업자 를 선택할 수 있습니다. 다중 노드 클러스터의 경우 컨트롤 플레인 노드를 선택하여 컨트롤 플레인 노드 설치 디스크를 암호화하고 Workers 를 선택하여 작업자 노드 설치 디스크를 암호화할 수 있습니다.
기본 도메인, SNO 확인란, CPU 아키텍처, 호스트의 네트워크 구성 또는 설치가 시작된 후 디스크 암호화를 변경할 수 없습니다.
3.3. 선택사항: 정적 네트워크 구성
지원 설치 관리자는 SDN 및 OVN을 사용한 IPv4 네트워킹을 지원하며 OVN을 사용하는 IPv6 및 듀얼 스택 네트워킹만 지원합니다. 지원 설치 관리자는 IP 주소/MAC 주소 매핑을 사용하여 정적 네트워크 인터페이스를 사용하여 네트워크 구성을 지원합니다. 또한 지원 설치 관리자는 호스트에 대한 선언적 네트워크 관리자 API인 NMState 라이브러리를 사용하여 호스트 네트워크 인터페이스 구성을 지원합니다. NMState를 사용하여 고정 IP 주소 지정, 본딩, VLAN 및 기타 고급 네트워킹 기능이 있는 호스트를 배포할 수 있습니다. 먼저 네트워크 전체 구성을 설정해야 합니다. 그런 다음 각 호스트에 대해 호스트별 구성을 생성해야 합니다.
z/VM을 사용하여 IBM Z에 설치하는 경우 정적 네트워크 및 NMState에 대해 z/VM 노드 및 vSwitch가 올바르게 구성되었는지 확인합니다. 또한 z/VM 노드에는 MAC 주소 풀로 인해 NMState에 문제가 발생할 수 있으므로 고정된 MAC 주소가 할당되어 있어야 합니다.
절차
- 인터넷 프로토콜 버전을 선택합니다. 유효한 옵션은 IPv4 및 듀얼 스택 입니다.
- 클러스터 호스트가 공유 VLAN에 있는 경우 VLAN ID를 입력합니다.
네트워크 전체 IP 주소를 입력합니다. 듀얼 스택 네트워킹을 선택한 경우 IPv4 및 IPv6 주소를 모두 입력해야 합니다.
- CIDR 표기법으로 클러스터 네트워크의 IP 주소 범위를 입력합니다.
- 기본 게이트웨이 IP 주소를 입력합니다.
- DNS 서버 IP 주소를 입력합니다.
호스트별 구성을 입력합니다.
- 단일 네트워크 인터페이스를 사용하는 고정 IP 주소만 설정하는 경우 양식 보기를 사용하여 각 호스트의 IP 주소와 MAC 주소를 입력합니다.
- 여러 인터페이스, 본딩 또는 기타 고급 네트워킹 기능을 사용하는 경우 YAML 보기를 사용하고 NMState 구문을 사용하는 각 호스트에 대해 원하는 네트워크 상태를 입력합니다. 그런 다음 네트워크 구성에 사용된 각 호스트 인터페이스의 MAC 주소 및 인터페이스 이름을 추가합니다.
추가 리소스
3.4. Operator 구성
지원 설치 프로그램은 특정 Operator가 구성된 상태에서 설치할 수 있습니다. Operator는 다음과 같습니다.
- OpenShift Virtualization
- Kubernetes용 MCCE(Multicluster Engine)
- OpenShift Data Foundation
- LVM(Logical Volume Manager) 스토리지
하드웨어 요구 사항, 스토리지 고려 사항, 상호 종속 항목 및 추가 설치 지침과 함께 각 Operator에 대한 자세한 설명은 추가 리소스를 참조하십시오.
이 단계는 선택 사항입니다. Operator를 선택하지 않고 설치를 완료할 수 있습니다.
절차
- OpenShift Virtualization을 설치하려면 OpenShift Virtualization 설치를 선택합니다.
- MCCE(Multicluster Engine)를 설치하려면 다중 클러스터 엔진 설치를 선택합니다.
- OpenShift Data Foundation을 설치하려면 OpenShift Data Foundation 설치를 선택합니다.
- 논리 볼륨 관리자를 설치하려면 Install Logical Volume Manager 를 선택합니다.
- 다음을 클릭하여 다음 단계를 진행합니다.
3.5. 클러스터에 호스트 추가
클러스터에 하나 이상의 호스트를 추가해야 합니다. 클러스터에 호스트를 추가하려면 검색 ISO를 생성해야 합니다. 검색 ISO는 에이전트를 사용하여 RHCOS(Red Hat Enterprise Linux CoreOS) in-memory를 실행합니다.
클러스터의 각 호스트에 대해 다음 절차를 수행합니다.
절차
호스트 추가 버튼을 클릭하고 설치 미디어를 선택합니다.
-
Minimal image file: Provision with virtual media 를 선택하여 부팅에 필요한 데이터를 가져올 작은 이미지를 다운로드합니다. 노드에는 가상 미디어 기능이 있어야 합니다. 이 방법은
x86_64
및arm64
아키텍처에 권장되는 방법입니다. -
Full image file: Provision with physical media 를 선택하여 더 큰 전체 이미지를 다운로드합니다. 이는
ppc64le
아키텍처에 권장되는 방법입니다. iPXE: Provision을 네트워크 서버에서 선택하여 iPXE를 사용하여 호스트를 부팅합니다. 이 방법은
s390x
아키텍처에 권장되는 방법입니다.참고RHEL KVM에 iPXE를 사용하여 설치하는 경우 경우에 따라 KVM 호스트의 VM이 처음 부팅될 때 재부팅되지 않으므로 수동으로 시작해야 합니다.
-
Minimal image file: Provision with virtual media 를 선택하여 부팅에 필요한 데이터를 가져올 작은 이미지를 다운로드합니다. 노드에는 가상 미디어 기능이 있어야 합니다. 이 방법은
- 선택 사항: 클러스터 호스트가 프록시를 사용해야 하는 방화벽 뒤에 있는 경우 클러스터 전체 프록시 설정 구성을 선택합니다. 프록시 서버의 HTTP 및 HTTPS URL에 대한 사용자 이름, 암호, IP 주소 및 포트를 입력합니다.
선택 사항:
core
사용자로 클러스터 노드에 연결할 수 있도록 SSH 공개 키를 추가합니다. 클러스터 노드에 로그인하면 설치 중에 디버깅 정보를 제공할 수 있습니다.중요재해 복구 및 디버깅이 필요한 프로덕션 환경에서는이 단계를 생략하지 마십시오.
- 로컬 시스템에 기존 SSH 키 쌍이 없는 경우 클러스터 노드 SSH 액세스에 대한 키 쌍 생성 단계를 따르십시오.
-
SSH 공개 키 필드에서 찾아보기 를 클릭하여 SSH 공개 키가 포함된
id_rsa.pub
파일을 업로드합니다. 또는 파일을 파일 관리자의 필드로 끌어다 놓습니다. 파일 관리자에서 파일을 보려면 메뉴에서 숨겨진 파일 표시를 선택합니다.
- 선택 사항: 클러스터 호스트가 재암호화 MITM(man-in-the-middle) 프록시를 사용하는 네트워크에 있거나 클러스터가 컨테이너 이미지 레지스트리와 같은 다른 용도로 인증서를 신뢰해야 하는 경우 클러스터 전체에서 신뢰할 수 있는 인증서 구성을 선택합니다. X.509 형식으로 추가 인증서를 추가합니다.
- 필요한 경우 검색 이미지를 구성합니다.
- 선택 사항: 플랫폼에 설치하고 플랫폼과 통합 하려면 가상화 플랫폼과 통합을 선택합니다. 모든 호스트를 부팅하고 호스트 인벤토리에 표시되는지 확인해야 합니다. 모든 호스트가 동일한 플랫폼에 있어야 합니다.
- Discovery ISO 생성을 클릭하거나 스크립트 파일 생성을 클릭합니다.
- 검색 ISO 또는 iPXE 스크립트를 다운로드합니다.
- 검색 이미지 또는 iPXE 스크립트를 사용하여 호스트를 부팅합니다.
3.6. 호스트 구성
검색 ISO로 호스트를 부팅하면 호스트가 페이지 하단에 있는 테이블에 표시됩니다. 선택 옵션으로 각 호스트의 호스트 이름과 역할을 구성할 수 있습니다. 필요한 경우 호스트를 삭제할 수도 있습니다.
절차
호스트의 Options (Options) 메뉴에서 Change hostname 을 선택합니다. 필요한 경우 호스트의 새 이름을 입력하고 변경을 클릭합니다. 각 호스트에 유효한 고유한 호스트 이름이 있는지 확인해야 합니다.
또는 작업 목록에서 호스트 이름 변경을 선택하여 선택한 여러 호스트의 이름을 변경합니다. 호스트 이름 변경 대화 상자에서 새 이름을 입력하고
{{n}}
를 포함하여 각 호스트 이름을 고유하게 설정합니다. 그런 다음 변경을 클릭합니다.참고사용자가 입력할 때 프리뷰 창에서 새 이름이 나타나는 것을 확인할 수 있습니다. 호스트당 한 자리 증분을 제외하고 선택한 모든 호스트에 대해 이름이 동일합니다.
Options (Options) 메뉴에서 Delete host 를 선택하여 호스트를 삭제할 수 있습니다. 삭제를 클릭하여 삭제를 확인합니다.
또는 Actions 목록에서 Delete 를 선택하여 선택한 여러 호스트를 동시에 삭제합니다. 그런 다음 호스트 삭제를 클릭합니다.
참고일반 배포에서 클러스터에 3개 이상의 호스트가 있을 수 있으며, 이 중 세 개는 컨트롤 플레인 호스트여야 합니다. 컨트롤 플레인이라고도 하는 호스트를 삭제하거나 두 개의 호스트만 남아 있는 경우 시스템이 준비되지 않았음이라는 메시지가 표시됩니다. 호스트를 복원하려면 검색 ISO에서 호스트를 재부팅해야 합니다.
- 호스트의 Options (Options) 메뉴에서 선택적으로 호스트 이벤트 보기 를 선택합니다. 목록에 있는 이벤트는 순서대로 표시됩니다.
멀티 호스트 클러스터의 경우 호스트 이름 옆에 있는 Role 열에서 메뉴를 클릭하여 호스트의 역할을 변경할 수 있습니다.
역할을 선택하지 않으면 지원 설치 프로그램이 자동으로 역할을 할당합니다. 컨트롤 플레인 노드의 최소 하드웨어 요구 사항은 작업자 노드를 초과합니다. 호스트에 역할을 할당하는 경우 최소 하드웨어 요구 사항을 충족하는 호스트에 컨트롤 플레인 역할을 할당해야 합니다.
- Status (상태) 링크를 클릭하여 호스트에 대한 하드웨어, 네트워크 및 Operator 검증을 확인합니다.
- 호스트 이름 왼쪽에 있는 화살표를 클릭하여 호스트 세부 정보를 확장합니다.
모든 클러스터 호스트가 Ready 상태로 표시되면 다음 단계를 진행합니다.
3.7. 스토리지 디스크 구성
클러스터 호스트를 검색하고 구성한 후 선택적으로 각 호스트에 대한 스토리지 디스크를 구성할 수 있습니다.
여기에서 가능한 모든 호스트 구성은 호스트 구성 섹션에서 설명합니다. 링크는 아래 추가 리소스를 참조하십시오.
절차
- 호스트 이름 옆에 있는 확인란의 왼쪽에 있는 를 클릭하여 해당 호스트의 스토리지 디스크를 표시합니다.
- 호스트에 대한 스토리지 디스크가 여러 개인 경우 설치 디스크 역할을 할 다른 디스크를 선택할 수 있습니다. 디스크의 Role 드롭다운 목록을 클릭한 다음 Installation disk 를 선택합니다. 이전 설치 디스크의 역할이 None 으로 변경됩니다.
- 부팅 가능한 모든 디스크는 기본적으로 설치 중에 CDROM과 같은 읽기 전용 디스크를 제외하고 다시 포맷하기 위해 표시됩니다. 디스크가 다시 포맷되지 않도록 형식 확인란을 선택 취소합니다. 설치 디스크를 다시 포맷해야 합니다. 진행하기 전에 중요한 데이터를 백업하십시오.
모든 디스크 드라이브가 Ready 상태로 표시되면 다음 단계를 진행합니다.
추가 리소스
3.8. 네트워킹 구성
OpenShift Container Platform을 설치하기 전에 클러스터 네트워크를 구성해야 합니다.
절차
네트워킹 페이지에서 아직 선택하지 않은 경우 다음 중 하나를 선택합니다.
클러스터 관리 네트워킹: 클러스터 관리 네트워킹을 선택하면 지원 설치 프로그램이 API 및 Ingress VIP 주소를 관리하기 위한
keepalived
및 VRRP(Virtual Router Redundancy Protocol)를 비롯한 표준 네트워크 토폴로지를 구성합니다.참고현재 Cluster-Managed Networking은 IBM zSystems 및 IBM Power in OpenShift Container Platform 버전 4.13에서 지원되지 않습니다.
-
사용자 관리 네트워킹: 사용자 관리 네트워킹을 선택하면 비표준 네트워크 토폴로지를 사용하여 OpenShift Container Platform을 배포할 수 있습니다. 예를 들어
keepalived
및 VRRP 대신 외부 로드 밸런서로 배포하거나 여러 개별 L2 네트워크 세그먼트에 클러스터 노드를 배포하려는 경우.
클러스터 관리 네트워킹의 경우 다음 설정을 구성합니다.
- 시스템 네트워크를 정의합니다. 기본 네트워크를 사용하거나 서브넷을 선택할 수 있습니다.
- API 가상 IP 를 정의합니다. API 가상 IP는 모든 사용자가 상호 작용하고 플랫폼을 구성할 수 있는 끝점을 제공합니다.
- Ingress 가상 IP 를 정의합니다. Ingress 가상 IP는 클러스터 외부에서 이동하는 애플리케이션 트래픽에 대한 끝점을 제공합니다.
사용자 관리 네트워킹의 경우 다음 설정을 구성합니다.
네트워킹 스택 유형을 선택합니다.
- IPv4: 호스트가 IPv4 만 사용하는 경우 이 유형을 선택합니다.
- Dual-stack: 호스트가 IPv6와 함께 IPv4를 사용하는 경우 듀얼 스택을 선택할 수 있습니다.
- 시스템 네트워크를 정의합니다. 기본 네트워크를 사용하거나 서브넷을 선택할 수 있습니다.
- API 가상 IP 를 정의합니다. API 가상 IP는 모든 사용자가 상호 작용하고 플랫폼을 구성할 수 있는 끝점을 제공합니다.
- Ingress 가상 IP 를 정의합니다. Ingress 가상 IP는 클러스터 외부에서 이동하는 애플리케이션 트래픽에 대한 끝점을 제공합니다.
- 선택 사항: DHCP 서버를 통해 IP 할당을 선택하여 DHCP 서버를 사용하여 API IP 및 Ingress IP 를 자동으로 할당할 수 있습니다.
선택 사항: 고급 네트워킹 사용을 선택하여 다음 고급 네트워킹 속성을 구성합니다.
- 클러스터 네트워크 CIDR: Pod IP 주소가 할당되는 IP 주소 블록을 정의합니다.
- 클러스터 네트워크 호스트 접두사: 각 노드에 할당할 서브넷 접두사 길이를 정의합니다.
- Service network CIDR: 서비스 IP 주소에 사용할 IP 주소를 정의합니다.
- 네트워크 유형: 표준 네트워킹의 경우 SDN(소프트웨어 정의 네트워킹) 또는 IPv6, 듀얼 스택 네트워킹 및 통신 기능에 대해 OVN(Open Virtual Networking) 을 선택합니다. OpenShift Container Platform 4.12 이상 릴리스에서는 OVN이 기본 CNI(Container Network Interface)입니다.
추가 리소스
3.9. 설치 전 검증
지원 설치 관리자는 복잡한 설치 후 문제 해결을 제거하여 클러스터가 설치 전에 사전 요구 사항을 충족하는지 확인하므로 시간과 노력을 많이 절약할 수 있습니다. 클러스터를 설치하기 전에 클러스터와 각 호스트가 설치 사전 검증을 통과했는지 확인합니다.
추가 리소스
3.10. 클러스터 설치
구성을 완료한 후 모든 노드가 준비 상태가 되면 설치를 시작할 수 있습니다. 설치 프로세스는 상당한 시간이 소요되며 지원 설치 관리자 웹 콘솔에서 설치를 모니터링할 수 있습니다. 노드는 설치 중에 재부팅되고 설치 후 초기화됩니다.
절차
- Starte gin installation 을 누릅니다.
- Host Inventory (호스트 인벤토리) 목록의 Status (상태) 열에서 링크를 클릭하여 특정 호스트의 설치 상태를 확인합니다.
3.11. 설치 완료
클러스터를 설치하고 초기화한 후 지원 설치 프로그램은 설치가 완료되었음을 나타냅니다. 지원 설치 프로그램에서는 콘솔 URL, kubeadmin
사용자 이름 및 암호, kubeconfig
파일을 제공합니다. 또한 지원 설치 관리자는 OpenShift Container Platform 버전, 기본 도메인, CPU 아키텍처, API 및 Ingress IP 주소, 클러스터 및 서비스 네트워크 IP 주소를 포함한 클러스터 세부 정보를 제공합니다.
사전 요구 사항
-
oc
CLI 툴을 설치했습니다.
절차
-
kubeadmin
사용자 이름 및 암호를 복사합니다. kubeconfig
파일을 다운로드하여 작업 디렉터리 아래의auth
디렉터리에 복사합니다.$ mkdir -p <working_directory>/auth
$ cp kubeadmin <working_directory>/auth
참고kubeconfig
파일은 설치를 완료한 후 24시간 동안 다운로드할 수 있습니다.kubeconfig
파일을 환경에 추가합니다.$ export KUBECONFIG=<your working directory>/auth/kubeconfig
oc
CLI 툴로 로그인합니다.$ oc login -u kubeadmin -p <password>
&
lt;password
>를kubeadmin
사용자의 암호로 바꿉니다.- 웹 콘솔 URL을 클릭하거나 OpenShift 콘솔 시작을 클릭하여 콘솔을 엽니다.
-
kubeadmin
사용자 이름 및 암호를 입력합니다. OpenShift Container Platform 콘솔의 지침에 따라 ID 공급자를 구성하고 경고 수신자를 구성합니다. - OpenShift Container Platform 콘솔의 북마크를 추가합니다.
- 설치 후 플랫폼 통합 단계를 완료합니다.
추가 리소스
4장. 지원 설치 관리자 API로 설치
클러스터 노드 및 네트워크 요구 사항이 충족되는지 확인한 후 지원 설치 관리자 API를 사용하여 클러스터 설치를 시작할 수 있습니다. API를 사용하려면 다음 절차를 수행해야 합니다.
- API 인증을 설정합니다.
- 풀 시크릿을 구성합니다.
- 새 클러스터 정의를 등록합니다.
- 클러스터의 인프라 환경을 생성합니다.
이러한 단계를 수행한 후에는 클러스터 정의를 수정하고, 검색 ISO를 생성하고, 호스트를 클러스터에 추가하고, 클러스터를 설치할 수 있습니다. 이 문서는 지원 설치 관리자 API의 모든 끝점을 다루지는 않지만 API 뷰어 또는 swagger.yaml 파일의 모든 끝점을 검토할 수 있습니다.
4.1. 선택사항: OpenShift Cluster Manager CLI 설치
OpenShift Cluster Manager(ocm) CLI 툴을 사용하면 명령줄에서 OpenShift Cluster Manager와 상호 작용할 수 있습니다. REST GET, POST, PATCH 및 DELETE 작업을 실행하고 API 토큰을 생성하고 다른 기능 간에 클러스터를 나열할 수 있습니다.
OpenShift Cluster Manager CLI는 개발자 프리뷰 기능 전용입니다. 개발자 프리뷰 기능은 Red Hat에서 어떤 방식으로든 지원하지 않으며 완전한 기능이나 프로덕션에 준비되지 않습니다. 프로덕션 또는 비즈니스 크리티컬 워크로드에는 개발자 프리뷰 기능을 사용하지 마십시오. 개발자 프리뷰 기능을 사용하면 Red Hat 제품에 포함될 수 있는 제품 기능을 미리 미리 액세스할 수 있으므로 고객은 개발 과정에서 기능을 테스트하고 피드백을 제공할 수 있습니다. 이러한 기능에는 문서가 없을 수 있으며 언제든지 변경 또는 제거가 적용되며 테스트가 제한됩니다. Red Hat은 관련 SLA 없이 개발자 프리뷰 기능에 대한 피드백을 제출할 수 있는 방법을 제공할 수 있습니다.
사전 요구 사항
-
jq
를 설치합니다. - 클러스터 생성 권한이 있는 사용자로 OpenShift Cluster Manager 에 로그인합니다.
절차
- 메뉴에서 OpenShift 를 클릭합니다.
- 하위 메뉴에서 다운로드를 클릭합니다.
- OpenShift Cluster Manager API 토큰 의 토큰 섹션에서 API 토큰 보기 를 클릭합니다.
토큰 로드 를 클릭합니다.
중요팝업 차단기를 비활성화합니다.
- API 토큰 섹션에서 오프라인 토큰을 복사합니다.
터미널에서 오프라인 토큰을
OFFLINE_TOKEN
변수로 설정합니다.$ export OFFLINE_TOKEN=<copied_api_token>
작은 정보오프라인 토큰을 영구적으로 만들려면 프로필에 추가합니다.
- ocm CLI 다운로드를 클릭합니다.
-
다운로드한 파일을 경로에 복사합니다. 예를 들어 파일을
/usr/bin
또는~/.local/bin
에 복사하고ocm
심볼릭 링크를 만듭니다. 인증 명령을 복사하여 터미널에 붙여넣고 Enter 키를 눌러 로그인하십시오.
$ ocm login --token="${OFFLINE_TOKEN}"
4.2. REST API를 사용한 인증
API 호출에는 API 토큰을 사용한 인증이 필요합니다. API_TOKEN
을 변수 이름으로 사용하는 경우 REST API로 인증하기 위해 API 호출에 -H "Authorization: Bearer ${API_TOKEN}"
를 추가합니다.
API 토큰은 15분 후에 만료됩니다.
사전 요구 사항
- (선택 사항) OpenShift Cluster Manager (ocm) CLI 도구를 설치했습니다.
절차
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" \ )
(선택 사항) 명령줄 터미널에서
ocm
클라이언트에 로그인합니다.$ ocm login --token="${OFFLINE_TOKEN}"
그런 다음 API 토큰을 생성합니다.
$ export API_TOKEN=$(ocm token)
토큰 생성 방법 중 하나의 경로에 스크립트를 생성합니다. 예를 들면 다음과 같습니다.
$ 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" \ )
그런 다음 파일을 저장합니다.
파일 모드를 변경하여 실행 가능하게 합니다.
$ chmod +x ~/.local/bin/refresh-token
API 토큰을 새로 고칩니다.
$ source refresh-token
다음 명령을 실행하여 API에 액세스할 수 있는지 확인합니다.
$ curl -s https://api.openshift.com/api/assisted-install/v2/component-versions -H "Authorization: Bearer ${API_TOKEN}" | jq
출력 예
{ "release_tag": "v2.11.3", "versions": { "assisted-installer": "registry.redhat.io/rhai-tech-preview/assisted-installer-rhel8:v1.0.0-211", "assisted-installer-controller": "registry.redhat.io/rhai-tech-preview/assisted-installer-reporter-rhel8:v1.0.0-266", "assisted-installer-service": "quay.io/app-sre/assisted-service:78d113a", "discovery-agent": "registry.redhat.io/rhai-tech-preview/assisted-installer-agent-rhel8:v1.0.0-195" } }
4.3. 풀 시크릿 구성
대부분의 지원 설치 관리자 API 호출에는 풀 시크릿이 필요합니다. API 호출에서 참조할 수 있도록 파일에 풀 시크릿을 다운로드합니다. 가져오기 보안은 요청의 JSON 오브젝트에 값으로 포함될 JSON 오브젝트입니다. 따옴표를 이스케이프하려면 가져오기 시크릿 JSON을 포맷해야 합니다. 예를 들면 다음과 같습니다.
before
{"auths":{"cloud.openshift.com": ...
후
{\"auths\":{\"cloud.openshift.com\": ...
절차
- 메뉴에서 OpenShift 를 클릭합니다.
- 하위 메뉴에서 다운로드를 클릭합니다.
- Pull secret 아래의 토큰 섹션에서 다운로드를 클릭합니다.
쉘 변수의 풀 시크릿을 사용하려면 다음 명령을 실행합니다.
$ export PULL_SECRET=$(cat ~/Downloads/pull-secret.txt | jq -R .)
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" } ')"
4.4. 새 클러스터 등록
API에 새 클러스터 정의를 등록하려면 /v2/clusters 끝점을 사용합니다. 새 클러스터를 등록하려면 다음 설정이 필요합니다.
-
name
-
openshift-version
-
pull_secret
-
cpu_architecture
새 클러스터를 등록할 때 설정할 수 있는 필드에 대한 자세한 내용은 API 뷰어 의 cluster-create-params
모델을 참조하십시오. olm_operators
필드를 설정할 때 Operator 설치에 대한 자세한 내용은 추가 리소스 를 참조하십시오.
클러스터 정의를 생성한 후 클러스터 정의를 수정하고 추가 설정에 대한 값을 제공할 수 있습니다. 클러스터 수정에 대한 자세한 내용은 추가 리소스 를 참조하십시오.
사전 요구 사항
-
유효한
API_TOKEN
을 생성했습니다. 토큰은 15분마다 만료됩니다. - 풀 시크릿을 다운로드했습니다.
-
선택 사항:
$PULL_SECRET
변수에 풀 시크릿을 할당했습니다.
절차
API 토큰을 새로 고칩니다.
$ source refresh-token
새 클러스터를 등록합니다.
선택 사항: 요청에 풀 시크릿 파일을 슬리핑하여 새 클러스터를 등록할 수 있습니다.
$ 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'
선택 사항: 새 클러스터를 JSON 파일에 작성한 다음 요청에서 참조하여 새 클러스터를 등록할 수 있습니다.
cat << EOF > cluster.json { "name": "testcluster", "openshift_version": "4.11", "high_availability_mode": "<cluster_type>", "base_dns_domain": "example.com", "pull_secret": $PULL_SECRET } EOF
$ curl -s -X POST "https://api.openshift.com/api/assisted-install/v2/clusters" \ -d @./cluster.json \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $API_TOKEN" \ | jq '.id'
반환된
cluster_id
를CLUSTER_ID
변수에 할당하고 이를 내보냅니다.$ export CLUSTER_ID=<cluster_id>
참고터미널 세션을 닫는 경우
CLUSTER_ID
변수를 새 터미널 세션에서 다시 내보내야 합니다.새 클러스터의 상태를 확인합니다.
$ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $API_TOKEN" \ | jq
새 클러스터 정의를 등록한 후 클러스터의 인프라 환경을 생성합니다.
인프라 환경을 생성할 때까지 지원 설치 관리자 사용자 인터페이스에서 클러스터 구성 설정을 확인할 수 없습니다.
추가 리소스
4.5. 클러스터 수정
API를 사용하여 클러스터 정의를 수정하려면 /v2/clusters/{cluster_id} 끝점을 사용합니다. 클러스터 리소스 수정은 네트워크 유형 변경 또는 사용자 관리 네트워킹 활성화와 같은 설정을 추가하는 일반적인 작업입니다. 클러스터 정의를 수정할 때 설정할 수 있는 필드에 대한 자세한 내용은 API 뷰어 의 v2-cluster-update-params
모델을 참조하십시오. 클러스터 내에서 Operator 정의에 대한 자세한 내용은 Operator 설치 및 수정 을 참조하십시오.
사전 요구 사항
- 새 클러스터 리소스가 생성되어 있습니다.
절차
API 토큰을 새로 고칩니다.
$ source refresh-token
클러스터를 수정합니다. 예를 들면 다음과 같습니다.
$ curl https://api.openshift.com/api/assisted-install/v2/clusters/${CLUSTER_ID} \ -X PATCH \ -H "Authorization: Bearer ${API_TOKEN}" \ -H "Content-Type: application/json" \ -d ' { "ssh_public_key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDZrD4LMkAEeoU2vShhF8VM+cCZtVRgB7tqtsMxms2q3TOJZAgfuqReKYWm+OLOZTD+DO3Hn1pah/mU3u7uJfTUg4wEX0Le8zBu9xJVym0BVmSFkzHfIJVTn6SfZ81NqcalisGWkpmkKXVCdnVAX6RsbHfpGKk9YPQarmRCn5KzkelJK4hrSWpBPjdzkFXaIpf64JBZtew9XVYA3QeXkIcFuq7NBuUH9BonroPEmIXNOa41PUP1IWq3mERNgzHZiuU8Ks/pFuU5HCMvv4qbTOIhiig7vidImHPpqYT/TCkuVi5w0ZZgkkBeLnxWxH0ldrfzgFBYAxnpTU8Ih/4VhG538Ix1hxPaM6cXds2ic71mBbtbSrk+zjtNPaeYk1O7UpcCw4jjHspU/rVV/DY51D5gSiiuaFPBMucnYPgUxy4FMBFfGrmGLIzTKiLzcz0DiSz1jBeTQOX++1nz+KDLBD8CPdi5k4dq7lLkapRk85qdEvgaG5RlHMSPSS3wDrQ51fD8= user@hostname" } ' | jq
4.6. 새 인프라 환경 등록
지원 설치 관리자 API에 새 클러스터 정의를 등록한 후 v2/infra-envs 끝점을 사용하여 인프라 환경을 생성합니다. 새 인프라 환경을 등록하려면 다음 설정이 필요합니다.
-
name
-
pull_secret
-
cpu_architecture
새 인프라 환경을 등록할 때 설정할 수 있는 필드에 대한 자세한 내용은 API 뷰어 의 infra-env-create-params
모델을 참조하십시오. 인프라 환경을 생성한 후 수정할 수 있습니다. 새 인프라 환경을 생성할 때 cluster_id
를 포함하는 것이 좋습니다. cluster_id
는 인프라 환경을 클러스터 정의와 연결합니다. 새 인프라 환경을 생성할 때 지원 설치 관리자도 검색 ISO를 생성합니다.
사전 요구 사항
-
유효한
API_TOKEN
을 생성했습니다. 토큰은 15분마다 만료됩니다. - 풀 시크릿을 다운로드했습니다.
-
선택 사항: 새 클러스터 정의를 등록하고
cluster_id
를 내보냈습니다.
절차
API 토큰을 새로 고칩니다.
$ source refresh-token
새 인프라 환경을 등록합니다. 클러스터 이름을 포함한 이름을 지정합니다. 이 예제에서는 인프라 환경을 클러스터 리소스와 연결하는 클러스터 ID를 제공합니다. 다음 예제에서는
image_type
을 지정합니다.full-iso
또는minimal-iso
를 지정할 수 있습니다. 기본값은minimal-iso
입니다.선택 사항: 요청에 풀 시크릿 파일을 슬루핑하여 새 인프라 환경을 등록할 수 있습니다.
$ 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
선택 사항: JSON 파일에 구성을 작성한 다음 요청에서 참조하여 새 인프라 환경을 등록할 수 있습니다.
$ cat << EOF > infra-envs.json { "name": "testcluster-infra-env", "image_type": "full-iso", "cluster_id": "$CLUSTER_ID", "pull_secret": $PULL_SECRET } EOF
$ curl -s -X POST "https://api.openshift.com/api/assisted-install/v2/infra-envs" \ -d @./infra-envs.json \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $API_TOKEN" \ | jq '.id'
반환된 ID를
INFRA_ENV_ID
변수에 할당하고 이를 내보냅니다.$ export INFRA_ENV_ID=<id>
인프라 환경을 생성하여 cluster_id
를 통해 클러스터 정의에 연결하면 지원 설치 관리자 웹 사용자 인터페이스에서 클러스터 설정을 확인할 수 있습니다. 터미널 세션을 닫는 경우 새 터미널 세션에서 ID 를
다시 내보내야 합니다.
4.7. 인프라 환경 수정
/v2/infra-envs/{infra_env_id} 끝점을 사용하여 인프라 환경을 수정할 수 있습니다. 인프라 환경 수정은 네트워킹, SSH 키 또는 Ignition 구성 덮어쓰기와 같은 설정을 추가하는 일반적인 작업입니다.
인프라 환경을 수정할 때 설정할 수 있는 필드에 대한 자세한 내용은 API 뷰어 의 infra-env-update-params
모델을 참조하십시오. 새로운 인프라 환경을 수정할 때 지원 설치 관리자도 검색 ISO를 다시 생성합니다.
사전 요구 사항
- 새 인프라 환경을 생성했습니다.
절차
API 토큰을 새로 고칩니다.
$ source refresh-token
인프라 환경을 변경합니다.
$ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID} \ -X PATCH \ -H "Authorization: Bearer ${API_TOKEN}" \ -H "Content-Type: application/json" \ -d "$(jq --null-input \ --slurpfile pull_secret ~/Downloads/pull-secret.txt ' { "image_type":"minimal-iso", "pull_secret": $pull_secret[0] | tojson } ')" | jq
4.8. 호스트 추가
클러스터 리소스 및 인프라 환경을 구성한 후 검색 ISO 이미지를 다운로드합니다. 다음 두 가지 이미지에서 선택할 수 있습니다.
- 전체 ISO 이미지: 부팅이 자체적으로 포함되어야 할 때 전체 ISO 이미지를 사용합니다. 이미지에는 지원 설치 관리자 에이전트를 부팅하고 시작하는 데 필요한 모든 항목이 포함되어 있습니다. ISO 이미지의 크기는 약 1GB입니다.
- 최소 ISO 이미지: 가상 미디어 연결을 통한 대역폭이 제한된 경우 최소 ISO 이미지를 사용합니다. 이 설정은 기본 설정입니다. 이미지에는 네트워킹으로 호스트를 부팅하는 데 필요한 항목만 포함됩니다. 대부분의 콘텐츠는 부팅 시 다운로드됩니다. ISO 이미지의 크기는 약 100MB입니다.
- iPXE: 's390x' 아키텍처에 권장되는 방법입니다.
두 이미지 모두 동일한 설치 절차를 수행합니다. 이미지 유형을 변경하려면 이 절차를 수행하기 전에 인프라 환경에서 image_type
설정을 변경합니다.
사전 요구 사항
- 클러스터를 생성했습니다.
- 인프라 환경을 생성했습니다.
- 구성을 완료했습니다.
- 클러스터 호스트가 프록시를 사용해야 하는 방화벽 뒤에 있는 경우 프록시 서버의 HTTP 및 HTTPS URL에 대한 사용자 이름, 암호, IP 주소 및 포트를 구성한 것입니다.
-
이미지 유형을 선택했거나 기본값
minimal-iso
를 사용합니다.
절차
- 필요한 경우 검색 이미지를 구성합니다. iPXE를 사용하여 호스트 부팅을참조하십시오.
API 토큰을 새로 고칩니다.
$ source refresh-token
다운로드 URL을 가져옵니다.
$ curl -H "Authorization: Bearer ${API_TOKEN}" \ https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/downloads/image-url
검색 이미지를 다운로드합니다.
$ wget -O discovery.iso '<url>'
&
lt;url&
gt;을 이전 단계의 다운로드 URL로 바꿉니다.- 검색 이미지를 사용하여 호스트를 부팅합니다. 플랫폼에 설치하고 플랫폼과 통합하려는 경우 자세한 내용은 다음 추가 리소스를 참조하십시오.
- 호스트에 역할을 할당합니다.
4.9. 호스트 수정
호스트를 추가한 후 필요에 따라 호스트를 수정합니다. 가장 일반적인 수정 사항은 host_name
및 host_role
매개 변수입니다.
/v2/infra-envs/{infra_env_id}/hosts/{host_id} 엔드포인트를 사용하여 호스트를 수정할 수 있습니다. 호스트를 수정할 때 설정할 수 있는 필드에 대한 자세한 내용은 API 뷰어 의 host-update-params
모델을 참조하십시오.
호스트는 다음 두 가지 역할 중 하나일 수 있습니다.
-
master
:마스터
역할이 있는 호스트가 컨트롤 플레인 호스트로 작동합니다. -
worker
:작업자
역할이 있는 호스트가 작업자 호스트로 작동합니다.
기본적으로 지원 설치 관리자는 호스트를 자동 할당
으로 설정합니다. 즉, 설치 프로그램이 호스트가 마스터
또는 작업자
역할인지 여부를 자동으로 결정합니다. 다음 절차에 따라 호스트의 역할을 설정합니다.
사전 요구 사항
- 클러스터에 호스트를 추가했습니다.
절차
API 토큰을 새로 고칩니다.
$ source refresh-token
호스트 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'
z/VM이 있는 IBM Z(s390x)에 설치하려면 추가 커널 인수가 필요합니다.
일치하는 노드의 hostID를 검색하려면 다음 명령을 실행합니다.
curl https://api.openshift.com/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts -H "Authorization: Bearer ${API_TOKEN}" | jq '.[]|[.id,.requested_hostname] | join("|")'
필요한 커널 인수를 지정하려면 다음 명령을 실행합니다.
curl https://api.stage.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/$1/installer-args \ -X PATCH \ -H "Authorization: Bearer ${API_TOKEN}" \ -H "Content-Type: application/json" \ -d ' { "args": [ "--append-karg", "rd.neednet=1", "--append-karg", "ip=10.14.6.3::10.14.6.1:255.255.255.0:master-0.boea3e06.lnxero1.boe:encbdd0:none", "--append-karg", "nameserver=10.14.6.1", "--append-karg", "ip=[fd00::3]::[fd00::1]:64::encbdd0:none", "--append-karg", "nameserver=[fd00::1]", "--append-karg", "zfcp.allow_lun_scan=0", "--append-karg", "rd.znet=qeth,0.0.bdd0,0.0.bdd1,0.0.bdd2,layer2=1", "--append-karg", "rd.dasd=0.0.5235" ] } ' | jq
참고각 호스트에는 특정 커널 인수가 있을 수 있습니다.
출력 예
[ "1062663e-7989-8b2d-7fbb-e6f4d5bb28e5" ]
호스트를 수정합니다.
$ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/<host_id> \ 1 -X PATCH \ -H "Authorization: Bearer ${API_TOKEN}" \ -H "Content-Type: application/json" \ -d ' { "host_role":"worker" "host_name" : "worker-1" } ' | jq
- 1
- &
lt;host_id&
gt;를 호스트 ID로 바꿉니다.
4.10. 설치 전 검증
지원 설치 관리자는 복잡한 설치 후 문제 해결을 제거하여 클러스터가 설치 전에 사전 요구 사항을 충족하는지 확인하므로 시간과 노력을 많이 절약할 수 있습니다. 클러스터를 설치하기 전에 클러스터와 각 호스트가 설치 사전 검증을 통과했는지 확인합니다.
추가 리소스
4.11. 클러스터 설치
클러스터가 과거의 검증을 호스팅하면 클러스터를 설치할 수 있습니다.
사전 요구 사항
- 클러스터 및 인프라 환경을 생성했습니다.
- 인프라 환경에 호스트를 추가했습니다.
- 호스트가 검증을 통과했습니다.
절차
API 토큰을 새로 고칩니다.
$ source refresh-token
클러스터를 설치합니다.
$ curl -H "Authorization: Bearer $API_TOKEN" \ -X POST \ https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/actions/install | jq
- 설치 후 플랫폼 통합 단계를 완료합니다.
추가 리소스
5장. 선택 사항: 디스크 암호화 활성화
TPM v2 또는 Tang 암호화 모드를 사용하여 설치 디스크의 암호화를 활성화할 수 있습니다.
경우에 따라 베어 메탈 호스트의 펌웨어에서 TPM 디스크 암호화를 활성화한 다음 지원 설치 프로그램으로 생성하는 ISO에서 부팅하면 클러스터 배포가 중단될 수 있습니다. 이는 호스트에 이전 설치의 TPM 암호화 키가 남아 있는 경우 발생할 수 있습니다. 자세한 내용은 BZ#2011634 에서 참조하십시오. 이 문제가 발생하면 Red Hat 지원에 문의하십시오.
5.1. TPM v2 암호화 활성화
사전 요구 사항
-
각 호스트의 BIOS에서 TPM v2 암호화가 활성화되어 있는지 확인합니다. 대부분의 Dell 시스템에는 이 작업이 필요합니다. 컴퓨터 설명서를 확인하십시오. 지원 설치 프로그램은 또한 TPM이 펌웨어에서 활성화되어 있는지 확인합니다. 자세한 내용은 지원 설치 관리자 API 의
디스크
등록 모델을 참조하십시오.
TPM v2 암호화 칩이 각 노드에 설치되어 있고 펌웨어에서 활성화되어 있는지 확인합니다.
절차
- 선택 사항: UI를 사용하여 사용자 인터페이스 마법사의 클러스터 세부 정보 단계에서 컨트롤 플레인 노드, 작업자 또는 둘 다에서 TPM v2 암호화를 사용하도록 선택합니다.
선택 사항: API를 사용하여 "호스트 수정" 절차를 따르십시오.
disk_encryption.enable_on
설정을모든
,masters
또는workers
로 설정합니다.disk_encryption.mode
설정을tpmv2
로 설정합니다.API 토큰을 새로 고칩니다.
$ source refresh-token
TPM v2 암호화를 활성화합니다.
$ curl https://api.openshift.com/api/assisted-install/v2/clusters/${CLUSTER_ID} \ -X PATCH \ -H "Authorization: Bearer ${API_TOKEN}" \ -H "Content-Type: application/json" \ -d ' { "disk_encryption": { "enable_on": "none", "mode": "tpmv2" } } ' | jq
enable_on
의 유효한 설정은모두
,master
,worker
,none
입니다.
5.2. Tang 암호화 활성화
사전 요구 사항
- Tang 교환 키의 지문을 생성하는 데 사용할 수 있는 RHEL (Red Hat Enterprise Linux) 8 시스템에 액세스할 수 있습니다.
절차
- Tang 서버를 설정하거나 기존 서버에 액세스합니다. 자세한 내용은 Network-bound disk encryption에서 참조하십시오. 여러 Tang 서버를 설정할 수 있지만 지원 설치 프로그램은 설치 중에 모든 서버에 연결할 수 있어야 합니다.
Tang 서버에서
tang-show-keys
를 사용하여 Tang 서버의 지문을 검색합니다.$ tang-show-keys <port>
선택 사항: &
lt;port&
gt;를 포트 번호로 바꿉니다. 기본 포트 번호는80
입니다.지문 예
1gYTN_LpU9ZMB35yn5IbADY5OQ0
선택 사항:
jose
를 사용하여 Tang 서버의 지문을 검색합니다.jose
가 Tang 서버에 설치되어 있는지 확인합니다.$ sudo dnf install jose
Tang 서버에서
jose
를 사용하여 지문을 검색합니다.$ sudo jose jwk thp -i /var/db/tang/<public_key>.jwk
&
lt;public_key
>를 Tang 서버의 공개 교환 키로 바꿉니다.지문 예
1gYTN_LpU9ZMB35yn5IbADY5OQ0
- 선택 사항: 사용자 인터페이스 마법사의 클러스터 세부 정보 단계에서 컨트롤 플레인 노드, 작업자 또는 둘 다에서 Tang 암호화를 사용하도록 선택합니다. Tang 서버의 URL과 지문을 입력해야 합니다.
선택 사항: API를 사용하여 "호스트 수정" 절차를 따르십시오.
API 토큰을 새로 고칩니다.
$ source refresh-token
disk_encryption.enable_on
설정을모든
,masters
또는workers
로 설정합니다.disk_encryption.mode
설정을 10.0.0.1으로설정합니다
. 하나 이상의 Tang 서버에 대한 URL 및 지문 세부 정보를 제공하도록disk_encyrption.tang_servers
를 설정합니다.$ curl https://api.openshift.com/api/assisted-install/v2/clusters/${CLUSTER_ID} \ -X PATCH \ -H "Authorization: Bearer ${API_TOKEN}" \ -H "Content-Type: application/json" \ -d ' { "disk_encryption": { "enable_on": "all", "mode": "tang", "tang_servers": "[{\"url\":\"http://tang.example.com:7500\",\"thumbprint\":\"PLjNyRdGw03zlRoGjQYMahSZGu9\"},{\"url\":\"http://tang2.example.com:7500\",\"thumbprint\":\"XYjNyRdGw03zlRoGjQYMahSZGu3\"}]" } } ' | jq
enable_on
의 유효한 설정은모두
,master
,worker
,none
입니다. CloudEvent_servers
값 내에서 오브젝트 내에서 따옴표를 주석 처리합니다.
5.3. 추가 리소스
6장. 선택사항: Operator 설치 및 수정
지원 설치 관리자는 UI 또는 API에서 기본 구성으로 선택한 Operator를 설치할 수 있습니다. 고급 옵션이 필요한 경우 클러스터를 설치한 후 원하는 Operator를 설치합니다.
지원 설치 관리자는 선택한 Operator의 설치를 클러스터 설치의 일부로 모니터링하고 상태를 보고합니다. 설치 중에 하나 이상의 Operator에 오류가 발생하면 지원 설치 관리자에서 하나 이상의 Operator를 설치하지 못한 경고와 함께 클러스터 설치가 완료되었다고 보고합니다.
지원 설치 관리자 UI 또는 API를 사용하여 클러스터 정의를 설치하거나 수정할 때 설정할 수 있는 Operator의 아래 섹션을 참조하십시오. OpenShift Container Platform 클러스터 설치에 대한 전체 지침은 각각 지원 설치 관리자 UI 로 설치 또는 지원 설치 설치에서 참조하십시오.
6.1. Operator 설치
지원 설치 관리자 UI를 사용하여ng Operator를 설치할 때 마법사의 Operator 페이지에서 Operator 를 선택합니다. 지원 설치 관리자 API를 사용하여 Operator를 설치할 때 /v2/clusters 끝점에서 POST 메서드를 사용합니다.
6.1.1. OpenShift Virtualization 설치
클러스터를 구성할 때 OpenShift Virtualization 을 활성화할 수 있습니다.
현재 OpenShift Virtualization은 IBM zSystems 및 IBM Power에서 지원되지 않습니다.
활성화된 경우 지원 설치 관리자:
- 환경이 아래에 설명된 사전 요구 사항을 충족하는지 확인합니다.
다음과 같이 가상 머신 스토리지를 구성합니다.
- 단일 노드 OpenShift 클러스터 버전 4.10 이상의 경우 지원 설치 프로그램은 hostpath 프로비전 프로그램을 구성합니다.
- 이전 버전의 단일 노드 OpenShift 클러스터의 경우 지원 설치 프로그램은 Local Storage Operator 를 구성합니다.
- 다중 노드 클러스터의 경우 지원 설치 관리자는 OpenShift Data Foundation을 구성합니다.
사전 요구 사항
- RHEL (Red Hat Enterprise Linux) 8에서 지원
- Intel 64 또는 AMD64 CPU 확장 지원
- Intel Virtualization Technology 또는 AMD-V 하드웨어 가상화 확장 가능
- NX (no execute) 플래그 활성화
절차
지원 설치 관리자 UI를 사용하는 경우:
- 마법사의 Operator 단계에서 OpenShift Virtualization 설치 확인란을 활성화합니다.
지원 설치 관리자 API를 사용하는 경우:
새 클러스터를 등록할 때
"olm_operators: [{"name": "cnv"}]"
문을 추가합니다.참고CNV는 컨테이너 네이티브 가상화를 나타냅니다.
예를 들면 다음과 같습니다.
$ curl -s -X POST https://api.openshift.com/api/assisted-install/v2/clusters \ -H "Authorization: Bearer ${API_TOKEN}" \ -H "Content-Type: application/json" \ -d "$(jq --null-input \ --slurpfile pull_secret ~/Downloads/pull-secret.txt ' { "name": "testcluster", "openshift_version": "4.11", "cpu_architecture" : "x86_64", "base_dns_domain": "example.com", "olm_operators: [{"name": "cnv"}]" "pull_secret": $pull_secret[0] | tojson } ')" | jq '.id'
추가 리소스
- OpenShift Virtualization용 클러스터 준비에 대한 자세한 내용은 OpenShift 설명서 를 참조하십시오.
6.1.2. MCCE(Multicluster Engine) 설치
클러스터를 구성할 때 MCCE (Multicluster Engine) Operator를 활성화할 수 있습니다. MC(Multicluster Engine) Operator를 사용하면 현재 설치 중인 클러스터에서 추가 클러스터를 설치할 수 있습니다.
사전 요구 사항
- OpenShift 버전 4.10 이상
- 멀티 노드 OpenShift 클러스터에 4개의 CPU 코어 및 16GB의 RAM이 추가로 제공됩니다.
- 단일 노드 OpenShift 클러스터의 경우 추가 8 CPU 코어 및 32GB RAM
스토리지 고려 사항
설치하기 전에 멀티 클러스터 엔진에서 클러스터를 관리하는 데 필요한 스토리지를 고려해야 합니다. 스토리지 자동화를 위해 다음 시나리오 중 하나를 선택할 수 있습니다.
- 다중 노드 클러스터에 ODF(OpenShift Data Foundation)를 설치합니다. ODF는 클러스터에 권장되는 스토리지이지만 추가 서브스크립션이 필요합니다. 자세한 내용은 이 장의 OpenShift Data Foundation 설치를 참조하십시오.
- 단일 노드 OpenShift(SNO) 클러스터에 LVMS(Logical Volume Management Storage)를 설치합니다.
- 스토리지를 구성하지 않고 다중 노드 클러스터에 다중 클러스터 엔진을 설치합니다. 그런 다음 선택한 스토리지를 구성하고 설치 후 CIM(Central Infrastructure Management) 서비스를 활성화합니다. 자세한 내용은 이 장의 추가 리소스 를 참조하십시오.
절차
지원 설치 관리자 UI를 사용하는 경우:
- 마법사의 Operator 단계에서 다중 클러스터 엔진 설치 확인란을 활성화합니다.
지원 설치 관리자 API를 사용하는 경우:
새 클러스터를 등록할 때
"olm_operators: [{"name": "mce"}]"
문을 사용합니다. 예를 들면 다음과 같습니다.$ curl -s -X POST https://api.openshift.com/api/assisted-install/v2/clusters \ -H "Authorization: Bearer ${API_TOKEN}" \ -H "Content-Type: application/json" \ -d "$(jq --null-input \ --slurpfile pull_secret ~/Downloads/pull-secret.txt ' { "name": "testcluster", "openshift_version": "4.11", "cpu_architecture" : "x86_64" "base_dns_domain": "example.com", "olm_operators: [{"name": "mce"}]", "pull_secret": $pull_secret[0] | tojson } ')" | jq '.id'
설치 후 단계
- 지원 설치 관리자 기술을 다중 클러스터 엔진과 함께 사용하려면 중앙 인프라 관리 서비스를 활성화합니다. 자세한 내용은 Central Infrastructure Management 서비스 활성화를 참조하십시오.
- 호스팅된 컨트롤 플레인을 사용하여 OpenShift Container Platform 클러스터를 배포하려면 호스팅된 컨트롤 플레인을 구성합니다. 자세한 내용은 호스팅 컨트롤 플레인을 참조하십시오.
추가 리소스
- MC(Multicluster Engine) Operator와 관련된 고급 클러스터 관리 설명서는 Red Hat Advanced Cluster Mangement for Kubernetes를 참조하십시오.
- MC(Multicluster Engine) Operator와 관련된 OpenShift Container Platform 설명서는 Kubernetes Operator용 Multicluster Engine을 참조하십시오.
6.1.3. OpenShift Data Foundation 설치
클러스터를 구성할 때 OpenShift Data Foundation 을 활성화할 수 있습니다. 활성화된 경우 지원 설치 관리자:
- 환경이 아래에 설명된 사전 요구 사항을 충족하는지 확인합니다. 디스크 장치가 다시 포맷되었는지 확인하지 않으므로 시작하기 전에 확인해야 합니다.
- 사용 가능한 모든 디스크를 사용하도록 스토리지를 구성합니다.
OpenShift Data Foundation을 활성화하면 지원 설치 프로그램은 OpenShift Data Foundation과 함께 사용할 수 있는 모든 디스크를 지정하는 StorageCluster
리소스를 생성합니다. 다른 구성이 필요한 경우 클러스터를 설치한 후 구성을 수정하거나 클러스터를 설치한 후 Operator를 설치합니다.
사전 요구 사항
- 클러스터는 3노드 OpenShift 클러스터이거나 작업자 노드가 3개 이상 있습니다.
- 각 호스트에는 최소 25GB의 설치 이외의 디스크가 하나 이상 있습니다.
- 사용하는 디스크 장치는 비어 있어야 합니다. 디스크에는 물리 볼륨(PV), 볼륨 그룹(VG) 또는 논리 볼륨(LV)이 없어야 합니다.
- 각 호스트에는 다른 CPU 요구 사항 외에 표준 클러스터의 경우 3노드 OpenShift 또는 8 CPU 코어에 대해 6개의 CPU 코어가 있습니다.
- 각 호스트에는 다른 RAM 요구 사항 외에 19GiB RAM이 있습니다.
- 각 호스트에는 다른 CPU 및 RAM 요구 사항 외에 스토리지 디스크당 2개의 CPU 코어와 5GiB RAM이 있습니다.
- 각 호스트에 컨트롤 플레인 또는 작업자 역할을 할당했습니다(자동 할당되지 않음).
절차
지원 설치 관리자 UI를 사용하는 경우:
- 마법사의 Operator 단계에서 OpenShift Data Foundation 설치 확인란을 활성화합니다.
지원 설치 관리자 API를 사용하는 경우:
새 클러스터를 등록할 때
"olm_operators: [{"name": "odf"}]"
문을 추가합니다. 예를 들면 다음과 같습니다.$ curl -s -X POST https://api.openshift.com/api/assisted-install/v2/clusters \ -H "Authorization: Bearer ${API_TOKEN}" \ -H "Content-Type: application/json" \ -d "$(jq --null-input \ --slurpfile pull_secret ~/Downloads/pull-secret.txt ' { "name": "testcluster", "openshift_version": "4.11", "cpu_architecture" : "x86_64", "base_dns_domain": "example.com", "olm_operators: [{"name": "odf"}]", "pull_secret": $pull_secret[0] | tojson } ')" | jq '.id'
추가 리소스
- OpenShift Data Foundation에 대한 자세한 내용은 OpenShift 설명서 를 참조하십시오.
6.1.4. 논리 볼륨 관리자 스토리지 설치
클러스터를 구성할 때 단일 노드 OpenShift 클러스터에서 LVMS(Logical Volume Manager Storage) Operator를 활성화할 수 있습니다. LVMS Operator를 설치하면 로컬 스토리지를 동적으로 프로비저닝할 수 있습니다.
사전 요구 사항
- 버전 4.11 이상으로 설치된 단일 노드 OpenShift 클러스터
- 설치되지 않은 디스크가 하나 이상
- CPU 코어 1개와 400MB의 RAM( 4.13 이전 버전용 1200MB RAM)
절차
지원 설치 관리자 UI를 사용하는 경우:
- 마법사의 Operator 단계에서 Install Logical Volume Manager Storage 확인란을 활성화합니다.
지원 설치 관리자 API를 사용하는 경우:
새 클러스터를 등록할 때
olm_operators: [{"name": "lvm"}]
문을 사용합니다. 예를 들면 다음과 같습니다.$ curl -s -X POST https://api.openshift.com/api/assisted-install/v2/clusters \ -H "Authorization: Bearer ${API_TOKEN}" \ -H "Content-Type: application/json" \ -d "$(jq --null-input \ --slurpfile pull_secret ~/Downloads/pull-secret.txt ' { "name": "testcluster", "openshift_version": "4.14", "cpu_architecture" : "x86_64", "base_dns_domain": "example.com", "olm_operators: [{"name": "lvm"}]" "pull_secret": $pull_secret[0] | tojson } ')" | jq '.id'
추가 리소스
- LVMS와 관련된 OpenShift Container Platform 문서는 LVM 스토리지를 사용하는 영구 스토리지를 참조하십시오.
6.2. Operator 수정
지원 설치 관리자에서는 이전 설치 단계의 일부로 이미 등록된 클러스터 리소스의 Operator를 추가하거나 제거할 수 있습니다. 이는 OpenShift Container Platform 설치를 시작하기 전에만 가능합니다.
정의된 Operator를 수정하려면 다음을 수행합니다.
- 지원 설치 관리자 UI를 사용하는 경우 마법사의 Operator 페이지로 이동하여 선택을 수정합니다. 자세한 내용은 이 섹션에서 Operator 설치를 참조하십시오.
- 지원 설치 프로그램 API를 사용하는 경우 /v2/clusters/{cluster_id} 엔드포인트에 PATCH 방법을 사용하여 필요한 Operator 정의를 설정합니다.
사전 요구 사항
- 새 클러스터 리소스가 생성되어 있습니다.
절차
API 토큰을 새로 고칩니다.
$ source refresh-token
다음과 같이 기존 클러스터를 나열하여
CLUSTER_ID
변수를 식별합니다.$ curl -s https://api.openshift.com/api/assisted-install/v2/clusters -H "Authorization: Bearer ${API_TOKEN}" | jq '[ .[] | { "name": .name, "id": .id } ]'
샘플 출력
[ { "name": "lvmtest", "id": "475358f9-ed3a-442f-ab9e-48fd68bc8188" 1 }, { "name": "mcetest", "id": "b5259f97-be09-430e-b5eb-d78420ee509a" } ]
참고- 1
id
값은 <cluster_id>입니다
.
반환된 <
;cluster_id&
gt;를CLUSTER_ID
변수에 할당하고 내보냅니다.$ export CLUSTER_ID=<cluster_id>
새 Operator로 클러스터를 업데이트합니다.
$ curl https://api.openshift.com/api/assisted-install/v2/clusters/${CLUSTER_ID} \ -X PATCH \ -H "Authorization: Bearer ${API_TOKEN}" \ -H "Content-Type: application/json" \ -d ' { "olm_operators": [{"name": "mce"}, {"name": "cnv"}], 1 } ' | jq '.id'
참고- 1
- Operator가 설치됨을 나타냅니다. 유효한 값에는
mce
,cnv
,lvm
,odf
가 포함됩니다. 이전에 설치한 Operator를 제거하려면 값 목록에서 제외합니다. 이전에 설치한 모든 Operator를 제거하려면"olm_operators": []
를 입력합니다.
샘플 출력
{ <various cluster properties>, "monitored_operators": [ { "cluster_id": "b5259f97-be09-430e-b5eb-d78420ee509a", "name": "console", "operator_type": "builtin", "status_updated_at": "0001-01-01T00:00:00.000Z", "timeout_seconds": 3600 }, { "cluster_id": "b5259f97-be09-430e-b5eb-d78420ee509a", "name": "cvo", "operator_type": "builtin", "status_updated_at": "0001-01-01T00:00:00.000Z", "timeout_seconds": 3600 }, { "cluster_id": "b5259f97-be09-430e-b5eb-d78420ee509a", "name": "mce", "namespace": "multicluster-engine", "operator_type": "olm", "status_updated_at": "0001-01-01T00:00:00.000Z", "subscription_name": "multicluster-engine", "timeout_seconds": 3600 }, { "cluster_id": "b5259f97-be09-430e-b5eb-d78420ee509a", "name": "cnv", "namespace": "openshift-cnv", "operator_type": "olm", "status_updated_at": "0001-01-01T00:00:00.000Z", "subscription_name": "hco-operatorhub", "timeout_seconds": 3600 }, { "cluster_id": "b5259f97-be09-430e-b5eb-d78420ee509a", "name": "lvm", "namespace": "openshift-local-storage", "operator_type": "olm", "status_updated_at": "0001-01-01T00:00:00.000Z", "subscription_name": "local-storage-operator", "timeout_seconds": 4200 } ], <more cluster properties>
참고출력은 새 클러스터 상태에 대한 설명입니다. 출력의
monitored_operators
속성에는 다음 두 가지 유형의 Operator가 포함되어 있습니다.-
"operator_type": "builtin
": 이 유형의 Operator는 OpenShift Container Platform의 통합 부분입니다. -
"operator_type": "olm
": 이 유형의 Operator는 사용자가 수동으로 추가하거나 종속성으로 인해 자동으로 추가됩니다. 이 예제에서는cnv
Operator에 필요하므로lso
Operator가 자동으로 추가되었습니다.
7장. 검색 이미지 구성
지원 설치 관리자는 초기 이미지를 사용하여 OpenShift Container Platform을 설치하기 전에 하드웨어 및 네트워크 검증을 수행하는 에이전트를 실행합니다. Ignition 을 사용하여 검색 이미지를 사용자 지정할 수 있습니다.
검색 이미지에 대한 수정은 시스템에서 유지되지 않습니다.
7.1. Ignition 구성 파일 생성
Ignition은 임시 초기 루트 파일 시스템인 initramfs 의 일부인 낮은 수준의 시스템 구성 유틸리티입니다. Ignition이 첫 번째 부팅에서 실행되면 Ignition 구성 파일에서 구성 데이터를 찾아 switch_root
가 호출되기 전에 호스트에 적용하여 호스트의 루트 파일 시스템을 피벗합니다.
Ignition은 JSON 구성 사양 파일을 사용하여 첫 번째 부팅에서 발생하는 변경 사항 세트를 나타냅니다.
3.2 이상의 Ignition 버전은 지원되지 않으며 오류가 발생합니다.
절차
Ignition 파일을 생성하고 구성 사양 버전을 지정합니다.
$ vim ~/ignition.conf
{ "ignition": { "version": "3.1.0" } }
Ignition 파일에 구성 데이터를 추가합니다. 예를 들어
core
사용자에 암호를 추가합니다.암호 해시를 생성합니다.
$ openssl passwd -6
생성된 암호 해시를
core
사용자에게 추가합니다.{ "ignition": { "version": "3.1.0" }, "passwd": { "users": [ { "name": "core", "passwordHash": "$6$spam$M5LGSMGyVD.9XOboxcwrsnwNdF4irpJdAWy.1Ry55syyUiUssIzIAHaOrUHr2zg6ruD8YNBPW9kW0H8EnKXyc1" } ] } }
Ignition 파일을 저장하고
IGNITION_FILE
변수로 내보냅니다.$ export IGNITION_FILE=~/ignition.conf
7.2. Ignition을 사용하여 검색 이미지 수정
Ignition 구성 파일을 생성한 후에는 지원 설치 관리자 API를 사용하여 인프라 환경에 패치하여 검색 이미지를 수정할 수 있습니다.
사전 요구 사항
- UI를 사용하여 클러스터를 생성한 경우 API 인증을 설정해야 합니다.
-
인프라 환경이 있고 인프라 환경 ID를
INFRA_ENV_ID
변수로 내보낸 것입니다. -
유효한 Ignition 파일이 있고 파일 이름을
$IGNITION_FILE
로 내보냈습니다.
절차
ignition_config_override
JSON 오브젝트를 생성하고 파일로 리디렉션합니다.$ jq -n \ --arg IGNITION "$(jq -c . $IGNITION_FILE)" \ '{ignition_config_override: $IGNITION}' \ > discovery_ignition.json
API 토큰을 새로 고칩니다.
$ source refresh-token
인프라 환경을 패치합니다.
$ 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 파일을 참조합니다.- 업데이트된 검색 이미지를 다운로드합니다.
8장. 검색 이미지를 사용하여 호스트 부팅
지원 설치 관리자는 초기 이미지를 사용하여 OpenShift Container Platform을 설치하기 전에 하드웨어 및 네트워크 검증을 수행하는 에이전트를 실행합니다. 다음 세 가지 방법을 사용하여 검색 이미지로 호스트를 부팅할 수 있습니다.
- USB 드라이브
- RedFish 가상 미디어
- iPXE
8.1. USB 드라이브에서 ISO 이미지 생성
검색 ISO 이미지가 포함된 USB 드라이브를 사용하여 지원 설치 관리자 에이전트를 설치할 수 있습니다. USB 드라이브로 호스트를 시작하면 소프트웨어 설치를 위한 호스트가 준비됩니다.
절차
- 관리 호스트에서 USB 드라이브를 USB 포트에 삽입합니다.
ISO 이미지를 USB 드라이브에 복사합니다. 예를 들면 다음과 같습니다.
# dd if=<path_to_iso> of=<path_to_usb> status=progress
다음과 같습니다.
- <path_to_iso>
-
다운로드한 검색 ISO 파일의 상대 경로입니다(예:
discovery.iso
). - <path_to_usb>
연결된 USB 드라이브의 위치입니다(예:
/dev/sdb
).ISO를 USB 드라이브에 복사한 후 USB 드라이브를 사용하여 클러스터 호스트에 지원 설치 프로그램 에이전트를 설치할 수 있습니다.
8.2. USB 드라이브 부팅
부팅 가능한 USB 드라이브를 사용하여 지원 설치 관리자에 노드를 등록하려면 다음 절차를 사용하십시오.
절차
- RHCOS 검색 ISO USB 드라이브를 대상 호스트에 삽입합니다.
- 연결된 검색 ISO에서 부팅한 다음 서버를 재부팅하도록 서버 펌웨어 설정에서 부팅 순서를 구성합니다.
호스트가 부팅될 때까지 기다립니다.
- UI 설치의 경우 관리 호스트에서 브라우저로 돌아갑니다. 검색된 호스트 목록에 호스트가 표시될 때까지 기다립니다.
API 설치의 경우 토큰을 새로 고치고 활성화된 호스트 수를 확인하고 호스트 ID를 수집합니다.
$ source refresh-token
$ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID" \ --header "Content-Type: application/json" \ -H "Authorization: Bearer $API_TOKEN" \ | jq '.enabled_host_count'
$ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID" \ --header "Content-Type: application/json" \ -H "Authorization: Bearer $API_TOKEN" \ | jq '.host_networks[].host_ids'
출력 예
[ "1062663e-7989-8b2d-7fbb-e6f4d5bb28e5" ]
8.3. Redfish API를 사용하여 HTTP 호스팅 ISO 이미지에서 부팅
Redfish BMC(Baseboard Management Controller) API를 사용하여 설치한 ISO를 사용하여 네트워크에서 호스트를 프로비저닝할 수 있습니다.
사전 요구 사항
- 설치 RHCOS(Red Hat Enterprise Linux CoreOS) ISO를 다운로드합니다.
절차
- ISO 파일을 네트워크에서 액세스할 수 있는 HTTP 서버에 복사합니다.
호스트된 ISO 파일에서 호스트를 부팅합니다. 예를 들면 다음과 같습니다.
다음 명령을 실행하여 호스팅된 ISO를
VirtualMedia
부팅 미디어로 설정하려면 redfish API를 호출합니다.$ curl -k -u <bmc_username>:<bmc_password> \ -d '{"Image":"<hosted_iso_file>", "Inserted": true}' \ -H "Content-Type: application/json" \ -X POST <host_bmc_address>/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia
다음과 같습니다.
- <bmc_username>:<bmc_password>
- 는 대상 호스트 BMC의 사용자 이름 및 암호입니다.
- <hosted_iso_file>
-
호스트 설치 ISO의 URL입니다(예:
http://webserver.example.com/rhcos-live-minimal.iso
). 대상 호스트 시스템에서 ISO에 액세스할 수 있어야 합니다. - <host_bmc_address>
- 대상 호스트 시스템의 BMC IP 주소입니다.
다음 명령을 실행하여
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
호스트를 재부팅합니다.
$ 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
선택 사항: 호스트의 전원이 꺼지면
{"ResetType": "On"}
스위치를 사용하여 부팅할 수 있습니다. 다음 명령을 실행합니다.$ curl -k -u <bmc_username>:<bmc_password> \ -d '{"ResetType": "On"}' -H 'Content-type: application/json' \ -X POST <host_bmc_address>/redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset
8.4. iPXE를 사용하여 호스트 부팅
지원 설치 프로그램은 인프라 환경에 대한 검색 이미지를 부팅하는 데 필요한 모든 아티팩트를 포함하는 iPXE 스크립트를 제공합니다. iPXE의 현재 HTTPS 구현의 제한으로 인해 필요한 아티팩트를 다운로드하여 HTTP 서버에 노출하는 것이 좋습니다. 현재 iPXE가 HTTPS 프로토콜을 지원하더라도 지원되는 알고리즘은 오래되어 권장되지 않습니다.
지원되는 암호화의 전체 목록은 https://ipxe.org/crypto 에 있습니다.
사전 요구 사항
- API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.
-
쉘에서
$INFRA_ENV_ID
로 내보낸 인프라 환경 ID가 있어야 합니다. -
API에 액세스할 때 사용할 자격 증명이 있고 쉘에서
$API_TOKEN
으로 토큰을 내보냈습니다. - 이미지를 호스팅할 HTTP 서버가 있습니다.
UI를 통해 구성할 때 $INFRA_ENV_ID
및 $API_TOKEN
변수가 이미 제공됩니다.
IBM Power는 PXE만 지원합니다. 필요한 PXE만 지원합니다. /var/lib/tftpboot
에 grub2 를 설치했습니다. PXE용 DHCP 및 TFTP를 설치했습니다.
절차
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
ipxe-script
에서 URL을 추출하여 필요한 아티팩트를 다운로드합니다.초기 RAM 디스크를 다운로드합니다.
$ awk '/^initrd /{print $NF}' ipxe-script | curl -o initrd.img
Linux 커널을 다운로드합니다.
$ awk '/^kernel /{print $2}' ipxe-script | curl -o kernel
루트 파일 시스템을 다운로드합니다.
$ grep ^kernel ipxe-script | xargs -n1| grep ^coreos.live.rootfs_url | cut -d = -f 2- | curl -o rootfs.img
로컬 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
선택 사항: 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이 첫 번째 부팅 시 재부팅되지 않으므로 수동으로 시작해야 합니다.
선택 사항: IBM Power에 설치할 때 다음과 같이 intramfs, kernel 및 root를 다운로드해야 합니다.
- initrd.img 및 kernel.img를 PXE 디렉터리 '/var/lib/tftpboot/rhcos'로 복사합니다.
- rootfs.img를 HTTPD 디렉터리 '/var/www/html/install '에 복사합니다.
'/var/lib/tftpboot/boot/grub2/grub.cfg ':
if [ ${net_default_mac} == fa:1d:67:35:13:20 ]; then default=0 fallback=1 timeout=1 menuentry "CoreOS (BIOS)" { echo "Loading kernel" linux "/rhcos/kernel.img" ip=dhcp rd.neednet=1 ignition.platform.id=metal ignition.firstboot coreos.live.rootfs_url=http://9.114.98.8:8000/install/rootfs.img echo "Loading initrd" initrd "/rhcos/initrd.img" } fi
9장. 호스트에 역할 할당
검색된 호스트에 역할을 할당할 수 있습니다. 이러한 역할은 클러스터 내에서 호스트의 기능을 정의합니다. 역할은 표준 Kubernetes 유형( 컨트롤 플레인(마스터) 또는 작업자 ) 중 하나일 수 있습니다.
호스트는 선택한 역할에 대한 최소 요구사항을 충족해야 합니다. 이 문서의 사전 요구 사항 섹션을 참조하거나 사전 진행 요구 사항 API를 사용하여 하드웨어 요구 사항을 확인할 수 있습니다.
역할을 선택하지 않으면 시스템에서 사용자를 위한 역할을 선택합니다. 설치를 시작하기 전에 언제든지 역할을 변경할 수 있습니다.
9.1. UI를 사용하여 역할 선택
호스트가 검색을 완료한 후 역할을 선택할 수 있습니다.
절차
- Host Discovery (호스트 검색) 탭으로 이동하여 Host Inventory (호스트 인벤토리) 테이블까지 아래로 스크롤합니다.
필요한 호스트의 자동 할당 드롭다운을 선택합니다.
- 컨트롤 플레인 노드를 선택하여 이 호스트에 컨트롤 플레인 역할을 할당합니다.
- 이 호스트에 작업자 역할을 할당하려면 Worker 를 선택합니다.
- 검증 상태를 확인합니다.
9.2. API를 사용하여 역할 선택
/v2/infra-envs/{infra_env_id}/hosts/{host_id} 끝점을 사용하여 호스트의 역할을 선택할 수 있습니다. 호스트는 다음 두 가지 역할 중 하나일 수 있습니다.
-
master
:마스터
역할이 있는 호스트가 컨트롤 플레인 호스트로 작동합니다. -
worker
:작업자
역할이 있는 호스트가 작업자 호스트로 작동합니다.
기본적으로 지원 설치 관리자는 호스트를 자동 할당으로
설정합니다. 즉, 설치 프로그램이 호스트가 마스터
또는 작업자
역할인지 자동으로 결정됩니다. 이 절차를 사용하여 호스트의 역할을 설정합니다.
사전 요구 사항
- 클러스터에 호스트를 추가했습니다.
절차
API 토큰을 새로 고칩니다.
$ source refresh-token
호스트 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" ]
host_role
설정을 수정합니다.$ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/<host_id> \ -X PATCH \ -H "Authorization: Bearer ${API_TOKEN}" \ -H "Content-Type: application/json" \ -d ' { "host_role":"worker" } ' | jq
&
lt;host_id&
gt;를 호스트 ID로 바꿉니다.
9.3. 자동 할당 역할
지원되는 설치 관리자에서 역할을 직접 할당하지 않는 경우 호스트에 대해 자동으로 역할을 선택합니다. 역할 선택 메커니즘은 호스트의 메모리, CPU 및 디스크 공간을 제공합니다. 컨트롤 플레인 노드의 최소 요구사항을 충족하는 3개의 가장 약한 호스트에 컨트롤 플레인 역할을 할당하는 것을 목표로 합니다. 다른 모든 호스트는 기본적으로 작업자 노드로 설정됩니다. 목표는 컨트롤 플레인을 실행하고 실제 워크로드를 실행하기 위해 용량 집약적인 호스트를 예약하기에 충분한 리소스를 제공하는 것입니다.
설치 전 언제든지 자동 할당 결정을 재정의할 수 있습니다.
검증을 통해 자동 선택이 유효한지 확인합니다.
9.4. 추가 리소스
10장. 설치 전 검증
10.1. 사전 설치 검증 정의
지원 설치 프로그램은 클러스터를 최대한 단순하고 효율적으로 오류가 없이 설치하는 것을 목표로 합니다. 지원 설치 관리자는 설치를 시작하기 전에 구성 및 수집된 Telemetry에 대한 검증 검사를 수행합니다.
지원 설치 관리자는 설치 전에 제공한 정보(예: 컨트롤 플레인 토폴로지, 네트워크 구성 및 호스트 이름)를 사용합니다. 또한 설치하려는 호스트에서 실시간 Telemetry를 사용합니다.
호스트가 검색 ISO를 부팅하면 호스트에서 에이전트가 시작됩니다. 에이전트는 호스트 상태에 대한 정보를 지원 설치 관리자에 보냅니다.
지원 설치 관리자는 이 모든 정보를 사용하여 실시간 설치 검증을 계산합니다. 모든 검증은 설치를 차단하거나 차단하지 않는 것입니다.
10.2. 검증 차단 및 차단
검증을 차단하면 설치 진행이 방지됩니다. 즉, 문제를 해결하고 진행하기 전에 차단 검증을 전달해야 합니다.
비 차단 검증은 경고이며 문제가 발생할 수 있는 사항을 알려줍니다.
10.3. 검증 유형
지원 설치 관리자는 다음 두 가지 유형의 검증을 수행합니다.
호스트
호스트 검증은 지정된 호스트의 구성이 설치에 유효한지 확인합니다.
Cluster
클러스터 검증은 전체 클러스터의 구성이 설치에 유효한지 확인합니다.
10.4. 호스트 검증
10.4.1. REST API를 사용하여 호스트 검증 가져오기
웹 기반 UI를 사용하는 경우 이러한 검증의 대부분은 이름으로 표시되지 않습니다. 레이블과 일치하는 검증 목록을 가져오려면 다음 절차를 사용하십시오.
사전 요구 사항
-
jq
유틸리티를 설치했습니다. - API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.
- 검색 ISO로 호스트가 부팅됨
-
CLUSTER_ID
로 쉘에 클러스터 ID를 내보내고 있어야 합니다. -
API에 액세스할 때 사용할 인증 정보가 있고 쉘에서 토큰을
API_TOKEN
로 내보낸 것입니다.
프로시저
API 토큰을 새로 고칩니다.
$ source refresh-token
모든 호스트에 대한 모든 검증을 가져옵니다.
$ curl \ --silent \ --header "Authorization: Bearer $API_TOKEN" \ https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/hosts \ | jq -r .[].validations_info \ | jq 'map(.[])'
모든 호스트에 대해 바이패스(passing)를 가져옵니다.
$ curl \ --silent \ --header "Authorization: Bearer $API_TOKEN" \ https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/hosts \ | jq -r .[].validations_info \ | jq 'map(.[]) | map(select(.status=="failure" or .status=="pending")) | select(length>0)'
10.4.2. 호스트 검증 세부 정보
매개변수 | 검증 유형 | 설명 |
---|---|---|
| 비차단(Non-blocking) | 호스트가 최근에 지원 설치 관리자와 통신했는지 확인합니다. |
| 비차단(Non-blocking) | 지원 설치 프로그램이 호스트에서 인벤토리를 수신했는지 확인합니다. |
| 비차단(Non-blocking) | CPU 코어 수가 최소 요구사항을 충족하는지 확인합니다. |
| 비차단(Non-blocking) | 메모리 양이 최소 요구 사항을 충족하는지 확인합니다. |
| 비차단(Non-blocking) | 사용 가능한 디스크가 자격 기준을 충족하는지 확인합니다. |
| 차단 | 코어 수가 호스트 역할에 대한 최소 요구사항을 충족하는지 확인합니다. |
| 차단 | 메모리 양이 호스트 역할에 대한 최소 요구사항을 충족하는지 확인합니다. |
| 차단 | 2일 차 호스트의 경우 호스트에서 1일 차 클러스터에서 ignition 구성을 다운로드할 수 있는지 확인합니다. |
| 차단 | 대부분의 그룹은 클러스터에서 가장 큰 전체-mesh 연결 그룹이며, 모든 멤버가 다른 모든 멤버와 통신할 수 있습니다. 이 검증은 다중 노드 1 클러스터의 호스트가 대다수 그룹에 있는지 확인합니다. |
| 차단 | 플랫폼이 네트워크 설정에 유효한지 확인합니다. |
| 비차단(Non-blocking) | NTP 서버가 호스트의 시간을 동기화하는 데 성공적으로 사용되는지 확인합니다. |
| 비차단(Non-blocking) | 이미지 레지스트리에서 컨테이너 이미지를 가져왔는지 확인합니다. |
| 차단 | 이전 설치의 디스크 속도 메트릭이 있는 경우 요구 사항을 충족하는지 확인합니다. |
| 차단 | 클러스터의 호스트 간 평균 네트워크 대기 시간이 요구 사항을 충족하는지 확인합니다. |
| 차단 | 클러스터의 호스트 간 네트워크 패킷 손실이 요구 사항을 충족하는지 확인합니다. |
| 차단 | 호스트에 기본 경로가 구성되어 있는지 확인합니다. |
| 차단 | 사용자 관리 네트워킹이 있는 다중 노드 클러스터의 경우 호스트에서 클러스터의 API 도메인 이름을 확인할 수 있는지 확인합니다. |
| 차단 | 사용자 관리 네트워킹이 있는 다중 노드 클러스터의 경우 호스트가 클러스터의 내부 API 도메인 이름을 확인할 수 있는지 확인합니다. |
| 차단 | 사용자 관리 네트워킹이 있는 다중 노드 클러스터의 경우 호스트가 클러스터의 내부 앱 도메인 이름을 확인할 수 있는지 확인합니다. |
| 비차단(Non-blocking) | 호스트가 클러스터 플랫폼과 호환되는지 확인 |
| 차단 | 와일드카드 DNS *.<cluster_name>.<base_domain>이 구성되지 않았는지 확인합니다. OpenShift에 알려진 문제가 발생하기 때문입니다. |
| 비차단(Non-blocking) | 구성된 호스트 및 디스크 암호화 유형이 요구 사항을 충족하는지 확인합니다. |
| 차단 | 이 호스트에 겹치는 서브넷이 없는지 확인합니다. |
| 차단 | 호스트 이름이 클러스터에서 고유한지 확인합니다. |
| 차단 | 호스트 이름의 유효성을 확인합니다. 즉, 호스트 이름의 일반 형식과 일치하며 허용되지 않습니다. |
| 차단 | 호스트 IP가 시스템 CIDR의 주소 범위에 있는지 확인합니다. |
| 차단 | 클러스터가 Local Storage Operator의 요구 사항을 충족하는지 확인합니다. |
| 차단 | 클러스터가 Openshift Data Foundation Operator의 요구 사항을 충족하는지 확인합니다.
|
| 차단 | 클러스터가 Container Native Virtualization의 요구 사항을 충족하는지 확인합니다.
|
| 차단 | 클러스터가 Logical Volume Manager Operator의 요구 사항을 충족하는지 확인합니다.
|
| 비차단(Non-blocking) | 유효한 각 디스크가 disk.EnableUUID 를 true 로 설정했는지 확인합니다. VSphere에서 이 경우 각 디스크에 UUID가 있습니다. |
| 차단 | 검색 에이전트 버전이 에이전트 Docker 이미지 버전과 호환되는지 확인합니다. |
| 차단 | 설치 디스크가 디스크 포맷을 건너뛰지 않는지 확인합니다. |
| 차단 | 포맷을 건너뛰도록 표시된 모든 디스크가 인벤토리에 있는지 확인합니다. 재부팅 시 디스크 ID가 변경될 수 있으며 이 검증으로 인해 발생한 문제가 발생하지 않습니다. |
| 차단 | 호스트에 대한 설치 미디어의 연결을 확인합니다. |
| 비차단(Non-blocking) | 클러스터의 시스템 네트워크 정의가 존재하는지 확인합니다. |
| 차단 | 플랫폼이 네트워크 설정과 호환되는지 확인합니다. 일부 플랫폼은 단일 노드 Openshift를 설치하거나 사용자 관리 네트워킹을 사용하는 경우에만 허용됩니다. |
10.5. 클러스터 검증
10.5.1. REST API를 사용하여 클러스터 검증 가져오기
참고: 웹 기반 UI를 사용하는 경우 이러한 검증 중 대다수가 이름으로 표시되지 않습니다. 레이블과 일치하는 검증 목록을 가져오려면 다음 절차를 사용하십시오.
사전 요구 사항
-
jq
유틸리티를 설치했습니다. - API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.
-
CLUSTER_ID
로 쉘에 클러스터 ID를 내보내고 있어야 합니다. -
API에 액세스할 때 사용할 인증 정보가 있고 쉘에서 토큰을
API_TOKEN
로 내보낸 것입니다.
프로시저
API 토큰을 새로 고칩니다.
$ source refresh-token
모든 클러스터 검증을 가져옵니다.
$ curl \ --silent \ --header "Authorization: Bearer $API_TOKEN" \ https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID \ | jq -r .validations_info \ | jq 'map(.[])'
클러스터 검증을 통과하지 않음을 가져옵니다.
$ curl \ --silent \ --header "Authorization: Bearer $API_TOKEN" \ https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID \ | jq -r .validations_info \ | jq '. | map(.[] | select(.status=="failure" or .status=="pending")) | select(length>0)'
10.5.2. 클러스터 검증 세부 정보
매개변수 | 검증 유형 | 설명 |
---|---|---|
| 비차단(Non-blocking) | 클러스터의 시스템 네트워크 정의가 존재하는지 확인합니다. |
| 비차단(Non-blocking) | 클러스터에 대한 클러스터 네트워크 정의가 존재하는지 확인합니다. |
| 비차단(Non-blocking) | 클러스터의 서비스 네트워크 정의가 존재하는지 확인합니다. |
| 차단 | 정의된 네트워크가 겹치지 않는지 확인합니다. |
| 차단 | 정의된 네트워크가 동일한 주소 제품군을 공유하는지 확인합니다(유효한 주소 제품군은 IPv4, IPv6) |
| 차단 | 클러스터 네트워크 접두사가 유효하고 모든 호스트에 충분한 주소 공간을 허용하는지 확인합니다. |
| 차단 |
사용자 관리 네트워킹 클러스터의 경우 |
| 비차단(Non-blocking) |
사용자 관리 네트워킹 클러스터의 경우 |
| 차단 |
사용자 관리 네트워킹 클러스터의 경우 |
| 차단 |
사용자 관리 네트워킹 클러스터의 경우 |
| 비차단(Non-blocking) |
사용자 관리 네트워킹 클러스터의 경우 |
| 차단 | 클러스터의 모든 호스트가 "설치 가능" 상태인지 확인합니다. |
| 차단 | 이 검증은 다중 노드 클러스터에만 적용됩니다.
|
| 비차단(Non-blocking) | 클러스터의 기본 DNS 도메인이 있는지 확인합니다. |
| 비차단(Non-blocking) | 풀 시크릿이 있는지 확인합니다. 풀 시크릿이 유효한지 또는 권한이 있는지 확인하지 않습니다. |
| 차단 | 호스트 시계가 4분 이상 동기화되지 않는지 확인합니다. |
| 차단 | 클러스터가 Local Storage Operator의 요구 사항을 충족하는지 확인합니다. |
| 차단 | 클러스터가 Openshift Data Foundation Operator의 요구 사항을 충족하는지 확인합니다.
|
| 차단 | 클러스터가 Container Native Virtualization의 요구 사항을 충족하는지 확인합니다.
|
| 차단 | 클러스터가 Logical Volume Manager Operator의 요구 사항을 충족하는지 확인합니다.
|
| 차단 | 네트워크 유형이 존재하는 경우 유효성을 검사합니다.
|
11장. 네트워크 구성
이 섹션에서는 지원 설치 관리자를 사용한 네트워크 구성의 기본 사항에 대해 설명합니다.
11.1. 클러스터 네트워킹
OpenShift에서 사용하는 다양한 네트워크 유형 및 주소가 있으며 아래 표에 나열되어 있습니다.
유형 | DNS | 설명 |
---|---|---|
| Pod IP 주소가 할당되는 IP 주소 풀입니다. | |
| 서비스의 IP 주소 풀입니다. | |
| 클러스터를 형성하는 시스템의 IP 주소 블록입니다. | |
|
| API 통신에 사용할 VIP입니다. 이 설정은 기본 이름이 올바르게 확인되도록 DNS에서 지정되거나 사전에 설정해야 합니다. 듀얼 스택 네트워킹을 사용하여 배포하는 경우 IPv4 주소여야 합니다. |
|
|
API 통신에 사용할 VIP입니다. 이 설정은 기본 이름이 올바르게 확인되도록 DNS에서 지정되거나 사전에 설정해야 합니다. 듀얼 스택 네트워킹을 사용하는 경우 첫 번째 주소는 IPv4 주소여야 하며 두 번째 주소는 IPv6 주소여야 합니다. |
|
| Ingress 트래픽에 사용할 VIP입니다. 듀얼 스택 네트워킹을 사용하여 배포하는 경우 IPv4 주소여야 합니다. |
|
|
Ingress 트래픽에 사용할 VIP입니다. 듀얼 스택 네트워킹을 사용하여 배포하는 경우 첫 번째 주소는 IPv4 주소여야 하며 두 번째 주소는 IPv6 주소여야 합니다. |
OpenShift Container Platform 4.12에는 듀얼 스택 네트워킹에 대해 여러 IP 주소를 수락하기 위해 새로운 apiVIPs
및 ingressVIPs
설정이 도입되었습니다. 듀얼 스택 네트워킹을 사용하는 경우 첫 번째 IP 주소는 IPv4 주소여야 하며 두 번째 IP 주소는 IPv6 주소여야 합니다. 새 설정은 apiVIP
및 IngressVIP
를 대체하지만 API를 사용하여 구성을 수정할 때 새 설정과 이전 설정을 모두 설정해야 합니다.
원하는 네트워크 스택에 따라 다양한 네트워크 컨트롤러를 선택할 수 있습니다. 현재 지원 서비스는 다음 구성 중 하나를 사용하여 OpenShift Container Platform 클러스터를 배포할 수 있습니다.
- IPv4
- IPv6
- 듀얼 스택(IPv4 + IPv6)
지원되는 네트워크 컨트롤러는 선택한 스택에 따라 다르며 아래 표에 요약되어 있습니다. 자세한 CNI(Container Network Interface) 네트워크 공급자 기능 비교의 경우 OCP 네트워킹 설명서 를 참조하십시오.
스택 | SDN | OVN |
---|---|---|
IPv4 | 제공됨 | 제공됨 |
IPv6 | 없음 | 제공됨 |
듀얼 스택 | 없음 | 제공됨 |
OVN은 OpenShift Container Platform 4.12 이상 릴리스의 기본 CNI(Container Network Interface)입니다.
11.1.1. 제한
11.1.1.1. SDN
- SNO(Single Node OpenShift)에서는 SDN 컨트롤러가 지원되지 않습니다.
- SDN 컨트롤러는 IPv6를 지원하지 않습니다.
11.1.1.2. OVN-Kubernetes
11.1.2. 클러스터 네트워크
클러스터 네트워크는 클러스터에 배포된 모든 Pod가 해당 IP 주소를 가져오는 네트워크입니다. 워크로드를 클러스터를 구성하는 여러 노드에 걸쳐 존재할 수 있으므로 네트워크 공급자가 Pod의 IP 주소를 기반으로 개별 노드를 쉽게 찾을 수 있어야 합니다. 이를 위해 clusterNetwork.cidr
은 clusterNetwork.hostPrefix
에 정의된 크기의 서브넷으로 추가로 분할됩니다.
호스트 접두사는 클러스터의 각 개별 노드에 할당된 서브넷의 길이를 지정합니다. 클러스터가 다중 노드 클러스터에 주소를 할당하는 방법의 예입니다.
--- clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 ---
위 스니펫을 사용하여 3-노드 클러스터를 생성하면 다음과 같은 네트워크 토폴로지가 생성될 수 있습니다.
-
노드 #1에 예약된 Pod는
10.128.0.0/23
에서 IP를 가져옵니다. -
#2 노드에 예약된 Pod는
10.128.2.0/23
에서 IP를 가져옵니다. -
노드 #3에 예약된 Pod는
10.128.4.0/23
에서 IP를 가져옵니다.
OVN-K8s 내부를 설명하는 것은 이 문서에 포함되지 않지만, 위에서 설명한 패턴은 Pod와 해당 노드 간에 큰 매핑 목록을 유지하지 않고 다른 노드 간에 Pod-to-Pod 트래픽을 라우팅하는 방법을 제공합니다.
11.1.3. 머신 네트워크
시스템 네트워크는 클러스터를 구성하여 서로 통신하도록 구성하는 모든 호스트에서 사용하는 네트워크입니다. API 및 Ingress VIP를 포함해야 하는 서브넷이기도 합니다.
11.1.4. 다중 노드 클러스터와 비교하여 SNO
단일 노드 OpenShift 또는 다중 노드 클러스터를 배포하는지 여부에 따라 다른 값이 필요합니다. 아래 표는 이에 대해 자세히 설명합니다.
매개변수 | SNO | DHCP 모드를 사용하는 다중 노드 클러스터 | DHCP 모드가 없는 다중 노드 클러스터 |
---|---|---|---|
| 필수 항목 | 필수 항목 | 필수 항목 |
| 필수 항목 | 필수 항목 | 필수 항목 |
| 자동 할당 가능 (*) | 자동 할당 가능 (*) | 자동 할당 가능 (*) |
| 허용되지 않음 | 허용되지 않음 | 필수 항목 |
| 허용되지 않음 | 허용되지 않음 | 4.12 이상 릴리스에서 필수 |
| 허용되지 않음 | 허용되지 않음 | 필수 항목 |
| 허용되지 않음 | 허용되지 않음 | 4.12 이상 릴리스에서 필수 |
*) 단일 호스트 네트워크만 있는 경우 머신 네트워크 CIDR의 자동 할당이 수행됩니다. 그렇지 않으면 명시적으로 지정해야 합니다.
11.1.5. Air-gapped 환경
인터넷 액세스 없이 클러스터를 배포하는 워크플로에는 이 문서의 범위를 벗어나는 사전 요구 사항이 있습니다. Zero 10.0.0.1 Provisioning 일부 정보를 보려면 Git 리포지토리를 하드 방식으로 프로비저닝하는 것을 참조할 수 있습니다.
11.2. DHCP VIP 할당
VIP DHCP 할당은 사용자가 DHCP 서버에서 해당 IP 주소를 자동으로 할당하는 기능을 활용하여 API 및 Ingress에 대한 가상 IP를 수동으로 제공하는 요구 사항을 건너뛸 수 있는 기능입니다.
클러스터 구성에서 api_vips
및 ingress_vips
를 사용하는 대신 기능을 활성화하면 서비스는 리스 할당 요청을 보내고 응답에 따라 VIP를 사용합니다. 이 서비스는 Machine Network에서 IP 주소를 할당합니다.
이는 OpenShift Container Platform 기능이 아니며 설정을 더 쉽게 만들기 위해 지원 서비스에 구현되어 있습니다.
11.2.1. 자동 할당을 활성화하는 페이로드 예
--- { "vip_dhcp_allocation": true, "network_type": "OVNKubernetes", "user_managed_networking": false, "cluster_networks": [ { "cidr": "10.128.0.0/14", "host_prefix": 23 } ], "service_networks": [ { "cidr": "172.30.0.0/16" } ], "machine_networks": [ { "cidr": "192.168.127.0/24" } ] } ---
11.2.2. 자동 할당을 비활성화하는 페이로드 예
--- { "api_vip": "192.168.127.100", "api_vips": [ { "ip": "192.168.127.100" } ], "ingress_vip": "192.168.127.101", "ingress_vips": [ { "ip": "192.168.127.101" } ], "vip_dhcp_allocation": false, "network_type": "OVNKubernetes", "user_managed_networking": false, "cluster_networks": [ { "cidr": "10.128.0.0/14", "host_prefix": 23 } ], "service_networks": [ { "cidr": "172.30.0.0/16" } ] } ---
OpenShift Container Platform 4.12에서는 레거시 api_vip
및 ingress_vip
설정과 새 api_vips
및 ingress_vips
설정을 모두 설정해야 합니다.
11.3. 추가 리소스
- 베어 메탈 IPI 설명서에서 는 VIP 주소 구문에 대한 추가 설명을 제공합니다.
11.4. User Managed Networking과 Cluster Managed Networking의 차이점
사용자 관리 네트워킹은 비표준 네트워크 토폴로지를 사용하는 고객이 OpenShift Container Platform 클러스터를 배포할 수 있는 지원 설치 관리자의 기능입니다. 예를 들면 다음과 같습니다.
-
VIP 주소를 처리하기 위해
keepalived
및 VRRP를 사용하지 않으려는 외부 로드 밸런서가 있는 고객. - 여러 다른 L2 네트워크 세그먼트에 분산된 클러스터 노드를 사용한 배포.
11.4.1. 검증
지원 설치 관리자에서 설치를 시작하기 전에 다양한 네트워크 검증이 수행됩니다. User Managed Networking을 활성화하면 다음과 같은 검증이 변경됩니다.
- L2 검사(ARP) 대신 L3 연결 검사(ICMP) 수행
11.5. 정적 네트워크 구성
검색 ISO를 생성하거나 업데이트할 때 정적 네트워크 구성을 사용할 수 있습니다.
11.5.1. 사전 요구 사항
- NMState 에 대해 잘 알고 있습니다.
11.5.2. NMState 구성
YAML 형식의 NMState 파일은 호스트에 대해 원하는 네트워크 구성을 지정합니다. 검색 시 인터페이스의 실제 이름으로 대체되는 인터페이스의 논리 이름이 있습니다.
11.5.2.1. NMState 구성 예
--- dns-resolver: config: server: - 192.168.126.1 interfaces: - ipv4: address: - ip: 192.168.126.30 prefix-length: 24 dhcp: false enabled: true name: eth0 state: up type: ethernet - ipv4: address: - ip: 192.168.141.30 prefix-length: 24 dhcp: false enabled: true name: eth1 state: up type: ethernet routes: config: - destination: 0.0.0.0/0 next-hop-address: 192.168.126.1 next-hop-interface: eth0 table-id: 254 ---
11.5.3. MAC 인터페이스 매핑
MAC 인터페이스 맵은 호스트에 있는 실제 인터페이스를 사용하여 NMState 구성에 정의된 논리 인터페이스를 매핑하는 속성입니다.
매핑은 항상 호스트에 있는 물리적 인터페이스를 사용해야 합니다. 예를 들어 NMState 구성에서 본딩 또는 VLAN을 정의하는 경우 매핑에는 상위 인터페이스에 대한 항목만 포함되어야 합니다.
11.5.3.1. MAC 인터페이스 매핑 예
--- mac_interface_map: [ { mac_address: 02:00:00:2c:23:a5, logical_nic_name: eth0 }, { mac_address: 02:00:00:68:73:dc, logical_nic_name: eth1 } ] ---
11.5.4. 추가 NMState 구성 예
아래 예제는 부분 구성만 표시합니다. 이는 그대로 사용할 수 없으며 항상 사용할 환경에 맞게 조정해야 합니다. 잘못 사용된 경우 네트워크 연결이 없는 머신을 남겨 둘 수 있습니다.
11.5.4.1. 태그가 지정된 VLAN
--- interfaces: - ipv4: address: - ip: 192.168.143.15 prefix-length: 24 dhcp: false enabled: true ipv6: enabled: false name: eth0.404 state: up type: vlan vlan: base-iface: eth0 id: 404 ---
11.5.4.2. 네트워크 본딩
--- interfaces: - ipv4: address: - ip: 192.168.138.15 prefix-length: 24 dhcp: false enabled: true ipv6: enabled: false link-aggregation: mode: active-backup options: all_slaves_active: delivered miimon: "140" slaves: - eth0 - eth1 name: bond0 state: up type: bond ---
11.6. API를 사용하여 정적 네트워크 구성 적용
지원 설치 관리자 API를 사용하여 정적 네트워크 구성을 적용할 수 있습니다.
사전 요구 사항
- API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.
-
쉘에서
$INFRA_ENV_ID
로 내보낸 인프라 환경 ID가 있어야 합니다. -
API에 액세스할 때 사용할 자격 증명이 있고 쉘에서
$API_TOKEN
으로 토큰을 내보냈습니다. -
server-a.yaml
및server-b.yaml
로 사용 가능한 정적 네트워크 구성이 있는 YAML 파일이 있습니다.
절차
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 ---
API 토큰을 새로 고칩니다.
$ source refresh-token
지원 서비스 API 끝점에 요청을 보냅니다.
--- curl -H "Content-Type: application/json" \ -X PATCH -d @/tmp/request-body.txt \ -H "Authorization: Bearer ${API_TOKEN}" \ https://api.openshift.com/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID ---
11.7. 추가 리소스
11.8. 듀얼 스택 네트워킹으로 변환
듀얼 스택 IPv4/IPv6 구성을 사용하면 IPv4 및 IPv6 서브넷에 상주하는 포드가 있는 클러스터를 배포할 수 있습니다.
11.8.1. 사전 요구 사항
- OVN-K8s 설명서에대해 잘 알고 있습니다.
11.8.2. 단일 노드 OpenShift의 페이로드 예
--- { "network_type": "OVNKubernetes", "user_managed_networking": false, "cluster_networks": [ { "cidr": "10.128.0.0/14", "host_prefix": 23 }, { "cidr": "fd01::/48", "host_prefix": 64 } ], "service_networks": [ {"cidr": "172.30.0.0/16"}, {"cidr": "fd02::/112"} ], "machine_networks": [ {"cidr": "192.168.127.0/24"},{"cidr": "1001:db8::/120"} ] } ---
11.8.3. 많은 노드로 구성된 OpenShift Container Platform 클러스터의 페이로드 예
--- { "vip_dhcp_allocation": false, "network_type": "OVNKubernetes", "user_managed_networking": false, "api_vip": "192.168.127.100", "api_vips": [ { "ip": "192.168.127.100" }, { "ip": "2001:0db8:85a3:0000:0000:8a2e:0370:7334" } ], "ingress_vip": "192.168.127.101", "ingress_vips": [ { "ip": "192.168.127.101" }, { "ip": "2001:0db8:85a3:0000:0000:8a2e:0370:7335" } ], "cluster_networks": [ { "cidr": "10.128.0.0/14", "host_prefix": 23 }, { "cidr": "fd01::/48", "host_prefix": 64 } ], "service_networks": [ {"cidr": "172.30.0.0/16"}, {"cidr": "fd02::/112"} ], "machine_networks": [ {"cidr": "192.168.127.0/24"},{"cidr": "1001:db8::/120"} ] } ---
11.8.4. 제한
api_vip
IP 주소와 ingress_vip
IP 주소 설정은 IPv4 주소여야 하는 듀얼 스택 네트워킹을 사용할 때 기본 IP 주소 제품군이어야 합니다. 현재 Red Hat은 IPv6를 사용한 듀얼 스택 VIP 또는 듀얼 스택 네트워킹을 기본 IP 주소 제품군으로 지원하지 않습니다. Red Hat은 IPv4를 기본 IP 주소 제품군으로 사용하는 듀얼 스택 네트워킹을 보조 IP 주소 제품군으로 지원합니다. 따라서 IP 주소 값을 입력할 때 IPv6 항목 앞에 IPv4 항목을 배치해야 합니다.
OpenShift Container Platform 4.12에서는 VIP 주소에서 듀얼 스택 네트워킹을 사용하려면 레거시 api_vip
및 ingress_vip
설정과 새 api_vips
및 ingress_vips
설정을 모두 설정해야 합니다. 레거시 api_vip
및 ingress_vip
설정은 각각 하나의 값만 사용하므로 IPv4 주소여야 합니다.
11.9. 추가 리소스
12장. 클러스터 확장
사용자 인터페이스 또는 API를 사용하여 호스트를 추가하여 지원 설치 관리자로 설치된 클러스터를 확장할 수 있습니다.
12.1. 사전 요구 사항
- 지원 설치 프로그램 클러스터에 액세스할 수 있어야 합니다.
-
OpenShift CLI(
oc
)를 설치해야 합니다. - 작업자 노드를 추가하는 클러스터에 필요한 모든 DNS 레코드가 있는지 확인합니다.
-
여러 CPU 아키텍처가 있는 클러스터에 작업자 노드를 추가하는 경우 아키텍처가
multi
로 설정되어 있는지 확인해야 합니다.
12.2. 여러 아키텍처 확인
여러 아키텍처가 있는 클러스터에 노드를 추가할 때 아키텍처
설정이 multi
로 설정되어 있는지 확인합니다.
절차
- CLI를 사용하여 클러스터에 로그인합니다.
아키텍처
설정을 확인합니다.$ oc adm release info -o json | jq .metadata.metadata
architecture
설정이 'multi'로 설정되어 있는지 확인합니다.{ "release.openshift.io/architecture": "multi" }
12.3. UI로 호스트 추가
지원 설치 관리자를 사용하여 생성된 클러스터에 호스트를 추가할 수 있습니다.
지원 설치 관리자 클러스터에 호스트를 추가하는 것은 OpenShift Container Platform 버전 4.11 이상을 실행하는 클러스터에서만 지원됩니다.
절차
- OpenShift Cluster Manager 에 로그인하고 확장할 클러스터를 클릭합니다.
- 호스트 추가를 클릭하고 새 호스트에 대한 검색 ISO를 다운로드하여 SSH 공개 키를 추가하고 필요에 따라 클러스터 전체 프록시 설정을 구성합니다.
- 선택 사항: 필요에 따라 Ignition 파일을 수정합니다.
- 검색 ISO를 사용하여 대상 호스트를 부팅하고 콘솔에서 호스트를 검색할 때까지 기다립니다.
-
호스트 역할을 선택합니다.
작업자
또는컨트롤 플레인
호스트일 수 있습니다. - 설치를 시작합니다.
설치가 진행되면 설치에 호스트에 대한 보류 중인 인증서 서명 요청(CSR)이 생성됩니다. 메시지가 표시되면 보류 중인 CSR을 승인하여 설치를 완료합니다.
호스트가 정상적으로 설치되면 클러스터 웹 콘솔에 호스트로 나열됩니다.
새 호스트는 원래 클러스터와 동일한 방법을 사용하여 암호화됩니다.
12.4. API를 사용하여 호스트 추가
지원 설치 관리자 REST API를 사용하여 클러스터에 호스트를 추가할 수 있습니다.
사전 요구 사항
-
OpenShift Cluster Manager CLI(
ocm
)를 설치합니다. - 클러스터 생성 권한이 있는 사용자로 OpenShift Cluster Manager 에 로그인합니다.
-
jq
를 설치합니다. - 확장하려는 클러스터에 필요한 모든 DNS 레코드가 있는지 확인합니다.
절차
- 지원 설치 관리자 REST API에 대해 인증하고 세션에 대한 API 토큰을 생성합니다. 생성된 토큰은 15분 동안만 유효합니다.
다음 명령을 실행하여
$API_URL
변수를 설정합니다.$ export API_URL=<api_url> 1
다음 명령을 실행하여 클러스터를 가져옵니다.
$CLUSTER_ID
변수를 설정합니다. 클러스터에 로그인하고 다음 명령을 실행합니다.$ export CLUSTER_ID=$(oc get clusterversion -o jsonpath='{.items[].spec.clusterID}')
클러스터를 가져오는 데 사용되는
$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 }')
클러스터를 가져와서
$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')
클러스터에 대한
InfraEnv
리소스를 생성하고 다음 명령을 실행하여$INFRA_ENV_ID
변수를 설정합니다.- console.redhat.com 의 Red Hat OpenShift Cluster Manager에서 풀 시크릿 파일을 다운로드합니다.
$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
이미지 유형으로 바꿉니다.
$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')
다음 명령을 실행하여 클러스터 호스트에 대한 검색 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
ISO를 다운로드합니다.
$ curl -L -s '<iso_url>' --output rhcos-live-minimal.iso 1
- 1
- &
lt;iso_url
>을 이전 단계의 ISO URL로 바꿉니다.
-
다운로드한
rhcos-live-minimal.iso
에서 새 작업자 호스트를 부팅합니다. 설치되지 않은 클러스터에서 호스트 목록을 가져옵니다. 새 호스트가 표시될 때까지 다음 명령을 계속 실행하십시오.
$ 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
새 호스트의
$HOST_ID
변수를 설정합니다. 예를 들면 다음과 같습니다.$ HOST_ID=<host_id> 1
- 1
- &
lt;host_id&
gt;를 이전 단계의 호스트 ID로 바꿉니다.
다음 명령을 실행하여 호스트를 설치할 준비가 되었는지 확인합니다.
참고전체
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": [] } }
이전 명령에서 호스트가 준비되었다고 표시되면 다음 명령을 실행하여 /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}"
설치가 진행되면 설치에 호스트에 대한 보류 중인 인증서 서명 요청(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" } ] }
선택 사항: 다음 명령을 실행하여 클러스터의 모든 이벤트를 확인합니다.
$ 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"}
- 클러스터에 로그인하고 보류 중인 CSR을 승인하여 설치를 완료합니다.
검증
새 호스트가
Ready
: 상태의 클러스터에 성공적으로 추가되었는지 확인합니다.$ oc get nodes
출력 예
NAME STATUS ROLES AGE VERSION control-plane-1.example.com Ready master,worker 56m v1.25.0 compute-1.example.com Ready worker 11m v1.25.0
12.5. 정상 클러스터에 기본 컨트롤 플레인 노드 설치
다음 절차에서는 정상적인 OpenShift Container Platform 클러스터에 기본 컨트롤 플레인 노드를 설치하는 방법을 설명합니다.
클러스터가 비정상이면 추가 작업을 관리해야 관리할 수 있습니다. 자세한 내용은 비정상 클러스터에 기본 컨트롤 플레인 노드 설치를 참조하십시오.
사전 요구 사항
절차
CSR 검토 및 승인
CSR(
CertificateSigningRequests
)을 검토합니다.$ oc get csr | grep Pending
출력 예
csr-5sd59 8m19s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper <none> Pending csr-xzqts 10s kubernetes.io/kubelet-serving system:node:worker-6 <none> Pending
보류 중인 모든 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을 승인해야 합니다.
기본 노드가
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)가 필요합니다.Machine
CR을BareMetalHost
및Node
:에 연결합니다.고유한
.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>
BareMetalHost
CR을 적용합니다.$ oc apply -f <filename>
고유한
.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>
Machine
CR을 적용합니다.$ oc apply -f <filename>
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
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 | +--------+---------+--------+--------------+--------------+---------+
etcd-operator
구성이 모든 노드에 적용되는지 확인합니다.$ oc get clusteroperator etcd
출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE etcd 4.11.5 True False False 5h54m
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
노드 상태를 확인합니다.
$ 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
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
ClusterVersion
확인 :$ oc get ClusterVersion
출력 예
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.11.5 True False 5h57m Cluster version is 4.11.5
이전 컨트롤 플레인 노드를 제거합니다.
BareMetalHost
CR을 삭제합니다.$ oc delete bmh -n openshift-machine-api custom-master3
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
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
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
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
etcd-operator
가 클러스터 멤버를 조정할 수 있도록 물리적 머신을 제거합니다.$ oc rsh -n openshift-etcd etcd-worker-2 etcdctl member list -w table; etcdctl endpoint health
출력 예
+--------+---------+--------+--------------+--------------+---------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | LEARNER | +--------+---------+--------+--------------+--------------+---------+ |2c18942f| started |worker-3|192.168.111.26|192.168.111.26| false | |61e2a860| started |worker-2|192.168.111.25|192.168.111.25| false | |ead4f280| started |worker-5|192.168.111.28|192.168.111.28| false | +--------+---------+--------+--------------+--------------+---------+ 192.168.111.26 is healthy: committed proposal: took = 10.458132ms 192.168.111.25 is healthy: committed proposal: took = 11.047349ms 192.168.111.28 is healthy: committed proposal: took = 11.414402ms
추가 리소스
12.6. 비정상 클러스터에 기본 컨트롤 플레인 노드 설치
다음 절차에서는 비정상 OpenShift Container Platform 클러스터에 기본 컨트롤 플레인 노드를 설치하는 방법을 설명합니다.
사전 요구 사항
절차
클러스터의 초기 상태를 확인합니다.
$ 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
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
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 | +--------+---------+--------+--------------+--------------+---------+
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
Machine
사용자 정의 리소스를 삭제하여 비정상 컨트롤 플레인을 제거합니다.$ oc delete machine -n openshift-machine-api test-day2-1-6qv96-master-2
참고비정상 클러스터를 성공적으로 실행할 수 없는 경우
머신
및노드
사용자 정의 리소스(CR)는 삭제되지 않습니다.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}]
비정상적인
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 | +--------+---------+--------+--------------+--------------+---------+
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
etcdctl
멤버 사용자 정의 리소스를 삭제하여 비정상 클러스터를 제거합니다.$ etcdctl member remove 61e2a86084aafa62
출력 예
Member 61e2a86084aafa62 removed from cluster 6881c977b97990d7
다음 명령을 실행하여
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 | +----------+---------+--------+--------------+--------------+-------+
인증서 서명 요청 검토 및 승인
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
보류 중인 모든 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을 승인해야 합니다.
컨트롤 플레인 노드의 준비 상태를 확인합니다.
$ 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
시스템 ,
노드
BareMetalHost
사용자 정의 리소스를 검증합니다.etcd-operator
를 사용하려면 클러스터가 작동하는 머신 API로 실행되는 경우Machine
CR이 있어야 합니다.머신
CR은실행
중 단계에서 표시됩니다.BareMetalHost
및노드
와 연결된머신
사용자 정의 리소스를 생성합니다.새로 추가된 노드를 참조하는
머신
CR이 있는지 확인합니다.중요boot-it-yourself는
BareMetalHost
및Machine
CR을 생성하지 않으므로 생성해야 합니다.BareMetalHost
및Machine
CR을 생성하지 않으면etcd-operator
를 실행할 때 오류가 생성됩니다.BareMetalHost
사용자 정의 리소스를 추가합니다.$ oc create bmh -n openshift-machine-api custom-master3
머신
사용자 정의 리소스 추가:$ oc create machine -n openshift-machine-api custom-master3
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
다음 명령을 실행하여
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 | +---------+-------+--------+--------------+--------------+-------+
etcd
Operator가 모든 노드를 구성했는지 확인합니다.$ oc get clusteroperator etcd
출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE etcd 4.11.5 True False False 22h
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
노드의 상태를 확인합니다.
$ 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
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
ClusterVersion
확인 :$ oc get ClusterVersion
출력 예
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.11.5 True False 22h Cluster version is 4.11.5
추가 리소스
12.7. 추가 리소스
13장. 선택 사항: Nutanix에 설치
Nutanix에 OpenShift Container Platform을 설치하는 경우 지원 설치 관리자는 OpenShift Container Platform 클러스터를 Nutanix에 노출하고 Nutanix 컨테이너 인터페이스 (CSI)를 사용하여 자동 스케일링 및 동적으로 스토리지 컨테이너를 프로비저닝하는 Nutanix 플랫폼과 통합할 수 있습니다.
13.1. UI를 사용하여 Nutanix에 호스트 추가
UI(사용자 인터페이스)를 사용하여 Nutanix에 호스트를 추가하려면 지원 설치 관리자에서 검색 이미지 ISO를 생성합니다. 최소 검색 이미지 ISO를 사용합니다. 이 설정은 기본 설정입니다. 이미지에는 네트워킹으로 호스트를 부팅하는 데 필요한 항목만 포함됩니다. 대부분의 콘텐츠는 부팅 시 다운로드됩니다. ISO 이미지의 크기는 약 100MB입니다.
이 작업이 완료되면 Nutanix 플랫폼에 대한 이미지를 생성하고 Nutanix 가상 머신을 생성해야 합니다.
사전 요구 사항
- 지원 설치 관리자 UI에 클러스터 프로필을 생성했습니다.
- Nutanix 클러스터 환경을 설정하고 클러스터 이름과 서브넷 이름을 적어 둡니다.
절차
- 호스트 검색에서 호스트 추가 버튼을 클릭하고 설치 미디어를 선택합니다.
- Minimal image file: Provision with virtual media 를 선택하여 부팅에 필요한 데이터를 가져올 작은 이미지를 다운로드합니다.
선택 사항:
core
사용자로 Nutanix VM에 연결할 수 있도록 SSH 공개 키를 추가합니다. 클러스터 호스트에 로그인하면 설치 중에 디버깅 정보를 제공할 수 있습니다.- 로컬 시스템에 기존 SSH 키 쌍이 없는 경우 클러스터 노드 SSH 액세스에 대한 키 쌍 생성 단계를 따르십시오.
-
SSH 공개 키 필드에서 찾아보기 를 클릭하여 SSH 공개 키가 포함된
id_rsa.pub
파일을 업로드합니다. 또는 파일을 파일 관리자의 필드로 끌어다 놓습니다. 파일 관리자에서 파일을 보려면 메뉴에서 숨겨진 파일 표시를 선택합니다.
- 선택 사항: 클러스터 호스트가 프록시를 사용해야 하는 방화벽 뒤에 있는 경우 클러스터 전체 프록시 설정 구성을 선택합니다. 프록시 서버의 HTTP 및 HTTPS URL에 대한 사용자 이름, 암호, IP 주소 및 포트를 입력합니다.
- 선택 사항: Ignition 파일로 부팅하려면 검색 이미지를 구성합니다. 자세한 내용은 검색 이미지 구성을 참조하십시오.
- Discovery ISO 생성을 클릭합니다.
- Discovery ISO URL 을 복사합니다.
- Nutanix Prism UI에서 지침에 따라 지원 설치 관리자에서 검색 이미지를 업로드합니다.
Nutanix Prism UI에서 Prism Central을 통해 컨트롤 플레인 (마스터) VM을 생성합니다.
-
이름을 입력합니다. 예를 들면
control-plane
또는master
입니다. - VM 수를 입력합니다. 컨트롤 플레인에는 3이어야 합니다.
- 나머지 설정이 컨트롤 플레인 호스트의 최소 요구 사항을 충족하는지 확인합니다.
-
이름을 입력합니다. 예를 들면
Nutanix Prism UI에서 Prism Central을 통해 작업자 VM을 생성합니다.
-
이름을 입력합니다. 예를 들면
worker
입니다. - VM 수를 입력합니다. 작업자 노드가 2개 이상 생성해야 합니다.
- 나머지 설정이 작업자 호스트의 최소 요구 사항을 충족하는지 확인합니다.
-
이름을 입력합니다. 예를 들면
-
지원 설치 관리자 사용자 인터페이스로 돌아가서 지원 설치 프로그램이 호스트를 검색하고 각각
Ready
상태가 될 때까지 기다립니다. - Nutanix 와의 통합을 활성화하려면 가상화 플랫폼과 통합하십시오.
- 설치 절차를 계속합니다.
13.2. API를 사용하여 Nutanix에 호스트 추가
API를 사용하여 Nutanix에 호스트를 추가하려면 지원 설치 관리자에서 검색 이미지 ISO를 생성합니다. 최소 검색 이미지 ISO를 사용합니다. 이 설정은 기본 설정입니다. 이미지에는 네트워킹으로 호스트를 부팅하는 데 필요한 항목만 포함됩니다. 대부분의 콘텐츠는 부팅 시 다운로드됩니다. ISO 이미지의 크기는 약 100MB입니다.
이 작업이 완료되면 Nutanix 플랫폼에 대한 이미지를 생성하고 Nutanix 가상 머신을 생성해야 합니다.
사전 요구 사항
- 지원 설치 관리자 API 인증을 설정했습니다.
- 지원 설치 관리자 클러스터 프로필이 생성되어 있습니다.
- 지원 설치 관리자 인프라 환경이 생성되어 있습니다.
-
쉘에서
$INFRA_ENV_ID
로 내보낸 인프라 환경 ID가 있어야 합니다. - 지원 설치 관리자 클러스터 구성을 완료했습니다.
- Nutanix 클러스터 환경을 설정하고 클러스터 이름과 서브넷 이름을 적어 둡니다.
절차
- ignition 파일로 부팅하려면 검색 이미지를 구성합니다.
환경 변수를 저장할 Nutanix 클러스터 구성 파일을 생성합니다.
$ touch ~/nutanix-cluster-env.sh
$ chmod +x ~/nutanix-cluster-env.sh
새 터미널 세션을 시작해야 하는 경우 환경 변수를 쉽게 다시 로드할 수 있습니다. 예를 들면 다음과 같습니다.
$ source ~/nutanix-cluster-env.sh
구성 파일의 NTX_CLUSTER_NAME 환경 변수에 Nutanix 클러스터의 이름을
NTX_CLUSTER_NAME
에 할당합니다.$ cat << EOF >> ~/nutanix-cluster-env.sh export NTX_CLUSTER_NAME=<cluster_name> EOF
&
lt;cluster_name
>을 Nutanix 클러스터 이름으로 바꿉니다.구성 파일의
NTX_SUBNET_NAME
환경 변수에 Nutanix 클러스터의 서브넷 이름을 할당합니다.$ cat << EOF >> ~/nutanix-cluster-env.sh export NTX_SUBNET_NAME=<subnet_name> EOF
&
lt;subnet_name
>을 Nutanix 클러스터 서브넷 이름으로 바꿉니다.API 토큰을 새로 고칩니다.
$ source refresh-token
다운로드 URL을 가져옵니다.
$ curl -H "Authorization: Bearer ${API_TOKEN}" \ https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/downloads/image-url
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로 바꿉니다.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'
<
;user&
gt;를 Nutanix 사용자 이름으로 바꿉니다.'<password>'
를 Nutanix 암호로 바꿉니다. <domain-or-ip
>를 Nutanix underform의 도메인 이름 또는 IP 주소로 바꿉니다. <port&
gt;를 Nutanix 서버의 포트로 바꿉니다. 포트 기본값은9440
입니다.반환된 UUID를 구성 파일의
NTX_IMAGE_UUID
환경 변수에 할당합니다.$ cat << EOF >> ~/nutanix-cluster-env.sh export NTX_IMAGE_UUID=<uuid> EOF
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'
<
;user&
gt;를 Nutanix 사용자 이름으로 바꿉니다.'<password>'
를 Nutanix 암호로 바꿉니다. <domain-or-ip
>를 Nutanix underform의 도메인 이름 또는 IP 주소로 바꿉니다. <port&
gt;를 Nutanix 서버의 포트로 바꿉니다. 포트 기본값은9440
입니다. <nutanix_cluster_name&
gt;을 Nutanix 클러스터 이름으로 바꿉니다.반환된 Nutanix 클러스터 UUID를 구성 파일의
NTX_CLUSTER_UUID
환경 변수에 할당합니다.$ cat << EOF >> ~/nutanix-cluster-env.sh export NTX_CLUSTER_UUID=<uuid> EOF
&
lt;uuid&
gt;를 Nutanix 클러스터의 반환된 UUID로 바꿉니다.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'
<
;user&
gt;를 Nutanix 사용자 이름으로 바꿉니다.'<password>'
를 Nutanix 암호로 바꿉니다. <domain-or-ip
>를 Nutanix underform의 도메인 이름 또는 IP 주소로 바꿉니다. <port&
gt;를 Nutanix 서버의 포트로 바꿉니다. 포트 기본값은9440
입니다. <subnet_name
>을 클러스터 서브넷 이름으로 바꿉니다.반환된 Nutanix 서브넷 UUID를 구성 파일의
NTX_CLUSTER_UUID
환경 변수에 할당합니다.$ cat << EOF >> ~/nutanix-cluster-env.sh export NTX_SUBNET_UUID=<uuid> EOF
&
lt;uuid&
gt;를 클러스터 서브넷의 반환된 UUID로 바꿉니다.Nutanix 환경 변수가 설정되어 있는지 확인합니다.
$ source ~/nutanix-cluster-env.sh
각 Nutanix 호스트에 대한 VM 구성 파일을 생성합니다. 컨트롤 플레인 (마스터) VM과 두 개 이상의 작업자 VM을 생성합니다. 예를 들면 다음과 같습니다.
$ touch create-master-0.json
$ cat << EOF > create-master-0.json { "spec": { "name": "<host_name>", "resources": { "power_state": "ON", "num_vcpus_per_socket": 1, "num_sockets": 16, "memory_size_mib": 32768, "disk_list": [ { "disk_size_mib": 122880, "device_properties": { "device_type": "DISK" } }, { "device_properties": { "device_type": "CDROM" }, "data_source_reference": { "kind": "image", "uuid": "$NTX_IMAGE_UUID" } } ], "nic_list": [ { "nic_type": "NORMAL_NIC", "is_connected": true, "ip_endpoint_list": [ { "ip_type": "DHCP" } ], "subnet_reference": { "kind": "subnet", "name": "$NTX_SUBNET_NAME", "uuid": "$NTX_SUBNET_UUID" } } ], "guest_tools": { "nutanix_guest_tools": { "state": "ENABLED", "iso_mount_state": "MOUNTED" } } }, "cluster_reference": { "kind": "cluster", "name": "$NTX_CLUSTER_NAME", "uuid": "$NTX_CLUSTER_UUID" } }, "api_version": "3.1.0", "metadata": { "kind": "vm" } } EOF
&
lt;host_name
>을 호스트 이름으로 바꿉니다.각 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'
<
;user&
gt;를 Nutanix 사용자 이름으로 바꿉니다.'<password>'
를 Nutanix 암호로 바꿉니다. <domain-or-ip
>를 Nutanix underform의 도메인 이름 또는 IP 주소로 바꿉니다. <port&
gt;를 Nutanix 서버의 포트로 바꿉니다. 포트 기본값은9440
입니다. <vm_config_file_name&
gt;을 VM 구성 파일의 이름으로 바꿉니다.반환된 VM UUID를 구성 파일의 고유한 환경 변수에 할당합니다.
$ cat << EOF >> ~/nutanix-cluster-env.sh export NTX_MASTER_0_UUID=<uuid> EOF
&
lt;uuid&
gt;를 VM의 반환된 UUID로 바꿉니다.참고환경 변수에는 각 VM마다 고유한 이름이 있어야 합니다.
지원 설치 프로그램이 각 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'
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
- 설치 절차를 계속합니다.
13.3. Nutanix 설치 후 구성
아래 단계에 따라 OpenShift Container Platform과 Nutanix 클라우드 공급자의 통합을 완료하고 검증하십시오.
사전 요구 사항
- 지원 설치 프로그램이 클러스터 설치를 성공적으로 완료했습니다.
- 클러스터가 console.redhat.com 에 연결되어 있습니다.
- Red Hat OpenShift Container Platform 명령줄 인터페이스에 액세스할 수 있습니다.
13.3.1. Nutanix 구성 설정 업데이트
지원 설치 관리자를 사용하여 Nutanix 플랫폼에 OpenShift Container Platform을 설치한 후 다음 Nutanix 구성 설정을 수동으로 업데이트해야 합니다.
-
<prismcentral_username&
gt; : Nutanix Prism Central 사용자 이름. -
<prismcentral_password
> : Nutanix Prism Central 암호. -
<prismcentral_address
> : Nutanix Prism Central 주소입니다. -
<prismcentral_port
> : Nutanix Prism 중앙 포트입니다. -
<prismelement_username&
gt; : Nutanix Prism Element 사용자 이름. -
<prismelement_password
> : Nutanix Prism Element 암호. -
<prismelement_address
> : Nutanix Prism Element 주소 -
<prismelement_port
> : Nutanix Prism Element 포트입니다. -
<prismelement_clustername&
gt; : Nutanix Prism Element 클러스터 이름입니다. -
<nutanix_storage_container
> : Nutanix Prism 스토리지 컨테이너
절차
OpenShift Container Platform 명령줄 인터페이스에서 Nutanix 클러스터 구성 설정을 업데이트합니다.
$ oc patch infrastructure/cluster --type=merge --patch-file=/dev/stdin <<-EOF { "spec": { "platformSpec": { "nutanix": { "prismCentral": { "address": "<prismcentral_address>", "port": <prismcentral_port> }, "prismElements": [ { "endpoint": { "address": "<prismelement_address>", "port": <prismelement_port> }, "name": "<prismelement_clustername>" } ] }, "type": "Nutanix" } } } EOF
샘플 출력
infrastructure.config.openshift.io/cluster patched
자세한 내용은 Nutanix에서 머신 세트 생성 을 참조하십시오.
Nutanix 시크릿을 생성합니다.
$ cat <<EOF | oc create -f - apiVersion: v1 kind: Secret metadata: name: nutanix-credentials namespace: openshift-machine-api type: Opaque stringData: credentials: | [{"type":"basic_auth","data":{"prismCentral":{"username":"${<prismcentral_username>}","password":"${<prismcentral_password>}"},"prismElements":null}}] EOF
샘플 출력
secret/nutanix-credentials created
OpenShift Container Platform 버전 4.13 이상을 설치할 때 Nutanix 클라우드 공급자 구성을 업데이트합니다.
Nutanix 클라우드 공급자 구성 YAML 파일을 가져옵니다.
$ oc get cm cloud-provider-config -o yaml -n openshift-config > cloud-provider-config-backup.yaml
구성 파일의 백업을 생성합니다.
$ cp cloud-provider-config_backup.yaml cloud-provider-config.yaml
구성 YAML 파일을 엽니다.
$ vi cloud-provider-config.yaml
다음과 같이 구성 YAML 파일을 편집합니다.
kind: ConfigMap apiVersion: v1 metadata: name: cloud-provider-config namespace: openshift-config data: config: | { "prismCentral": { "address": "<prismcentral_address>", "port":<prismcentral_port>, "credentialRef": { "kind": "Secret", "name": "nutanix-credentials", "namespace": "openshift-cloud-controller-manager" } }, "topologyDiscovery": { "type": "Prism", "topologyCategories": null }, "enableCustomLabeling": true }
구성 업데이트를 적용합니다.
$ oc apply -f cloud-provider-config.yaml
샘플 출력
Warning: resource configmaps/cloud-provider-config is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by oc apply. oc apply should only be used on resources created declaratively by either oc create --save-config or oc apply. The missing annotation will be patched automatically. configmap/cloud-provider-config configured
13.3.2. Nutanix CSI Operator group 생성
Nutanix CSI Operator에 대한 Operator 그룹을 생성합니다.
Operator 그룹 및 관련 개념에 대한 설명은 추가 리소스 의 일반 Operator 프레임워크 약관 을 참조하십시오.
절차
Nutanix CSI Operator 그룹 YAML 파일을 엽니다.
$ vi openshift-cluster-csi-drivers-operator-group.yaml
다음과 같이 YAML 파일을 편집합니다.
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: generateName: openshift-cluster-csi-drivers namespace: openshift-cluster-csi-drivers spec: targetNamespaces: - openshift-cluster-csi-drivers upgradeStrategy: Default
Operator 그룹을 생성합니다.
$ oc create -f openshift-cluster-csi-drivers-operator-group.yaml
샘플 출력
operatorgroup.operators.coreos.com/openshift-cluster-csi-driversjw9cd created
13.3.3. Nutanix CSI Operator 설치
Kubernetes용 Nutanix CSI(Container Storage Interface) Operator는 Nutanix CSI 드라이버를 배포하고 관리합니다.
Red Hat OpenShift Container Platform을 통해 이 단계를 수행하는 방법에 대한 자세한 내용은 추가 리소스에서 Nutanix CSI Operator 문서의 Operator 설치 섹션을 참조하십시오.
절차
Nutanix CSI Operator YAML 파일의 매개변수 값을 가져옵니다.
Nutanix CSI Operator가 있는지 확인합니다.
$ oc get packagemanifests | grep nutanix
샘플 출력
nutanixcsioperator Certified Operators 129m
Operator의 기본 채널을 BASH 변수에 할당합니다.
$ DEFAULT_CHANNEL=$(oc get packagemanifests nutanixcsioperator -o jsonpath={.status.defaultChannel})
Operator의 시작 CSV(클러스터 서비스 버전)를 BASH 변수에 할당합니다.
$ STARTING_CSV=$(oc get packagemanifests nutanixcsioperator -o jsonpath=\{.status.channels[*].currentCSV\})
서브스크립션의 카탈로그 소스를 BASH 변수에 할당합니다.
$ CATALOG_SOURCE=$(oc get packagemanifests nutanixcsioperator -o jsonpath=\{.status.catalogSource\})
Nutanix CSI Operator 소스 네임스페이스를 BASH 변수에 할당합니다.
$ SOURCE_NAMESPACE=$(oc get packagemanifests nutanixcsioperator -o jsonpath=\{.status.catalogSourceNamespace\})
BASH 변수를 사용하여 Nutanix CSI Operator YAML 파일을 생성합니다.
$ cat << EOF > nutanixcsioperator.yaml apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: nutanixcsioperator namespace: openshift-cluster-csi-drivers spec: channel: $DEFAULT_CHANNEL installPlanApproval: Automatic name: nutanixcsioperator source: $CATALOG_SOURCE sourceNamespace: $SOURCE_NAMESPACE startingCSV: $STARTING_CSV EOF
CSI Nutanix Operator를 생성합니다.
$ oc apply -f nutanixcsioperator.yaml
샘플 출력
subscription.operators.coreos.com/nutanixcsioperator created
Operator 서브스크립션 상태가
AtLatestKnown
으로 변경될 때까지 다음 명령을 실행합니다. 이는 Operator 서브스크립션이 생성되었으며 시간이 걸릴 수 있음을 나타냅니다.$ oc get subscription nutanixcsioperator -n openshift-cluster-csi-drivers -o 'jsonpath={..status.state}'
13.3.4. Nutanix CSI 스토리지 드라이버 배포
Kubernetes용 Nutanix CSI(Container Storage Interface) 드라이버는 상태 저장 애플리케이션을 위한 확장 가능하고 영구 스토리지를 제공합니다.
Red Hat OpenShift Container Platform을 통해 이 단계를 수행하는 방법에 대한 자세한 내용은 추가 리소스 의 Nutanix CSI Operator 문서의 Operator 섹션을 사용하여 CSI 드라이버 설치 섹션을 참조하십시오.
절차
드라이버를 배포할
NutanixCsiStorage
리소스를 생성합니다.$ cat <<EOF | oc create -f - apiVersion: crd.nutanix.com/v1alpha1 kind: NutanixCsiStorage metadata: name: nutanixcsistorage namespace: openshift-cluster-csi-drivers spec: {} EOF
샘플 출력
snutanixcsistorage.crd.nutanix.com/nutanixcsistorage created
CSI 스토리지 드라이버에 대한 Nutanix 시크릿 YAML 파일을 생성합니다.
$ cat <<EOF | oc create -f - apiVersion: v1 kind: Secret metadata: name: ntnx-secret namespace: openshift-cluster-csi-drivers stringData: # prism-element-ip:prism-port:admin:password key: <prismelement_address:prismelement_port:prismcentral_username:prismcentral_password> 1 EOF
참고- 1
- 동일한 형식을 유지하면서 이러한 매개변수를 실제 값으로 바꿉니다.
샘플 출력
secret/nutanix-secret created
13.3.5. 설치 후 구성 검증
다음 단계를 실행하여 구성을 검증합니다.
절차
스토리지 클래스를 생성할 수 있는지 확인합니다.
$ cat <<EOF | oc create -f - kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: nutanix-volume annotations: storageclass.kubernetes.io/is-default-class: 'true' provisioner: csi.nutanix.com parameters: csi.storage.k8s.io/fstype: ext4 csi.storage.k8s.io/provisioner-secret-namespace: openshift-cluster-csi-drivers csi.storage.k8s.io/provisioner-secret-name: ntnx-secret storageContainer: <nutanix_storage_container> 1 csi.storage.k8s.io/controller-expand-secret-name: ntnx-secret csi.storage.k8s.io/node-publish-secret-namespace: openshift-cluster-csi-drivers storageType: NutanixVolumes csi.storage.k8s.io/node-publish-secret-name: ntnx-secret csi.storage.k8s.io/controller-expand-secret-namespace: openshift-cluster-csi-drivers reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: Immediate EOF
참고- 1
- Nutanix_storage_container>는 Nutanix 구성에서 <nutanix_storage_container>를 사용합니다(예: SelfServiceContainer).
샘플 출력
storageclass.storage.k8s.io/nutanix-volume created
Nutanix PVC(영구 볼륨 클레임)를 생성할 수 있는지 확인합니다.
PVC(영구 볼륨 클레임)를 생성합니다.
$ cat <<EOF | oc create -f - kind: PersistentVolumeClaim apiVersion: v1 metadata: name: nutanix-volume-pvc namespace: openshift-cluster-csi-drivers annotations: volume.beta.kubernetes.io/storage-provisioner: csi.nutanix.com volume.kubernetes.io/storage-provisioner: csi.nutanix.com finalizers: - kubernetes.io/pvc-protection spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: nutanix-volume volumeMode: Filesystem EOF
샘플 출력
persistentvolumeclaim/nutanix-volume-pvc created
PVC(영구 볼륨 클레임) 상태가 Bound인지 확인합니다.
$ oc get pvc -n openshift-cluster-csi-drivers
샘플 출력
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE nutanix-volume-pvc Bound nutanix-volume 52s
14장. 선택사항: vSphere에 설치
vSphere에 OpenShift Container Platform을 설치하는 경우 지원 설치 관리자는 OpenShift Container Platform 클러스터를 vSphere에 노출하고 자동 스케일링을 활성화하는 vSphere 플랫폼과 통합할 수 있습니다.
14.1. vSphere에 호스트 추가
온라인 vSphere 클라이언트 또는 govc
vSphere CLI 툴을 사용하여 지원 설치 관리자 클러스터에 호스트를 추가할 수 있습니다. 다음 절차에서는 govc
CLI 툴을 사용하여 호스트를 추가하는 방법을 보여줍니다. 온라인 vSphere Client를 사용하려면 vSphere 설명서를 참조하십시오.
vSphere govc
CLI를 사용하여 vSphere에 호스트를 추가하려면 지원 설치 관리자에서 검색 이미지 ISO를 생성합니다. 최소 검색 이미지 ISO는 기본 설정입니다. 이 이미지에는 네트워킹으로 호스트를 부팅하는 데 필요한 항목만 포함됩니다. 대부분의 콘텐츠는 부팅 시 다운로드됩니다. ISO 이미지의 크기는 약 100MB입니다.
이 작업이 완료되면 vSphere 플랫폼의 이미지를 생성하고 vSphere 가상 머신을 생성해야 합니다.
사전 요구 사항
- vSphere 7.0.2 이상을 사용하고 있습니다.
-
vSphere
govc
CLI 툴이 설치되어 구성되어 있습니다. -
vSphere에서
clusterSet disk.enableUUID
를 true 로 설정해야 합니다. - 지원 설치 프로그램 UI에서 클러스터를 생성했거나
다음이 있습니다.
- API를 사용하여 지원 설치 관리자 클러스터 프로필 및 인프라 환경을 생성했습니다.
-
쉘의 인프라 환경 ID를
$INFRA_ENV_ID
로 내보냅니다. - 설정을 완료합니다.
절차
- ignition 파일로 부팅하려면 검색 이미지를 구성합니다.
지원 설치 관리자 UI에서 ISO를 생성하고 다운로드합니다.
- 호스트 검색에서 호스트 추가 버튼을 클릭하고 설치 미디어를 선택합니다.
- Minimal image file: Provision with virtual media 를 선택하여 부팅에 필요한 데이터를 가져올 작은 이미지를 다운로드합니다.
core
사용자로 vSphere VM에 연결할 수 있도록 SSH 공개 키를 추가합니다. 클러스터 호스트에 로그인하면 설치 중에 디버깅 정보를 제공할 수 있습니다.- 로컬 시스템에 기존 SSH 키 쌍이 없는 경우 클러스터 노드 SSH 액세스에 대한 키 쌍 생성 단계를 따르십시오.
-
SSH 공개 키 필드에서 찾아보기 를 클릭하여 SSH 공개 키가 포함된
id_rsa.pub
파일을 업로드합니다. 또는 파일을 파일 관리자의 필드로 끌어다 놓습니다. 파일 관리자에서 파일을 보려면 메뉴에서 숨겨진 파일 표시를 선택합니다.
- 선택 사항: 클러스터 호스트가 프록시를 사용해야 하는 방화벽 뒤에 있는 경우 클러스터 전체 프록시 설정 구성을 선택합니다. 프록시 서버의 HTTP 및 HTTPS URL에 대한 사용자 이름, 암호, IP 주소 및 포트를 입력합니다.
- 선택 사항: 클러스터 호스트가 재암호화 MITM(man-in-the-middle) 프록시를 사용하는 네트워크에 있거나 클러스터가 컨테이너 이미지 레지스트리와 같은 다른 용도로 인증서를 신뢰해야 하는 경우 클러스터 전체에서 신뢰할 수 있는 인증서 구성을 선택하고 추가 인증서를 추가해야 합니다.
- 선택 사항: Ignition 파일로 부팅하려면 검색 이미지를 구성합니다. 자세한 내용은 검색 이미지 구성을 참조하십시오.
- Discovery ISO 생성을 클릭합니다.
- Discovery ISO URL 을 복사합니다.
검색 ISO를 다운로드합니다.
$ wget - O vsphere-discovery-image.iso <discovery_url>
&
lt;discovery_url&
gt;을 이전 단계의 URL로 바꿉니다.
명령줄에서 기존 가상 머신의 전원을 끄고 삭제합니다.
$ 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;를 데이터 센터 이름으로 바꿉니다. <folder_name
>을 VM 인벤토리 폴더의 이름으로 바꿉니다.데이터 저장소에서 기존 ISO 이미지를 제거합니다(있는 경우).
$ govc datastore.rm -ds <iso_datastore> <image>
&
lt;iso_datastore
>를 데이터 저장소 이름으로 교체합니다.이미지를
ISO 이미지의 이름으로 바꿉니다.지원 설치 관리자 검색 ISO를 업로드합니다.
$ govc datastore.upload -ds <iso_datastore> vsphere-discovery-image.iso
&
lt;iso_datastore
>를 데이터 저장소 이름으로 교체합니다.참고클러스터의 모든 노드는 검색 이미지에서 부팅해야 합니다.
컨트롤 플레인 (마스터) 노드 세 개를 부팅합니다.
$ 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 을 참조하십시오.
참고위 예제에서는 컨트롤 플레인 노드에 필요한 최소 리소스를 보여줍니다.
두 개 이상의 작업자 노드를 부팅합니다.
$ 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 을 참조하십시오.
참고위 예제에서는 작업자 노드에 필요한 최소 리소스를 보여줍니다.
VM이 실행 중인지 확인합니다.
$ govc ls /<datacenter>/vm/<folder_name>
&
lt;datacenter&
gt;를 데이터 센터 이름으로 바꿉니다. <folder_name
>을 VM 인벤토리 폴더의 이름으로 바꿉니다.2분 후 VM을 종료합니다.
$ for VM in $(govc ls /<datacenter>/vm/<folder_name>) do govc vm.power -s=true $VM done
&
lt;datacenter&
gt;를 데이터 센터 이름으로 바꿉니다. <folder_name
>을 VM 인벤토리 폴더의 이름으로 바꿉니다.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;를 데이터 센터 이름으로 바꿉니다. <folder_name
>을 VM 인벤토리 폴더의 이름으로 바꿉니다.참고vSphere로 자동 스케일링을 활성화하려면 모든 노드에서
disk.enableUUID
를TRUE
로 설정해야 합니다.VM을 재시작합니다.
$ for VM in $(govc ls /<datacenter>/vm/<folder_name>) do govc vm.power -on=true $VM done
&
lt;datacenter&
gt;를 데이터 센터 이름으로 바꿉니다. <folder_name
>을 VM 인벤토리 폴더의 이름으로 바꿉니다.-
지원 설치 관리자 사용자 인터페이스로 돌아가서 지원 설치 프로그램이 호스트를 검색하고 각각
Ready
상태가 될 때까지 기다립니다. - vSphere 와의 통합을 활성화하려면 가상화 플랫폼과 통합하십시오.
- 필요한 경우 역할을 선택합니다.
- Networking 에서 DHCP 서버를 통한 IP 할당을 선택 해제합니다.
- API VIP 주소를 설정합니다.
- Ingress VIP 주소를 설정합니다.
- 설치 절차를 계속합니다.
14.2. CLI를 사용한 vSphere 설치 후 구성
플랫폼 통합 기능이 활성화된 vSphere에서 지원 설치 관리자를 사용하여 OpenShift Container Platform 클러스터를 설치한 후 다음 vSphere 구성 설정을 수동으로 업데이트해야 합니다.
- vCenter 사용자 이름
- vCenter 암호
- vCenter 주소
- vCenter 클러스터
- 데이터 센터
- 데이터 저장소
- 폴더
사전 요구 사항
- 지원 설치 프로그램이 클러스터 설치를 성공적으로 완료했습니다.
- 클러스터가 console.redhat.com 에 연결되어 있습니다.
절차
vCenter에 대한 base64로 인코딩된 사용자 이름 및 암호를 생성합니다.
$ echo -n "<vcenter_username>" | base64 -w0
<
;vcenter_username>
;을 vCenter 사용자 이름으로 교체합니다.$ echo -n "<vcenter_password>" | base64 -w0
&
lt;vcenter_password>
;를 vCenter 암호로 교체합니다.vSphere 인증 정보를 백업합니다.
$ oc get secret vsphere-creds -o yaml -n kube-system > creds_backup.yaml
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>
;를 vCenter 주소로 바꿉니다. <vcenter_username_encoded&
gt;를 vSphere 사용자 이름의 base64 인코딩 버전으로 바꿉니다. <vcenter_password_encoded
>를 vSphere 암호 base64 인코딩 버전으로 바꿉니다.vSphere 인증 정보를 교체합니다.
$ oc replace -f vsphere-creds.yaml
kube-controller-manager Pod를 재배포합니다.
$ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
vSphere 클라우드 공급자 구성을 백업합니다.
$ oc get cm cloud-provider-config -o yaml -n openshift-config > cloud-provider-config_backup.yaml
클라우드 공급자 구성을 편집합니다.
$ 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>
;를 vCenter 주소로 바꿉니다. <datacenter
>를 데이터 센터 이름으로 교체합니다. <datastore
>를 데이터 저장소 이름으로 바꿉니다. <folder&
gt;를 클러스터 VM이 포함된 폴더로 바꿉니다.클라우드 공급자 구성을 적용합니다.
$ oc apply -f cloud-provider-config.yaml
초기화되지 않은
테인트가 있는 노드에 테인트를 적용합니다.중요OpenShift Container Platform 4.13 이상을 설치하는 경우 9~12단계를 따르십시오.
테인트할 노드를 식별합니다.
$ oc get nodes
각 노드에 대해 다음 명령을 실행합니다.
$ 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
인프라 구성을 백업합니다.
$ oc get infrastructures.config.openshift.io -o yaml > infrastructures.config.openshift.io.yaml.backup
인프라 구성을 편집합니다.
$ cp infrastructures.config.openshift.io.yaml.backup infrastructures.config.openshift.io.yaml
$ vi infrastructures.config.openshift.io.yaml
apiVersion: v1 items: - apiVersion: config.openshift.io/v1 kind: Infrastructure metadata: creationTimestamp: "2023-05-07T10:19:55Z" generation: 1 name: cluster resourceVersion: "536" uid: e8a5742c-6d15-44e6-8a9e-064b26ab347d spec: cloudConfig: key: config name: cloud-provider-config platformSpec: type: VSphere vsphere: failureDomains: - name: assisted-generated-failure-domain region: assisted-generated-region server: <vcenter_address> topology: computeCluster: /<data_center>/host/<vcenter_cluster> datacenter: <data_center> datastore: /<data_center>/datastore/<datastore> folder: "/<data_center>/path/to/folder" networks: - "VM Network" resourcePool: /<data_center>/host/<vcenter_cluster>/Resources zone: assisted-generated-zone nodeNetworking: external: {} internal: {} vcenters: - datacenters: - <data_center> server: <vcenter_address> kind: List metadata: resourceVersion: ""
&
lt;vcenter_address>
;를 vCenter 주소로 바꿉니다. <datacenter
>를 vCenter 데이터 센터의 이름으로 바꿉니다. <datastore&
gt;를 vCenter 데이터 저장소의 이름으로 바꿉니다. <folder&
gt;를 클러스터 VM이 포함된 폴더로 바꿉니다. <vcenter_cluster&
gt;를 OpenShift Container Platform이 설치된 vSphere vCenter 클러스터로 바꿉니다.인프라 구성을 적용합니다.
$ oc apply -f infrastructures.config.openshift.io.yaml --overwrite=true
14.3. UI를 사용한 vSphere 설치 후 구성
플랫폼 통합 기능이 활성화된 vSphere에서 지원 설치 관리자를 사용하여 OpenShift Container Platform 클러스터를 설치한 후 다음 vSphere 구성 설정을 수동으로 업데이트해야 합니다.
- vCenter 주소
- vCenter 클러스터
- vCenter 사용자 이름
- vCenter 암호
- 데이터 센터
- 기본 데이터 저장소
- 가상 머신 폴더
사전 요구 사항
- 지원 설치 프로그램이 클러스터 설치를 성공적으로 완료했습니다.
- 클러스터가 console.redhat.com 에 연결되어 있습니다.
절차
- 관리자 관점에서 홈 → 개요 로 이동합니다.
- 상태 에서 vSphere 연결을 클릭하여 vSphere 연결 구성 마법사를 엽니다.
-
vCenter 필드에 vSphere vCenter 서버의 네트워크 주소를 입력합니다. 도메인 이름 또는 IP 주소일 수 있습니다. vSphere 웹 클라이언트 URL(예:
https://[your_vCenter_address]/ui
)에 나타납니다. vCenter 클러스터 필드에 OpenShift Container Platform이 설치된 vSphere vCenter 클러스터의 이름을 입력합니다.
중요이 단계는 OpenShift Container Platform 4.13 이상을 설치한 경우 필수입니다.
- Username 필드에 vSphere vCenter 사용자 이름을 입력합니다.
암호 필드에 vSphere vCenter 암호를 입력합니다.
주의시스템은 클러스터의
kube-system
네임스페이스에vsphere-creds
시크릿에 사용자 이름과 암호를 저장합니다. 잘못된 vCenter 사용자 이름 또는 암호를 사용하면 클러스터 노드를 예약할 수 없습니다.-
Datacenter 필드에 클러스터를 호스팅하는 데 사용되는 가상 머신이 포함된 vSphere 데이터 센터의 이름을 입력합니다(예:
SDDC-Datacenter
). Default 데이터 저장소 필드에 영구 데이터 볼륨을 저장하는 vSphere 데이터 저장소를 입력합니다(예:
/SDDC-Datacenter/datastore/datastore/datastore
).주의구성이 저장된 후 vSphere 데이터 센터 또는 기본 데이터 저장소를 업데이트한 후 활성 vSphere
PersistentVolumes
를 분리합니다.-
가상 머신 폴더 필드에 클러스터의 가상 머신이 포함된 데이터 센터 폴더(예:
/SDDC-Datacenter/vm/ci-ln-hjg4vg2-c61657-t2gzr
)를 입력합니다. OpenShift Container Platform 설치가 성공하려면 클러스터를 구성하는 모든 가상 머신이 단일 데이터 센터 폴더에 있어야 합니다. -
Save Configuration 을 클릭합니다. 이렇게 하면
openshift-config
네임스페이스에서cloud-provider-config
파일이 업데이트되고 구성 프로세스가 시작됩니다. - vSphere 연결 구성 마법사를 다시 열고 모니터된 Operator 패널을 확장합니다. Operator의 상태가 Progressing 또는 Healthy 인지 확인합니다.
검증
연결 구성 프로세스는 Operator 상태 및 컨트롤 플레인 노드를 업데이트합니다. 완료하는 데 약 1 시간이 걸립니다. 구성 프로세스 중에 노드가 재부팅됩니다. 이전에는 바인딩된 PersistentVolumeClaims
오브젝트가 연결이 끊어질 수 있었습니다.
다음 단계에 따라 구성 프로세스를 모니터링합니다.
구성 프로세스가 성공적으로 완료되었는지 확인합니다.
- OpenShift Container Platform 관리자 화면에서 홈 → 개요 로 이동합니다.
- Status (상태)에서 Operators 를 클릭합니다. 모든 Operator 상태가 Progressing 에서 All succeeded 로 변경될 때까지 기다립니다. 실패 상태는 구성이 실패했음을 나타냅니다.
- 상태에서 컨트롤 플레인 을 클릭합니다. 모든 컨트롤 Pane 구성 요소의 응답 속도가 100%로 반환될 때까지 기다립니다. 실패한 컨트롤 플레인 구성 요소는 구성이 실패했음을 나타냅니다.
오류가 발생하면 연결 설정 중 하나 이상이 올바르지 않음을 나타냅니다. vSphere 연결 구성 마법사에서 설정을 변경하고 구성을 다시 저장합니다.
다음 단계를 수행하여
PersistentVolumeClaims
오브젝트를 바인딩할 수 있는지 확인합니다.다음 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
다음 YAML을 사용하여
PersistentVolumeClaims
오브젝트를 생성합니다.kind: PersistentVolumeClaim apiVersion: v1 metadata: name: test-pvc namespace: openshift-config annotations: volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume finalizers: - kubernetes.io/pvc-protection spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: vsphere-sc volumeMode: Filesystem
자세한 내용은 OpenShift Container Platform 설명서의 동적 프로비저닝 을 참조하십시오.
PersistentVolumeClaims
오브젝트의 문제를 해결하려면 OpenShift Container Platform UI의 관리자 화면에서 스토리지 → PersistentVolumeClaims 로 이동합니다.
15장. 문제 해결
지원 설치 프로그램이 설치를 시작할 수 없거나 클러스터가 제대로 설치되지 않는 경우가 있습니다. 이러한 이벤트에서는 가능한 오류 모드와 오류 문제를 해결하는 방법을 이해하는 것이 도움이 됩니다.
15.1. 사전 요구 사항
- API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.
15.2. 검색 ISO 문제 해결
지원 설치 관리자는 ISO 이미지를 사용하여 호스트를 클러스터에 등록하고 OpenShift를 설치하기 전에 하드웨어 및 네트워크 검증을 수행하는 에이전트를 실행합니다. 다음 절차에 따라 호스트 검색과 관련된 문제를 해결할 수 있습니다.
검색 ISO 이미지로 호스트를 시작하면 지원 설치 프로그램이 호스트를 검색하여 지원 서비스 UI에 표시합니다.
자세한 내용은 검색 이미지 구성을 참조하십시오.
15.3. 최소 ISO 이미지
가상 미디어 연결을 통한 대역폭이 제한될 때 최소 ISO 이미지를 사용해야 합니다. 여기에는 네트워킹으로 호스트를 부팅하는 데 필요한 항목만 포함됩니다. 대부분의 콘텐츠는 부팅 시 다운로드됩니다. 결과 ISO 이미지는 전체 ISO 이미지의 경우 1GB와 비교하여 약 100MB 크기입니다.
15.3.1. 최소 ISO 부팅 실패 문제 해결
환경에 지원 설치 관리자 서비스에 액세스하기 위해 정적 네트워크 구성이 필요한 경우 해당 구성에 대한 모든 문제가 Minimal ISO가 제대로 부팅되지 않을 수 있습니다. 부팅 화면에 호스트가 루트 파일 시스템 이미지를 다운로드하지 못한 것으로 표시되면 추가 네트워크 구성이 올바른지 확인합니다. 전체 ISO 이미지로 전환하면 더 쉽게 디버깅할 수 있습니다.
rootfs 다운로드 실패의 예
15.4. 검색 에이전트가 실행 중인지 확인
사전 요구 사항
- API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.
- 인프라 환경 검색 ISO로 호스트를 부팅했으며 호스트가 등록하지 못했습니다.
- 호스트에 대한 ssh 액세스 권한이 있습니다.
- 암호 없이 시스템에 SSH로 연결할 수 있도록 Discovery ISO를 생성하기 전에 "호스트 추가" 대화 상자에 SSH 공개 키를 제공했습니다.
절차
- 호스트 시스템의 전원이 켜져 있는지 확인합니다.
- DHCP 네트워킹을 선택한 경우 DHCP 서버가 활성화되어 있는지 확인합니다.
- 고정 IP, 브리지 및 본딩 네트워킹을 선택한 경우 구성이 올바른지 확인합니다.
SSH, BMC와 같은 콘솔 또는 가상 머신 콘솔을 사용하여 호스트 머신에 액세스할 수 있는지 확인합니다.
$ ssh core@<host_ip_address>
기본 디렉터리에 저장되지 않는 경우
-i
매개변수를 사용하여 개인 키 파일을 지정할 수 있습니다.$ ssh -i <ssh_private_key_file> core@<host_ip_address>
호스트에 ssh를 사용하지 않으면 부팅 중에 호스트가 실패하거나 네트워크를 구성하지 못했습니다.
로그인 시 다음 메시지가 표시됩니다.
login 예
이 메시지가 표시되지 않으면 호스트가 assisted-installer ISO로 부팅되지 않았음을 의미합니다. 부팅 순서를 올바르게 구성했는지 확인합니다(호스트가 live-ISO에서 한 번 부팅되어야 함).
에이전트 서비스 로그를 확인합니다.
$ sudo journalctl -u agent.service
다음 예에서 오류는 네트워크 문제가 있음을 나타냅니다.
에이전트 서비스 로그의 에이전트 서비스 로그 스크린샷의 예
에이전트 이미지를 가져오는 데 오류가 발생하면 프록시 설정을 확인합니다. 호스트가 네트워크에 연결되어 있는지 확인합니다.
nmcli
를 사용하여 네트워크 구성에 대한 추가 정보를 가져올 수 있습니다.
15.5. 에이전트가 assisted-service에 액세스할 수 있는지 확인
사전 요구 사항
- API를 사용하여 인프라 환경을 생성하거나 UI를 사용하여 클러스터를 생성했습니다.
- 인프라 환경 검색 ISO로 호스트를 부팅했으며 호스트가 등록하지 못했습니다.
- 검색 에이전트가 실행 중인지 확인했습니다.
절차
에이전트 로그를 확인하여 에이전트가 지원 서비스에 액세스할 수 있는지 확인합니다.
$ sudo journalctl TAG=agent
다음 예의 오류는 에이전트가 지원 서비스에 액세스하지 못했음을 나타냅니다.
에이전트 로그 예
클러스터에 대해 구성한 프록시 설정을 확인합니다. 구성된 경우 프록시에서 지원 서비스 URL에 대한 액세스를 허용해야 합니다.
15.6. 호스트의 부팅 순서 수정
Discovery Image의 일부로 실행되는 설치가 완료되면 지원 설치 관리자에서 호스트를 재부팅합니다. 계속 클러스터를 형성하려면 호스트가 설치 디스크에서 부팅되어야 합니다. 호스트의 부팅 순서를 올바르게 구성하지 않은 경우 대신 다른 디스크에서 부팅되어 설치를 중단합니다.
호스트가 검색 이미지를 다시 부팅하면 지원 설치 프로그램이 즉시 이 이벤트를 감지하고 호스트의 상태를 보류 중인 사용자 작업 설치 로 설정합니다. 또는 지원 설치 프로그램이 할당된 시간 내에 호스트가 올바른 디스크를 부팅했는지 감지하지 못하면 이 호스트 상태도 설정됩니다.
절차
- 호스트를 재부팅하고 설치 디스크에서 부팅하도록 부팅 순서를 설정합니다. 설치 디스크를 선택하지 않은 경우 지원 설치 프로그램이 사용자를 위해 선택한 디스크를 선택했습니다. 선택한 설치 디스크를 보려면 호스트 인벤토리에서 호스트 정보를 확장하고 "설치 디스크" 역할이 있는지 확인합니다.
15.7. 부분적으로 필요한 설치 해결
지원 설치 프로그램이 오류가 발생하더라도 성공적으로 설치를 선언하는 경우가 있습니다.
- OLM Operator를 설치하도록 요청했는데 설치 실패가 하나 이상 실패한 경우 클러스터 콘솔에 로그인하여 오류를 해결합니다.
- 두 개 이상의 작업자 노드를 설치하도록 요청했지만 하나 이상의 작업자를 설치에 실패한 경우 두 개 이상의 성공으로 구성된 작업자를 설치된 클러스터에 추가합니다.