Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

1.7. 호스팅된 컨트롤 플레인

다중 클러스터 엔진 Operator 클러스터 관리를 사용하면 독립 실행형 또는 호스팅된 컨트롤 플레인이라는 두 가지 컨트롤 플레인 구성을 사용하여 OpenShift Container Platform 클러스터를 배포할 수 있습니다. 독립 실행형 구성은 전용 가상 머신 또는 물리적 머신을 사용하여 OpenShift Container Platform 컨트롤 플레인을 호스팅합니다. OpenShift Container Platform의 호스팅된 컨트롤 플레인을 사용하면 각 컨트롤 플레인의 전용 물리적 머신 없이도 호스팅 클러스터에서 컨트롤 플레인을 Pod로 생성합니다.

OpenShift Container Platform의 호스팅된 컨트롤 플레인은 베어 메탈 및 Red Hat OpenShift Virtualization에서 사용할 수 있으며 AWS(Amazon Web Services)의 기술 프리뷰 기능으로 사용할 수 있습니다. OpenShift Container Platform 버전 4.14에서 컨트롤 플레인을 호스팅할 수 있습니다. 호스트된 컨트롤 플레인 기능은 기본적으로 활성화되어 있습니다.

1.7.1. 요구사항
링크 복사

다음 표는 각 플랫폼에 지원되는 OpenShift Container Platform 버전을 나타냅니다. 표에서 Cryostat OpenShift Container Platform 버전은 다중 클러스터 엔진 Operator가 활성화된 OpenShift Container Platform 버전을 나타냅니다.

Expand

플랫폼

OpenShift Container Platform 버전 호스팅

호스팅된 OpenShift Container Platform 버전

베어 메탈

4.14

4.14 (만 해당)

Red Hat OpenShift Virtualization

4.14

4.14 (만 해당)

AWS (기술 프리뷰)

4.11 - 4.14

4.14 (만 해당)

참고: 호스팅된 컨트롤 플레인의 동일한 플랫폼에서 허브 클러스터 및 작업자를 실행합니다.

컨트롤 플레인은 단일 네임스페이스에 포함되어 있고 호스팅된 컨트롤 플레인 클러스터와 연결된 Pod로 실행됩니다. OpenShift Container Platform은 이러한 유형의 호스팅 클러스터를 생성할 때 컨트롤 플레인과 독립적인 작업자 노드를 생성합니다.

프록시를 사용하고 Pod에서 Kubernetes API 서버로 전송되는 경우 기본 Kubernetes API 서버 주소인 172.20.0.1을 no_proxy 목록에 추가합니다.

호스팅된 컨트롤 플레인 클러스터는 다음과 같은 몇 가지 이점을 제공합니다.

  • 전용 컨트롤 플레인 노드를 호스팅할 필요가 없어 비용 절감
  • 컨트롤 플레인과 워크로드를 분리하여 격리를 개선하고 변경이 필요할 수 있는 구성 오류를 줄입니다.
  • 컨트롤 플레인 노드 부트스트랩에 대한 요구 사항을 제거하여 클러스터 생성 시간을 줄입니다.
  • 턴 키 배포 또는 완전히 사용자 지정된 OpenShift Container Platform 프로비저닝 지원

호스팅된 컨트롤 플레인을 사용하려면 다음 문서로 시작합니다.

  1. 호스팅된 컨트롤 플레인 크기 조정 지침
  2. 호스팅된 컨트롤 플레인 명령줄 인터페이스 설치
  3. 호스트된 클러스터 워크로드 배포

그런 다음 사용할 플랫폼과 관련된 설명서를 참조하십시오.

호스팅된 컨트롤 플레인에 대한 추가 리소스는 다음 OpenShift Container Platform 설명서를 참조하십시오.

1.7.2. 호스팅된 컨트롤 플레인 크기 조정 지침
링크 복사

호스트 클러스터 워크로드 및 작업자 노드 수를 포함한 많은 요인은 특정 컨트롤 플레인 노드 내에 적합한 호스트 클러스터 수에 영향을 미칩니다. 이 크기 조정 가이드를 사용하여 호스트된 클러스터 용량 계획에 도움이 됩니다. 이 가이드에서는 고가용성 호스팅 컨트롤 플레인 토폴로지를 가정합니다. 로드 기반 크기 조정 예제는 베어 메탈 클러스터에서 측정되었습니다. 클라우드 기반 인스턴스에는 메모리 크기와 같은 제한 요소가 다를 수 있습니다. 고가용성 호스팅 컨트롤 플레인 토폴로지에 대한 자세한 내용은 호스팅 된 클러스터 워크로드 배포를 참조하십시오.

OpenShift Container Platform 버전 4.12.9 이상에서 테스트된 다음 고가용성 호스팅 컨트롤 플레인 요구 사항을 참조하십시오.

  • 78 Pod
  • etcd의 경우 3GiB PV
  • 최소 vCPU: 약 5.5코어
  • 최소 메모리: 약 19GiB

1.7.2.1. Pod 제한
링크 복사

각 노드의 maxPods 설정은 컨트롤 플레인 노드에 들어갈 수 있는 호스트 클러스터 수에 영향을 미칩니다. 모든 control-plane 노드에서 maxPods 값을 기록하는 것이 중요합니다. 고가용성 호스팅 컨트롤 플레인마다 약 75개의 Pod를 계획합니다.

베어 메탈 노드의 경우 기본 maxPods 설정 250는 제한 요소가 될 수 있습니다. 이는 머신에 많은 리소스가 부족하더라도 Pod 요구 사항을 충족하는 각 노드에 대해 약 3개의 호스팅 컨트롤 플레인이 적합하기 때문입니다. KubeletConfig 값을 구성하여 maxPods 값을 500으로 설정하면 호스트된 컨트롤 플레인 밀도가 증가할 수 있으므로 추가 컴퓨팅 리소스를 활용할 수 있습니다. 자세한 내용은 OpenShift Container Platform 설명서 의 노드당 최대 Pod 수 구성 을 참조하십시오.

1.7.2.2. 요청 기반 리소스 제한
링크 복사

요청 기반 리소스 제한을 이해하려면 호스트된 컨트롤 플레인의 총 요청 값을 고려하십시오. 해당 값을 계산하려면 네임스페이스에서 고가용성 호스팅 컨트롤 플레인 Pod의 요청 값을 추가합니다. 다음 예제를 참조하십시오.

  • 고가용성 호스트 컨트롤 플레인마다 vCPU 요청 5개
  • 고가용성 호스트 컨트롤 플레인마다 18GiB 메모리 요청

1.7.2.3. 로드 기반 제한
링크 복사

요청 기반 크기 조정은 평균 리소스 사용량을 충족하는 Burstable 클래스의 최소 요청 합계를 기반으로 실행할 수 있는 최대 호스트 컨트롤 플레인 수를 제공합니다. 호스트된 클러스터 로드의 상위 수준에 맞게 조정되는 크기 조정 지침의 경우 로드 기반 접근 방식은 API 속도를 늘릴 때 리소스 사용량을 보여줍니다. 로드 기반 접근 방식은 더 높은 API 로드 포인트를 처리하기 위해 호스트된 컨트롤 플레인마다 리소스 용량을 빌드합니다.

예를 들어 API 로드를 사용하여 리소스 확장을 시연하려면 다음 워크로드 구성을 고려하십시오.

  • KubeVirt 공급자를 사용하여 9개의 작업자 (8 vCPU, 32GiB 각각)가 있는 호스트 클러스터 1개
  • 벤치마크 툴: Kube-burner

  • 워크로드 프로필은 다음 정의에 따라 API 컨트롤 플레인의 과부하에 중점을 두도록 구성된 클러스터 밀도 테스트입니다.

    • 네임스페이스당 오브젝트를 생성하고 총 100개의 네임스페이스로 확장
    • churn 매개변수가 활성화되어 지속적인 오브젝트 삭제 및 생성에 대한 추가 API 과부하가 발생할 수 있습니다.
    • 초당 워크로드 쿼리(QPS) 및 Burst 설정은 클라이언트 측 제한을 제거하기 위해 높게 설정됩니다.

리소스 사용률은 워크로드가 총 네임스페이스 수로 증가하면 측정됩니다. 이 데이터는 예상되는 API 로드에 따라 컴퓨팅 리소스 용량을 늘리기 위한 추정 요소를 제공했습니다. 정확한 사용률 비율은 클러스터 워크로드의 유형 및 속도에 따라 다를 수 있습니다.

Expand
호스트된 컨트롤 플레인 리소스 사용률 스케일링vCPU메모리(GiB)

기본 요청

5

18

유휴 상태일 때의 사용량

2.9

11.1

API 속도 1000당 증분 사용량 증가

9.0

2.5

이러한 예제를 사용하면 API에서 예상되는 과부하 속도를 기반으로 하는 부하 기반 제한을 인수할 수 있습니다. 이 제한은 3개의 호스팅된 API 서버에서 집계된 QPS로 측정됩니다. 일반적인 크기 조정을 위해 1000개의 QPS API 속도가 중간 호스트 클러스터 로드이고 2000 QPS API를 호스트하는 클러스터 로드가 높은 것으로 간주합니다.

활성 호스트 클러스터의 API 속도를 확인하려면 다음 메트릭을 사용하여 적절한 호스팅 네임스페이스에 대한 초당 쿼리 수를 측정하려면 Observe Metrics 를 선택하여 OpenShift Container Platform 웹 콘솔의 관리자 화면에서 쿼리할 수 있습니다. 

sum(rate(apiserver_request_total{namespace=~"clusters-$name*"}[2m])) by (namespace)
Copy to Clipboard Toggle word wrap

다음 예제에서는 워크로드 및 API 속도 정의에 대한 호스팅된 컨트롤 플레인 리소스 스케일링을 보여줍니다.

Expand
QPS(API 속도)vCPU 사용메모리 사용량(GiB)

50개 미만 QPS(낮음)

2.9

11.1

1000 QPS (medium)

11.9

13.6

2000 QPS (High)

20.9

16.1

호스트된 컨트롤 플레인 크기 조정은 API 활동, etcd 활동 또는 둘 다로 인해 발생하는 컨트롤 플레인 로드 및 워크로드에 관한 것입니다. 데이터베이스 실행과 같은 데이터 플레인 로드에 중점을 둔 호스팅된 Pod 워크로드는 API 비율이 높지 않을 수 있습니다.

1.7.2.4. 크기 조정 계산 예
링크 복사

이 예제에서는 다음 시나리오에 대한 크기 조정 지침을 제공합니다.

  • hypershift.openshift.io/control-plane 노드로 레이블이 지정된 베어 메탈 작업자 세 개
  • maxPods 값이 500으로 설정
  • 예상되는 API 속도는 로드 기반 제한에 따라 중간 또는 약 1000입니다.
Expand
표 1.7. 입력 제한
제한 설명서버 1서버 2

작업자 노드의 vCPU 수

64

128

작업자 노드의 메모리(GiB)

128

256

작업자당 최대 Pod 수

500

500

컨트롤 플레인을 호스팅하는 데 사용되는 작업자 수

3

3

최대 QPS 대상 속도(초당 API 요청)

1000

1000

Expand
표 1.8. 크기 조정 계산 예

작업자 노드 크기 및 API 속도를 기반으로 계산된 값

서버 1

서버 2

계산 노트

vCPU 요청을 기반으로 작업자당 최대 호스트 컨트롤 플레인

12.8

25.6

호스트된 컨트롤 플레인당 총 vCPU 요청 수 5개

vCPU 사용을 기반으로 작업자당 최대 호스트 컨트롤 플레인

5.4

10.7

vCPUS Cryostat (2.9 측정 유휴 vCPU 사용량 + (QPS 대상 비율 Cryostat 1000) × 9.0 QPS 증가당 vCPU 사용량 측정)

메모리 요청을 기반으로 작업자당 최대 호스트 컨트롤 플레인

7.1

14.2

작업자 메모리 GiB Cryostat 18GiB의 호스트된 컨트롤 플레인당 총 메모리 요청

메모리 사용량을 기반으로 작업자당 최대 호스트된 컨트롤 플레인

9.4

18.8

작업자 메모리 GiB Cryostat (1.1 측정 유휴 메모리 사용량 + (QPS 대상 비율 Cryostat 1000) × 2.5는 1000 QPS 증가당 메모리 사용량 측정)

노드 Pod 제한에 따라 작업자당 최대 호스트 컨트롤 플레인

6.7

6.7

호스팅된 컨트롤 플레인당 500 maxPods Cryostat 75개의 Pod

이전에 언급된 최소 최대값

5.4

6.7

 
 

vCPU 제한 요소

maxPods 제한 요소

 

관리 클러스터 내의 최대 호스트 컨트롤 플레인 수

16

20

이전에 언급된 최소 최대 × 3 개의 컨트롤 플레인 작업자

1.7.2.5. 추가 리소스
링크 복사

1.7.3. 호스팅된 컨트롤 플레인 명령줄 인터페이스 설치
링크 복사

다음 단계를 완료하여 호스팅된 컨트롤 플레인 명령줄 인터페이스 hcp 를 설치할 수 있습니다.

  1. OpenShift Container Platform 콘솔에서 도움말 아이콘 > 명령줄 툴 을 클릭합니다.
  2. 플랫폼에 대한 hcp CLI 다운로드를 클릭합니다.

  3. 다음 명령을 실행하여 다운로드한 아카이브의 압축을 풉니다. 

    tar xvzf hcp.tar.gz
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 바이너리 파일을 실행 가능하게 만듭니다. 

    chmod +x hcp
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 바이너리 파일을 경로의 디렉터리로 이동합니다. 

    sudo mv hcp /usr/local/bin/.
    Copy to Clipboard Toggle word wrap

다음 단계를 완료하여 CLI를 사용하여 호스팅되는 컨트롤 플레인 명령줄 인터페이스 hcp 를 설치할 수 있습니다.

  1. 다음 명령을 실행하여 hcp 바이너리를 다운로드하려면 URL을 가져옵니다. 

    oc get ConsoleCLIDownload hcp-cli-download -o json | jq -r ".spec"
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 hcp 바이너리를 다운로드합니다. 

    wget <hcp_cli_download_url>
    1
    Copy to Clipboard Toggle word wrap
    1
    hcp_cli_download_url 을 이전 단계에서 얻은 URL로 바꿉니다.

  3. 다음 명령을 실행하여 다운로드한 아카이브의 압축을 풉니다. 

    tar xvzf hcp.tar.gz
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 바이너리 파일을 실행 가능하게 만듭니다. 

    chmod +x hcp
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 바이너리 파일을 경로의 디렉터리로 이동합니다. 

    sudo mv hcp /usr/local/bin/.
    Copy to Clipboard Toggle word wrap

콘텐츠 게이트웨이를 사용하여 호스팅되는 컨트롤 플레인 명령줄 인터페이스 hcp 를 설치할 수 있습니다. 다음 단계를 완료합니다.

  1. 콘텐츠 게이트웨이로 이동하여 hcp 바이너리를 다운로드합니다.

  2. 다음 명령을 실행하여 다운로드한 아카이브의 압축을 풉니다. 

    tar xvzf hcp.tar.gz
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 바이너리 파일을 실행 가능하게 만듭니다. 

    chmod +x hcp
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 바이너리 파일을 경로의 디렉터리로 이동합니다. 

    sudo mv hcp /usr/local/bin/.
    Copy to Clipboard Toggle word wrap

이제 hcp create cluster 명령을 사용하여 호스팅 클러스터를 생성하고 관리할 수 있습니다. 사용 가능한 매개변수를 나열하려면 다음 명령을 입력합니다. 

hcp create cluster <platform> --help
1
Copy to Clipboard Toggle word wrap
1
지원되는 플랫폼은 aws,agent, kubevirt 입니다.

1.7.4. 호스트된 클러스터 워크로드 배포
링크 복사

OpenShift Container Platform의 호스트된 컨트롤 플레인을 시작하기 전에 호스트 클러스터의 Pod를 인프라 노드에 예약할 수 있도록 노드에 레이블을 올바르게 지정해야 합니다. 다음과 같은 이유로 노드 레이블 지정도 중요합니다.

  • 고가용성 및 적절한 워크로드 배포를 보장합니다. 예를 들어 OpenShift Container Platform 서브스크립션에 컨트롤 플레인 워크로드 수가 발생하지 않도록 node-role.kubernetes.io/infra 레이블을 설정할 수 있습니다.
  • 컨트롤 플레인 워크로드가 관리 클러스터의 다른 워크로드와 분리되어 있는지 확인하려면 다음을 수행하십시오.

중요: 워크로드에 관리 클러스터를 사용하지 마십시오. 컨트롤 플레인이 실행되는 노드에서 워크로드가 실행되지 않아야 합니다.

1.7.4.1. 관리 클러스터 노드의 라벨 및 테인트
링크 복사

관리 클러스터 관리자는 관리 클러스터 노드에서 다음 레이블 및 테인트를 사용하여 컨트롤 플레인 워크로드를 예약합니다.

  • Hypershift.openshift.io/control-plane: true: 이 레이블과 테인트를 사용하여 호스트된 컨트롤 플레인 워크로드를 실행하는 노드를 전용으로 사용합니다. true 값을 설정하면 컨트롤 플레인 노드를 관리 클러스터의 인프라 구성 요소 또는 실수로 배포된 워크로드와 같은 다른 구성 요소와 공유하지 않습니다.
  • Hypershift.openshift.io/cluster: ${HostedControlPlane Namespace}: 노드를 단일 호스트 클러스터에 전용으로 설정하려면 이 레이블과 테인트를 사용합니다.

control-plane Pod를 호스팅하는 노드에 다음 레이블을 적용합니다.

  • node-role.kubernetes.io/infra: 서브스크립션에 컨트롤 플레인 워크로드 수가 발생하지 않도록 이 라벨을 사용합니다.

  • topology.kubernetes.io/zone: 관리 클러스터 노드에서 이 레이블을 사용하여 장애 도메인에서 고가용성 클러스터를 배포합니다. 영역은 위치, 랙 이름 또는 영역이 설정된 노드의 호스트 이름이 될 수 있습니다. 예를 들어 관리 클러스터에는 worker-1a,worker-1b,worker-2a 및 worker-2b 와 같은 노드가 있습니다. worker-1a 및 worker-1b 노드는 rack1 에 있으며 worker-2a 및 worker-2b 노드는 rack2 에 있습니다. 각 랙을 가용성 영역으로 사용하려면 다음 명령을 입력합니다. 

    oc label node/worker-1a node/worker-1b topology.kubernetes.io/zone=rack1
oc label node/worker-2a node/worker-2b topology.kubernetes.io/zone=rack2
    Copy to Clipboard Toggle word wrap

호스팅된 클러스터의 Pod에는 허용 오차가 있으며 스케줄러는 선호도 규칙을 사용하여 스케줄링합니다. Pod는 컨트롤 플레인 및 Pod에 대한 클러스터 의 테인트를 허용합니다. 스케줄러는 hypershift.openshift.io/control-plane 및 hypershift.openshift.io/cluster: ${HostedControlPlane Namespace} 로 레이블이 지정된 노드에 Pod 예약에 우선순위를 지정합니다.

ControllerAvailabilityPolicy 옵션의 경우 호스팅된 컨트롤 플레인 명령줄 인터페이스인 hcp, deploy의 기본값인 HighlyAvailable 을 사용합니다. 이 옵션을 사용하면 topology.kubernetes.io/zone 을 토폴로지 키로 설정하여 다양한 장애 도메인에서 호스트된 클러스터 내에서 각 배포에 대한 Pod를 예약할 수 있습니다. 고가용성이 아닌 컨트롤 플레인은 지원되지 않습니다.

중요: 다음 절차에 자세히 설명된 노드 레이블 지정은 호스팅된 컨트롤 플레인을 배포하기 위한 사전 요구 사항입니다.

1.7.4.2. 호스팅된 클러스터의 노드 레이블
링크 복사

호스트 클러스터를 활성화하려면 다음 예와 같이 Pod를 인프라 노드에 예약해야 합니다. HostedCluster.spec.nodeSelector 를 설정합니다. 

  spec:
    nodeSelector:
      role.kubernetes.io/infra: ""
Copy to Clipboard Toggle word wrap

이렇게 하면 각 호스팅된 클러스터의 호스팅 컨트롤 플레인이 적합한 인프라 노드 워크로드이며 기본 OpenShift Container Platform 노드에 액세스할 필요가 없습니다.

1.7.4.3. 우선순위 클래스
링크 복사

기본 제공 우선순위 클래스 4개가 호스트된 클러스터 Pod의 우선 순위 및 선점에 영향을 미칩니다. 다음과 같은 순서로 관리 클러스터에 Pod를 생성할 수 있습니다.

  • Hypershift-operator: HyperShift Operator Pod
  • Hypershift-etcd: etcd 용 Pod
  • Hypershift-api-critical: API 호출 및 리소스 승인에 필요한 Pod입니다. 이러한 Pod에는 kube-apiserver, 집계 API 서버 및 웹 후크와 같은 Pod가 포함됩니다.
  • Hypershift-control-plane: API-critical는 아니지만 클러스터 버전 Operator와 같이 높은 우선 순위가 필요한 컨트롤 플레인의 Pod입니다.

1.7.4.4. 추가 리소스
링크 복사

호스팅된 컨트롤 플레인에 대한 자세한 내용은 다음 항목을 참조하십시오.

1.7.5. AWS에서 호스팅된 컨트롤 플레인 클러스터 구성 (기술 프리뷰)
링크 복사

호스팅된 컨트롤 플레인을 구성하려면 호스팅 클러스터와 호스팅 클러스터가 필요합니다. hypershift-addon 관리 클러스터 애드온을 사용하여 기존 관리 클러스터에 HyperShift Operator를 배포하면 해당 클러스터를 호스팅 클러스터로 활성화하고 호스팅 클러스터를 생성할 수 있습니다. Hypershift-addon 관리 클러스터 애드온은 다중 클러스터 엔진 Operator 2.4 및 Red Hat Advanced Cluster Management 2.9 허브 클러스터의 로컬 클러스터 관리 클러스터에 대해 기본적으로 활성화됩니다.

호스팅 클러스터는 호스팅 클러스터에서 호스팅되 는 API 끝점 및 컨트롤 플레인이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 클러스터에는 컨트롤 플레인과 해당 데이터 플레인이 포함됩니다. 다중 클러스터 엔진 Operator 콘솔 또는 호스팅된 컨트롤 플레인 명령줄 인터페이스인 hcp 를 사용하여 호스트된 클러스터를 생성할 수 있습니다. 호스팅된 클러스터는 관리 클러스터로 자동으로 가져옵니다. 이 자동 가져오기 기능을 비활성화하려면 호스팅된 클러스터를 멀티 클러스터 엔진 Operator로 자동 가져오기 비활성화 를 참조하십시오.

중요:

  • 각 호스팅된 클러스터에는 다중 클러스터 엔진 운영자가 관리할 수 있는 고유한 이름이 있어야 합니다.
  • 호스팅된 컨트롤 플레인의 동일한 플랫폼에서 허브 클러스터 및 작업자를 실행합니다.
  • 각 호스팅된 클러스터에는 다중 클러스터 엔진 운영자가 관리할 수 있는 고유한 이름이 있어야 합니다.
  • 호스트된 클러스터는 다중 클러스터 엔진 Operator 관리 클러스터의 네임스페이스에서 생성할 수 없습니다.

1.7.5.1. 사전 요구 사항
링크 복사

호스팅 클러스터를 구성하려면 다음 사전 요구 사항이 있어야 합니다.

  • Kubernetes Operator 2.4 이상용 멀티 클러스터 엔진은 OpenShift Container Platform 클러스터에 설치되어 있습니다. Red Hat Advanced Cluster Management를 설치할 때 다중 클러스터 엔진 Operator가 자동으로 설치됩니다. 멀티 클러스터 엔진 Operator는 OpenShift Container Platform OperatorHub의 Operator로 Red Hat Advanced Cluster Management 없이 설치할 수도 있습니다.

  • 다중 클러스터 엔진 Operator에는 하나 이상의 관리형 OpenShift Container Platform 클러스터가 있어야 합니다. local-cluster 는 다중 클러스터 엔진 Operator 2.4 이상에서 자동으로 가져옵니다. local-cluster 에 대한 자세한 내용은 고급 구성 을 참조하십시오. 다음 명령을 실행하여 허브 클러스터의 상태를 확인할 수 있습니다. 

    oc get managedclusters local-cluster
    Copy to Clipboard Toggle word wrap
  • AWS 명령줄 인터페이스
  • 호스팅된 컨트롤 플레인 명령줄 인터페이스

호스팅된 컨트롤 플레인에 대한 추가 리소스는 다음 문서를 참조하십시오.

1.7.5.2. Amazon Web Services S3 버킷 및 S3 OIDC 시크릿 생성
링크 복사

AWS에서 호스팅 클러스터를 생성하고 관리하려면 다음 단계를 완료합니다.

  1. 클러스터의 호스트 OIDC 검색 문서에 대한 공용 액세스 권한이 있는 S3 버킷을 생성합니다.

    • us-east-1 리전에 버킷을 생성하려면 다음 코드를 입력합니다. 

      BUCKET_NAME=<your_bucket_name>
aws s3api create-bucket --bucket $BUCKET_NAME
aws s3api delete-public-access-block --bucket $BUCKET_NAME
echo '{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::${BUCKET_NAME}/*"
        }
    ]
}' | envsubst > policy.json
aws s3api put-bucket-policy --bucket $BUCKET_NAME --policy file://policy.json
      Copy to Clipboard Toggle word wrap
    • us-east-1 리전 이외의 리전에서 버킷을 생성하려면 다음 코드를 입력합니다. 
    BUCKET_NAME=your-bucket-name
REGION=us-east-2
aws s3api create-bucket --bucket $BUCKET_NAME \
  --create-bucket-configuration LocationConstraint=$REGION \
  --region $REGION
aws s3api delete-public-access-block --bucket $BUCKET_NAME
echo '{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::${BUCKET_NAME}/*"
        }
    ]
}' | envsubst > policy.json
aws s3api put-bucket-policy --bucket $BUCKET_NAME --policy file://policy.json
    Copy to Clipboard Toggle word wrap
  2. HyperShift Operator에 대해 hypershift-operator-oidc-provider-s3-credentials 라는 OIDC S3 시크릿을 생성합니다.
  3. 로컬 클러스터 네임스페이스에 시크릿을 저장합니다.

  4. 다음 표를 참조하여 보안에 다음 필드가 포함되어 있는지 확인합니다.

    Expand
    필드 이름설명

    bucket

    HyperShift 클러스터에 대한 호스트 OIDC 검색 문서에 대한 공용 액세스가 가능한 S3 버킷을 포함합니다.

    인증 정보

    버킷에 액세스할 수 있는 기본 프로필의 자격 증명이 포함된 파일에 대한 참조입니다. 기본적으로 HyperShift는 기본 프로필만 사용하여 버킷 을 작동합니다.

    region

    S3 버킷의 리전을 지정합니다.

    다음 예제에서는 샘플 AWS 시크릿 템플릿을 보여줍니다. 

    oc create secret generic hypershift-operator-oidc-provider-s3-credentials --from-file=credentials=$HOME/.aws/credentials --from-literal=bucket=<s3-bucket-for-hypershift> --from-literal=region=<region> -n local-cluster
    Copy to Clipboard Toggle word wrap

    참고: 시크릿에 대한 재해 복구 백업은 자동으로 활성화되지 않습니다. 다음 명령을 실행하여 재해 복구를 위해 hypershift-operator-oidc-provider-s3-credentials 시크릿을 백업할 수 있는 레이블을 추가합니다. 

    oc label secret hypershift-operator-oidc-provider-s3-credentials -n local-cluster cluster.open-cluster-management.io/backup=true
    Copy to Clipboard Toggle word wrap

1.7.5.3. 라우팅 가능한 퍼블릭 영역 생성
링크 복사

게스트 클러스터의 애플리케이션에 액세스하려면 퍼블릭 영역을 라우팅할 수 있어야 합니다. 퍼블릭 영역이 있는 경우 이 단계를 건너뜁니다. 그렇지 않으면 퍼블릭 영역이 기존 기능에 영향을 미칩니다.

다음 명령을 실행하여 클러스터 DNS 레코드에 대한 퍼블릭 영역을 생성합니다. 

BASE_DOMAIN=www.example.com
aws route53 create-hosted-zone --name $BASE_DOMAIN --caller-reference $(whoami)-$(date --rfc-3339=date)
Copy to Clipboard Toggle word wrap

1.7.5.4. 외부 DNS 활성화
링크 복사

컨트롤 플레인과 데이터 플레인은 호스팅된 컨트롤 플레인에서 분리되어 있으므로 두 개의 독립적인 영역에서 DNS를 구성할 수 있습니다.

  • 호스트 클러스터 내의 워크로드에 대한 Ingress(예: *.apps.service-consumer-domain.com)
  • 서비스 공급자 도메인을 통한 API 또는 OAUTH 끝점과 같은 관리 클러스터 내의 서비스 끝점에 대한 Ingress: *.service-provider-domain.com

hostedCluster.spec.dns 의 입력은 호스팅된 클러스터 내의 워크로드에 대한 Ingress를 지정합니다. hostedCluster.spec.services.servicePublishingStrategy.route.hostname 의 입력은 관리 클러스터 내의 서비스 끝점의 Ingress를 지정합니다.

외부 DNS는 LoadBalancer 또는 Route 의 게시 유형을 지정하고 해당 게시 유형의 호스트 이름을 제공하는 호스팅 클러스터 서비스에 대한 이름 레코드를 생성합니다. Private 또는 PublicAndPrivate 엔드포인트 액세스 유형이 있는 호스팅 클러스터의 경우 APIServer 및 OAuth 서비스만 호스트 이름을 지원합니다. 프라이빗 호스트 클러스터의 경우 DNS 레코드는 VPC의 VPC(Virtual Private Cloud) 끝점의 프라이빗 IP로 확인됩니다.

호스팅된 컨트롤 플레인은 다음 네 가지 서비스를 노출합니다.

  • APIServer
  • OAuthServer
  • Konnectivity
  • Ignition

각 서비스는 HostedCluster 사양에서 servicePublishingStrategy 를 사용하여 노출됩니다. 기본적으로 LoadBalancer 및 Route 유형의 servicePublishingStrategy 에서는 다음 두 가지 방법 중 하나로 서비스를 게시합니다.

  • LoadBalancer 유형의 서비스 상태에 있는 로드 밸런서의 호스트 이름 사용
  • 경로의 status.host 필드에서

그러나 관리 서비스 컨텍스트에 호스팅되는 컨트롤 플레인을 배포할 때 이러한 방법은 기본 관리 클러스터의 Ingress 하위 도메인을 노출하고 관리 클러스터 라이프사이클 및 재해 복구에 대한 제한 옵션을 노출할 수 있습니다.

LoadBalancer 및 Route 게시 유형에 DNS indirection이 계층화된 경우 관리형 서비스 운영자는 서비스 수준 도메인을 사용하여 모든 공용 호스팅 클러스터 서비스를 게시할 수 있습니다. 이 아키텍처를 사용하면 DNS 이름을 새 LoadBalancer 또는 경로에 다시 매핑할 수 있으며 관리 클러스터의 Ingress 도메인을 노출하지 않습니다. 호스팅된 컨트롤 플레인은 외부 DNS를 사용하여 해당 간접 계층을 달성합니다.

관리 클러스터의 hypershift 네임스페이스에 hypershift Operator와 함께 external-dns 를 배포할 수 있습니다. 외부 DNS는 external-dns.alpha.kubernetes.io/hostname 주석이 있는 서비스 또는 경로를 감시합니다. 해당 주석은 레코드 또는 경로 (예: CNAME 레코드)와 같은 서비스를 가리키는 DNS 레코드를 생성하는 데 사용됩니다.

1.7.5.4.1. 사전 요구 사항
링크 복사

호스팅된 컨트롤 플레인에 대한 외부 DNS를 설정하려면 먼저 다음 사전 요구 사항을 충족해야 합니다.

  • 참조할 수 있는 외부 퍼블릭 도메인
  • AWS Route53 관리 콘솔에 액세스
1.7.5.4.2. 호스팅된 컨트롤 플레인의 외부 DNS 설정
링크 복사

서비스 수준 DNS(외부 DNS)를 사용하여 호스팅된 컨트롤 플레인 클러스터를 프로비저닝하려면 다음 단계를 완료합니다.

  1. HyperShift Operator에 대한 AWS 인증 정보 시크릿을 생성하고 local-cluster 네임스페이스에서 hypershift-operator-external-dns-credentials 이름을 지정합니다.

  2. 다음 표를 참조하여 보안에 필수 필드가 있는지 확인합니다.

    Expand
    필드 이름설명선택 사항 또는 필수

    공급자

    서비스 수준 DNS 영역을 관리하는 DNS 공급자입니다.

    필수 항목

    domain-filter

    서비스 수준 도메인입니다.

    필수 항목

    인증 정보

    모든 외부 DNS 유형을 지원하는 자격 증명 파일입니다.

    AWS 키를 사용할 때 선택 사항

    aws-access-key-id

    인증 정보 액세스 키 ID입니다.

    AWS DNS 서비스를 사용할 때 선택 사항

    aws-secret-access-key

    인증 정보 액세스 키 시크릿입니다.

    AWS DNS 서비스를 사용할 때 선택 사항

    다음 예제에서는 샘플 hypershift-operator-external-dns-credentials 시크릿 템플릿을 보여줍니다. 

    oc create secret generic hypershift-operator-external-dns-credentials --from-literal=provider=aws --from-literal=domain-filter=service.my.domain.com --from-file=credentials=<credentials-file> -n local-cluster
    Copy to Clipboard Toggle word wrap

    참고: 시크릿에 대한 재해 복구 백업은 자동으로 활성화되지 않습니다. 재해 복구를 위해 hypershift-operator-external-dns-credentials 시크릿을 백업할 수 있는 레이블을 추가하려면 다음 명령을 입력합니다. 

    oc label secret hypershift-operator-external-dns-credentials -n local-cluster cluster.open-cluster-management.io/backup=""
    Copy to Clipboard Toggle word wrap
1.7.5.4.3. 퍼블릭 DNS 호스팅 영역 생성
링크 복사

AWS Route 53 관리 콘솔에서 외부 DNS 도메인 필터로 사용할 퍼블릭 DNS 호스팅 영역을 생성할 수 있습니다.

  1. Route 53 관리 콘솔에서 호스팅 영역 생성을 클릭합니다.
  2. 호스팅 영역 구성 페이지에서 도메인 이름을 입력하고 게시 호스팅 영역이 유형으로 선택되어 있는지 확인하고 호스트 영역 생성 을 클릭합니다.
  3. 영역이 생성되면 레코드 탭에서 Value/Route 트래픽의 값을 열로 기록해 둡니다.
  4. 기본 도메인에서 NS 레코드를 생성하여 DNS 요청을 위임된 영역으로 리디렉션합니다. 값 필드에 이전 단계에서 기록한 값을 입력합니다.
  5. 레코드 생성을 클릭합니다.

  6. 새 하위 영역에 테스트 항목을 생성하고 다음 예와 같이 dig 명령으로 테스트하여 DNS 호스팅 영역이 작동하는지 확인합니다. 

    dig +short test.user-dest-public.aws.kerberos.com
192.168.1.1
    Copy to Clipboard Toggle word wrap

  7. LoadBalancer 및 Route 서비스의 호스트 이름을 설정하는 호스팅 클러스터를 생성하려면 다음 명령을 입력합니다. 여기서 external-dns-domain 은 사용자가 생성한 공개 호스팅 영역과 일치합니다. 

    hypershift create cluster aws --name=example --endpoint-access=PublicAndPrivate --external-dns-domain=service-provider-domain.com ...
    Copy to Clipboard Toggle word wrap

이 예에서는 호스팅된 클러스터에 대한 결과 서비스 블록을 보여줍니다. 

  platform:
    aws:
      endpointAccess: PublicAndPrivate
...
  services:
  - service: APIServer
    servicePublishingStrategy:
      route:
        hostname: api-example.service-provider-domain.com
      type: Route
  - service: OAuthServer
    servicePublishingStrategy:
      route:
        hostname: oauth-example.service-provider-domain.com
      type: Route
  - service: Konnectivity
    servicePublishingStrategy:
      type: Route
  - service: Ignition
    servicePublishingStrategy:
      type: Route
Copy to Clipboard Toggle word wrap

Control Plane Operator가 Services 및 Routes 를 생성할 때 external-dns.alpha.kubernetes.io/hostname 주석으로 주석을 답니다. 값은 해당 유형의 servicePublishingStrategy 의 hostname 필드입니다. Control Plane Operator는 서비스 끝점에 해당 이름을 사용하며 호스트 이름이 설정된 경우 DNS 레코드를 생성할 수 있는 external-dns 또는 기타와 같은 메커니즘이 존재합니다.

공용 서비스만 서비스 수준 DNS를 리디렉션할 수 있습니다. 프라이빗 서비스는 hypershift.local 프라이빗 영역을 사용하며 지정된 엔드포인트 액세스 유형에 대해 프라이빗 서비스의 호스트 이름을 설정하는 것은 유효하지 않습니다.

다음 표에서는 서비스 및 엔드포인트 조합에 대한 호스트 이름을 설정하는 것이 유효한 경우를 설명합니다.

Expand
Service퍼블릭PublicAndPrivate프라이빗

APIServer

Y

Y

N

OAuthServer

Y

Y

N

Konnectivity

Y

N

N

Ignition

Y

N

N

1.7.5.4.4. 명령줄 인터페이스 및 외부 DNS를 사용하여 클러스터 배포
링크 복사

외부 공개 호스팅 영역이 이미 존재하는 경우 hypershift 및 external-dns Operator를 배포해야 합니다. 다음 명령을 입력하여 external-dns Operator가 실행 중이며 내부 플래그가 공개 호스팅 영역을 가리키는지 확인합니다. 

export KUBECONFIG=<path_to_management_cluster_kubeconfig>
export AWS_CREDS=~/.aws/credentials
export REGION=<region>

hypershift create cluster aws \
    --aws-creds ${AWS_CREDS} \
    --instance-type m6i.xlarge \
    --region ${REGION} \
    --auto-repair \
    --generate-ssh \
    --name <cluster_name> \
    --namespace clusters \
    --base-domain service-consumer-domain.com \
1 

    --node-pool-replicas 2 \
    --pull-secret ${HOME}/pull_secret.json \
    --release-image quay.io/openshift-release-dev/ocp-release:4.12.0-ec.3-x86_64 \
    --external-dns-domain=service-provider-domain.com \
2 

    --endpoint-access=PublicAndPrivate
3
Copy to Clipboard Toggle word wrap
1
공용 호스팅 영역인 service-consumer-domain.com 을 가리킵니다. 이는 일반적으로 서비스 소비자가 소유한 AWS 계정에 있습니다.
2
일반적으로 서비스 공급자가 소유한 AWS 계정에 있는 공개 외부 DNS 호스팅 영역 service-provider-domain.com 을 가리킵니다.
3
PublicAndPrivate로 설정합니다. 외부 DNS는 공용 또는 Public AndPrivate 구성에서만 사용할 수 있습니다.

1.7.5.6. 호스트된 클러스터의 재해 복구
링크 복사

호스트된 컨트롤 플레인은 다중 클러스터 엔진 Operator 허브 클러스터에서 실행됩니다. 데이터 플레인은 선택한 별도의 플랫폼에서 실행됩니다. 재해에서 다중 클러스터 엔진 Operator 허브 클러스터를 복구할 때 호스트된 컨트롤 플레인을 복구해야 할 수도 있습니다.

호스팅된 컨트롤 플레인 클러스터를 백업하고 다른 클러스터에 복원하는 방법을 알아보려면 AWS 리전 내의 호스트 클러스터 재해 를 참조하십시오.

중요: 호스팅 클러스터의 재해 복구는 AWS에서만 사용할 수 있습니다.

1.7.5.7. AWS에 호스팅된 클러스터 배포
링크 복사

호스팅된 컨트롤 플레인 명령줄 인터페이스인 hcp 를 설정하고 local-cluster 를 호스팅 클러스터로 설정한 후 다음 단계를 완료하여 AWS에 호스팅 클러스터를 배포할 수 있습니다. 프라이빗 호스팅 클러스터를 배포하려면 AWS에 개인 호스팅 클러스터 배포를 참조하십시오.

  1. 필요에 따라 환경 변수를 인증 정보로 교체하여 다음과 같이 환경 변수를 설정합니다. 

    export REGION=us-east-1
export CLUSTER_NAME=clc-name-hs1
export INFRA_ID=clc-name-hs1
export BASE_DOMAIN=dev09.red-chesterfield.com
export AWS_CREDS=$HOME/name-aws
export PULL_SECRET=/Users/username/pull-secret.txt
export BUCKET_NAME=acmqe-hypershift
export BUCKET_REGION=us-east-1
    Copy to Clipboard Toggle word wrap

  2. CLUSTER_NAME 및 INFRA_ID 의 값이 동일한지 확인합니다. 그러지 않으면 Kubernetes Operator 콘솔의 다중 클러스터 엔진에 클러스터가 올바르게 표시되지 않을 수 있습니다. 각 변수에 대한 설명을 보려면 다음 명령을 실행합니다. 

    hcp create cluster aws --help
    Copy to Clipboard Toggle word wrap
  3. hub 클러스터에 로그인되어 있는지 확인합니다.

  4. 다음 명령을 실행하여 호스트된 클러스터를 생성합니다. 

    hcp create cluster aws \
    --name $CLUSTER_NAME \
    --infra-id $INFRA_ID \
    --base-domain $BASE_DOMAIN \
    --aws-creds $AWS_CREDS \
    --pull-secret $PULL_SECRET \
    --region $REGION \
    --generate-ssh \
    --node-pool-replicas 3 \
    --namespace <hypershift-hosting-service-cluster>
    Copy to Clipboard Toggle word wrap

    참고: 기본적으로 모든 HostedCluster 및 NodePool 사용자 정의 리소스는 클러스터 네임스페이스에 생성됩니다. --namespace <namespace> 매개변수를 지정하면 선택한 네임스페이스에 HostedCluster 및 NodePool 사용자 정의 리소스가 생성됩니다.

  5. 다음 명령을 실행하여 호스팅 클러스터의 상태를 확인할 수 있습니다. 

    oc get hostedclusters -n <hypershift-hosting-service-cluster>
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 실행하여 노드 풀을 확인할 수 있습니다. 

    oc get nodepools --namespace clusters
    Copy to Clipboard Toggle word wrap

1.7.5.8. AWS의 여러 영역에서 호스팅 클러스터 생성
링크 복사

다음 명령을 입력하여 퍼블릭 영역의 BASE_DOMAIN 을 지정하여 클러스터를 생성합니다. 

REGION=us-east-1
ZONES=us-east-1a,us-east-1b
CLUSTER_NAME=example
BASE_DOMAIN=example.com
AWS_CREDS="$HOME/.aws/credentials"
PULL_SECRET="$HOME/pull-secret"

hcp create cluster aws \
--name $CLUSTER_NAME \
--node-pool-replicas=3 \
--base-domain $BASE_DOMAIN \
--pull-secret $PULL_SECRET \
--aws-creds $AWS_CREDS \
--region $REGION \
--zones $ZONES
1
Copy to Clipboard Toggle word wrap
1
--zones 플래그는 --region 플래그에 의해 지정된 리전 내의 가용성 영역을 지정해야 합니다.

지정된 각 영역에 대해 다음 인프라가 생성됩니다.

  • 퍼블릭 서브넷
  • 프라이빗 서브넷
  • NAT 게이트웨이
  • 프라이빗 경로 테이블(공용 경로 테이블은 퍼블릭 서브넷에서 공유됨)

각 영역에 대해 하나의 NodePool 리소스가 생성됩니다. 노드 풀 이름은 영역 이름으로 접미사가 지정됩니다. 영역의 프라이빗 서브넷은 spec.platform.aws.subnet.id 에 설정됩니다.

1.7.5.8.1. AWS에서 호스팅 클러스터를 생성하기 위한 인증 정보 제공
링크 복사

hcp create cluster aws 명령을 사용하여 호스팅 클러스터를 생성할 때 클러스터에 대한 인프라 리소스를 생성할 수 있는 권한이 있는 AWS 계정 인증 정보를 제공해야 합니다. 인프라 리소스의 예로는 VPC, 서브넷 및 NAT 게이트웨이가 있습니다. --aws-creds 플래그를 사용하거나 다중 클러스터 엔진 Operator의 AWS 클라우드 공급자 시크릿을 사용하여 AWS 인증 정보를 제공할 수 있습니다.

1.7.5.8.1.1. --aws-creds 플래그를 사용하여 인증 정보 제공
링크 복사

--aws-creds 플래그를 사용하여 인증 정보를 제공하는 경우 해당 플래그를 AWS 인증 정보 파일 경로의 값과 함께 사용합니다.

다음 예제를 참조하십시오. 

hcp create cluster aws \
--name $CLUSTER_NAME \
--node-pool-replicas=3 \
--base-domain $BASE_DOMAIN \
--pull-secret $PULL_SECRET \
--aws-creds $AWS_CREDS \
--region $REGION \
Copy to Clipboard Toggle word wrap
1.7.5.8.1.2. AWS 클라우드 공급자 시크릿을 사용하여 인증 정보 제공
링크 복사

다중 클러스터 엔진 Operator의 AWS 클라우드 공급자 시크릿을 사용하여 인증 정보를 제공하는 경우 시크릿의 형식은 다음과 같습니다. 

apiVersion: v1
metadata:
  name: my-aws-cred
1 

  namespace: clusters
2 

type: Opaque
kind: Secret
stringData:
  ssh-publickey:          # Value
  ssh-privatekey:         # Value
  pullSecret:             # Value, required
  baseDomain:             # Value, required
  aws_secret_access_key:  # Value, required
  aws_access_key_id:      # Value, required
Copy to Clipboard Toggle word wrap
1
보안에 SSH 키, 풀 시크릿, 기본 도메인 및 AWS 인증 정보가 포함되어 있으므로 --secret-creds <my_aws_cred > 플래그와 함께 hcp create cluster aws 명령을 사용할 수 있습니다. 여기서 < my_aws_cred >는 클라우드 공급자 시크릿 이름입니다.
2
시크릿이 기본 클러스터 네임스페이스에 없는 경우 네임스페이스를 지정해야 합니다(예: --secret-creds <my_aws_cred> --namespace <name_of_namespace> ).

이 시크릿을 사용하면 다음 플래그는 선택 사항이 됩니다. --secret-creds <my_aws_cred > 플래그를 사용하여 이러한 플래그를 지정하면 이러한 플래그가 클라우드 공급자 시크릿의 값보다 우선합니다.

  • --aws-creds
  • --base-domain
  • --pull-secret
  • --ssh-key
  1. {mce-shortF} 콘솔을 사용하여 시크릿을 생성하려면 탐색 메뉴에서 인증 정보를 선택하고 콘솔의 인증 정보 생성 단계를 따릅니다.

  2. 명령줄에서 보안을 생성하려면 다음 명령을 입력합니다. 

    $ oc create secret generic <my_secret> -n <namespace> --from-literal=baseDomain='your.domain.com' --from-literal=aws_access_key_id='your-aws-access-key' --from-literal=aws_secret_access_key='your-aws-secret-key' --from-literal=pullSecret='{"auths":{"cloud.openshift.com":{"auth":"auth-info", "email":"xx@redhat.com"}, "quay.io":{"auth":"auth-info", "email":"xx@redhat.com"} } }' --from-literal=ssh-publickey='your-ssh-publickey' --from-literal=ssh-privatekey='your-ssh-privatekey'
    Copy to Clipboard Toggle word wrap
1.7.5.8.2. 추가 리소스
링크 복사

호스팅된 클러스터에 AWS EBS(Elastic File Service) CSI Driver Operator를 설치하는 방법은 보안 토큰 서비스를 사용하여 AWS EFS CSI Driver Operator 구성 을 참조하십시오.

관리 클러스터 환경의 OpenShift Container Platform ARM64 데이터 플레인과 함께 ARM64 호스팅 컨트롤 플레인을 사용할 수 있습니다. 이 기능은 AWS의 호스팅 컨트롤 플레인에서만 사용할 수 있습니다.

1.7.5.9.1. 사전 요구 사항
링크 복사

64비트 ARM 인프라에 설치된 OpenShift Container Platform 클러스터가 있어야 합니다. 자세한 내용은 Create an OpenShift Cluster: AWS (ARM) 를 참조하십시오.

ARM64 OpenShift Container Platform 클러스터에서 호스팅 클러스터를 실행하려면 다음 단계를 완료합니다.

  1. 다중 아키텍처 릴리스 이미지로 기본 릴리스 이미지를 덮어쓰는 호스팅 클러스터를 생성합니다.

    예를 들어 호스팅된 컨트롤 플레인 명령줄 인터페이스를 통해 hcp 를 입력하고 클러스터 이름, 노드 풀 복제본, 기본 도메인, 풀 시크릿, AWS 인증 정보 및 리전을 정보로 교체합니다. 

    hcp create cluster aws \
--name $CLUSTER_NAME \
--node-pool-replicas=$NODEPOOL_REPLICAS \
--base-domain $BASE_DOMAIN \
--pull-secret $PULL_SECRET \
--aws-creds $AWS_CREDS \
--region $REGION \
--release-image quay.io/openshift-release-dev/ocp-release:4.13.0-rc.0-multi
    Copy to Clipboard Toggle word wrap

    이 예제에서는 --node-pool-replicas 플래그를 통해 기본 NodePool 오브젝트를 추가합니다.

  2. 호스팅된 클러스터에 64비트 x_86 NodePool 오브젝트를 추가합니다.

    예를 들어 호스팅된 컨트롤 플레인 명령줄 인터페이스를 통해 hcp 를 입력하여 클러스터 이름, 노드 풀 이름 및 노드 풀 복제본을 정보로 교체합니다. 

    hcp create nodepool aws \
--cluster-name $CLUSTER_NAME \
--name $NODEPOOL_NAME \
--node-count=$NODEPOOL_REPLICAS
    Copy to Clipboard Toggle word wrap
1.7.5.9.3. AWS 호스팅 클러스터에서 ARM NodePool 오브젝트 생성
링크 복사

동일한 호스팅 컨트롤 플레인에서 64비트 ARM 및 AMD64에서 애플리케이션 워크로드(NodePool 오브젝트)를 예약할 수 있습니다. 이렇게 하려면 NodePool 사양에 arch 필드를 정의하여 NodePool 오브젝트에 필요한 프로세서 아키텍처를 설정합니다. arch 필드에 유효한 값은 다음과 같습니다.

  • arm64
  • amd64

arch 필드의 값을 지정하지 않으면 기본적으로 amd64 값이 사용됩니다.

AWS의 호스팅 클러스터에서 ARM NodePool 오브젝트를 생성하려면 다음 단계를 완료합니다.

  1. HostedCluster 사용자 정의 리소스에 사용할 다중 아키텍처 이미지가 있는지 확인합니다. https://multi.ocp.releases.ci.openshift.org/ 에서 다중 아키텍처 야간 이미지에 액세스할 수 있습니다.

    다중 아키텍처 이미지는 다음 예와 유사합니다. 

    % oc image info quay.io/openshift-release-dev/ocp-release-nightly@sha256:9b992c71f77501678c091e3dc77c7be066816562efe3d352be18128b8e8fce94 -a ~/pull-secrets.json

error: the image is a manifest list and contains multiple images - use --filter-by-os to select from:

  OS            DIGEST
  linux/amd64   sha256:c9dc4d07788ebc384a3d399a0e17f80b62a282b2513062a13ea702a811794a60
  linux/ppc64le sha256:c59c99d6ff1fe7b85790e24166cfc448a3c2ac3ef3422fce3c7259e48d2c9aab
  linux/s390x   sha256:07fcd16d5bee95196479b1e6b5b3b8064dd5359dac75e3d81f0bd4be6b8fe208
  linux/arm64   sha256:1d93a6beccc83e2a4c56ecfc37e921fe73d8964247c1a3ec34c4d66f175d9b3d
    Copy to Clipboard Toggle word wrap

  2. 호스팅된 컨트롤 플레인 명령줄 인터페이스 hcp 에 다음 명령을 입력하여 NodePool 오브젝트를 렌더링합니다. 

    hcp create nodepool aws --cluster-name $CLUSTER_NAME --name $ARM64_NODEPOOL_NAME --node-count=$NODEPOOL_REPLICAS --render > arm_nodepool_spec.yml
    Copy to Clipboard Toggle word wrap

    이 명령은 다음 예와 같이 NodePool 오브젝트의 CPU 아키텍처를 지정하는 YAML 파일을 생성합니다. 

    apiVersion: hypershift.openshift.io/v1beta1
kind: NodePool
metadata:
  creationTimestamp: null
  name: hypershift-arm-us-east-1a
  namespace: clusters
spec:
  arch: amd64
  clusterName: hypershift-arm
  management:
    autoRepair: false
    upgradeType: Replace
  nodeDrainTimeout: 0s
  platform:
    aws:
      instanceProfile: hypershift-arm-2m289-worker
      instanceType: m5.large
      rootVolume:
        size: 120
        type: gp3
      securityGroups:
      - id: sg-064ea63968d258493
      subnet:
        id: subnet-02c74cf1cf1e7413f
    type: AWS
  release:
    image: quay.io/openshift-release-dev/ocp-release-nightly@sha256:390a33cebc940912a201a35ca03927ae5b058fbdae9626f7f4679786cab4fb1c
  replicas: 3
status:
  replicas: 0
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 입력하여 YAML 파일에서 arch 및 instanceType 값을 수정합니다. 명령에서 ARM 인스턴스 유형은 m6g.large 이지만 모든 ARM 인스턴스 유형이 작동합니다. 

    sed 's/arch: amd64/arch: arm64/g; s/instanceType: m5.large/instanceType: m6g.large/g' arm_nodepool_spec.yml > temp.yml && mv temp.yml arm_nodepool_spec.yml
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 입력하여 렌더링된 YAML 파일을 호스팅 클러스터에 적용합니다. 

    oc apply -f arm_nodepool_spec.yml
    Copy to Clipboard Toggle word wrap

1.7.5.10. 호스트된 클러스터에 액세스
링크 복사

리소스에서 직접 kubeconfig 파일 및 kubeadmin 자격 증명을 가져오거나 hypershift 명령줄 인터페이스를 사용하여 kubeconfig 파일을 생성하여 호스팅 클러스터에 액세스할 수 있습니다.

  • 리소스에서 직접 kubeconfig 파일 및 인증 정보를 가져와서 호스팅되는 클러스터에 액세스하려면 호스팅된 컨트롤 플레인 클러스터의 액세스 시크릿을 숙지해야 합니다. 보안은 호스팅된 클러스터(호스팅) 네임스페이스에 저장됩니다. 호스팅된 클러스터(호스팅) 네임스페이스에는 호스팅된 클러스터 리소스가 포함되어 있으며 호스팅된 컨트롤 플레인 네임스페이스는 호스팅된 컨트롤 플레인이 실행되는 위치입니다.

    보안 이름 형식은 다음과 같습니다.

    • kubeconfig 시크릿: < hostingNamespace>-<name>-admin-kubeconfig (clusters-hypershift-demo-admin-kubeconfig)

    • kubeadmin 암호 시크릿: < hostingNamespace>-<name>-kubeadmin-password (clusters-hypershift-demo-kubeadmin-password)

      kubeconfig 시크릿에는 Base64로 인코딩된 kubeconfig 필드가 포함되어 있으며 다음 명령과 함께 사용할 파일에 디코딩하고 저장할 수 있습니다. 

      oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
      Copy to Clipboard Toggle word wrap

    kubeadmin 암호 시크릿도 Base64로 인코딩됩니다. 이를 디코딩하고 암호를 사용하여 호스팅된 클러스터의 API 서버 또는 콘솔에 로그인할 수 있습니다.

  • hypershift CLI를 사용하여 kubeconfig 파일을 생성하여 호스팅된 클러스터에 액세스하려면 다음 단계를 수행합니다.

    1. 다음 명령을 입력하여 kubeconfig 파일을 생성합니다. 

      hcp create kubeconfig --namespace ${CLUSTERS_NAMESPACE} --name ${HOSTED_CLUSTER_NAME} > ${HOSTED_CLUSTER_NAME}.kubeconfig
      Copy to Clipboard Toggle word wrap

    2. kubeconfig 파일을 저장한 후 다음 예제 명령을 입력하여 호스팅된 클러스터에 액세스할 수 있습니다. 

      oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
      Copy to Clipboard Toggle word wrap
1.7.5.10.1. 추가 리소스
링크 복사

호스팅된 클러스터에 액세스한 후 노드 풀을 확장하거나 호스팅된 클러스터에 대한 노드 자동 확장을 활성화할 수 있습니다. 자세한 내용은 다음 항목을 참조하십시오.

호스팅된 클러스터에 대한 노드 튜닝을 구성하려면 다음 항목을 참조하십시오.

1.7.5.11. AWS에 프라이빗 호스팅 클러스터 배포 (기술 프리뷰)
링크 복사

호스팅된 컨트롤 플레인 명령줄 인터페이스, hcp 를 설정하고 local-cluster 를 호스팅 클러스터로 설정한 후 호스팅 클러스터 또는 AWS에 개인 호스팅 클러스터를 배포할 수 있습니다. AWS에 공용 호스팅 클러스터를 배포하려면 AWS에 호스팅된 클러스터 배포를 참조하십시오.

기본적으로 호스팅되는 컨트롤 플레인 게스트 클러스터는 퍼블릭 DNS 및 관리 클러스터의 기본 라우터를 통해 공개적으로 액세스할 수 있습니다.

AWS의 프라이빗 클러스터의 경우 게스트 클러스터와의 모든 통신은 AWS PrivateLink를 통해 수행됩니다. AWS에서 프라이빗 클러스터 지원을 위해 호스팅되는 컨트롤 플레인을 구성하려면 다음 단계를 따르십시오.

중요: 모든 리전에서 퍼블릭 클러스터를 생성할 수 있지만 --aws-private-region 에서 지정하는 리전에서만 프라이빗 클러스터를 생성할 수 있습니다.

1.7.5.11.1. 사전 요구 사항
링크 복사

AWS용 프라이빗 호스팅 클러스터를 활성화하려면 먼저 AWS PrivateLink를 활성화해야 합니다. 자세한 내용은 AWS PrivateLink 활성화를 참조하십시오.

1.7.5.11.2. AWS에서 개인 호스트 클러스터 생성
링크 복사

  1. 다음 명령을 입력하여 개인 클러스터 IAM 정책 문서를 생성합니다. 

    cat << EOF >> policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateVpcEndpointServiceConfiguration",
        "ec2:DescribeVpcEndpointServiceConfigurations",
        "ec2:DeleteVpcEndpointServiceConfigurations",
        "ec2:DescribeVpcEndpointServicePermissions",
        "ec2:ModifyVpcEndpointServicePermissions",
        "ec2:CreateTags",
        "elasticloadbalancing:DescribeLoadBalancers"
      ],
      "Resource": "\*"
    }
  ]
}
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 AWS에서 IAM 정책을 생성합니다. 

    aws iam create-policy --policy-name=hypershift-operator-policy --policy-document=file://policy.json
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 입력하여 hypershift-operator IAM 사용자를 생성합니다. 

    aws iam create-user --user-name=hypershift-operator
    Copy to Clipboard Toggle word wrap

  4. 이 명령을 입력하여 hypershift-operator 사용자에게 정책을 연결하고 $POLICY_ARN 을 생성한 정책의 ARN으로 교체합니다. 

    aws iam attach-user-policy --user-name=hypershift-operator --policy-arn=$POLICY_ARN
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 입력하여 사용자의 IAM 액세스 키를 생성합니다. 

    aws iam create-access-key --user-name=hypershift-operator
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 입력하여 개인 호스팅 클러스터를 생성하고 필요에 따라 변수를 값으로 교체합니다. 

    CLUSTER_NAME=example
BASE_DOMAIN=example.com
AWS_CREDS="$HOME/.aws/credentials"
PULL_SECRET="$HOME/pull-secret"

hcp create cluster aws \
--name $CLUSTER_NAME \
--node-pool-replicas=3 \
--base-domain $BASE_DOMAIN \
--pull-secret $PULL_SECRET \
--aws-creds $AWS_CREDS \
--region $REGION \
--endpoint-access Private
    1
    Copy to Clipboard Toggle word wrap
    1
    --endpoint-access 플래그는 클러스터가 공용인지 프라이빗인지 여부를 지정합니다.

클러스터의 API 끝점은 프라이빗 DNS 영역을 통해 액세스할 수 있습니다.

  • api.$CLUSTER_NAME.hypershift.local
  • *.apps.$CLUSTER_NAME.hypershift.local
1.7.5.11.3. AWS에서 프라이빗 호스팅 클러스터에 액세스
링크 복사

프라이빗 클러스터에 액세스하려면 bastion을 사용합니다.

  1. 다음 명령을 입력하여 bastion 인스턴스를 시작하고 $SSH_KEY 를 bastion에 연결할 인증 정보로 교체합니다. 

    hypershift create bastion aws --aws-creds=$AWS_CREDS --infra-id=$INFRA_ID --region=$REGION --ssh-key-file=$SSH_KEY
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 클러스터 노드 풀에서 노드의 개인 IP를 찾습니다. 

    aws ec2 describe-instances --filter="Name=tag:kubernetes.io/cluster/$INFRA_ID,Values=owned" | jq '.Reservations[] | .Instances[] | select(.PublicDnsName=="") | .PrivateIpAddress'
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 입력하여 노드에 복사할 수 있는 클러스터의 kubeconfig 파일을 생성합니다. 

    hcp create kubeconfig > $CLUSTER_KUBECONFIG
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 입력하여 create bastion 명령에서 출력된 IP를 사용하여 bastion을 통해 노드 중 하나에 SSH를 입력합니다. 

    ssh -o ProxyCommand="ssh ec2-user@$BASTION_IP -W %h:%p" core@$NODE_IP
    Copy to Clipboard Toggle word wrap

  5. SSH 쉘에서 다음 명령을 입력하여 kubeconfig 파일 콘텐츠를 노드의 파일에 복사합니다. 

    cat << EOF >> kubeconfig
<paste kubeconfig contents>
export KUBECONFIG=$PWD/kubeconfig
    Copy to Clipboard Toggle word wrap

  6. SSH 쉘에서 게스트 클러스터 상태를 관찰하거나 다음 예와 같이 다른 oc 명령을 실행합니다. 

    oc get clusteroperators
oc get clusterversion
    Copy to Clipboard Toggle word wrap
1.7.5.11.4. 추가 리소스
링크 복사

AWS에 공용 호스트 클러스터를 배포하는 방법에 대한 자세한 내용은 AWS에 호스트 클러스터 배포를 참조하십시오.

AWS에서 Red Hat OpenShift Container Platform에 호스팅되는 컨트롤 플레인을 사용하는 경우 인프라 요구 사항은 설정에 따라 다릅니다.

1.7.5.12.1. 사전 요구 사항
링크 복사

호스팅된 컨트롤 플레인 클러스터를 생성하려면 먼저 호스팅 컨트롤 플레인을 구성해야 합니다. 자세한 내용은 AWS에서 호스팅되는 컨트롤 플레인 클러스터 구성 (기술 프리뷰) 을 참조하십시오.

1.7.5.12.2. AWS 인프라 요구사항
링크 복사

AWS에서 호스팅되는 컨트롤 플레인을 사용하는 경우 인프라 요구 사항은 다음 카테고리에 적합합니다.

  • 임의의 AWS 계정에서 HyperShift Operator에 대한 사전 요구 사항 및 관리되지 않는 인프라
  • 호스트 클러스터 AWS 계정에서 사전 요구 사항 및 관리되지 않는 인프라
  • 관리 AWS 계정에서 호스팅되는 컨트롤 플레인 관리 인프라
  • 호스트 클러스터 AWS 계정에서 호스팅된 컨트롤 플레인 관리 인프라
  • 호스트 클러스터 AWS 계정의 Kubernetes 관리 인프라

Prerequired 는 호스팅된 컨트롤 플레인이 제대로 작동하려면 AWS 인프라가 필요하다는 것을 의미합니다. Unmanaged 는 Operator 또는 컨트롤러가 사용자를 위한 인프라를 생성하지 않음을 의미합니다. 다음 섹션에는 AWS 리소스 생성에 대한 세부 정보가 포함되어 있습니다.

임의의 AWS 계정은 호스팅된 컨트롤 플레인 서비스 공급자에 따라 다릅니다.

자체 관리형 호스팅 컨트롤 플레인에서 클러스터 서비스 공급자는 AWS 계정을 제어합니다. 클러스터 서비스 공급자는 클러스터 컨트롤 플레인을 호스팅하고 가동 시간을 담당하는 관리자입니다. 관리형 호스팅 컨트롤 플레인에서 AWS 계정은 Red Hat에 속합니다.

HyperShift Operator에 대한 사전 필수 및 관리되지 않는 인프라에서 다음 인프라 요구 사항이 관리 클러스터 AWS 계정에 적용됩니다.

  • S3 버킷 1개

    • OpenID Connect(OIDC)

  • Route 53 호스팅 영역

    • 호스팅된 클러스터의 프라이빗 및 공용 항목을 호스트하는 도메인

호스트 클러스터 AWS 계정에서 인프라가 사전 필수적이고 관리되지 않는 경우 모든 액세스 모드에 대한 인프라 요구 사항은 다음과 같습니다.

  • VPC 1개
  • DHCP 옵션 1개

  • 두 개의 서브넷

    • 내부 데이터 플레인 서브넷인 프라이빗 서브넷
    • 데이터 플레인에서 인터넷에 액세스할 수 있는 공용 서브넷
  • 하나의 인터넷 게이트웨이
  • 탄력적 IP 1개
  • NAT 게이트웨이 1개
  • 하나의 보안 그룹(작업자 노드)
  • 두 개의 경로 테이블(개인 1개 및 공용)
  • 두 개의 Route 53 호스팅 영역

  • 다음 항목에 대한 할당량이 충분합니다.

    • 퍼블릭 호스팅 클러스터를 위한 하나의 Ingress 서비스 로드 밸런서
    • 프라이빗 호스팅 클러스터용 프라이빗 링크 끝점 1개

참고: 개인 링크 네트워킹이 작동하려면 호스팅 클러스터 AWS 계정의 끝점 영역이 관리 클러스터 AWS 계정의 서비스 끝점에 의해 해결되는 인스턴스의 영역과 일치해야 합니다. AWS에서 영역 이름은 us-east-2b 와 같은 별칭이며, 다른 계정의 동일한 영역에 매핑되지는 않습니다. 결과적으로 개인 링크가 작동하려면 관리 클러스터에 해당 리전의 모든 영역에 서브넷 또는 작업자가 있어야 합니다.

1.7.5.12.2.3. 관리 AWS 계정에서 호스팅되는 컨트롤 플레인 관리 인프라
링크 복사

관리 AWS 계정의 호스팅된 컨트롤 플레인에서 인프라를 관리하는 경우 클러스터의 퍼블릭, 프라이빗 또는 조합 여부에 따라 인프라 요구 사항이 다릅니다.

퍼블릭 클러스터가 있는 계정의 경우 인프라 요구 사항은 다음과 같습니다.

  • 네트워크 로드 밸런서: 로드 밸런서 Kube API 서버

    • Kubernetes에서 보안 그룹을 생성합니다.

  • volumes

    • etcd의 경우 (고용도에 따라 1개 또는 3개)
    • OVN-Kube의 경우

프라이빗 클러스터가 있는 계정의 경우 인프라 요구 사항은 다음과 같습니다.

  • 네트워크 로드 밸런서: 로드 밸런서 개인 라우터
  • 엔드포인트 서비스(개인 링크)

퍼블릭 및 프라이빗 클러스터가 있는 계정의 경우 인프라 요구 사항은 다음과 같습니다.

  • 네트워크 로드 밸런서: 로드 밸런서 공용 라우터
  • 네트워크 로드 밸런서: 로드 밸런서 개인 라우터
  • 엔드포인트 서비스(개인 링크)

  • volumes:

    • etcd의 경우 (고용도에 따라 1개 또는 3개)
    • OVN-Kube의 경우

호스팅된 클러스터 AWS 계정의 호스팅된 컨트롤 플레인에서 인프라를 관리하는 경우 클러스터의 퍼블릭, 프라이빗 또는 조합에 따라 인프라 요구 사항이 다릅니다.

퍼블릭 클러스터가 있는 계정의 경우 인프라 요구 사항은 다음과 같습니다.

  • 노드 풀에는 Role 및 RolePolicy 가 정의된 EC2 인스턴스가 있어야 합니다.

프라이빗 클러스터가 있는 계정의 경우 인프라 요구 사항은 다음과 같습니다.

  • 각 가용성 영역에 대해 하나의 개인 링크 끝점
  • 노드 풀용 EC2 인스턴스

퍼블릭 및 프라이빗 클러스터가 있는 계정의 경우 인프라 요구 사항은 다음과 같습니다.

  • 각 가용성 영역에 대해 하나의 개인 링크 끝점
  • 노드 풀용 EC2 인스턴스
1.7.5.12.2.5. 호스트 클러스터 AWS 계정의 Kubernetes 관리 인프라
링크 복사

Kubernetes가 호스팅 클러스터 AWS 계정에서 인프라를 관리하는 경우 인프라 요구 사항은 다음과 같습니다.

  • 기본 Ingress의 네트워크 로드 밸런서
  • 레지스트리의 S3 버킷
1.7.5.12.3. IAM(Identity and Access Management) 권한
링크 복사

호스트된 컨트롤 플레인의 컨텍스트에서 소비자는 ARM(Amazon Resource Name) 역할을 생성합니다. 소비자 는 권한 파일을 생성하기 위한 자동화된 프로세스입니다. 소비자는 명령줄 인터페이스 또는 OpenShift Cluster Manager일 수 있습니다. 호스팅된 컨트롤 플레인은 최소 권한 구성 요소의 원칙을 준수하기 위해 세분성을 활성화하려고 합니다. 즉, 모든 구성 요소가 자체 역할을 사용하여 AWS 오브젝트를 작동하거나 생성하며 역할이 제품이 정상적으로 작동하는 데 필요한 항목으로 제한됩니다.

명령줄 인터페이스에서 ARN 역할을 생성할 수 있는 방법의 예는 "AWS 인프라 및 IAM 리소스 생성"을 참조하십시오.

호스트된 클러스터는 ARN 역할을 입력으로 수신하고 소비자는 각 구성 요소에 대한 AWS 권한 구성을 생성합니다. 결과적으로 구성 요소는 STS 및 사전 구성된 OIDC IDP를 통해 인증할 수 있습니다.

다음 역할은 컨트롤 플레인에서 실행되고 데이터 플레인에서 작동하는 호스팅된 컨트롤 플레인의 일부 구성 요소에서 소비됩니다.

  • controlPlaneOperatorARN
  • imageRegistryARN
  • ingressARN
  • kubeCloudControllerARN
  • nodePoolManagementARN
  • storageARN
  • networkARN

다음 예제는 호스팅된 클러스터의 IAM 역할에 대한 참조를 보여줍니다. 

...
endpointAccess: Public
  region: us-east-2
  resourceTags:
  - key: kubernetes.io/cluster/example-cluster-bz4j5
    value: owned
rolesRef:
    controlPlaneOperatorARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-control-plane-operator
    imageRegistryARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-openshift-image-registry
    ingressARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-openshift-ingress
    kubeCloudControllerARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-cloud-controller
    networkARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-cloud-network-config-controller
    nodePoolManagementARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-node-pool
    storageARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-aws-ebs-csi-driver-controller
type: AWS
...
Copy to Clipboard Toggle word wrap

컨트롤 플레인에서 사용하는 역할은 다음 예에 표시됩니다.

  • ingressARN 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:DescribeLoadBalancers",
                "tag:GetResources",
                "route53:ListHostedZones"
            ],
            "Resource": "\*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:ChangeResourceRecordSets"
            ],
            "Resource": [
                "arn:aws:route53:::PUBLIC_ZONE_ID",
                "arn:aws:route53:::PRIVATE_ZONE_ID"
            ]
        }
    ]
}
    Copy to Clipboard Toggle word wrap

  • imageRegistryARN 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:CreateBucket",
                "s3:DeleteBucket",
                "s3:PutBucketTagging",
                "s3:GetBucketTagging",
                "s3:PutBucketPublicAccessBlock",
                "s3:GetBucketPublicAccessBlock",
                "s3:PutEncryptionConfiguration",
                "s3:GetEncryptionConfiguration",
                "s3:PutLifecycleConfiguration",
                "s3:GetLifecycleConfiguration",
                "s3:GetBucketLocation",
                "s3:ListBucket",
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:ListBucketMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": "\*"
        }
    ]
}
    Copy to Clipboard Toggle word wrap

  • storageARN 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:AttachVolume",
                "ec2:CreateSnapshot",
                "ec2:CreateTags",
                "ec2:CreateVolume",
                "ec2:DeleteSnapshot",
                "ec2:DeleteTags",
                "ec2:DeleteVolume",
                "ec2:DescribeInstances",
                "ec2:DescribeSnapshots",
                "ec2:DescribeTags",
                "ec2:DescribeVolumes",
                "ec2:DescribeVolumesModifications",
                "ec2:DetachVolume",
                "ec2:ModifyVolume"
            ],
            "Resource": "\*"
        }
    ]
}
    Copy to Clipboard Toggle word wrap

  • networkARN 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeInstanceStatus",
                "ec2:DescribeInstanceTypes",
                "ec2:UnassignPrivateIpAddresses",
                "ec2:AssignPrivateIpAddresses",
                "ec2:UnassignIpv6Addresses",
                "ec2:AssignIpv6Addresses",
                "ec2:DescribeSubnets",
                "ec2:DescribeNetworkInterfaces"
            ],
            "Resource": "\*"
        }
    ]
}
    Copy to Clipboard Toggle word wrap

  • kubeCloudControllerARN 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeImages",
                "ec2:DescribeRegions",
                "ec2:DescribeRouteTables",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeVolumes",
                "ec2:CreateSecurityGroup",
                "ec2:CreateTags",
                "ec2:CreateVolume",
                "ec2:ModifyInstanceAttribute",
                "ec2:ModifyVolume",
                "ec2:AttachVolume",
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:CreateRoute",
                "ec2:DeleteRoute",
                "ec2:DeleteSecurityGroup",
                "ec2:DeleteVolume",
                "ec2:DetachVolume",
                "ec2:RevokeSecurityGroupIngress",
                "ec2:DescribeVpcs",
                "elasticloadbalancing:AddTags",
                "elasticloadbalancing:AttachLoadBalancerToSubnets",
                "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
                "elasticloadbalancing:CreateLoadBalancer",
                "elasticloadbalancing:CreateLoadBalancerPolicy",
                "elasticloadbalancing:CreateLoadBalancerListeners",
                "elasticloadbalancing:ConfigureHealthCheck",
                "elasticloadbalancing:DeleteLoadBalancer",
                "elasticloadbalancing:DeleteLoadBalancerListeners",
                "elasticloadbalancing:DescribeLoadBalancers",
                "elasticloadbalancing:DescribeLoadBalancerAttributes",
                "elasticloadbalancing:DetachLoadBalancerFromSubnets",
                "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
                "elasticloadbalancing:ModifyLoadBalancerAttributes",
                "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
                "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
                "elasticloadbalancing:AddTags",
                "elasticloadbalancing:CreateListener",
                "elasticloadbalancing:CreateTargetGroup",
                "elasticloadbalancing:DeleteListener",
                "elasticloadbalancing:DeleteTargetGroup",
                "elasticloadbalancing:DescribeListeners",
                "elasticloadbalancing:DescribeLoadBalancerPolicies",
                "elasticloadbalancing:DescribeTargetGroups",
                "elasticloadbalancing:DescribeTargetHealth",
                "elasticloadbalancing:ModifyListener",
                "elasticloadbalancing:ModifyTargetGroup",
                "elasticloadbalancing:RegisterTargets",
                "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
                "iam:CreateServiceLinkedRole",
                "kms:DescribeKey"
            ],
            "Resource": [
                "\*"
            ],
            "Effect": "Allow"
        }
    ]
}
    Copy to Clipboard Toggle word wrap

  • nodePoolManagementARN 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:AllocateAddress",
                "ec2:AssociateRouteTable",
                "ec2:AttachInternetGateway",
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:CreateInternetGateway",
                "ec2:CreateNatGateway",
                "ec2:CreateRoute",
                "ec2:CreateRouteTable",
                "ec2:CreateSecurityGroup",
                "ec2:CreateSubnet",
                "ec2:CreateTags",
                "ec2:DeleteInternetGateway",
                "ec2:DeleteNatGateway",
                "ec2:DeleteRouteTable",
                "ec2:DeleteSecurityGroup",
                "ec2:DeleteSubnet",
                "ec2:DeleteTags",
                "ec2:DescribeAccountAttributes",
                "ec2:DescribeAddresses",
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeImages",
                "ec2:DescribeInstances",
                "ec2:DescribeInternetGateways",
                "ec2:DescribeNatGateways",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DescribeNetworkInterfaceAttribute",
                "ec2:DescribeRouteTables",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeVpcs",
                "ec2:DescribeVpcAttribute",
                "ec2:DescribeVolumes",
                "ec2:DetachInternetGateway",
                "ec2:DisassociateRouteTable",
                "ec2:DisassociateAddress",
                "ec2:ModifyInstanceAttribute",
                "ec2:ModifyNetworkInterfaceAttribute",
                "ec2:ModifySubnetAttribute",
                "ec2:ReleaseAddress",
                "ec2:RevokeSecurityGroupIngress",
                "ec2:RunInstances",
                "ec2:TerminateInstances",
                "tag:GetResources",
                "ec2:CreateLaunchTemplate",
                "ec2:CreateLaunchTemplateVersion",
                "ec2:DescribeLaunchTemplates",
                "ec2:DescribeLaunchTemplateVersions",
                "ec2:DeleteLaunchTemplate",
                "ec2:DeleteLaunchTemplateVersions"
            ],
            "Resource": [
                "\*"
            ],
            "Effect": "Allow"
        },
        {
            "Condition": {
                "StringLike": {
                    "iam:AWSServiceName": "elasticloadbalancing.amazonaws.com"
                }
            },
            "Action": [
                "iam:CreateServiceLinkedRole"
            ],
            "Resource": [
                "arn:*:iam::*:role/aws-service-role/elasticloadbalancing.amazonaws.com/AWSServiceRoleForElasticLoadBalancing"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "iam:PassRole"
            ],
            "Resource": [
                "arn:*:iam::*:role/*-worker-role"
            ],
            "Effect": "Allow"
        }
    ]
}
    Copy to Clipboard Toggle word wrap

  • controlPlaneOperatorARN 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateVpcEndpoint",
                "ec2:DescribeVpcEndpoints",
                "ec2:ModifyVpcEndpoint",
                "ec2:DeleteVpcEndpoints",
                "ec2:CreateTags",
                "route53:ListHostedZones"
            ],
            "Resource": "\*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:ChangeResourceRecordSets",
                "route53:ListResourceRecordSets"
            ],
            "Resource": "arn:aws:route53:::%s"
        }
    ]
}
    Copy to Clipboard Toggle word wrap
1.7.5.12.4. AWS 인프라 및 IAM 리소스를 별도로 생성
링크 복사

기본적으로 hcp create cluster aws 명령은 호스팅된 클러스터를 사용하여 클라우드 인프라를 생성하여 적용합니다. hcp create cluster aws 명령을 사용하여 클러스터를 생성하거나 적용하기 전에 수정할 수 있도록 클라우드 인프라 부분을 별도로 생성할 수 있습니다.

클라우드 인프라 부분을 별도로 생성하려면 AWS 인프라를 생성하고 AWS Identity and Access(IAM) 리소스를 생성하고 클러스터를 생성해야 합니다.

1.7.5.12.4.1. AWS 인프라 생성
링크 복사

AWS 인프라를 생성하려면 다음 명령을 입력합니다. 

hypershift create infra aws --name CLUSTER_NAME \
1 

    --aws-creds AWS_CREDENTIALS_FILE \
2 

    --base-domain BASEDOMAIN \
3 

    --infra-id INFRA_ID \
4 

    --region REGION \
5 

    --output-file OUTPUT_INFRA_FILE
6
Copy to Clipboard Toggle word wrap
1
CLUSTER_NAME 을 생성 중인 호스팅 클러스터의 이름으로 바꿉니다. 이 값은 클러스터의 Route 53 개인 호스팅 영역을 생성하는 데 사용됩니다.
2
AWS_CREDENTIALS_FILE 을 VPC, 서브넷, NAT 게이트웨이와 같은 클러스터의 인프라 리소스를 생성할 수 있는 권한이 있는 AWS 인증 정보 파일의 이름으로 교체합니다. 이 값은 작업자가 있는 게스트 클러스터의 AWS 계정에 해당해야 합니다.
3
BASEDOMAIN 을 호스팅된 클러스터 Ingress에 사용할 기본 도메인의 이름으로 교체합니다. 이 값은 레코드를 생성할 수 있는 Route 53 공용 영역에 해당해야 합니다.
4
태그를 사용하여 인프라를 식별하는 고유한 이름으로 INFRA_ID 를 바꿉니다. 이 값은 Kubernetes의 클라우드 컨트롤러 관리자와 클러스터 API 관리자가 클러스터의 인프라를 식별하는 데 사용됩니다. 일반적으로 이 값은 접미사가 추가된 클러스터 이름(CLUSTER_NAME)입니다.
5
REGION 을 클러스터 인프라를 생성할 리전으로 교체합니다.
6
OUTPUT_INFRA_FILE 을 인프라 ID를 JSON 형식으로 저장하려는 파일 이름으로 바꿉니다. 이 파일을 hcp create cluster aws 명령에 대한 입력으로 사용하여 HostedCluster 및 NodePool resouces의 필드를 채울 수 있습니다.

명령을 입력하면 다음 리소스가 생성됩니다.

  • VPC 1개
  • DHCP 옵션 1개
  • 프라이빗 서브넷 1개
  • 퍼블릭 서브넷 1개
  • 하나의 인터넷 게이트웨이
  • NAT 게이트웨이 1개
  • 작업자 노드에 대한 하나의 보안 그룹
  • 두 개의 경로 테이블: 1개의 개인 및 공용 테이블
  • 두 개의 개인 호스팅 영역: 클러스터 Ingress용 1개와 프라이빗 클러스터를 생성하는 경우 PrivateLink용 1개

이러한 모든 리소스에는 kubernetes.io/cluster/INFRA_ID=owned 태그가 포함됩니다. 여기서 INFRA_ID 는 명령에서 지정한 값입니다.

1.7.5.12.4.2. AWS IAM 리소스 생성
링크 복사

AWS IAM 리소스를 생성하려면 다음 명령을 입력합니다. 

hypershift create iam aws --infra-id INFRA_ID \
1 

    --aws-creds AWS_CREDENTIALS_FILE \
2 

    --oidc-storage-provider-s3-bucket-name OIDC_BUCKET_NAME \
3 

    --oidc-storage-provider-s3-region OIDC_BUCKET_REGION \
4 

    --region REGION \
5 

    --public-zone-id PUBLIC_ZONE_ID \
6 

    --private-zone-id PRIVATE_ZONE_ID \
7 

    --local-zone-id LOCAL_ZONE_ID \
8 

    --output-file OUTPUT_IAM_FILE
9
Copy to Clipboard Toggle word wrap
1
INFRA_ID 를 create infra aws 명령에 지정한 것과 동일한 ID로 바꿉니다. 이 값은 호스팅된 클러스터와 연결된 IAM 리소스를 식별합니다.
2
AWS_CREDENTIALS_FILE 을 역할과 같은 IAM 리소스를 생성할 수 있는 권한이 있는 AWS 인증 정보 파일의 이름으로 교체합니다. 이 파일은 인프라를 생성하기 위해 지정한 자격 증명 파일과 같을 필요는 없지만 동일한 AWS 계정에 해당되어야 합니다.
3
OIDC_BUCKET_NAME 을 OIDC 문서를 저장하는 버킷 이름으로 바꿉니다. 이 버킷은 호스팅된 컨트롤 플레인을 설치하기 위한 사전 요구 사항으로 생성되었습니다. 버킷의 이름은 이 명령으로 생성된 OIDC 공급자의 URL을 구성하는 데 사용됩니다.
4
OIDC_BUCKET_REGION 을 OIDC 버킷이 있는 리전으로 교체합니다.
5
REGION 을 클러스터 인프라가 있는 리전으로 교체합니다. 이 값은 호스팅된 클러스터에 속하는 시스템의 작업자 인스턴스 프로필을 생성하는 데 사용됩니다.
6
PUBLIC_ZONE_ID 를 게스트 클러스터의 공용 영역 ID로 바꿉니다. 이 값은 Ingress Operator에 대한 정책을 생성하는 데 사용됩니다. create infra aws 명령으로 생성된 OUTPUT_INFRA_FILE 에서 이 값을 찾을 수 있습니다.
7
PRIVATE_ZONE_ID 를 게스트 클러스터의 프라이빗 영역 ID로 바꿉니다. 이 값은 Ingress Operator에 대한 정책을 생성하는 데 사용됩니다. create infra aws 명령으로 생성된 OUTPUT_INFRA_FILE 에서 이 값을 찾을 수 있습니다.
8
LOCAL_ZONE_ID 를 프라이빗 클러스터를 생성할 때 게스트 클러스터의 로컬 영역 ID로 바꿉니다. 이 값은 PrivateLink 끝점에 대한 레코드를 관리할 수 있도록 Control Plane Operator에 대한 정책을 생성하는 데 사용됩니다. create infra aws 명령으로 생성된 OUTPUT_INFRA_FILE 에서 이 값을 찾을 수 있습니다.
9
OUTPUT_IAM_FILE 을 IAM 리소스의 ID를 JSON 형식으로 저장하려는 파일 이름으로 바꿉니다. 그런 다음 이 파일을 hcp create cluster aws 명령에 대한 입력으로 사용하여 HostedCluster 및 NodePool 리소스의 필드를 채울 수 있습니다.

명령을 입력하면 다음 리소스가 생성됩니다.

  • STS 인증을 활성화하는 데 필요한 OIDC 공급자 1개
  • Kubernetes 컨트롤러 관리자, 클러스터 API 공급자 및 레지스트리와 같이 공급자와 상호 작용하는 모든 구성 요소에 대해 별도의 7가지 역할
  • 클러스터의 모든 작업자 인스턴스에 할당된 프로필인 인스턴스 프로필 1개
1.7.5.12.4.3. 클러스터 생성
링크 복사

클러스터를 생성하려면 다음 명령을 입력합니다. 

hcp create cluster aws \
    --infra-id INFRA_ID \
1 

    --name CLUSTER_NAME \
2 

    --aws-creds AWS_CREDENTIALS \
3 

    --pull-secret PULL_SECRET_FILE \
4 

    --generate-ssh \
5 

    --node-pool-replicas 3
Copy to Clipboard Toggle word wrap
1
INFRA_ID 를 create infra aws 명령에 지정한 것과 동일한 ID로 바꿉니다. 이 값은 호스팅된 클러스터와 연결된 IAM 리소스를 식별합니다.
2
CLUSTER_NAME 을 create infra aws 명령에 지정한 것과 동일한 이름으로 바꿉니다.
3
AWS_CREDENTIALS 를 create infra aws 명령에 지정한 것과 동일한 값으로 바꿉니다.
4
PULL_SECRET_FILE 을 유효한 OpenShift Container Platform 풀 시크릿이 포함된 파일 이름으로 교체합니다.
5
--generate-ssh 플래그는 선택 사항이지만 작업자에게 SSH를 사용해야 하는 경우 포함할 수 있습니다. SSH 키는 사용자를 위해 생성되며 호스팅된 클러스터와 동일한 네임스페이스에 시크릿으로 저장됩니다.

명령에 --render 플래그를 추가하고 클러스터에 적용하기 전에 리소스를 편집할 수 있는 파일로 출력을 리디렉션할 수도 있습니다.

명령을 실행하면 다음 리소스가 클러스터에 적용됩니다.

  • 네임스페이스
  • 풀 시크릿이 있는 시크릿
  • HostedCluster
  • NodePool
  • 컨트롤 플레인 구성 요소에 대한 세 가지 AWS STS 시크릿
  • --generate-ssh 플래그를 지정한 경우 SSH 키 시크릿 1개

1.7.5.13. AWS에서 호스트된 클러스터 삭제
링크 복사

호스트 클러스터 및 관리 클러스터 리소스를 삭제하려면 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 다중 클러스터 엔진 Operator에서 관리되는 클러스터 리소스를 삭제합니다. 

    oc delete managedcluster <cluster_name>
    Copy to Clipboard Toggle word wrap

    여기서 cluster_name 은 클러스터의 이름입니다.

  2. 다음 명령을 실행하여 호스팅된 클러스터 및 해당 백엔드 리소스를 삭제합니다. 

    hcp destroy cluster aws --name <cluster_name> --infra-id <infra_id> --aws-creds <aws-credentials> --base-domain <base_domain>
    Copy to Clipboard Toggle word wrap

    필요한 경우 이름을 바꿉니다.

1.7.6. 베어 메탈에서 호스팅된 컨트롤 플레인 클러스터 구성
링크 복사

호스팅 클러스터로 작동하도록 클러스터를 구성하여 호스팅 컨트롤 플레인을 배포할 수 있습니다. 호스팅 클러스터는 컨트롤 플레인이 호스팅되는 OpenShift Container Platform 클러스터입니다. 호스팅 클러스터를 관리 클러스터라고도 합니다.

참고: 관리 클러스터는 관리 클러스터와 동일하지 않습니다. 관리형 클러스터는 hub 클러스터가 관리하는 클러스터입니다.

호스트된 컨트롤 플레인 기능은 기본적으로 활성화되어 있습니다.

다중 클러스터 엔진 Operator 2.4는 관리하는 허브 클러스터인 기본 로컬 클러스터와 허브 클러스터를 호스팅 클러스터로만 지원합니다. Red Hat Advanced Cluster Management 2.9에서는 로컬 클러스터라고도 하는 관리 허브 클러스터를 호스팅 클러스터로 사용할 수 있습니다.

호스팅 클러스터는 호스팅 클러스터에서 호스팅되 는 API 끝점 및 컨트롤 플레인이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 클러스터에는 컨트롤 플레인과 해당 데이터 플레인이 포함됩니다. 다중 클러스터 엔진 Operator 콘솔 또는 호스팅된 컨트롤 플레인 명령줄 인터페이스인 hcp 를 사용하여 호스트된 클러스터를 생성할 수 있습니다. 호스팅된 클러스터는 관리 클러스터로 자동으로 가져옵니다. 이 자동 가져오기 기능을 비활성화하려면 호스팅된 클러스터를 멀티 클러스터 엔진 Operator로 자동 가져오기 비활성화 를 참조하십시오.

중요:

  • 각 호스팅된 클러스터에는 다중 클러스터 엔진 운영자가 관리할 수 있는 고유한 이름이 있어야 합니다.
  • 호스팅된 컨트롤 플레인의 동일한 플랫폼에서 허브 클러스터 및 작업자를 실행합니다.
  • 각 호스팅된 클러스터에는 다중 클러스터 엔진 운영자가 관리할 수 있는 고유한 이름이 있어야 합니다.
  • 호스트된 클러스터는 다중 클러스터 엔진 Operator 관리 클러스터의 네임스페이스에서 생성할 수 없습니다.
  • 베어 메탈에서 호스팅되는 컨트롤 플레인을 프로비저닝하려면 에이전트 플랫폼을 사용할 수 있습니다. 에이전트 플랫폼은 중앙 인프라 관리 서비스를 사용하여 호스트된 클러스터에 작업자 노드를 추가합니다. 중앙 인프라 관리 서비스에 대한 소개는 중앙 인프라 관리 서비스 활성화를 참조하십시오.
  • 각 베어 메탈 호스트는 중앙 인프라 관리에서 제공하는 검색 이미지를 사용하여 시작해야 합니다. 수동으로 또는 Cluster-Baremetal-Operator 를 사용하여 호스트를 시작할 수 있습니다. 각 호스트가 시작되면 에이전트 프로세스를 실행하여 호스트 세부 정보를 검색하고 설치를 완료합니다. 에이전트 사용자 정의 리소스는 각 호스트를 나타냅니다.
  • 에이전트 플랫폼으로 호스팅된 클러스터를 생성하면 HyperShift가 호스팅된 컨트롤 플레인 네임스페이스에 에이전트 클러스터 API 공급자를 설치합니다.
  • 노드 풀을 확장하면 머신이 생성됩니다. Cluster API 공급자는 승인된 에이전트를 찾고 현재 검증이 사용되지 않으며, 노드 풀 사양에 지정된 요구 사항을 충족합니다. 에이전트의 상태 및 조건을 확인하여 에이전트 설치를 모니터링할 수 있습니다.
  • 노드 풀을 축소하면 에이전트가 해당 클러스터에서 바인딩되지 않습니다. 클러스터를 재사용하려면 먼저 검색 이미지를 사용하여 노드 수를 업데이트하여 클러스터를 다시 시작해야 합니다.
  • 호스트된 컨트롤 플레인에 대한 스토리지를 구성할 때 권장 etcd 사례를 고려하십시오. 대기 시간 요구 사항을 충족하는지 확인하려면 각 컨트롤 플레인 노드에서 실행되는 모든 호스팅 컨트롤 플레인 etcd 인스턴스에 빠른 스토리지 장치를 전용으로 지정합니다. LVM 스토리지를 사용하여 호스팅된 etcd pod의 로컬 스토리지 클래스를 구성할 수 있습니다. 자세한 내용은 OpenShift Container Platform 설명서의 논리 볼륨 관리자 스토리지를 사용하여 etcd 권장 사례 및 영구 스토리지를 참조하십시오.

1.7.6.1. 사전 요구 사항
링크 복사

호스팅 클러스터를 구성하려면 다음 사전 요구 사항이 있어야 합니다.

  • Kubernetes Operator 2.2 이상용 멀티 클러스터 엔진이 OpenShift Container Platform 클러스터에 설치되어 있어야 합니다. Red Hat Advanced Cluster Management를 설치할 때 다중 클러스터 엔진 Operator가 자동으로 설치됩니다. Red Hat Advanced Cluster Management 없이 OpenShift Container Platform OperatorHub의 Operator로 다중 클러스터 엔진 Operator를 설치할 수도 있습니다.

  • 다중 클러스터 엔진 Operator에는 하나 이상의 관리형 OpenShift Container Platform 클러스터가 있어야 합니다. local-cluster 는 다중 클러스터 엔진 Operator 2.2 이상에서 자동으로 가져옵니다. local-cluster 에 대한 자세한 내용은 고급 구성 을 참조하십시오. 다음 명령을 실행하여 허브 클러스터의 상태를 확인할 수 있습니다. 

    oc get managedclusters local-cluster
    Copy to Clipboard Toggle word wrap
  • 중앙 인프라 관리를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
  • 호스팅된 컨트롤 플레인 명령줄 인터페이스를 설치해야 합니다.

1.7.6.2. 베어 메탈 방화벽 및 포트 요구 사항
링크 복사

포트가 관리 클러스터, 컨트롤 플레인 및 호스팅 클러스터 간에 통신할 수 있도록 방화벽 및 포트 요구 사항을 충족하는지 확인합니다.

  • kube-apiserver 서비스는 기본적으로 포트 6443에서 실행되며 컨트롤 플레인 구성 요소 간의 통신을 위해 수신 액세스가 필요합니다.

    • NodePort 게시 전략을 사용하는 경우 kube-apiserver 서비스에 할당된 노드 포트가 노출되어 있는지 확인합니다.
    • MetalLB 로드 밸런싱을 사용하는 경우 로드 밸런서 IP 주소에 사용되는 IP 범위에 대한 수신 액세스를 허용합니다.
  • NodePort 게시 전략을 사용하는 경우 ignition-server 및 Oauth-server 설정에 방화벽 규칙을 사용합니다.

  • 호스팅된 클러스터에서 양방향 통신을 허용하도록 역방향 터널을 설정하는 konnectivity 에이전트에는 포트 6443의 클러스터 API 서버 주소에 대한 송신 액세스가 필요합니다. 이 송신 액세스를 사용하면 에이전트가 kube-apiserver 서비스에 도달할 수 있습니다.

    • 클러스터 API 서버 주소가 내부 IP 주소인 경우 워크로드 서브넷에서 포트 6443의 IP 주소로 액세스를 허용합니다.
    • 주소가 외부 IP 주소인 경우 6443 포트에서 노드에서 해당 외부 IP 주소로 송신을 허용합니다.
  • 기본 6443 포트를 변경하는 경우 해당 변경 사항을 반영하도록 규칙을 조정합니다.
  • 클러스터에서 실행되는 워크로드에 필요한 모든 포트를 열어야 합니다.
  • 방화벽 규칙, 보안 그룹 또는 기타 액세스 제어를 사용하여 필요한 소스만 액세스를 제한합니다. 필요한 경우 포트를 공개적으로 노출하지 마십시오.
  • 프로덕션 배포의 경우 로드 밸런서를 사용하여 단일 IP 주소를 통한 액세스를 단순화합니다.

1.7.6.3. 베어 메탈 인프라 요구 사항
링크 복사

에이전트 플랫폼은 인프라를 생성하지 않지만 인프라에 대한 다음과 같은 요구 사항이 있습니다.

  • 에이전트: 에이전트 는 검색 이미지로 부팅되고 OpenShift Container Platform 노드로 프로비저닝할 준비가 된 호스트를 나타냅니다.
  • DNS: API 및 수신 끝점은 라우팅할 수 있어야 합니다.

베어 메탈의 호스팅 컨트롤 플레인에 대한 추가 리소스는 다음 문서를 참조하십시오.

1.7.6.4. 베어 메탈에서 DNS 구성
링크 복사

호스팅된 클러스터의 API 서버는 NodePort 서비스로 노출됩니다. API Server에 연결할 수 있는 대상을 가리키는 api.${HOSTED_CLUSTER_NAME}.${BASEDOMAIN} 에 대한 DNS 항목이 있어야 합니다.

DNS 항목은 호스팅된 컨트롤 플레인을 실행하는 관리형 클러스터의 노드 중 하나를 가리키는 레코드만큼 단순할 수 있습니다. 이 항목은 들어오는 트래픽을 인그레스 포드로 리디렉션하기 위해 배포된 로드 밸런서를 가리킬 수도 있습니다.

  • 다음 예제 DNS 구성을 참조하십시오. 

    api.example.krnl.es.    IN A 192.168.122.20
api.example.krnl.es.    IN A 192.168.122.21
api.example.krnl.es.    IN A 192.168.122.22
api-int.example.krnl.es.    IN A 192.168.122.20
api-int.example.krnl.es.    IN A 192.168.122.21
api-int.example.krnl.es.    IN A 192.168.122.22
`*`.apps.example.krnl.es. IN A 192.168.122.23
    Copy to Clipboard Toggle word wrap

  • IPv6 네트워크에서 연결이 끊긴 환경에 대한 DNS를 구성하는 경우 다음 예제 DNS 구성을 참조하십시오. 

    api.example.krnl.es.    IN A 2620:52:0:1306::5
api.example.krnl.es.    IN A 2620:52:0:1306::6
api.example.krnl.es.    IN A 2620:52:0:1306::7
api-int.example.krnl.es.    IN A 2620:52:0:1306::5
api-int.example.krnl.es.    IN A 2620:52:0:1306::6
api-int.example.krnl.es.    IN A 2620:52:0:1306::7
`*`.apps.example.krnl.es. IN A 2620:52:0:1306::10
    Copy to Clipboard Toggle word wrap

  • 듀얼 스택 네트워크에서 연결이 끊긴 환경에 대해 DNS를 구성하는 경우 IPv4 및 IPv6 모두에 대한 DNS 항목을 포함해야 합니다. 다음 예제 DNS 구성을 참조하십시오. 

    host-record=api-int.hub-dual.dns.base.domain.name,192.168.126.10
host-record=api.hub-dual.dns.base.domain.name,192.168.126.10
address=/apps.hub-dual.dns.base.domain.name/192.168.126.11
dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,192.168.126.20
dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,192.168.126.21
dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,192.168.126.22
dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,192.168.126.25
dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,192.168.126.26

host-record=api-int.hub-dual.dns.base.domain.name,2620:52:0:1306::2
host-record=api.hub-dual.dns.base.domain.name,2620:52:0:1306::2
address=/apps.hub-dual.dns.base.domain.name/2620:52:0:1306::3
dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,[2620:52:0:1306::5]
dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,[2620:52:0:1306::6]
dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,[2620:52:0:1306::7]
dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,[2620:52:0:1306::8]
dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,[2620:52:0:1306::9]
    Copy to Clipboard Toggle word wrap

다음으로 베어 메탈에서 호스팅된 컨트롤 플레인에 대한 호스트 인벤토리를 생성합니다.

1.7.6.5. 베어 메탈에서 호스트 클러스터 생성
링크 복사

베어 메탈에서 호스팅 클러스터를 생성하거나 가져올 수 있습니다. 호스트 클러스터를 가져오는 방법은 호스팅 클러스터 가져오기를 참조하십시오.

  1. 호스팅된 컨트롤 플레인 네임스페이스를 생성하려면 다음 명령을 실행합니다. 

    oc create ns <hosted_cluster_namespace>-<hosted_cluster_name>
    Copy to Clipboard Toggle word wrap

    &lt ;hosted_cluster_namespace >를 호스팅된 클러스터 네임스페이스 이름(예: 클러스터 )으로 바꿉니다. &lt ;hosted_cluster_name> 을 호스트된 클러스터 이름으로 교체합니다.

  2. 클러스터에 대해 기본 스토리지 클래스가 구성되어 있는지 확인합니다. 그러지 않으면 보류 중인 PVC가 표시될 수 있습니다. 다음 명령을 실행합니다. 

    hcp create cluster agent \
    --name=<hosted_cluster_name> \
    1 
    
    --pull-secret=<path_to_pull_secret> \
    2 
    
    --agent-namespace=<hosted_control_plane_namespace> \
    3 
    
    --base-domain=<basedomain> \
    4 
    
    --api-server-address=api.<hosted_cluster_name>.<basedomain> \
    --etcd-storage-class=<etcd_storage_class> \
    5 
    
    --ssh-key  <path_to_ssh_public_key> \
    6 
    
    --namespace <hosted_cluster_namespace> \
    7 
    
    --control-plane-availability-policy SingleReplica \
    --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image>
    8
    Copy to Clipboard Toggle word wrap
    1
    호스팅된 클러스터의 이름을 지정합니다( 예: ).
    2
    풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
    3
    호스팅된 컨트롤 플레인 네임스페이스를 지정합니다(예: cluster -example ). oc get agent -n <hosted_control_plane_namespace> 명령을 사용하여 이 네임스페이스 에서 에이전트를 사용할 수 있는지 확인합니다.
    4
    기본 도메인을 지정합니다(예: krnl.es ).
    5
    etcd 스토리지 클래스 이름을 지정합니다(예: lvm-storageclass ).
    6
    SSH 공개 키의 경로를 지정합니다. 기본 파일 경로는 ~/.ssh/id_rsa.pub 입니다.
    7
    호스팅된 클러스터 네임스페이스를 지정합니다.
    8
    사용하려는 지원되는 OpenShift Container Platform 버전을 지정합니다(예: 4.14.0-x86_64 ). 연결이 끊긴 환경을 사용하는 경우 < ocp_release_image >를 다이제스트 이미지로 교체합니다. OpenShift Container Platform 릴리스 이미지 다이제스트를 추출하려면 OpenShift Container Platform 릴리스 이미지 다이제스트 추출을 참조하십시오.

  3. 잠시 후 다음 명령을 입력하여 호스팅된 컨트롤 플레인 pod가 실행 중인지 확인합니다. 

    oc -n <hosted_control_plane_namespace> get pods
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME                                             READY   STATUS    RESTARTS   AGE
capi-provider-7dcf5fc4c4-nr9sq                   1/1     Running   0          4m32s
catalog-operator-6cd867cc7-phb2q                 2/2     Running   0          2m50s
certified-operators-catalog-884c756c4-zdt64      1/1     Running   0          2m51s
cluster-api-f75d86f8c-56wfz                      1/1     Running   0          4m32s
    Copy to Clipboard Toggle word wrap
1.7.6.5.1. 콘솔을 사용하여 베어 메탈에서 호스트 클러스터 생성
링크 복사
  1. OpenShift Container Platform 웹 콘솔을 열고 관리자 인증 정보를 입력하여 로그인합니다. 콘솔을 여는 방법은 OpenShift Container Platform 설명서 의 웹 콘솔 액세스를 참조하십시오.
  2. 콘솔 헤더에서 모든 클러스터 가 선택되어 있는지 확인합니다.
  3. Infrastructure > Clusters를 클릭합니다.

  4. Create cluster > Host inventory > Hosted control Plane 을 클릭합니다.

    클러스터 생성 페이지가 표시됩니다.

  5. 클러스터 생성 페이지에서 프롬프트에 따라 클러스터, 노드 풀, 네트워킹 및 자동화에 대한 세부 정보를 입력합니다.

    참고: 클러스터에 대한 세부 정보를 입력하면 다음 팁이 유용할 수 있습니다.

    • 사전 정의된 값을 사용하여 콘솔에서 필드를 자동으로 채우려면 호스트 인벤토리 인증 정보를 생성할 수 있습니다. 자세한 내용은 온-프레미스 환경에 대한 인증 정보 만들기 를 참조하십시오.
    • 클러스터 세부 정보 페이지에서 풀 시크릿은 OpenShift Container Platform 리소스에 액세스하는 데 사용하는 OpenShift Container Platform 풀 시크릿입니다. 호스트 인벤토리 인증 정보를 선택한 경우 가져오기 보안이 자동으로 채워집니다.
    • 노드 풀 페이지에서 네임스페이스에는 노드 풀의 호스트가 포함되어 있습니다. 콘솔을 사용하여 호스트 인벤토리를 생성한 경우 콘솔은 전용 네임스페이스를 생성합니다.
    • 네트워킹 페이지에서 API 서버 게시 전략을 선택합니다. 호스팅된 클러스터의 API 서버는 기존 로드 밸런서를 사용하거나 NodePort 유형의 서비스로 노출될 수 있습니다. API 서버에 연결할 수 있는 대상을 가리키는 api.<hosted_cluster_name>.<basedomain > 설정에 대한 DNS 항목이 있어야 합니다. 이 항목은 관리 클러스터의 노드 중 하나를 가리키는 레코드이거나 수신 트래픽을 Ingress pod로 리디렉션하는 로드 밸런서를 가리키는 레코드일 수 있습니다.

  6. 항목을 검토하고 생성 을 클릭합니다.

    호스팅된 클러스터 보기가 표시됩니다.

  7. Hosted 클러스터 보기에서 호스팅된 클러스터의 배포를 모니터링합니다. 호스팅된 클러스터에 대한 정보가 표시되지 않는 경우 모든 클러스터가 선택되어 있는지 확인하고 클러스터 이름을 클릭합니다.
  8. 컨트롤 플레인 구성 요소가 준비될 때까지 기다립니다. 이 프로세스는 몇 분 정도 걸릴 수 있습니다.
  9. 노드 풀 상태를 보려면 NodePool 섹션으로 스크롤합니다. 노드를 설치하는 프로세스에는 약 10분이 걸립니다. 노드를 클릭하여 노드가 호스팅된 클러스터에 참여하고 있는지 확인할 수도 있습니다.

미러 레지스트리를 사용하여 hcp create cluster 명령에 --image-content-sources 플래그를 지정하여 베어 메탈에 호스팅 클러스터를 생성할 수 있습니다. 다음 단계를 완료합니다.

  1. YAML 파일을 생성하여 ICSP(Image Content Source Policies)를 정의합니다. 다음 예제를 참조하십시오. 

    - mirrors:
  - brew.registry.redhat.io
  source: registry.redhat.io
- mirrors:
  - brew.registry.redhat.io
  source: registry.stage.redhat.io
- mirrors:
  - brew.registry.redhat.io
  source: registry-proxy.engineering.redhat.com
    Copy to Clipboard Toggle word wrap
  2. 파일을 icsp.yaml 로 저장합니다. 이 파일에는 미러 레지스트리가 포함되어 있습니다.

  3. 미러 레지스트리를 사용하여 호스팅된 클러스터를 생성하려면 다음 명령을 실행합니다. 

    hcp create cluster agent \
    --name=<hosted_cluster_name> \
    1 
    
    --pull-secret=<path_to_pull_secret> \
    2 
    
    --agent-namespace=<hosted_control_plane_namespace> \
    3 
    
    --base-domain=<basedomain> \
    4 
    
    --api-server-address=api.<hosted_cluster_name>.<basedomain> \
    --image-content-sources icsp.yaml  \
    5 
    
    --ssh-key  <path_to_ssh_key> \
    6 
    
    --namespace <hosted_cluster_namespace> \
    7 
    
    --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image>
    8
    Copy to Clipboard Toggle word wrap
    1
    호스팅된 클러스터의 이름을 지정합니다( 예: ).
    2
    풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
    3
    호스팅된 컨트롤 플레인 네임스페이스를 지정합니다(예: cluster -example ). oc get agent -n <hosted-control-plane-namespace> 명령을 사용하여 이 네임스페이스 에서 에이전트를 사용할 수 있는지 확인합니다.
    4
    기본 도메인을 지정합니다(예: krnl.es ).
    5
    ICSP 및 미러 레지스트리를 정의하는 icsp.yaml 파일을 지정합니다.
    6
    SSH 공개 키의 경로를 지정합니다. 기본 파일 경로는 ~/.ssh/id_rsa.pub 입니다.
    7
    호스팅된 클러스터 네임스페이스를 지정합니다.
    8
    사용하려는 지원되는 OpenShift Container Platform 버전을 지정합니다(예: 4.14.0-x86_64 ). 연결이 끊긴 환경을 사용하는 경우 < ocp_release_image >를 다이제스트 이미지로 교체합니다. OpenShift Container Platform 릴리스 이미지 다이제스트를 추출하려면 OpenShift Container Platform 릴리스 이미지 다이제스트 추출을 참조하십시오.
1.7.6.5.3. 추가 리소스
링크 복사

1.7.6.6. 호스트된 클러스터 생성 확인
링크 복사

배포 프로세스가 완료되면 호스트 클러스터가 성공적으로 생성되었는지 확인할 수 있습니다. 호스팅된 클러스터를 생성한 후 몇 분 후에 다음 단계를 수행합니다.

  1. extract 명령을 입력하여 새 호스팅 클러스터에 대한 kubeconfig를 가져옵니다. 

    oc extract -n kni21 secret/kni21-admin-kubeconfig --to=- > kubeconfig-kni21
# kubeconfig
    Copy to Clipboard Toggle word wrap

  2. kubeconfig를 사용하여 호스팅된 클러스터의 클러스터 Operator를 확인합니다. 다음 명령을 실행합니다. 

    oc get co --kubeconfig=kubeconfig-kni21
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
console                                    4.10.26   True        False         False      2m38s
csi-snapshot-controller                    4.10.26   True        False         False      4m3s
dns                                        4.10.26   True        False         False      2m52s
image-registry                             4.10.26   True        False         False      2m8s
ingress                                    4.10.26   True        False         False      22m
kube-apiserver                             4.10.26   True        False         False      23m
kube-controller-manager                    4.10.26   True        False         False      23m
kube-scheduler                             4.10.26   True        False         False      23m
kube-storage-version-migrator              4.10.26   True        False         False      4m52s
monitoring                                 4.10.26   True        False         False      69s
network                                    4.10.26   True        False         False      4m3s
node-tuning                                4.10.26   True        False         False      2m22s
openshift-apiserver                        4.10.26   True        False         False      23m
openshift-controller-manager               4.10.26   True        False         False      23m
openshift-samples                          4.10.26   True        False         False      2m15s
operator-lifecycle-manager                 4.10.26   True        False         False      22m
operator-lifecycle-manager-catalog         4.10.26   True        False         False      23m
operator-lifecycle-manager-packageserver   4.10.26   True        False         False      23m
service-ca                                 4.10.26   True        False         False      4m41s
storage                                    4.10.26   True        False         False      4m43s
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 입력하여 호스팅 클러스터에서 실행 중인 Pod를 볼 수도 있습니다. 

    oc get pods -A --kubeconfig=kubeconfig-kni21
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAMESPACE                                          NAME                                                      READY   STATUS             RESTARTS        AGE
kube-system                                        konnectivity-agent-khlqv                                  0/1     Running            0               3m52s
kube-system                                        konnectivity-agent-nrbvw                                  0/1     Running            0               4m24s
kube-system                                        konnectivity-agent-s5p7g                                  0/1     Running            0               4m14s
kube-system                                        kube-apiserver-proxy-asus3-vm1.kni.schmaustech.com        1/1     Running            0               5m56s
kube-system                                        kube-apiserver-proxy-asus3-vm2.kni.schmaustech.com        1/1     Running            0               6m37s
kube-system                                        kube-apiserver-proxy-asus3-vm3.kni.schmaustech.com        1/1     Running            0               6m17s
openshift-cluster-node-tuning-operator             cluster-node-tuning-operator-798fcd89dc-9cf2k             1/1     Running            0               20m
openshift-cluster-node-tuning-operator             tuned-dhw5p                                               1/1     Running            0               109s
openshift-cluster-node-tuning-operator             tuned-dlp8f                                               1/1     Running            0               110s
openshift-cluster-node-tuning-operator             tuned-l569k                                               1/1     Running            0               109s
openshift-cluster-samples-operator                 cluster-samples-operator-6b5bcb9dff-kpnbc                 2/2     Running            0               20m
openshift-cluster-storage-operator                 cluster-storage-operator-5f784969f5-vwzgz                 1/1     Running            1 (113s ago)    20m
openshift-cluster-storage-operator                 csi-snapshot-controller-6b7687b7d9-7nrfw                  1/1     Running            0               3m8s
openshift-cluster-storage-operator                 csi-snapshot-controller-6b7687b7d9-csksg                  1/1     Running            0               3m9s
openshift-cluster-storage-operator                 csi-snapshot-controller-operator-7f4d9fc5b8-hkvrk         1/1     Running            0               20m
openshift-cluster-storage-operator                 csi-snapshot-webhook-6759b5dc8b-7qltn                     1/1     Running            0               3m12s
openshift-cluster-storage-operator                 csi-snapshot-webhook-6759b5dc8b-f8bqk                     1/1     Running            0               3m12s
openshift-console-operator                         console-operator-8675b58c4c-flc5p                         1/1     Running            1 (96s ago)     20m
openshift-console                                  console-5cbf6c7969-6gk6z                                  1/1     Running            0               119s
openshift-console                                  downloads-7bcd756565-6wj5j                                1/1     Running            0               4m3s
openshift-dns-operator                             dns-operator-77d755cd8c-xjfbn                             2/2     Running            0               21m
openshift-dns                                      dns-default-jwjkz                                         2/2     Running            0               113s
openshift-dns                                      dns-default-kfqnh                                         2/2     Running            0               113s
openshift-dns                                      dns-default-xlqsm                                         2/2     Running            0               113s
openshift-dns                                      node-resolver-jzxnd                                       1/1     Running            0               110s
openshift-dns                                      node-resolver-xqdr5                                       1/1     Running            0               110s
openshift-dns                                      node-resolver-zl6h4                                       1/1     Running            0               110s
openshift-image-registry                           cluster-image-registry-operator-64fcfdbf5-r7d5t           1/1     Running            0               20m
openshift-image-registry                           image-registry-7fdfd99d68-t9pq9                           1/1     Running            0               53s
openshift-image-registry                           node-ca-hkfnr                                             1/1     Running            0               56s
openshift-image-registry                           node-ca-vlsdl                                             1/1     Running            0               56s
openshift-image-registry                           node-ca-xqnsw                                             1/1     Running            0               56s
openshift-ingress-canary                           ingress-canary-86z6r                                      1/1     Running            0               4m13s
openshift-ingress-canary                           ingress-canary-8jhxk                                      1/1     Running            0               3m52s
openshift-ingress-canary                           ingress-canary-cv45h                                      1/1     Running            0               4m24s
openshift-ingress                                  router-default-6bb8944f66-z2lxr                           1/1     Running            0               20m
openshift-kube-storage-version-migrator-operator   kube-storage-version-migrator-operator-56b57b4844-p9zgp   1/1     Running            1 (2m16s ago)   20m
openshift-kube-storage-version-migrator            migrator-58bb4d89d5-5sl9w                                 1/1     Running            0               3m30s
openshift-monitoring                               alertmanager-main-0                                       6/6     Running            0               100s
openshift-monitoring                               cluster-monitoring-operator-5bc5885cd4-dwbc4              2/2     Running            0               20m
openshift-monitoring                               grafana-78f798868c-wd84p                                  3/3     Running            0               94s
openshift-monitoring                               kube-state-metrics-58b8f97f6c-6kp4v                       3/3     Running            0               104s
openshift-monitoring                               node-exporter-ll7cp                                       2/2     Running            0               103s
openshift-monitoring                               node-exporter-tgsqg                                       2/2     Running            0               103s
openshift-monitoring                               node-exporter-z99gr                                       2/2     Running            0               103s
openshift-monitoring                               openshift-state-metrics-677b9fb74f-qqp6g                  3/3     Running            0               104s
openshift-monitoring                               prometheus-adapter-f69fff5f9-7tdn9                        0/1     Running            0               17s
openshift-monitoring                               prometheus-k8s-0                                          6/6     Running            0               93s
openshift-monitoring                               prometheus-operator-6b9d4fd9bd-tqfcx                      2/2     Running            0               2m2s
openshift-monitoring                               telemeter-client-74d599658c-wqw5j                         3/3     Running            0               101s
openshift-monitoring                               thanos-querier-64c8757854-z4lll                           6/6     Running            0               98s
openshift-multus                                   multus-additional-cni-plugins-cqst9                       1/1     Running            0               6m14s
openshift-multus                                   multus-additional-cni-plugins-dbmkj                       1/1     Running            0               5m56s
openshift-multus                                   multus-additional-cni-plugins-kcwl9                       1/1     Running            0               6m14s
openshift-multus                                   multus-admission-controller-22cmb                         2/2     Running            0               3m52s
openshift-multus                                   multus-admission-controller-256tn                         2/2     Running            0               4m13s
openshift-multus                                   multus-admission-controller-mz9jm                         2/2     Running            0               4m24s
openshift-multus                                   multus-bxgvr                                              1/1     Running            0               6m14s
openshift-multus                                   multus-dmkdc                                              1/1     Running            0               6m14s
openshift-multus                                   multus-gqw2f                                              1/1     Running            0               5m56s
openshift-multus                                   network-metrics-daemon-6cx4x                              2/2     Running            0               5m56s
openshift-multus                                   network-metrics-daemon-gz4jp                              2/2     Running            0               6m13s
openshift-multus                                   network-metrics-daemon-jq9j4                              2/2     Running            0               6m13s
openshift-network-diagnostics                      network-check-source-8497dc8f86-cn4nm                     1/1     Running            0               5m59s
openshift-network-diagnostics                      network-check-target-d8db9                                1/1     Running            0               5m58s
openshift-network-diagnostics                      network-check-target-jdbv8                                1/1     Running            0               5m58s
openshift-network-diagnostics                      network-check-target-zzmdv                                1/1     Running            0               5m55s
openshift-network-operator                         network-operator-f5b48cd67-x5dcz                          1/1     Running            0               21m
openshift-sdn                                      sdn-452r2                                                 2/2     Running            0               5m56s
openshift-sdn                                      sdn-68g69                                                 2/2     Running            0               6m
openshift-sdn                                      sdn-controller-4v5mv                                      2/2     Running            0               5m56s
openshift-sdn                                      sdn-controller-crscc                                      2/2     Running            0               6m1s
openshift-sdn                                      sdn-controller-fxtn9                                      2/2     Running            0               6m1s
openshift-sdn                                      sdn-n5jm5                                                 2/2     Running            0               6m
openshift-service-ca-operator                      service-ca-operator-5bf7f9d958-vnqcg                      1/1     Running            1 (2m ago)      20m
openshift-service-ca                               service-ca-6c54d7944b-v5mrw                               1/1     Running            0               3m8s
    Copy to Clipboard Toggle word wrap

1.7.6.7. 호스트 클러스터의 NodePool 오브젝트 스케일링
링크 복사

NodePool 오브젝트를 스케일링하여 호스팅 클러스터에 노드를 추가합니다.

  1. NodePool 오브젝트를 두 개의 노드로 확장합니다. 

    oc -n <cluster-namespace> scale nodepool <nodepool-name> --replicas 2
    Copy to Clipboard Toggle word wrap

    Cluster API 에이전트 공급자는 호스트 클러스터에 할당된 두 개의 에이전트를 임의로 선택합니다. 이러한 에이전트는 다른 상태를 통과하고 마지막으로 호스팅된 클러스터에 OpenShift Container Platform 노드로 참여합니다. 에이전트는 다음 순서로 상태를 통과합니다.

    • 바인딩
    • 검색
    • insufficient
    • 설치
    • installing-in-progress
    • added-to-existing-cluster

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

    oc -n <hosted-control-plane-namespace> get agent
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME                                   CLUSTER         APPROVED   ROLE          STAGE
4dac1ab2-7dd5-4894-a220-6a3473b67ee6   hypercluster1   true       auto-assign
d9198891-39f4-4930-a679-65fb142b108b                   true       auto-assign
da503cf1-a347-44f2-875c-4960ddb04091   hypercluster1   true       auto-assign
    Copy to Clipboard Toggle word wrap

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

    oc -n <hosted-control-plane-namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound
BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
    Copy to Clipboard Toggle word wrap

  4. 에이전트가 add-to-existing-cluster 상태에 도달한 후 다음 명령을 입력하여 OpenShift Container Platform 노드를 볼 수 있는지 확인합니다. 

    oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME           STATUS   ROLES    AGE     VERSION
ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f
ocp-worker-2   Ready    worker   6m3s    v1.24.0+3882f8f
    Copy to Clipboard Toggle word wrap

    클러스터 Operator는 노드에 워크로드를 추가하여 조정하기 시작합니다.

  5. 다음 명령을 입력하여 NodePool 오브젝트를 확장할 때 두 개의 머신이 생성되었는지 확인합니다. 

    oc -n <hosted-control-plane-namespace> get machines
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.12z
hypercluster1-c96b6f675-tl42p   hypercluster1-b2qhl   ocp-worker-2   agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6   Running   15m   4.12z
    Copy to Clipboard Toggle word wrap

    clusterversion 조정 프로세스는 결국 Ingress 및 Console 클러스터 Operator만 누락된 지점에 도달합니다.

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

    oc --kubeconfig <hosted-cluster-name>.kubeconfig get clusterversion,co
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version             False       True          40m     Unable to apply 4.12z: the cluster operator console has not yet successfully rolled out

NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.12z    False       False         False      11m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.hypercluster1.domain.com): Get "https://console-openshift-console.apps.hypercluster1.domain.com": dial tcp 10.19.3.29:443: connect: connection refused
clusteroperator.config.openshift.io/csi-snapshot-controller                    4.12z    True        False         False      10m
clusteroperator.config.openshift.io/dns                                        4.12z    True        False         False      9m16s
clusteroperator.config.openshift.io/image-registry                             4.12z    True        False         False      9m5s
clusteroperator.config.openshift.io/ingress                                    4.12z    True        False         True       39m     The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)
clusteroperator.config.openshift.io/insights                                   4.12z    True        False         False      11m
clusteroperator.config.openshift.io/kube-apiserver                             4.12z    True        False         False      40m
clusteroperator.config.openshift.io/kube-controller-manager                    4.12z    True        False         False      40m
clusteroperator.config.openshift.io/kube-scheduler                             4.12z    True        False         False      40m
clusteroperator.config.openshift.io/kube-storage-version-migrator              4.12z    True        False         False      10m
clusteroperator.config.openshift.io/monitoring                                 4.12z    True        False         False      7m38s
clusteroperator.config.openshift.io/network                                    4.12z    True        False         False      11m
clusteroperator.config.openshift.io/openshift-apiserver                        4.12z    True        False         False      40m
clusteroperator.config.openshift.io/openshift-controller-manager               4.12z    True        False         False      40m
clusteroperator.config.openshift.io/openshift-samples                          4.12z    True        False         False      8m54s
clusteroperator.config.openshift.io/operator-lifecycle-manager                 4.12z    True        False         False      40m
clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog         4.12z    True        False         False      40m
clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver   4.12z    True        False         False      40m
clusteroperator.config.openshift.io/service-ca                                 4.12z    True        False         False      11m
clusteroperator.config.openshift.io/storage                                    4.12z    True        False         False      11m
    Copy to Clipboard Toggle word wrap
1.7.6.7.1. 노드 풀 추가
링크 복사

이름, 복제본 수 및 에이전트 라벨 선택기와 같은 추가 정보를 지정하여 호스팅된 클러스터에 대한 노드 풀을 생성할 수 있습니다.

  1. 노드 풀을 생성하려면 다음 정보를 입력합니다. 이 예에서 노드 풀은 "size" : "medium" 라벨이 있는 에이전트를 사용합니다. 

    export NODEPOOL_NAME=${CLUSTER_NAME}-extra-cpu
export WORKER_COUNT="2"

hcp create nodepool agent \
  --cluster-name $CLUSTER_NAME \
  --name $NODEPOOL_NAME \
  --node-count $WORKER_COUNT \
  --agentLabelSelector '{"matchLabels": {"size": "medium"}}'
    Copy to Clipboard Toggle word wrap

  2. cluster 네임스페이스에 nodepool 리소스를 나열하여 노드 풀의 상태를 확인합니다. 

    oc get nodepools --namespace clusters
    Copy to Clipboard Toggle word wrap

  3. 잠시 후 다음 명령을 입력하여 노드 풀의 상태를 확인할 수 있습니다. 

    oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 입력하여 노드 풀이 예상되는 상태에 있는지 확인합니다. 

    oc get nodepools --namespace clusters
    Copy to Clipboard Toggle word wrap

1.7.6.8. 베어 메탈의 호스트 클러스터에서 수신 처리
링크 복사

모든 OpenShift Container Platform 클러스터에는 기본 애플리케이션 Ingress 컨트롤러에는 연결된 외부 DNS 레코드가 있어야 합니다. 예를 들어 기본 도메인 krnl.es 를 사용하여 example 이라는 HyperShift 클러스터를 생성하는 경우 와일드카드 도메인 *.apps.example.krnl.es 를 라우팅할 수 있을 것으로 예상할 수 있습니다.

*.apps 에 대한 로드 밸런서 및 와일드카드 DNS 레코드를 설정할 수 있습니다. 이 프로세스에서는 MetalLB를 배포하고, 인그레스 배포로 라우팅하는 새 로드 밸런서 서비스를 구성하고, 로드 밸런서 IP 주소에 와일드카드 DNS 항목을 할당해야 합니다.

  1. LoadBalancer 유형의 서비스를 생성할 때 MetalLB에서 서비스에 외부 IP 주소를 추가하도록 MetalLB를 설정합니다.

    1. MetalLB Operator의 구성이 포함된 YAML 파일을 생성합니다. 

      apiVersion: v1
kind: Namespace
metadata:
  name: metallb
  labels:
    openshift.io/cluster-monitoring: "true"
  annotations:
    workload.openshift.io/allowed: management
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: metallb-operator-operatorgroup
  namespace: metallb
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: metallb-operator
  namespace: metallb
spec:
  channel: "stable"
  name: metallb-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
      Copy to Clipboard Toggle word wrap
    2. 파일을 metallb-operator-config.yaml 로 저장합니다.
    3. 다음 명령을 입력하여 구성을 적용합니다. 
    oc apply -f metallb-operator-config.yaml
    Copy to Clipboard Toggle word wrap

  2. Operator가 실행되면 MetalLB 인스턴스를 생성합니다.

    1. MetalLB 인스턴스의 구성이 포함된 YAML 파일을 생성합니다. 

      apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb
      Copy to Clipboard Toggle word wrap
    2. 파일을 metallb-instance-config.yaml 로 저장합니다.
    3. 다음 명령을 입력하여 MetalLB 인스턴스를 생성합니다. 
    oc apply -f metallb-instance-config.yaml
    Copy to Clipboard Toggle word wrap

  3. 다음 두 리소스를 생성하여 MetalLB Operator를 구성합니다.

    • 단일 IP 주소가 있는 IPAddressPool 리소스. 이 IP 주소는 클러스터 노드에서 사용하는 네트워크와 동일한 서브넷에 있어야 합니다.

    • 로드 밸런서 IP 주소를 IPAddressPool 리소스에서 BGP 프로토콜을 통해 제공하는 BGPAdvertisement 리소스입니다.

      중요: 환경 주소와 일치하도록 INGRESS_IP 환경 변수를 변경합니다.

      1. 구성을 포함할 YAML 파일을 생성합니다. 

        export INGRESS_IP=192.168.122.23

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: ingress-public-ip
  namespace: metallb
spec:
  protocol: layer2
  autoAssign: false
  addresses:
    - ${INGRESS_IP}-${INGRESS_IP}
---
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: ingress-public-ip
  namespace: metallb
spec:
  ipAddressPools:
    - ingress-public-ip
        Copy to Clipboard Toggle word wrap
      2. 파일을 ipaddresspool-bgpadvertisement-config.yaml 로 저장합니다.
      3. 다음 명령을 입력하여 리소스를 생성합니다. 
    oc apply -f ipaddresspool-bgpadvertisement-config.yaml
    Copy to Clipboard Toggle word wrap

  4. 다음 단계에 따라 MetalLB를 통해 OpenShift Container Platform 라우터를 노출합니다.

    1. YAML 파일을 생성하여 수신 트래픽을 수신 배포로 라우팅하는 LoadBalancer 서비스를 설정합니다. 

      kind: Service
apiVersion: v1
metadata:
  annotations:
    metallb.universe.tf/address-pool: ingress-public-ip
  name: metallb-ingress
  namespace: openshift-ingress
spec:
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
    - name: https
      protocol: TCP
      port: 443
      targetPort: 443
  selector:
    ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
  type: LoadBalancer
      Copy to Clipboard Toggle word wrap
    2. 파일을 metallb-loadbalancer-service.yaml 로 저장합니다.

    3. 다음 명령을 입력하여 YAML 파일의 구성을 적용합니다. 

      oc apply -f metallb-loadbalancer-service.yaml
      Copy to Clipboard Toggle word wrap

    4. 다음 명령을 입력하여 OpenShift Container Platform 콘솔에 연결합니다. 

      curl -kI https://console-openshift-console.apps.example.krnl.es

HTTP/1.1 200 OK
      Copy to Clipboard Toggle word wrap

    5. clusterversion 및 clusteroperator 값을 확인하여 모든 항목이 실행 중인지 확인합니다. 다음 명령을 실행합니다. 

      oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get clusterversion,co
      Copy to Clipboard Toggle word wrap

      다음 예제 출력을 참조하십시오. 

    NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.12z    True        False         3m32s   Cluster version is 4.12z

NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.12z    True        False         False      3m50s
clusteroperator.config.openshift.io/csi-snapshot-controller                    4.12z    True        False         False      25m
clusteroperator.config.openshift.io/dns                                        4.12z    True        False         False      23m
clusteroperator.config.openshift.io/image-registry                             4.12z    True        False         False      23m
clusteroperator.config.openshift.io/ingress                                    4.12z    True        False         False      53m
clusteroperator.config.openshift.io/insights                                   4.12z    True        False         False      25m
clusteroperator.config.openshift.io/kube-apiserver                             4.12z    True        False         False      54m
clusteroperator.config.openshift.io/kube-controller-manager                    4.12z    True        False         False      54m
clusteroperator.config.openshift.io/kube-scheduler                             4.12z    True        False         False      54m
clusteroperator.config.openshift.io/kube-storage-version-migrator              4.12z    True        False         False      25m
clusteroperator.config.openshift.io/monitoring                                 4.12z    True        False         False      21m
clusteroperator.config.openshift.io/network                                    4.12z    True        False         False      25m
clusteroperator.config.openshift.io/openshift-apiserver                        4.12z    True        False         False      54m
clusteroperator.config.openshift.io/openshift-controller-manager               4.12z    True        False         False      54m
clusteroperator.config.openshift.io/openshift-samples                          4.12z    True        False         False      23m
clusteroperator.config.openshift.io/operator-lifecycle-manager                 4.12z    True        False         False      54m
clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog         4.12z    True        False         False      54m
clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver   4.12z    True        False         False      54m
clusteroperator.config.openshift.io/service-ca                                 4.12z    True        False         False      25m
clusteroperator.config.openshift.io/storage                                    4.12z    True        False         False      25m
    Copy to Clipboard Toggle word wrap
1.7.6.8.1. 추가 리소스
링크 복사

1.7.6.9. 호스트 클러스터의 노드 자동 확장 활성화
링크 복사

호스팅된 클러스터에 용량이 더 필요하고 예비 에이전트를 사용할 수 있는 경우 자동 확장을 활성화하여 새 작업자 노드를 설치할 수 있습니다.

  1. 자동 확장을 활성화하려면 다음 명령을 입력합니다. 이 경우 최소 노드 수는 2이고 최대값은 5입니다. 추가할 수 있는 최대 노드 수는 플랫폼에 바인딩될 수 있습니다. 예를 들어 에이전트 플랫폼을 사용하는 경우 사용 가능한 에이전트 수에 따라 최대 노드 수가 바인딩됩니다. 

    oc -n ${CLUSTERS_NAMESPACE} patch nodepool ${HOSTED_CLUSTER_NAME} --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'
    Copy to Clipboard Toggle word wrap

    추가 용량이 필요하지 않고 10분을 전달하면 작업자 노드가 제거됩니다. 에이전트 플랫폼에서 에이전트는 해제되어 재사용될 수 있습니다.

  2. 새 노드가 필요한 워크로드를 생성합니다.

    1. 다음 예와 같이 워크로드 구성이 포함된 YAML 파일을 생성합니다. 

      apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: reversewords
  name: reversewords
  namespace: default
spec:
  replicas: 40
  selector:
    matchLabels:
      app: reversewords
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: reversewords
  spec:
    containers:
    - image: quay.io/mavazque/reversewords:latest
      name: reversewords
      resources:
        requests:
          memory: 2Gi
status: {}
      Copy to Clipboard Toggle word wrap
    2. 파일을 workload-config.yaml 로 저장합니다.
    3. 다음 명령을 입력하여 YAML을 적용합니다. 
    oc apply -f workload-config.yaml
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 입력하여 노드를 확인하는 경우 새 노드가 출력에 표시됩니다. 이 예에서는 ocp-worker-0 이 클러스터에 추가됩니다. 

    oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME           STATUS   ROLES    AGE   VERSION
ocp-worker-0   Ready    worker   35s   v1.24.0+3882f8f
ocp-worker-1   Ready    worker   40m   v1.24.0+3882f8f
ocp-worker-2   Ready    worker   41m   v1.24.0+3882f8f
    Copy to Clipboard Toggle word wrap

  4. 노드를 제거하려면 다음 명령을 입력하여 워크로드를 삭제합니다. 

    oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig -n default delete deployment reversewords
    Copy to Clipboard Toggle word wrap

  5. 10분 정도 기다린 다음 다음 명령을 입력하여 노드가 제거되었는지 확인합니다. 

    oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME           STATUS   ROLES    AGE   VERSION
ocp-worker-1   Ready    worker   51m   v1.24.0+3882f8f
ocp-worker-2   Ready    worker   52m   v1.24.0+3882f8f
    Copy to Clipboard Toggle word wrap
1.7.6.9.1. 호스트 클러스터의 노드 자동 확장 비활성화
링크 복사

노드 자동 확장을 비활성화하려면 다음 명령을 입력합니다. 

oc -n ${CLUSTERS_NAMESPACE} patch nodepool ${HOSTED_CLUSTER_NAME} --type=json -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": $SOME_INT_VALUE_FOR_SCALING_TO}]'
Copy to Clipboard Toggle word wrap

이 명령은 YAML 파일에서 "spec.autoScaling" 을 제거하고 "spec.replicas" 를 추가하고 지정한 값에 "spec.replicas" 를 설정합니다.

1.7.6.10. 베어 메탈에서 호스트 클러스터 삭제
링크 복사

콘솔을 사용하여 베어 메탈 호스팅 클러스터를 제거할 수 있습니다. 베어 메탈에서 호스트된 클러스터를 삭제하려면 다음 단계를 완료합니다.

  1. 콘솔에서 Infrastructure > Clusters 로 이동합니다.
  2. 클러스터 페이지에서 삭제할 클러스터를 선택합니다.
  3. 작업 메뉴에서 클러스터 삭제 를 선택하여 클러스터를 제거합니다.
1.7.6.10.1. 명령줄을 사용하여 베어 메탈에서 호스트 클러스터 제거
링크 복사

호스트 클러스터 및 관리 클러스터 리소스를 삭제하려면 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 다중 클러스터 엔진 Operator에서 관리되는 클러스터 리소스를 삭제합니다. 

    oc delete managedcluster <cluster_name>
    Copy to Clipboard Toggle word wrap

    여기서 cluster_name 은 클러스터의 이름입니다.

  2. 다음 명령을 실행하여 호스팅된 클러스터 및 해당 백엔드 리소스를 삭제합니다. 

    hcp destroy cluster agent --name <cluster_name>
    Copy to Clipboard Toggle word wrap

    필요한 경우 이름을 바꿉니다.

기술 프리뷰: IBM Power (ppc64le) 컴퓨팅 노드의 경우 64비트 x86 베어 메탈에서 호스팅 클러스터를 구성하는 것은 제한적으로 지원됩니다.

호스팅 클러스터로 작동하도록 클러스터를 구성하여 호스팅 컨트롤 플레인을 배포할 수 있습니다. 호스팅 클러스터는 컨트롤 플레인이 호스팅되는 OpenShift Container Platform 클러스터입니다. 호스팅 클러스터를 관리 클러스터라고도 합니다.

참고: 관리 클러스터는 관리 클러스터가 아닙니다. 관리형 클러스터는 hub 클러스터가 관리하는 클러스터입니다.

다중 클러스터 엔진 Operator 2.4는 관리하는 허브 클러스터인 기본 로컬 클러스터와 허브 클러스터를 호스팅 클러스터로만 지원합니다.

중요:

  • 베어 메탈에서 호스팅되는 컨트롤 플레인을 프로비저닝하려면 에이전트 플랫폼을 사용할 수 있습니다. 에이전트 플랫폼은 중앙 인프라 관리 서비스를 사용하여 호스트된 클러스터에 작업자 노드를 추가합니다. 중앙 인프라 관리 서비스에 대한 도입은 호스트 인벤토리 생성을 참조하십시오.
  • 각 IBM Power 시스템 호스트는 중앙 인프라 관리에서 제공하는 검색 이미지를 사용하여 시작해야 합니다. 각 호스트가 시작되면 에이전트 프로세스를 실행하여 호스트의 세부 정보를 검색하고 설치를 완료합니다. 에이전트 사용자 정의 리소스는 각 호스트를 나타냅니다.
  • 에이전트 플랫폼으로 호스팅된 클러스터를 생성하면 HyperShift가 호스팅된 컨트롤 플레인 네임스페이스에 에이전트 클러스터 API 공급자를 설치합니다.
  • 노드 풀을 확장하면 머신이 생성됩니다. Cluster API 공급자는 승인된 에이전트를 찾고 현재 검증이 사용되지 않으며, 노드 풀 사양에 지정된 요구 사항을 충족합니다. 에이전트의 상태 및 조건을 확인하여 에이전트 설치를 모니터링할 수 있습니다.
  • 노드 풀을 축소하면 에이전트가 해당 클러스터에서 바인딩되지 않습니다. 클러스터를 재사용하려면 먼저 검색 이미지를 사용하여 노드 수를 업데이트하여 클러스터를 다시 시작해야 합니다.

1.7.7.1. 사전 요구 사항
링크 복사

호스팅 클러스터를 구성하려면 다음 사전 요구 사항이 있어야 합니다.

  • Kubernetes Operator 2.4 이상용 다중 클러스터 엔진이 OpenShift Container Platform 클러스터에 설치되어 있습니다. Red Hat Advanced Cluster Management를 설치할 때 다중 클러스터 엔진 Operator가 자동으로 설치됩니다. Red Hat Advanced Cluster Management 없이 OpenShift Container Platform OperatorHub의 Operator로 다중 클러스터 엔진 Operator를 설치할 수도 있습니다.

  • 다중 클러스터 엔진 Operator에는 하나 이상의 관리형 OpenShift Container Platform 클러스터가 있어야 합니다. local-cluster 는 다중 클러스터 엔진 Operator 2.4 이상에서 자동으로 가져옵니다. local-cluster 에 대한 자세한 내용은 고급 구성 을 참조하십시오. 다음 명령을 실행하여 허브 클러스터의 상태를 확인할 수 있습니다. 

    oc get managedclusters local-cluster
    Copy to Clipboard Toggle word wrap
  • HyperShift Operator를 실행하려면 작업자 노드가 3개 이상인 호스팅 클러스터가 필요합니다.
  • 중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
  • 호스팅된 컨트롤 플레인 명령줄 인터페이스를 설치해야 합니다. 호스팅된 컨트롤 플레인 명령줄 인터페이스 설치를 참조하십시오.

1.7.7.2. IBM Power 인프라 요구사항
링크 복사

에이전트 플랫폼은 인프라를 생성하지 않지만 인프라에는 다음이 필요합니다.

  • 에이전트: 에이전트 는 검색 이미지로 부팅되고 OpenShift Container Platform 노드로 프로비저닝할 준비가 된 호스트를 나타냅니다.
  • DNS: API 및 수신 끝점은 라우팅할 수 있어야 합니다.

1.7.7.3. IBM Power 구성 문서
링크 복사

사전 요구 사항을 충족한 후 베어 메탈에서 호스팅된 컨트롤 플레인을 구성하려면 다음 주제를 참조하십시오.

  1. InfraEnv 리소스에 에이전트 추가
  2. IBM Power에서 호스팅된 컨트롤 플레인을 위한 DNS 구성
  3. 베어 메탈에서 호스트 클러스터 생성
  4. IBM Power 컴퓨팅 노드의 64비트 x86 베어 메탈에서 호스팅된 컨트롤 플레인에 대한 InfraEnv 리소스 생성
  5. IBM Power에서 호스팅된 클러스터의 NodePool 오브젝트를 확장합니다.

1.7.7.4. InfraEnv 리소스에 에이전트 추가
링크 복사

라이브 ISO로 시작하도록 시스템을 수동으로 구성하여 에이전트를 추가할 수 있습니다.

  1. 라이브 ISO를 다운로드하여 호스트를 시작하는 데 사용합니다(베어 메탈 또는 VM). 라이브 ISO의 URL은 InfraEnv 리소스에서 status.isoDownloadURL 필드에 있습니다. 시작 시 호스트는 지원 서비스와 통신하고 InfraEnv 리소스와 동일한 네임스페이스에 에이전트로 등록합니다.

  2. 에이전트 및 일부 속성을 나열하려면 다음 명령을 입력합니다. 

    oc -n <hosted-control-plane-namespace> get agents
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME                                   CLUSTER   APPROVED   ROLE          STAGE
86f7ac75-4fc4-4b36-8130-40fa12602218                        auto-assign
e57a637f-745b-496e-971d-1abbf03341ba                        auto-assign
    Copy to Clipboard Toggle word wrap

  3. 각 에이전트가 생성되면 선택적으로 사양에 installation_disk_id 및 hostname 을 설정하고 다음 명령을 입력하여 에이전트를 승인할 수 있습니다. 

    oc -n <hosted-control-plane-namespace> patch agent 86f7ac75-4fc4-4b36-8130-40fa12602218 -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' --type merge

oc -n <hosted-control-plane-namespace> patch agent 23d0c614-2caa-43f5-b7d3-0b3564688baa -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' --type merge
    Copy to Clipboard Toggle word wrap

  4. 에이전트가 사용되도록 승인되었는지 확인하려면 다음 명령을 입력하고 출력을 확인합니다. 

    oc -n <hosted-control-plane-namespace> get agents
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME                                   CLUSTER   APPROVED   ROLE          STAGE
86f7ac75-4fc4-4b36-8130-40fa12602218             true       auto-assign
e57a637f-745b-496e-971d-1abbf03341ba             true       auto-assign
    Copy to Clipboard Toggle word wrap

1.7.7.5. IBM Power에서 호스팅된 컨트롤 플레인을 위한 DNS 구성
링크 복사

호스팅된 클러스터의 API 서버가 노출됩니다. API 서버에 연결할 수 있는 대상을 가리키는 api.<hosted_cluster_name>.<base-domain > 항목에 대한 DNS 항목이 있어야 합니다.

DNS 항목은 호스팅된 컨트롤 플레인을 실행하는 관리형 클러스터의 노드 중 하나를 가리키는 레코드만큼 단순할 수 있습니다.

이 항목은 들어오는 트래픽을 인그레스 포드로 리디렉션하기 위해 배포된 로드 밸런서를 가리킬 수도 있습니다.

다음 DNS 구성 예제를 참조하십시오. 

$ cat /var/named/<example.krnl.es.zone>
Copy to Clipboard Toggle word wrap

다음 예제 출력을 참조하십시오. 

$ TTL 900
@ IN  SOA bastion.example.krnl.es.com. hostmaster.example.krnl.es.com. (
      2019062002
      1D 1H 1W 3H )
  IN NS bastion.example.krnl.es.com.
;
;
api                   IN A 1xx.2x.2xx.1xx
1 

api-int               IN A 1xx.2x.2xx.1xx
;
;
*.apps.${HOSTED_CLUSTER_NAME}.${BASEDOMAIN}           IN A 1xx.2x.2xx.1xx
;
;EOF
Copy to Clipboard Toggle word wrap
1
레코드는 호스팅된 컨트롤 플레인의 수신 및 송신 트래픽을 처리하는 API 로드 밸런서의 IP 주소를 나타냅니다.

IBM Power의 경우 에이전트의 IP 주소에 해당하는 IP 주소를 추가합니다. 

compute-0              IN A 1xx.2x.2xx.1yy
compute-1              IN A 1xx.2x.2xx.1yy
Copy to Clipboard Toggle word wrap

InfraEnv 는 라이브 ISO를 시작하는 호스트가 에이전트로 참여할 수 있는 환경입니다. 이 경우 에이전트는 호스팅된 컨트롤 플레인과 동일한 네임스페이스에 생성됩니다.

InfraEnv 리소스를 생성하려면 다음 단계를 완료합니다.

  1. 구성을 포함할 YAML 파일을 생성합니다. 다음 예제를 참조하십시오. 

    apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: ${HOSTED_CLUSTER_NAME}
  namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE}
spec:
  cpuArchitecture: ppc64le
  pullSecretRef:
    name: pull-secret
  sshAuthorizedKey: ${SSH_PUB_KEY}
    Copy to Clipboard Toggle word wrap
  2. 파일을 infraenv-config.yaml 로 저장합니다.

  3. 다음 명령을 입력하여 구성을 적용합니다. 

    oc apply -f infraenv-config.yaml
    Copy to Clipboard Toggle word wrap

  4. IBM Power 머신이 에이전트로 결합할 수 있는 라이브 ISO를 다운로드하는 URL을 가져오려면 다음 명령을 입력합니다. 

    oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> -o json
    Copy to Clipboard Toggle word wrap

1.7.7.7. IBM Power에서 호스팅된 클러스터의 NodePool 오브젝트 확장
링크 복사

NodePool 오브젝트는 호스팅된 클러스터를 생성할 때 생성됩니다. NodePool 오브젝트를 스케일링하면 호스팅된 컨트롤 플레인에 더 많은 컴퓨팅 노드를 추가할 수 있습니다.

  1. 다음 명령을 실행하여 NodePool 오브젝트를 두 개의 노드로 확장합니다. 

    oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
    Copy to Clipboard Toggle word wrap

    Cluster API 에이전트 공급자는 호스트 클러스터에 할당된 두 개의 에이전트를 임의로 선택합니다. 이러한 에이전트는 다른 상태를 통과하고 마지막으로 호스팅된 클러스터에 OpenShift Container Platform 노드로 참여합니다. 에이전트는 다음 순서로 전환 단계를 통과합니다.

    • 바인딩
    • 검색
    • insufficient
    • 설치
    • installing-in-progress
    • added-to-existing-cluster

  2. 다음 명령을 실행하여 특정 확장 에이전트의 상태를 확인합니다. 

    oc -n <hosted_control_plane_namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

    다음 출력을 참조하십시오. 

    BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound
BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 전환 단계를 확인합니다. 

    oc -n <hosted_control_plane_namespace> get agent
    Copy to Clipboard Toggle word wrap

    다음 출력을 참조하십시오. 

    NAME                                   CLUSTER           APPROVED       ROLE        STAGE
50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   hosted-forwarder   true          auto-assign
5e498cd3-542c-e54f-0c58-ed43e28b568a                      true          auto-assign
da503cf1-a347-44f2-875c-4960ddb04091   hosted-forwarder   true          auto-assign
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 호스팅된 클러스터에 액세스할 kubeconfig 파일을 생성합니다. 

    hcp create kubeconfig --namespace <clusters_namespace> --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig
    Copy to Clipboard Toggle word wrap

  5. 에이전트가 add-to-existing-cluster 상태에 도달한 후 다음 명령을 입력하여 OpenShift Container Platform 노드를 볼 수 있는지 확인합니다. 

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    다음 출력을 참조하십시오. 

    NAME                             STATUS   ROLES    AGE      VERSION
worker-zvm-0.hostedn.example.com Ready    worker   5m41s    v1.24.0+3882f8f
worker-zvm-1.hostedn.example.com Ready    worker   6m3s     v1.24.0+3882f8f
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 입력하여 NodePool 오브젝트를 확장할 때 두 개의 머신이 생성되었는지 확인합니다. 

    oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io
    Copy to Clipboard Toggle word wrap

    다음 출력을 참조하십시오. 

    NAME                                CLUSTER  NODENAME PROVIDERID     PHASE     AGE   VERSION
hosted-forwarder-79558597ff-5tbqp   hosted-forwarder-crqq5   worker-zvm-0.hostedn.example.com   agent://50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   Running   41h   4.14.0
hosted-forwarder-79558597ff-lfjfk   hosted-forwarder-crqq5   worker-zvm-1.hostedn.example.com   agent://5e498cd3-542c-e54f-0c58-ed43e28b568a   Running   41h   4.14.0
    Copy to Clipboard Toggle word wrap

  7. 다음 명령을 실행하여 클러스터 버전 및 클러스터 Operator 상태를 확인합니다. 

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
    Copy to Clipboard Toggle word wrap

    다음 출력을 참조하십시오. 

    NAME                                         VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.14.0   True        False         40h     Cluster version is 4.14.0
NAME                                                                           VERSION       AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.14.0   True        False         False      40h
clusteroperator.config.openshift.io/csi-snapshot-controller                    4.14.0   True        False         False      2d2h
clusteroperator.config.openshift.io/dns                                        4.14.0   True        False         False      40h
clusteroperator.config.openshift.io/image-registry                             4.14.0   True        False         False      40h
clusteroperator.config.openshift.io/ingress                                    4.14.0   True        False         False      2d2h
clusteroperator.config.openshift.io/insights                                   4.14.0   True        False         False      40h
clusteroperator.config.openshift.io/kube-apiserver                             4.14.0   True        False         False      2d2h
clusteroperator.config.openshift.io/kube-controller-manager                    4.14.0   True        False         False      2d2h
clusteroperator.config.openshift.io/kube-scheduler                             4.14.0   True        False         False      2d2h
clusteroperator.config.openshift.io/kube-storage-version-migrator              4.14.0   True        False         False      40h
clusteroperator.config.openshift.io/monitoring                                 4.14.0   True        False         False      40h
clusteroperator.config.openshift.io/network                                    4.14.0   True        False         False      40h
clusteroperator.config.openshift.io/node-tuning                                4.14.0   True        False         False      40h
clusteroperator.config.openshift.io/openshift-apiserver                        4.14.0   True        False         False      2d2h
clusteroperator.config.openshift.io/openshift-controller-manager               4.14.0   True        False         False      2d2h
clusteroperator.config.openshift.io/openshift-samples                          4.14.0   True        False         False      40h
clusteroperator.config.openshift.io/operator-lifecycle-manager                 4.14.0   True        False         False      2d2h
clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog         4.14.0   True        False         False      2d2h
clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver   4.14.0   True        False         False      2d2h
clusteroperator.config.openshift.io/service-ca                                 4.14.0   True        False         False      40h
clusteroperator.config.openshift.io/storage                                    4.14.0   True        False         False      2d2h
    Copy to Clipboard Toggle word wrap

기술 프리뷰: IBM Z (390x) 컴퓨팅 노드의 x86 베어 메탈에서 호스팅 클러스터를 구성하는 것은 제한된 지원이 포함된 기술 프리뷰 상태에 있습니다.

호스팅 클러스터로 작동하도록 클러스터를 구성하여 호스팅 컨트롤 플레인을 배포할 수 있습니다. 호스팅 클러스터는 컨트롤 플레인이 호스팅되는 OpenShift Container Platform 클러스터입니다. 호스팅 클러스터를 관리 클러스터라고도 합니다.

참고: 관리 클러스터는 관리 클러스터가 아닙니다. 관리형 클러스터는 hub 클러스터가 관리하는 클러스터입니다.

hypershift 애드온을 사용하여 해당 클러스터에 HyperShift Operator를 배포하여 관리 클러스터를 호스팅 클러스터로 변환할 수 있습니다. 그런 다음 호스팅된 클러스터를 생성할 수 있습니다.

다중 클러스터 엔진 Operator 2.4는 관리하는 허브 클러스터인 기본 로컬 클러스터와 허브 클러스터를 호스팅 클러스터로만 지원합니다.

중요:

  • IBM Z는 ISO 부팅을 지원하지 않습니다.
  • 베어 메탈에서 호스팅되는 컨트롤 플레인을 프로비저닝하려면 에이전트 플랫폼을 사용할 수 있습니다. 에이전트 플랫폼은 중앙 인프라 관리 서비스를 사용하여 호스트된 클러스터에 작업자 노드를 추가합니다. 중앙 인프라 관리 서비스에 대한 소개는 Kube API - 시작하기 가이드를 참조하십시오.
  • 각 IBM Z 시스템 호스트는 중앙 인프라 관리에서 제공하는 PXE 이미지로 시작해야 합니다. 각 호스트가 시작되면 에이전트 프로세스를 실행하여 호스트의 세부 정보를 검색하고 설치를 완료합니다. 에이전트 사용자 정의 리소스는 각 호스트를 나타냅니다.
  • 에이전트 플랫폼을 사용하여 호스팅된 클러스터를 생성하면 HyperShift Operator가 호스팅된 컨트롤 플레인 네임스페이스에 에이전트 클러스터 API 공급자를 설치합니다.
  • 노드 풀을 확장하면 머신이 생성됩니다. Cluster API 공급자는 승인된 에이전트를 찾고 현재 검증이 사용되지 않으며, 노드 풀 사양에 지정된 요구 사항을 충족합니다. 에이전트의 상태 및 조건을 확인하여 에이전트 설치를 모니터링할 수 있습니다.
  • 노드 풀을 축소하면 에이전트가 해당 클러스터에서 바인딩되지 않습니다. 클러스터를 재사용하기 전에 PXE 이미지를 사용하여 노드 수를 업데이트하여 클러스터를 부팅해야 합니다.

1.7.8.1. 사전 요구 사항
링크 복사

  • Kubernetes Operator 버전 2.4 이상을 위한 다중 클러스터 엔진이 OpenShift Container Platform 클러스터에 설치되어 있어야 합니다. Red Hat Advanced Cluster Management를 설치할 때 다중 클러스터 엔진 Operator가 자동으로 설치됩니다. Red Hat Advanced Cluster Management 없이 OpenShift Container Platform OperatorHub의 Operator로 다중 클러스터 엔진 Operator를 설치할 수도 있습니다.

  • 다중 클러스터 엔진 Operator에는 하나 이상의 관리형 OpenShift Container Platform 클러스터가 있어야 합니다. local-cluster 는 다중 클러스터 엔진 Operator 2.4 이상에서 자동으로 가져옵니다. local-cluster 에 대한 자세한 내용은 고급 구성 을 참조하십시오. 다음 명령을 실행하여 허브 클러스터의 상태를 확인할 수 있습니다. 

    oc get managedclusters local-cluster
    Copy to Clipboard Toggle word wrap
  • HyperShift Operator를 실행하려면 작업자 노드가 3개 이상 있는 호스팅 클러스터가 필요합니다.
  • 중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
  • 호스팅된 컨트롤 플레인 명령줄 인터페이스를 설치해야 합니다. 호스팅된 컨트롤 플레인 명령줄 인터페이스 설치를 참조하십시오.

1.7.8.2. IBM Z 인프라 요구사항
링크 복사

에이전트 플랫폼은 인프라를 생성하지 않지만 인프라에는 다음이 필요합니다.

  • 에이전트: 에이전트 는 검색 이미지 또는 PXE 이미지로 부팅되고 OpenShift Container Platform 노드로 프로비저닝할 준비가 된 호스트를 나타냅니다.
  • DNS: API 및 Ingress 끝점은 라우팅할 수 있어야 합니다.

호스트된 컨트롤 플레인 기능은 기본적으로 활성화되어 있습니다. 기능을 비활성화하고 수동으로 활성화하거나 기능을 비활성화해야 하는 경우 호스팅된 컨트롤 플레인 기능 활성화 또는 비활성화를 참조하십시오.

1.7.8.3. IBM Z 구성 문서
링크 복사

사전 요구 사항을 충족한 후 베어 메탈에서 호스팅된 컨트롤 플레인을 구성하려면 다음 주제를 참조하십시오.

  1. InfraEnv 리소스에 IBM Z 에이전트 추가 (기술 프리뷰)
  2. IBM Z를 사용하여 호스팅된 컨트롤 플레인의 DNS 구성
  3. 베어 메탈에서 호스트 클러스터 생성
  4. IBM Z 컴퓨팅 노드의 64비트 x86 베어 메탈에서 호스팅된 컨트롤 플레인에 대한 InfraEnv 리소스 생성
  5. IBM Z에서 호스팅된 클러스터의 NodePool 오브젝트를 확장합니다.

1.7.8.4. InfraEnv 리소스에 IBM Z 에이전트 추가 (기술 프리뷰)
링크 복사

IBM Z 환경에 에이전트를 추가하려면 이 섹션에 자세히 설명된 추가 단계가 필요합니다.

참고: 달리 명시되지 않는 한, 다음 절차는 IBM Z 및 IBM LinuxONE의 z/VM 및 RHEL KVM 설치에 모두 적용됩니다.

1.7.8.4.1. KVM을 사용하여 IBM Z용 에이전트 추가
링크 복사

IBM Z with KVM의 경우 다음 명령을 실행하여 InfraEnv 리소스에서 다운로드한 PXE 이미지로 IBM Z 환경을 시작합니다. 에이전트가 생성되면 호스트는 지원 서비스와 통신하고 관리 클러스터의 InfraEnv 리소스와 동일한 네임스페이스에 등록합니다. 

virt-install \
   --name "<vm_name>" \
   --autostart \
   --ram=16384 \
   --cpu host \
   --vcpus=4 \
   --location "<path_to_kernel_initrd_image>,kernel=kernel.img,initrd=initrd.img" \
   --disk <qcow_image_path> \
   --network network:macvtap-net,mac=<mac_address> \
   --graphics none \
   --noautoconsole \
   --wait=-1 \
   --extra-args "rd.neednet=1 nameserver=<nameserver>   coreos.live.rootfs_url=http://<http_server>/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"
Copy to Clipboard Toggle word wrap
1.7.8.4.2. z/VM을 사용하여 에이전트 fror IBM 추가
링크 복사

InfraEnv 리소스에서 다운로드한 PXE 이미지로 IBM Z 환경을 시작하려면 다음 단계를 완료합니다. 에이전트가 생성되면 호스트는 지원 서비스와 통신하고 관리 클러스터의 InfraEnv 리소스와 동일한 네임스페이스에 등록합니다.

  1. 매개 변수 파일을 업데이트하여 rootfs_url,network_adaptor 및 disk_type 값을 추가합니다.

    다음 예제 매개변수 파일을 참조하십시오. 

    rd.neednet=1 \
console=ttysclp0  \
coreos.live.rootfs_url=<rootfs_url> \
ip=<IP_guest_vm>::<nameserver>:255.255.255.0::<network_adaptor>:none \
nameserver=<nameserver> \
zfcp.allow_lun_scan=0 \
    1 
    
rd.znet=qeth,<network_adaptor_range>,layer2=1 \
rd.<disk_type>=<storage> random.trust_cpu=on \
    2 
    
rd.luks.options=discard \
ignition.firstboot ignition.platform.id=metal \
console=tty1 console=ttyS1,115200n8 \
coreos.inst.persistent-kargs="console=tty1 console=ttyS1,115200n8
    Copy to Clipboard Toggle word wrap
    1
    VSwitch를 사용한 설치의 경우 zfcp.allow_lun_scan=0 을 추가합니다. OSA, Hipersockets 및 RoCE를 사용하여 설치하려면 이 항목을 생략합니다.
    2
    DASD 유형 디스크에 설치하는 경우 rd.dasd= 를 사용하여 설치 디스크를 지정합니다. FCP 유형 디스크에 설치하려면 rd.zfcp= 를 사용합니다.

  2. 다음 명령을 실행하여 initrd, 커널 이미지 및 매개변수 파일을 게스트 VM으로 이동합니다. 

    vmur pun -r -u -N kernel.img $INSTALLERKERNELLOCATION/<image name>
    Copy to Clipboard Toggle word wrap 
    vmur pun -r -u -N generic.parm $PARMFILELOCATION/paramfilename
    Copy to Clipboard Toggle word wrap 
    vmur pun -r -u -N initrd.img $INSTALLERINITRAMFSLOCATION/<image name>
    Copy to Clipboard Toggle word wrap

  3. 게스트 VM 콘솔에서 다음 명령을 실행합니다. 

    cp ipl c
    Copy to Clipboard Toggle word wrap

  4. 에이전트 및 해당 속성을 나열하려면 다음 명령을 입력합니다. 

    oc -n <hosted_control_plane_namespace> get agents
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME    CLUSTER APPROVED    ROLE    STAGE
50c23cda-cedc-9bbd-bcf1-9b3a5c75804d    auto-assign
5e498cd3-542c-e54f-0c58-ed43e28b568a    auto-assign
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 에이전트를 승인합니다. 선택 사항: 사양에서 에이전트 ID < installation_disk_id > 및 < hostname >을 설정할 수 있습니다. 

    oc -n <hosted_control_plane_namespace> patch agent 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-zvm-0.hostedn.example.com"}}' --type merge
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 실행하여 에이전트가 승인되었는지 확인합니다. 

    oc -n <hosted_control_plane_namespace> get agents
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME                                            CLUSTER     APPROVED   ROLE          STAGE
50c23cda-cedc-9bbd-bcf1-9b3a5c75804d             true       auto-assign
5e498cd3-542c-e54f-0c58-ed43e28b568a             true       auto-assign
    Copy to Clipboard Toggle word wrap

  7. IBM z/VM의 경우 이전 단계에서 패치한 에이전트를 편집하고 다음과 같이 spec 섹션에서 installerArgs 설정을 업데이트합니다. 

    installerArgs:
--append-karg rd.neednet=1 \
--append-karg ip=<IP_guest_vm>::<nameserver>:255.255.255.0:<hostname>:<network_adaptor>:none \
--append-karg nameserver=<nameserver> \
--append-karg rd.znet=qeth,<network_adaptor_range>,layer2=1 \
--append-karg rd.<storage_type>=<storage>
    Copy to Clipboard Toggle word wrap

1.7.8.5. IBM Z를 사용하여 호스팅된 컨트롤 플레인의 DNS 구성
링크 복사

호스팅된 클러스터의 API 서버는 'NodePort' 서비스로 노출됩니다. API 서버에 연결할 수 있는 대상을 가리키는 api.<hosted_cluster_name>.<base-domain >에 대한 DNS 항목이 있어야 합니다.

DNS 항목은 호스팅된 컨트롤 플레인을 실행하는 관리형 클러스터의 노드 중 하나를 가리키는 레코드만큼 단순할 수 있습니다.

이 항목은 들어오는 트래픽을 Ingress Pod로 리디렉션하기 위해 배포된 로드 밸런서를 가리킬 수도 있습니다.

다음 DNS 구성 예제를 참조하십시오. 

$ cat /var/named/<example.krnl.es.zone>
Copy to Clipboard Toggle word wrap

다음 예제 출력을 참조하십시오. 

$ TTL 900
@ IN  SOA bastion.example.krnl.es.com. hostmaster.example.krnl.es.com. (
      2019062002
      1D 1H 1W 3H )
  IN NS bastion.example.krnl.es.com.
;
;
api                   IN A 1xx.2x.2xx.1xx
1 

api-int               IN A 1xx.2x.2xx.1xx
;
;
*.apps        IN A 1xx.2x.2xx.1xx
;
;EOF
Copy to Clipboard Toggle word wrap
1
레코드는 호스팅된 컨트롤 플레인의 수신 및 송신 트래픽을 처리하는 API 로드 밸런서의 IP 주소를 나타냅니다.

IBM z/VM의 경우 에이전트의 IP 주소에 해당하는 IP 주소를 추가합니다. 

compute-0              IN A 1xx.2x.2xx.1yy
compute-1              IN A 1xx.2x.2xx.1yy
Copy to Clipboard Toggle word wrap

InfraEnv 는 PXE 이미지로 부팅되는 호스트가 에이전트로 참여할 수 있는 환경입니다. 이 경우 에이전트는 호스팅된 컨트롤 플레인과 동일한 네임스페이스에 생성됩니다.

InfraEnv 리소스를 생성하려면 다음 절차를 참조하십시오.

  1. 구성을 포함할 YAML 파일을 생성합니다. 다음 예제를 참조하십시오. 

    apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: ${HOSTED_CLUSTER_NAME}
  namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE}
spec:
  cpuArchitecture: s390x
  pullSecretRef:
    name: pull-secret
  sshAuthorizedKey: ${SSH_PUB_KEY}
    Copy to Clipboard Toggle word wrap
  2. 파일을 infraenv-config.yaml 로 저장합니다.

  3. 다음 명령을 입력하여 구성을 적용합니다. 

    oc apply -f infraenv-config.yaml
    Copy to Clipboard Toggle word wrap

  4. IBM Z 머신이 에이전트로 결합할 수 있는 initrd.img,kernel.img, rootfs.img 와 같은 PXE 이미지를 다운로드하여 URL을 가져오려면 다음 명령을 입력합니다. 

    oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> -o json
    Copy to Clipboard Toggle word wrap

1.7.8.7. IBM Z에서 호스팅된 클러스터의 NodePool 오브젝트 확장
링크 복사

NodePool 오브젝트는 호스팅된 클러스터를 생성할 때 생성됩니다. NodePool 오브젝트를 스케일링하면 호스팅된 컨트롤 플레인에 더 많은 컴퓨팅 노드를 추가할 수 있습니다.

  1. 다음 명령을 실행하여 NodePool 오브젝트를 두 개의 노드로 확장합니다. 

    oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
    Copy to Clipboard Toggle word wrap

    Cluster API 에이전트 공급자는 호스트 클러스터에 할당된 두 개의 에이전트를 임의로 선택합니다. 이러한 에이전트는 다른 상태를 통과하고 마지막으로 호스팅된 클러스터에 OpenShift Container Platform 노드로 참여합니다. 에이전트는 다음 순서로 전환 단계를 통과합니다.

    • 바인딩
    • 검색
    • insufficient
    • 설치
    • installing-in-progress
    • added-to-existing-cluster

  2. 다음 명령을 실행하여 특정 확장 에이전트의 상태를 확인합니다. 

    oc -n <hosted_control_plane_namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

    다음 출력을 참조하십시오. 

    BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound
BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 전환 단계를 확인합니다. 

    oc -n <hosted_control_plane_namespace> get agent
    Copy to Clipboard Toggle word wrap

    다음 출력을 참조하십시오. 

    NAME                                   CLUSTER           APPROVED       ROLE        STAGE
50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   hosted-forwarder   true          auto-assign
5e498cd3-542c-e54f-0c58-ed43e28b568a                      true          auto-assign
da503cf1-a347-44f2-875c-4960ddb04091   hosted-forwarder   true          auto-assign
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 호스팅된 클러스터에 액세스할 kubeconfig 파일을 생성합니다. 

    hcp create kubeconfig --namespace <clusters_namespace> --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig
    Copy to Clipboard Toggle word wrap

  5. 에이전트가 add-to-existing-cluster 상태에 도달한 후 다음 명령을 입력하여 OpenShift Container Platform 노드를 볼 수 있는지 확인합니다. 

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    다음 출력을 참조하십시오. 

    NAME                             STATUS   ROLES    AGE      VERSION
worker-zvm-0.hostedn.example.com Ready    worker   5m41s    v1.24.0+3882f8f
worker-zvm-1.hostedn.example.com Ready    worker   6m3s     v1.24.0+3882f8f
    Copy to Clipboard Toggle word wrap

    클러스터 Operator는 노드에 워크로드를 추가하여 조정하기 시작합니다.

  6. 다음 명령을 입력하여 NodePool 오브젝트를 확장할 때 두 개의 머신이 생성되었는지 확인합니다. 

    oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io
    Copy to Clipboard Toggle word wrap

    다음 출력을 참조하십시오. 

    NAME                                CLUSTER  NODENAME PROVIDERID     PHASE     AGE   VERSION
hosted-forwarder-79558597ff-5tbqp   hosted-forwarder-crqq5   worker-zvm-0.hostedn.example.com   agent://50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   Running   41h   4.14.0
hosted-forwarder-79558597ff-lfjfk   hosted-forwarder-crqq5   worker-zvm-1.hostedn.example.com   agent://5e498cd3-542c-e54f-0c58-ed43e28b568a   Running   41h   4.14.0
    Copy to Clipboard Toggle word wrap

  7. 다음 명령을 실행하여 클러스터 버전을 확인합니다. 

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
    Copy to Clipboard Toggle word wrap

    다음 출력을 참조하십시오. 

    NAME                                         VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.14.0-ec.2   True        False         40h     Cluster version is 4.14.0-ec.2
    Copy to Clipboard Toggle word wrap

  8. 다음 명령을 실행하여 클러스터 Operator 상태를 확인합니다. 

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators
    Copy to Clipboard Toggle word wrap

    다음 출력을 참조하십시오. 

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
console                                    4.14.2    True        False         False      5h34m
csi-snapshot-controller                    4.14.2    True        False         False      5h47m
dns                                        4.14.2    True        False         False      5h35m
image-registry                             4.14.2    True        False         False      5h34m
ingress                                    4.14.2    True        False         False      5h46m
insights                                   4.14.2    True        False         False      5h35m
kube-apiserver                             4.14.2    True        False         False      5h47m
kube-controller-manager                    4.14.2    True        False         False      5h47m
kube-scheduler                             4.14.2    True        False         False      5h47m
kube-storage-version-migrator              4.14.2    True        False         False      5h35m
monitoring                                 4.14.2    True        False         False      5h34m
network                                    4.14.2    True        False         False      5h34m
node-tuning                                4.14.2    True        False         False      5h35m
openshift-apiserver                        4.14.2    True        False         False      5h47m
openshift-controller-manager               4.14.2    True        False         False      5h47m
openshift-samples                          4.14.2    True        False         False      5h34m
operator-lifecycle-manager                 4.14.2    True        False         False      5h47m
operator-lifecycle-manager-catalog         4.14.2    True        False         False      5h47m
operator-lifecycle-manager-packageserver   4.14.2    True        False         False      5h47m
service-ca                                 4.14.2    True        False         False      5h35m
storage                                    4.14.2    True        False         False      5h47m
    Copy to Clipboard Toggle word wrap

1.7.9. OpenShift Virtualization에서 호스트된 컨트롤 플레인 클러스터 관리
링크 복사

호스팅된 컨트롤 플레인 및 Red Hat OpenShift Virtualization을 사용하면 KubeVirt 가상 머신에서 호스팅하는 작업자 노드로 OpenShift Container Platform 클러스터를 생성할 수 있습니다. OpenShift Virtualization에서 호스팅되는 컨트롤 플레인은 다음과 같은 몇 가지 이점을 제공합니다.

  • 동일한 기본 베어 메탈 인프라에서 호스트된 컨트롤 플레인 및 호스팅된 클러스터를 패키징하여 리소스 사용량 개선
  • 강력한 격리를 제공하기 위해 호스팅되는 컨트롤 플레인과 호스팅 클러스터를 분리
  • 베어 메탈 노드 부트스트랩 프로세스를 제거하여 클러스터 프로비저닝 시간 단축
  • 동일한 기본 OpenShift Container Platform 클러스터에서 많은 릴리스 관리

호스트된 컨트롤 플레인 기능은 기본적으로 활성화되어 있습니다.

호스팅된 컨트롤 플레인 명령줄 인터페이스 hcp 를 사용하여 OpenShift Container Platform 호스팅 클러스터를 생성할 수 있습니다. 호스팅된 클러스터는 관리 클러스터로 자동으로 가져옵니다. 이 자동 가져오기 기능을 비활성화하려면 호스팅된 클러스터를 멀티 클러스터 엔진 Operator로 자동 가져오기 비활성화 를 참조하십시오.

중요:

  • 호스팅된 컨트롤 플레인의 동일한 플랫폼에서 허브 클러스터 및 작업자를 실행합니다.
  • 각 호스팅된 클러스터에는 다중 클러스터 엔진 운영자가 관리할 수 있는 고유한 이름이 있어야 합니다.
  • 호스트된 클러스터는 다중 클러스터 엔진 Operator 관리 클러스터의 네임스페이스에서 생성할 수 없습니다.
  • 호스트된 컨트롤 플레인에 대한 스토리지를 구성할 때 권장 etcd 사례를 고려하십시오. 대기 시간 요구 사항을 충족하는지 확인하려면 각 컨트롤 플레인 노드에서 실행되는 모든 호스팅 컨트롤 플레인 etcd 인스턴스에 빠른 스토리지 장치를 전용으로 지정합니다. LVM 스토리지를 사용하여 호스팅된 etcd pod의 로컬 스토리지 클래스를 구성할 수 있습니다. 자세한 내용은 OpenShift Container Platform 설명서의 논리 볼륨 관리자 스토리지를 사용하여 etcd 권장 사례 및 영구 스토리지를 참조하십시오.

1.7.9.1. 사전 요구 사항
링크 복사

OpenShift Virtualization에서 OpenShift Container Platform 클러스터를 생성하려면 다음 사전 요구 사항을 충족해야 합니다.

  • KUBECONFIG 환경 변수에 지정된 OpenShift Container Platform 클러스터 버전 4.14 이상에 대한 관리자 액세스 권한이 필요합니다.

  • OpenShift Container Platform 호스팅 클러스터에는 다음 DNS에 표시된 대로 와일드카드 DNS 경로가 활성화되어 있어야 합니다. 

    oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
    Copy to Clipboard Toggle word wrap
  • OpenShift Container Platform 호스팅 클러스터에는 OpenShift Virtualization, 버전 4.14 이상이 설치되어 있어야 합니다. 자세한 내용은 웹 콘솔을 사용하여 OpenShift Virtualization 설치를 참조하십시오.
  • OpenShift Container Platform 호스팅 클러스터는 OVNKubernetes를 기본 Pod 네트워크 CNI로 구성해야합니다.

  • OpenShift Container Platform 호스팅 클러스터에는 기본 스토리지 클래스가 있어야 합니다. 자세한 내용은 설치 후 스토리지 구성 을 참조하십시오. 다음 예제에서는 기본 스토리지 클래스를 설정하는 방법을 보여줍니다. 

    oc patch storageclass ocs-storagecluster-ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
    Copy to Clipboard Toggle word wrap
  • quay.io/openshift-release-dev 리포지토리에 유효한 풀 시크릿 파일이 필요합니다. 자세한 내용은 사용자 프로비저닝 인프라가 있는 모든 x86_64 플랫폼에 OpenShift 설치를 참조하십시오.
  • 호스팅된 컨트롤 플레인 명령줄 인터페이스를 설치해야 합니다.
  • 클러스터를 프로비저닝하려면 먼저 로드 밸런서를 구성해야 합니다. 자세한 내용은 선택 사항: MetalLB 구성을 참조하십시오.
  • 최적의 네트워크 성능을 위해서는 KubeVirt 가상 머신을 호스팅하는 OpenShift Container Platform 클러스터에서 네트워크 최대 전송 단위(MTU)를 9000 이상으로 사용하십시오. 더 낮은 MTU 설정을 사용하는 경우 호스트된 Pod의 네트워크 대기 시간과 처리량이 영향을 받습니다. MTU가 9000 이상인 경우에만 노드 풀에서 멀티 큐를 활성화합니다.

  • 다중 클러스터 엔진 Operator에는 하나 이상의 관리형 OpenShift Container Platform 클러스터가 있어야 합니다. local-cluster 는 다중 클러스터 엔진 Operator 2.4 이상에서 자동으로 가져옵니다. local-cluster 에 대한 자세한 내용은 고급 구성 을 참조하십시오. 다음 명령을 실행하여 허브 클러스터의 상태를 확인할 수 있습니다. 

    oc get managedclusters local-cluster
    Copy to Clipboard Toggle word wrap

1.7.9.2. 방화벽 및 포트 요구 사항
링크 복사

포트가 관리 클러스터, 컨트롤 플레인 및 호스팅 클러스터 간에 통신할 수 있도록 방화벽 및 포트 요구 사항을 충족하는지 확인합니다.

  • kube-apiserver 서비스는 기본적으로 포트 6443에서 실행되며 컨트롤 플레인 구성 요소 간의 통신을 위해 수신 액세스가 필요합니다.

    • NodePort 게시 전략을 사용하는 경우 kube-apiserver 서비스에 할당된 노드 포트가 노출되어 있는지 확인합니다.
    • MetalLB 로드 밸런싱을 사용하는 경우 로드 밸런서 IP 주소에 사용되는 IP 범위에 대한 수신 액세스를 허용합니다.
  • NodePort 게시 전략을 사용하는 경우 ignition-server 및 Oauth-server 설정에 방화벽 규칙을 사용합니다.

  • 호스팅된 클러스터에서 양방향 통신을 허용하도록 역방향 터널을 설정하는 konnectivity 에이전트에는 포트 6443의 클러스터 API 서버 주소에 대한 송신 액세스가 필요합니다. 이 송신 액세스를 사용하면 에이전트가 kube-apiserver 서비스에 도달할 수 있습니다.

    • 클러스터 API 서버 주소가 내부 IP 주소인 경우 워크로드 서브넷에서 포트 6443의 IP 주소로 액세스를 허용합니다.
    • 주소가 외부 IP 주소인 경우 6443 포트에서 노드에서 해당 외부 IP 주소로 송신을 허용합니다.
  • 기본 6443 포트를 변경하는 경우 해당 변경 사항을 반영하도록 규칙을 조정합니다.
  • 클러스터에서 실행되는 워크로드에 필요한 모든 포트를 열어야 합니다.
  • 방화벽 규칙, 보안 그룹 또는 기타 액세스 제어를 사용하여 필요한 소스만 액세스를 제한합니다. 필요한 경우 포트를 공개적으로 노출하지 마십시오.
  • 프로덕션 배포의 경우 로드 밸런서를 사용하여 단일 IP 주소를 통한 액세스를 단순화합니다.

Red Hat OpenShift Virtualization의 호스팅 컨트롤 플레인에 대한 추가 리소스는 다음 문서를 참조하십시오.

1.7.9.3. KubeVirt 플랫폼을 사용하여 호스트 클러스터 생성
링크 복사

OpenShift Container Platform 4.14 이상에서는 KubeVirt로 클러스터를 생성하여 외부 인프라로 생성할 수 있습니다. KubeVirt를 사용하여 생성하는 프로세스에 대해 자세히 알아보십시오.

1.7.9.3.1. 호스트 클러스터 생성
링크 복사

  1. 호스트된 클러스터를 생성하려면 환경 변수와 호스팅된 컨트롤 플레인 명령줄 인터페이스를 사용합니다. hcp: 

    export CLUSTER_NAME=example
export PULL_SECRET="$HOME/pull-secret"
export MEM="6Gi"
export CPU="2"
export WORKER_COUNT="2"
export ETCD_STORAGE="lvm-storageclass"

hcp create cluster kubevirt \
--name $CLUSTER_NAME \
--node-pool-replicas $WORKER_COUNT \
--pull-secret $PULL_SECRET \
--memory $MEM \
--cores $CPU \
--etcd-storage-class=${ETCD_STORAGE}
    Copy to Clipboard Toggle word wrap

    필요한 경우 값을 바꿉니다.

    참고: --release-image 플래그를 사용하여 특정 OpenShift Container Platform 릴리스와 함께 호스팅 클러스터를 설정할 수 있습니다.

    --node-pool-replicas 플래그에 따라 두 개의 가상 머신 작업자 복제본이 있는 클러스터에 대한 기본 노드 풀이 생성됩니다.

  2. 잠시 후 다음 명령을 입력하여 호스팅된 컨트롤 플레인 포드가 실행 중인지 확인합니다. 

    oc -n clusters-$CLUSTER_NAME get pods
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME                                                  READY   STATUS    RESTARTS   AGE
capi-provider-5cc7b74f47-n5gkr                        1/1     Running   0          3m
catalog-operator-5f799567b7-fd6jw                     2/2     Running   0          69s
certified-operators-catalog-784b9899f9-mrp6p          1/1     Running   0          66s
cluster-api-6bbc867966-l4dwl                          1/1     Running   0          66s
.
.
.
redhat-operators-catalog-9d5fd4d44-z8qqk              1/1     Running   0          66s
    Copy to Clipboard Toggle word wrap

    KubeVirt 가상 머신에서 지원하는 작업자 노드가 있는 호스팅된 클러스터는 일반적으로 완전히 프로비저닝되는 데 10-15분이 걸립니다.

  3. 호스트 클러스터의 상태를 확인하려면 다음 명령을 입력하여 해당 HostedCluster 리소스를 참조하십시오. 

    oc get --namespace clusters hostedclusters
    Copy to Clipboard Toggle word wrap

    완전히 프로비저닝된 HostedCluster 오브젝트를 설명하는 다음 예제 출력을 참조하십시오. 

    NAMESPACE   NAME      VERSION   KUBECONFIG                 PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
clusters    example   4.14.0    example-admin-kubeconfig   Completed   True        False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap
  4. 호스트 클러스터 액세스 지침에 따라 호스팅된 클러스터에 액세스 합니다.
1.7.9.3.2. 외부 인프라를 사용하여 호스트된 클러스터 생성
링크 복사

기본적으로 HyperShift Operator는 동일한 클러스터 내에서 호스팅되는 클러스터의 컨트롤 플레인 Pod와 KubeVirt 작업자 VM을 모두 호스팅합니다. 외부 인프라 기능을 사용하면 작업자 노드 VM을 컨트롤 플레인 Pod와 별도의 클러스터에 배치할 수 있습니다.

  • 관리 클러스터 는 HyperShift Operator를 실행하고 호스팅된 클러스터의 컨트롤 플레인 Pod를 호스팅하는 OpenShift Container Platform 클러스터입니다.
  • 인프라 클러스터 는 호스팅된 클러스터의 KubeVirt 작업자 VM을 실행하는 OpenShift Container Platform 클러스터입니다.
  • 기본적으로 관리 클러스터는 VM을 호스팅하는 인프라 클러스터 역할을 합니다. 그러나 외부 인프라의 경우 관리 및 인프라 클러스터는 다릅니다.
1.7.9.3.2.1. 외부 인프라의 사전 요구 사항
링크 복사
  • KubeVirt 노드를 호스팅하려면 외부 인프라 클러스터에 네임스페이스가 있어야 합니다.
  • 외부 인프라 클러스터에 대한 kubeconfig 파일이 있어야 합니다.
1.7.9.3.2.2. hcp 명령줄 인터페이스를 사용하여 호스트 클러스터 생성
링크 복사

hcp 명령줄 인터페이스를 사용하여 호스트된 클러스터를 생성할 수 있습니다.

  1. 인프라 클러스터에 KubeVirt 작업자 VM을 배치하려면 다음 예와 같이 --infra-kubeconfig-file 및 --infra-namespace 인수를 사용합니다. 

    export CLUSTER_NAME=example
export PULL_SECRET="$HOME/pull-secret"
export MEM="6Gi"
export CPU="2"
export WORKER_COUNT="2"

hcp create cluster kubevirt \
--name $CLUSTER_NAME \
--node-pool-replicas $WORKER_COUNT \
--pull-secret $PULL_SECRET \
--memory $MEM \
--cores $CPU \
--infra-namespace=clusters-example \
--infra-kubeconfig-file=$HOME/external-infra-kubeconfig
    Copy to Clipboard Toggle word wrap

해당 명령을 입력하면 컨트롤 플레인 Pod가 HyperShift Operator가 실행되는 관리 클러스터에서 호스팅되고 KubeVirt VM은 별도의 인프라 클러스터에서 호스팅됩니다.

  1. 호스트 클러스터 액세스 지침에 따라 호스팅된 클러스터에 액세스 합니다.

1.7.9.4. 기본 수신 및 DNS 동작
링크 복사

모든 OpenShift Container Platform 클러스터에는 기본 애플리케이션 Ingress 컨트롤러가 포함되어 있으며, 이와 연결된 와일드카드 DNS 레코드가 있어야 합니다. 기본적으로 HyperShift KubeVirt 공급자를 사용하여 생성된 호스팅 클러스터는 KubeVirt 가상 머신이 실행되는 OpenShift Container Platform 클러스터의 하위 도메인이 자동으로 됩니다.

예를 들어 OpenShift Container Platform 클러스터에 다음과 같은 기본 인그레스 DNS 항목이 있을 수 있습니다. 

*.apps.mgmt-cluster.example.com
Copy to Clipboard Toggle word wrap

결과적으로 guest 라는 이름의 KubeVirt 호스팅 클러스터에는 다음과 같은 기본 수신이 있습니다. 

*.apps.guest.apps.mgmt-cluster.example.com
Copy to Clipboard Toggle word wrap

기본 인그레스 DNS가 제대로 작동하려면 KubeVirt 가상 머신을 호스팅하는 클러스터에서 와일드카드 DNS 경로를 허용해야 합니다. 다음 명령을 입력하여 이 동작을 구성할 수 있습니다. 

oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
Copy to Clipboard Toggle word wrap

참고: 기본 호스팅 클러스터 수신을 사용하는 경우 포트 443을 통한 HTTPS 트래픽으로 제한됩니다. 포트 80을 통한 일반 HTTP 트래픽이 거부됩니다. 이 제한은 기본 수신 동작에만 적용됩니다.

1.7.9.4.1. 수신 및 DNS 동작 사용자 정의
링크 복사

기본 수신 및 DNS 동작을 사용하지 않으려면 생성 시 KubeVirt 호스팅 클러스터를 고유 기본 도메인으로 구성할 수 있습니다. 이 옵션을 사용하려면 생성 중에 수동 구성 단계가 필요하며 클러스터 생성, 로드 밸런서 생성 및 와일드카드 DNS 구성의 세 가지 주요 단계가 포함됩니다.

1.7.9.4.1.1. 기본 도메인을 지정하는 호스팅된 클러스터 배포
링크 복사

  1. 기본 도메인을 지정하는 호스팅 클러스터를 생성하려면 다음 명령을 입력합니다. 

    export CLUSTER_NAME=example
    1 
    
export PULL_SECRET="$HOME/pull-secret"
export MEM="6Gi"
export CPU="2"
export WORKER_COUNT="2"
export BASE_DOMAIN=hypershift.lab
    2 
    

hcp create cluster kubevirt \
--name $CLUSTER_NAME \
--node-pool-replicas $WORKER_COUNT \
--pull-secret $PULL_SECRET \
--memory $MEM \
--cores $CPU \
--base-domain $BASE_DOMAIN
    Copy to Clipboard Toggle word wrap
    1
    호스트된 클러스터의 이름(예:)은 입니다.
    2
    예를 들어 기본 도메인은 hypershift.lab 입니다.

    그 결과 클러스터 이름 및 기본 도메인에 대해 구성된 인그레스 와일드카드가 있거나 이 예제 .apps.example.hypershift.lab 과 같이 호스팅된 클러스터가 생성됩니다. 호스트된 클러스터는 배포를 완료하지 않지만 부분적으로 유지됩니다. 기본 도메인을 구성했기 때문에 필요한 DNS 레코드 및 로드 밸런서가 있는지 확인해야 합니다.

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

    oc get --namespace clusters hostedclusters
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME            VERSION   KUBECONFIG                       PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
example                   example-admin-kubeconfig         Partial    True        False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 입력하여 클러스터에 액세스합니다. 

    hcp create kubeconfig --name $CLUSTER_NAME > $CLUSTER_NAME-kubeconfig
    Copy to Clipboard Toggle word wrap 
    oc --kubeconfig $CLUSTER_NAME-kubeconfig get co
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
console                                    4.14.0    False       False         False      30m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.example.hypershift.lab): Get "https://console-openshift-console.apps.example.hypershift.lab": dial tcp: lookup console-openshift-console.apps.example.hypershift.lab on 172.31.0.10:53: no such host
.
.
.
ingress                                    4.14.0    True        False         True       28m     The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)
    Copy to Clipboard Toggle word wrap

    다음 단계에서는 출력의 오류를 수정합니다.

    참고: 클러스터가 베어 메탈에 있는 경우 로드 밸런서 서비스를 설정할 수 있도록 MetalLB가 필요할 수 있습니다. 자세한 내용은 선택 사항: MetalLB 구성을 참조하십시오.

1.7.9.4.1.2. 로드 밸런서 설정
링크 복사

KubeVirt VM으로 라우팅하는 로드 밸런서를 설정하고 로드 밸런서 IP 주소에 와일드카드 DNS 항목을 할당합니다. Ingress 트래픽을 KubeVirt VM으로 라우팅하는 로드 밸런서 서비스를 생성해야 합니다. 호스팅된 클러스터 인그레스를 노출하는 NodePort 서비스가 이미 있으므로 노드 포트를 내보내고 해당 포트를 대상으로 하는 로드 밸런서 서비스를 생성할 수 있습니다.

  1. 다음 명령을 입력하여 노드 포트를 내보냅니다. 

    export HTTP_NODEPORT=$(oc --kubeconfig $CLUSTER_NAME-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}')
export HTTPS_NODEPORT=$(oc --kubeconfig $CLUSTER_NAME-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 로드 밸런서 서비스를 생성합니다. 

    oc apply -f -
apiVersion: v1
kind: Service
metadata:
  labels:
    app: $CLUSTER_NAME
  name: $CLUSTER_NAME-apps
  namespace: clusters-$CLUSTER_NAME
spec:
  ports:
  - name: https-443
    port: 443
    protocol: TCP
    targetPort: ${HTTPS_NODEPORT}
  - name: http-80
    port: 80
    protocol: TCP
    targetPort: ${HTTP_NODEPORT}
  selector:
    kubevirt.io: virt-launcher
  type: LoadBalancer
    Copy to Clipboard Toggle word wrap
1.7.9.4.1.3. 와일드카드 DNS 설정
링크 복사

로드 밸런서 서비스의 외부 IP를 참조하는 와일드카드 DNS 레코드 또는 CNAME을 설정합니다.

  1. 다음 명령을 입력하여 외부 IP를 내보냅니다. 

    export EXTERNAL_IP=$(oc -n clusters-$CLUSTER_NAME get service $CLUSTER_NAME-apps -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    Copy to Clipboard Toggle word wrap

  2. $EXTERNAL_IP 경로에 저장된 IP를 참조하는 와일드카드 DNS 항목을 구성합니다. 다음 예제 DNS 항목을 확인합니다. 

    *.apps.<hosted-cluster-name\>.<base-domain\>.
    Copy to Clipboard Toggle word wrap

    DNS 항목은 클러스터 내부 및 외부에서 라우팅할 수 있어야 합니다. 1단계에서의 예제 입력을 사용하는 경우 외부 IP 값이 192.168.20.30 인 클러스터의 경우 DNS 확인은 다음과 같습니다. 

    dig +short test.apps.example.hypershift.lab

192.168.20.30
    Copy to Clipboard Toggle word wrap

  3. 호스트된 클러스터 상태를 확인하고 다음 명령을 입력하여 Partial 에서 Completed 로 이동했는지 확인합니다. 

    oc get --namespace clusters hostedclusters
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME            VERSION   KUBECONFIG                       PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
example         4.14.0    example-admin-kubeconfig         Completed   True        False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap
1.7.9.4.1.4. 추가 리소스
링크 복사

1.7.9.5. 선택사항: MetalLB 구성
링크 복사

MetalLB와 같은 로드 밸런서를 사용해야 합니다. 다음 예제에서는 MetalLB를 설치한 후 구성하는 데 사용할 수 있는 단계를 보여줍니다. MetalLB 설치에 대한 자세한 내용은 OpenShift Container Platform 설명서에서 MetalLB Operator 설치를 참조하십시오.

  1. MetalLB 리소스 인스턴스를 생성합니다. 

    oc create -f -
apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
    Copy to Clipboard Toggle word wrap

  2. 노드 네트워크 내에서 사용 가능한 IP 주소 범위를 사용하여 주소 풀을 생성합니다. 다음 IP 주소 범위를 네트워크에서 사용 가능한 IP 주소의 사용되지 않는 풀로 바꿉니다. 다음 명령을 실행합니다. 

    oc create -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: metallb
  namespace: metallb-system
spec:
  addresses:
  - 192.168.216.32-192.168.216.122
    Copy to Clipboard Toggle word wrap

  3. L2 프로토콜을 사용하여 주소 풀을 알립니다. 다음 명령을 실행합니다. 

    oc create -f -
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertisement
  namespace: metallb-system
spec:
  ipAddressPools:
   - metallb
    Copy to Clipboard Toggle word wrap
1.7.9.5.1. 추가 리소스
링크 복사

1.7.9.6. 노드 풀 확장
링크 복사

  1. oc scale 명령을 사용하여 노드 풀을 수동으로 확장할 수 있습니다. 

    NODEPOOL_NAME=${CLUSTER_NAME}-work
NODEPOOL_REPLICAS=5

oc scale nodepool/$NODEPOOL_NAME --namespace clusters --replicas=$NODEPOOL_REPLICAS
    Copy to Clipboard Toggle word wrap

  2. 잠시 후 다음 명령을 입력하여 노드 풀의 상태를 확인합니다. 

    oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME                  STATUS   ROLES    AGE     VERSION
example-9jvnf         Ready    worker   97s     v1.27.4+18eadca
example-n6prw         Ready    worker   116m    v1.27.4+18eadca
example-nc6g4         Ready    worker   117m    v1.27.4+18eadca
example-thp29         Ready    worker   4m17s   v1.27.4+18eadca
example-twxns         Ready    worker   88s     v1.27.4+18eadca
    Copy to Clipboard Toggle word wrap
1.7.9.6.1. 노드 풀 추가
링크 복사

이름, 복제본 수 및 메모리 및 CPU 요구 사항과 같은 추가 정보를 지정하여 호스팅된 클러스터에 대한 노드 풀을 생성할 수 있습니다.

  1. 노드 풀을 생성하려면 다음 정보를 입력합니다. 이 예에서 노드 풀에는 VM에 더 많은 CPU가 할당됩니다. 

    export NODEPOOL_NAME=${CLUSTER_NAME}-extra-cpu
export WORKER_COUNT="2"
export MEM="6Gi"
export CPU="4"
export DISK="16"

hcp create nodepool kubevirt \
  --cluster-name $CLUSTER_NAME \
  --name $NODEPOOL_NAME \
  --node-count $WORKER_COUNT \
  --memory $MEM \
  --cores $CPU
  --root-volume-size $DISK
    Copy to Clipboard Toggle word wrap

  2. cluster 네임스페이스에 nodepool 리소스를 나열하여 노드 풀의 상태를 확인합니다. 

    oc get nodepools --namespace clusters
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME                      CLUSTER         DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
example                   example         5               5               False         False        4.14.0
example-extra-cpu         example         2                               False         False                  True              True             Minimum availability requires 2 replicas, current 0 available
    Copy to Clipboard Toggle word wrap

  3. 잠시 후 다음 명령을 입력하여 노드 풀의 상태를 확인할 수 있습니다. 

    oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME                      STATUS   ROLES    AGE     VERSION
example-9jvnf             Ready    worker   97s     v1.27.4+18eadca
example-n6prw             Ready    worker   116m    v1.27.4+18eadca
example-nc6g4             Ready    worker   117m    v1.27.4+18eadca
example-thp29             Ready    worker   4m17s   v1.27.4+18eadca
example-twxns             Ready    worker   88s     v1.27.4+18eadca
example-extra-cpu-zh9l5   Ready    worker   2m6s    v1.27.4+18eadca
example-extra-cpu-zr8mj   Ready    worker   102s    v1.27.4+18eadca
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 입력하여 노드 풀이 예상되는 상태에 있는지 확인합니다. 

    oc get nodepools --namespace clusters
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME                      CLUSTER         DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
example                   example         5               5               False         False        4.14.0
example-extra-cpu         example         2               2               False         False        4.14.0
Delete a HostedCluster
    Copy to Clipboard Toggle word wrap
1.7.9.6.1.1. 추가 리소스
링크 복사

1.7.9.7. OpenShift Virtualization에서 호스트된 클러스터 생성 확인
링크 복사

호스팅 클러스터가 성공적으로 생성되었는지 확인하려면 다음 단계를 완료합니다.

  1. 다음 명령을 입력하여 HostedCluster 리소스가 완료된 상태로 전환되었는지 확인합니다. 

    oc get --namespace clusters hostedclusters ${CLUSTER_NAME}
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAMESPACE   NAME      VERSION   KUBECONFIG                 PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
clusters    example   4.12.2    example-admin-kubeconfig   Completed   True        False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 호스팅 클러스터의 모든 클러스터 운영자가 온라인 상태인지 확인합니다. 

    hcp create kubeconfig --name $CLUSTER_NAME > $CLUSTER_NAME-kubeconfig
    Copy to Clipboard Toggle word wrap 
    oc get co --kubeconfig=$CLUSTER_NAME-kubeconfig
    Copy to Clipboard Toggle word wrap

    다음 예제 출력을 참조하십시오. 

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
console                                    4.12.2   True        False         False      2m38s
csi-snapshot-controller                    4.12.2   True        False         False      4m3s
dns                                        4.12.2   True        False         False      2m52s
image-registry                             4.12.2   True        False         False      2m8s
ingress                                    4.12.2   True        False         False      22m
kube-apiserver                             4.12.2   True        False         False      23m
kube-controller-manager                    4.12.2   True        False         False      23m
kube-scheduler                             4.12.2   True        False         False      23m
kube-storage-version-migrator              4.12.2   True        False         False      4m52s
monitoring                                 4.12.2   True        False         False      69s
network                                    4.12.2   True        False         False      4m3s
node-tuning                                4.12.2   True        False         False      2m22s
openshift-apiserver                        4.12.2   True        False         False      23m
openshift-controller-manager               4.12.2   True        False         False      23m
openshift-samples                          4.12.2   True        False         False      2m15s
operator-lifecycle-manager                 4.12.2   True        False         False      22m
operator-lifecycle-manager-catalog         4.12.2   True        False         False      23m
operator-lifecycle-manager-packageserver   4.12.2   True        False         False      23m
service-ca                                 4.12.2   True        False         False      4m41s
storage                                    4.12.2   True        False         False      4m43s
    Copy to Clipboard Toggle word wrap

고급 구성이 제공되지 않으면 KubeVirt 가상 머신(VM) 이미지, KubeVirt CSI 매핑 및 etcd 볼륨에 기본 스토리지 클래스가 사용됩니다.

1.7.9.8.1. KubeVirt CSI 스토리지 클래스 매핑
링크 복사

kubevirt CSI를 사용하면 ReadWriteMany 액세스 모드가 있는 모든 인프라 스토리지 클래스를 호스트된 클러스터에 노출할 수 있습니다. 인프라 클러스터 스토리지 클래스의 이러한 매핑은 hcp 명령줄 인터페이스 및 --infra-storage-class-mapping 인수를 사용하여 클러스터 생성 중에 구성할 수 있습니다.

인프라 스토리지 클래스를 호스팅된 스토리지 클래스에 매핑하려면 다음 예제를 참조하십시오. 이 예제에서는 infra-sc1 및 infra-sc2 라는 두 인프라 스토리지 클래스를 guest-sc1 및 guest-sc2 라는 호스팅 스토리지 클래스에 매핑하는 방법을 보여줍니다. --infra-storage-class-mapping 인수는 create 명령 내에서 여러 번 사용할 수 있습니다. 

export CLUSTER_NAME=example
export PULL_SECRET="$HOME/pull-secret"
export MEM="6Gi"
export CPU="2"
export WORKER_COUNT="2"

hcp create cluster kubevirt \
--name $CLUSTER_NAME \
--node-pool-replicas $WORKER_COUNT \
--pull-secret $PULL_SECRET \
--memory $MEM \
--cores $CPU \
--infra-storage-class-mapping=infra-sc1/guest-sc1 \
--infra-storage-class-mapping=infra-sc2/guest-sc2
Copy to Clipboard Toggle word wrap

호스트된 클러스터를 생성하면 guest-sc1 및 guest-sc2 스토리지 클래스가 호스팅된 클러스터 내에 표시됩니다. 이러한 스토리지 클래스 중 하나를 사용하는 호스트 클러스터 내에서 PVC를 생성하면 KubeVirt CSI는 클러스터 생성 중에 구성한 인프라 스토리지 클래스 매핑을 사용하여 해당 볼륨을 프로비저닝합니다.

참고: KubeVirt CSI는 RWX( ReadWriteMany ) 액세스를 수행할 수 있는 인프라 스토리지 클래스만 매핑을 지원합니다.

1.7.9.8.2. KubeVirt VM 루트 볼륨 구성
링크 복사

클러스터 생성 시 hcp 명령줄 인터페이스 및 --root-volume-storage-class 인수를 사용하여 KubeVirt VM 루트 볼륨을 호스팅하는 데 사용되는 스토리지 클래스를 구성할 수 있습니다. --root-volume-size 인수를 사용하여 볼륨 크기를 구성할 수 있습니다.

KubeVirt VM의 사용자 정의 스토리지 클래스 및 볼륨 크기를 설정하려면 다음 예제를 참조하십시오. 이 예에서 결과는 ocs-storagecluster-ceph-rdb 스토리지 클래스에서 호스팅하는 64Gi PVC에서 호스팅되는 VM이 있는 호스팅 클러스터입니다. 

export CLUSTER_NAME=example
export PULL_SECRET="$HOME/pull-secret"
export MEM="6Gi"
export CPU="2"
export WORKER_COUNT="2"

hcp create cluster kubevirt \
--name $CLUSTER_NAME \
--node-pool-replicas $WORKER_COUNT \
--pull-secret $PULL_SECRET \
--memory $MEM \
--cores $CPU \
--root-volume-storage-class ocs-storagecluster-ceph-rbd \
--root-volume-size 64
Copy to Clipboard Toggle word wrap
1.7.9.8.3. KubeVirt VM 이미지 캐싱 활성화
링크 복사

kubevirt 이미지 캐싱은 클러스터 시작 시간과 스토리지 사용률을 모두 최적화하는 데 사용할 수 있는 고급 기능입니다. 이 기능을 사용하려면 스마트 복제 및 ReadWriteMany 액세스 모드가 가능한 스토리지 클래스를 사용해야 합니다. 스마트 복제에 대한 자세한 내용은 스마트 복제 를 사용하여 데이터 볼륨 복제를 참조하십시오.

이미지 캐싱은 다음과 같이 작동합니다.

  1. VM 이미지는 호스팅된 클러스터와 연결된 PVC로 가져옵니다.
  2. 해당 PVC의 고유한 복제본은 클러스터에 작업자 노드로 추가되는 모든 KubeVirt VM에 대해 생성됩니다.

이미지 캐싱은 단일 이미지 가져오기만 요구하여 VM 시작 시간을 줄입니다. 스토리지 클래스가 COW(Copy-On-Write) 복제를 지원하는 경우 전체 클러스터 스토리지 사용량을 추가로 줄일 수 있습니다.

이미지 캐싱을 활성화하려면 다음 예와 같이 hcp 명령줄 인터페이스와 --root-volume-cache-strategy=PVC 인수를 사용합니다. 

export CLUSTER_NAME=example
export PULL_SECRET="$HOME/pull-secret"
export MEM="6Gi"
export CPU="2"
export WORKER_COUNT="2"

hcp create cluster kubevirt \
--name $CLUSTER_NAME \
--node-pool-replicas $WORKER_COUNT \
--pull-secret $PULL_SECRET \
--memory $MEM \
--cores $CPU \
--root-volume-cache-strategy=PVC
Copy to Clipboard Toggle word wrap
1.7.9.8.4. etcd 스토리지 구성
링크 복사

클러스터 생성 시 hcp 명령줄 인터페이스 및 --etcd-storage-class 인수를 사용하여 etcd 데이터를 호스팅하는 데 사용되는 스토리지 클래스를 구성할 수 있습니다. --etcd-storage-class 인수를 제공하지 않으면 기본 스토리지 클래스가 사용됩니다.

etcd의 스토리지 클래스를 구성하려면 다음 예제를 참조하십시오. 

export CLUSTER_NAME=example
export PULL_SECRET="$HOME/pull-secret"
export MEM="6Gi"
export CPU="2"
export WORKER_COUNT="2"
export ETCD_STORAGE="lvm-storageclass"

hcp create cluster kubevirt \
--name $CLUSTER_NAME \
--node-pool-replicas $WORKER_COUNT \
--pull-secret $PULL_SECRET \
--memory $MEM \
--cores $CPU \
--etcd-storage-class=${ETCD_STORAGE}
Copy to Clipboard Toggle word wrap
1.7.9.8.4.1. 추가 리소스
링크 복사

1.7.9.9. OpenShift Virtualization에서 호스트된 클러스터 삭제
링크 복사

호스트 클러스터 및 관리 클러스터 리소스를 삭제하려면 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 다중 클러스터 엔진 Operator에서 관리되는 클러스터 리소스를 삭제합니다. 

    oc delete managedcluster <cluster_name>
    Copy to Clipboard Toggle word wrap

    여기서 cluster_name 은 클러스터의 이름입니다.

  2. 다음 명령을 실행하여 호스팅된 클러스터 및 해당 백엔드 리소스를 삭제합니다. 

    hcp destroy cluster kubevirt --name $CLUSTER_NAME
    Copy to Clipboard Toggle word wrap

    필요한 경우 이름을 바꿉니다.

1.7.10. 연결이 끊긴 환경에서 호스트된 컨트롤 플레인 구성
링크 복사

호스팅된 컨트롤 플레인의 컨텍스트에서 연결이 끊긴 환경은 인터넷에 연결되지 않고 호스팅된 컨트롤 플레인을 기반으로 사용하는 OpenShift Container Platform 배포입니다.

기술 프리뷰: IPv4 또는 IPv6 네트워크를 사용하여 베어 메탈 플랫폼의 연결이 끊긴 환경에 호스팅된 컨트롤 플레인을 배포할 수 있습니다. 또한 연결이 끊긴 환경의 호스팅 컨트롤 플레인은 듀얼 스택 네트워크에서 기술 프리뷰 기능으로 사용할 수 있습니다. Red Hat OpenShift Virtualization 플랫폼을 사용하는 경우 연결이 끊긴 환경에서 호스팅되는 컨트롤 플레인을 기술 프리뷰 기능으로만 사용할 수 있습니다.

1.7.10.1. 연결이 끊긴 환경 아키텍처
링크 복사

베어 메탈에서 호스팅되는 컨트롤 플레인을 프로비저닝할 때 에이전트 플랫폼을 사용합니다. 에이전트 플랫폼과 다중 클러스터 엔진 Operator가 함께 작동하여 연결이 끊긴 배포를 활성화합니다. 에이전트 플랫폼은 중앙 인프라 관리 서비스를 사용하여 호스트된 클러스터에 작업자 노드를 추가합니다. 중앙 인프라 관리 서비스에 대한 소개는 중앙 인프라 관리 서비스 활성화를 참조하십시오.

다음 다이어그램은 연결이 끊긴 환경의 예제 아키텍처를 보여줍니다.

Disconnected architecture diagram

  1. 연결이 끊긴 배포가 작동하는지 확인하기 위해 TLS 지원, 웹 서버 및 DNS를 사용하여 레지스트리 인증서 배포를 포함한 인프라 서비스를 구성합니다.

  2. openshift-config 네임스페이스에 구성 맵을 생성합니다. 이 예에서 구성 맵의 이름은 registry-config 입니다. 구성 맵의 내용은 레지스트리 CA 인증서입니다. 구성 맵의 data 필드에는 다음 키와 값이 포함되어야 합니다.

    • 키: < registry_dns_domain_name>..<port > (예: registry.hypershiftdomain.lab..5000: ). 포트를 지정할 때 레지스트리 DNS 도메인 이름 뒤에 .. 를 배치해야 합니다.
    • value: 인증서 콘텐츠

    구성 맵 생성에 대한 자세한 내용은 IPv4 네트워크의 TLS 인증서 구성을 참조하십시오.

  3. images.config.openshift.io 사용자 지정 리소스에 name: registry-config 의 값을 사용하여 additionalTrustedCA 필드를 추가합니다.

  4. multicluster-engine 네임스페이스에 구성 맵을 생성합니다. 다음 샘플 구성을 참조하십시오. 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-registries
  namespace: multicluster-engine
  labels:
    app: assisted-service
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    ...
    ...
    -----END CERTIFICATE-----
  registries.conf: |
    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/openshift4"
    mirror-by-digest-only = true

    [[registry.mirror]]
      location = "registry.ocp-edge-cluster-0.qe.lab.redhat.com:5000/openshift4"

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/rhacm2"
    mirror-by-digest-only = true
...
...
    Copy to Clipboard Toggle word wrap
  5. 다중 클러스터 엔진 Operator 네임스페이스에서 Agent 및 hypershift-addon 애드온을 둘 다 활성화하는 multiclusterengine CR을 생성합니다. 다중 클러스터 엔진 Operator 네임스페이스에는 연결이 끊긴 배포에서 동작을 수정하려면 구성 맵이 포함되어야 합니다. 네임스페이스에는 multicluster-engine,assisted-service, hypershift-addon-manager Pod도 포함되어 있습니다.

  6. 다음 구성 요소를 포함하는 호스팅된 클러스터를 배포하는 데 필요한 오브젝트를 생성합니다.

    • 보안: 시크릿에는 풀 시크릿, SSH 키 및 etcd 암호화 키가 포함됩니다.
    • 구성 맵: 구성 맵에는 프라이빗 레지스트리의 CA 인증서가 포함되어 있습니다.
    • HostedCluster 리소스: HostedCluster 리소스는 호스팅된 클러스터에 대한 구성을 정의합니다.
    • NodePool 리소스: NodePool 리소스는 데이터 플레인에 사용할 머신을 참조하는 노드 풀을 식별합니다.
  7. 호스팅된 클러스터 오브젝트를 생성하면 HyperShift Operator에서 컨트롤 플레인 Pod를 수용하도록 HostedControlPlane 네임스페이스를 설정합니다. 네임스페이스는 에이전트, 베어 메탈 호스트(BMH) 및 InfraEnv 리소스와 같은 구성 요소도 호스팅합니다. 나중에 InfraEnv 리소스를 생성하고 ISO 생성 후 BMC(Baseboard Management Controller) 인증 정보가 포함된 BMH 및 해당 시크릿을 생성합니다.
  8. openshift-machine-api 네임스페이스의 Metal3 Operator는 새 BMH를 검사합니다. 그런 다음 Metal3 Operator는 다중 클러스터 엔진 Operator 네임스페이스에서 AgentServiceConfig CR을 통해 지정된 구성된 LiveISO 및 RootFS 값을 사용하여 BMC에 연결을 시도합니다.
  9. 호스팅된 클러스터 오브젝트를 생성한 후 HyperShift Operator는 HostedControlPlane 네임스페이스에 컨트롤 플레인 Pod를 생성합니다. HostedControlPlane 네임스페이스는 에이전트, 베어 메탈 호스트 및 InfraEnv 리소스와 같은 구성 요소도 호스팅합니다.
  10. InfraEnv 리소스를 만듭니다. ISO 이미지를 생성한 후 베어 메탈 호스트와 BMC(Baseboard Management Controller) 인증 정보가 포함된 시크릿을 생성합니다. openshift-machine-api 네임스페이스의 Metal3 Operator는 새 베어 메탈 호스트를 검사합니다.
  11. Metal3 Operator를 사용하여 BMC를 연결하고 시작하려면 다중 클러스터 엔진 Operator 네임스페이스의 AgentServiceConfig CR을 통해 LiveISO 및 RootFS 값을 지정합니다.
  12. HostedCluster 리소스의 작업자 노드가 준비되면 에이전트 컨테이너가 자동으로 시작됩니다.
  13. NodePool 리소스를 HostedCluster 리소스의 작업자 노드 수로 스케일링합니다.
  14. 배포 프로세스가 완료될 때까지 몇 분 정도 기다립니다.

1.7.10.2. 사전 요구 사항
링크 복사

연결이 끊긴 환경에서 호스팅되는 컨트롤 플레인을 구성하려면 다음 사전 요구 사항을 충족해야 합니다.

  • cpu: 제공된 CPU 수에 따라 동시에 실행할 수 있는 호스트 클러스터 수가 결정됩니다. 일반적으로 노드 3개당 각 노드에 16개의 CPU를 사용합니다. 최소 개발의 경우 노드 3개에 각 노드에 12개의 CPU를 사용할 수 있습니다.
  • memory: 호스트할 수 있는 호스트 클러스터 수에 영향을 미칩니다. 각 노드에 48GB의 RAM을 사용합니다. 최소한의 개발의 경우 18GB의 RAM이면 충분합니다.

  • 스토리지: 다중 클러스터 엔진 Operator에 SSD 스토리지를 사용합니다.

    • 관리 클러스터: 250GB.
    • 레지스트리: 필요한 레지스트리 스토리지는 호스팅되는 릴리스, 운영자 및 이미지 수에 따라 다릅니다. 500GB가 필요할 수 있으며, 호스트 클러스터를 호스팅하는 디스크와 별도로 필요할 수 있습니다.
    • 웹 서버: 필요한 웹 서버 스토리지는 호스팅되는 ISO 및 이미지 수에 따라 다릅니다. 500GB가 필요할 수 있습니다.

  • 프로덕션: 프로덕션 환경의 경우 관리 클러스터, 레지스트리 및 웹 서버를 다른 디스크에서 분리합니다. 프로덕션에 대한 다음 예제 구성을 참조하십시오.

    • 레지스트리: 2TB
    • 관리 클러스터: 500GB
    • 웹 서버: 2TB

1.7.10.3. OpenShift Container Platform 릴리스 이미지 다이제스트 추출
링크 복사

태그된 이미지를 사용하여 OpenShift Container Platform 릴리스 이미지 다이제스트를 추출할 수 있습니다. 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 이미지 다이제스트를 가져옵니다. 

    oc adm release info <tagged_openshift_release_image> | grep "Pull From"
    Copy to Clipboard Toggle word wrap

    < tagged_openshift_release_image >를 지원되는 OpenShift Container Platform 버전에 대한 태그된 이미지로 바꿉니다(예: quay.io/openshift-release-dev/ocp-release:4.14.0-x8_64 ).

    다음 예제 출력을 참조하십시오. 

    Pull From: quay.io/openshift-release-dev/ocp-release@sha256:69d1292f64a2b67227c5592c1a7d499c7d00376e498634ff8e1946bc9ccdddfe
    Copy to Clipboard Toggle word wrap

    이미지 태그 및 다이제스트에 대한 자세한 내용은 OpenShift Container Platform 설명서의 이미지 스트림 참조 에서 참조하십시오.

1.7.10.3.1. 추가 리소스
링크 복사

1.7.10.4. 연결이 끊긴 환경에서 사용자 워크로드 모니터링
링크 복사

하이퍼shift-addon 관리 클러스터 애드온은 HyperShift Operator에서 --enable-uwm-telemetry-remote-write 옵션을 활성화합니다. 이 옵션을 활성화하면 사용자 워크로드 모니터링이 활성화되고 컨트롤 플레인에서 Telemetry 메트릭을 원격으로 작성할 수 있습니다.

인터넷에 연결되지 않은 OpenShift Container Platform 클러스터에 다중 클러스터 엔진 Operator를 설치한 경우 다음 명령을 입력하여 HyperShift Operator의 사용자 워크로드 모니터링 기능을 실행하려고 하면 오류와 함께 기능이 실패합니다. 

oc get events -n hypershift
Copy to Clipboard Toggle word wrap

오류는 다음과 같을 수 있습니다. 

LAST SEEN   TYPE      REASON           OBJECT                MESSAGE
4m46s       Warning   ReconcileError   deployment/operator   Failed to ensure UWM telemetry remote write: cannot get telemeter client secret: Secret "telemeter-client" not found
Copy to Clipboard Toggle word wrap

이 오류를 방지하려면 local-cluster 네임스페이스에 구성 맵을 생성하여 사용자 워크로드 모니터링 옵션을 비활성화해야 합니다. 애드온을 활성화하기 전이나 후에 구성 맵을 생성할 수 있습니다. 애드온 에이전트는 HyperShift Operator를 재구성합니다.

다음 구성 맵을 생성합니다. 

kind: ConfigMap
apiVersion: v1
metadata:
  name: hypershift-operator-install-flags
  namespace: local-cluster
data:
  installFlagsToAdd: ""
  installFlagsToRemove: "--enable-uwm-telemetry-remote-write"
Copy to Clipboard Toggle word wrap
1.7.10.4.1. 호스트된 컨트롤 플레인 기능의 상태 확인
링크 복사

다중 클러스터 엔진 Operator 2.4부터 호스팅되는 컨트롤 플레인 기능은 기본적으로 활성화됩니다.

  1. 기능이 비활성화되고 이를 활성화하려면 다음 명령을 입력합니다. multiclusterengine 을 다중 클러스터 엔진 Operator 인스턴스의 이름으로 교체합니다. 

    oc patch mce <multiclusterengine> --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}'
    Copy to Clipboard Toggle word wrap

    기능을 활성화하면 hypershift-addon 관리 클러스터 애드온이 로컬 클러스터 관리 클러스터에 설치되고 애드온 에이전트는 다중 클러스터 엔진 Operator 허브 클러스터에 HyperShift Operator를 설치합니다.

  2. 다음 명령을 입력하여 hypershift-addon 관리 클러스터 애드온이 설치되었는지 확인합니다. 

    oc get managedclusteraddons -n local-cluster hypershift-addon
    Copy to Clipboard Toggle word wrap

  3. 결과 출력을 확인합니다. 

    NAME               AVAILABLE   DEGRADED   PROGRESSING
hypershift-addon   True        False
    Copy to Clipboard Toggle word wrap

  4. 이 프로세스 중에 시간 초과를 방지하려면 다음 명령을 입력합니다. 

    oc wait --for=condition=Degraded=True managedclusteraddons/hypershift-addon -n local-cluster --timeout=5m
    Copy to Clipboard Toggle word wrap 
    oc wait --for=condition=Available=True managedclusteraddons/hypershift-addon -n local-cluster --timeout=5m
    Copy to Clipboard Toggle word wrap

    프로세스가 완료되면 hypershift-addon 관리 클러스터 애드온 및 HyperShift Operator가 설치되고 로컬 클러스터 관리 클러스터를 호스팅 및 관리할 수 있습니다.

기본적으로 hypershift-addon 관리 클러스터 애드온에 노드 배치 기본 설정은 지정되지 않습니다. 인프라 노드에서 애드온을 실행하는 것이 좋습니다. 이렇게 하면 서브스크립션 수와 별도의 유지 관리 및 관리 작업에 대해 청구 비용이 발생하지 않도록 할 수 있습니다.

  1. hub 클러스터에 로그인합니다.

  2. 다음 명령을 입력하여 편집할 hypershift-addon-deploy-config 배포 구성 사양을 엽니다. 

    oc edit addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine
    Copy to Clipboard Toggle word wrap

  3. 다음 예와 같이 nodePlacement 필드를 사양에 추가합니다. 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: AddOnDeploymentConfig
metadata:
  name: hypershift-addon-deploy-config
  namespace: multicluster-engine
spec:
  nodePlacement:
    nodeSelector:
      node-role.kubernetes.io/infra: ""
    tolerations:
    - effect: NoSchedule
      key: node-role.kubernetes.io/infra
      operator: Exists
    Copy to Clipboard Toggle word wrap
  4. 변경 사항을 저장합니다. 하이퍼shift-addon 관리 클러스터 애드온은 신규 및 기존 관리 클러스터를 위해 인프라 노드에 배포됩니다.

1.7.10.5. IPv4 네트워크에서 호스트된 컨트롤 플레인 구성
링크 복사

IPv4는 연결이 끊긴 환경에서 호스팅된 컨트롤 플레인을 배포하는 가장 간단한 네트워크 구성 중 하나입니다. IPv4 범위에는 IPv6 또는 듀얼 스택 설정보다 적은 수의 외부 구성 요소가 필요합니다.

IPv4 네트워크에서 호스팅되는 컨트롤 플레인을 구성하는 프로세스에는 다음 단계가 포함되며, 다음 섹션에 자세히 설명되어 있습니다.

  1. IPv4 네트워크에 대한 하이퍼바이저 구성
  2. IPv4 네트워크에 대한 DNS 구성
  3. IPv4 네트워크의 레지스트리 배포
  4. IPv4 네트워크의 관리 클러스터 설정
  5. IPv4 네트워크에 대한 웹 서버 구성
  6. IPv4 네트워크의 이미지 미러링 구성
  7. IPv4 네트워크용 다중 클러스터 엔진 Operator 배포
  8. IPv4 네트워크에 대한 TLS 인증서 구성
  9. IPv4 네트워크용 호스트 클러스터 배포
  10. IPv4 네트워크에 대한 배포 완료
1.7.10.5.1. IPv4 네트워크에 대한 하이퍼바이저 구성
링크 복사

다음 정보는 가상 머신 환경에만 적용됩니다.

  1. 가상 OpenShift Container Platform 관리 클러스터를 배포하려면 다음 명령을 입력하여 필요한 패키지에 액세스합니다. 

    sudo dnf install dnsmasq radvd vim golang podman bind-utils net-tools httpd-tools tree htop strace tmux -y
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 Podman 서비스를 활성화하고 시작합니다. 

    systemctl enable --now podman
    Copy to Clipboard Toggle word wrap

  3. kcli 를 사용하여 OpenShift Container Platform 관리 클러스터 및 기타 가상 구성 요소를 배포하려면 다음 명령을 입력하여 하이퍼바이저를 설치 및 구성합니다. 

    sudo yum -y install libvirt libvirt-daemon-driver-qemu qemu-kvm
    Copy to Clipboard Toggle word wrap 
    sudo usermod -aG qemu,libvirt $(id -un)
    Copy to Clipboard Toggle word wrap 
    sudo newgrp libvirt
    Copy to Clipboard Toggle word wrap 
    sudo systemctl enable --now libvirtd
    Copy to Clipboard Toggle word wrap 
    sudo dnf -y copr enable karmab/kcli
    Copy to Clipboard Toggle word wrap 
    sudo dnf -y install kcli
    Copy to Clipboard Toggle word wrap 
    sudo kcli create pool -p /var/lib/libvirt/images default
    Copy to Clipboard Toggle word wrap 
    kcli create host kvm -H 127.0.0.1 local
    Copy to Clipboard Toggle word wrap 
    sudo setfacl -m u:$(id -un):rwx /var/lib/libvirt/images
    Copy to Clipboard Toggle word wrap 
    kcli create network  -c 192.168.122.0/24 default
    Copy to Clipboard Toggle word wrap
1.7.10.5.1.2. 네트워크 관리자 디스패처 활성화
링크 복사

  1. 네트워크 관리자 디스패처를 활성화하여 가상 머신이 필요한 도메인, 경로 및 레지스트리를 확인할 수 있는지 확인합니다. 네트워크 관리자 디스패처를 활성화하려면 /etc/NetworkManager/dispatcher.d/ 디렉터리에서 다음 콘텐츠가 포함된 forcedns 라는 스크립트를 생성하여 환경에 맞게 값을 교체하십시오. 

    #!/bin/bash

export IP="192.168.126.1"
    1 
    
export BASE_RESOLV_CONF="/run/NetworkManager/resolv.conf"

if ! [[ `grep -q "$IP" /etc/resolv.conf` ]]; then
export TMP_FILE=$(mktemp /etc/forcedns_resolv.conf.XXXXXX)
cp $BASE_RESOLV_CONF $TMP_FILE
chmod --reference=$BASE_RESOLV_CONF $TMP_FILE
sed -i -e "s/dns.base.domain.name//" -e "s/search /& dns.base.domain.name /" -e "0,/nameserver/s/nameserver/& $IP\n&/" $TMP_FILE
    2 
    
mv $TMP_FILE /etc/resolv.conf
fi
echo "ok"
    Copy to Clipboard Toggle word wrap
    1
    OpenShift Container Platform 관리 클러스터를 호스팅하는 하이퍼바이저 인터페이스의 IP 주소를 가리키도록 IP 변수를 수정합니다.
    2
    dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

  2. 파일을 생성한 후 다음 명령을 입력하여 권한을 추가합니다. 

    chmod 755 /etc/NetworkManager/dispatcher.d/forcedns
    Copy to Clipboard Toggle word wrap
  3. 스크립트를 실행하고 출력이 ok 를 반환하는지 확인합니다.
1.7.10.5.1.3. BMC 액세스 구성
링크 복사

  1. 가상 머신의 BMC(Baseboard Management Controller)를 시뮬레이션하도록 ksushy 를 구성합니다. 다음 명령을 입력합니다. 

    sudo dnf install python3-pyOpenSSL.noarch python3-cherrypy -y
    Copy to Clipboard Toggle word wrap 
    kcli create sushy-service --ssl --port 9000
    Copy to Clipboard Toggle word wrap 
    sudo systemctl daemon-reload
    Copy to Clipboard Toggle word wrap 
    systemctl enable --now ksushy
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 서비스가 올바르게 작동하는지 테스트합니다. 

    systemctl status ksushy
    Copy to Clipboard Toggle word wrap
1.7.10.5.1.4. 연결을 허용하도록 하이퍼바이저 시스템 구성
링크 복사

개발 환경에서 작업하는 경우 환경 내에서 다양한 가상 네트워크를 통한 다양한 유형의 연결을 허용하도록 하이퍼바이저 시스템을 구성합니다.

참고: 프로덕션 환경에서 작업하는 경우 firewalld 서비스에 대한 적절한 규칙을 설정하고 안전한 환경을 유지 관리하도록 SELinux 정책을 구성해야 합니다.

  • SELinux의 경우 다음 명령을 입력합니다. 

    sed -i s/^SELINUX=.*$/SELINUX=permissive/ /etc/selinux/config; setenforce 0
    Copy to Clipboard Toggle word wrap

  • firewalld 의 경우 다음 명령을 입력합니다. 

    systemctl disable --now firewalld
    Copy to Clipboard Toggle word wrap

  • libvirtd 의 경우 다음 명령을 입력합니다. 

    systemctl restart libvirtd
    Copy to Clipboard Toggle word wrap 
    systemctl enable --now libvirtd
    Copy to Clipboard Toggle word wrap

다음으로 환경에 맞게 DNS를 구성합니다.

1.7.10.5.1.5. 추가 리소스
링크 복사
1.7.10.5.2. IPv4 네트워크에 대한 DNS 구성
링크 복사

이 단계는 가상 및 베어 메탈 환경 모두에서 연결이 끊긴 환경과 연결된 환경 모두에 필요합니다. 가상 환경과 베어 메탈 환경 간의 주요 차이점은 리소스를 구성하는 위치에 있습니다. 베어 메탈 환경에서는 dnsmasq 와 같은 경량 솔루션이 아닌 바인딩과 같은 솔루션을 사용합니다.

다음으로 레지스트리를 배포합니다.

1.7.10.5.3. IPv4 네트워크의 레지스트리 배포
링크 복사

개발 환경의 경우 Podman 컨테이너를 사용하여 소규모 자체 호스팅 레지스트리를 배포합니다. 프로덕션 환경의 경우 Red Hat Quay, Nexus 또는 Artifactory와 같은 엔터프라이즈 호스팅 레지스트리를 사용합니다.

Podman을 사용하여 작은 레지스트리를 배포하려면 다음 단계를 완료합니다.

  1. 권한 있는 사용자로 ${HOME} 디렉터리에 액세스하고 다음 스크립트를 생성합니다. 

    #!/usr/bin/env bash

set -euo pipefail

PRIMARY_NIC=$(ls -1 /sys/class/net | grep -v podman | head -1)
export PATH=/root/bin:$PATH
export PULL_SECRET="/root/baremetal/hub/openshift_pull.json"
    1 
    

if [[ ! -f $PULL_SECRET ]];then
  echo "Pull Secret not found, exiting..."
  exit 1
fi

dnf -y install podman httpd httpd-tools jq skopeo libseccomp-devel
export IP=$(ip -o addr show $PRIMARY_NIC | head -1 | awk '{print $4}' | cut -d'/' -f1)
REGISTRY_NAME=registry.$(hostname --long)
REGISTRY_USER=dummy
REGISTRY_PASSWORD=dummy
KEY=$(echo -n $REGISTRY_USER:$REGISTRY_PASSWORD | base64)
echo "{\"auths\": {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\", \"email\": \"sample-email@domain.ltd\"}}}" > /root/disconnected_pull.json
mv ${PULL_SECRET} /root/openshift_pull.json.old
jq ".auths += {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\",\"email\": \"sample-email@domain.ltd\"}}" < /root/openshift_pull.json.old > $PULL_SECRET
mkdir -p /opt/registry/{auth,certs,data,conf}
cat <<EOF > /opt/registry/conf/config.yml
version: 0.1
log:
  fields:
    service: registry
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry
  delete:
    enabled: true
http:
  addr: :5000
  headers:
    X-Content-Type-Options: [nosniff]
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3
compatibility:
  schema1:
    enabled: true
EOF
openssl req -newkey rsa:4096 -nodes -sha256 -keyout /opt/registry/certs/domain.key -x509 -days 3650 -out /opt/registry/certs/domain.crt -subj "/C=US/ST=Madrid/L=San Bernardo/O=Karmalabs/OU=Guitar/CN=$REGISTRY_NAME" -addext "subjectAltName=DNS:$REGISTRY_NAME"
cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract
htpasswd -bBc /opt/registry/auth/htpasswd $REGISTRY_USER $REGISTRY_PASSWORD
podman create --name registry --net host --security-opt label=disable --replace -v /opt/registry/data:/var/lib/registry:z -v /opt/registry/auth:/auth:z -v /opt/registry/conf/config.yml:/etc/docker/registry/config.yml -e "REGISTRY_AUTH=htpasswd" -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry" -e "REGISTRY_HTTP_SECRET=ALongRandomSecretForRegistry" -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd -v /opt/registry/certs:/certs:z -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key docker.io/library/registry:latest
[ "$?" == "0" ] || !!
systemctl enable --now registry
    Copy to Clipboard Toggle word wrap
    1
    PULL_SECRET 위치를 설정에 적합한 위치로 교체합니다.

  2. 스크립트 파일 이름을 registry.sh 로 지정하고 저장합니다. 스크립트를 실행하면 다음 정보를 가져옵니다.

    • 하이퍼바이저 호스트 이름을 기반으로 하는 레지스트리 이름
    • 필요한 인증 정보 및 사용자 액세스 세부 정보

  3. 다음과 같이 실행 플래그를 추가하여 권한을 조정합니다. 

    chmod u+x ${HOME}/registry.sh
    Copy to Clipboard Toggle word wrap

  4. 매개변수 없이 스크립트를 실행하려면 다음 명령을 입력합니다. 

    ${HOME}/registry.sh
    Copy to Clipboard Toggle word wrap

    스크립트가 서버를 시작합니다.

  5. 스크립트는 관리 목적으로 systemd 서비스를 사용합니다. 스크립트를 관리해야 하는 경우 다음 명령을 사용할 수 있습니다. 

    systemctl status
    Copy to Clipboard Toggle word wrap 
    systemctl start
    Copy to Clipboard Toggle word wrap 
    systemctl stop
    Copy to Clipboard Toggle word wrap

레지스트리의 루트 폴더는 /opt/registry 디렉터리에 있으며 다음 하위 디렉터리가 포함되어 있습니다.

  • 인증서에는 TLS 인증서가 포함되어 있습니다.
  • auth 에는 인증 정보가 포함됩니다.
  • 데이터에 는 레지스트리 이미지가 포함되어 있습니다.
  • conf 에는 레지스트리 구성이 포함되어 있습니다.
1.7.10.5.4. IPv4 네트워크의 관리 클러스터 설정
링크 복사

OpenShift Container Platform 관리 클러스터를 설정하려면 dev-scripts를 사용하거나 가상 머신을 기반으로 하는 경우 kcli 툴을 사용할 수 있습니다. 다음 지침은 kcli 툴에 따라 다릅니다.

  1. 하이퍼바이저에서 적절한 네트워크를 사용할 준비가 되었는지 확인합니다. 네트워크는 관리 및 호스팅 클러스터를 모두 호스팅합니다. 다음 kcli 명령을 입력합니다. 

    kcli create network -c 192.168.125.0/24 -P dhcp=false -P dns=false --domain dns.base.domain.name ipv4
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    • -c 는 네트워크의 CIDR을 지정합니다.
    • -P dhcp=false 는 DHCP를 비활성화하도록 네트워크를 구성하며, 구성한 dnsmasq 에서 처리합니다.
    • -P dns=false 는 DNS를 비활성화하도록 네트워크를 구성하며, 구성한 dnsmasq 에서도 처리합니다.
    • --domain 은 검색할 도메인을 설정합니다.
    • DNS.base.domain.name 은 DNS 기본 도메인 이름입니다.
    • ipv4 는 생성 중인 네트워크의 이름입니다.

  2. 네트워크가 생성되면 다음 출력을 검토합니다. 

    [root@hypershiftbm ~]# kcli list network
Listing Networks...
+---------+--------+---------------------+-------+------------------+------+
| Network |  Type  |         Cidr        |  Dhcp |      Domain      | Mode |
+---------+--------+---------------------+-------+------------------+------+
| default | routed |   192.168.122.0/24  |  True |     default      | nat  |
| ipv4    | routed |   192.168.125.0/24  | False | dns.base.domain.name | nat  |
| ipv6    | routed | 2620:52:0:1306::/64 | False | dns.base.domain.name | nat  |
+---------+--------+---------------------+-------+------------------+------+
    Copy to Clipboard Toggle word wrap 
    [root@hypershiftbm ~]# kcli info network ipv4
Providing information about network ipv4...
cidr: 192.168.125.0/24
dhcp: false
domain: dns.base.domain.name
mode: nat
plan: kvirt
type: routed
    Copy to Clipboard Toggle word wrap

  3. OpenShift Container Platform 관리 클러스터를 배포할 수 있도록 풀 시크릿 및 kcli 계획 파일이 있는지 확인합니다.

    1. 풀 시크릿이 kcli 계획과 동일한 폴더에 있고 풀 시크릿 파일의 이름이 openshift_pull.json 인지 확인합니다.
    2. mgmt-compact-hub-ipv4.yaml 파일에서 OpenShift Container Platform 정의가 포함된 kcli 계획을 추가합니다. 해당 환경과 일치하도록 파일 콘텐츠를 업데이트해야 합니다. 
    plan: hub-ipv4
force: true
version: nightly
tag: "4.14.0-0.nightly-2023-08-29-102237"
cluster: "hub-ipv4"
domain: dns.base.domain.name
api_ip: 192.168.125.10
ingress_ip: 192.168.125.11
disconnected_url: registry.dns.base.domain.name:5000
disconnected_update: true
disconnected_user: dummy
disconnected_password: dummy
disconnected_operators_version: v4.14
disconnected_operators:
- name: metallb-operator
- name: lvms-operator
  channels:
  - name: stable-4.13
disconnected_extra_images:
- quay.io/user-name/trbsht:latest
- quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3
- registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
dualstack: false
disk_size: 200
extra_disks: [200]
memory: 48000
numcpus: 16
ctlplanes: 3
workers: 0
manifests: extra-manifests
metal3: true
network: ipv4
users_dev: developer
users_devpassword: developer
users_admin: admin
users_adminpassword: admin
metallb_pool: ipv4-virtual-network
metallb_ranges:
- 192.168.125.150-192.168.125.190
metallb_autoassign: true
apps:
- users
- lvms-operator
- metallb-operator
vmrules:
- hub-bootstrap:
    nets:
    - name: ipv4
      mac: aa:aa:aa:aa:02:10
- hub-ctlplane-0:
    nets:
    - name: ipv4
      mac: aa:aa:aa:aa:02:01
- hub-ctlplane-1:
    nets:
    - name: ipv4
      mac: aa:aa:aa:aa:02:02
- hub-ctlplane-2:
    nets:
    - name: ipv4
      mac: aa:aa:aa:aa:02:03
    Copy to Clipboard Toggle word wrap

  4. 관리 클러스터를 프로비저닝하려면 다음 명령을 입력합니다. 

    kcli create cluster openshift --pf mgmt-compact-hub-ipv4.yaml
    Copy to Clipboard Toggle word wrap
1.7.10.5.4.1. 추가 리소스
링크 복사
  • kcli 계획 파일의 매개변수에 대한 자세한 내용은 공식 kcli 문서의 parameters.yml 만들기 를 참조하십시오.
1.7.10.5.5. IPv4 네트워크에 대한 웹 서버 구성
링크 복사

호스트 클러스터로 배포 중인 OpenShift Container Platform 릴리스와 연결된 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 호스팅하도록 추가 웹 서버를 구성해야 합니다.

웹 서버를 구성하려면 다음 단계를 완료합니다.

  1. 다음 명령을 입력하여 사용할 OpenShift Container Platform 릴리스에서 openshift-install 바이너리를 추출합니다. 

    oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
    Copy to Clipboard Toggle word wrap

  2. 다음 스크립트를 실행합니다. 이 스크립트는 /opt/srv 디렉터리에 폴더를 생성합니다. 폴더에는 작업자 노드를 프로비저닝하는 RHCOS 이미지가 포함되어 있습니다. 

    #!/bin/bash

WEBSRV_FOLDER=/opt/srv
ROOTFS_IMG_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.pxe.rootfs.location')"
    1 
    
LIVE_ISO_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.iso.disk.location')"
    2 
    

mkdir -p ${WEBSRV_FOLDER}/images
curl -Lk ${ROOTFS_IMG_URL} -o ${WEBSRV_FOLDER}/images/${ROOTFS_IMG_URL##*/}
curl -Lk ${LIVE_ISO_URL} -o ${WEBSRV_FOLDER}/images/${LIVE_ISO_URL##*/}
chmod -R 755 ${WEBSRV_FOLDER}/*

## Run Webserver
podman ps --noheading | grep -q websrv-ai
if [[ $? == 0 ]];then
    echo "Launching Registry pod..."
    /usr/bin/podman run --name websrv-ai --net host -v /opt/srv:/usr/local/apache2/htdocs:z quay.io/alosadag/httpd:p8080
fi
    Copy to Clipboard Toggle word wrap
    1
    ROOTFS_IMG_URL 값은 OpenShift CI 릴리스 페이지에서 찾을 수 있습니다.
    2
    LIVE_ISO_URL 값은 OpenShift CI 릴리스 페이지에서 확인할 수 있습니다.

다운로드가 완료되면 컨테이너가 실행되어 웹 서버에서 이미지를 호스팅합니다. 컨테이너는 공식 HTTPd 이미지의 변형을 사용하여 IPv6 네트워크에서도 작업할 수 있습니다.

1.7.10.5.6. IPv4 네트워크의 이미지 미러링 구성
링크 복사

이미지 미러링은 registry.redhat.com 또는 quay.io 와 같은 외부 레지스트리에서 이미지를 가져와서 프라이빗 레지스트리에 저장하는 프로세스입니다.

1.7.10.5.6.1. 미러링 프로세스 완료
링크 복사

참고: 레지스트리 서버가 실행된 후 미러링 프로세스를 시작합니다.

다음 절차에서는 ImageSetConfiguration 오브젝트를 사용하는 바이너리인 oc-mirror 툴이 사용됩니다. 파일에서 다음 정보를 지정할 수 있습니다.

  • 미러링할 OpenShift Container Platform 버전입니다. 버전은 quay.io 에 있습니다.
  • 미러링할 추가 Operator입니다. 패키지를 개별적으로 선택합니다.
  • 리포지토리에 추가할 추가 이미지입니다.

이미지 미러링을 구성하려면 다음 단계를 완료합니다.

  1. 이미지를 푸시하려는 프라이빗 레지스트리와 미러링할 레지스트리를 사용하여 ${HOME}/.docker/config.json 파일이 업데이트되었는지 확인합니다.

  2. 다음 예제를 사용하여 미러링에 사용할 ImageSetConfiguration 오브젝트를 만듭니다. 환경에 맞게 필요에 따라 값을 바꿉니다. 

    apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
  registry:
    imageURL: registry.dns.base.domain.name:5000/openshift/release/metadata:latest
    1 
    
mirror:
  platform:
    channels:
    - name: candidate-4.14
      minVersion: 4.14.0-ec.1
      maxVersion: 4.14.0-ec.3
      type: ocp
    graph: true
  additionalImages:
  - name: quay.io/karmab/origin-keepalived-ipfailover:latest
  - name: quay.io/karmab/kubectl:latest
  - name: quay.io/karmab/haproxy:latest
  - name: quay.io/karmab/mdns-publisher:latest
  - name: quay.io/karmab/origin-coredns:latest
  - name: quay.io/karmab/curl:latest
  - name: quay.io/karmab/kcli:latest
  - name: quay.io/user-name/trbsht:latest
  - name: quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3
  - name: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14
    packages:
    - name: lvms-operator
    - name: local-storage-operator
    - name: odf-csi-addons-operator
    - name: odf-operator
    - name: mcg-operator
    - name: ocs-operator
    - name: metallb-operator
    - name: kubevirt-hyperconverged
    Copy to Clipboard Toggle word wrap
    1
    dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

  3. 다음 명령을 입력하여 미러링 프로세스를 시작합니다. 

    oc-mirror --source-skip-tls --config imagesetconfig.yaml docker://${REGISTRY}
    Copy to Clipboard Toggle word wrap

    미러링 프로세스가 완료되면 호스트 클러스터에 적용할 ICSP 및 카탈로그 소스가 포함된 oc-mirror-workspace/results-XXXXXX/ 라는 새 폴더가 있습니다.

  4. oc adm release mirror 명령을 사용하여 OpenShift Container Platform의 Nightly 또는 CI 버전을 미러링합니다. 다음 명령을 실행합니다. 

    REGISTRY=registry.$(hostname --long):5000

oc adm release mirror \
  --from=registry.ci.openshift.org/ocp/release:4.14.0-0.nightly-2023-08-29-102237 \
  --to=${REGISTRY}/openshift/release \
  --to-release-image=${REGISTRY}/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237
    Copy to Clipboard Toggle word wrap
  5. 연결이 끊긴 네트워크에 설치 단계에 따라 최신 다중 클러스터 엔진 Operator 이미지를 미러링합니다.
1.7.10.5.6.2. 관리 클러스터에 오브젝트 적용
링크 복사

미러링 프로세스가 완료되면 관리 클러스터에 두 개의 오브젝트를 적용해야 합니다.

  • Image Content Source Policies (ICSP) 또는 Image Digest 미러 세트(IDMS)
  • 카탈로그 소스

oc-mirror 툴을 사용하는 경우 출력 아티팩트는 oc-mirror-workspace/results-XXXXXX/ 이라는 폴더에 있습니다.

ICSP 또는 IDMS는 노드를 재시작하지 않고 각 노드에서 kubelet을 다시 시작하는 MachineConfig 변경 사항을 시작합니다. 노드가 READY 로 표시되면 새로 생성된 카탈로그 소스를 적용해야 합니다.

카탈로그 소스는 카탈로그 이미지 다운로드 및 처리와 같은 openshift-marketplace Operator에서 작업을 시작하여 해당 이미지에 포함된 모든 PackageManifest 를 검색합니다.

  1. 새 소스를 확인하려면 새 CatalogSource 를 소스로 사용하여 다음 명령을 실행합니다. 

    oc get packagemanifest
    Copy to Clipboard Toggle word wrap

  2. 아티팩트를 적용하려면 다음 단계를 완료합니다.

    1. 다음 명령을 입력하여 ICSP(ICSP) 또는 IDMS 아티팩트를 생성합니다. 

      oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
      Copy to Clipboard Toggle word wrap
    2. 노드가 준비될 때까지 기다린 다음 다음 명령을 입력합니다. 
    oc apply -f catalogSource-XXXXXXXX-index.yaml
    Copy to Clipboard Toggle word wrap

  3. OLM 카탈로그를 미러링하고 미러를 가리키도록 uchd 클러스터를 구성합니다.

    관리 (기본값) OLMCatalogPlacement 모드를 사용하면 관리 클러스터의 ICSP에서 재정의 정보를 사용하여 OLM 카탈로그에 사용되는 이미지 스트림이 자동으로 수정되지 않습니다.

    1. 원래 이름 및 태그를 사용하여 OLM 카탈로그가 내부 레지스트리에 올바르게 미러링된 경우 hypershift.openshift.io/olm-catalogs-is-registry-overrides 주석을 HostedCluster 리소스에 추가합니다. 형식은 "sr1=dr1,sr2=dr2" 입니다. 여기서 소스 레지스트리 문자열은 키이고 대상 레지스트리는 값입니다.

    2. OLM 카탈로그 이미지 스트림 메커니즘을 바이패스하려면 HostedCluster 리소스에서 다음 4개의 주석을 사용하여 OLM Operator 카탈로그에 사용할 4개의 이미지의 주소를 직접 지정합니다.

      • hypershift.openshift.io/certified-operators-catalog-image
      • hypershift.openshift.io/community-operators-catalog-image
      • hypershift.openshift.io/redhat-marketplace-catalog-image
      • hypershift.openshift.io/redhat-operators-catalog-image

      이 경우 이미지 스트림이 생성되지 않으며 Operator 업데이트를 가져오려면 내부 미러가 새로 고쳐질 때 주석 값을 업데이트해야 합니다.

    참고: 재정의 메커니즘이 필요한 경우 4개의 기본 카탈로그 소스에 대한 4개의 값이 모두 필요합니다.

1.7.10.5.6.3. 추가 리소스
링크 복사
1.7.10.5.7. IPv4 네트워크용 다중 클러스터 엔진 Operator 배포
링크 복사

다중 클러스터 엔진 Operator는 공급업체에 클러스터를 배포하는 데 중요한 역할을 합니다. Red Hat Advanced Cluster Management를 이미 설치한 경우 자동으로 설치되므로 다중 클러스터 엔진 Operator를 설치할 필요가 없습니다.

다중 클러스터 엔진 Operator가 설치되어 있지 않은 경우 다음 문서를 검토하여 사전 요구 사항 및 설치 단계를 이해하십시오.

1.7.10.5.7.1. AgentServiceConfig 리소스 배포
링크 복사

AgentServiceConfig 사용자 지정 리소스는 다중 클러스터 엔진 Operator의 일부인 지원 서비스 애드온의 필수 구성 요소입니다. 베어 메탈 클러스터 배포를 담당합니다. 애드온이 활성화되면 AgentServiceConfig 리소스를 배포하여 애드온을 구성합니다.

AgentServiceConfig 리소스를 구성하는 것 외에도 연결이 끊긴 환경에서 다중 클러스터 엔진 Operator가 제대로 작동하는지 확인하기 위해 추가 구성 맵을 포함해야 합니다.

  1. 배포를 사용자 지정하는 연결이 끊긴 세부 정보가 포함된 다음 구성 맵을 추가하여 사용자 정의 레지스트리를 구성합니다. 

    ---
apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-registries
  namespace: multicluster-engine
  labels:
    app: assisted-service
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
  registries.conf: |
    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/openshift4"
    mirror-by-digest-only = true

    [[registry.mirror]]
      location = "registry.dns.base.domain.name:5000/openshift4"
    1 
    

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/rhacm2"
    mirror-by-digest-only = true
    ...
    ...
    Copy to Clipboard Toggle word wrap
    1
    dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

    오브젝트에는 다음 두 개의 필드가 있습니다.

    • 사용자 정의 CA: 이 필드에는 배포의 다양한 프로세스에 로드되는 CA(인증 기관)가 포함되어 있습니다.
    • Registry: Registries.conf 필드에는 원래 소스 레지스트리가 아닌 미러 레지스트리에서 사용해야 하는 이미지 및 네임스페이스에 대한 정보가 포함되어 있습니다.

  2. 다음 예와 같이 AssistedServiceConfig 오브젝트를 추가하여 Assisted Service를 구성합니다. 

    ---
apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
  annotations:
    unsupported.agent-install.openshift.io/assisted-service-configmap: assisted-service-config
    1 
    
  name: agent
  namespace: multicluster-engine
spec:
  mirrorRegistryRef:
    name: custom-registries
    2 
    
  databaseStorage:
    storageClassName: lvms-vg1
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi
  filesystemStorage:
    storageClassName: lvms-vg1
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 20Gi
  osImages:
    3 
    
  - cpuArchitecture: x86_64
    openshiftVersion: "4.14"
    rootFSUrl: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live-rootfs.x86_64.img
    4 
    
    url: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live.x86_64.iso
    version: 414.92.202308281054-0
    Copy to Clipboard Toggle word wrap
    1
    metadata.annotations["unsupported.agent-install.openshift.io/assisted-service-configmap"] 주석은 Operator가 동작을 사용자 정의하는 데 사용하는 구성 맵 이름을 참조합니다.
    2
    spec.mirrorRegistryRef.name 주석은 Assisted Service Operator가 사용하는 연결이 끊긴 레지스트리 정보가 포함된 구성 맵을 가리킵니다. 이 구성 맵은 배포 프로세스 중에 해당 리소스를 추가합니다.
    3
    spec.osImages 필드에는 이 Operator에서 배포할 수 있는 다양한 버전이 포함되어 있습니다. 이 필드는 필수입니다. 이 예제에서는 이미 RootFS 및 LiveISO 파일을 다운로드했다고 가정합니다.
    4
    rootFSUrl 및 url 필드에서 dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

  3. 해당 오브젝트를 단일 파일에 연결하고 관리 클러스터에 적용하여 모든 오브젝트를 배포합니다. 이렇게 하려면 다음 명령을 입력합니다. 

    oc apply -f agentServiceConfig.yaml
    Copy to Clipboard Toggle word wrap

    이 명령은 이 예제 출력에 표시된 대로 두 개의 Pod를 트리거합니다. 

    assisted-image-service-0                               1/1     Running   2             11d
    1 
    
assisted-service-668b49548-9m7xw                       2/2     Running   5             11d
    2
    Copy to Clipboard Toggle word wrap
    1
    assisted-image-service Pod는 배포하는 각 클러스터에 대해 사용자 지정되는 RHCOS(Red Hat Enterprise Linux CoreOS) 부팅 이미지 템플릿을 생성합니다.
    2
    assisted-service 는 Operator를 나타냅니다.
1.7.10.5.8. IPv4 네트워크에 대한 TLS 인증서 구성
링크 복사

연결이 끊긴 환경에서 호스팅된 컨트롤 플레인을 구성하는 프로세스에 여러 TLS 인증서가 포함됩니다. 관리 클러스터에 CA(인증 기관)를 추가하려면 OpenShift Container Platform 컨트롤 플레인 및 작업자 노드에서 다음 파일의 내용을 수정해야 합니다.

  • /etc/pki/ca-trust/extracted/pem/
  • /etc/pki/ca-trust/source/anchors
  • /etc/pki/tls/certs/

관리 클러스터에 CA를 추가하려면 다음 단계를 완료합니다.

  1. 공식 OpenShift Container Platform 설명서에서 CA 번들 업데이트 단계를 완료합니다. 이 방법은 CA를 OpenShift Container Platform 노드에 배포하는 image-registry-operator 를 사용하는 것입니다.

  2. 해당 방법이 상황에 적용되지 않는 경우 관리 클러스터의 openshift-config 네임스페이스에 user-ca-bundle 이라는 구성 맵이 포함되어 있는지 확인합니다.

    • 네임스페이스에 해당 구성 맵이 포함된 경우 다음 명령을 입력합니다. 

      ## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE>
export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt

oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${REGISTRY_CERT_PATH}
      Copy to Clipboard Toggle word wrap

    • 네임스페이스에 해당 구성 맵이 포함되지 않은 경우 다음 명령을 입력합니다. 

      ## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE>
export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt
export TMP_FILE=$(mktemp)

oc get cm -n openshift-config user-ca-bundle -ojsonpath='{.data.ca-bundle\.crt}' > ${TMP_FILE}
echo >> ${TMP_FILE}
echo \#registry.$(hostname --long) >> ${TMP_FILE}
cat ${REGISTRY_CERT_PATH} >> ${TMP_FILE}
oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${TMP_FILE} --dry-run=client -o yaml | kubectl apply -f -
      Copy to Clipboard Toggle word wrap
1.7.10.5.9. IPv4 네트워크용 호스트 클러스터 배포
링크 복사

호스팅 클러스터는 관리 클러스터에서 호스팅되는 컨트롤 플레인 및 API 끝점이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 클러스터에는 컨트롤 플레인과 해당 데이터 플레인이 포함됩니다.

Red Hat Advanced Cluster Management에서 콘솔을 사용하여 호스트 클러스터를 생성할 수 있지만 다음 절차에서는 관련 아티팩트를 수정하는 데 더 유연하게 사용할 수 있는 매니페스트를 사용합니다.

1.7.10.5.9.1. 호스트된 클러스터 오브젝트 배포
링크 복사

이 절차의 목적을 위해 다음 값이 사용됩니다.

  • HostedCluster 이름: hosted-ipv4
  • HostedCluster 네임스페이스: 클러스터
  • disconnected: true
  • 네트워크 스택: IPv4

일반적으로 HyperShift Operator는 HostedControlPlane 네임스페이스를 생성합니다. 그러나 이 경우 HyperShift Operator가 HostedCluster 오브젝트를 조정하기 전에 모든 오브젝트를 포함해야 합니다. 그러면 Operator가 조정 프로세스를 시작하면 모든 오브젝트를 찾을 수 있습니다.

  1. 네임스페이스에 대한 다음 정보를 사용하여 YAML 파일을 생성합니다. 

    ---
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: clusters-hosted-ipv4
spec: {}
status: {}
---
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: clusters
spec: {}
status: {}
    Copy to Clipboard Toggle word wrap

  2. HostedCluster 배포에 포함할 구성 맵 및 시크릿에 대한 다음 정보를 사용하여 YAML 파일을 생성합니다. 

    ---
apiVersion: v1
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: clusters
---
apiVersion: v1
data:
  .dockerconfigjson: xxxxxxxxx
kind: Secret
metadata:
  creationTimestamp: null
  name: hosted-ipv4-pull-secret
  namespace: clusters
---
apiVersion: v1
kind: Secret
metadata:
  name: sshkey-cluster-hosted-ipv4
  namespace: clusters
stringData:
  id_rsa.pub: ssh-rsa xxxxxxxxx
---
apiVersion: v1
data:
  key: nTPtVBEt03owkrKhIdmSW8jrWRxU57KO/fnZa8oaG0Y=
kind: Secret
metadata:
  creationTimestamp: null
  name: hosted-ipv4-etcd-encryption-key
  namespace: clusters
type: Opaque
    Copy to Clipboard Toggle word wrap

  3. 지원 서비스 에이전트가 호스팅된 컨트롤 플레인과 동일한 HostedControlPlane 네임스페이스에 있을 수 있고 클러스터 API에서 계속 관리할 수 있도록 RBAC 역할이 포함된 YAML 파일을 생성합니다. 

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: capi-provider-role
  namespace: clusters-hosted-ipv4
rules:
- apiGroups:
  - agent-install.openshift.io
  resources:
  - agents
  verbs:
  - '*'
    Copy to Clipboard Toggle word wrap

  4. 필요에 따라 값을 교체하여 HostedCluster 오브젝트에 대한 정보를 사용하여 YAML 파일을 생성합니다. 

    apiVersion: hypershift.openshift.io/v1beta1
kind: HostedCluster
metadata:
  name: hosted-ipv4
  namespace: clusters
spec:
  additionalTrustBundle:
    name: "user-ca-bundle"
  olmCatalogPlacement: guest
  imageContentSources:
    1 
    
  - source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
    mirrors:
    - registry.dns.base.domain.name:5000/openshift/release
  - source: quay.io/openshift-release-dev/ocp-release
    mirrors:
    - registry.dns.base.domain.name:5000/openshift/release-images
  - mirrors:
  ...
  ...
  autoscaling: {}
  controllerAvailabilityPolicy: SingleReplica
  dns:
    baseDomain: dns.base.domain.name
  etcd:
    managed:
      storage:
        persistentVolume:
          size: 8Gi
        restoreSnapshotURL: null
        type: PersistentVolume
    managementType: Managed
  fips: false
  networking:
    clusterNetwork:
    - cidr: 10.132.0.0/14
    networkType: OVNKubernetes
    serviceNetwork:
    - cidr: 172.31.0.0/16
  platform:
    agent:
      agentNamespace: clusters-hosted-ipv4
    type: Agent
  pullSecret:
    name: hosted-ipv4-pull-secret
  release:
    image: registry.dns.base.domain.name:5000/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237
  secretEncryption:
    aescbc:
      activeKey:
        name: hosted-ipv4-etcd-encryption-key
    type: aescbc
  services:
  - service: APIServer
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv4.dns.base.domain.name
      type: NodePort
  - service: OAuthServer
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv4.dns.base.domain.name
      type: NodePort
  - service: OIDC
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv4.dns.base.domain.name
      type: NodePort
  - service: Konnectivity
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv4.dns.base.domain.name
      type: NodePort
  - service: Ignition
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv4.dns.base.domain.name
      type: NodePort
  sshKey:
    name: sshkey-cluster-hosted-ipv4
status:
  controlPlaneEndpoint:
    host: ""
    port: 0
    Copy to Clipboard Toggle word wrap

    여기서 dns.base.domain.name 은 DNS 기본 도메인 이름입니다.

    1
    imageContentSources 섹션에는 호스팅된 클러스터 내의 사용자 워크로드에 대한 미러 참조가 포함되어 있습니다.

  5. OpenShift Container Platform 릴리스의 HyperShift Operator 릴리스를 가리키는 HostedCluster 오브젝트에 주석을 추가합니다.

    1. 다음 명령을 입력하여 이미지 페이로드를 가져옵니다. 

      oc adm release info registry.dns.base.domain.name:5000/openshift-release-dev/ocp-release:4.14.0-rc.1-x86_64 | grep hypershift
      Copy to Clipboard Toggle word wrap

      여기서 dns.base.domain.name 은 DNS 기본 도메인 이름입니다.

    2. 다음 출력을 참조하십시오. 

      hypershift                                     sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
      Copy to Clipboard Toggle word wrap

    3. OpenShift Container Platform 이미지 네임스페이스를 사용하여 다음 명령을 입력하여 다이제스트를 확인합니다. 

      podman pull registry.dns.base.domain.name:5000/openshift-release-dev/ocp-v4.0-art-dev@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
      Copy to Clipboard Toggle word wrap

      여기서 dns.base.domain.name 은 DNS 기본 도메인 이름입니다.

    4. 다음 출력을 참조하십시오. 

      podman pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
Trying to pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8...
Getting image source signatures
Copying blob d8190195889e skipped: already exists
Copying blob c71d2589fba7 skipped: already exists
Copying blob d4dc6e74b6ce skipped: already exists
Copying blob 97da74cc6d8f skipped: already exists
Copying blob b70007a560c9 done
Copying config 3a62961e6e done
Writing manifest to image destination
Storing signatures
3a62961e6ed6edab46d5ec8429ff1f41d6bb68de51271f037c6cb8941a007fde
      Copy to Clipboard Toggle word wrap

    참고: HostedCluster 오브젝트에 설정된 릴리스 이미지는 태그가 아닌 다이제스트를 사용해야 합니다. 예를 들어 quay.io/openshift-release-dev/ocp-release@sha256:e3ba11bd1e5e8ea5a0b36a75791c90f29afb0fdbe4125be4e48f69c76a5c.

  6. YAML 파일에 정의된 모든 오브젝트를 파일에 연결하고 관리 클러스터에 적용하여 해당 오브젝트를 생성합니다. 이렇게 하려면 다음 명령을 입력합니다. 

    oc apply -f 01-4.14-hosted_cluster-nodeport.yaml
    Copy to Clipboard Toggle word wrap

  7. 호스트된 컨트롤 플레인의 출력을 참조하십시오. 

    NAME                                                  READY   STATUS    RESTARTS   AGE
capi-provider-5b57dbd6d5-pxlqc                        1/1     Running   0          3m57s
catalog-operator-9694884dd-m7zzv                      2/2     Running   0          93s
cluster-api-f98b9467c-9hfrq                           1/1     Running   0          3m57s
cluster-autoscaler-d7f95dd5-d8m5d                     1/1     Running   0          93s
cluster-image-registry-operator-5ff5944b4b-648ht      1/2     Running   0          93s
cluster-network-operator-77b896ddc-wpkq8              1/1     Running   0          94s
cluster-node-tuning-operator-84956cd484-4hfgf         1/1     Running   0          94s
cluster-policy-controller-5fd8595d97-rhbwf            1/1     Running   0          95s
cluster-storage-operator-54dcf584b5-xrnts             1/1     Running   0          93s
cluster-version-operator-9c554b999-l22s7              1/1     Running   0          95s
control-plane-operator-6fdc9c569-t7hr4                1/1     Running   0          3m57s
csi-snapshot-controller-785c6dc77c-8ljmr              1/1     Running   0          77s
csi-snapshot-controller-operator-7c6674bc5b-d9dtp     1/1     Running   0          93s
csi-snapshot-webhook-5b8584875f-2492j                 1/1     Running   0          77s
dns-operator-6874b577f-9tc6b                          1/1     Running   0          94s
etcd-0                                                3/3     Running   0          3m39s
hosted-cluster-config-operator-f5cf5c464-4nmbh        1/1     Running   0          93s
ignition-server-6b689748fc-zdqzk                      1/1     Running   0          95s
ignition-server-proxy-54d4bb9b9b-6zkg7                1/1     Running   0          95s
ingress-operator-6548dc758b-f9gtg                     1/2     Running   0          94s
konnectivity-agent-7767cdc6f5-tw782                   1/1     Running   0          95s
kube-apiserver-7b5799b6c8-9f5bp                       4/4     Running   0          3m7s
kube-controller-manager-5465bc4dd6-zpdlk              1/1     Running   0          44s
kube-scheduler-5dd5f78b94-bbbck                       1/1     Running   0          2m36s
machine-approver-846c69f56-jxvfr                      1/1     Running   0          92s
oauth-openshift-79c7bf44bf-j975g                      2/2     Running   0          62s
olm-operator-767f9584c-4lcl2                          2/2     Running   0          93s
openshift-apiserver-5d469778c6-pl8tj                  3/3     Running   0          2m36s
openshift-controller-manager-6475fdff58-hl4f7         1/1     Running   0          95s
openshift-oauth-apiserver-dbbc5cc5f-98574             2/2     Running   0          95s
openshift-route-controller-manager-5f6997b48f-s9vdc   1/1     Running   0          95s
packageserver-67c87d4d4f-kl7qh                        2/2     Running   0          93s
    Copy to Clipboard Toggle word wrap

  8. 호스트 클러스터의 출력을 참조하십시오. 

    NAMESPACE   NAME         VERSION   KUBECONFIG                PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
clusters    hosted-ipv4            hosted-admin-kubeconfig   Partial    True          False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap

다음으로 NodePool 오브젝트를 생성합니다.

1.7.10.5.9.2. 호스트된 클러스터에 대한 NodePool 오브젝트 생성
링크 복사

NodePool 은 호스팅된 클러스터와 연결된 확장 가능한 작업자 노드 집합입니다. NodePool 머신 아키텍처는 특정 풀 내에서 일관되게 유지되며 컨트롤 플레인의 머신 아키텍처와 독립적입니다.

  1. NodePool 오브젝트에 대한 다음 정보를 사용하여 YAML 파일을 생성하여 필요에 따라 값을 바꿉니다. 

    apiVersion: hypershift.openshift.io/v1beta1
kind: NodePool
metadata:
  creationTimestamp: null
  name: hosted-ipv4
  namespace: clusters
spec:
  arch: amd64
  clusterName: hosted-ipv4
  management:
    autoRepair: false
    1 
    
    upgradeType: InPlace
    2 
    
  nodeDrainTimeout: 0s
  platform:
    type: Agent
  release:
    image: registry.dns.base.domain.name:5000/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237
    3 
    
  replicas: 0
status:
  replicas: 0
    4
    Copy to Clipboard Toggle word wrap
    1
    노드가 제거되면 노드가 다시 생성되지 않기 때문에 autoRepair 필드가 false 로 설정됩니다.
    2
    upgradeType 은 업그레이드 중에 동일한 베어 메탈 노드가 재사용됨을 나타내는 InPlace 로 설정됩니다.
    3
    이 NodePool 에 포함된 모든 노드는 다음 OpenShift Container Platform 버전 4.14.0-0.nightly-2023-08-29-102237 을 기반으로 합니다. dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.
    4
    필요한 경우 스케일링할 수 있도록 replicas 값은 0 으로 설정됩니다. 모든 단계가 완료될 때까지 NodePool 복제본을 0으로 유지하는 것이 중요합니다.

  2. 다음 명령을 입력하여 NodePool 오브젝트를 생성합니다. 

    oc apply -f 02-nodepool.yaml
    Copy to Clipboard Toggle word wrap

  3. 출력을 참조하십시오. 

    NAMESPACE   NAME          CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted-ipv4   hosted    0                               False         False        4.14.0-0.nightly-2023-08-29-102237
    Copy to Clipboard Toggle word wrap

다음으로 InfraEnv 리소스를 생성합니다.

1.7.10.5.9.3. 호스트된 클러스터에 대한 InfraEnv 리소스 생성
링크 복사

InfraEnv 리소스는 pullSecretRef 및 sshAuthorizedKey 와 같은 필수 세부 정보를 포함하는 지원 서비스 오브젝트입니다. 이러한 세부 사항은 호스팅된 클러스터에 대해 사용자 지정된 RHCOS(Red Hat Enterprise Linux CoreOS) 부팅 이미지를 생성하는 데 사용됩니다.

  1. 필요에 따라 값을 교체하여 InfraEnv 리소스에 대한 다음 정보를 사용하여 YAML 파일을 생성합니다. 

    ---
apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: hosted-ipv4
  namespace: clusters-hosted-ipv4
spec:
  pullSecretRef:
    1 
    
    name: pull-secret
  sshAuthorizedKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDk7ICaUE+/k4zTpxLk4+xFdHi4ZuDi5qjeF52afsNkw0w/glILHhwpL5gnp5WkRuL8GwJuZ1VqLC9EKrdmegn4MrmUlq7WTsP0VFOZFBfq2XRUxo1wrRdor2z0Bbh93ytR+ZsDbbLlGngXaMa0Vbt+z74FqlcajbHTZ6zBmTpBVq5RHtDPgKITdpE1fongp7+ZXQNBlkaavaqv8bnyrP4BWahLP4iO9/xJF9lQYboYwEEDzmnKLMW1VtCE6nJzEgWCufACTbxpNS7GvKtoHT/OVzw8ArEXhZXQUS1UY8zKsX2iXwmyhw5Sj6YboA8WICs4z+TrFP89LmxXY0j6536TQFyRz1iB4WWvCbH5n6W+ABV2e8ssJB1AmEy8QYNwpJQJNpSxzoKBjI73XxvPYYC/IjPFMySwZqrSZCkJYqQ023ySkaQxWZT7in4KeMu7eS2tC+Kn4deJ7KwwUycx8n6RHMeD8Qg9flTHCv3gmab8JKZJqN3hW1D378JuvmIX4V0=
    2
    Copy to Clipboard Toggle word wrap
    1
    pullSecretRef 는 가져오기 보안이 사용되는 InfraEnv 와 동일한 네임스페이스에서 구성 맵 참조를 나타냅니다.
    2
    sshAuthorizedKey 는 부팅 이미지에 배치된 SSH 공개 키를 나타냅니다. SSH 키를 사용하면 core 사용자로 작업자 노드에 액세스할 수 있습니다.

  2. 다음 명령을 입력하여 InfraEnv 리소스를 생성합니다. 

    oc apply -f 03-infraenv.yaml
    Copy to Clipboard Toggle word wrap

  3. 다음 출력을 참조하십시오. 

    NAMESPACE              NAME     ISO CREATED AT
clusters-hosted-ipv4   hosted   2023-09-11T15:14:10Z
    Copy to Clipboard Toggle word wrap

다음으로 작업자 노드를 생성합니다.

1.7.10.5.9.4. 호스트된 클러스터의 작업자 노드 생성
링크 복사

베어 메탈 플랫폼에서 작업하는 경우 작업자 노드를 생성하는 것은 BareMetalHost 의 세부 정보가 올바르게 구성되었는지 확인하는 데 중요합니다.

가상 머신으로 작업하는 경우 다음 단계를 완료하여 Metal3 Operator에서 사용하는 빈 작업자 노드를 생성할 수 있습니다. 이렇게 하려면 kcli 를 사용합니다.

  1. 이것이 작업자 노드 생성을 처음 시도하지 않은 경우 먼저 이전 설정을 삭제해야 합니다. 이렇게 하려면 다음 명령을 입력하여 계획을 삭제합니다. 

    kcli delete plan hosted-ipv4
    Copy to Clipboard Toggle word wrap
    1. 계획을 삭제할지 여부를 확인하라는 메시지가 표시되면 y 를 입력합니다.
    2. 계획이 삭제되었음을 알리는 메시지가 표시되는지 확인합니다.

  2. 다음 명령을 입력하여 가상 머신을 생성합니다. 

    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv4 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv4\", \"mac\": \"aa:aa:aa:aa:02:11\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0211 -P name=hosted-ipv4-worker0
    Copy to Clipboard Toggle word wrap 
    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv4 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv4\", \"mac\": \"aa:aa:aa:aa:02:12\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0212 -P name=hosted-ipv4-worker1
    Copy to Clipboard Toggle word wrap 
    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv4 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv4\", \"mac\": \"aa:aa:aa:aa:02:13\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0213 -P name=hosted-ipv4-worker2
    Copy to Clipboard Toggle word wrap 
    systemctl restart ksushy
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    • start=False 는 VM(가상 머신)이 생성 시 자동으로 시작되지 않음을 의미합니다.
    • uefi_legacy=true 는 UEFI 레거시 부팅을 사용하여 이전 UEFI 구현과의 호환성을 보장합니다.
    • plan=hosted-dual 은 시스템 그룹을 클러스터로 식별하는 계획 이름을 나타냅니다.
    • memory=8192 및 numcpus=16 은 RAM 및 CPU를 포함하여 VM의 리소스를 지정하는 매개변수입니다.
    • disks=[200,200] 은 VM에 씬 프로비저닝된 두 개의 디스크를 생성 중임을 나타냅니다.
    • nets=[{"name": "dual", "mac": "aa:aa:aa:aa:aa:aa:02:13"}] 은 연결할 네트워크 이름과 기본 인터페이스의 MAC 주소를 포함한 네트워크 세부 정보입니다.
    • ksushy 를 다시 시작하여 ksushy 툴을 다시 시작하여 추가한 VM을 감지합니다.

  3. 결과 출력을 확인합니다. 

    +---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
|         Name        | Status |         Ip        |                       Source                       |     Plan    | Profile |
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
|    hosted-worker0   |  down  |                   |                                                    | hosted-ipv4 |  kvirt  |
|    hosted-worker1   |  down  |                   |                                                    | hosted-ipv4 |  kvirt  |
|    hosted-worker2   |  down  |                   |                                                    | hosted-ipv4 |  kvirt  |
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
    Copy to Clipboard Toggle word wrap

다음으로 호스팅된 클러스터에 대한 베어 메탈 호스트를 생성합니다.

1.7.10.5.9.5. 호스트 클러스터를 위한 베어 메탈 호스트 생성
링크 복사

베어 메탈 호스트 는 Metal3 Operator가 식별할 수 있도록 물리적 및 논리 세부 정보를 포함하는 openshift-machine-api 오브젝트입니다. 이러한 세부 사항은 에이전트 라고 하는 기타 지원 서비스 오브젝트와 연결됩니다.

중요: 베어 메탈 호스트 및 대상 노드를 생성하기 전에 가상 머신을 생성해야 합니다.

베어 메탈 호스트를 생성하려면 다음 단계를 완료합니다.

  1. 다음 정보를 사용하여 YAML 파일을 생성합니다.

    참고: 베어 메탈 호스트 인증 정보를 보유하는 시크릿이 하나 이상 있으므로 각 작업자 노드에 대해 두 개 이상의 오브젝트를 생성해야 합니다. 

    ---
apiVersion: v1
kind: Secret
metadata:
  name: hosted-ipv4-worker0-bmc-secret
  namespace: clusters-hosted-ipv4
data:
  password: YWRtaW4=
  username: YWRtaW4=
type: Opaque
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: hosted-ipv4-worker0
  namespace: clusters-hosted-ipv4
  labels:
    infraenvs.agent-install.openshift.io: hosted-ipv4
    1 
    
  annotations:
    inspect.metal3.io: disabled
    bmac.agent-install.openshift.io/hostname: hosted-ipv4-worker0
    2 
    
spec:
  automatedCleaningMode: disabled
    3 
    
  bmc:
    disableCertificateVerification: true
    4 
    
    address: redfish-virtualmedia://[192.168.125.1]:9000/redfish/v1/Systems/local/hosted-ipv4-worker0
    5 
    
    credentialsName: hosted-ipv4-worker0-bmc-secret
    6 
    
  bootMACAddress: aa:aa:aa:aa:02:11
    7 
    
  online: true
    8
    Copy to Clipboard Toggle word wrap
    1
    infraenvs.agent-install.openshift.io 는 지원 설치 프로그램과 BareMetalHost 오브젝트 간의 링크 역할을 합니다.
    2
    B MAC.agent-install.openshift.io/hostname 은 배포 중에 채택된 노드 이름을 나타냅니다.
    3
    automatedCleaningMode 를 사용하면 Metal3 Operator에 의해 노드가 지워지지 않습니다.
    4
    클라이언트에서 인증서 유효성 검사를 바이패스하려면 disableCertificateVerification 이 true 로 설정됩니다.
    5
    address 는 작업자 노드의 BMC(Baseboard Management Controller) 주소를 나타냅니다.
    6
    credentialsName 은 사용자 및 암호 인증 정보가 저장된 시크릿을 가리킵니다.
    7
    bootMACAddress 는 노드가 시작되는 인터페이스 MACAddress를 나타냅니다.
    8
    online 은 BareMetalHost 개체가 생성된 후 노드의 상태를 정의합니다.

  2. 다음 명령을 입력하여 BareMetalHost 오브젝트를 배포합니다. 

    oc apply -f 04-bmh.yaml
    Copy to Clipboard Toggle word wrap

    프로세스 중에 다음 출력을 볼 수 있습니다.

    • 이 출력은 프로세스가 노드에 연결을 시도 중임을 나타냅니다. 

      NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   registering              true             2s
clusters-hosted   hosted-worker1   registering              true             2s
clusters-hosted   hosted-worker2   registering              true             2s
      Copy to Clipboard Toggle word wrap

    • 이 출력은 노드가 시작됨을 나타냅니다. 

      NAMESPACE         NAME             STATE          CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   provisioning              true             16s
clusters-hosted   hosted-worker1   provisioning              true             16s
clusters-hosted   hosted-worker2   provisioning              true             16s
      Copy to Clipboard Toggle word wrap
    • 이 출력은 노드가 성공적으로 시작되었음을 나타냅니다. 
    NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   provisioned              true             67s
clusters-hosted   hosted-worker1   provisioned              true             67s
clusters-hosted   hosted-worker2   provisioned              true             67s
    Copy to Clipboard Toggle word wrap

  3. 노드가 시작된 후 다음 예와 같이 네임스페이스의 에이전트를 확인합니다. 

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413             true       auto-assign
    Copy to Clipboard Toggle word wrap

    에이전트는 설치에 사용할 수 있는 노드를 나타냅니다. 호스트 클러스터에 노드를 할당하려면 노드 풀을 확장합니다.

1.7.10.5.9.6. 노드 풀 확장
링크 복사

베어 메탈 호스트를 생성한 후 해당 상태가 Registering 에서 Provisioning (프로비저닝)으로 변경됨. 노드는 에이전트의 LiveISO 및 에이전트 라는 기본 Pod로 시작합니다. 해당 에이전트는 OpenShift Container Platform 페이로드를 설치하기 위해 Assisted Service Operator에서 지침을 받습니다.

  1. 노드 풀을 확장하려면 다음 명령을 입력합니다. 

    oc -n clusters scale nodepool hosted-ipv4 --replicas 3
    Copy to Clipboard Toggle word wrap

  2. 확장 프로세스가 완료되면 에이전트가 호스팅된 클러스터에 할당되어 있습니다. 

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411   hosted    true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412   hosted    true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413   hosted    true       auto-assign
    Copy to Clipboard Toggle word wrap

  3. 또한 노드 풀 복제본이 설정되어 있습니다. 

    NAMESPACE   NAME     CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted   hosted    3                               False         False        4.14.0-0.nightly-2023-08-29-102237                                      Minimum availability requires 3 replicas, current 0 available
    Copy to Clipboard Toggle word wrap
  4. 노드가 클러스터에 참여할 때까지 기다립니다. 프로세스 중에 에이전트는 단계 및 상태에 대한 업데이트를 제공합니다.

다음으로 호스트 클러스터의 배포를 모니터링합니다.

1.7.10.5.10. IPv4 네트워크의 호스트 클러스터 배포 완료
링크 복사

컨트롤 플레인과 데이터 플레인의 두 가지 관점에서 호스팅 클러스터 배포를 모니터링할 수 있습니다.

1.7.10.5.10.1. 컨트롤 플레인 모니터링
링크 복사

호스팅 클러스터를 배포하는 동안 다음 명령을 입력하여 컨트롤 플레인을 모니터링할 수 있습니다. 

export KUBECONFIG=/root/.kcli/clusters/hub-ipv4/auth/kubeconfig
Copy to Clipboard Toggle word wrap 
watch "oc get pod -n hypershift;echo;echo;oc get pod -n clusters-hosted-ipv4;echo;echo;oc get bmh -A;echo;echo;oc get agent -A;echo;echo;oc get infraenv -A;echo;echo;oc get hostedcluster -A;echo;echo;oc get nodepool -A;echo;echo;"
Copy to Clipboard Toggle word wrap

이러한 명령은 다음 아티팩트에 대한 정보를 제공합니다.

  • The HyperShift Operator
  • HostedControlPlane Pod
  • 베어 메탈 호스트
  • 에이전트
  • InfraEnv 리소스
  • HostedCluster 및 NodePool 리소스
1.7.10.5.10.2. 데이터 플레인 모니터링
링크 복사

배포 프로세스 중에 Operator가 진행 중인 방식을 모니터링하려면 다음 명령을 입력합니다. 

oc get secret -n clusters-hosted-ipv4 admin-kubeconfig -o jsonpath='{.data.kubeconfig}' |base64 -d > /root/hc_admin_kubeconfig.yaml
Copy to Clipboard Toggle word wrap 
export KUBECONFIG=/root/hc_admin_kubeconfig.yaml
Copy to Clipboard Toggle word wrap 
watch "oc get clusterversion,nodes,co"
Copy to Clipboard Toggle word wrap

이러한 명령은 다음 아티팩트에 대한 정보를 제공합니다.

  • 클러스터 버전
  • 특히 노드가 클러스터에 참여하는지 여부에 대한 노드
  • 클러스터 Operator

1.7.10.6. IPv6 네트워크에서 호스트된 컨트롤 플레인 구성
링크 복사

IPv6 네트워크 구성은 현재 연결이 끊긴 것으로 지정됩니다. 이러한 지정의 주요 이유는 원격 레지스트리가 IPv6에서 작동하지 않기 때문입니다.

IPv6 네트워크에서 호스팅되는 컨트롤 플레인을 구성하는 프로세스에는 다음 단계가 포함되며, 다음 섹션에 자세히 설명되어 있습니다.

  1. IPv6 네트워크에 대한 하이퍼바이저 구성
  2. IPv6 네트워크에 대한 DNS 구성
  3. IPv6 네트워크의 레지스트리 배포
  4. IPv6 네트워크의 관리 클러스터 설정
  5. IPv6 네트워크에 대한 웹 서버 구성
  6. IPv6 네트워크에 대한 이미지 미러링 구성
  7. IPv6 네트워크용 다중 클러스터 엔진 Operator 배포
  8. IPv6 네트워크에 대한 TLS 인증서 구성
  9. IPv6 네트워크에 대해 호스트된 클러스터 배포
  10. IPv6 네트워크에 대한 배포 완료
1.7.10.6.1. IPv6 네트워크에 대한 하이퍼바이저 구성
링크 복사

다음 정보는 가상 머신 환경에만 적용됩니다.

  1. 가상 OpenShift Container Platform 관리 클러스터를 배포하려면 다음 명령을 입력하여 필요한 패키지에 액세스합니다. 

    sudo dnf install dnsmasq radvd vim golang podman bind-utils net-tools httpd-tools tree htop strace tmux -y
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 Podman 서비스를 활성화하고 시작합니다. 

    systemctl enable --now podman
    Copy to Clipboard Toggle word wrap

  3. kcli 를 사용하여 OpenShift Container Platform 관리 클러스터 및 기타 가상 구성 요소를 배포하려면 다음 명령을 입력하여 하이퍼바이저를 설치 및 구성합니다. 

    sudo yum -y install libvirt libvirt-daemon-driver-qemu qemu-kvm
    Copy to Clipboard Toggle word wrap 
    sudo usermod -aG qemu,libvirt $(id -un)
    Copy to Clipboard Toggle word wrap 
    sudo newgrp libvirt
    Copy to Clipboard Toggle word wrap 
    sudo systemctl enable --now libvirtd
    Copy to Clipboard Toggle word wrap 
    sudo dnf -y copr enable karmab/kcli
    Copy to Clipboard Toggle word wrap 
    sudo dnf -y install kcli
    Copy to Clipboard Toggle word wrap 
    sudo kcli create pool -p /var/lib/libvirt/images default
    Copy to Clipboard Toggle word wrap 
    kcli create host kvm -H 127.0.0.1 local
    Copy to Clipboard Toggle word wrap 
    sudo setfacl -m u:$(id -un):rwx /var/lib/libvirt/images
    Copy to Clipboard Toggle word wrap 
    kcli create network  -c 192.168.122.0/24 default
    Copy to Clipboard Toggle word wrap
1.7.10.6.1.2. 네트워크 관리자 디스패처 활성화
링크 복사

  1. 네트워크 관리자 디스패처를 활성화하여 가상 머신이 필요한 도메인, 경로 및 레지스트리를 확인할 수 있는지 확인합니다. 네트워크 관리자 디스패처를 활성화하려면 /etc/NetworkManager/dispatcher.d/ 디렉터리에서 다음 콘텐츠가 포함된 forcedns 라는 스크립트를 생성하여 환경에 맞게 값을 교체하십시오. 

    #!/bin/bash

export IP="2620:52:0:1306::1"
    1 
    
export BASE_RESOLV_CONF="/run/NetworkManager/resolv.conf"

if ! [[ `grep -q "$IP" /etc/resolv.conf` ]]; then
export TMP_FILE=$(mktemp /etc/forcedns_resolv.conf.XXXXXX)
cp $BASE_RESOLV_CONF $TMP_FILE
chmod --reference=$BASE_RESOLV_CONF $TMP_FILE
sed -i -e "s/dns.base.domain.name//" -e "s/search /& dns.base.domain.name /" -e "0,/nameserver/s/nameserver/& $IP\n&/" $TMP_FILE
    2 
    
mv $TMP_FILE /etc/resolv.conf
fi
echo "ok"
    Copy to Clipboard Toggle word wrap
    1
    OpenShift Container Platform 관리 클러스터를 호스팅하는 하이퍼바이저 인터페이스의 IP 주소를 가리키도록 IP 변수를 수정합니다.
    2
    dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

  2. 파일을 생성한 후 다음 명령을 입력하여 권한을 추가합니다. 

    chmod 755 /etc/NetworkManager/dispatcher.d/forcedns
    Copy to Clipboard Toggle word wrap
  3. 스크립트를 실행하고 출력이 ok 를 반환하는지 확인합니다.
1.7.10.6.1.3. BMC 액세스 구성
링크 복사

  1. 가상 머신의 BMC(Baseboard Management Controller)를 시뮬레이션하도록 ksushy 를 구성합니다. 다음 명령을 입력합니다. 

    sudo dnf install python3-pyOpenSSL.noarch python3-cherrypy -y
    Copy to Clipboard Toggle word wrap 
    kcli create sushy-service --ssl --ipv6 --port 9000
    Copy to Clipboard Toggle word wrap 
    sudo systemctl daemon-reload
    Copy to Clipboard Toggle word wrap 
    systemctl enable --now ksushy
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 서비스가 올바르게 작동하는지 테스트합니다. 

    systemctl status ksushy
    Copy to Clipboard Toggle word wrap
1.7.10.6.1.4. 연결을 허용하도록 하이퍼바이저 시스템 구성
링크 복사

개발 환경에서 작업하는 경우 환경 내에서 다양한 가상 네트워크를 통한 다양한 유형의 연결을 허용하도록 하이퍼바이저 시스템을 구성합니다.

참고: 프로덕션 환경에서 작업하는 경우 firewalld 서비스에 대한 적절한 규칙을 설정하고 안전한 환경을 유지 관리하도록 SELinux 정책을 구성해야 합니다.

  • SELinux의 경우 다음 명령을 입력합니다. 

    sed -i s/^SELINUX=.*$/SELINUX=permissive/ /etc/selinux/config; setenforce 0
    Copy to Clipboard Toggle word wrap

  • firewalld 의 경우 다음 명령을 입력합니다. 

    systemctl disable --now firewalld
    Copy to Clipboard Toggle word wrap

  • libvirtd 의 경우 다음 명령을 입력합니다. 

    systemctl restart libvirtd
    Copy to Clipboard Toggle word wrap 
    systemctl enable --now libvirtd
    Copy to Clipboard Toggle word wrap

다음으로 환경에 맞게 DNS를 구성합니다.

1.7.10.6.1.5. 추가 리소스
링크 복사
1.7.10.6.2. IPv6 네트워크에 대한 DNS 구성
링크 복사

이 단계는 가상 및 베어 메탈 환경 모두에서 연결이 끊긴 환경과 연결된 환경 모두에 필요합니다. 가상 환경과 베어 메탈 환경 간의 주요 차이점은 리소스를 구성하는 위치에 있습니다. 베어 메탈 환경에서는 dnsmasq 와 같은 경량 솔루션이 아닌 바인딩과 같은 솔루션을 사용합니다.

다음으로 레지스트리를 배포합니다.

1.7.10.6.3. IPv6 네트워크의 레지스트리 배포
링크 복사

개발 환경의 경우 Podman 컨테이너를 사용하여 소규모 자체 호스팅 레지스트리를 배포합니다. 프로덕션 환경의 경우 Red Hat Quay, Nexus 또는 Artifactory와 같은 엔터프라이즈 호스팅 레지스트리를 사용합니다.

Podman을 사용하여 작은 레지스트리를 배포하려면 다음 단계를 완료합니다.

  1. 권한 있는 사용자로 ${HOME} 디렉터리에 액세스하고 다음 스크립트를 생성합니다. 

    #!/usr/bin/env bash

set -euo pipefail

PRIMARY_NIC=$(ls -1 /sys/class/net | grep -v podman | head -1)
export PATH=/root/bin:$PATH
export PULL_SECRET="/root/baremetal/hub/openshift_pull.json"
    1 
    

if [[ ! -f $PULL_SECRET ]];then
  echo "Pull Secret not found, exiting..."
  exit 1
fi

dnf -y install podman httpd httpd-tools jq skopeo libseccomp-devel
export IP=$(ip -o addr show $PRIMARY_NIC | head -1 | awk '{print $4}' | cut -d'/' -f1)
REGISTRY_NAME=registry.$(hostname --long)
REGISTRY_USER=dummy
REGISTRY_PASSWORD=dummy
KEY=$(echo -n $REGISTRY_USER:$REGISTRY_PASSWORD | base64)
echo "{\"auths\": {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\", \"email\": \"sample-email@domain.ltd\"}}}" > /root/disconnected_pull.json
mv ${PULL_SECRET} /root/openshift_pull.json.old
jq ".auths += {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\",\"email\": \"sample-email@domain.ltd\"}}" < /root/openshift_pull.json.old > $PULL_SECRET
mkdir -p /opt/registry/{auth,certs,data,conf}
cat <<EOF > /opt/registry/conf/config.yml
version: 0.1
log:
  fields:
    service: registry
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry
  delete:
    enabled: true
http:
  addr: :5000
  headers:
    X-Content-Type-Options: [nosniff]
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3
compatibility:
  schema1:
    enabled: true
EOF
openssl req -newkey rsa:4096 -nodes -sha256 -keyout /opt/registry/certs/domain.key -x509 -days 3650 -out /opt/registry/certs/domain.crt -subj "/C=US/ST=Madrid/L=San Bernardo/O=Karmalabs/OU=Guitar/CN=$REGISTRY_NAME" -addext "subjectAltName=DNS:$REGISTRY_NAME"
cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract
htpasswd -bBc /opt/registry/auth/htpasswd $REGISTRY_USER $REGISTRY_PASSWORD
podman create --name registry --net host --security-opt label=disable --replace -v /opt/registry/data:/var/lib/registry:z -v /opt/registry/auth:/auth:z -v /opt/registry/conf/config.yml:/etc/docker/registry/config.yml -e "REGISTRY_AUTH=htpasswd" -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry" -e "REGISTRY_HTTP_SECRET=ALongRandomSecretForRegistry" -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd -v /opt/registry/certs:/certs:z -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key docker.io/library/registry:latest
[ "$?" == "0" ] || !!
systemctl enable --now registry
    Copy to Clipboard Toggle word wrap
    1
    PULL_SECRET 위치를 설정에 적합한 위치로 교체합니다.

  2. 스크립트 파일 이름을 registry.sh 로 지정하고 저장합니다. 스크립트를 실행하면 다음 정보를 가져옵니다.

    • 하이퍼바이저 호스트 이름을 기반으로 하는 레지스트리 이름
    • 필요한 인증 정보 및 사용자 액세스 세부 정보

  3. 다음과 같이 실행 플래그를 추가하여 권한을 조정합니다. 

    chmod u+x ${HOME}/registry.sh
    Copy to Clipboard Toggle word wrap

  4. 매개변수 없이 스크립트를 실행하려면 다음 명령을 입력합니다. 

    ${HOME}/registry.sh
    Copy to Clipboard Toggle word wrap

    스크립트가 서버를 시작합니다.

  5. 스크립트는 관리 목적으로 systemd 서비스를 사용합니다. 스크립트를 관리해야 하는 경우 다음 명령을 사용할 수 있습니다. 

    systemctl status
    Copy to Clipboard Toggle word wrap 
    systemctl start
    Copy to Clipboard Toggle word wrap 
    systemctl stop
    Copy to Clipboard Toggle word wrap

레지스트리의 루트 폴더는 /opt/registry 디렉터리에 있으며 다음 하위 디렉터리가 포함되어 있습니다.

  • 인증서에는 TLS 인증서가 포함되어 있습니다.
  • auth 에는 인증 정보가 포함됩니다.
  • 데이터에 는 레지스트리 이미지가 포함되어 있습니다.
  • conf 에는 레지스트리 구성이 포함되어 있습니다.
1.7.10.6.4. IPv6 네트워크의 관리 클러스터 설정
링크 복사

OpenShift Container Platform 관리 클러스터를 설정하려면 dev-scripts를 사용하거나 가상 머신을 기반으로 하는 경우 kcli 툴을 사용할 수 있습니다. 다음 지침은 kcli 툴에 따라 다릅니다.

  1. 하이퍼바이저에서 적절한 네트워크를 사용할 준비가 되었는지 확인합니다. 네트워크는 관리 및 호스팅 클러스터를 모두 호스팅합니다. 다음 kcli 명령을 입력합니다. 

    kcli create network -c 2620:52:0:1305::0/64 -P dhcp=false -P dns=false --domain dns.base.domain.name --nodhcp ipv6
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    • -c 는 네트워크의 CIDR을 지정합니다.
    • -P dhcp=false 는 DHCP를 비활성화하도록 네트워크를 구성하며, 구성한 dnsmasq 에서 처리합니다.
    • -P dns=false 는 DNS를 비활성화하도록 네트워크를 구성하며, 구성한 dnsmasq 에서도 처리합니다.
    • --domain 은 검색할 도메인을 설정합니다.
    • DNS.base.domain.name 은 DNS 기본 도메인 이름입니다.
    • ipv6 는 생성 중인 네트워크의 이름입니다.

  2. 네트워크가 생성되면 다음 출력을 검토합니다. 

    [root@hypershiftbm ~]# kcli list network
Listing Networks...
+---------+--------+---------------------+-------+------------------+------+
| Network |  Type  |         Cidr        |  Dhcp |      Domain      | Mode |
+---------+--------+---------------------+-------+------------------+------+
| default | routed |   192.168.122.0/24  |  True |     default      | nat  |
| ipv4    | routed |   192.168.125.0/24  | False | dns.base.domain.name | nat  |
| ipv4    | routed | 2620:52:0:1305::/64 | False | dns.base.domain.name | nat  |
+---------+--------+---------------------+-------+------------------+------+
    Copy to Clipboard Toggle word wrap 
    [root@hypershiftbm ~]# kcli info network ipv6
Providing information about network ipv6...
cidr: 2620:52:0:1305::/64
dhcp: false
domain: dns.base.domain.name
mode: nat
plan: kvirt
type: routed
    Copy to Clipboard Toggle word wrap

  3. OpenShift Container Platform 관리 클러스터를 배포할 수 있도록 풀 시크릿 및 kcli 계획 파일이 있는지 확인합니다.

    1. 풀 시크릿이 kcli 계획과 동일한 폴더에 있고 풀 시크릿 파일의 이름이 openshift_pull.json 인지 확인합니다.
    2. mgmt-compact-hub-ipv6.yaml 파일에서 OpenShift Container Platform 정의가 포함된 kcli 계획을 추가합니다. 해당 환경과 일치하도록 파일 콘텐츠를 업데이트해야 합니다. 
    plan: hub-ipv6
force: true
version: nightly
tag: "4.14.0-0.nightly-2023-08-29-102237"
cluster: "hub-ipv6"
ipv6: true
domain: dns.base.domain.name
api_ip: 2620:52:0:1305::2
ingress_ip: 2620:52:0:1305::3
disconnected_url: registry.dns.base.domain.name:5000
disconnected_update: true
disconnected_user: dummy
disconnected_password: dummy
disconnected_operators_version: v4.14
disconnected_operators:
- name: metallb-operator
- name: lvms-operator
  channels:
  - name: stable-4.13
disconnected_extra_images:
- quay.io/user-name/trbsht:latest
- quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3
- registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
dualstack: false
disk_size: 200
extra_disks: [200]
memory: 48000
numcpus: 16
ctlplanes: 3
workers: 0
manifests: extra-manifests
metal3: true
network: ipv6
users_dev: developer
users_devpassword: developer
users_admin: admin
users_adminpassword: admin
metallb_pool: ipv6-virtual-network
metallb_ranges:
- 2620:52:0:1305::150-2620:52:0:1305::190
metallb_autoassign: true
apps:
- users
- lvms-operator
- metallb-operator
vmrules:
- hub-bootstrap:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:03:10
- hub-ctlplane-0:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:03:01
- hub-ctlplane-1:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:03:02
- hub-ctlplane-2:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:03:03
    Copy to Clipboard Toggle word wrap

  4. 관리 클러스터를 프로비저닝하려면 다음 명령을 입력합니다. 

    kcli create cluster openshift --pf mgmt-compact-hub-ipv6.yaml
    Copy to Clipboard Toggle word wrap
1.7.10.6.4.1. 추가 리소스
링크 복사
  • kcli 계획 파일의 매개변수에 대한 자세한 내용은 공식 kcli 문서의 parameters.yml 만들기 를 참조하십시오.
1.7.10.6.5. IPv6 네트워크에 대한 웹 서버 구성
링크 복사

호스트 클러스터로 배포 중인 OpenShift Container Platform 릴리스와 연결된 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 호스팅하도록 추가 웹 서버를 구성해야 합니다.

웹 서버를 구성하려면 다음 단계를 완료합니다.

  1. 다음 명령을 입력하여 사용할 OpenShift Container Platform 릴리스에서 openshift-install 바이너리를 추출합니다. 

    oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
    Copy to Clipboard Toggle word wrap

  2. 다음 스크립트를 실행합니다. 이 스크립트는 /opt/srv 디렉터리에 폴더를 생성합니다. 폴더에는 작업자 노드를 프로비저닝하는 RHCOS 이미지가 포함되어 있습니다. 

    #!/bin/bash

WEBSRV_FOLDER=/opt/srv
ROOTFS_IMG_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.pxe.rootfs.location')"
    1 
    
LIVE_ISO_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.iso.disk.location')"
    2 
    

mkdir -p ${WEBSRV_FOLDER}/images
curl -Lk ${ROOTFS_IMG_URL} -o ${WEBSRV_FOLDER}/images/${ROOTFS_IMG_URL##*/}
curl -Lk ${LIVE_ISO_URL} -o ${WEBSRV_FOLDER}/images/${LIVE_ISO_URL##*/}
chmod -R 755 ${WEBSRV_FOLDER}/*

## Run Webserver
podman ps --noheading | grep -q websrv-ai
if [[ $? == 0 ]];then
    echo "Launching Registry pod..."
    /usr/bin/podman run --name websrv-ai --net host -v /opt/srv:/usr/local/apache2/htdocs:z quay.io/alosadag/httpd:p8080
fi
    Copy to Clipboard Toggle word wrap
    1
    ROOTFS_IMG_URL 값은 OpenShift CI 릴리스 페이지에서 찾을 수 있습니다.
    2
    LIVE_ISO_URL 값은 OpenShift CI 릴리스 페이지에서 확인할 수 있습니다.

다운로드가 완료되면 컨테이너가 실행되어 웹 서버에서 이미지를 호스팅합니다. 컨테이너는 공식 HTTPd 이미지의 변형을 사용하여 IPv6 네트워크에서도 작업할 수 있습니다.

1.7.10.6.6. IPv6 네트워크에 대한 이미지 미러링 구성
링크 복사

이미지 미러링은 registry.redhat.com 또는 quay.io 와 같은 외부 레지스트리에서 이미지를 가져와서 프라이빗 레지스트리에 저장하는 프로세스입니다.

1.7.10.6.6.1. 미러링 프로세스 완료
링크 복사

참고: 레지스트리 서버가 실행된 후 미러링 프로세스를 시작합니다.

다음 절차에서는 ImageSetConfiguration 오브젝트를 사용하는 바이너리인 oc-mirror 툴이 사용됩니다. 파일에서 다음 정보를 지정할 수 있습니다.

  • 미러링할 OpenShift Container Platform 버전입니다. 버전은 quay.io 에 있습니다.
  • 미러링할 추가 Operator입니다. 패키지를 개별적으로 선택합니다.
  • 리포지토리에 추가할 추가 이미지입니다.

이미지 미러링을 구성하려면 다음 단계를 완료합니다.

  1. 이미지를 푸시하려는 프라이빗 레지스트리와 미러링할 레지스트리를 사용하여 ${HOME}/.docker/config.json 파일이 업데이트되었는지 확인합니다.

  2. 다음 예제를 사용하여 미러링에 사용할 ImageSetConfiguration 오브젝트를 만듭니다. 환경에 맞게 필요에 따라 값을 바꿉니다. 

    apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
  registry:
    imageURL: registry.dns.base.domain.name:5000/openshift/release/metadata:latest
    1 
    
mirror:
  platform:
    channels:
    - name: candidate-4.14
      minVersion: 4.14.0-ec.1
      maxVersion: 4.14.0-ec.3
      type: ocp
    graph: true
  additionalImages:
  - name: quay.io/karmab/origin-keepalived-ipfailover:latest
  - name: quay.io/karmab/kubectl:latest
  - name: quay.io/karmab/haproxy:latest
  - name: quay.io/karmab/mdns-publisher:latest
  - name: quay.io/karmab/origin-coredns:latest
  - name: quay.io/karmab/curl:latest
  - name: quay.io/karmab/kcli:latest
  - name: quay.io/user-name/trbsht:latest
  - name: quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3
  - name: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14
    packages:
    - name: lvms-operator
    - name: local-storage-operator
    - name: odf-csi-addons-operator
    - name: odf-operator
    - name: mcg-operator
    - name: ocs-operator
    - name: metallb-operator
    Copy to Clipboard Toggle word wrap
    1
    dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

  3. 다음 명령을 입력하여 미러링 프로세스를 시작합니다. 

    oc-mirror --source-skip-tls --config imagesetconfig.yaml docker://${REGISTRY}
    Copy to Clipboard Toggle word wrap

    미러링 프로세스가 완료되면 호스트 클러스터에 적용할 ICSP 및 카탈로그 소스가 포함된 oc-mirror-workspace/results-XXXXXX/ 라는 새 폴더가 있습니다.

  4. oc adm release mirror 명령을 사용하여 OpenShift Container Platform의 Nightly 또는 CI 버전을 미러링합니다. 다음 명령을 실행합니다. 

    REGISTRY=registry.$(hostname --long):5000

oc adm release mirror \
  --from=registry.ci.openshift.org/ocp/release:4.14.0-0.nightly-2023-08-29-102237 \
  --to=${REGISTRY}/openshift/release \
  --to-release-image=${REGISTRY}/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237
    Copy to Clipboard Toggle word wrap
  5. 연결이 끊긴 네트워크에 설치 단계에 따라 최신 다중 클러스터 엔진 Operator 이미지를 미러링합니다.
1.7.10.6.6.2. 관리 클러스터에 오브젝트 적용
링크 복사

미러링 프로세스가 완료되면 관리 클러스터에 두 개의 오브젝트를 적용해야 합니다.

  • Image Content Source Policies (ICSP) 또는 Image Digest 미러 세트(IDMS)
  • 카탈로그 소스

oc-mirror 툴을 사용하는 경우 출력 아티팩트는 oc-mirror-workspace/results-XXXXXX/ 이라는 폴더에 있습니다.

ICSP 또는 IDMS는 노드를 재시작하지 않고 각 노드에서 kubelet을 다시 시작하는 MachineConfig 변경 사항을 시작합니다. 노드가 READY 로 표시되면 새로 생성된 카탈로그 소스를 적용해야 합니다.

카탈로그 소스는 카탈로그 이미지 다운로드 및 처리와 같은 openshift-marketplace Operator에서 작업을 시작하여 해당 이미지에 포함된 모든 PackageManifest 를 검색합니다.

  1. 새 소스를 확인하려면 새 CatalogSource 를 소스로 사용하여 다음 명령을 실행합니다. 

    oc get packagemanifest
    Copy to Clipboard Toggle word wrap

  2. 아티팩트를 적용하려면 다음 단계를 완료합니다.

    1. 다음 명령을 입력하여 ICSP 또는 IDMS 아티팩트를 생성합니다. 

      oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
      Copy to Clipboard Toggle word wrap
    2. 노드가 준비될 때까지 기다린 다음 다음 명령을 입력합니다. 
    oc apply -f catalogSource-XXXXXXXX-index.yaml
    Copy to Clipboard Toggle word wrap
1.7.10.6.6.3. 추가 리소스
링크 복사
1.7.10.6.7. IPv6 네트워크용 다중 클러스터 엔진 Operator 배포
링크 복사

다중 클러스터 엔진 Operator는 공급업체에 클러스터를 배포하는 데 중요한 역할을 합니다. Red Hat Advanced Cluster Management를 이미 설치한 경우 자동으로 설치되므로 다중 클러스터 엔진 Operator를 설치할 필요가 없습니다.

다중 클러스터 엔진 Operator가 설치되어 있지 않은 경우 다음 문서를 검토하여 사전 요구 사항 및 설치 단계를 이해하십시오.

1.7.10.6.7.1. AgentServiceConfig 리소스 배포
링크 복사

AgentServiceConfig 사용자 지정 리소스는 다중 클러스터 엔진 Operator의 일부인 지원 서비스 애드온의 필수 구성 요소입니다. 베어 메탈 클러스터 배포를 담당합니다. 애드온이 활성화되면 AgentServiceConfig 리소스를 배포하여 애드온을 구성합니다.

AgentServiceConfig 리소스를 구성하는 것 외에도 연결이 끊긴 환경에서 다중 클러스터 엔진 Operator가 제대로 작동하는지 확인하기 위해 추가 구성 맵을 포함해야 합니다.

  1. 배포를 사용자 지정하는 연결이 끊긴 세부 정보가 포함된 다음 구성 맵을 추가하여 사용자 정의 레지스트리를 구성합니다. 

    ---
apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-registries
  namespace: multicluster-engine
  labels:
    app: assisted-service
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
  registries.conf: |
    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/openshift4"
    mirror-by-digest-only = true

    [[registry.mirror]]
      location = "registry.dns.base.domain.name:5000/openshift4"
    1 
    

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/rhacm2"
    mirror-by-digest-only = true
    ...
    ...
    Copy to Clipboard Toggle word wrap
    1
    dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

    오브젝트에는 다음 두 개의 필드가 있습니다.

    • 사용자 정의 CA: 이 필드에는 배포의 다양한 프로세스에 로드되는 CA(인증 기관)가 포함되어 있습니다.
    • Registry: Registries.conf 필드에는 원래 소스 레지스트리가 아닌 미러 레지스트리에서 사용해야 하는 이미지 및 네임스페이스에 대한 정보가 포함되어 있습니다.

  2. 다음 예와 같이 AssistedServiceConfig 오브젝트를 추가하여 Assisted Service를 구성합니다. 

    ---
apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
  annotations:
    unsupported.agent-install.openshift.io/assisted-service-configmap: assisted-service-config
    1 
    
  name: agent
  namespace: multicluster-engine
spec:
  mirrorRegistryRef:
    name: custom-registries
    2 
    
  databaseStorage:
    storageClassName: lvms-vg1
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi
  filesystemStorage:
    storageClassName: lvms-vg1
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 20Gi
  osImages:
    3 
    
  - cpuArchitecture: x86_64
    openshiftVersion: "4.14"
    rootFSUrl: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live-rootfs.x86_64.img
    4 
    
    url: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live.x86_64.iso
    version: 414.92.202308281054-0
    Copy to Clipboard Toggle word wrap
    1
    metadata.annotations["unsupported.agent-install.openshift.io/assisted-service-configmap"] 주석은 Operator가 동작을 사용자 정의하는 데 사용하는 구성 맵 이름을 참조합니다.
    2
    spec.mirrorRegistryRef.name 주석은 Assisted Service Operator가 사용하는 연결이 끊긴 레지스트리 정보가 포함된 구성 맵을 가리킵니다. 이 구성 맵은 배포 프로세스 중에 해당 리소스를 추가합니다.
    3
    spec.osImages 필드에는 이 Operator에서 배포할 수 있는 다양한 버전이 포함되어 있습니다. 이 필드는 필수입니다. 이 예제에서는 이미 RootFS 및 LiveISO 파일을 다운로드했다고 가정합니다.
    4
    rootFSUrl 및 url 필드에서 dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

  3. 해당 오브젝트를 단일 파일에 연결하고 관리 클러스터에 적용하여 모든 오브젝트를 배포합니다. 이렇게 하려면 다음 명령을 입력합니다. 

    oc apply -f agentServiceConfig.yaml
    Copy to Clipboard Toggle word wrap

    이 명령은 이 예제 출력에 표시된 대로 두 개의 Pod를 트리거합니다. 

    assisted-image-service-0                               1/1     Running   2             11d
    1 
    
assisted-service-668b49548-9m7xw                       2/2     Running   5             11d
    2
    Copy to Clipboard Toggle word wrap
    1
    assisted-image-service Pod는 배포하는 각 클러스터에 대해 사용자 지정되는 RHCOS(Red Hat Enterprise Linux CoreOS) 부팅 이미지 템플릿을 생성합니다.
    2
    assisted-service 는 Operator를 나타냅니다.
1.7.10.6.8. IPv6 네트워크에 대한 TLS 인증서 구성
링크 복사

연결이 끊긴 환경에서 호스팅된 컨트롤 플레인을 구성하는 프로세스에 여러 TLS 인증서가 포함됩니다. 관리 클러스터에 CA(인증 기관)를 추가하려면 OpenShift Container Platform 컨트롤 플레인 및 작업자 노드에서 다음 파일의 내용을 수정해야 합니다.

  • /etc/pki/ca-trust/extracted/pem/
  • /etc/pki/ca-trust/source/anchors
  • /etc/pki/tls/certs/

관리 클러스터에 CA를 추가하려면 다음 단계를 완료합니다.

  1. 공식 OpenShift Container Platform 설명서에서 CA 번들 업데이트 단계를 완료합니다. 이 방법은 CA를 OpenShift Container Platform 노드에 배포하는 image-registry-operator 를 사용하는 것입니다.

  2. 해당 방법이 상황에 적용되지 않는 경우 관리 클러스터의 openshift-config 네임스페이스에 user-ca-bundle 이라는 구성 맵이 포함되어 있는지 확인합니다.

    • 네임스페이스에 해당 구성 맵이 포함된 경우 다음 명령을 입력합니다. 

      ## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE>
export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt

oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${REGISTRY_CERT_PATH}
      Copy to Clipboard Toggle word wrap

    • 네임스페이스에 해당 구성 맵이 포함되지 않은 경우 다음 명령을 입력합니다. 

      ## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE>
export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt
export TMP_FILE=$(mktemp)

oc get cm -n openshift-config user-ca-bundle -ojsonpath='{.data.ca-bundle\.crt}' > ${TMP_FILE}
echo >> ${TMP_FILE}
echo \#registry.$(hostname --long) >> ${TMP_FILE}
cat ${REGISTRY_CERT_PATH} >> ${TMP_FILE}
oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${TMP_FILE} --dry-run=client -o yaml | kubectl apply -f -
      Copy to Clipboard Toggle word wrap
1.7.10.6.9. IPv6 네트워크에 대해 호스트된 클러스터 배포
링크 복사

호스팅 클러스터는 관리 클러스터에서 호스팅되는 컨트롤 플레인 및 API 끝점이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 클러스터에는 컨트롤 플레인과 해당 데이터 플레인이 포함됩니다.

Red Hat Advanced Cluster Management에서 콘솔을 사용하여 호스트 클러스터를 생성할 수 있지만 다음 절차에서는 관련 아티팩트를 수정하는 데 더 유연하게 사용할 수 있는 매니페스트를 사용합니다.

1.7.10.6.9.1. 호스트된 클러스터 오브젝트 배포
링크 복사

이 절차의 목적을 위해 다음 값이 사용됩니다.

  • HostedCluster 이름: hosted-ipv6
  • HostedCluster 네임스페이스: 클러스터
  • disconnected: true
  • 네트워크 스택: IPv6

일반적으로 HyperShift Operator는 HostedControlPlane 네임스페이스를 생성합니다. 그러나 이 경우 HyperShift Operator가 HostedCluster 오브젝트를 조정하기 전에 모든 오브젝트를 포함해야 합니다. 그러면 Operator가 조정 프로세스를 시작하면 모든 오브젝트를 찾을 수 있습니다.

  1. 네임스페이스에 대한 다음 정보를 사용하여 YAML 파일을 생성합니다. 

    ---
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: clusters-hosted-ipv6
spec: {}
status: {}
---
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: clusters
spec: {}
status: {}
    Copy to Clipboard Toggle word wrap

  2. HostedCluster 배포에 포함할 구성 맵 및 시크릿에 대한 다음 정보를 사용하여 YAML 파일을 생성합니다. 

    ---
apiVersion: v1
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: clusters
---
apiVersion: v1
data:
  .dockerconfigjson: xxxxxxxxx
kind: Secret
metadata:
  creationTimestamp: null
  name: hosted-ipv6-pull-secret
  namespace: clusters
---
apiVersion: v1
kind: Secret
metadata:
  name: sshkey-cluster-hosted-ipv6
  namespace: clusters
stringData:
  id_rsa.pub: ssh-rsa xxxxxxxxx
---
apiVersion: v1
data:
  key: nTPtVBEt03owkrKhIdmSW8jrWRxU57KO/fnZa8oaG0Y=
kind: Secret
metadata:
  creationTimestamp: null
  name: hosted-ipv6-etcd-encryption-key
  namespace: clusters
type: Opaque
    Copy to Clipboard Toggle word wrap

  3. 지원 서비스 에이전트가 호스팅된 컨트롤 플레인과 동일한 HostedControlPlane 네임스페이스에 있을 수 있고 클러스터 API에서 계속 관리할 수 있도록 RBAC 역할이 포함된 YAML 파일을 생성합니다. 

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: capi-provider-role
  namespace: clusters-hosted-ipv6
rules:
- apiGroups:
  - agent-install.openshift.io
  resources:
  - agents
  verbs:
  - '*'
    Copy to Clipboard Toggle word wrap

  4. 필요에 따라 값을 교체하여 HostedCluster 오브젝트에 대한 정보를 사용하여 YAML 파일을 생성합니다. 

    apiVersion: hypershift.openshift.io/v1beta1
kind: HostedCluster
metadata:
  name: hosted-ipv6
  namespace: clusters
  annotations:
    hypershift.openshift.io/control-plane-operator-image: registry.ocp-edge-cluster-0.qe.lab.redhat.com:5005/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
spec:
  additionalTrustBundle:
    name: "user-ca-bundle"
  olmCatalogPlacement: guest
  imageContentSources:
    1 
    
  - source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
    mirrors:
    - registry.dns.base.domain.name:5000/openshift/release
  - source: quay.io/openshift-release-dev/ocp-release
    mirrors:
    - registry.dns.base.domain.name:5000/openshift/release-images
  - mirrors:
  ...
  ...
  autoscaling: {}
  controllerAvailabilityPolicy: SingleReplica
  dns:
    baseDomain: dns.base.domain.name
  etcd:
    managed:
      storage:
        persistentVolume:
          size: 8Gi
        restoreSnapshotURL: null
        type: PersistentVolume
    managementType: Managed
  fips: false
  networking:
    clusterNetwork:
    - cidr: 10.132.0.0/14
    networkType: OVNKubernetes
    serviceNetwork:
    - cidr: 172.31.0.0/16
  platform:
    agent:
      agentNamespace: clusters-hosted-ipv6
    type: Agent
  pullSecret:
    name: hosted-ipv6-pull-secret
  release:
    image: registry.dns.base.domain.name:5000/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237
  secretEncryption:
    aescbc:
      activeKey:
        name: hosted-ipv6-etcd-encryption-key
    type: aescbc
  services:
  - service: APIServer
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv6.dns.base.domain.name
      type: NodePort
  - service: OAuthServer
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv6.dns.base.domain.name
      type: NodePort
  - service: OIDC
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv6.dns.base.domain.name
      type: NodePort
  - service: Konnectivity
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv6.dns.base.domain.name
      type: NodePort
  - service: Ignition
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv6.dns.base.domain.name
      type: NodePort
  sshKey:
    name: sshkey-cluster-hosted-ipv6
status:
  controlPlaneEndpoint:
    host: ""
    port: 0
    Copy to Clipboard Toggle word wrap

    여기서 dns.base.domain.name 은 DNS 기본 도메인 이름입니다.

    1
    imageContentSources 섹션에는 호스팅된 클러스터 내의 사용자 워크로드에 대한 미러 참조가 포함되어 있습니다.

  5. OpenShift Container Platform 릴리스의 HyperShift Operator 릴리스를 가리키는 HostedCluster 오브젝트에 주석을 추가합니다.

    1. 다음 명령을 입력하여 이미지 페이로드를 가져옵니다. 

      oc adm release info registry.dns.base.domain.name:5000/openshift-release-dev/ocp-release:4.14.0-rc.1-x86_64 | grep hypershift
      Copy to Clipboard Toggle word wrap

      여기서 dns.base.domain.name 은 DNS 기본 도메인 이름입니다.

    2. 다음 출력을 참조하십시오. 

      hypershift                                     sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
      Copy to Clipboard Toggle word wrap

    3. OpenShift Container Platform 이미지 네임스페이스를 사용하여 다음 명령을 입력하여 다이제스트를 확인합니다. 

      podman pull registry.dns.base.domain.name:5000/openshift-release-dev/ocp-v4.0-art-dev@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
      Copy to Clipboard Toggle word wrap

      여기서 dns.base.domain.name 은 DNS 기본 도메인 이름입니다.

    4. 다음 출력을 참조하십시오. 

      podman pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
Trying to pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8...
Getting image source signatures
Copying blob d8190195889e skipped: already exists
Copying blob c71d2589fba7 skipped: already exists
Copying blob d4dc6e74b6ce skipped: already exists
Copying blob 97da74cc6d8f skipped: already exists
Copying blob b70007a560c9 done
Copying config 3a62961e6e done
Writing manifest to image destination
Storing signatures
3a62961e6ed6edab46d5ec8429ff1f41d6bb68de51271f037c6cb8941a007fde
      Copy to Clipboard Toggle word wrap

    참고: HostedCluster 오브젝트에 설정된 릴리스 이미지는 태그가 아닌 다이제스트를 사용해야 합니다. 예를 들어 quay.io/openshift-release-dev/ocp-release@sha256:e3ba11bd1e5e8ea5a0b36a75791c90f29afb0fdbe4125be4e48f69c76a5c.

  6. YAML 파일에 정의된 모든 오브젝트를 파일에 연결하고 관리 클러스터에 적용하여 해당 오브젝트를 생성합니다. 이렇게 하려면 다음 명령을 입력합니다. 

    oc apply -f 01-4.14-hosted_cluster-nodeport.yaml
    Copy to Clipboard Toggle word wrap

  7. 호스트된 컨트롤 플레인의 출력을 참조하십시오. 

    NAME                                                  READY   STATUS    RESTARTS   AGE
capi-provider-5b57dbd6d5-pxlqc                        1/1     Running   0          3m57s
catalog-operator-9694884dd-m7zzv                      2/2     Running   0          93s
cluster-api-f98b9467c-9hfrq                           1/1     Running   0          3m57s
cluster-autoscaler-d7f95dd5-d8m5d                     1/1     Running   0          93s
cluster-image-registry-operator-5ff5944b4b-648ht      1/2     Running   0          93s
cluster-network-operator-77b896ddc-wpkq8              1/1     Running   0          94s
cluster-node-tuning-operator-84956cd484-4hfgf         1/1     Running   0          94s
cluster-policy-controller-5fd8595d97-rhbwf            1/1     Running   0          95s
cluster-storage-operator-54dcf584b5-xrnts             1/1     Running   0          93s
cluster-version-operator-9c554b999-l22s7              1/1     Running   0          95s
control-plane-operator-6fdc9c569-t7hr4                1/1     Running   0          3m57s
csi-snapshot-controller-785c6dc77c-8ljmr              1/1     Running   0          77s
csi-snapshot-controller-operator-7c6674bc5b-d9dtp     1/1     Running   0          93s
csi-snapshot-webhook-5b8584875f-2492j                 1/1     Running   0          77s
dns-operator-6874b577f-9tc6b                          1/1     Running   0          94s
etcd-0                                                3/3     Running   0          3m39s
hosted-cluster-config-operator-f5cf5c464-4nmbh        1/1     Running   0          93s
ignition-server-6b689748fc-zdqzk                      1/1     Running   0          95s
ignition-server-proxy-54d4bb9b9b-6zkg7                1/1     Running   0          95s
ingress-operator-6548dc758b-f9gtg                     1/2     Running   0          94s
konnectivity-agent-7767cdc6f5-tw782                   1/1     Running   0          95s
kube-apiserver-7b5799b6c8-9f5bp                       4/4     Running   0          3m7s
kube-controller-manager-5465bc4dd6-zpdlk              1/1     Running   0          44s
kube-scheduler-5dd5f78b94-bbbck                       1/1     Running   0          2m36s
machine-approver-846c69f56-jxvfr                      1/1     Running   0          92s
oauth-openshift-79c7bf44bf-j975g                      2/2     Running   0          62s
olm-operator-767f9584c-4lcl2                          2/2     Running   0          93s
openshift-apiserver-5d469778c6-pl8tj                  3/3     Running   0          2m36s
openshift-controller-manager-6475fdff58-hl4f7         1/1     Running   0          95s
openshift-oauth-apiserver-dbbc5cc5f-98574             2/2     Running   0          95s
openshift-route-controller-manager-5f6997b48f-s9vdc   1/1     Running   0          95s
packageserver-67c87d4d4f-kl7qh                        2/2     Running   0          93s
    Copy to Clipboard Toggle word wrap

  8. 호스트 클러스터의 출력을 참조하십시오. 

    NAMESPACE   NAME         VERSION   KUBECONFIG                PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
clusters    hosted-ipv6            hosted-admin-kubeconfig   Partial    True          False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap

다음으로 NodePool 오브젝트를 생성합니다.

1.7.10.6.9.2. 호스트된 클러스터에 대한 NodePool 오브젝트 생성
링크 복사

NodePool 은 호스팅된 클러스터와 연결된 확장 가능한 작업자 노드 집합입니다. NodePool 머신 아키텍처는 특정 풀 내에서 일관되게 유지되며 컨트롤 플레인의 머신 아키텍처와 독립적입니다.

  1. NodePool 오브젝트에 대한 다음 정보를 사용하여 YAML 파일을 생성하여 필요에 따라 값을 바꿉니다. 

    apiVersion: hypershift.openshift.io/v1beta1
kind: NodePool
metadata:
  creationTimestamp: null
  name: hosted-ipv6
  namespace: clusters
spec:
  arch: amd64
  clusterName: hosted-ipv6
  management:
    autoRepair: false
    1 
    
    upgradeType: InPlace
    2 
    
  nodeDrainTimeout: 0s
  platform:
    type: Agent
  release:
    image: registry.dns.base.domain.name:5000/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237
    3 
    
  replicas: 0
status:
  replicas: 0
    4
    Copy to Clipboard Toggle word wrap
    1
    노드가 제거되면 노드가 다시 생성되지 않기 때문에 autoRepair 필드가 false 로 설정됩니다.
    2
    upgradeType 은 업그레이드 중에 동일한 베어 메탈 노드가 재사용됨을 나타내는 InPlace 로 설정됩니다.
    3
    이 NodePool 에 포함된 모든 노드는 다음 OpenShift Container Platform 버전 4.14.0-0.nightly-2023-08-29-102237 을 기반으로 합니다. dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.
    4
    필요한 경우 스케일링할 수 있도록 replicas 값은 0 으로 설정됩니다. 모든 단계가 완료될 때까지 NodePool 복제본을 0으로 유지하는 것이 중요합니다.

  2. 다음 명령을 입력하여 NodePool 오브젝트를 생성합니다. 

    oc apply -f 02-nodepool.yaml
    Copy to Clipboard Toggle word wrap

  3. 출력을 참조하십시오. 

    NAMESPACE   NAME          CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted-ipv6   hosted    0                               False         False        4.14.0-0.nightly-2023-08-29-102237
    Copy to Clipboard Toggle word wrap

다음으로 InfraEnv 리소스를 생성합니다.

1.7.10.6.9.3. 호스트된 클러스터에 대한 InfraEnv 리소스 생성
링크 복사

InfraEnv 리소스는 pullSecretRef 및 sshAuthorizedKey 와 같은 필수 세부 정보를 포함하는 지원 서비스 오브젝트입니다. 이러한 세부 사항은 호스팅된 클러스터에 대해 사용자 지정된 RHCOS(Red Hat Enterprise Linux CoreOS) 부팅 이미지를 생성하는 데 사용됩니다.

  1. 필요에 따라 값을 교체하여 InfraEnv 리소스에 대한 다음 정보를 사용하여 YAML 파일을 생성합니다. 

    ---
apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: hosted-ipv6
  namespace: clusters-hosted-ipv6
spec:
  pullSecretRef:
    1 
    
    name: pull-secret
  sshAuthorizedKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDk7ICaUE+/k4zTpxLk4+xFdHi4ZuDi5qjeF52afsNkw0w/glILHhwpL5gnp5WkRuL8GwJuZ1VqLC9EKrdmegn4MrmUlq7WTsP0VFOZFBfq2XRUxo1wrRdor2z0Bbh93ytR+ZsDbbLlGngXaMa0Vbt+z74FqlcajbHTZ6zBmTpBVq5RHtDPgKITdpE1fongp7+ZXQNBlkaavaqv8bnyrP4BWahLP4iO9/xJF9lQYboYwEEDzmnKLMW1VtCE6nJzEgWCufACTbxpNS7GvKtoHT/OVzw8ArEXhZXQUS1UY8zKsX2iXwmyhw5Sj6YboA8WICs4z+TrFP89LmxXY0j6536TQFyRz1iB4WWvCbH5n6W+ABV2e8ssJB1AmEy8QYNwpJQJNpSxzoKBjI73XxvPYYC/IjPFMySwZqrSZCkJYqQ023ySkaQxWZT7in4KeMu7eS2tC+Kn4deJ7KwwUycx8n6RHMeD8Qg9flTHCv3gmab8JKZJqN3hW1D378JuvmIX4V0=
    2
    Copy to Clipboard Toggle word wrap
    1
    pullSecretRef 는 가져오기 보안이 사용되는 InfraEnv 와 동일한 네임스페이스에서 구성 맵 참조를 나타냅니다.
    2
    sshAuthorizedKey 는 부팅 이미지에 배치된 SSH 공개 키를 나타냅니다. SSH 키를 사용하면 core 사용자로 작업자 노드에 액세스할 수 있습니다.

  2. 다음 명령을 입력하여 InfraEnv 리소스를 생성합니다. 

    oc apply -f 03-infraenv.yaml
    Copy to Clipboard Toggle word wrap

  3. 다음 출력을 참조하십시오. 

    NAMESPACE              NAME     ISO CREATED AT
clusters-hosted-ipv6   hosted   2023-09-11T15:14:10Z
    Copy to Clipboard Toggle word wrap

다음으로 작업자 노드를 생성합니다.

1.7.10.6.9.4. 호스트된 클러스터의 작업자 노드 생성
링크 복사

베어 메탈 플랫폼에서 작업하는 경우 작업자 노드를 생성하는 것은 BareMetalHost 의 세부 정보가 올바르게 구성되었는지 확인하는 데 중요합니다.

가상 머신으로 작업하는 경우 다음 단계를 완료하여 Metal3 Operator에서 사용하는 빈 작업자 노드를 생성할 수 있습니다. 이렇게 하려면 kcli 툴을 사용합니다.

  1. 이것이 작업자 노드 생성을 처음 시도하지 않은 경우 먼저 이전 설정을 삭제해야 합니다. 이렇게 하려면 다음 명령을 입력하여 계획을 삭제합니다. 

    kcli delete plan hosted-ipv6
    Copy to Clipboard Toggle word wrap
    1. 계획을 삭제할지 여부를 확인하라는 메시지가 표시되면 y 를 입력합니다.
    2. 계획이 삭제되었음을 알리는 메시지가 표시되는지 확인합니다.

  2. 다음 명령을 입력하여 가상 머신을 생성합니다. 

    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv6 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv6\", \"mac\": \"aa:aa:aa:aa:02:11\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0211 -P name=hosted-ipv6-worker0
    Copy to Clipboard Toggle word wrap 
    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv6 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv6\", \"mac\": \"aa:aa:aa:aa:02:12\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0212 -P name=hosted-ipv6-worker1
    Copy to Clipboard Toggle word wrap 
    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv6 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv6\", \"mac\": \"aa:aa:aa:aa:02:13\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0213 -P name=hosted-ipv6-worker2
    Copy to Clipboard Toggle word wrap 
    systemctl restart ksushy
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    • start=False 는 VM(가상 머신)이 생성 시 자동으로 시작되지 않음을 의미합니다.
    • uefi_legacy=true 는 UEFI 레거시 부팅을 사용하여 이전 UEFI 구현과의 호환성을 보장합니다.
    • plan=hosted-dual 은 시스템 그룹을 클러스터로 식별하는 계획 이름을 나타냅니다.
    • memory=8192 및 numcpus=16 은 RAM 및 CPU를 포함하여 VM의 리소스를 지정하는 매개변수입니다.
    • disks=[200,200] 은 VM에 씬 프로비저닝된 두 개의 디스크를 생성 중임을 나타냅니다.
    • nets=[{"name": "dual", "mac": "aa:aa:aa:aa:aa:aa:02:13"}] 은 연결할 네트워크 이름과 기본 인터페이스의 MAC 주소를 포함한 네트워크 세부 정보입니다.
    • ksushy 를 다시 시작하여 ksushy 툴을 다시 시작하여 추가한 VM을 감지합니다.

  3. 결과 출력을 확인합니다. 

    +---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
|         Name        | Status |         Ip        |                       Source                       |     Plan    | Profile |
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
|    hosted-worker0   |  down  |                   |                                                    | hosted-ipv6 |  kvirt  |
|    hosted-worker1   |  down  |                   |                                                    | hosted-ipv6 |  kvirt  |
|    hosted-worker2   |  down  |                   |                                                    | hosted-ipv6 |  kvirt  |
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
    Copy to Clipboard Toggle word wrap

다음으로 호스팅된 클러스터에 대한 베어 메탈 호스트를 생성합니다.

1.7.10.6.9.5. 호스트 클러스터를 위한 베어 메탈 호스트 생성
링크 복사

베어 메탈 호스트 는 Metal3 Operator가 식별할 수 있도록 물리적 및 논리 세부 정보를 포함하는 openshift-machine-api 오브젝트입니다. 이러한 세부 사항은 에이전트 라고 하는 기타 지원 서비스 오브젝트와 연결됩니다.

중요: 베어 메탈 호스트 및 대상 노드를 생성하기 전에 가상 머신을 생성해야 합니다.

베어 메탈 호스트를 생성하려면 다음 단계를 완료합니다.

  1. 다음 정보를 사용하여 YAML 파일을 생성합니다.

    참고: 베어 메탈 호스트 인증 정보를 보유하는 시크릿이 하나 이상 있으므로 각 작업자 노드에 대해 두 개 이상의 오브젝트를 생성해야 합니다. 

    ---
apiVersion: v1
kind: Secret
metadata:
  name: hosted-ipv6-worker0-bmc-secret
  namespace: clusters-hosted-ipv6
data:
  password: YWRtaW4=
  username: YWRtaW4=
type: Opaque
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: hosted-ipv6-worker0
  namespace: clusters-hosted-ipv6
  labels:
    infraenvs.agent-install.openshift.io: hosted-ipv6
    1 
    
  annotations:
    inspect.metal3.io: disabled
    bmac.agent-install.openshift.io/hostname: hosted-ipv6-worker0
    2 
    
spec:
  automatedCleaningMode: disabled
    3 
    
  bmc:
    disableCertificateVerification: true
    4 
    
    address: redfish-virtualmedia://[192.168.125.1]:9000/redfish/v1/Systems/local/hosted-ipv6-worker0
    5 
    
    credentialsName: hosted-ipv6-worker0-bmc-secret
    6 
    
  bootMACAddress: aa:aa:aa:aa:03:11
    7 
    
  online: true
    8
    Copy to Clipboard Toggle word wrap
    1
    infraenvs.agent-install.openshift.io 는 지원 설치 프로그램과 BareMetalHost 오브젝트 간의 링크 역할을 합니다.
    2
    B MAC.agent-install.openshift.io/hostname 은 배포 중에 채택된 노드 이름을 나타냅니다.
    3
    automatedCleaningMode 를 사용하면 Metal3 Operator에 의해 노드가 지워지지 않습니다.
    4
    클라이언트에서 인증서 유효성 검사를 바이패스하려면 disableCertificateVerification 이 true 로 설정됩니다.
    5
    address 는 작업자 노드의 BMC(Baseboard Management Controller) 주소를 나타냅니다.
    6
    credentialsName 은 사용자 및 암호 인증 정보가 저장된 시크릿을 가리킵니다.
    7
    bootMACAddress 는 노드가 시작되는 인터페이스 MAC 주소를 나타냅니다.
    8
    online 은 BareMetalHost 개체가 생성된 후 노드의 상태를 정의합니다.

  2. 다음 명령을 입력하여 BareMetalHost 오브젝트를 배포합니다. 

    oc apply -f 04-bmh.yaml
    Copy to Clipboard Toggle word wrap

    프로세스 중에 다음 출력을 볼 수 있습니다.

    • 이 출력은 프로세스가 노드에 연결을 시도 중임을 나타냅니다. 

      NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   registering              true             2s
clusters-hosted   hosted-worker1   registering              true             2s
clusters-hosted   hosted-worker2   registering              true             2s
      Copy to Clipboard Toggle word wrap

    • 이 출력은 노드가 시작됨을 나타냅니다. 

      NAMESPACE         NAME             STATE          CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   provisioning              true             16s
clusters-hosted   hosted-worker1   provisioning              true             16s
clusters-hosted   hosted-worker2   provisioning              true             16s
      Copy to Clipboard Toggle word wrap
    • 이 출력은 노드가 성공적으로 시작되었음을 나타냅니다. 
    NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   provisioned              true             67s
clusters-hosted   hosted-worker1   provisioned              true             67s
clusters-hosted   hosted-worker2   provisioned              true             67s
    Copy to Clipboard Toggle word wrap

  3. 노드가 시작된 후 다음 예와 같이 네임스페이스의 에이전트를 확인합니다. 

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413             true       auto-assign
    Copy to Clipboard Toggle word wrap

    에이전트는 설치에 사용할 수 있는 노드를 나타냅니다. 호스트 클러스터에 노드를 할당하려면 노드 풀을 확장합니다.

1.7.10.6.9.6. 노드 풀 확장
링크 복사

베어 메탈 호스트를 생성한 후 해당 상태가 Registering 에서 Provisioning (프로비저닝)으로 변경됨. 노드는 에이전트의 LiveISO 및 에이전트 라는 기본 Pod로 시작합니다. 해당 에이전트는 OpenShift Container Platform 페이로드를 설치하기 위해 Assisted Service Operator에서 지침을 받습니다.

  1. 노드 풀을 확장하려면 다음 명령을 입력합니다. 

    oc -n clusters scale nodepool hosted-ipv6 --replicas 3
    Copy to Clipboard Toggle word wrap

  2. 확장 프로세스가 완료되면 에이전트가 호스팅된 클러스터에 할당되어 있습니다. 

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0211   hosted    true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0212   hosted    true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0213   hosted    true       auto-assign
    Copy to Clipboard Toggle word wrap

  3. 또한 노드 풀 복제본이 설정되어 있습니다. 

    NAMESPACE   NAME     CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted   hosted    3                               False         False        4.14.0-0.nightly-2023-08-29-102237                                      Minimum availability requires 3 replicas, current 0 available
    Copy to Clipboard Toggle word wrap
  4. 노드가 클러스터에 참여할 때까지 기다립니다. 프로세스 중에 에이전트는 단계 및 상태에 대한 업데이트를 제공합니다.

다음으로 호스트 클러스터의 배포를 모니터링합니다.

1.7.10.6.10. IPv6 네트워크의 호스트 클러스터 배포 완료
링크 복사

컨트롤 플레인과 데이터 플레인의 두 가지 관점에서 호스팅 클러스터 배포를 모니터링할 수 있습니다.

1.7.10.6.10.1. 컨트롤 플레인 모니터링
링크 복사

호스팅 클러스터를 배포하는 동안 다음 명령을 입력하여 컨트롤 플레인을 모니터링할 수 있습니다. 

export KUBECONFIG=/root/.kcli/clusters/hub-ipv4/auth/kubeconfig
Copy to Clipboard Toggle word wrap 
watch "oc get pod -n hypershift;echo;echo;oc get pod -n clusters-hosted-ipv4;echo;echo;oc get bmh -A;echo;echo;oc get agent -A;echo;echo;oc get infraenv -A;echo;echo;oc get hostedcluster -A;echo;echo;oc get nodepool -A;echo;echo;"
Copy to Clipboard Toggle word wrap

이러한 명령은 다음 아티팩트에 대한 정보를 제공합니다.

  • The HyperShift Operator
  • HostedControlPlane Pod
  • 베어 메탈 호스트
  • 에이전트
  • InfraEnv 리소스
  • HostedCluster 및 NodePool 리소스
1.7.10.6.10.2. 데이터 플레인 모니터링
링크 복사

배포 프로세스 중에 Operator가 진행 중인 방식을 모니터링하려면 다음 명령을 입력합니다. 

oc get secret -n clusters-hosted-ipv4 admin-kubeconfig -o jsonpath='{.data.kubeconfig}' |base64 -d > /root/hc_admin_kubeconfig.yaml
Copy to Clipboard Toggle word wrap 
export KUBECONFIG=/root/hc_admin_kubeconfig.yaml
Copy to Clipboard Toggle word wrap 
watch "oc get clusterversion,nodes,co"
Copy to Clipboard Toggle word wrap

이러한 명령은 다음 아티팩트에 대한 정보를 제공합니다.

  • 클러스터 버전
  • 특히 노드가 클러스터에 참여하는지 여부에 대한 노드
  • 클러스터 Operator

듀얼 스택 네트워크 구성은 현재 연결이 끊긴 것으로 지정됩니다. 이러한 지정의 주요 이유는 원격 레지스트리가 IPv6에서 작동하지 않기 때문입니다.

듀얼 스택 네트워크에서 호스팅되는 컨트롤 플레인을 구성하는 프로세스에는 다음 단계가 포함되며, 다음 섹션에 자세히 설명되어 있습니다.

  1. 듀얼 스택 네트워크에 대한 하이퍼바이저 구성
  2. 듀얼 스택 네트워크에 대한 DNS 구성
  3. 듀얼 스택 네트워크의 레지스트리 배포
  4. 듀얼 스택 네트워크에 대한 관리 클러스터 설정
  5. 듀얼 스택 네트워크에 대한 웹 서버 구성
  6. 듀얼 스택 네트워크의 이미지 미러링 구성
  7. 듀얼 스택 네트워크용 다중 클러스터 엔진 Operator 배포
  8. 듀얼 스택 네트워크에 대한 TLS 인증서 구성
  9. 듀얼 스택 네트워크용 호스트 클러스터 배포
  10. 듀얼 스택 네트워크의 배포 완료
1.7.10.7.1. 듀얼 스택 네트워크에 대한 하이퍼바이저 구성
링크 복사

다음 정보는 가상 머신 환경에만 적용됩니다.

  1. 가상 OpenShift Container Platform 관리 클러스터를 배포하려면 다음 명령을 입력하여 필요한 패키지에 액세스합니다. 

    sudo dnf install dnsmasq radvd vim golang podman bind-utils net-tools httpd-tools tree htop strace tmux -y
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 Podman 서비스를 활성화하고 시작합니다. 

    systemctl enable --now podman
    Copy to Clipboard Toggle word wrap

  3. kcli 를 사용하여 OpenShift Container Platform 관리 클러스터 및 기타 가상 구성 요소를 배포하려면 다음 명령을 입력하여 하이퍼바이저를 설치 및 구성합니다. 

    sudo yum -y install libvirt libvirt-daemon-driver-qemu qemu-kvm
    Copy to Clipboard Toggle word wrap 
    sudo usermod -aG qemu,libvirt $(id -un)
    Copy to Clipboard Toggle word wrap 
    sudo newgrp libvirt
    Copy to Clipboard Toggle word wrap 
    sudo systemctl enable --now libvirtd
    Copy to Clipboard Toggle word wrap 
    sudo dnf -y copr enable karmab/kcli
    Copy to Clipboard Toggle word wrap 
    sudo dnf -y install kcli
    Copy to Clipboard Toggle word wrap 
    sudo kcli create pool -p /var/lib/libvirt/images default
    Copy to Clipboard Toggle word wrap 
    kcli create host kvm -H 127.0.0.1 local
    Copy to Clipboard Toggle word wrap 
    sudo setfacl -m u:$(id -un):rwx /var/lib/libvirt/images
    Copy to Clipboard Toggle word wrap 
    kcli create network  -c 192.168.122.0/24 default
    Copy to Clipboard Toggle word wrap
1.7.10.7.1.2. 네트워크 관리자 디스패처 활성화
링크 복사

  1. 네트워크 관리자 디스패처를 활성화하여 가상 머신이 필요한 도메인, 경로 및 레지스트리를 확인할 수 있는지 확인합니다. 네트워크 관리자 디스패처를 활성화하려면 /etc/NetworkManager/dispatcher.d/ 디렉터리에서 다음 콘텐츠가 포함된 forcedns 라는 스크립트를 생성하여 환경에 맞게 값을 교체하십시오. 

    #!/bin/bash

export IP="192.168.126.1"
    1 
    
export BASE_RESOLV_CONF="/run/NetworkManager/resolv.conf"

if ! [[ `grep -q "$IP" /etc/resolv.conf` ]]; then
export TMP_FILE=$(mktemp /etc/forcedns_resolv.conf.XXXXXX)
cp $BASE_RESOLV_CONF $TMP_FILE
chmod --reference=$BASE_RESOLV_CONF $TMP_FILE
sed -i -e "s/dns.base.domain.name//" -e "s/search /& dns.base.domain.name /" -e "0,/nameserver/s/nameserver/& $IP\n&/" $TMP_FILE
    2 
    
mv $TMP_FILE /etc/resolv.conf
fi
echo "ok"
    Copy to Clipboard Toggle word wrap
    1
    OpenShift Container Platform 관리 클러스터를 호스팅하는 하이퍼바이저 인터페이스의 IP 주소를 가리키도록 IP 변수를 수정합니다.
    2
    dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

  2. 파일을 생성한 후 다음 명령을 입력하여 권한을 추가합니다. 

    chmod 755 /etc/NetworkManager/dispatcher.d/forcedns
    Copy to Clipboard Toggle word wrap
  3. 스크립트를 실행하고 출력이 ok 를 반환하는지 확인합니다.
1.7.10.7.1.3. BMC 액세스 구성
링크 복사

  1. 가상 머신의 BMC(Baseboard Management Controller)를 시뮬레이션하도록 ksushy 를 구성합니다. 다음 명령을 입력합니다. 

    sudo dnf install python3-pyOpenSSL.noarch python3-cherrypy -y
    Copy to Clipboard Toggle word wrap 
    kcli create sushy-service --ssl --ipv6 --port 9000
    Copy to Clipboard Toggle word wrap 
    sudo systemctl daemon-reload
    Copy to Clipboard Toggle word wrap 
    systemctl enable --now ksushy
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 서비스가 올바르게 작동하는지 테스트합니다. 

    systemctl status ksushy
    Copy to Clipboard Toggle word wrap
1.7.10.7.1.4. 연결을 허용하도록 하이퍼바이저 시스템 구성
링크 복사

개발 환경에서 작업하는 경우 환경 내에서 다양한 가상 네트워크를 통한 다양한 유형의 연결을 허용하도록 하이퍼바이저 시스템을 구성합니다.

참고: 프로덕션 환경에서 작업하는 경우 firewalld 서비스에 대한 적절한 규칙을 설정하고 안전한 환경을 유지 관리하도록 SELinux 정책을 구성해야 합니다.

  • SELinux의 경우 다음 명령을 입력합니다. 

    sed -i s/^SELINUX=.*$/SELINUX=permissive/ /etc/selinux/config; setenforce 0
    Copy to Clipboard Toggle word wrap

  • firewalld 의 경우 다음 명령을 입력합니다. 

    systemctl disable --now firewalld
    Copy to Clipboard Toggle word wrap

  • libvirtd 의 경우 다음 명령을 입력합니다. 

    systemctl restart libvirtd
    Copy to Clipboard Toggle word wrap 
    systemctl enable --now libvirtd
    Copy to Clipboard Toggle word wrap

다음으로 환경에 맞게 DNS를 구성합니다.

1.7.10.7.1.5. 추가 리소스
링크 복사
1.7.10.7.2. 듀얼 스택 네트워크에 대한 DNS 구성
링크 복사

이 단계는 가상 및 베어 메탈 환경 모두에서 연결이 끊긴 환경과 연결된 환경 모두에 필요합니다. 가상 환경과 베어 메탈 환경 간의 주요 차이점은 리소스를 구성하는 위치에 있습니다. 비가상 환경에서 dnsmasq 와 같은 경량 솔루션을 사용하는 대신 바인딩과 같은 솔루션을 사용하십시오.

다음으로 레지스트리를 배포합니다.

1.7.10.7.3. 듀얼 스택 네트워크의 레지스트리 배포
링크 복사

개발 환경의 경우 Podman 컨테이너를 사용하여 소규모 자체 호스팅 레지스트리를 배포합니다. 프로덕션 환경의 경우 Red Hat Quay, Nexus 또는 Artifactory와 같은 엔터프라이즈 호스팅 레지스트리를 배포합니다.

Podman을 사용하여 작은 레지스트리를 배포하려면 다음 단계를 완료합니다.

  1. 권한 있는 사용자로 ${HOME} 디렉터리에 액세스하고 다음 스크립트를 생성합니다. 

    #!/usr/bin/env bash

set -euo pipefail

PRIMARY_NIC=$(ls -1 /sys/class/net | grep -v podman | head -1)
export PATH=/root/bin:$PATH
export PULL_SECRET="/root/baremetal/hub/openshift_pull.json"
    1 
    

if [[ ! -f $PULL_SECRET ]];then
  echo "Pull Secret not found, exiting..."
  exit 1
fi

dnf -y install podman httpd httpd-tools jq skopeo libseccomp-devel
export IP=$(ip -o addr show $PRIMARY_NIC | head -1 | awk '{print $4}' | cut -d'/' -f1)
REGISTRY_NAME=registry.$(hostname --long)
REGISTRY_USER=dummy
REGISTRY_PASSWORD=dummy
KEY=$(echo -n $REGISTRY_USER:$REGISTRY_PASSWORD | base64)
echo "{\"auths\": {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\", \"email\": \"sample-email@domain.ltd\"}}}" > /root/disconnected_pull.json
mv ${PULL_SECRET} /root/openshift_pull.json.old
jq ".auths += {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\",\"email\": \"sample-email@domain.ltd\"}}" < /root/openshift_pull.json.old > $PULL_SECRET
mkdir -p /opt/registry/{auth,certs,data,conf}
cat <<EOF > /opt/registry/conf/config.yml
version: 0.1
log:
  fields:
    service: registry
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry
  delete:
    enabled: true
http:
  addr: :5000
  headers:
    X-Content-Type-Options: [nosniff]
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3
compatibility:
  schema1:
    enabled: true
EOF
openssl req -newkey rsa:4096 -nodes -sha256 -keyout /opt/registry/certs/domain.key -x509 -days 3650 -out /opt/registry/certs/domain.crt -subj "/C=US/ST=Madrid/L=San Bernardo/O=Karmalabs/OU=Guitar/CN=$REGISTRY_NAME" -addext "subjectAltName=DNS:$REGISTRY_NAME"
cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract
htpasswd -bBc /opt/registry/auth/htpasswd $REGISTRY_USER $REGISTRY_PASSWORD
podman create --name registry --net host --security-opt label=disable --replace -v /opt/registry/data:/var/lib/registry:z -v /opt/registry/auth:/auth:z -v /opt/registry/conf/config.yml:/etc/docker/registry/config.yml -e "REGISTRY_AUTH=htpasswd" -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry" -e "REGISTRY_HTTP_SECRET=ALongRandomSecretForRegistry" -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd -v /opt/registry/certs:/certs:z -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key docker.io/library/registry:latest
[ "$?" == "0" ] || !!
systemctl enable --now registry
    Copy to Clipboard Toggle word wrap
    1
    PULL_SECRET 위치를 설정에 적합한 위치로 교체합니다.

  2. 스크립트 파일 이름을 registry.sh 로 지정하고 저장합니다. 스크립트를 실행하면 다음 정보를 가져옵니다.

    • 하이퍼바이저 호스트 이름을 기반으로 하는 레지스트리 이름
    • 필요한 인증 정보 및 사용자 액세스 세부 정보

  3. 다음과 같이 실행 플래그를 추가하여 권한을 조정합니다. 

    chmod u+x ${HOME}/registry.sh
    Copy to Clipboard Toggle word wrap

  4. 매개변수 없이 스크립트를 실행하려면 다음 명령을 입력합니다. 

    ${HOME}/registry.sh
    Copy to Clipboard Toggle word wrap

    스크립트가 서버를 시작합니다.

  5. 스크립트는 관리 목적으로 systemd 서비스를 사용합니다. 스크립트를 관리해야 하는 경우 다음 명령을 사용할 수 있습니다. 

    systemctl status
    Copy to Clipboard Toggle word wrap 
    systemctl start
    Copy to Clipboard Toggle word wrap 
    systemctl stop
    Copy to Clipboard Toggle word wrap

레지스트리의 루트 폴더는 /opt/registry 디렉터리에 있으며 다음 하위 디렉터리가 포함되어 있습니다.

  • 인증서에는 TLS 인증서가 포함되어 있습니다.
  • auth 에는 인증 정보가 포함됩니다.
  • 데이터에 는 레지스트리 이미지가 포함되어 있습니다.
  • conf 에는 레지스트리 구성이 포함되어 있습니다.
1.7.10.7.4. 듀얼 스택 네트워크의 관리 클러스터 설정
링크 복사

OpenShift Container Platform 관리 클러스터를 설정하려면 dev-scripts를 사용하거나 가상 머신을 기반으로 하는 경우 kcli 툴을 사용할 수 있습니다. 다음 지침은 kcli 툴에 따라 다릅니다.

  1. 하이퍼바이저에서 적절한 네트워크를 사용할 준비가 되었는지 확인합니다. 네트워크는 관리 및 호스팅 클러스터를 모두 호스팅합니다. 다음 kcli 명령을 입력합니다. 

    kcli create network -c 192.168.126.0/24 -P dhcp=false -P dns=false -d 2620:52:0:1306::0/64 --domain dns.base.domain.name --nodhcp dual
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    • -c 는 네트워크의 CIDR을 지정합니다.
    • -P dhcp=false 는 DHCP를 비활성화하도록 네트워크를 구성하며, 구성한 dnsmasq 에서 처리합니다.
    • -P dns=false 는 DNS를 비활성화하도록 네트워크를 구성하며, 구성한 dnsmasq 에서도 처리합니다.
    • --domain 은 검색할 도메인을 설정합니다.
    • DNS.base.domain.name 은 DNS 기본 도메인 이름입니다.
    • Dual 은 생성 중인 네트워크의 이름입니다.

  2. 네트워크가 생성되면 다음 출력을 검토합니다. 

    [root@hypershiftbm ~]# kcli list network
Listing Networks...
+---------+--------+---------------------+-------+------------------+------+
| Network |  Type  |         Cidr        |  Dhcp |      Domain      | Mode |
+---------+--------+---------------------+-------+------------------+------+
| default | routed |   192.168.122.0/24  |  True |     default      | nat  |
| ipv4    | routed | 2620:52:0:1306::/64 | False | dns.base.domain.name | nat  |
| ipv4    | routed |   192.168.125.0/24  | False | dns.base.domain.name | nat  |
| ipv6    | routed | 2620:52:0:1305::/64 | False | dns.base.domain.name | nat  |
+---------+--------+---------------------+-------+------------------+------+
    Copy to Clipboard Toggle word wrap 
    [root@hypershiftbm ~]# kcli info network ipv6
Providing information about network ipv6...
cidr: 2620:52:0:1306::/64
dhcp: false
domain: dns.base.domain.name
mode: nat
plan: kvirt
type: routed
    Copy to Clipboard Toggle word wrap

  3. OpenShift Container Platform 관리 클러스터를 배포할 수 있도록 풀 시크릿 및 kcli 계획 파일이 있는지 확인합니다.

    1. 풀 시크릿이 kcli 계획과 동일한 폴더에 있고 풀 시크릿 파일의 이름이 openshift_pull.json 인지 확인합니다.
    2. mgmt-compact-hub-dual.yaml 파일에서 OpenShift Container Platform 정의가 포함된 kcli 계획을 추가합니다. 해당 환경과 일치하도록 파일 콘텐츠를 업데이트해야 합니다. 
    plan: hub-dual
force: true
version: nightly
tag: "4.14.0-0.nightly-2023-08-29-102237"
cluster: "hub-dual"
dualstack: true
domain: dns.base.domain.name
api_ip: 192.168.126.10
ingress_ip: 192.168.126.11
service_networks:
- 172.30.0.0/16
- fd02::/112
cluster_networks:
- 10.132.0.0/14
- fd01::/48
disconnected_url: registry.dns.base.domain.name:5000
disconnected_update: true
disconnected_user: dummy
disconnected_password: dummy
disconnected_operators_version: v4.14
disconnected_operators:
- name: metallb-operator
- name: lvms-operator
  channels:
  - name: stable-4.13
disconnected_extra_images:
- quay.io/user-name/trbsht:latest
- quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3
- registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
dualstack: true
disk_size: 200
extra_disks: [200]
memory: 48000
numcpus: 16
ctlplanes: 3
workers: 0
manifests: extra-manifests
metal3: true
network: dual
users_dev: developer
users_devpassword: developer
users_admin: admin
users_adminpassword: admin
metallb_pool: dual-virtual-network
metallb_ranges:
- 192.168.126.150-192.168.126.190
metallb_autoassign: true
apps:
- users
- lvms-operator
- metallb-operator
vmrules:
- hub-bootstrap:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:10:07
- hub-ctlplane-0:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:10:01
- hub-ctlplane-1:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:10:02
- hub-ctlplane-2:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:10:03
    Copy to Clipboard Toggle word wrap

  4. 관리 클러스터를 프로비저닝하려면 다음 명령을 입력합니다. 

    kcli create cluster openshift --pf mgmt-compact-hub-dual.yaml
    Copy to Clipboard Toggle word wrap

다음으로 웹 서버를 구성합니다.

1.7.10.7.4.1. 추가 리소스
링크 복사
  • kcli 계획 파일의 매개변수에 대한 자세한 내용은 공식 kcli 문서의 parameters.yml 만들기 를 참조하십시오.
1.7.10.7.5. 듀얼 스택 네트워크에 대한 웹 서버 구성
링크 복사

호스트 클러스터로 배포 중인 OpenShift Container Platform 릴리스와 연결된 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 호스팅하도록 추가 웹 서버를 구성해야 합니다.

웹 서버를 구성하려면 다음 단계를 완료합니다.

  1. 다음 명령을 입력하여 사용할 OpenShift Container Platform 릴리스에서 openshift-install 바이너리를 추출합니다. 

    oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
    Copy to Clipboard Toggle word wrap

  2. 다음 스크립트를 실행합니다. 이 스크립트는 /opt/srv 디렉터리에 폴더를 생성합니다. 폴더에는 작업자 노드를 프로비저닝하는 RHCOS 이미지가 포함되어 있습니다. 

    #!/bin/bash

WEBSRV_FOLDER=/opt/srv
ROOTFS_IMG_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.pxe.rootfs.location')"
    1 
    
LIVE_ISO_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.iso.disk.location')"
    2 
    

mkdir -p ${WEBSRV_FOLDER}/images
curl -Lk ${ROOTFS_IMG_URL} -o ${WEBSRV_FOLDER}/images/${ROOTFS_IMG_URL##*/}
curl -Lk ${LIVE_ISO_URL} -o ${WEBSRV_FOLDER}/images/${LIVE_ISO_URL##*/}
chmod -R 755 ${WEBSRV_FOLDER}/*

## Run Webserver
podman ps --noheading | grep -q websrv-ai
if [[ $? == 0 ]];then
    echo "Launching Registry pod..."
    /usr/bin/podman run --name websrv-ai --net host -v /opt/srv:/usr/local/apache2/htdocs:z quay.io/alosadag/httpd:p8080
fi
    Copy to Clipboard Toggle word wrap
    1
    ROOTFS_IMG_URL 값은 OpenShift CI 릴리스 페이지에서 찾을 수 있습니다.
    2
    LIVE_ISO_URL 값은 OpenShift CI 릴리스 페이지에서 확인할 수 있습니다.

다운로드가 완료되면 컨테이너가 실행되어 웹 서버에서 이미지를 호스팅합니다. 컨테이너는 공식 HTTPd 이미지의 변형을 사용하여 IPv6 네트워크에서도 작업할 수 있습니다.

1.7.10.7.6. 듀얼 스택 네트워크의 이미지 미러링 구성
링크 복사

이미지 미러링은 registry.redhat.com 또는 quay.io 와 같은 외부 레지스트리에서 이미지를 가져와서 프라이빗 레지스트리에 저장하는 프로세스입니다.

1.7.10.7.6.1. 미러링 프로세스 완료
링크 복사

참고: 레지스트리 서버가 실행된 후 미러링 프로세스를 시작합니다.

다음 절차에서는 ImageSetConfiguration 오브젝트를 사용하는 바이너리인 oc-mirror 툴이 사용됩니다. 파일에서 다음 정보를 지정할 수 있습니다.

  • 미러링할 OpenShift Container Platform 버전입니다. 버전은 quay.io 에 있습니다.
  • 미러링할 추가 Operator입니다. 패키지를 개별적으로 선택합니다.
  • 리포지토리에 추가할 추가 이미지입니다.

이미지 미러링을 구성하려면 다음 단계를 완료합니다.

  1. 이미지를 푸시하려는 프라이빗 레지스트리와 미러링할 레지스트리를 사용하여 ${HOME}/.docker/config.json 파일이 업데이트되었는지 확인합니다.

  2. 다음 예제를 사용하여 미러링에 사용할 ImageSetConfiguration 오브젝트를 만듭니다. 환경에 맞게 필요에 따라 값을 바꿉니다. 

    apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
  registry:
    imageURL: registry.dns.base.domain.name:5000/openshift/release/metadata:latest
mirror:
  platform:
    channels:
    - name: candidate-4.14
      minVersion: 4.14.0-ec.1
      maxVersion: 4.14.0-ec.3
      type: ocp
    graph: true
  additionalImages:
  - name: quay.io/karmab/origin-keepalived-ipfailover:latest
  - name: quay.io/karmab/kubectl:latest
  - name: quay.io/karmab/haproxy:latest
  - name: quay.io/karmab/mdns-publisher:latest
  - name: quay.io/karmab/origin-coredns:latest
  - name: quay.io/karmab/curl:latest
  - name: quay.io/karmab/kcli:latest
  - name: quay.io/user-name/trbsht:latest
  - name: quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3
  - name: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14
    packages:
    - name: lvms-operator
    - name: local-storage-operator
    - name: odf-csi-addons-operator
    - name: odf-operator
    - name: mcg-operator
    - name: ocs-operator
    - name: metallb-operator
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 입력하여 미러링 프로세스를 시작합니다. 

    oc-mirror --source-skip-tls --config imagesetconfig.yaml docker://${REGISTRY}
    Copy to Clipboard Toggle word wrap

    미러링 프로세스가 완료되면 호스트 클러스터에 적용할 ICSP 및 카탈로그 소스가 포함된 oc-mirror-workspace/results-XXXXXX/ 라는 새 폴더가 있습니다.

  4. oc adm release mirror 명령을 사용하여 OpenShift Container Platform의 Nightly 또는 CI 버전을 미러링합니다. 다음 명령을 실행합니다. 

    REGISTRY=registry.$(hostname --long):5000

oc adm release mirror \
  --from=registry.ci.openshift.org/ocp/release:4.14.0-0.nightly-2023-08-29-102237 \
  --to=${REGISTRY}/openshift/release \
  --to-release-image=${REGISTRY}/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237
    Copy to Clipboard Toggle word wrap
  5. 연결이 끊긴 네트워크에 설치 단계에 따라 최신 다중 클러스터 엔진 Operator 이미지를 미러링합니다.
1.7.10.7.6.2. 관리 클러스터에 오브젝트 적용
링크 복사

미러링 프로세스가 완료되면 관리 클러스터에 두 개의 오브젝트를 적용해야 합니다.

  • Image Content Source Policies (ICSP) 또는 Image Digest 미러 세트(IDMS)
  • 카탈로그 소스

oc-mirror 툴을 사용하는 경우 출력 아티팩트는 oc-mirror-workspace/results-XXXXXX/ 이라는 폴더에 있습니다.

ICSP 또는 IDMS는 노드를 재시작하지 않고 각 노드에서 kubelet을 다시 시작하는 MachineConfig 변경 사항을 시작합니다. 노드가 READY 로 표시되면 새로 생성된 카탈로그 소스를 적용해야 합니다.

카탈로그 소스는 카탈로그 이미지 다운로드 및 처리와 같은 openshift-marketplace Operator에서 작업을 시작하여 해당 이미지에 포함된 모든 PackageManifest 를 검색합니다.

  1. 새 소스를 확인하려면 새 CatalogSource 를 소스로 사용하여 다음 명령을 실행합니다. 

    oc get packagemanifest
    Copy to Clipboard Toggle word wrap

  2. 아티팩트를 적용하려면 다음 단계를 완료합니다.

    1. 다음 명령을 입력하여 ICSP 또는 IDMS 아티팩트를 생성합니다. 

      oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
      Copy to Clipboard Toggle word wrap
    2. 노드가 준비될 때까지 기다린 다음 다음 명령을 입력합니다. 
    oc apply -f catalogSource-XXXXXXXX-index.yaml
    Copy to Clipboard Toggle word wrap

다음으로 다중 클러스터 엔진 Operator를 배포합니다.

1.7.10.7.6.3. 추가 리소스
링크 복사
1.7.10.7.7. 듀얼 스택 네트워크용 다중 클러스터 엔진 Operator 배포
링크 복사

다중 클러스터 엔진 Operator는 공급업체에 클러스터를 배포하는 데 중요한 역할을 합니다. Red Hat Advanced Cluster Management를 이미 설치한 경우 자동으로 설치되므로 다중 클러스터 엔진 Operator를 설치할 필요가 없습니다.

다중 클러스터 엔진 Operator가 설치되어 있지 않은 경우 다음 문서를 검토하여 사전 요구 사항 및 설치 단계를 이해하십시오.

1.7.10.7.7.1. AgentServiceConfig 리소스 배포
링크 복사

AgentServiceConfig 사용자 지정 리소스는 다중 클러스터 엔진 Operator의 일부인 지원 서비스 애드온의 필수 구성 요소입니다. 베어 메탈 클러스터 배포를 담당합니다. 애드온이 활성화되면 AgentServiceConfig 리소스를 배포하여 애드온을 구성합니다.

AgentServiceConfig 리소스를 구성하는 것 외에도 연결이 끊긴 환경에서 다중 클러스터 엔진 Operator가 제대로 작동하는지 확인하기 위해 추가 구성 맵을 포함해야 합니다.

  1. 배포를 사용자 지정하는 연결이 끊긴 세부 정보가 포함된 다음 구성 맵을 추가하여 사용자 정의 레지스트리를 구성합니다. 

    ---
apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-registries
  namespace: multicluster-engine
  labels:
    app: assisted-service
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
  registries.conf: |
    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/openshift4"
    mirror-by-digest-only = true

    [[registry.mirror]]
      location = "registry.dns.base.domain.name:5000/openshift4"
    1 
    

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/rhacm2"
    mirror-by-digest-only = true
    ...
    ...
    Copy to Clipboard Toggle word wrap
    1
    dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

    오브젝트에는 다음 두 개의 필드가 있습니다.

    • 사용자 정의 CA: 이 필드에는 배포의 다양한 프로세스에 로드되는 CA(인증 기관)가 포함되어 있습니다.
    • Registry: Registries.conf 필드에는 원래 소스 레지스트리가 아닌 미러 레지스트리에서 사용해야 하는 이미지 및 네임스페이스에 대한 정보가 포함되어 있습니다.

  2. 다음 예와 같이 AssistedServiceConfig 오브젝트를 추가하여 Assisted Service를 구성합니다. 

    ---
apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
  annotations:
    unsupported.agent-install.openshift.io/assisted-service-configmap: assisted-service-config
    1 
    
  name: agent
  namespace: multicluster-engine
spec:
  mirrorRegistryRef:
    name: custom-registries
    2 
    
  databaseStorage:
    storageClassName: lvms-vg1
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi
  filesystemStorage:
    storageClassName: lvms-vg1
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 20Gi
  osImages:
    3 
    
  - cpuArchitecture: x86_64
    openshiftVersion: "4.14"
    rootFSUrl: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live-rootfs.x86_64.img
    4 
    
    url: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live.x86_64.iso
    version: 414.92.202308281054-0
    Copy to Clipboard Toggle word wrap
    1
    metadata.annotations["unsupported.agent-install.openshift.io/assisted-service-configmap"] 주석은 Operator가 동작을 사용자 정의하는 데 사용하는 구성 맵 이름을 참조합니다.
    2
    spec.mirrorRegistryRef.name 주석은 Assisted Service Operator가 사용하는 연결이 끊긴 레지스트리 정보가 포함된 구성 맵을 가리킵니다. 이 구성 맵은 배포 프로세스 중에 해당 리소스를 추가합니다.
    3
    spec.osImages 필드에는 이 Operator에서 배포할 수 있는 다양한 버전이 포함되어 있습니다. 이 필드는 필수입니다. 이 예제에서는 이미 RootFS 및 LiveISO 파일을 다운로드했다고 가정합니다.
    4
    rootFSUrl 및 url 필드에서 dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

  3. 해당 오브젝트를 단일 파일에 연결하고 관리 클러스터에 적용하여 모든 오브젝트를 배포합니다. 이렇게 하려면 다음 명령을 입력합니다. 

    oc apply -f agentServiceConfig.yaml
    Copy to Clipboard Toggle word wrap

    이 명령은 이 예제 출력에 표시된 대로 두 개의 Pod를 트리거합니다. 

    assisted-image-service-0                               1/1     Running   2             11d
    1 
    
assisted-service-668b49548-9m7xw                       2/2     Running   5             11d
    2
    Copy to Clipboard Toggle word wrap
    1
    assisted-image-service Pod는 배포하는 각 클러스터에 대해 사용자 지정되는 RHCOS(Red Hat Enterprise Linux CoreOS) 부팅 이미지 템플릿을 생성합니다.
    2
    assisted-service 는 Operator를 나타냅니다.
1.7.10.7.8. 듀얼 스택 네트워크에 대한 TLS 인증서 구성
링크 복사

연결이 끊긴 환경에서 호스팅된 컨트롤 플레인을 구성하는 프로세스에 여러 TLS 인증서가 포함됩니다. 관리 클러스터에 CA(인증 기관)를 추가하려면 OpenShift Container Platform 컨트롤 플레인 및 작업자 노드에서 다음 파일의 내용을 수정해야 합니다.

  • /etc/pki/ca-trust/extracted/pem/
  • /etc/pki/ca-trust/source/anchors
  • /etc/pki/tls/certs/

관리 클러스터에 CA를 추가하려면 다음 단계를 완료합니다.

  1. 공식 OpenShift Container Platform 설명서에서 CA 번들 업데이트 단계를 완료합니다. 이 방법은 CA를 OpenShift Container Platform 노드에 배포하는 image-registry-operator 를 사용하는 것입니다.

  2. 해당 방법이 상황에 적용되지 않는 경우 관리 클러스터의 openshift-config 네임스페이스에 user-ca-bundle 이라는 구성 맵이 포함되어 있는지 확인합니다.

    • 네임스페이스에 해당 구성 맵이 포함된 경우 다음 명령을 입력합니다. 

      ## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE>
export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt

oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${REGISTRY_CERT_PATH}
      Copy to Clipboard Toggle word wrap

    • 네임스페이스에 해당 구성 맵이 포함되지 않은 경우 다음 명령을 입력합니다. 

      ## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE>
export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt
export TMP_FILE=$(mktemp)

oc get cm -n openshift-config user-ca-bundle -ojsonpath='{.data.ca-bundle\.crt}' > ${TMP_FILE}
echo >> ${TMP_FILE}
echo \#registry.$(hostname --long) >> ${TMP_FILE}
cat ${REGISTRY_CERT_PATH} >> ${TMP_FILE}
oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${TMP_FILE} --dry-run=client -o yaml | kubectl apply -f -
      Copy to Clipboard Toggle word wrap
1.7.10.7.9. 듀얼 스택 네트워크에 대해 호스트된 클러스터 배포
링크 복사

호스팅 클러스터는 관리 클러스터에서 호스팅되는 컨트롤 플레인 및 API 끝점이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 클러스터에는 컨트롤 플레인과 해당 데이터 플레인이 포함됩니다.

Red Hat Advanced Cluster Management에서 콘솔을 사용하여 호스트 클러스터를 생성할 수 있지만 다음 절차에서는 관련 아티팩트를 수정하는 데 더 유연하게 사용할 수 있는 매니페스트를 사용합니다.

1.7.10.7.9.1. 호스트된 클러스터 오브젝트 배포
링크 복사

이 절차의 목적을 위해 다음 값이 사용됩니다.

  • HostedCluster 이름: hosted-dual
  • HostedCluster 네임스페이스: 클러스터
  • disconnected: true
  • 네트워크 스택: 듀얼

일반적으로 HyperShift Operator는 HostedControlPlane 네임스페이스를 생성합니다. 그러나 이 경우 HyperShift Operator가 HostedCluster 오브젝트를 조정하기 전에 모든 오브젝트를 포함해야 합니다. 그러면 Operator가 조정 프로세스를 시작하면 모든 오브젝트를 찾을 수 있습니다.

  1. 네임스페이스에 대한 다음 정보를 사용하여 YAML 파일을 생성합니다. 

    ---
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: clusters-hosted-dual
spec: {}
status: {}
---
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: clusters
spec: {}
status: {}
    Copy to Clipboard Toggle word wrap

  2. HostedCluster 배포에 포함할 구성 맵 및 시크릿에 대한 다음 정보를 사용하여 YAML 파일을 생성합니다. 

    ---
apiVersion: v1
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: clusters
---
apiVersion: v1
data:
  .dockerconfigjson: xxxxxxxxx
kind: Secret
metadata:
  creationTimestamp: null
  name: hosted-dual-pull-secret
  namespace: clusters
---
apiVersion: v1
kind: Secret
metadata:
  name: sshkey-cluster-hosted-dual
  namespace: clusters
stringData:
  id_rsa.pub: ssh-rsa xxxxxxxxx
---
apiVersion: v1
data:
  key: nTPtVBEt03owkrKhIdmSW8jrWRxU57KO/fnZa8oaG0Y=
kind: Secret
metadata:
  creationTimestamp: null
  name: hosted-dual-etcd-encryption-key
  namespace: clusters
type: Opaque
    Copy to Clipboard Toggle word wrap

  3. 지원 서비스 에이전트가 호스팅된 컨트롤 플레인과 동일한 HostedControlPlane 네임스페이스에 있을 수 있고 클러스터 API에서 계속 관리할 수 있도록 RBAC 역할이 포함된 YAML 파일을 생성합니다. 

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: capi-provider-role
  namespace: clusters-hosted-dual
rules:
- apiGroups:
  - agent-install.openshift.io
  resources:
  - agents
  verbs:
  - '*'
    Copy to Clipboard Toggle word wrap

  4. 필요에 따라 값을 교체하여 HostedCluster 오브젝트에 대한 정보를 사용하여 YAML 파일을 생성합니다. 

    apiVersion: hypershift.openshift.io/v1beta1
kind: HostedCluster
metadata:
  name: hosted-dual
  namespace: clusters
spec:
  additionalTrustBundle:
    name: "user-ca-bundle"
  olmCatalogPlacement: guest
  imageContentSources:
    1 
    
  - source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
    mirrors:
    - registry.dns.base.domain.name:5000/openshift/release
    2 
    
  - source: quay.io/openshift-release-dev/ocp-release
    mirrors:
    - registry.dns.base.domain.name:5000/openshift/release-images
  - mirrors:
  ...
  ...
  autoscaling: {}
  controllerAvailabilityPolicy: SingleReplica
  dns:
    baseDomain: dns.base.domain.name
  etcd:
    managed:
      storage:
        persistentVolume:
          size: 8Gi
        restoreSnapshotURL: null
        type: PersistentVolume
    managementType: Managed
  fips: false
  networking:
    clusterNetwork:
    - cidr: 10.132.0.0/14
    - cidr: fd01::/48
    networkType: OVNKubernetes
    serviceNetwork:
    - cidr: 172.31.0.0/16
    - cidr: fd02::/112
  platform:
    agent:
      agentNamespace: clusters-hosted-dual
    type: Agent
  pullSecret:
    name: hosted-dual-pull-secret
  release:
    image: registry.dns.base.domain.name:5000/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237
  secretEncryption:
    aescbc:
      activeKey:
        name: hosted-dual-etcd-encryption-key
    type: aescbc
  services:
  - service: APIServer
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-dual.dns.base.domain.name
      type: NodePort
  - service: OAuthServer
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-dual.dns.base.domain.name
      type: NodePort
  - service: OIDC
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-dual.dns.base.domain.name
      type: NodePort
  - service: Konnectivity
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-dual.dns.base.domain.name
      type: NodePort
  - service: Ignition
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-dual.dns.base.domain.name
      type: NodePort
  sshKey:
    name: sshkey-cluster-hosted-dual
status:
  controlPlaneEndpoint:
    host: ""
    port: 0
    Copy to Clipboard Toggle word wrap
    1
    imageContentSources 섹션에는 호스팅된 클러스터 내의 사용자 워크로드에 대한 미러 참조가 포함되어 있습니다.
    2
    YAML 파일 전체에서 dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

  5. OpenShift Container Platform 릴리스의 HyperShift Operator 릴리스를 가리키는 HostedCluster 오브젝트에 주석을 추가합니다.

    1. 다음 명령을 입력하여 이미지 페이로드를 가져옵니다. 

      oc adm release info registry.dns.base.domain.name:5000/openshift-release-dev/ocp-release:4.14.0-rc.1-x86_64 | grep hypershift
      Copy to Clipboard Toggle word wrap

      여기서 dns.base.domain.name 은 DNS 기본 도메인 이름입니다.

    2. 다음 출력을 참조하십시오. 

      hypershift                                     sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
      Copy to Clipboard Toggle word wrap

    3. OpenShift Container Platform 이미지 네임스페이스를 사용하여 다음 명령을 입력하여 다이제스트를 확인합니다. 

      podman pull registry.dns.base.domain.name:5000/openshift-release-dev/ocp-v4.0-art-dev@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
      Copy to Clipboard Toggle word wrap

      여기서 dns.base.domain.name 은 DNS 기본 도메인 이름입니다.

    4. 다음 출력을 참조하십시오. 

      podman pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
Trying to pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8...
Getting image source signatures
Copying blob d8190195889e skipped: already exists
Copying blob c71d2589fba7 skipped: already exists
Copying blob d4dc6e74b6ce skipped: already exists
Copying blob 97da74cc6d8f skipped: already exists
Copying blob b70007a560c9 done
Copying config 3a62961e6e done
Writing manifest to image destination
Storing signatures
3a62961e6ed6edab46d5ec8429ff1f41d6bb68de51271f037c6cb8941a007fde
      Copy to Clipboard Toggle word wrap

    참고: HostedCluster 오브젝트에 설정된 릴리스 이미지는 태그가 아닌 다이제스트를 사용해야 합니다. 예를 들어 quay.io/openshift-release-dev/ocp-release@sha256:e3ba11bd1e5e8ea5a0b36a75791c90f29afb0fdbe4125be4e48f69c76a5c.

  6. YAML 파일에 정의된 모든 오브젝트를 파일에 연결하고 관리 클러스터에 적용하여 해당 오브젝트를 생성합니다. 이렇게 하려면 다음 명령을 입력합니다. 

    oc apply -f 01-4.14-hosted_cluster-nodeport.yaml
    Copy to Clipboard Toggle word wrap

  7. 호스트된 컨트롤 플레인의 출력을 참조하십시오. 

    NAME                                                  READY   STATUS    RESTARTS   AGE
capi-provider-5b57dbd6d5-pxlqc                        1/1     Running   0          3m57s
catalog-operator-9694884dd-m7zzv                      2/2     Running   0          93s
cluster-api-f98b9467c-9hfrq                           1/1     Running   0          3m57s
cluster-autoscaler-d7f95dd5-d8m5d                     1/1     Running   0          93s
cluster-image-registry-operator-5ff5944b4b-648ht      1/2     Running   0          93s
cluster-network-operator-77b896ddc-wpkq8              1/1     Running   0          94s
cluster-node-tuning-operator-84956cd484-4hfgf         1/1     Running   0          94s
cluster-policy-controller-5fd8595d97-rhbwf            1/1     Running   0          95s
cluster-storage-operator-54dcf584b5-xrnts             1/1     Running   0          93s
cluster-version-operator-9c554b999-l22s7              1/1     Running   0          95s
control-plane-operator-6fdc9c569-t7hr4                1/1     Running   0          3m57s
csi-snapshot-controller-785c6dc77c-8ljmr              1/1     Running   0          77s
csi-snapshot-controller-operator-7c6674bc5b-d9dtp     1/1     Running   0          93s
csi-snapshot-webhook-5b8584875f-2492j                 1/1     Running   0          77s
dns-operator-6874b577f-9tc6b                          1/1     Running   0          94s
etcd-0                                                3/3     Running   0          3m39s
hosted-cluster-config-operator-f5cf5c464-4nmbh        1/1     Running   0          93s
ignition-server-6b689748fc-zdqzk                      1/1     Running   0          95s
ignition-server-proxy-54d4bb9b9b-6zkg7                1/1     Running   0          95s
ingress-operator-6548dc758b-f9gtg                     1/2     Running   0          94s
konnectivity-agent-7767cdc6f5-tw782                   1/1     Running   0          95s
kube-apiserver-7b5799b6c8-9f5bp                       4/4     Running   0          3m7s
kube-controller-manager-5465bc4dd6-zpdlk              1/1     Running   0          44s
kube-scheduler-5dd5f78b94-bbbck                       1/1     Running   0          2m36s
machine-approver-846c69f56-jxvfr                      1/1     Running   0          92s
oauth-openshift-79c7bf44bf-j975g                      2/2     Running   0          62s
olm-operator-767f9584c-4lcl2                          2/2     Running   0          93s
openshift-apiserver-5d469778c6-pl8tj                  3/3     Running   0          2m36s
openshift-controller-manager-6475fdff58-hl4f7         1/1     Running   0          95s
openshift-oauth-apiserver-dbbc5cc5f-98574             2/2     Running   0          95s
openshift-route-controller-manager-5f6997b48f-s9vdc   1/1     Running   0          95s
packageserver-67c87d4d4f-kl7qh                        2/2     Running   0          93s
    Copy to Clipboard Toggle word wrap

  8. 호스트 클러스터의 출력을 참조하십시오. 

    NAMESPACE   NAME         VERSION   KUBECONFIG                PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
clusters    hosted-dual            hosted-admin-kubeconfig   Partial    True          False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap

다음으로 NodePool 오브젝트를 생성합니다.

1.7.10.7.9.2. 호스트된 클러스터에 대한 NodePool 오브젝트 생성
링크 복사

NodePool 은 호스팅된 클러스터와 연결된 확장 가능한 작업자 노드 집합입니다. NodePool 머신 아키텍처는 특정 풀 내에서 일관되게 유지되며 컨트롤 플레인의 머신 아키텍처와 독립적입니다.

  1. NodePool 오브젝트에 대한 다음 정보를 사용하여 YAML 파일을 생성하여 필요에 따라 값을 바꿉니다. 

    apiVersion: hypershift.openshift.io/v1beta1
kind: NodePool
metadata:
  creationTimestamp: null
  name: hosted-dual
  namespace: clusters
spec:
  arch: amd64
  clusterName: hosted-dual
  management:
    autoRepair: false
    1 
    
    upgradeType: InPlace
    2 
    
  nodeDrainTimeout: 0s
  platform:
    type: Agent
  release:
    image: registry.dns.base.domain.name:5000/openshift/release-images:4.14.0-0.nightly-2023-08-29-102237
    3 
    
  replicas: 0
status:
  replicas: 0
    4
    Copy to Clipboard Toggle word wrap
    1
    노드가 제거되면 노드가 다시 생성되지 않기 때문에 autoRepair 필드가 false 로 설정됩니다.
    2
    upgradeType 은 업그레이드 중에 동일한 베어 메탈 노드가 재사용됨을 나타내는 InPlace 로 설정됩니다.
    3
    이 NodePool 에 포함된 모든 노드는 다음 OpenShift Container Platform 버전 4.14.0-0.nightly-2023-08-29-102237 을 기반으로 합니다. dns.base.domain.name 값을 DNS 기본 도메인 이름으로 교체합니다.
    4
    필요한 경우 스케일링할 수 있도록 replicas 값은 0 으로 설정됩니다. 모든 단계가 완료될 때까지 NodePool 복제본을 0으로 유지하는 것이 중요합니다.

  2. 다음 명령을 입력하여 NodePool 오브젝트를 생성합니다. 

    oc apply -f 02-nodepool.yaml
    Copy to Clipboard Toggle word wrap

  3. 출력을 참조하십시오. 

    NAMESPACE   NAME          CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted-dual   hosted    0                               False         False        4.14.0-0.nightly-2023-08-29-102237
    Copy to Clipboard Toggle word wrap

다음으로 InfraEnv 리소스를 생성합니다.

1.7.10.7.9.3. 호스트된 클러스터에 대한 InfraEnv 리소스 생성
링크 복사

InfraEnv 리소스는 pullSecretRef 및 sshAuthorizedKey 와 같은 필수 세부 정보를 포함하는 지원 서비스 오브젝트입니다. 이러한 세부 사항은 호스팅된 클러스터에 대해 사용자 지정된 RHCOS(Red Hat Enterprise Linux CoreOS) 부팅 이미지를 생성하는 데 사용됩니다.

  1. 필요에 따라 값을 교체하여 InfraEnv 리소스에 대한 다음 정보를 사용하여 YAML 파일을 생성합니다. 

    ---
apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: hosted-dual
  namespace: clusters-hosted-dual
spec:
  pullSecretRef:
    1 
    
    name: pull-secret
  sshAuthorizedKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDk7ICaUE+/k4zTpxLk4+xFdHi4ZuDi5qjeF52afsNkw0w/glILHhwpL5gnp5WkRuL8GwJuZ1VqLC9EKrdmegn4MrmUlq7WTsP0VFOZFBfq2XRUxo1wrRdor2z0Bbh93ytR+ZsDbbLlGngXaMa0Vbt+z74FqlcajbHTZ6zBmTpBVq5RHtDPgKITdpE1fongp7+ZXQNBlkaavaqv8bnyrP4BWahLP4iO9/xJF9lQYboYwEEDzmnKLMW1VtCE6nJzEgWCufACTbxpNS7GvKtoHT/OVzw8ArEXhZXQUS1UY8zKsX2iXwmyhw5Sj6YboA8WICs4z+TrFP89LmxXY0j6536TQFyRz1iB4WWvCbH5n6W+ABV2e8ssJB1AmEy8QYNwpJQJNpSxzoKBjI73XxvPYYC/IjPFMySwZqrSZCkJYqQ023ySkaQxWZT7in4KeMu7eS2tC+Kn4deJ7KwwUycx8n6RHMeD8Qg9flTHCv3gmab8JKZJqN3hW1D378JuvmIX4V0=
    2
    Copy to Clipboard Toggle word wrap
    1
    pullSecretRef 는 가져오기 보안이 사용되는 InfraEnv 와 동일한 네임스페이스에서 구성 맵 참조를 나타냅니다.
    2
    sshAuthorizedKey 는 부팅 이미지에 배치된 SSH 공개 키를 나타냅니다. SSH 키를 사용하면 core 사용자로 작업자 노드에 액세스할 수 있습니다.

  2. 다음 명령을 입력하여 InfraEnv 리소스를 생성합니다. 

    oc apply -f 03-infraenv.yaml
    Copy to Clipboard Toggle word wrap

  3. 다음 출력을 참조하십시오. 

    NAMESPACE              NAME     ISO CREATED AT
clusters-hosted-dual   hosted   2023-09-11T15:14:10Z
    Copy to Clipboard Toggle word wrap

다음으로 작업자 노드를 생성합니다.

1.7.10.7.9.4. 호스트된 클러스터의 작업자 노드 생성
링크 복사

베어 메탈 플랫폼에서 작업하는 경우 작업자 노드를 생성하는 것은 BareMetalHost 의 세부 정보가 올바르게 구성되었는지 확인하는 데 중요합니다.

가상 머신으로 작업하는 경우 다음 단계를 완료하여 Metal3 Operator에서 사용할 빈 작업자 노드를 생성할 수 있습니다. 이렇게 하려면 kcli 툴을 사용합니다.

  1. 이것이 작업자 노드 생성을 처음 시도하지 않은 경우 먼저 이전 설정을 삭제해야 합니다. 이렇게 하려면 다음 명령을 입력하여 계획을 삭제합니다. 

    kcli delete plan hosted-dual
    Copy to Clipboard Toggle word wrap
    1. 계획을 삭제할지 여부를 확인하라는 메시지가 표시되면 y 를 입력합니다.
    2. 계획이 삭제되었음을 알리는 메시지가 표시되는지 확인합니다.

  2. 다음 명령을 입력하여 가상 머신을 생성합니다. 

    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-dual -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"dual\", \"mac\": \"aa:aa:aa:aa:11:01\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa1101 -P name=hosted-dual-worker0
    Copy to Clipboard Toggle word wrap 
    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-dual -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"dual\", \"mac\": \"aa:aa:aa:aa:11:02\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa1102 -P name=hosted-dual-worker1
    Copy to Clipboard Toggle word wrap 
    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-dual -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"dual\", \"mac\": \"aa:aa:aa:aa:11:03\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa1103 -P name=hosted-dual-worker2
    Copy to Clipboard Toggle word wrap 
    systemctl restart ksushy
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    • start=False 는 VM(가상 머신)이 생성 시 자동으로 시작되지 않음을 의미합니다.
    • uefi_legacy=true 는 UEFI 레거시 부팅을 사용하여 이전 UEFI 구현과의 호환성을 보장합니다.
    • plan=hosted-dual 은 시스템 그룹을 클러스터로 식별하는 계획 이름을 나타냅니다.
    • memory=8192 및 numcpus=16 은 RAM 및 CPU를 포함하여 VM의 리소스를 지정하는 매개변수입니다.
    • disks=[200,200] 은 VM에 씬 프로비저닝된 두 개의 디스크를 생성 중임을 나타냅니다.
    • nets=[{"name": "dual", "mac": "aa:aa:aa:aa:aa:aa:02:13"}] 은 연결할 네트워크 이름과 기본 인터페이스의 MAC 주소를 포함한 네트워크 세부 정보입니다.
    • ksushy 를 다시 시작하여 ksushy 툴을 다시 시작하여 추가한 VM을 감지합니다.

  3. 결과 출력을 확인합니다. 

    +---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
|         Name        | Status |         Ip        |                       Source                       |     Plan    | Profile |
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
|    hosted-worker0   |  down  |                   |                                                    | hosted-dual |  kvirt  |
|    hosted-worker1   |  down  |                   |                                                    | hosted-dual |  kvirt  |
|    hosted-worker2   |  down  |                   |                                                    | hosted-dual |  kvirt  |
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
    Copy to Clipboard Toggle word wrap

다음으로 호스팅된 클러스터에 대한 베어 메탈 호스트를 생성합니다.

1.7.10.7.9.5. 호스트 클러스터를 위한 베어 메탈 호스트 생성
링크 복사

베어 메탈 호스트 는 Metal3 Operator가 식별할 수 있도록 물리적 및 논리 세부 정보를 포함하는 openshift-machine-api 오브젝트입니다. 이러한 세부 사항은 에이전트 라고 하는 기타 지원 서비스 오브젝트와 연결됩니다.

중요: 베어 메탈 호스트 및 대상 노드를 생성하기 전에 가상 머신을 생성해야 합니다.

베어 메탈 호스트를 생성하려면 다음 단계를 완료합니다.

  1. 다음 정보를 사용하여 YAML 파일을 생성합니다.

    참고: 베어 메탈 호스트 인증 정보를 보유하는 시크릿이 하나 이상 있으므로 각 작업자 노드에 대해 두 개 이상의 오브젝트를 생성해야 합니다. 

    ---
apiVersion: v1
kind: Secret
metadata:
  name: hosted-dual-worker0-bmc-secret
  namespace: clusters-hosted-dual
data:
  password: YWRtaW4=
  username: YWRtaW4=
type: Opaque
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: hosted-dual-worker0
  namespace: clusters-hosted-dual
  labels:
    infraenvs.agent-install.openshift.io: hosted-dual
    1 
    
  annotations:
    inspect.metal3.io: disabled
    bmac.agent-install.openshift.io/hostname: hosted-dual-worker0
    2 
    
spec:
  automatedCleaningMode: disabled
    3 
    
  bmc:
    disableCertificateVerification: true
    4 
    
    address: redfish-virtualmedia://[192.168.126.1]:9000/redfish/v1/Systems/local/hosted-dual-worker0
    5 
    
    credentialsName: hosted-dual-worker0-bmc-secret
    6 
    
  bootMACAddress: aa:aa:aa:aa:02:11
    7 
    
  online: true
    8
    Copy to Clipboard Toggle word wrap
    1
    infraenvs.agent-install.openshift.io 는 지원 설치 프로그램과 BareMetalHost 오브젝트 간의 링크 역할을 합니다.
    2
    B MAC.agent-install.openshift.io/hostname 은 배포 중에 채택된 노드 이름을 나타냅니다.
    3
    automatedCleaningMode 를 사용하면 Metal3 Operator에 의해 노드가 지워지지 않습니다.
    4
    클라이언트에서 인증서 유효성 검사를 바이패스하려면 disableCertificateVerification 이 true 로 설정됩니다.
    5
    address 는 작업자 노드의 BMC(Baseboard Management Controller) 주소를 나타냅니다.
    6
    credentialsName 은 사용자 및 암호 인증 정보가 저장된 시크릿을 가리킵니다.
    7
    bootMACAddress 는 노드가 시작되는 인터페이스 MAC 주소를 나타냅니다.
    8
    online 은 BareMetalHost 개체가 생성된 후 노드의 상태를 정의합니다.

  2. 다음 명령을 입력하여 BareMetalHost 오브젝트를 배포합니다. 

    oc apply -f 04-bmh.yaml
    Copy to Clipboard Toggle word wrap

    프로세스 중에 다음 출력을 볼 수 있습니다.

    • 이 출력은 프로세스가 노드에 연결을 시도 중임을 나타냅니다. 

      NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   registering              true             2s
clusters-hosted   hosted-worker1   registering              true             2s
clusters-hosted   hosted-worker2   registering              true             2s
      Copy to Clipboard Toggle word wrap

    • 이 출력은 노드가 시작됨을 나타냅니다. 

      NAMESPACE         NAME             STATE          CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   provisioning              true             16s
clusters-hosted   hosted-worker1   provisioning              true             16s
clusters-hosted   hosted-worker2   provisioning              true             16s
      Copy to Clipboard Toggle word wrap
    • 이 출력은 노드가 성공적으로 시작되었음을 나타냅니다. 
    NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   provisioned              true             67s
clusters-hosted   hosted-worker1   provisioned              true             67s
clusters-hosted   hosted-worker2   provisioned              true             67s
    Copy to Clipboard Toggle word wrap

  3. 노드가 시작된 후 다음 예와 같이 네임스페이스의 에이전트를 확인합니다. 

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413             true       auto-assign
    Copy to Clipboard Toggle word wrap

    에이전트는 설치에 사용할 수 있는 노드를 나타냅니다. 호스트 클러스터에 노드를 할당하려면 노드 풀을 확장합니다.

1.7.10.7.9.6. 노드 풀 확장
링크 복사

베어 메탈 호스트를 생성한 후 해당 상태가 Registering 에서 Provisioning (프로비저닝)으로 변경됨. 노드는 에이전트의 LiveISO 및 에이전트 라는 기본 Pod로 시작합니다. 해당 에이전트는 OpenShift Container Platform 페이로드를 설치하기 위해 Assisted Service Operator에서 지침을 받습니다.

  1. 노드 풀을 확장하려면 다음 명령을 입력합니다. 

    oc -n clusters scale nodepool hosted-dual --replicas 3
    Copy to Clipboard Toggle word wrap

  2. 확장 프로세스가 완료되면 에이전트가 호스팅된 클러스터에 할당되어 있습니다. 

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411   hosted    true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412   hosted    true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413   hosted    true       auto-assign
    Copy to Clipboard Toggle word wrap

  3. 또한 노드 풀 복제본이 설정되어 있습니다. 

    NAMESPACE   NAME     CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted   hosted    3                               False         False        4.14.0-0.nightly-2023-08-29-102237                                      Minimum availability requires 3 replicas, current 0 available
    Copy to Clipboard Toggle word wrap
  4. 노드가 클러스터에 참여할 때까지 기다립니다. 프로세스 중에 에이전트는 단계 및 상태에 대한 업데이트를 제공합니다.

다음으로 호스트 클러스터의 배포를 모니터링합니다.

1.7.10.7.10. 듀얼 스택 네트워크에 대해 호스트된 클러스터 배포 완료
링크 복사

컨트롤 플레인과 데이터 플레인의 두 가지 관점에서 호스팅 클러스터 배포를 모니터링할 수 있습니다.

1.7.10.7.10.1. 컨트롤 플레인 모니터링
링크 복사

호스팅 클러스터를 배포하는 동안 다음 명령을 입력하여 컨트롤 플레인을 모니터링할 수 있습니다. 

export KUBECONFIG=/root/.kcli/clusters/hub-ipv4/auth/kubeconfig
Copy to Clipboard Toggle word wrap 
watch "oc get pod -n hypershift;echo;echo;oc get pod -n clusters-hosted-ipv4;echo;echo;oc get bmh -A;echo;echo;oc get agent -A;echo;echo;oc get infraenv -A;echo;echo;oc get hostedcluster -A;echo;echo;oc get nodepool -A;echo;echo;"
Copy to Clipboard Toggle word wrap

이러한 명령은 다음 아티팩트에 대한 정보를 제공합니다.

  • The HyperShift Operator
  • HostedControlPlane Pod
  • 베어 메탈 호스트
  • 에이전트
  • InfraEnv 리소스
  • HostedCluster 및 NodePool 리소스
1.7.10.7.10.2. 데이터 플레인 모니터링
링크 복사

배포 프로세스 중에 Operator가 진행 중인 방식을 모니터링하려면 다음 명령을 입력합니다. 

oc get secret -n clusters-hosted-ipv4 admin-kubeconfig -o jsonpath='{.data.kubeconfig}' |base64 -d > /root/hc_admin_kubeconfig.yaml
Copy to Clipboard Toggle word wrap 
export KUBECONFIG=/root/hc_admin_kubeconfig.yaml
Copy to Clipboard Toggle word wrap 
watch "oc get clusterversion,nodes,co"
Copy to Clipboard Toggle word wrap

이러한 명령은 다음 아티팩트에 대한 정보를 제공합니다.

  • 클러스터 버전
  • 특히 노드가 클러스터에 참여하는지 여부에 대한 노드
  • 클러스터 Operator

1.7.11. 수동으로 호스팅된 컨트롤 플레인 클러스터 가져오기
링크 복사

호스팅된 컨트롤 플레인을 사용할 수 있게 되면 호스팅된 클러스터는 멀티 클러스터 엔진 Operator로 자동으로 가져옵니다. 호스트 클러스터를 수동으로 가져오려면 다음 단계를 완료합니다.

  1. 콘솔에서 Infrastructure > Clusters 를 클릭하고 가져올 호스팅 클러스터를 선택합니다.

  2. 호스팅 클러스터 가져오기 를 클릭합니다.

    참고: 검색된 호스트 클러스터의 경우 콘솔에서 가져올 수도 있지만 클러스터는 업그레이드 가능한 상태여야 합니다. 호스팅된 컨트롤 플레인을 사용할 수 없기 때문에 호스팅된 클러스터가 업그레이드 가능한 상태가 아닌 경우 클러스터의 가져오기가 비활성화됩니다. 가져오기 를 클릭하여 프로세스를 시작합니다. 클러스터가 업데이트를 수신하는 동안 상태가 Importing 된 다음 Ready 로 변경됩니다.

다음 단계를 완료하여 명령줄 인터페이스를 사용하여 AWS에서 호스팅되는 컨트롤 플레인 클러스터를 가져올 수도 있습니다.

  1. 다음 샘플 YAML 파일을 사용하여 ManagedCluster 리소스를 생성합니다. 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    import.open-cluster-management.io/hosting-cluster-name: local-cluster
    import.open-cluster-management.io/klusterlet-deploy-mode: Hosted
    open-cluster-management/created-via: hypershift
  labels:
    cloud: auto-detect
    cluster.open-cluster-management.io/clusterset: default
    name: <cluster_name>
    vendor: OpenShift
  name: <cluster_name>
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60
    Copy to Clipboard Toggle word wrap

    & lt;cluster_name& gt;을 호스트된 클러스터 이름으로 바꿉니다.

  2. 다음 명령을 실행하여 리소스를 적용합니다. 

    oc apply -f <file_name>
    Copy to Clipboard Toggle word wrap

    <file_name>을 이전 단계에서 생성한 YAML 파일 이름으로 바꿉니다.

  3. 다음 샘플 YAML 파일을 사용하여 KlusterletAddonConfig 리소스를 생성합니다. 이는 Red Hat Advanced Cluster Management에만 적용됩니다. 다중 클러스터 엔진 Operator만 설치한 경우 다음 단계를 건너뜁니다. 

    apiVersion: agent.open-cluster-management.io/v1
kind: KlusterletAddonConfig
metadata:
  name: <cluster_name>
  namespace: <cluster_name>
spec:
  clusterName: <cluster_name>
  clusterNamespace: <cluster_name>
  clusterLabels:
    cloud: auto-detect
    vendor: auto-detect
  applicationManager:
    enabled: true
  certPolicyController:
    enabled: true
  iamPolicyController:
    enabled: true
  policyController:
    enabled: true
  searchCollector:
    enabled: false
    Copy to Clipboard Toggle word wrap

    & lt;cluster_name& gt;을 호스트된 클러스터 이름으로 바꿉니다.

  4. 다음 명령을 실행하여 리소스를 적용합니다. 

    oc apply -f <file_name>
    Copy to Clipboard Toggle word wrap

    <file_name>을 이전 단계에서 생성한 YAML 파일 이름으로 바꿉니다.

  5. 가져오기 프로세스가 완료되면 콘솔에 호스팅된 클러스터가 표시됩니다. 다음 명령을 실행하여 호스팅 클러스터의 상태를 확인할 수도 있습니다. 

    oc get managedcluster <cluster_name>
    Copy to Clipboard Toggle word wrap

1.7.11.2. 추가 리소스
링크 복사

멀티 클러스터 엔진 Operator 2.4부터 컨트롤 플레인을 사용할 수 있게 되면 호스팅된 클러스터를 멀티 클러스터 엔진 Operator로 자동으로 가져옵니다. Red Hat Advanced Cluster Management가 설치된 경우 모든 Red Hat Advanced Cluster Management 애드온도 활성화됩니다. 자동 가져오기를 비활성화하더라도 이전에 가져온 호스팅 클러스터는 영향을 받지 않습니다. 다중 클러스터 엔진 Operator 2.4로 업그레이드하고 자동 가져오기가 활성화되면 컨트롤 플레인을 사용할 수 있는 경우 가져오지 않은 모든 호스팅 클러스터를 자동으로 가져옵니다.

필요한 경우 호스팅 클러스터의 자동 가져오기를 비활성화할 수 있습니다. 자동 가져오기가 비활성화되면 새로 생성된 호스팅 클러스터만 자동으로 가져오지 않습니다. 이미 가져온 호스트 클러스터는 영향을 받지 않습니다. 콘솔을 사용하거나 ManagedCluster 및 KlusterletAddonConfig 사용자 정의 리소스를 생성하여 클러스터를 수동으로 가져올 수 있습니다. 수동 가져오기에 대한 자세한 내용은 호스팅된 컨트롤 플레인 클러스터 가져오기를 참조하십시오.

호스트 클러스터의 자동 가져오기를 비활성화하려면 다음 단계를 완료합니다.

  1. 허브 클러스터에서 다음 명령을 입력하여 다중 클러스터 엔진 Operator가 설치된 네임스페이스의 AddonDeploymentConfig 리소스에 있는 hypershift-addon-deploy-config 사양을 엽니다. 

    oc edit addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine
    Copy to Clipboard Toggle word wrap

  2. spec.customizedVariables 섹션에서 다음 예와 같이 값이 "true" 인 autoImportDisabled 변수를 추가합니다. 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: AddOnDeploymentConfig
metadata:
  name: hypershift-addon-deploy-config
  namespace: multicluster-engine
spec:
  customizedVariables:
   - name: hcMaxNumber
     value: "80"
  - name: hcThresholdNumber
    value: "60"
  - name: autoImportDisabled
    value: "true"
    Copy to Clipboard Toggle word wrap
  3. 자동 가져오기를 다시 활성화하려면 autoImportDisabled 변수 값을 "false" 로 설정하거나 AddonDeploymentConfig 리소스에서 변수를 제거합니다.
1.7.11.3.1. 추가 리소스
링크 복사

호스트 클러스터를 수동으로 가져오는 방법은 호스팅된 컨트롤 플레인 클러스터 수동 가져오기를 참조하십시오.

1.7.12. 호스팅된 컨트롤 플레인 기능 활성화 또는 비활성화
링크 복사

호스팅된 컨트롤 플레인 기능 및 hypershift-addon 관리 클러스터 애드온은 기본적으로 활성화되어 있습니다. 기능을 비활성화하거나 비활성화한 후 수동으로 활성화하려면 다음 절차를 참조하십시오.

1.7.12.1. 수동으로 호스트된 컨트롤 플레인 기능 활성화
링크 복사

  1. 다음 명령을 실행하여 기능을 활성화할 수 있습니다. 

    oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}'
    1
    Copy to Clipboard Toggle word wrap
    1
    기본 MultiClusterEngine 리소스 인스턴스 이름은 multiclusterengine 이지만 다음 명령을 실행하여 클러스터에서 MultiClusterEngine 이름을 가져올 수 있습니다. $ oc get mce.

  2. 다음 명령을 실행하여 MultiClusterEngine 사용자 정의 리소스에서 hypershift 및 hypershift-local-hosting 기능이 활성화되어 있는지 확인합니다. 

    oc get mce multiclusterengine -o yaml
    1
    Copy to Clipboard Toggle word wrap
    1
    기본 MultiClusterEngine 리소스 인스턴스 이름은 multiclusterengine 이지만 다음 명령을 실행하여 클러스터에서 MultiClusterEngine 이름을 가져올 수 있습니다. $ oc get mce.

    출력은 다음 예와 유사합니다. 

    apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  overrides:
    components:
    - name: hypershift
      enabled: true
    - name: hypershift-local-hosting
      enabled: true
    Copy to Clipboard Toggle word wrap

호스팅된 컨트롤 플레인 기능을 활성화하면 하이퍼shift-addon 관리 클러스터 애드온이 자동으로 활성화됩니다. hypershift-addon 관리 클러스터 애드온을 수동으로 활성화해야 하는 경우 hypershift-addon 을 사용하여 local-cluster 에 HyperShift Operator를 설치하려면 다음 단계를 완료합니다.

  1. 다음 예제와 유사한 파일을 생성하여 ManagedClusterAddon HyperShift 애드온을 생성합니다. 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: ManagedClusterAddOn
metadata:
  name: hypershift-addon
  namespace: local-cluster
spec:
  installNamespace: open-cluster-management-agent-addon
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 파일을 적용합니다. 

    oc apply -f <filename>
    Copy to Clipboard Toggle word wrap

    filename 을 생성한 파일의 이름으로 바꿉니다.

  3. 다음 명령을 실행하여 hypershift-addon 이 설치되었는지 확인합니다. 

    oc get managedclusteraddons -n local-cluster hypershift-addon
    Copy to Clipboard Toggle word wrap

    애드온이 설치된 경우 출력은 다음 예와 유사합니다. 

    NAME               AVAILABLE   DEGRADED   PROGRESSING
hypershift-addon   True
    Copy to Clipboard Toggle word wrap

HyperShift 애드온이 설치되고 호스팅 클러스터를 사용하여 호스팅 클러스터를 생성하고 관리할 수 있습니다.

1.7.12.2. 호스트된 컨트롤 플레인 기능 비활성화
링크 복사

HyperShift Operator를 설치 제거하고 호스팅된 컨트롤 플레인을 비활성화할 수 있습니다. 호스팅된 컨트롤 플레인 클러스터 기능을 비활성화할 때 호스트된 컨트롤 플레인 클러스터 관리 항목에 설명된 대로 멀티 클러스터 엔진 Operator에서 호스팅 클러스터 및 관리 클러스터 리소스를 제거해야 합니다.

1.7.12.2.1. HyperShift Operator 설치 제거
링크 복사

HyperShift Operator를 설치 제거하고 local-cluster 에서 hypershift-addon 을 비활성화하려면 다음 단계를 완료하십시오.

  1. 다음 명령을 실행하여 호스트 클러스터가 실행되고 있지 않은지 확인합니다. 

    oc get hostedcluster -A
    Copy to Clipboard Toggle word wrap

    중요: 호스트 클러스터가 실행 중인 경우 hypershift-addon 이 비활성화된 경우에도 HyperShift Operator가 제거되지 않습니다.

  2. 다음 명령을 실행하여 hypershift-addon 을 비활성화합니다. 

    oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": false}]}}}'
    1
    Copy to Clipboard Toggle word wrap
    1
    기본 MultiClusterEngine 리소스 인스턴스 이름은 multiclusterengine 이지만 다음 명령을 실행하여 클러스터에서 MultiClusterEngine 이름을 가져올 수 있습니다. $ oc get mce.

    참고: hypershift-addon 을 비활성화한 후 다중 클러스터 엔진 Operator 콘솔에서 local-cluster 의 hypershift-addon 을 비활성화할 수도 있습니다.

1.7.12.2.2. 호스트된 컨트롤 플레인 기능 비활성화
링크 복사

먼저 호스팅된 컨트롤 플레인 기능을 비활성화하기 전에 HyperShift Operator를 설치 제거해야 합니다. 다음 명령을 실행하여 호스팅된 컨트롤 플레인 기능을 비활성화합니다. 

oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": false}]}}}'
1
Copy to Clipboard Toggle word wrap
1
기본 MultiClusterEngine 리소스 인스턴스 이름은 multiclusterengine 이지만 다음 명령을 실행하여 클러스터에서 MultiClusterEngine 이름을 가져올 수 있습니다. $ oc get mce.

다음 명령을 실행하여 hypershift 및 hypershift-local-hosting 기능이 MultiClusterEngine 사용자 정의 리소스에서 비활성화되어 있는지 확인할 수 있습니다. 

oc get mce multiclusterengine -o yaml
1
Copy to Clipboard Toggle word wrap
1
기본 MultiClusterEngine 리소스 인스턴스 이름은 multiclusterengine 이지만 다음 명령을 실행하여 클러스터에서 MultiClusterEngine 이름을 가져올 수 있습니다. $ oc get mce.

hypershift 및 hypershift-local-hosting 에 enabled: flags가 false 로 설정된 다음 예제를 참조하십시오. 

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  overrides:
    components:
    - name: hypershift
      enabled: false
    - name: hypershift-local-hosting
      enabled: false
Copy to Clipboard Toggle word wrap

1.7.12.3. 추가 리소스
링크 복사

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat