검색

지원 설치 관리자를 사용하여 OpenShift Container Platform 설치

download PDF
Assisted Installer for OpenShift Container Platform 2024

사용자 가이드

Red Hat Customer Content Services

초록

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

머리말

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 이러한 변경 사항은 가능한 한 점진적으로 업데이트되고 있습니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

Red Hat 문서에 관한 피드백 제공

Jira에서 문제 생성 양식을 제출하여 피드백을 제공하거나 오류를 보고할 수 있습니다. Jira 문제는 Red Hat Hybrid Cloud Infrastructure Jira 프로젝트에서 생성되어 피드백의 진행 상황을 추적할 수 있습니다.

  1. Jira에 로그인했는지 확인합니다. Jira 계정이 없는 경우 피드백을 제출할 계정을 생성합니다.
  2. 문제 생성을클릭합니다.

    1. 요약설명 필드를 작성합니다. 설명 필드에 문서 URL, 장 또는 섹션 번호, 문제에 대한 자세한 설명을 포함합니다. 양식의 다른 필드를 수정하지 마십시오.
  3. 생성을 클릭합니다.

문서 개선을 위한 의견에 감사드립니다.

1장. 지원 설치 관리자 정보

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

다음 플랫폼의 경우 선택적 HTTP/S 프록시를 사용하여 연결된 환경의 온프레미스에 OpenShift Container Platform을 설치할 수 있습니다.

  • 고가용성 OpenShift Container Platform 또는 단일 노드 OpenShift 클러스터
  • 완전한 플랫폼 통합 또는 통합이 없는 기타 가상화 플랫폼이 있는 베어 메탈 또는 vSphere의 OpenShift Container Platform
  • 선택적으로 OpenShift Virtualization 및 Red Hat OpenShift Data Foundation

1.1. 기능

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

웹 인터페이스
부트스트랩 노드 없음
  • 부트스트랩 프로세스가 클러스터 내의 노드에서 실행되므로 부트스트랩 노드가 필요하지 않습니다.
간소화된 설치 워크플로
  • 클러스터를 배포하기 위해 OpenShift Container Platform에 대한 지식이 필요하지 않습니다. 지원 설치 프로그램은 적절한 기본 구성을 제공합니다.
  • OpenShift Container Platform 설치 프로그램을 로컬에서 실행할 필요가 없습니다.
  • 최신 테스트된 z-stream 릴리스의 최신 지원 설치 프로그램에 액세스할 수 있습니다.
고급 네트워킹 옵션
  • 지원 설치 프로그램은 OVN만, NMState 기반 고정 IP 주소 지정 및 HTTP/S 프록시가 있는 SDN 및 OVN, IPv6 및 듀얼 스택 네트워킹을 사용하여 IPv4 네트워킹을 지원합니다.
  • OVN은 OpenShift Container Platform 4.12 이상의 기본 CNI(Container Network Interface)입니다.
  • SDN은 OpenShift Container Platform 4.14까지 지원되며 OpenShift Container Platform 4.15에서 더 이상 사용되지 않습니다.
사전 설치 검증
  • 설치하기 전에 지원 설치 프로그램에서 다음 구성을 확인합니다.

    • 네트워크 연결
    • 네트워크 대역폭
    • 레지스트리에 연결
    • 도메인 이름의 업스트림 DNS 확인
    • 클러스터 노드 간 시간 동기화
    • 클러스터 노드 하드웨어
    • 설치 구성 매개변수
REST API
  • 지원 설치 관리자 REST API를 사용하여 설치 프로세스를 자동화할 수 있습니다.

1.2. 설치 사용자 정의

하나 이상의 옵션을 선택하여 설치를 사용자 지정할 수 있습니다.

이러한 옵션은 컨트롤 플레인에서 서비스 및 애플리케이션을 패키지, 배포 및 관리하는 데 사용되는 Operator로 설치됩니다.

고급 구성 옵션이 필요한 경우 설치 후 이러한 Operator를 배포할 수 있습니다.

OpenShift Virtualization

OpenShift Virtualization을 배포하여 다음 작업을 수행할 수 있습니다.

  • Linux 및 Windows VM(가상 머신)을 생성하고 관리합니다.
  • 클러스터에서 서로 함께 Pod 및 VM 워크로드를 실행합니다.
  • 다양한 콘솔 및 CLI 툴을 통해 VM에 연결합니다.
  • 기존 VM을 가져오고 복제합니다.
  • VM에 연결된 네트워크 인터페이스 컨트롤러 및 스토리지 디스크를 관리합니다.
  • 노드 간에 VM을 실시간 마이그레이션합니다.
Kubernetes용 다중 클러스터 엔진

Kubernetes용 다중 클러스터 엔진을 배포하여 대규모 다중 클러스터 환경에서 다음 작업을 수행할 수 있습니다.

  • 초기 클러스터에서 추가 Kubernetes 클러스터를 프로비저닝하고 관리합니다.
  • 호스팅된 컨트롤 플레인을 사용하여 관리 비용을 줄이고 컨트롤 및 데이터 플레인을 분리하여 클러스터 배포를 최적화합니다.
  • GitOps Zero Touch Provisioning을 사용하여 대규모로 원격 에지 사이트를 관리합니다.

    모든 OpenShift Container Platform 클러스터에 Red Hat OpenShift Data Foundation을 사용하여 다중 클러스터 엔진을 배포할 수 있습니다.

중요

OpenShift Data Foundation 없이 다중 클러스터 엔진을 배포하면 다음과 같은 시나리오가 발생합니다.

  • 다중 노드 클러스터: 스토리지가 구성되지 않았습니다. 설치 프로세스 후 스토리지를 구성해야 합니다.
  • 단일 노드 OpenShift: LVM 스토리지가 설치되어 있습니다.

환경에 다중 클러스터 엔진에 대한 추가 리소스가 충분한지 확인하려면 사전 요구 사항을 검토해야 합니다.

논리 볼륨 관리자 스토리지
LVM 스토리지(Logical Volume Manager Storage)를 사용하여 제한된 리소스 클러스터에서 블록 스토리지를 동적으로 프로비저닝할 수 있습니다.
Red Hat OpenShift Data Foundation
파일, 블록 및 오브젝트 스토리지에 Red Hat OpenShift Data Foundation을 사용할 수 있습니다. 이 스토리지 옵션은 모든 OpenShift Container Platform 클러스터에 권장됩니다. OpenShift Data Foundation에는 별도의 서브스크립션이 필요합니다.

1.3. API 지원 정책

지원 설치 관리자 API는 사용 중단 발표 후 최소 3개월 동안 지원됩니다.

2장. 사전 요구 사항

지원 설치 프로그램은 설치에 성공했는지 확인하기 위해 다음 사전 요구 사항을 검증합니다.

방화벽을 사용하는 경우 지원 설치 프로그램이 작동하는 데 필요한 리소스에 액세스할 수 있도록 방화벽을 구성해야 합니다.

2.1. 지원되는 CPU 아키텍처

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

  • x86_64
  • arm64
  • ppc64le
  • s390x

2.2. 리소스 요구 사항

이 섹션에서는 다양한 클러스터 및 설치 옵션에 대한 리소스 요구 사항에 대해 설명합니다.

Kubernetes용 다중 클러스터 엔진에는 추가 리소스가 필요합니다.

OpenShift Data Foundation 또는 LVM Storage와 같은 스토리지를 사용하여 다중 클러스터 엔진을 배포하는 경우 각 노드에 추가 리소스도 할당해야 합니다.

2.2.1. 다중 노드 클러스터 리소스 요구 사항

다중 노드 클러스터의 리소스 요구 사항은 설치 옵션에 따라 다릅니다.

다중 노드 클러스터 기본 설치
  • 컨트롤 플레인 노드:

  • 컴퓨팅 노드:

    • CPU 코어 2개
    • 8GB RAM
    • 100GB 스토리지
다중 노드 클러스터 + 다중 클러스터 엔진
  • 추가 4 CPU 코어
  • 추가 16GB RAM

    참고

    OpenShift Data Foundation 없이 다중 클러스터 엔진을 배포하는 경우 스토리지가 구성되지 않습니다. 설치 후 스토리지를 구성합니다.

다중 노드 클러스터 + 다중 클러스터 엔진 + OpenShift Data Foundation 또는 LVM 스토리지
  • 추가 75GB 스토리지

2.2.2. 단일 노드 OpenShift 리소스 요구 사항

단일 노드 OpenShift의 리소스 요구 사항은 설치 옵션에 따라 다릅니다.

단일 노드 OpenShift 기본 설치
  • 8개의 CPU 코어
  • 16GB RAM
  • 100GB 스토리지
단일 노드 OpenShift + 다중 클러스터 엔진
  • 8 CPU 코어 추가
  • 추가 32GB RAM

    참고

    OpenShift Data Foundation 없이 다중 클러스터 엔진을 배포하면 LVM 스토리지가 활성화됩니다.

단일 노드 OpenShift + 다중 클러스터 엔진 + OpenShift Data Foundation 또는 LVM 스토리지
  • 추가95GB 스토리지

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 툴을 통해 클러스터에 액세스할 수 있도록 하려면 포트 6443 이 API URL에 열려 있습니다.
  • 방화벽 외부의 사용자가 콘솔에 액세스하도록 허용하려면 콘솔에 포트 443 이 열려 있습니다.
  • 사용자 관리 네트워킹을 사용할 때 클러스터의 각 노드에 대한 DNS A/AAAA 레코드가 진행되지 않습니다. 클러스터에 연결하기 위해 설치 후 Cluster Managed Networking을 사용할 때 클러스터의 각 노드에 DNS A/AAAA 레코드가 필요하지만 Cluster Managed Networking을 사용할 때 A/AAAA 레코드 없이 설치를 진행할 수 있습니다.
  • 고정 IP 주소를 사용할 때 사전 설정된 호스트 이름으로 부팅하려는 경우 클러스터의 각 노드의 DNS PTR 레코드입니다. 그렇지 않으면 노드의 이름을 네트워크 인터페이스 MAC 주소로 이름을 바꾸는 고정 IP 주소를 사용할 때 지원 설치 관리자의 자동 노드 이름 변경 기능이 있습니다.
중요
  • 최상위 도메인 등록 기관의 DNS A/AAAA 레코드 설정은 업데이트하는 데 상당한 시간이 걸릴 수 있습니다. 설치 지연을 방지하기 위해 설치 전에 A/AAAA 레코드 DNS 설정이 작동하는지 확인합니다.
  • DNS 레코드 예제는 이 장의 DNS 구성 예제 를 참조하십시오.

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

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

2.4. DNS 구성 예

이 섹션에서는 지원 설치 관리자를 사용하여 OpenShift Container Platform 배포를 위한 DNS 요구 사항을 충족하는 A 및 PTR 레코드 구성 예제를 제공합니다. 이 예제에서는 하나의 DNS 솔루션을 선택하기 위한 조언을 제공하기 위한 것이 아닙니다.

이 예제에서 클러스터 이름은 ocp4이고 기본 도메인은 example.com입니다.

2.4.1. DNS A 레코드 구성 예

다음 예제는 지원 설치 관리자를 사용하여 설치된 클러스터의 이름 확인을 위한 샘플 A 레코드를 보여주는 BIND 영역 파일입니다.

DNS 영역 데이터베이스 예

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
	IN	MX 10	smtp.example.com.
;
;
ns1.example.com.		IN	A	192.168.1.1
smtp.example.com.		IN	A	192.168.1.5
;
helper.example.com.		IN	A	192.168.1.5
;
api.ocp4.example.com.		IN	A	192.168.1.5 1
api-int.ocp4.example.com.	IN	A	192.168.1.5 2
;
*.apps.ocp4.example.com.	IN	A	192.168.1.5 3
;
control-plane0.ocp4.example.com.	IN	A	192.168.1.97 4
control-plane1.ocp4.example.com.	IN	A	192.168.1.98
control-plane2.ocp4.example.com.	IN	A	192.168.1.99
;
worker0.ocp4.example.com.	IN	A	192.168.1.11 5
worker1.ocp4.example.com.	IN	A	192.168.1.7
;
;EOF

1
Kubernetes API의 이름 확인을 제공합니다. 레코드는 API 로드 밸런서의 IP 주소를 나타냅니다.
2
Kubernetes API의 이름 확인을 제공합니다. 레코드는 API 로드 밸런서의 IP 주소를 참조하며 내부 클러스터 통신에 사용됩니다.
3
와일드카드 경로의 이름 확인을 제공합니다. 레코드는 애플리케이션 인그레스 로드 밸런서의 IP 주소를 나타냅니다. 애플리케이션 인그레스 로드 밸런서는 Ingress 컨트롤러 Pod를 실행하는 머신을 대상으로 합니다. Ingress 컨트롤러 Pod는 기본적으로 작업자 머신에서 실행됩니다.
참고

이 예제에서는 Kubernetes API 및 애플리케이션 인그레스 트래픽에 동일한 로드 밸런서를 사용합니다. 프로덕션 시나리오에서는 각각에 대해 개별적으로 로드 밸런서 인프라를 확장할 수 있도록 API 및 애플리케이션 인그레스 로드 밸런서를 별도로 배포할 수 있습니다.

4
컨트롤 플레인 시스템의 이름 확인을 제공합니다.
5
작업자 시스템의 이름 확인을 제공합니다.

2.4.2. DNS PTR 레코드 구성의 예

다음 예제는 지원 설치 관리자를 사용하여 설치된 클러스터의 역방향 이름 확인을 위한 샘플 PTR 레코드를 보여주는 BIND 영역 파일입니다.

역방향 레코드에 대한 DNS 영역 데이터베이스의 예

$$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
;
5.1.168.192.in-addr.arpa.	IN	PTR	api.ocp4.example.com. 1
5.1.168.192.in-addr.arpa.	IN	PTR	api-int.ocp4.example.com. 2
;
97.1.168.192.in-addr.arpa.	IN	PTR	control-plane0.ocp4.example.com. 3
98.1.168.192.in-addr.arpa.	IN	PTR	control-plane1.ocp4.example.com.
99.1.168.192.in-addr.arpa.	IN	PTR	control-plane2.ocp4.example.com.
;
11.1.168.192.in-addr.arpa.	IN	PTR	worker0.ocp4.example.com. 4
7.1.168.192.in-addr.arpa.	IN	PTR	worker1.ocp4.example.com.
;
;EOF

1
Kubernetes API의 역방향 DNS 확인을 제공합니다. PTR 레코드는 API 로드 밸런서의 레코드 이름을 참조합니다.
2
Kubernetes API의 역방향 DNS 확인을 제공합니다. PTR 레코드는 API 로드 밸런서의 레코드 이름을 참조하며 내부 클러스터 통신에 사용됩니다.
3
컨트롤 플레인 시스템의 역방향 DNS 확인을 제공합니다.
4
작업자 시스템의 역방향 DNS 확인을 제공합니다.
참고

OpenShift Container Platform 애플리케이션 와일드카드에는 PTR 레코드가 필요하지 않습니다.

2.5. preflight 검증

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

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

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

3장. 지원 설치 관리자 웹 콘솔 설치

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

3.1. 사전 설치 고려 사항

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

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

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

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

프로세스

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

    참고

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

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

    중요
    • IBM Power 및 IBM zSystems 플랫폼의 경우 OpenShift Container Platform 4.13 이상만 지원됩니다.
    • 혼합 아키텍처 클러스터 설치의 경우 OpenShift Container Platform 4.12 이상을 선택하고 -multi 옵션을 사용합니다. 혼합 아키텍처 클러스터 설치에 대한 자세한 내용은 추가 리소스를 참조하십시오.
  10. 선택 사항: 단일 노드에 OpenShift Container Platform을 설치하려면 Install single node Openshift (SNO) 를 선택합니다.

    참고

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

  11. 선택 사항: 지원 설치 프로그램에 이미 계정에 연결된 풀 시크릿이 있습니다. 다른 풀 시크릿을 사용하려면 풀 시크릿 편집을 선택합니다.
  12. 선택 사항: 타사 플랫폼에 OpenShift Container Platform을 설치하는 경우 외부 파트 플랫폼 목록과 통합 플랫폼을 선택합니다. 유효한 값은 Nutanix,vSphere 또는 Oracle Cloud Infrastructure 입니다. 지원 설치 관리자의 기본값은 플랫폼 통합이 없습니다.

    참고

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

    중요

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

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

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

    중요

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

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

    중요
    • Oracle Cloud Infrastructure(OCI) 타사 플랫폼에 OpenShift Container Platform을 설치하는 경우 Oracle에서 제공하는 사용자 정의 매니페스트를 추가해야 합니다.
    • 사용자 정의 매니페스트를 이미 추가한 경우 사용자 정의 매니페스트 포함 상자를 선택 해제하면 모두 자동으로 삭제됩니다. 삭제를 확인하라는 메시지가 표시됩니다.
  15. 선택 사항: 지원 설치 프로그램은 기본적으로 DHCP 네트워킹으로 설정됩니다. DHCP 예약 대신 클러스터 노드에 고정 IP 구성, 브리지 또는 본딩을 사용하는 경우 고정 IP, 브리지 및 본딩 을 선택합니다.

    참고

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

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

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

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

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

참고

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

프로세스

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

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

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

추가 리소스

3.4. 선택사항: Operator 설치

이 단계는 선택 사항입니다.

사전 요구 사항 및 구성 옵션은 제품 설명서를 참조하십시오.

고급 옵션이 필요한 경우 클러스터를 설치한 후 Operator를 설치합니다.

프로세스

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

    • Install OpenShift Virtualization
    • 다중 클러스터 엔진 설치

      모든 OpenShift Container Platform 클러스터에 OpenShift Data Foundation을 사용하여 다중 클러스터 엔진을 배포할 수 있습니다.

      중요

      OpenShift Data Foundation 없이 다중 클러스터 엔진을 배포하면 다음과 같은 스토리지 구성이 생성됩니다.

      • 다중 노드 클러스터: 스토리지가 구성되지 않았습니다. 설치 후 스토리지를 구성해야 합니다.
      • 단일 노드 OpenShift: LVM 스토리지가 설치되어 있습니다.
    • 논리 볼륨 관리자 스토리지 설치
    • Install OpenShift Data Foundation
  2. 다음을 클릭합니다.

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

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

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

프로세스

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

    1. 최소 이미지 파일: 가상 미디어를 사용하여 프로비저닝 하여 부팅에 필요한 데이터를 가져올 작은 이미지를 다운로드합니다. 노드에는 가상 미디어 기능이 있어야 합니다. 이 방법은 x86_64arm64 아키텍처에 권장되는 방법입니다.
    2. Full image file: Provision with physical media 를 선택하여 더 큰 전체 이미지를 다운로드합니다. 이는 RHEL KVM을 사용하여 설치할 때 ppc64le 아키텍처 및 s390x 아키텍처에 권장되는 방법입니다.
    3. iPXE를 사용하여 호스트를 부팅하려면 네트워크 서버에서 iPXE: Provision 을 선택합니다. 이는 z/VM 노드가 있는 IBM Z에 권장되는 방법입니다. ISO 부팅은 RHEL KVM 설치에 권장되는 방법입니다.

      참고
      • RHEL KVM에 설치하는 경우 경우에 따라 KVM 호스트의 VM이 처음 부팅 시 재부팅되지 않으므로 수동으로 다시 시작해야 합니다.
      • Oracle Cloud Infrastructure에 OpenShift Container Platform을 설치하는 경우 최소 이미지 파일: Provision with virtual media 를 선택합니다.
  2. 선택 사항: 컨트롤 플레인 노드에서 실행 워크로드 를 활성화하여 기본 작업자 노드 외에도 컨트롤 플레인 노드에서 실행되도록 워크로드를 예약합니다.

    참고

    이 옵션은 5개 이상의 노드로 구성된 클러스터에서 사용할 수 있습니다. 노드가 5개 미만인 클러스터의 경우 시스템은 기본적으로 컨트롤 플레인 노드에서만 워크로드를 실행합니다. 자세한 내용은 추가 리소스 에서 예약 가능한 컨트롤 플레인 노드 구성을 참조하십시오.

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

    중요

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

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

3.6. 호스트 구성

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

프로세스

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

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

    참고

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

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

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

    참고

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

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

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

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

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

3.7. 스토리지 디스크 구성

호스트 검색 중에 검색된 각 호스트에는 여러 스토리지 디스크가 있을 수 있습니다. 스토리지 디스크는 지원 설치 관리자 마법사의 스토리지 페이지에 있는 호스트에 대해 나열됩니다.

선택적으로 각 디스크의 기본 구성을 수정할 수 있습니다.

설치 디스크 변경

지원 설치 관리자는 기본적으로 설치 디스크를 무작위로 할당합니다. 호스트에 대한 스토리지 디스크가 여러 개 있는 경우 다른 디스크를 선택하여 설치 디스크가 될 수 있습니다. 이렇게 하면 이전 디스크가 자동으로 할당 해제됩니다.

프로세스

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

지원 설치 프로그램은 설치 디스크로 정의되었는지 여부에 관계없이 설치 프로세스 중에 포맷할 수 있는 모든 부팅 가능한 디스크를 표시합니다. 포맷으로 인해 데이터가 손실됩니다.

특정 디스크의 포맷을 비활성화하도록 선택할 수 있습니다. 부팅 가능한 디스크가 부팅 순서 측면에서 설치 프로세스를 방해할 수 있으므로 이 작업은 주의해서 수행해야 합니다.

설치 디스크의 포맷을 비활성화할 수 없습니다.

프로세스

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

추가 리소스

3.8. 네트워킹 구성

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

프로세스

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

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

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

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

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

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

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

추가 리소스

3.9. 사용자 정의 매니페스트 추가

사용자 정의 매니페스트는 지원 설치 관리자 사용자 인터페이스에서 현재 지원되지 않는 고급 구성이 포함된 JSON 또는 YAML 파일입니다. 사용자 정의 매니페스트를 생성하거나 타사에서 제공하는 매니페스트를 사용할 수 있습니다.

파일 시스템에서 사용자 정의 매니페스트를 openshift 폴더 또는 매니페스트 폴더에 업로드할 수 있습니다. 허용된 사용자 정의 매니페스트 파일 수에는 제한이 없습니다.

한 번에 하나의 파일만 업로드할 수 있습니다. 그러나 업로드된 각 YAML 파일에는 여러 사용자 정의 매니페스트가 포함될 수 있습니다. 여러 문서 YAML 매니페스트를 업로드하는 것이 YAML 파일을 개별적으로 추가하는 것보다 빠릅니다.

단일 사용자 정의 매니페스트가 포함된 파일의 경우 허용되는 파일 확장자에는 .yaml,.yml 또는 .json 이 포함됩니다.

단일 사용자 정의 매니페스트 예

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-openshift-machineconfig-master-kargs
spec:
  kernelArguments:
    - loglevel=7

여러 사용자 지정 매니페스트가 포함된 파일의 경우 허용되는 파일 유형에는 .yaml 또는 .yml 이 포함됩니다.

여러 사용자 정의 매니페스트 예

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-openshift-machineconfig-master-kargs
spec:
  kernelArguments:
    - loglevel=7
---
apiVersion: machineconfiguration.openshift.io/v2
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 98-openshift-machineconfig-worker-kargs
spec:
  kernelArguments:
    - loglevel=5

참고
  • Oracle Cloud Infrastructure(OCI) 외부 플랫폼에 OpenShift Container Platform을 설치하는 경우 Oracle에서 제공하는 사용자 정의 매니페스트를 추가해야 합니다. vSphere 또는 Nutanix와 같은 추가 외부 파트너 통합의 경우 이 단계는 선택 사항입니다.
  • 사용자 정의 매니페스트에 대한 자세한 내용은 추가 리소스 를 참조하십시오.
지원 설치 관리자 사용자 인터페이스에서 사용자 정의 매니페스트 업로드

사용자 정의 매니페스트를 업로드할 때 매니페스트 파일 이름을 입력하고 대상 폴더를 선택합니다.

사전 요구 사항

  • 파일 시스템에 저장된 사용자 지정 매니페스트 파일이 하나 이상 있습니다.

프로세스

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

업로드된 사용자 정의 매니페스트의 폴더 및 파일 이름을 변경할 수 있습니다. 기존 매니페스트의 콘텐츠를 복사하거나 Chrome 다운로드 설정에 정의된 폴더에 다운로드할 수도 있습니다.

업로드된 매니페스트의 콘텐츠를 수정할 수 없습니다. 그러나 파일을 덮어쓸 수 있습니다.

사전 요구 사항

  • 하나 이상의 사용자 정의 매니페스트 파일을 업로드했습니다.

프로세스

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

다음 두 가지 방법 중 하나로 설치하기 전에 업로드된 사용자 정의 매니페스트를 제거할 수 있습니다.

  • 하나 이상의 매니페스트를 개별적으로 제거합니다.
  • 한 번에 모든 매니페스트를 제거합니다.

매니페스트를 제거한 후에는 작업을 취소할 수 없습니다. 해결방법은 매니페스트를 다시 업로드하는 것입니다.

단일 매니페스트 제거

한 번에 하나의 매니페스트를 삭제할 수 있습니다. 이 옵션은 마지막 남아 있는 매니페스트를 삭제할 수 없습니다.

사전 요구 사항

  • 두 개 이상의 사용자 지정 매니페스트 파일을 업로드했습니다.

프로세스

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

모든 사용자 정의 매니페스트를 한 번에 제거할 수 있습니다. 또한 사용자 정의 매니페스트 페이지도 숨겨집니다.

사전 요구 사항

  • 하나 이상의 사용자 정의 매니페스트 파일을 업로드했습니다.

프로세스

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

3.10. 사전 설치 검증

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

추가 리소스

3.11. 클러스터 설치

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

프로세스

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

3.12. 설치 완료

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

사전 요구 사항

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

프로세스

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

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

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

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

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

    $ oc login -u kubeadmin -p <password>

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

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

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

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

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

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

4.1. 오프라인 토큰 생성

지원 설치 프로그램 웹 콘솔에서 오프라인 토큰을 다운로드합니다. 오프라인 토큰을 사용하여 API 토큰을 설정합니다.

사전 요구 사항

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

프로세스

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

    중요

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

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

    $ export OFFLINE_TOKEN=<copied_token>
    작은 정보

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

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

    $ echo ${OFFLINE_TOKEN}

4.2. REST API로 인증

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

참고

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

사전 요구 사항

  • OFFLINE_TOKEN 변수를 생성했습니다.

프로세스

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

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

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

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

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

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

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

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

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

    출력 예

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

4.3. 풀 시크릿 구성

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

이전

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

이후

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

프로세스

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

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

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

    $ echo ${PULL_SECRET}

4.4. 선택 사항: SSH 공개 키 생성

OpenShift Container Platform을 설치하는 동안 설치 프로그램에 SSH 공개 키를 선택적으로 제공할 수 있습니다. 이 기능은 설치 오류 발생 시 원격 노드에 대한 SSH 연결을 시작하는 데 유용합니다.

로컬 시스템에 인증에 사용할 기존 SSH 키 쌍이 없는 경우 지금 만듭니다.

사전 요구 사항

  • OFFLINE_TOKENAPI_TOKEN 변수를 생성합니다.

프로세스

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

    $ cat /root/.ssh/id_rsa.pub
  2. SSH 공개 키를 CLUSTER_SSHKEY 변수로 설정합니다.

    $ CLUSTER_SSHKEY=<downloaded_ssh_key>
  3. CLUSTER_SSHKEY 변수 정의를 확인합니다.

    $ echo ${CLUSTER_SSHKEY}

4.5. 새 클러스터 등록

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

  • name
  • openshift-version
  • pull_secret
  • cpu_architecture

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

클러스터 정의를 생성한 후 클러스터 정의를 수정하고 추가 설정 값을 제공할 수 있습니다.

중요
  • 특정 설치 플랫폼 및 OpenShift Container Platform 버전의 경우 동일한 클러스터에서 두 개의 서로 다른 아키텍처를 결합하여 혼합 아키텍처 클러스터를 생성할 수도 있습니다. 자세한 내용은 추가 리소스 를 참조하십시오.
  • 타사 플랫폼에 OpenShift Container Platform을 설치하는 경우 관련 지침은 추가 리소스 를 참조하십시오.
  • 5~10개의 노드 사이의 클러스터의 경우 클러스터를 등록하는 동안 작업자 노드 외에도 컨트롤 플레인 노드에서 실행할 워크로드를 예약하도록 선택할 수 있습니다. 자세한 내용은 추가 리소스 에서 예약 가능한 컨트롤 플레인 노드 구성 을 참조하십시오.

사전 요구 사항

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

프로세스

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

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

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

      $ curl -s -X POST https://api.openshift.com/api/assisted-install/v2/clusters \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d "$(jq --null-input \
          --slurpfile pull_secret ~/Downloads/pull-secret.txt '
      {
          "name": "testcluster",
          "openshift_version": "4.11",
          "cpu_architecture" : "<architecture_name>", 1
          "high_availability_mode": "<cluster_type>", 2
          "base_dns_domain": "example.com",
          "pull_secret": $pull_secret[0] | tojson
      }
      ')" | jq '.id'
      참고
      1
      다음 값 중 하나를 사용합니다. x86_64,arm64,ppc64le,s390x,multi. 혼합 아키텍처 클러스터의 경우 multi 만 사용합니다.
      2
      기본값 Full 을 사용하여 다중 노드 OpenShift Container Platform 클러스터를 나타내거나 단일 노드 OpenShift 클러스터를 나타내는 None 을 사용합니다. full 은 여러 마스터 노드를 통해 고가용성 클러스터를 설치하고 설치된 클러스터의 가용성을 보장합니다. 어느 하나도 하나의 노드에 전체 클러스터를 설치하지 않습니다.
    2. 선택 사항: JSON 파일에 구성을 작성한 다음 요청에서 참조하여 새 클러스터를 등록할 수 있습니다.

      cat << EOF > cluster.json
      {
        "name": "testcluster",
        "openshift_version": "4.11",
        "high_availability_mode": "<cluster_type>", 1
        "base_dns_domain": "example.com",
        "network_type": "examplenetwork",
        "cluster_network_cidr":"11.111.1.0/14"
        "cluster_network_host_prefix": 11,
        "service_network_cidr": "111.11.1.0/16",
        "api_vips":[{"ip": ""}],
        "ingress_vips": [{"ip": ""}],
        "vip_dhcp_allocation": false,
        "additional_ntp_source": "clock.redhat.com,clock2.redhat.com",
        "ssh_public_key": "$CLUSTER_SSHKEY",
        "pull_secret": $PULL_SECRET
      }
      EOF
      참고
      1
      기본값 Full 을 사용하여 다중 노드 OpenShift Container Platform 클러스터를 나타내거나 단일 노드 OpenShift 클러스터를 나타내는 None 을 사용합니다. full 은 여러 마스터 노드를 통해 고가용성 클러스터를 설치하고 설치된 클러스터의 가용성을 보장합니다. 어느 하나도 하나의 노드에 전체 클러스터를 설치하지 않습니다.
      $ curl -s -X POST "https://api.openshift.com/api/assisted-install/v2/clusters" \
        -d @./cluster.json \
        -H "Content-Type: application/json" \
        -H "Authorization: Bearer $API_TOKEN" \
        | jq '.id'
  3. 반환된 cluster_idCLUSTER_ID 변수에 할당하고 내보냅니다.

    $ export CLUSTER_ID=<cluster_id>
    참고

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

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

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

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

참고

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

4.5.1. 선택사항: Operator 설치

새 클러스터를 등록할 때 다음 Operator를 설치할 수 있습니다.

  • OpenShift Virtualization Operator

    참고

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

  • 다중 클러스터 엔진 Operator
  • OpenShift Data Foundation Operator
  • LVM Storage Operator

고급 옵션이 필요한 경우 클러스터를 설치한 후 Operator를 설치합니다.

프로세스

  • 다음 명령을 실행합니다.

    $ 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.15",
       "cpu_architecture" : "x86_64",
       "base_dns_domain": "example.com",
      "olm_operators": [
      { "name": "mce" } 1
      ,
      { "name": "odf" } 2
        ]
       "pull_secret": $pull_secret[0] | tojson
    }
    ')" | jq '.id'
    1
    OpenShift Virtualization용 cnv, 다중 클러스터 엔진 mce, OpenShift Data Foundation의 경우 odf, LVM Storage의 경우 lvm 을 지정합니다.
    2
    이 예제에서는 다중 노드 클러스터에 다중 클러스터 엔진 및 OpenShift Data Foundation을 설치합니다. 단일 노드 OpenShift 클러스터의 mcelvm 을 지정합니다.

4.6. 클러스터 수정

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

이미 등록된 클러스터 리소스에서 Operator를 추가하거나 제거할 수 있습니다.

참고

노드에서 파티션을 생성하려면 OpenShift Container Platform 설명서의 노드에서 스토리지 구성 을 참조하십시오.

사전 요구 사항

  • 새 클러스터 리소스를 생성했습니다.

프로세스

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

    $ source refresh-token
  2. 클러스터를 수정합니다. 예를 들어 SSH 키를 변경합니다.

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

4.6.1. Operator 수정

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

/v2/clusters/{cluster_id} 엔드포인트에 PATCH 방법을 사용하여 필요한 Operator 정의를 설정합니다.

사전 요구 사항

  • API 토큰을 새로 고쳐야 합니다.
  • 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
    OpenShift Virtualization용 cnv, 다중 클러스터 엔진 mce, Red Hat OpenShift Data Foundation의 경우 odf 또는 Logical Volume Manager Storage의 경우 lvm 을 지정합니다. 이전에 설치한 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는 사용자가 수동으로 추가하거나 종속성으로 자동으로 추가됩니다. 이 예에서는 LVM Storage Operator가 OpenShift Virtualization의 종속성으로 자동으로 추가됩니다.

4.7. 새 인프라 환경 등록

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

  • name
  • pull_secret
  • cpu_architecture

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

사전 요구 사항

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

프로세스

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

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

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

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

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

    $ export INFRA_ENV_ID=<id>
참고

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

4.8. 인프라 환경 수정

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

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

사전 요구 사항

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

프로세스

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

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

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

4.8.1. 선택 사항: 커널 인수 추가

지원 설치 관리자를 통해 RHCOS(Red Hat Enterprise Linux CoreOS) 커널에 커널 인수를 제공하는 것은 특히 검색 ISO의 커널 매개 변수를 사용자 지정할 수 없는 경우 부팅 시 특정 매개변수 또는 옵션을 커널에 전달하는 것을 의미합니다. 커널 매개 변수는 커널 동작 및 운영 체제 구성의 다양한 측면을 제어하여 하드웨어 상호 작용, 시스템 성능 및 기능에 영향을 미칩니다. 커널 인수는 노드의 RHCOS 커널에 하드웨어 구성, 디버깅 기본 설정, 시스템 서비스 및 기타 하위 수준 설정에 대해 사용자 지정하거나 알리는 데 사용됩니다.

RHCOS 설치 프로그램 kargs modify 명령은 append,delete, replace 옵션을 지원합니다.

/v2/infra-envs/{infra_env_id} 엔드포인트를 사용하여 인프라 환경을 수정할 수 있습니다. 새로운 인프라 환경을 수정할 때 지원 설치 관리자도 검색 ISO를 다시 생성합니다.

프로세스

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

    $ source refresh-token
  2. 커널 인수를 수정합니다.

    $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID} \
    -X PATCH \
    -H "Authorization: Bearer ${API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d "$(jq --null-input \
      --slurpfile pull_secret ~/Downloads/pull-secret.txt '
        {
          "kernel_arguments": [{ "operation": "append", "value": "<karg>=<value>" }], 1
          "image_type":"minimal-iso",
          "pull_secret": $pull_secret[0] | tojson
        }
    ')" | jq
    1
    & lt;karg& gt;를 커널 인수로 바꾸고 < value >를 kernal 인수 값으로 바꿉니다. 예: rd.net.timeout.carrier=60. 각 커널 인수에 JSON 오브젝트를 추가하여 여러 커널 인수를 지정할 수 있습니다.

4.9. 호스트 추가

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

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

현재 z/VM이 있는 IBM Z(s390x)의 설치에는 ISO 이미지가 지원되지 않습니다. 자세한 내용은 iPXE를 사용하여 호스트 부팅을 참조하십시오.

세 가지 방법을 사용하여 검색 이미지로 호스트를 부팅할 수 있습니다. 자세한 내용은 검색 이미지를 사용하여 호스트 부팅을 참조하십시오.

사전 요구 사항

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

프로세스

  1. 필요한 경우 검색 이미지를 구성합니다. 자세한 내용은 검색 이미지 구성을 참조하십시오.
  2. API 토큰을 새로 고칩니다.

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

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

    출력 예

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

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

    $ wget -O discovery.iso <url>

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

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

4.10. 호스트 수정

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

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

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

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

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

사전 요구 사항

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

프로세스

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

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

    $ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID" \
    --header "Content-Type: application/json" \
      -H "Authorization: Bearer $API_TOKEN" \
    | jq '.host_networks[].host_ids'
  3. 호스트를 수정합니다.

    $ 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.1. 스토리지 디스크 구성 수정

호스트 검색 중에 검색된 각 호스트에는 여러 스토리지 디스크가 있을 수 있습니다. 선택적으로 각 디스크의 기본 구성을 수정할 수 있습니다.

사전 요구 사항

  • 클러스터를 구성하고 호스트를 검색합니다. 자세한 내용은 추가 리소스를 참조하십시오.
스토리지 디스크 보기

클러스터의 호스트와 각 호스트의 디스크를 볼 수 있습니다. 이를 통해 특정 디스크에 대한 작업을 수행할 수 있습니다.

프로세스

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

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

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

    샘플 출력

    $ "1022623e-7689-8b2d-7fbd-e6f4d5bb28e5"

    참고

    단일 호스트의 ID입니다. 여러 호스트 ID는 쉼표로 구분됩니다.

  3. 특정 호스트의 디스크를 가져옵니다.

    $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/<host_id> \ 1
    -H "Authorization: Bearer ${API_TOKEN}" \
    | jq '.inventory | fromjson | .disks'
    1
    & lt;host_id& gt;를 관련 호스트의 ID로 바꿉니다.

    샘플 출력

    $ [
      {
        "by_id": "/dev/disk/by-id/wwn-0x6c81f660f98afb002d3adc1a1460a506",
        "by_path": "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:0:0",
        "drive_type": "HDD",
        "has_uuid": true,
        "hctl": "1:2:0:0",
        "id": "/dev/disk/by-id/wwn-0x6c81f660f98afb002d3adc1a1460a506",
        "installation_eligibility": {
          "eligible": true,
          "not_eligible_reasons": null
        },
        "model": "PERC_H710P",
        "name": "sda",
        "path": "/dev/sda",
        "serial": "0006a560141adc3a2d00fb8af960f681",
        "size_bytes": 6595056500736,
        "vendor": "DELL",
        "wwn": "0x6c81f660f98afb002d3adc1a1460a506"
      }
    ]

    참고

    이는 하나의 디스크에 대한 출력입니다. 디스크에 대한 disk_idinstallation_eligibility 속성이 포함되어 있습니다.

설치 디스크 변경

지원 설치 관리자는 기본적으로 설치 디스크를 무작위로 할당합니다. 호스트에 대한 스토리지 디스크가 여러 개 있는 경우 다른 디스크를 선택하여 설치 디스크가 될 수 있습니다. 이렇게 하면 이전 디스크가 자동으로 할당 해제됩니다.

installation_eligibility 속성이 true 인 디스크를 설치 디스크로 선택할 수 있습니다.

프로세스

  1. 호스트 및 스토리지 디스크 ID를 가져옵니다. 자세한 내용은 스토리지 디스크 보기를 참조하십시오.
  2. 선택 사항: 현재 설치 디스크를 식별합니다.

    $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/<host_id> \ 1
    -H "Authorization: Bearer ${API_TOKEN}" \
    | jq '.installation_disk_id'
    1
    & lt;host_id& gt;를 관련 호스트의 ID로 바꿉니다.
  3. 새 설치 디스크를 할당합니다.

    $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/<host_id> \ 1
    -X PATCH \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer ${API_TOKEN}" \
    
    {
      "disks_selected_config": [
        {
          "id": "<disk_id>", 2
          "role": "install"
        }
      ]
    }
    참고
    1
    & lt;host_id& gt;를 호스트의 ID로 바꿉니다.
    2
    & lt;disk_id& gt;를 새 설치 디스크의 ID로 바꿉니다.
디스크 형식 비활성화

지원 설치 프로그램은 설치 디스크로 정의되었는지 여부에 관계없이 설치 프로세스 중에 포맷할 수 있는 모든 부팅 가능한 디스크를 표시합니다. 포맷으로 인해 데이터가 손실됩니다.

특정 디스크의 포맷을 비활성화하도록 선택할 수 있습니다. 부팅 가능한 디스크가 부팅 순서 측면에서 설치 프로세스를 방해할 수 있으므로 이 작업은 주의해서 수행해야 합니다.

설치 디스크의 포맷을 비활성화할 수 없습니다.

프로세스

  1. 호스트 및 스토리지 디스크 ID를 가져옵니다. 자세한 내용은 스토리지 디스크 보기를 참조하십시오.
  2. 다음 명령을 실행합니다.

    $  curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/<host_id> \ 1
    -X PATCH \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer ${API_TOKEN}" \
    
    {
     "disks_skip_formatting": [
       {
         "disk_id": "<disk_id>", 2
         "skip_formatting": true 3
       }
     ]
    }
    참고
    1
    & lt;host_id& gt;를 호스트의 ID로 바꿉니다.
    2
    & lt;disk_id& gt;를 디스크 ID로 바꿉니다. 디스크가 두 개 이상 있는 경우 ID를 쉼표로 구분합니다.
    3
    형식을 다시 활성화하려면 값을 false 로 변경합니다.

4.11. 사용자 정의 매니페스트 추가

사용자 정의 매니페스트는 지원 설치 관리자 사용자 인터페이스에서 현재 지원되지 않는 고급 구성이 포함된 JSON 또는 YAML 파일입니다. 사용자 정의 매니페스트를 생성하거나 타사에서 제공하는 매니페스트를 사용할 수 있습니다. API를 사용하여 사용자 정의 매니페스트를 생성하려면 /v2/clusters/$CLUSTER_ID/manifests 엔드포인트를 사용합니다.

base64로 인코딩된 사용자 정의 매니페스트를 openshift 폴더 또는 지원 설치 프로그램 API를 사용하여 매니페스트 폴더에 업로드할 수 있습니다. 허용된 사용자 정의 매니페스트 수에는 제한이 없습니다.

하나의 base64로 인코딩된 JSON 매니페스트만 한 번에 업로드할 수 있습니다. 그러나 업로드된 base64로 인코딩된 YAML 파일은 여러 사용자 정의 매니페스트를 포함할 수 있습니다. 여러 문서 YAML 매니페스트를 업로드하는 것이 YAML 파일을 개별적으로 추가하는 것보다 빠릅니다.

단일 사용자 정의 매니페스트가 포함된 파일의 경우 허용되는 파일 확장자에는 .yaml,.yml 또는 .json 이 포함됩니다.

단일 사용자 정의 매니페스트 예

{
    "apiVersion": "machineconfiguration.openshift.io/v1",
    "kind": "MachineConfig",
    "metadata": {
        "labels": {
            "machineconfiguration.openshift.io/role": "primary"
        },
        "name": "10_primary_storage_config"
    },
    "spec": {
        "config": {
            "ignition": {
                "version": "3.2.0"
            },
            "storage": {
                "disks": [
                    {
                        "device": "</dev/xxyN>",
                        "partitions": [
                            {
                                "label": "recovery",
                                "startMiB": 32768,
                                "sizeMiB": 16384
                            }
                        ]
                    }
                ],
                "filesystems": [
                    {
                        "device": "/dev/disk/by-partlabel/recovery",
                        "label": "recovery",
                        "format": "xfs"
                    }
                ]
            }
        }
    }
}

여러 사용자 지정 매니페스트가 포함된 파일의 경우 허용되는 파일 유형에는 .yaml 또는 .yml 이 포함됩니다.

여러 사용자 정의 매니페스트 예

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-openshift-machineconfig-master-kargs
spec:
  kernelArguments:
    - loglevel=7
---
apiVersion: machineconfiguration.openshift.io/v2
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 98-openshift-machineconfig-worker-kargs
spec:
  kernelArguments:
    - loglevel=5

참고
  • Oracle Cloud Infrastructure(OCI) 외부 플랫폼에 OpenShift Container Platform을 설치하는 경우 Oracle에서 제공하는 사용자 정의 매니페스트를 추가해야 합니다. vSphere 또는 Nutanix와 같은 추가 외부 파트너 통합의 경우 이 단계는 선택 사항입니다.
  • 사용자 정의 매니페스트에 대한 자세한 내용은 추가 리소스 를 참조하십시오.

사전 요구 사항

  • 유효한 API_TOKEN 을 생성했습니다. 토큰은 15분마다 만료됩니다.
  • 새 클러스터 정의를 등록하고 cluster_id$CLUSTER_ID BASH 변수로 내보냈습니다.

프로세스

  1. 사용자 정의 매니페스트 파일을 생성합니다.
  2. 파일 형식에 적절한 확장자를 사용하여 사용자 정의 매니페스트 파일을 저장합니다.
  3. API 토큰을 새로 고칩니다.

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

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

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

    출력 예

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

    참고

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

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

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

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

4.12. 사전 설치 검증

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

추가 리소스

4.13. 클러스터 설치

클러스터의 유효성을 검증한 후 클러스터를 설치할 수 있습니다.

사전 요구 사항

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

프로세스

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

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

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

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

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

참고

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

5.1. TPM v2 암호화 활성화

사전 요구 사항

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

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

프로세스

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

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

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

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

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

5.2. Tang 암호화 활성화

사전 요구 사항

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

프로세스

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

    $ tang-show-keys <port>

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

    지문 예

    1gYTN_LpU9ZMB35yn5IbADY5OQ0

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

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

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

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

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

      지문 예

      1gYTN_LpU9ZMB35yn5IbADY5OQ0

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

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

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

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

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

5.3. 추가 리소스

6장. 선택 사항: 스케줄링 가능한 컨트롤 플레인 노드 구성

고가용성 배포에서 세 개 이상의 노드가 컨트롤 플레인을 구성합니다. 컨트롤 플레인 노드는 OpenShift Container Platform을 관리하고 OpenShift 컨테이너를 실행하는 데 사용됩니다. 나머지 노드는 고객 컨테이너 및 워크로드를 실행하는 데 사용되는 작업자입니다. 1 ~ 수천 개의 작업자 노드 사이가 있을 수 있습니다.

단일 노드 OpenShift 클러스터 또는 최대 4개의 노드로 구성된 클러스터의 경우 시스템은 컨트롤 플레인 노드에서 실행되도록 워크로드를 자동으로 예약합니다.

5~10개의 노드 사이의 클러스터의 경우 작업자 노드 외에도 컨트롤 플레인 노드에서 실행되도록 워크로드를 예약하도록 선택할 수 있습니다. 이 옵션은 효율성을 강화하고 활용도가 낮은 리소스를 방지하는 것이 좋습니다. 설치 설정 중에 또는 설치 후 단계의 일부로 이 옵션을 선택할 수 있습니다.

노드가 10개 이상인 대규모 클러스터의 경우 이 옵션을 사용하지 않는 것이 좋습니다.

이 섹션에서는 설치 설정의 일부로 지원 설치 관리자 웹 콘솔 및 API를 사용하여 컨트롤 플레인 노드에서 실행할 워크로드를 예약하는 방법을 설명합니다.

설치 후 스케줄링 가능한 컨트롤 플레인 노드를 구성하는 방법에 대한 자세한 내용은 OpenShift Container Platform 설명서에서 컨트롤 플레인 노드를 예약 가능으로 구성 을 참조하십시오.

중요

기본 예약 불가에서 예약 가능으로 컨트롤 플레인 노드를 구성하면 추가 서브스크립션이 필요합니다. 그 이유는 컨트롤 플레인 노드가 작업자 노드가 되기 때문입니다.

6.1. 웹 콘솔을 사용하여 스케줄링 가능한 컨트롤 플레인 구성

사전 요구 사항

  • 클러스터 세부 정보를 설정했습니다.
  • OpenShift Container Platform 4.14 이상을 설치하고 있습니다.

프로세스

  1. Red Hat Hybrid Cloud Console 에 로그인하고 지원 설치 관리자 웹 콘솔을 사용하여 OpenShift Container Platform 설치 지침을 따르십시오. 자세한 내용은 추가 리소스에서 지원 설치 프로그램 웹 콘솔을 사용하여 설치를 참조하십시오.
  2. 호스트 검색 페이지에 도달하면 호스트 추가 를 클릭합니다.
  3. 필요한 경우 필요에 따라 프로비저닝 유형 및 추가 설정을 변경합니다. 모든 옵션은 예약 가능한 컨트롤 플레인과 호환됩니다.
  4. Discovery ISO 생성 을 클릭하여 ISO를 다운로드합니다.
  5. 컨트롤 플레인 노드에서 워크로드 실행을 on으로 설정합니다.

    참고

    4개의 노드의 경우 이 스위치는 자동으로 활성화되며 변경할 수 없습니다.

  6. 다음을 클릭합니다.

6.2. API를 사용하여 스케줄링 가능한 컨트롤 플레인 구성

schedulable_masters 속성을 사용하여 워크로드가 컨트롤 플레인 노드에서 실행되도록 합니다.

사전 요구 사항

  • 유효한 API_TOKEN 을 생성했습니다. 토큰은 15분마다 만료됩니다.
  • $PULL_SECRET 변수를 생성했습니다.
  • OpenShift Container Platform 4.14 이상을 설치하고 있습니다.

프로세스

  1. 지원 설치 관리자 API를 사용하여 지원 설치 관리자를 설치하는 지침을 따르십시오. 자세한 내용은 추가 리소스에서 지원 설치 관리자 API를 사용하여 설치를 참조하십시오.
  2. 새 클러스터 등록 단계에 도달하면 다음과 같이 schedulable_masters 속성을 설정합니다.

    $ 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 '
    {
      "schedulable_masters": true 1
    }
    ' | jq
    1
    컨트롤 플레인 노드에서 워크로드 예약을 활성화합니다.

6.3. 추가 리소스

7장. 검색 이미지 구성

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

참고

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

7.1. Ignition 구성 파일 생성

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

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

중요

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

프로세스

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

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

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

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

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

    $ export IGNITION_FILE=~/ignition.conf

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

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

사전 요구 사항

  • 웹 콘솔을 사용하여 클러스터를 생성한 경우 API 인증을 설정했습니다.
  • 인프라 환경이 있고 인프라 환경 ID를 INFRA_ENV_ID 변수로 내보냈습니다.
  • 유효한 Ignition 파일이 있으며 $IGNITION_FILE 로 파일 이름을 내보냈습니다.

프로세스

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

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

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

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

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

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

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

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

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

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

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

프로세스

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

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

    다음과 같습니다.

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

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

    ISO가 USB 드라이브에 복사되면 USB 드라이브를 사용하여 클러스터 호스트에 지원 설치 관리자 에이전트를 설치할 수 있습니다.

8.2. USB 드라이브로 부팅

부팅 가능한 USB 드라이브를 사용하여 지원 설치 프로그램으로 노드를 등록하려면 다음 절차를 사용하십시오.

프로세스

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

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

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

      출력 예

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

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

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

사전 요구 사항

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

프로세스

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

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

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

      다음과 같습니다.

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

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

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

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

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

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

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

사전 요구 사항

  • API를 사용하여 인프라 환경을 생성하거나 웹 콘솔을 사용하여 클러스터를 생성했습니다.
  • 쉘에서 인프라 환경 ID를 $INFRA_ENV_ID 로 내보내야 합니다.
  • API에 액세스할 때 사용할 인증 정보가 있으며 쉘에서 $API_TOKEN 으로 토큰을 내보냈습니다.
참고

웹 콘솔을 사용하여 iPXE를 구성하는 경우 $INFRA_ENV_ID$API_TOKEN 변수가 사전 설정됩니다.

  • 이미지를 호스팅할 HTTP 서버가 있습니다.
참고

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

프로세스

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

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

    예제

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

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

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

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

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

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

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

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

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

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

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

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

9장. 호스트에 역할 할당

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

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

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

9.1. 웹 콘솔을 사용하여 역할 선택

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

프로세스

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

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

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

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

기본적으로 지원 설치 관리자는 호스트를 자동 할당 으로 설정합니다. 즉, 설치 프로그램에서 호스트가 마스터 또는 작업자 역할인지 자동으로 결정합니다. 호스트 역할을 설정하려면 다음 절차를 사용하십시오.

사전 요구 사항

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

프로세스

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

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

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

    출력 예

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

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

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

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

9.3. 역할 자동 할당

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

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

검증은 자동 선택 사항이 유효한지 확인합니다.

9.4. 추가 리소스

사전 요구 사항

10장. 사전 설치 검증

10.1. 사전 설치 검증 정의

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

지원 설치 프로그램은 컨트롤 플레인 토폴로지, 네트워크 구성 및 호스트 이름과 같이 설치 전에 제공되는 정보를 사용합니다. 또한 설치하려는 호스트의 실시간 Telemetry를 사용합니다.

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

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

10.2. 차단 및 비차단 검증

차단 검증으로 인해 설치 진행 상황을 방지할 수 있습니다. 따라서 문제를 해결하고 계속 진행하기 전에 차단 검증을 전달해야 합니다.

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

10.3. 검증 유형

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

호스트

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

Cluster

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

10.4. 호스트 검증

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

참고

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

사전 요구 사항

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

프로시저

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

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

    $ curl \
      --silent \
      --header "Authorization: Bearer $API_TOKEN" \
      https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/hosts \
      | jq -r .[].validations_info \
      | jq 'map(.[])'
  3. 모든 호스트에 대해 통과하지 않은 검증을 가져옵니다.

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

10.4.2. 호스트 검증 세부 정보

매개변수검증 유형설명

연결됨

비차단(non-blocking)

호스트가 최근에 지원 설치 프로그램과 통신했는지 확인합니다.

has-inventory

비차단(non-blocking)

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

has-min-cpu-cores

비차단(non-blocking)

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

has-min-memory

비차단(non-blocking)

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

has-min-valid-disks

비차단(non-blocking)

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

has-cpu-cores-for-role

blocking

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

has-memory-for-role

blocking

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

ignition-downloadable

blocking

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

belongs-to-majority-group

blocking

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

valid-platform-network-settings

blocking

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

ntp-synced

비차단(non-blocking)

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

container-images-available

비차단(non-blocking)

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

sufficient-installation-disk-speed

blocking

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

sufficient-network-latency-requirement-for-role

blocking

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

sufficient-packet-loss-requirement-for-role

blocking

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

has-default-route

blocking

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

api-domain-name-resolved-correctly

blocking

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

api-int-domain-name-resolved-correctly

blocking

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

apps-domain-name-resolved-correctly

blocking

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

compatible-with-cluster-platform

비차단(non-blocking)

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

dns-wildcard-not-configured

blocking

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

disk-encryption-requirements-satisfied

비차단(non-blocking)

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

non-overlapping-subnets

blocking

이 호스트에 중복된 서브넷이 없는지 확인합니다.

hostname-unique

blocking

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

hostname-valid

blocking

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

belongs-to-machine-cidr

blocking

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

LSO-requirements-satisfied

blocking

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

oDF-requirements-satisfied

blocking

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

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

cnv-requirements-satisfied

blocking

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

  • 호스트의 BIOS에는 CPU 가상화가 활성화되어 있어야 합니다.
  • 호스트에는 Container Native Virtualization에 사용할 수 있는 충분한 CPU 코어 및 RAM이 있어야 합니다.
  • 필요한 경우 은 호스트 경로 Provisioner의 유효성을 검사합니다.

lvm-requirements-satisfied

blocking

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

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

vsphere-disk-uuid-enabled

비차단(non-blocking)

각 유효한 디스크가 disk.EnableUUIDtrue 로 설정하는지 확인합니다. VSphere에서 각 디스크에 UUID가 생성됩니다.

compatible-agent

blocking

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

no-skip-installation-disk

blocking

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

no-skip-missing-disk

blocking

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

미디어 연결

blocking

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

machine-cidr-defined

비차단(non-blocking)

클러스터에 대한 머신 네트워크 정의가 있는지 확인합니다.

id-platform-network-settings

blocking

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

10.5. 클러스터 검증

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

웹 콘솔을 사용하는 경우 이러한 검증의 대부분은 이름으로 표시되지 않습니다. 라벨과 일치하는 검증 목록을 얻으려면 다음 절차를 사용하십시오.

사전 요구 사항

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

프로시저

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

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

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

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

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

매개변수검증 유형설명

machine-cidr-defined

비차단(non-blocking)

클러스터에 대한 머신 네트워크 정의가 있는지 확인합니다.

cluster-cidr-defined

비차단(non-blocking)

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

service-cidr-defined

비차단(non-blocking)

클러스터에 대한 서비스 네트워크 정의가 있는지 확인합니다.

no-cidrs-overlapping

blocking

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

networks-same-address-families

blocking

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

network-prefix-valid

blocking

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

machine-cidr-equals-to-calculated-cidr

blocking

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

api-vips-defined

비차단(non-blocking)

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

api-vips-valid

blocking

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

ingress-vips-defined

blocking

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

ingress-vips-valid

비차단(non-blocking)

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

all-hosts-are-ready-to-install

blocking

클러스터의 모든 호스트가 "설치 준비" 상태에 있는지 확인합니다.

sufficient-masters-count

blocking

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

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

DNS-domain-defined

비차단(non-blocking)

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

pull-secret-set

비차단(non-blocking)

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

ntp-server-configured

blocking

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

LSO-requirements-satisfied

blocking

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

oDF-requirements-satisfied

blocking

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

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

cnv-requirements-satisfied

blocking

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

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

lvm-requirements-satisfied

blocking

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

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

network-type-valid

blocking

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

  • 네트워크 유형은 OpenshiftSDN 또는 OVNKubernetes여야 합니다.
  • OpenShiftSDN은 IPv6 또는 단일 노드 Openshift를 지원하지 않습니다. OpenShiftSDN은 OpenShift Container Platform 4.15 이상 릴리스에서 지원되지 않습니다.
  • OVNKubernetes는 VIP DHCP 할당을 지원하지 않습니다.

11장. 네트워크 구성

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

11.1. 클러스터 네트워킹

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

유형DNS설명

clusterNetwork

 

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

serviceNetwork

 

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

machineNetwork

 

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

apiVIP

api.<clustername.clusterdomain>

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

apiVIPs

api.<clustername.clusterdomain>

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

ingressVIP

*.apps.<clustername.clusterdomain>

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

ingressVIPs

*.apps.<clustername.clusterdomain>

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

참고

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

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

  • IPv4
  • Dual-stack (IPv4 + IPv6)

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

stackSDNOVN

IPv4

제공됨

제공됨

Dual-stack

없음

제공됨

참고

OVN은 OpenShift Container Platform 4.12 이상 릴리스의 기본 CNI(Container Network Interface)입니다. SDN은 OpenShift Container Platform 4.14에서 지원되지만 OpenShift Container Platform 4.15 이상 릴리스에서는 지원되지 않습니다.

11.1.1. 제한

11.1.1.1. SDN
  • SDN 컨트롤러는 단일 노드 OpenShift에서 지원되지 않습니다.
  • SDN 컨트롤러는 IPv6를 지원하지 않습니다.
  • OpenShift Container Platform 4.15 이상 릴리스에서는 SDN 컨트롤러가 지원되지 않습니다. 자세한 내용은 OpenShift Container Platform 릴리스 노트 에서 OpenShift SDN 네트워크 플러그인 사용 중단을 참조하십시오.
11.1.1.2. OVN-Kubernetes

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

11.1.2. 클러스터 네트워크

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

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

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

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

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

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

11.1.3. 머신 네트워크

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

11.1.4. 다중 노드 클러스터 비교

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

매개변수SNODHCP 모드가 있는 다중 노드 클러스터DHCP 모드가 없는 다중 노드 클러스터

clusterNetwork

필수 항목

필수 항목

필수 항목

serviceNetwork

필수 항목

필수 항목

필수 항목

machineNetwork

자동 할당 가능 (*)

자동 할당 가능 (*)

자동 할당 가능 (*)

apiVIP

사용 금지됨

사용 금지됨

필수 항목

apiVIPs

사용 금지됨

사용 금지됨

4.12 이상 릴리스에서 필수 항목

ingressVIP

사용 금지됨

사용 금지됨

필수 항목

ingressVIPs

사용 금지됨

사용 금지됨

4.12 이상 릴리스에서 필수 항목

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

11.1.5. Air-gapped 환경

인터넷 액세스없이 클러스터를 배포하기 위한 워크플로에는 이 문서에서 다루지 않는 몇 가지 사전 요구 사항이 있습니다. 일부 인사이트를 위해 Git 리포지토리를 하드 방식으로 프로비저닝한 제로 터치 프로비저닝 을 참조할 수 있습니다.

11.2. VIP DHCP 할당

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

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

이는 OpenShift Container Platform 기능이 아니며 구성을 더 쉽게 지원하기 위해 지원 서비스로 구현되었습니다.

중요

VIP DHCP 할당은 현재 OpenShift Container Platform SDN 네트워크 유형으로 제한됩니다. OpenShift Container Platform 버전 4.15 이상에서는 SDN이 지원되지 않습니다. 따라서 VIP DHCP 할당 지원도 OpenShift Container Platform 4.15 이상에서 종료됩니다.

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_vips": [
    {
        "ip": "192.168.127.100"
    }
  ],
  "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"
    }
  ]
}
---

11.3. 추가 리소스

11.4. 사용자 및 클러스터 관리 네트워킹 간의 차이점 이해

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

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

11.4.1. 검증

설치를 시작하기 전에 지원 설치 프로그램에서 다양한 네트워크 검증이 발생합니다. 사용자 관리 네트워킹을 활성화하면 다음 검증이 변경됩니다.

  • L3 연결 검사(ICMP)는 L2 검사(ARP) 대신 수행됩니다.

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
        reorder-headers: true
---
11.5.4.2. 네트워크 본딩
---
    interfaces:
    - ipv4:
        address:
        - ip: 192.168.138.15
          prefix-length: 24
        dhcp: false
        enabled: true
      ipv6:
        enabled: false
      link-aggregation:
        mode: active-backup
        options:
          all_slaves_active: delivered
          miimon: "140"
        slaves:
        - eth0
        - eth1
      name: bond0
      state: up
      type: bond
---

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

지원 설치 프로그램 API를 사용하여 정적 네트워크 구성을 적용할 수 있습니다.

사전 요구 사항

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

프로세스

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

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

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

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

11.7. 추가 리소스

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

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

11.8.1. 사전 요구 사항

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

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

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

---
{
  "vip_dhcp_allocation": false,
  "network_type": "OVNKubernetes",
  "user_managed_networking": false,
  "api_vips": [
     {
        "ip": "192.168.127.100"
     },
     {
        "ip": "2001:0db8:85a3:0000:0000:8a2e:0370:7334"
     }
  ],
  "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. 제한

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

11.9. 추가 리소스

12장. 클러스터 확장

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

12.1. 다중 아키텍처 지원 확인

다른 아키텍처로 노드를 추가하기 전에 클러스터가 여러 아키텍처를 지원할 수 있는지 확인해야 합니다.

프로세스

  1. CLI를 사용하여 클러스터에 로그인합니다.
  2. 다음 명령을 실행하여 클러스터에서 아키텍처 페이로드를 사용하는지 확인합니다.

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

검증

  • 다음 출력이 표시되면 클러스터가 여러 아키텍처를 지원합니다.

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

12.2. 다중 아키텍처 클러스터 설치

x86_64 컨트롤 플레인이 있는 클러스터는 두 개의 다른 CPU 아키텍처가 있는 작업자 노드를 지원할 수 있습니다. 혼합 아키텍처 클러스터는 각 아키텍처의 장점을 결합하고 다양한 워크로드를 지원합니다.

예를 들어 arm 64,IBM Power 또는 IBM zSystems 작업자 노드를 x86_64 를 사용하여 기존 OpenShift Container Platform 클러스터에 추가할 수 있습니다.

설치의 주요 단계는 다음과 같습니다.

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

지원되는 플랫폼

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

OpenShift Container Platform 버전지원되는 플랫폼1일 컨트롤 플레인 아키텍처Day 2 노드 아키텍처

4.12.0

  • Microsoft Azure(TP)
  • x86_64
  • arm64

4.13.0

  • Microsoft Azure
  • Amazon Web Services
  • Bare Metal(TP)
  • x86_64
  • x86_64
  • x86_64
  • arm64
  • arm64
  • arm64

4.14.0

  • Microsoft Azure
  • Amazon Web Services
  • Bare Metal
  • Google Cloud Platform
  • IBM® Power®
  • IBM Z®
  • x86_64
  • x86_64
  • x86_64
  • x86_64
  • x86_64
  • x86_64
  • arm64
  • arm64
  • arm64
  • arm64
  • ppc64le
  • s390x
중요

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

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

주요 단계

  1. API를 사용하여 OpenShift Container Platform을 설치하는 절차를 시작합니다. 자세한 내용은 추가 리소스 섹션에서 지원 설치 관리자 API를 사용하여 설치를 참조하십시오.
  2. 설치의 "새 클러스터 등록" 단계에 도달하면 클러스터를 다중 아키텍처 클러스터로 등록합니다.

    $ curl -s -X POST https://api.openshift.com/api/assisted-install/v2/clusters \
    -H "Authorization: Bearer ${API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d "$(jq --null-input \
       --slurpfile pull_secret ~/Downloads/pull-secret.txt '
    {
       "name": "testcluster",
       "openshift_version": "<version-number>-multi", 1
       "cpu_architecture" : "multi" 2
       "high_availability_mode": "full" 3
       "base_dns_domain": "example.com",
       "pull_secret": $pull_secret[0] | tojson
    }
    ')" | jq '.id'
    참고
    1
    OpenShift Container Platform 버전 번호에 multi- 옵션을 사용합니다(예: "4.12-multi" ).
    2
    CPU 아키텍처의 를 "multi" 로 설정합니다.
    3
    전체 값을 사용하여 Multi-Node OpenShift Container Platform을 표시합니다.
  3. 설치의 "새 인프라 환경 등록" 단계에 도달하면 cpu_architecturex86_64 로 설정합니다.

    $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs \
    -H "Authorization: Bearer ${API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d "$(jq --null-input \
     --slurpfile pull_secret ~/Downloads/pull-secret.txt \
     --arg cluster_id ${CLUSTER_ID} '
       {
         "name": "testcluster-infra-env",
         "image_type":"full-iso",
         "cluster_id": $cluster_id,
         "cpu_architecture" : "x86_64"
         "pull_secret": $pull_secret[0] | tojson
       }
    ')" | jq '.id'
  4. 설치의 "호스트 추가" 단계에 도달하면 host_rolemaster 로 설정합니다.

    참고

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

    $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/<host_id> \
    -X PATCH \
    -H "Authorization: Bearer ${API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d '
       {
         "host_role":"master"
       }
    ' | jq
  5. x86_64 아키텍처의 검색 이미지를 다운로드합니다.
  6. 생성된 검색 이미지를 사용하여 x86_64 아키텍처 호스트를 부팅합니다.
  7. 설치를 시작하고 클러스터가 완전히 설치될 때까지 기다립니다.
  8. 설치의 "새 인프라 환경 등록" 단계를 반복합니다. 이번에는 cpu_architectureppc64le (IBM Power의 경우), s390x (IBM Z용) 또는 arm64 중 하나로 설정합니다. 예를 들면 다음과 같습니다.

    $ curl -s -X POST https://api.openshift.com/api/assisted-install/v2/clusters \
    -H "Authorization: Bearer ${API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d "$(jq --null-input \
       --slurpfile pull_secret ~/Downloads/pull-secret.txt '
    {
       "name": "testcluster",
       "openshift_version": "4.12",
       "cpu_architecture" : "arm64"
       "high_availability_mode": "full"
       "base_dns_domain": "example.com",
       "pull_secret": $pull_secret[0] | tojson
    }
    ')" | jq '.id'
  9. 설치의 "호스트 추가" 단계를 반복합니다. 이번에는 host_roleworker 로 설정합니다.

    참고

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

    $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/<host_id> \
    -X PATCH \
    -H "Authorization: Bearer ${API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d '
       {
         "host_role":"worker"
       }
    ' | jq
  10. arm64,ppc64 le 또는 s390x 아키텍처의 검색 이미지를 다운로드합니다.
  11. 생성된 검색 이미지를 사용하여 아키텍처 호스트를 부팅합니다.
  12. 설치를 시작하고 클러스터가 완전히 설치될 때까지 기다립니다.

검증

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

    $ oc get nodes -o wide

12.3. 웹 콘솔을 사용하여 호스트 추가

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

중요

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

프로세스

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

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

중요

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

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

지원 설치 프로그램 REST API를 사용하여 클러스터에 호스트를 추가할 수 있습니다.

사전 요구 사항

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

프로세스

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

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

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

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

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

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

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

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

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

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

    출력 예

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

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

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

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

    출력 예

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

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

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

    참고

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

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

    출력 예

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

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

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

    중요

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

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

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

    출력 예

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

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

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

    출력 예

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

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

검증

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

    $ oc get nodes

    출력 예

    NAME                           STATUS   ROLES           AGE   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 클러스터에 기본 컨트롤 플레인 노드를 설치하는 방법을 설명합니다.

클러스터가 비정상이면 추가 작업을 관리해야 관리할 수 있습니다. 자세한 내용은 추가 리소스 를 참조하십시오.

사전 요구 사항

  • 최소 3개의 노드가 있는 정상 클러스터가 설치되어 있습니다.
  • 단일 노드에 role: master할당되어 있습니다.

프로세스

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

    $ oc get csr | grep Pending

    출력 예

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

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

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

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

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

    $ oc get nodes

    출력 예

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

    참고

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

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

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

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

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

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

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

      #!/bin/bash
      
      # Credit goes to https://bugzilla.redhat.com/show_bug.cgi?id=1801238.
      # This script will link Machine object and Node object. This is needed
      # in order to have IP address of the Node present in the status of the Machine.
      
      # set -x
      set -e
      
      machine="$1"
      node="$2"
      
      if [ -z "$machine" ] || [ -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 print_nics() {
          local ips
          local eob
          declare -a ips
      
          readarray -t ips < <(echo "${1}" \
                               | jq '.[] | select(. | .type == "InternalIP") | .address' \
                               | sed 's/"//g')
      
          eob=','
          for (( i=0; i<${#ips[@]}; i++ )); do
              if [ $((i+1)) -eq ${#ips[@]} ]; then
                  eob=""
              fi
              cat <<- EOF
                {
                  "ip": "${ips[$i]}",
                  "mac": "00:00:00:00:00:00",
                  "model": "unknown",
                  "speedGbps": 10,
                  "vlanId": 0,
                  "pxe": true,
                  "name": "eth1"
                }${eob}
      EOF
          done
      }
      
      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
                  printf '\nTimed out waiting for %s' "${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 machines.machine.openshift.io -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')
      
      set +e
      read -r -d '' host_patch << EOF
      {
        "status": {
          "hardware": {
            "hostname": "${hostname}",
            "nics": [
      $(print_nics "${addresses}")
            ],
            "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": []
            }
          }
        }
      }
      EOF
      set -e
      
      echo "PATCHING HOST"
      echo "${host_patch}" | jq .
      
      curl -s \
           -X PATCH \
           "${HOST_PROXY_API_PATH}/${host}/status" \
           -H "Content-type: application/merge-patch+json" \
           -d "${host_patch}"
      
      oc get baremetalhost -n openshift-machine-api -o yaml "${host}"
      $ bash link-machine-and-node.sh custom-master3 worker-5
  5. etcd 멤버를 확인합니다.

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

    출력 예

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

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

    $ oc get clusteroperator etcd

    출력 예

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

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

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

    출력 예

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

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

    $ oc get nodes

    출력 예

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

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

    $ oc get ClusterOperators

    출력 예

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

  10. ClusterVersion 확인 :

    $ oc get ClusterVersion

    출력 예

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

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

    1. BareMetalHost CR을 삭제합니다.

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

      $ oc get machine -A

      출력 예

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

    3. Machine CR을 삭제합니다.

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

      $ oc get nodes

      출력 예

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

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

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

    출력 예

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

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

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

    출력 예

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

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

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

사전 요구 사항

  • 최소 3개의 노드가 있는 정상 클러스터가 설치되어 있습니다.
  • 컨트롤 플레인을 생성했습니다.
  • 단일 노드에 role: master할당되어 있습니다.

프로세스

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

    $ oc get nodes

    출력 예

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

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

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

    출력 예

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

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

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

    출력 예

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

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

    $ etcdctl endpoint health

    출력 예

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

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

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

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

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

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

    출력 예

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

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

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

    출력 예

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

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

    $ etcdctl endpoint health

    출력 예

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

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

    $ etcdctl member remove 61e2a86084aafa62

    출력 예

    Member 61e2a86084aafa62 removed from cluster 6881c977b97990d7

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

    $ etcdctl member list -w table

    출력 예

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

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

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

      $ oc get csr | grep Pending

      출력 예

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

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

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

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

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

    $ oc get nodes

    출력 예

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

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

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

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

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

    중요

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

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

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

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

    #!/bin/bash
    
    # Credit goes to https://bugzilla.redhat.com/show_bug.cgi?id=1801238.
    # This script will link Machine object and Node object. This is needed
    # in order to have IP address of the Node present in the status of the Machine.
    
    # set -x
    set -e
    
    machine="$1"
    node="$2"
    
    if [ -z "$machine" ] || [ -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 print_nics() {
        local ips
        local eob
        declare -a ips
    
        readarray -t ips < <(echo "${1}" \
                             | jq '.[] | select(. | .type == "InternalIP") | .address' \
                             | sed 's/"//g')
    
        eob=','
        for (( i=0; i<${#ips[@]}; i++ )); do
            if [ $((i+1)) -eq ${#ips[@]} ]; then
                eob=""
            fi
            cat <<- EOF
              {
                "ip": "${ips[$i]}",
                "mac": "00:00:00:00:00:00",
                "model": "unknown",
                "speedGbps": 10,
                "vlanId": 0,
                "pxe": true,
                "name": "eth1"
              }${eob}
    EOF
        done
    }
    
    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
                printf '\nTimed out waiting for %s' "${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 machines.machine.openshift.io -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')
    
    set +e
    read -r -d '' host_patch << EOF
    {
      "status": {
        "hardware": {
          "hostname": "${hostname}",
          "nics": [
    $(print_nics "${addresses}")
          ],
          "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": []
          }
        }
      }
    }
    EOF
    set -e
    
    echo "PATCHING HOST"
    echo "${host_patch}" | jq .
    
    curl -s \
         -X PATCH \
         "${HOST_PROXY_API_PATH}/${host}/status" \
         -H "Content-type: application/merge-patch+json" \
         -d "${host_patch}"
    
    oc get baremetalhost -n openshift-machine-api -o yaml "${host}"
    $ bash link-machine-and-node.sh custom-master3 worker-3
  18. 다음 명령을 실행하여 etcdctl 의 멤버를 확인합니다.

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

    출력 예

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

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

    $ oc get clusteroperator etcd

    출력 예

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

  20. etcdctl 의 상태 확인 :

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

    출력 예

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

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

    $ oc get Nodes

    출력 예

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

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

    $ oc get ClusterOperators

    출력 예

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

  23. ClusterVersion 확인 :

    $ oc get ClusterVersion

    출력 예

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

12.7. 추가 리소스

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

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

중요

OpenShift Container Platform 클러스터를 배포하고 일상적인 작업을 유지하려면 필요한 환경 요구 사항이 있는 Nutanix 계정에 액세스해야 합니다. 자세한 내용은 환경 요구 사항을 참조하십시오.

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

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

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

사전 요구 사항

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

프로세스

  1. 클러스터 세부 정보외부 파트너 플랫폼 드롭다운 목록에서 Integrate를 선택합니다. 사용자 정의 매니페스트 포함 확인란은 선택 사항입니다.
  2. 호스트 검색에서 호스트 추가 버튼을 클릭합니다.
  3. 선택 사항: core 사용자로 Nutanix VM에 연결할 수 있도록 SSH 공개 키를 추가합니다. 클러스터 호스트에 로그인하면 설치 중에 디버깅 정보를 제공할 수 있습니다.

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

    참고

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

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

    1. 선택 사항: 클러스터 호스트가 프록시를 사용해야 하는 방화벽 뒤에 있는 경우 클러스터 전체 프록시 설정 구성 을 선택합니다. 프록시 서버의 HTTP 및 HTTPS URL에 대한 사용자 이름, 암호, IP 주소 및 포트를 입력합니다.
    2. 선택 사항: Ignition 파일로 부팅하려면 검색 이미지를 구성합니다. 자세한 내용은 검색 이미지 구성을 참조하십시오.
  6. Discovery ISO 생성을 클릭합니다.
  7. Discovery ISO URL 을 복사합니다.
  8. Nutanix Prism UI에서 지침에 따라 지원 설치 관리자에서 검색 이미지를 업로드 합니다.
  9. Nutanix Prism UI에서 Prism Central을 통해 컨트롤 플레인(마스터) VM을 생성합니다.

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

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

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

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

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

사전 요구 사항

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

프로세스

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    참고

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

  18. Assisted Installer가 각 VM을 검색하고 검증을 통과할 때까지 기다립니다.

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

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

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 Central 포트.
  • <prismelement_username& gt; : Nutanix Prism Element 사용자 이름.
  • <prismelement_password > : Nutanix Prism Element 암호.
  • <prismelement_address > : Nutanix Prism Element 주소
  • <prismelement_port > : Nutanix Prism Element 포트.
  • <prismelement_clustername > : Nutanix Prism Element 클러스터 이름입니다.
  • <nutanix_storage_container > : Nutanix Prism 스토리지 컨테이너

프로세스

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

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

    샘플 출력

    infrastructure.config.openshift.io/cluster patched

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

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

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

    샘플 출력

    secret/nutanix-credentials created

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

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

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

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

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

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

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

      샘플 출력

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

13.3.2. Nutanix CSI Operator group 생성

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

참고

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

프로세스

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

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

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

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

    샘플 출력

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

13.3.3. Nutanix CSI Operator 설치

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

참고

OpenShift Container Platform 웹 콘솔을 통해 이 단계를 수행하는 방법은 추가 리소스 에서 Nutanix CSI Operator 문서의 Operator 설치 섹션을 참조하십시오.

프로세스

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

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

      $ oc get packagemanifests | grep nutanix

      샘플 출력

      nutanixcsioperator   Certified Operators   129m

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

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

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

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

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

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

    $ oc apply -f nutanixcsioperator.yaml

    샘플 출력

    subscription.operators.coreos.com/nutanixcsioperator created

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

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

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

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

참고

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

프로세스

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

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

    샘플 출력

    snutanixcsistorage.crd.nutanix.com/nutanixcsistorage created

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

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

    샘플 출력

    secret/nutanix-secret created

13.3.5. 설치 후 구성 검증

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

프로세스

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

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

    샘플 출력

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

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

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

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

      샘플 출력

      persistentvolumeclaim/nutanix-volume-pvc created

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

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

      샘플 출력

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

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

지원 설치 프로그램은 OpenShift Container Platform 클러스터를 vSphere에 노출하고 자동 스케일링을 활성화하는 vSphere 플랫폼과 통합합니다.

14.1. vSphere에 호스트 추가

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

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

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

사전 요구 사항

  • vSphere 7.0.2 이상을 사용하고 있습니다.
  • vSphere govc CLI 툴이 설치 및 구성되어 있습니다.
  • vSphere에서 clusterSet disk.enableUUIDtrue 로 설정해야 합니다.
  • 지원 설치 프로그램 웹 콘솔에서 클러스터를 생성했거나
  • API를 사용하여 지원 설치 관리자 클러스터 프로필 및 인프라 환경을 생성했습니다.
  • 쉘에서 인프라 환경 ID를 $INFRA_ENV_ID 로 내보냈습니다.

프로세스

  1. Ignition 파일로 부팅하려면 검색 이미지를 구성합니다.
  2. 클러스터 세부 정보외부 파트너 플랫폼 드롭다운 목록에서 vSphere를 선택합니다. 사용자 정의 매니페스트 포함 확인란은 선택 사항입니다.
  3. 호스트 검색에서 호스트 추가 버튼을 클릭하고 프로비저닝 유형을 선택합니다.
  4. core 사용자로 vSphere VM에 연결할 수 있도록 SSH 공개 키를 추가합니다. 클러스터 호스트에 로그인하면 설치 중에 디버깅 정보를 제공할 수 있습니다.

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

    참고

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

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

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

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

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

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

    $ for VM in $(/usr/local/bin/govc ls /<datacenter>/vm/<folder_name>)
    do
     	/usr/local/bin/govc vm.power -off $VM
     	/usr/local/bin/govc vm.destroy $VM
    done

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

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

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

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

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

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

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

    참고

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

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

    $ govc vm.create -net.adapter <network_adapter_type> \
                     -disk.controller <disk_controller_type> \
                     -pool=<resource_pool> \
                     -c=16 \
                     -m=32768 \
                     -disk=120GB \
                     -disk-datastore=<datastore_file> \
                     -net.address="<nic_mac_address>" \
                     -iso-datastore=<iso_datastore> \
                     -iso="vsphere-discovery-image.iso" \
                     -folder="<inventory_folder>" \
                     <hostname>.<cluster_name>.example.com

    자세한 내용은 vm.create 을 참조하십시오.

    참고

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

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

    $ govc vm.create -net.adapter <network_adapter_type> \
                     -disk.controller <disk_controller_type> \
                     -pool=<resource_pool> \
                     -c=4 \
                     -m=8192 \
                     -disk=120GB \
                     -disk-datastore=<datastore_file> \
                     -net.address="<nic_mac_address>" \
                     -iso-datastore=<iso_datastore> \
                     -iso="vsphere-discovery-image.iso" \
                     -folder="<inventory_folder>" \
                     <hostname>.<cluster_name>.example.com

    자세한 내용은 vm.create 을 참조하십시오.

    참고

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

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

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

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

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

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

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

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

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

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

    참고

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

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

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

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

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

14.2. CLI를 사용한 vSphere 설치 후 구성

플랫폼 통합 기능이 활성화된 vSphere의 지원 설치 관리자를 사용하여 OpenShift Container Platform 클러스터를 설치한 후 다음 vSphere 구성 설정을 수동으로 업데이트해야 합니다.

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

사전 요구 사항

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

프로세스

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

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

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

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

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

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

    $ oc get secret vsphere-creds -o yaml -n kube-system > creds_backup.yaml
  3. vSphere 인증 정보를 편집합니다.

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

    & lt;vcenter_address&gt;를 vCenter 주소로 바꿉니다. & lt;vcenter_username_encoded& gt;를 vSphere 사용자 이름의 base64 인코딩 버전으로 바꿉니다. & lt;vcenter_password_encoded& gt;를 vSphere 암호의 base64 인코딩 버전으로 바꿉니다.

  4. vSphere 인증 정보를 교체합니다.

    $ oc replace -f vsphere-creds.yaml
  5. kube-controller-manager Pod를 재배포합니다.

    $ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
  6. vSphere 클라우드 공급자 구성을 백업합니다.

    $ oc get cm cloud-provider-config -o yaml -n openshift-config > cloud-provider-config_backup.yaml
  7. 클라우드 공급자 구성을 편집합니다.

    $ cloud-provider-config_backup.yaml cloud-provider-config.yaml
    $ vi cloud-provider-config.yaml
    apiVersion: v1
    data:
      config: |
        [Global]
        secret-name = "vsphere-creds"
        secret-namespace = "kube-system"
        insecure-flag = "1"
    
        [Workspace]
        server = "<vcenter_address>"
        datacenter = "<datacenter>"
        default-datastore = "<datastore>"
        folder = "/<datacenter>/vm/<folder>"
    
        [VirtualCenter "<vcenter_address>"]
        datacenters = "<datacenter>"
    kind: ConfigMap
    metadata:
      creationTimestamp: "2022-01-25T17:40:49Z"
      name: cloud-provider-config
      namespace: openshift-config
      resourceVersion: "2070"
      uid: 80bb8618-bf25-442b-b023-b31311918507

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

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

    $ oc apply -f cloud-provider-config.yaml
  9. 초기화되지 않은 테인트가 있는 노드에 테인트를 적용합니다.

    중요

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

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

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

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

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

    예제

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

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

    $ oc get infrastructures.config.openshift.io -o yaml > infrastructures.config.openshift.io.yaml.backup
  11. 인프라 구성을 편집합니다.

    $ cp infrastructures.config.openshift.io.yaml.backup infrastructures.config.openshift.io.yaml
    $ vi infrastructures.config.openshift.io.yaml
    apiVersion: v1
    items:
    - apiVersion: config.openshift.io/v1
      kind: Infrastructure
      metadata:
        creationTimestamp: "2022-05-07T10:19:55Z"
        generation: 1
        name: cluster
        resourceVersion: "536"
        uid: e8a5742c-6d15-44e6-8a9e-064b26ab347d
      spec:
        cloudConfig:
          key: config
          name: cloud-provider-config
        platformSpec:
          type: VSphere
          vsphere:
            failureDomains:
            - name: assisted-generated-failure-domain
              region: assisted-generated-region
              server: <vcenter_address>
              topology:
                computeCluster: /<data_center>/host/<vcenter_cluster>
                datacenter: <data_center>
                datastore: /<data_center>/datastore/<datastore>
                folder: "/<data_center>/path/to/folder"
                networks:
                - "VM Network"
                resourcePool: /<data_center>/host/<vcenter_cluster>/Resources
              zone: assisted-generated-zone
            nodeNetworking:
              external: {}
              internal: {}
            vcenters:
            - datacenters:
              - <data_center>
              server: <vcenter_address>
    
    kind: List
    metadata:
      resourceVersion: ""

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

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

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

14.3. 웹 콘솔을 사용한 vSphere 설치 후 구성

플랫폼 통합 기능이 활성화된 vSphere의 지원 설치 관리자를 사용하여 OpenShift Container Platform 클러스터를 설치한 후 다음 vSphere 구성 설정을 수동으로 업데이트해야 합니다.

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

사전 요구 사항

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

프로세스

  1. 관리자 화면에서 홈 → 개요 로 이동합니다.
  2. Status 에서 vSphere connection 을 클릭하여 vSphere 연결 구성 마법사를 엽니다.
  3. vCenter 필드에 vSphere vCenter 서버의 네트워크 주소를 입력합니다. 도메인 이름 또는 IP 주소일 수 있습니다. vSphere 웹 클라이언트 URL(예: https://[your_vCenter_address]/ui )에 표시됩니다.
  4. vCenter 클러스터 필드에 OpenShift Container Platform이 설치된 vSphere vCenter 클러스터의 이름을 입력합니다.

    중요

    이 단계는 OpenShift Container Platform 4.13 이상을 설치한 경우 필수입니다.

  5. Username 필드에 vSphere vCenter 사용자 이름을 입력합니다.
  6. 암호 필드에 vSphere vCenter 암호를 입력합니다.

    주의

    시스템은 클러스터의 kube-system 네임스페이스에 있는 vsphere-creds 시크릿에 사용자 이름과 암호를 저장합니다. vCenter 사용자 이름 또는 암호가 잘못되어 클러스터 노드를 예약할 수 없습니다.

  7. Datacenter 필드에 클러스터를 호스팅하는 데 사용되는 가상 머신이 포함된 vSphere 데이터 센터의 이름(예: SDDC-Datacenter )을 입력합니다.
  8. Default 데이터 저장소 필드에 영구 데이터 볼륨을 저장하는 vSphere 데이터 저장소(예: /SDDC-Datacenter/datastore/datastore/datastore )를 입력합니다.

    주의

    구성이 저장된 후 vSphere 데이터 센터 또는 기본 데이터 저장소를 업데이트하면 활성 vSphere PersistentVolumes.

  9. 가상 머신 폴더 필드에 클러스터의 가상 머신이 포함된 데이터 센터 폴더(예: /SDDC-Datacenter/vm/ci-ln-hjg4vg2-c61657-t2gzr )를 입력합니다. OpenShift Container Platform 설치에 성공하려면 클러스터가 포함된 모든 가상 머신이 단일 데이터 센터 폴더에 있어야 합니다.
  10. Save Configuration 을 클릭합니다. 그러면 openshift-config 네임스페이스에서 cloud-provider-config 파일이 업데이트되고 구성 프로세스가 시작됩니다.
  11. vSphere 연결 구성 마법사를 다시 열고 Monitored operators 패널을 확장합니다. Operator의 상태가 Progressing 또는 Healthy 인지 확인합니다.

검증

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

다음 단계에 따라 구성 프로세스를 모니터링합니다.

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

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

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

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

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

      kind: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
       name: vsphere-sc
      provisioner: kubernetes.io/vsphere-volume
      parameters:
       datastore: YOURVCENTERDATASTORE
       diskformat: thin
      reclaimPolicy: Delete
      volumeBindingMode: Immediate
    2. 다음 YAML을 사용하여 PersistentVolumeClaims 오브젝트를 생성합니다.

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

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

15장. 선택 사항: OCI(Oracle Cloud Infrastructure)에 설치

OpenShift Container Platform 4.14 이상 버전에서는 지원 설치 관리자를 사용하여 사용자가 제공하는 인프라를 사용하여 Oracle Cloud Infrastructure에 클러스터를 설치할 수 있습니다. Oracle Cloud Infrastructure는 규정 준수, 성능 및 비용 효율성에 대한 요구 사항을 충족할 수 있는 서비스를 제공합니다. OCI Resource Manager 구성에 액세스하여 OCI 리소스를 프로비저닝하고 구성할 수 있습니다.

중요

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

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

이 섹션에서는 Oracle Cloud Infrastructure와의 통합을 지원하기 위해 지원 설치 관리자 웹 콘솔에 필요한 단계를 요약합니다. Oracle Cloud Infrastructure에서 수행할 단계를 기록하지 않으며 두 플랫폼 간의 통합도 다루지 않습니다. 완전하고 포괄적인 절차는 지원 설치 관리자 사용을 통해 OCI에 클러스터 설치를 참조하십시오.

15.1. OCI 호환 검색 ISO 이미지 생성

필요한 단계를 완료하여 지원 설치 프로그램에서 검색 ISO 이미지를 생성합니다. Oracle Cloud Infrastructure에 OpenShift Container Platform을 설치하기 전에 이미지를 Oracle Cloud Infrastructure에 업로드해야 합니다.

사전 요구 사항

  • Oracle Cloud Infrastructure에 하위 구분 및 오브젝트 스토리지 버킷을 생성했습니다. OpenShift Container Platform 설명서에서 OCI 리소스 및 서비스 생성 을 참조하십시오.
  • 클러스터 설치에 필요한 요구 사항을 충족합니다. 자세한 내용은 사전 요구 사항을 참조하십시오.

프로세스

  1. Red Hat Hybrid Cloud Console 에 로그인합니다.
  2. 클러스터 생성을 클릭합니다.
  3. 클러스터 유형 페이지에서 Datacenter 탭을 클릭합니다.
  4. 지원 설치 관리자 섹션에서 클러스터 생성을 클릭합니다.
  5. 클러스터 세부 정보 페이지에서 다음 필드를 완료합니다.

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

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

15.2. 노드 역할 및 사용자 정의 매니페스트 할당

OCI(Oracle Cloud Infrastructure) 리소스를 프로비저닝하고 OpenShift Container Platform 사용자 정의 매니페스트 구성 파일을 OCI에 업로드한 후 OCI 인스턴스를 생성하기 전에 지원 설치 관리자에서 나머지 클러스터 설치 단계를 완료해야 합니다.

사전 요구 사항

  • OCI에서 리소스 스택을 생성하고 스택에는 사용자 정의 매니페스트 구성 파일 및 OCI Resource Manager 구성 리소스가 포함됩니다. 자세한 내용은 OpenShift Container Platform 설명서에서 매니페스트 파일 및 배포 리소스 다운로드를 참조하십시오.

프로세스

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

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

16장. 문제 해결

지원 설치 관리자가 설치를 시작할 수 없거나 클러스터가 제대로 설치되지 않는 경우가 있습니다. 이러한 이벤트에서는 잠재적인 실패 모드와 오류 문제 해결 방법을 이해하는 것이 도움이 됩니다.

16.1. 검색 ISO 문제 해결

지원 설치 프로그램은 ISO 이미지를 사용하여 호스트를 클러스터에 등록하고 OpenShift 설치를 시도하기 전에 하드웨어 및 네트워크 검증을 수행하는 에이전트를 실행합니다. 다음 절차에 따라 호스트 검색과 관련된 문제를 해결할 수 있습니다.

검색 ISO 이미지로 호스트를 시작하면 지원 설치 프로그램에서 호스트를 검색하여 지원 서비스 웹 콘솔에 표시합니다. 자세한 내용은 검색 이미지 구성을 참조하십시오.

16.1.1. 검색 에이전트가 실행 중인지 확인

사전 요구 사항

  • API를 사용하여 인프라 환경을 생성하거나 웹 콘솔을 사용하여 클러스터를 생성했습니다.
  • 인프라 환경 검색 ISO를 사용하여 호스트를 부팅했으며 호스트는 등록하지 못했습니다.
  • 호스트에 대한 SSH 액세스 권한이 있어야 합니다.
  • Discovery ISO를 생성하기 전에 "호스트 추가" 대화 상자에 SSH 공개 키를 제공하여 암호 없이 시스템에 SSH로 연결할 수 있습니다.

프로세스

  1. 호스트 시스템의 전원이 켜져 있는지 확인합니다.
  2. DHCP 네트워킹 을 선택한 경우 DHCP 서버가 활성화되어 있는지 확인합니다.
  3. 정적 IP, 브리지 및 본딩 네트워킹을 선택한 경우 구성이 올바른지 확인합니다.
  4. SSH, BMC와 같은 콘솔 또는 가상 머신 콘솔을 사용하여 호스트 시스템에 액세스할 수 있는지 확인합니다.

    $ ssh core@<host_ip_address>

    기본 디렉터리에 저장되지 않는 경우 -i 매개변수를 사용하여 개인 키 파일을 지정할 수 있습니다.

    $ ssh -i <ssh_private_key_file> core@<host_ip_address>

    호스트에 ssh를 연결하지 못하면 부팅 중에 호스트가 실패하거나 네트워크를 구성하지 못했습니다.

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

    로그인 예

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

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

    $ sudo journalctl -u agent.service

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

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

    screenshot of agent service log

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

16.1.2. 에이전트가 assisted-service에 액세스할 수 있는지 확인합니다.

사전 요구 사항

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

프로세스

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

    $ sudo journalctl TAG=agent

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

    에이전트 로그의 예

    screenshot of the agent log failing to access the Assisted Service

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

16.2. 최소한의 검색 ISO 문제 해결

가상 미디어 연결을 통한 대역폭이 제한될 때 최소 ISO 이미지를 사용해야 합니다. 네트워킹을 통해 호스트를 부팅하는 데 필요한 항목만 포함됩니다. 대부분의 콘텐츠는 부팅 시 다운로드됩니다. 결과 ISO 이미지는 전체 ISO 이미지의 경우 1GB에 비해 약 100MB의 크기입니다.

16.2.1. 부팅 프로세스를 중단하여 최소 ISO 부팅 실패 문제 해결

환경에 지원 설치 프로그램 서비스에 액세스하기 위해 정적 네트워크 구성이 필요한 경우 해당 구성에 문제가 있으면 최소 ISO가 제대로 부팅되지 않을 수 있습니다. 호스트가 루트 파일 시스템 이미지를 다운로드하지 못했음을 부팅 화면에 표시되면 네트워크가 올바르게 구성되지 않을 수 있습니다.

루트 파일 시스템 이미지를 다운로드하기 전에 부트스트랩 프로세스 초기에 커널 부팅을 중단할 수 있습니다. 이를 통해 루트 콘솔에 액세스하고 네트워크 구성을 검토할 수 있습니다.

rootfs 다운로드 실패의 예

Failed root file system image download

프로세스

  1. 배포 중인 클러스터의 infraEnv 오브젝트에 .spec.kernelArguments 스탠자를 추가합니다.

    참고

    인프라 환경 수정에 대한 자세한 내용은 추가 리소스 를 참조하십시오.

    # ...
    spec:
      clusterRef:
        name: sno1
        namespace: sno1
      cpuArchitecture: x86_64
      ipxeScriptType: DiscoveryImageAlways
      kernelArguments:
      - operation: append
        value: rd.break=initqueue 1
      nmStateConfigLabelSelector:
        matchLabels:
          nmstate-label: sno1
      pullSecretRef:
        name: assisted-deployment-pull-secret
    1
    rd.break=initqueuedracut 기본 루프에서 부팅을 중단합니다. 자세한 내용은 커널 부팅 디버깅 옵션은 rd.break 옵션을 참조하십시오.
  2. 관련 노드가 자동으로 재부팅되고 rootfs 를 다운로드하기 전에 iniqueue 단계에서 부팅이 중단될 때까지 기다립니다. root 콘솔로 리디렉션됩니다.
  3. 잘못된 네트워크 구성을 식별하고 변경합니다. 다음은 몇 가지 유용한 진단 명령입니다.

    1. journalctl 을 사용하여 시스템 로그를 확인합니다. 예를 들면 다음과 같습니다.

      # journalctl -p err //Sorts logs by errors
      # journalctl -p crit //Sorts logs by critical errors
      # journalctl -p warning //Sorts logs by warnings
    2. 다음과 같이 nmcli 를 사용하여 네트워크 연결 정보를 확인합니다.

      # nmcli conn show
    3. 구성 파일에 잘못된 네트워크 연결이 있는지 확인합니다. 예를 들면 다음과 같습니다.

      # cat /etc/assisted/network/host0/eno3.nmconnection
  4. control+d 를 눌러 부트스트랩 프로세스를 다시 시작합니다. 서버는 rootfs 를 다운로드하고 프로세스를 완료합니다.
  5. infraEnv 오브젝트를 다시 열고 .spec.kernelArguments 스탠자를 제거합니다.

추가 리소스

16.3. 호스트의 부팅 순서 수정

Discovery Image의 일부로 실행되는 설치가 완료되면 지원 설치 프로그램이 호스트를 재부팅합니다.  클러스터를 계속 형성하려면 호스트를 설치 디스크에서 부팅해야 합니다.  호스트의 부팅 순서를 올바르게 구성하지 않은 경우 대신 다른 디스크에서 부팅되어 설치를 중단합니다.

호스트가 검색 이미지를 다시 부팅하면 지원 설치 관리자가 즉시 이 이벤트를 감지하고 호스트의 상태를 보류 중인 사용자 작업으로 설정합니다.  또는 지원 설치 프로그램에서 호스트가 할당된 시간 내에 올바른 디스크를 부팅했는지 감지하지 못하면 이 호스트 상태도 설정합니다.

프로세스

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

16.4. 부분적으로 성공한 설치 수정

지원 설치 프로그램이 오류가 발생하더라도 성공적으로 설치를 선언하는 경우가 있습니다.

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

16.5. 클러스터에 노드를 추가할 때 API 연결 실패

2일 차 작업의 일부로 기존 클러스터에 노드를 추가하면 노드가 1일 클러스터에서 ignition 구성 파일을 다운로드합니다. 다운로드에 실패하고 노드가 클러스터에 연결할 수 없는 경우 호스트 검색 단계의 호스트 상태가 부족으로 변경됩니다. 이 상태를 클릭하면 다음과 같은 오류 메시지가 표시됩니다.

The host failed to download the ignition file from <URL>. You must ensure the host can reach the URL. Check your DNS and network configuration or update the IP address or domain used to reach the cluster.

error: ignition file download failed.... no route to host

연결에 실패하는 데는 여러 가지 이유가 있습니다. 다음은 몇 가지 권장 작업입니다.

프로세스

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

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

    $ sudo journalctl TAG=agent
    참고

법적 공지

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.