검색
지원콘솔개발자평가판 시작연락처

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

download PDF

다중 클러스터 엔진 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 버전을 나타냅니다.

플랫폼

OpenShift Container Platform 버전 호스팅

호스팅된 OpenShift Container Platform 버전

베어 메탈

4.14 - 4.15

4.14 - 4.15 (only)

Red Hat OpenShift Virtualization

4.14 - 4.15

4.14 - 4.15 (only)

AWS (기술 프리뷰)

4.11 - 4.15

4.14 - 4.15 (only)

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

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

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

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

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

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

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

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

노드 풀에 대한 추가 네트워크, 보장된 CPU 및 VM 스케줄링을 구성하려면 다음 문서를 참조하십시오.

호스팅된 컨트롤 플레인에 대한 추가 리소스는 다음 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의 호스팅된 컨트롤 플레인 CPU 및 메모리 요청을 기반으로 계산됩니다.

고가용성 호스트 컨트롤 플레인은 5개의 vCPU 및 18GB 메모리를 요청하는 78 Pod로 구성됩니다. 이러한 기준 번호는 클러스터 작업자 노드 리소스 용량과 비교하여 호스팅되는 컨트롤 플레인의 최대 수를 추정합니다.

1.7.2.3. 로드 기반 제한

클러스터에서 호스팅할 수 있는 최대 호스팅 컨트롤 플레인 수는 일부 워크로드가 호스팅된 컨트롤 플레인 Kubernetes API 서버에 배치될 때 호스팅된 컨트롤 플레인 CPU 및 메모리 사용률을 기반으로 계산됩니다.

다음 방법은 워크로드가 증가할 때 호스팅된 컨트롤 플레인 리소스 사용률을 측정하는 데 사용됩니다.

  • KubeVirt 플랫폼을 사용하는 동안 각각 8 vCPU 및 32GiB를 사용하는 9개의 작업자가 있는 호스트 클러스터

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

    • 각 네임스페이스에 대해 생성된 오브젝트로, 총 네임스페이스 100개까지 확장
    • 연속 오브젝트 삭제 및 생성에 대한 추가 API 과부하
    • 워크로드 쿼리-초당 (QPS) 및 Burst 설정은 클라이언트 측 제한을 제거하기 위해 높은 설정

로드가 1000개의 QPS로 증가하면 호스트된 컨트롤 플레인 리소스 사용률이 9개의 vCPU 및 2.5GB 메모리로 증가합니다.

일반적인 크기 조정을 위해 중간 호스트 클러스터 로드인 1000 QPS API 속도와 호스트 클러스터 로드가 많은 2000 QPS API를 고려하십시오.

참고: 이 테스트는 예상되는 API 로드에 따라 컴퓨팅 리소스 사용률을 늘리는 추정 요소를 제공합니다. 정확한 사용률 비율은 클러스터 워크로드의 유형 및 속도에 따라 다를 수 있습니다.

표 1.7. 로드 테이블
호스트된 컨트롤 플레인 리소스 사용률 스케일링vCPU메모리(GiB)

로드가 없는 리소스 사용률

2.9

11.1

1000 QPS 사용 리소스

9.0

2.5

로드가 1000개의 QPS로 증가하면 호스트된 컨트롤 플레인 리소스 사용률이 9개의 vCPU 및 2.5GB 메모리로 증가합니다.

일반적인 크기 조정을 위해 1000개의 QPS API 속도가 중간 호스트 클러스터 로드이고 2000 QPS API를 호스트하는 클러스터 로드가 높은 것으로 간주합니다.

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

표 1.8. API 속도 테이블
QPS(API 속도)vCPU 사용메모리 사용량(GiB)

낮은 부하 (50 QPS 미만)

2.9

11.1

중간 로드 (1000 QPS)

11.9

13.6

높은 부하 (2000 QPS)

20.9

16.1

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

1.7.2.4. 크기 조정 계산 예

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

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

작업자 노드의 vCPU 수

64

128

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

128

256

작업자당 최대 Pod 수

500

500

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

3

3

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

1000

1000

표 1.10. 크기 조정 계산 예

작업자 노드 크기 및 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.11. 호스팅된 컨트롤 플레인 용량 메트릭

이름

설명

mce_hs_addon_request_based_hcp_capacity_gauge

클러스터가 고가용성 호스팅 컨트롤 플레인 리소스 요청을 기반으로 호스팅할 수 있는 최대 호스트 컨트롤 플레인 수입니다.

mce_hs_addon_low_qps_based_hcp_capacity_gauge

모든 호스팅 컨트롤 플레인이 클러스터 Kube API 서버에 약 50 QPS를 생성하는 경우 클러스터에서 호스팅할 수 있는 호스트 컨트롤 플레인의 최대 최대 수입니다.

mce_hs_addon_medium_qps_based_hcp_capacity_gauge

모든 호스팅된 컨트롤 플레인이 클러스터 Kube API 서버에 약 1000개의 QPS를 생성하는 경우 클러스터에서 호스팅할 수 있는 호스트 컨트롤 플레인의 최대 최대 수입니다.

mce_hs_addon_high_qps_based_hcp_capacity_gauge

모든 호스팅된 컨트롤 플레인이 약 2000 QPS를 클러스터 Kube API 서버로 만드는 경우 클러스터에서 호스팅할 수 있는 호스팅되는 컨트롤 플레인의 최대 수입니다.

mce_hs_addon_average_qps_based_hcp_capacity_gauge

클러스터에서 호스트된 컨트롤 플레인의 기존 평균 QPS를 기반으로 호스팅할 수 있는 최대 호스트 컨트롤 플레인 수입니다. 활성 호스트 컨트롤 플레인이 없는 경우 낮은 QPS를 기대할 수 있습니다.

1.7.2.5. 추가 리소스

1.7.3. 리소스 사용률 측정 덮어쓰기

리소스 사용률에 대한 기준 측정 세트는 모든 클러스터에서 다를 수 있습니다. 자세한 내용은 호스팅된 컨트롤 플레인 크기 조정 지침을 참조하십시오.

클러스터 워크로드의 유형 및 속도에 따라 리소스 사용률 측정을 덮어쓸 수 있습니다. 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 ConfigMap 리소스를 생성합니다. 

    oc create -f <your-config-map-file.yaml>

    < your-config-map-file.yaml >을 hcp-sizing-baseline 구성 맵이 포함된 YAML 파일의 이름으로 바꿉니다.

  2. local-cluster 네임스페이스에 hcp-sizing-baseline 구성 맵을 생성하여 덮어쓸 측정값을 지정합니다. 구성 맵은 다음 YAML 파일과 유사할 수 있습니다. 

    kind: ConfigMap
apiVersion: v1
metadata:
  name: hcp-sizing-baseline
  namespace: local-cluster
data:
  incrementalCPUUsagePer1KQPS: "9.0"
  memoryRequestPerHCP: "18"
  minimumQPSPerHCP: "50.0"

  3. 다음 명령을 실행하여 hypershift-addon-agent 배포를 삭제하여 hypershift-addon-agent Pod를 다시 시작합니다. 

    oc delete deployment hypershift-addon-agent -n open-cluster-management-agent-addon

  4. hypershift-addon-agent Pod 로그를 관찰합니다. 다음 명령을 실행하여 재정의된 측정이 구성 맵에서 업데이트되었는지 확인합니다. 

    oc logs hypershift-addon-agent -n open-cluster-management-agent-addon

    로그는 다음 출력과 유사할 수 있습니다. 

    2024-01-05T19:41:05.392Z	INFO	agent.agent-reconciler	agent/agent.go:793	setting cpuRequestPerHCP to 5
2024-01-05T19:41:05.392Z	INFO	agent.agent-reconciler	agent/agent.go:802	setting memoryRequestPerHCP to 18
2024-01-05T19:53:54.070Z	INFO	agent.agent-reconciler	agent/hcp_capacity_calculation.go:141	The worker nodes have 12.000000 vCPUs
2024-01-05T19:53:54.070Z	INFO	agent.agent-reconciler	agent/hcp_capacity_calculation.go:142	The worker nodes have 49.173369 GB memory

    hcp-sizing-baseline 구성 맵에서 재정의된 측정이 제대로 업데이트되지 않으면 hypershift-addon-agent Pod 로그에 다음 오류 메시지가 표시될 수 있습니다. 

    2024-01-05T19:53:54.052Z	ERROR	agent.agent-reconciler	agent/agent.go:788	failed to get configmap from the hub. Setting the HCP sizing baseline with default values.	{"error": "configmaps \"hcp-sizing-baseline\" not found"}

1.7.3.1. 메트릭 서비스 모니터링 비활성화

하이퍼shift-addon 관리 클러스터 애드온을 활성화한 후 기본적으로 메트릭 서비스 모니터링이 구성되므로 OpenShift Container Platform 모니터링에서 hypershift-addon 에서 메트릭을 수집할 수 있습니다. 다음 단계를 완료하여 메트릭 서비스 모니터링을 비활성화할 수 있습니다.

  1. 다음 명령을 실행하여 허브 클러스터에 로그인합니다. 

    oc login

  2. 다음 명령을 실행하여 편집할 hypershift-addon-deploy-config 배포 구성 사양을 엽니다. 

    oc edit addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine

  3. 다음 예와 같이 disableMetrics=true 사용자 지정 변수를 사양에 추가합니다. 

    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: disableMetrics
    value: "true"
  4. 변경 사항을 저장합니다. disableMetrics=true 사용자 지정 변수는 신규 및 기존 hypershift-addon 관리 클러스터 애드온에 대한 메트릭 서비스 모니터링 구성을 비활성화합니다.

1.7.3.2. 추가 리소스

1.7.4. 호스팅된 컨트롤 플레인 명령줄 인터페이스 설치

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

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

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

    tar xvzf hcp.tar.gz

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

    chmod +x hcp

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

    sudo mv hcp /usr/local/bin/.

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

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

1.7.4.1. CLI를 사용하여 호스팅된 컨트롤 플레인 명령줄 인터페이스 설치

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

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

    oc get ConsoleCLIDownload hcp-cli-download -o json | jq -r ".spec"

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

    wget <hcp_cli_download_url> 1
    1
    hcp_cli_download_url 을 이전 단계에서 얻은 URL로 바꿉니다.

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

    tar xvzf hcp.tar.gz

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

    chmod +x hcp

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

    sudo mv hcp /usr/local/bin/.

1.7.4.2. 콘텐츠 게이트웨이를 사용하여 호스팅된 컨트롤 플레인 명령줄 인터페이스 설치

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

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

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

    tar xvzf hcp.tar.gz

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

    chmod +x hcp

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

    sudo mv hcp /usr/local/bin/.

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

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

1.7.5. 호스트된 클러스터 워크로드 배포

OpenShift Container Platform의 호스팅 컨트롤 플레인을 시작하기 전에 노드에 라벨을 지정하여 호스팅된 클러스터 Pod를 인프라 노드에 예약해야 합니다.

노드 라벨링은 다음 기능을 보장합니다.

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

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

1.7.5.1. 관리 클러스터 노드의 라벨 및 테인트

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

  • Hypershift.openshift.io/control-plane: true: 이 레이블과 테인트를 사용하여 호스트된 컨트롤 플레인 워크로드를 실행하는 노드를 전용으로 사용합니다. true 를 설정하면 컨트롤 플레인 노드를 다른 구성 요소와 공유하지 않습니다.
  • Hypershift.openshift.io/cluster: <hosted-control-plane-namespace >: 노드를 단일 호스트 클러스터에 전용으로 설정하려면 이 레이블과 테인트를 사용합니다.

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

  • node-role.kubernetes.io/infra: 서브스크립션에 컨트롤 플레인 워크로드 수가 발생하지 않도록 이 라벨을 사용합니다.
  • topology.kubernetes.io/zone: 관리 클러스터 노드에서 이 레이블을 사용하여 장애 도메인에서 고가용성 클러스터를 배포합니다. 영역은 위치, 랙 이름 또는 영역이 설정된 노드의 호스트 이름이 될 수 있습니다.

각 랙을 관리 클러스터 노드의 가용성 영역으로 사용하려면 다음 명령을 입력합니다.

+ 

oc label node/<management_node1_name> node/<management_node2_name> topology.kubernetes.io/zone=<rack_name>

호스팅된 클러스터의 Pod에는 허용 오차가 있으며 스케줄러는 선호도 규칙을 사용하여 스케줄링합니다. 스케줄러는 hypershift.openshift.io/control-plane 및 hypershift.openshift.io/cluster: <hosted_control_plane_namespace > 로 레이블이 지정된 노드에 Pod 예약에 우선순위를 지정합니다.

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

1.7.5.2. 호스팅된 클러스터의 노드 레이블

중요: 호스팅된 컨트롤 플레인을 배포하기 전에 노드에 라벨을 추가해야 합니다.

호스팅 클러스터에서 실행되는 Pod를 인프라 노드에 예약하려면 HostedCluster CR(사용자 정의 리소스)에 role.kubernetes.io/infra: "" 라벨을 추가합니다. 다음 예제를 참조하십시오. 

  spec:
    nodeSelector:
      role.kubernetes.io/infra: ""

1.7.5.3. 우선순위 클래스

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

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

1.7.5.4. 추가 리소스

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

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

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

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

중요:

  • 각 호스트 클러스터에는 클러스터 전체 이름이 있어야 합니다. 호스트된 클러스터 이름은 다중 클러스터 엔진 운영자가 이를 관리하기 위해 기존 관리 클러스터와 같을 수 없습니다.
  • 클러스터를 호스팅 클러스터 이름으로 사용하지 마십시오.
  • 호스팅된 컨트롤 플레인의 동일한 플랫폼에서 허브 클러스터 및 작업자를 실행합니다.
  • 호스트된 클러스터는 다중 클러스터 엔진 Operator 관리 클러스터의 네임스페이스에서 생성할 수 없습니다.

1.7.6.1. 사전 요구 사항

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

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

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

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

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

1.7.6.2. Amazon Web Services S3 버킷 및 S3 OIDC 시크릿 생성

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

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

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

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

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

    필드 이름설명

    bucket

    호스팅된 클러스터에 대한 호스트 OIDC 검색 문서에 대한 공용 액세스 권한이 있는 S3 버킷이 포함되어 있습니다.

    credentials

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

    region

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

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

    oc create secret generic hypershift-operator-oidc-provider-s3-credentials --from-file=credentials=<path>/.aws/credentials --from-literal=bucket=<s3-bucket-for-hypershift> --from-literal=region=<region> -n local-cluster

    참고: 시크릿에 대한 재해 복구 백업은 자동으로 활성화되지 않습니다. 다음 명령을 실행하여 재해 복구를 위해 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

1.7.6.3. 라우팅 가능한 퍼블릭 영역 생성

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

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

aws route53 create-hosted-zone --name <your-basedomain> --caller-reference $(whoami)-$(date --rfc-3339=date)

your-basedomain 을 기본 도메인으로 교체합니다(예: www.example.com ).

1.7.6.4. 외부 DNS 활성화

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

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

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

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

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

  • apiserver
  • OAuthServer
  • Konnectivity
  • Ignition
  • OVNSbDb
  • OIDC

HostedCluster 사양에서 servicePublishingStrategy 필드를 사용하여 이러한 서비스를 노출할 수 있습니다. 기본적으로 LoadBalancer 및 Route 유형의 servicePublishingStrategy 에서는 다음 방법 중 하나로 서비스를 게시할 수 있습니다.

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

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

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

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

클라우드 환경에서만 외부 DNS를 사용할 수 있습니다. 다른 환경의 경우 DNS 및 서비스를 수동으로 구성해야 합니다.

외부 DNS에 대한 자세한 내용은 외부 DNS 를 참조하십시오.

1.7.6.4.1. 사전 요구 사항

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

  • 외부 공용 도메인을 생성했습니다.
  • AWS Route53 관리 콘솔에 액세스할 수 있습니다.
1.7.6.4.2. 호스팅된 컨트롤 플레인의 외부 DNS 설정

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

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

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

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

    provider

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

    필수 항목

    domain-filter

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

    필수 항목

    credentials

    모든 외부 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=<domain_name> --from-file=credentials=<path_to_aws_credentials_file> -n local-cluster

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

    oc label secret hypershift-operator-external-dns-credentials -n local-cluster cluster.open-cluster-management.io/backup=""
1.7.6.4.3. 퍼블릭 DNS 호스팅 영역 생성

외부 DNS Operator는 퍼블릭 DNS 호스팅 영역을 사용하여 퍼블릭 호스팅 클러스터를 생성합니다.

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

  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

  7. LoadBalancer 및 Route 서비스의 호스트 이름을 설정하는 호스팅 클러스터를 생성하려면 다음 명령을 입력합니다. 

    hcp create cluster aws --name=<hosted_cluster_name> --endpoint-access=PublicAndPrivate --external-dns-domain=<public_hosted_zone> ...

    & lt;public_hosted_zone >을 생성한 공개 호스팅 영역으로 바꿉니다.

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

  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

Control Plane Operator는 Services 및 Routes 리소스를 생성하고 external-dns.alpha.kubernetes.io/hostname 주석으로 주석을 추가합니다. 서비스 및 경로 의 경우 컨트롤 플레인 Operator는 서비스 끝점의 servicePublishingStrategy 필드에 있는 hostname 매개변수 값을 사용합니다. DNS 레코드를 만들려면 external-dns 배포와 같은 메커니즘을 사용할 수 있습니다.

공용 서비스에 대해서만 서비스 수준 DNS를 간접으로 구성할 수 있습니다. hypershift.local 프라이빗 영역을 사용하므로 프라이빗 서비스의 호스트 이름을 설정할 수 없습니다.

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

Service퍼블릭PublicAndPrivate프라이빗

apiserver

Y

Y

N

OAuthServer

Y

Y

N

Konnectivity

Y

N

N

Ignition

Y

N

N

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

PublicAndPrivate 또는 Public publishing 전략을 사용하여 호스팅 클러스터를 생성하려면 관리 클러스터에 다음과 같은 아티팩트가 구성되어 있어야 합니다.

  • 퍼블릭 DNS 호스팅 영역
  • 외부 DNS Operator
  • The HyperShift Operator

명령줄 인터페이스를 사용하여 호스트된 클러스터를 배포하려면 다음 단계를 완료합니다.

  1. 관리 클러스터에 액세스하려면 다음 명령을 입력합니다. 

    export KUBECONFIG=<path_to_management_cluster_kubeconfig>

  2. 다음 명령을 입력하여 External DNS Operator가 실행 중인지 확인합니다. 

    oc get pod -n hypershift -lapp=external-dns

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

    NAME                            READY   STATUS    RESTARTS   AGE
external-dns-7c89788c69-rn8gp   1/1     Running   0          40s

  3. 외부 DNS를 사용하여 호스팅된 클러스터를 생성하려면 다음 명령을 입력합니다. 

    hypershift create cluster aws \
    --aws-creds <path_to_aws_credentials_file> \ 1
    --instance-type <instance_type> \ 2
    --region <region> \ 3
    --auto-repair \
    --generate-ssh \
    --name <hosted_cluster_name> \ 4
    --namespace clusters \
    --base-domain <service_consumer_domain> \ 5
    --node-pool-replicas <node_replica_count> \ 6
    --pull-secret <path_to_your_pull_secret> \ 7
    --release-image quay.io/openshift-release-dev/ocp-release:<ocp_release_image> \ 8
    --external-dns-domain=<service_provider_domain> \ 9
    --endpoint-access=PublicAndPrivate 10
    1
    AWS 인증 정보 파일의 경로를 지정합니다(예: /user/name/.aws/credentials ).
    2
    인스턴스 유형을 지정합니다(예: m6i.xlarge ).
    3
    AWS 리전을 지정합니다(예: us-east-1 ).
    4
    호스팅된 클러스터 이름을 지정합니다(예: my-external-aws ).
    5
    서비스 소비자가 소유한 공개 호스팅 영역을 지정합니다(예: service-consumer-domain.com ).
    6
    노드 복제본 수를 지정합니다(예: 2).
    7
    풀 시크릿 파일의 경로를 지정합니다.
    8
    사용하려는 지원되는 OpenShift Container Platform 버전을 지정합니다(예: 4.14.0-x86_64 ).
    9
    서비스 공급자가 소유한 공개 호스팅 영역을 지정합니다(예: service-provider-domain.com ).
    10
    을 PublicAndPrivate 로 설정합니다. 공용 또는 Public AndPrivate 구성으로만 외부 DNS를 사용할 수 있습니다.

1.7.6.6. 호스트된 클러스터의 재해 복구

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

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

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

1.7.6.7. AWS에 호스팅된 클러스터 배포

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

  1. 각 변수에 대한 설명을 보려면 다음 명령을 실행합니다. 

    hcp create cluster aws --help
  2. hub 클러스터에 로그인되어 있는지 확인합니다.

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

    hcp create cluster aws \
    --name <hosted_cluster_name> \ 1
    --infra-id <infra_id> \ 2
    --base-domain <basedomain> \ 3
    --aws-creds <path_to_aws_creds> \ 4
    --pull-secret <path_to_pull_secret> \ 5
    --region <region> \ 6
    --generate-ssh \
    --node-pool-replicas <node_pool_replica_count> \ 7
    --namespace <hosted_cluster_namespace> 8
1
호스팅된 클러스터의 이름을 지정합니다( 예: ). < hosted_cluster_name > 및 < infra_id >에 동일한 값이 있는지 확인합니다. 그러지 않으면 Kubernetes Operator 콘솔의 다중 클러스터 엔진에 클러스터가 올바르게 표시되지 않을 수 있습니다.
2
인프라 이름을 지정합니다(예: clc-name-hs 1).
3
기본 도메인을 지정합니다(예: dev09.red-chesterfield.com ).
4
AWS 인증 정보 파일의 경로를 지정합니다(예: /user/name/.aws/credentials ).
5
풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
6
AWS 리전 이름을 지정합니다(예: us-east-1 ).
7
노드 풀 복제본 수를 지정합니다(예: 2 ).
8
호스팅된 클러스터 네임스페이스를 지정합니다(예: 클러스터 ).

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

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

    oc get hostedclusters -n <hosted_cluster_namespace>
  2. 다음 명령을 실행하여 노드 풀을 확인할 수 있습니다. 
oc get nodepools --namespace <hosted_cluster_namespace>

1.7.6.8. AWS의 여러 영역에서 호스팅 클러스터 생성

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

hcp create cluster aws \
--name <hosted-cluster-name> \ 1
--node-pool-replicas=<node-pool-replica-count> \ 2
--base-domain <basedomain> \ 3
--pull-secret <path-to-pull-secret> \ 4
--aws-creds <path-to-aws-credentials> \ 5
--region <region> \ 6
--zones <zones> 7
1
호스팅된 클러스터의 이름을 지정합니다( 예: ).
2
노드 풀 복제본 수를 지정합니다(예: 2 ).
3
기본 도메인을 지정합니다(예: example.com ).
4
풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
5
AWS 인증 정보 파일의 경로를 지정합니다(예: /user/name/.aws/credentials ).
6
AWS 리전 이름을 지정합니다(예: us-east-1 ).
7
AWS 리전 내의 가용성 영역을 지정합니다(예: us-east-1a, us-east-1b ).

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

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

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

1.7.6.8.1. AWS에서 호스팅 클러스터를 생성하기 위한 인증 정보 제공

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

1.7.6.8.1.1. --aws-creds 플래그를 사용하여 인증 정보 제공

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

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

hcp create cluster aws \
--name <hosted-cluster-name> \ 1
--node-pool-replicas=<node-pool-replica-count> \ 2
--base-domain <basedomain> \ 3
--pull-secret <path-to-pull-secret> \ 4
--aws-creds <path-to-aws-credentials> \ 5
--region <region> 6
1
호스팅된 클러스터의 이름을 지정합니다( 예: ).
2
노드 풀 복제본 수를 지정합니다(예: 2 ).
3
기본 도메인을 지정합니다(예: example.com ).
4
풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
5
AWS 인증 정보 파일의 경로를 지정합니다(예: /user/name/.aws/credentials ).
6
AWS 리전 이름을 지정합니다(예: us-east-1 ).
1.7.6.8.1.2. AWS 클라우드 공급자 시크릿을 사용하여 인증 정보 제공

시크릿에는 SSH 키, 풀 시크릿, 기본 도메인, AWS 인증 정보가 포함되어 있습니다. 따라서 hcp create cluster aws 명령을 --secret-creds 플래그와 함께 사용하여 AWS 인증 정보를 제공할 수 있습니다. 다음 예제를 참조하십시오. 

hcp create cluster aws \
--name <hosted-cluster-name> \ 1
--region <region> \ 2
--namespace <hosted-cluster-namespace> \ 3
--secret-creds <my-aws-cred> 4
1
호스팅된 클러스터의 이름을 지정합니다( 예: ).
2
AWS 리전 이름을 지정합니다(예: us-east-1 ).
3
시크릿이 기본 클러스터 네임스페이스에 없는 경우 호스팅 클러스터 네임스페이스를 지정합니다.
4
AWS 시크릿 이름을 지정합니다(예: my-aws-cred ).

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

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

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

    $ oc create secret generic <my-secret> -n <namespace> --from-literal=baseDomain=<your-basedomain> --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>", "email":"<your-email>"}, "quay.io":{"auth":"<auth>", "email":"<your-email>"} } }' --from-literal=ssh-publickey=<your-ssh-publickey> --from-literal=ssh-privatekey=<your-ssh-privatekey>

    시크릿의 형식은 다음과 같습니다. 

    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
1.7.6.8.2. 추가 리소스

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

1.7.6.9. ARM64 OpenShift Container Platform 클러스터에서 호스팅된 컨트롤 플레인 활성화 (기술 프리뷰)

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

1.7.6.9.1. 사전 요구 사항

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

1.7.6.9.2. ARM64 OpenShift Container Platform 클러스터에서 호스팅 클러스터 실행

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

    이 예제에서는 --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
1.7.6.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

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

    hcp create nodepool aws --cluster-name $CLUSTER_NAME --name $ARM64_NODEPOOL_NAME --node-count=$NODEPOOL_REPLICAS --render > arm_nodepool_spec.yml

    이 명령은 다음 예와 같이 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

  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

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

    oc apply -f arm_nodepool_spec.yml

1.7.6.10. 호스트된 클러스터에 액세스

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

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

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

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

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

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

      oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes

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

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

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

      hcp create kubeconfig --namespace <hosted-cluster-namespace> --name <hosted-cluster-name> > <hosted-cluster-name>.kubeconfig

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

      oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes
1.7.6.10.1. 추가 리소스

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

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

1.7.6.11. AWS에 프라이빗 호스팅 클러스터 배포 (기술 프리뷰)

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

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

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

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

1.7.6.11.1. 사전 요구 사항

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

1.7.6.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": "\*"
    }
  ]
}

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

    aws iam create-policy --policy-name=hypershift-operator-policy --policy-document=file://policy.json

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

    aws iam create-user --user-name=hypershift-operator

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

    aws iam attach-user-policy --user-name=hypershift-operator --policy-arn=<policy-arn>

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

    aws iam create-access-key --user-name=hypershift-operator

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

    hcp create cluster aws \
--name <hosted-cluster-name> \ 1
--node-pool-replicas=<node-pool-replica-count> \ 2
--base-domain <basedomain> \ 3
--pull-secret <path-to-pull-secret> \ 4
--aws-creds <path-to-aws-credentials> \ 5
--region <region> \ 6
--endpoint-access Private 7
    1 1
    호스팅된 클러스터의 이름을 지정합니다( 예: ).
    2 2
    노드 풀 복제본 수를 지정합니다(예: 3 ).
    3
    기본 도메인을 지정합니다(예: example.com ).
    4
    풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
    5
    AWS 인증 정보 파일의 경로를 지정합니다(예: /user/name/.aws/credentials ).
    6
    AWS 리전 이름을 지정합니다(예: us-east-1 ).
    7
    클러스터가 공용인지 프라이빗인지 여부를 정의합니다.

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

    • api.<hosted-cluster-name>.hypershift.local
    • *.apps.<hosted-cluster-name>.hypershift.local
1.7.6.11.3. AWS에서 프라이빗 호스팅 클러스터에 액세스

bastion 인스턴스를 사용하여 프라이빗 클러스터에 액세스할 수 있습니다.

  1. 다음 명령을 입력하여 bastion 인스턴스를 시작합니다. 

    hypershift create bastion aws --aws-creds=<aws-creds> --infra-id=<infra-id> --region=<region> --ssh-key-file=<ssh-key>

    & lt;ssh-key& gt;를 SSH 공개 키 파일로 교체하여 bastion에 연결합니다. SSH 공개 키 파일의 기본 위치는 ~/.ssh/id_rsa.pub 입니다. < aws-creds >를 AWS 인증 정보 파일의 경로로 바꿉니다(예: /user/name/.aws/credentials ).

참고: 하이퍼shift CLI를 다운로드할 수 없습니다. 다음 명령을 사용하여 hypershift 네임스페이스에 있는 HyperShift Operator Pod를 사용하여 압축을 풉니다. & lt;hypershift-operator-pod-name >을 HyperShift Operator Pod 이름으로 교체합니다. 

oc project hypershift
oc rsync <hypershift-operator-pod-name>:/usr/bin/hypershift-no-cgo .
mv hypershift-no-cgo hypershift

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

    aws ec2 describe-instances --filter="Name=tag:kubernetes.io/cluster/<infra-id>,Values=owned" | jq '.Reservations[] | .Instances[] | select(.PublicDnsName=="") | .PrivateIpAddress'

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

    hcp create kubeconfig > <cluster-kubeconfig>

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

    ssh -o ProxyCommand="ssh ec2-user@<bastion-ip> -W %h:%p" core@<node-ip>

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

    mv <path-to-kubeconfig-file> <new-file-name>

  5. 다음 명령을 입력하여 kubeconfig 파일을 내보냅니다. 

    export KUBECONFIG=<path-to-kubeconfig-file>

  6. 다음 명령을 입력하여 게스트 클러스터 상태를 확인합니다. 

    oc get clusteroperators clusterversion
1.7.6.11.4. 추가 리소스

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

1.7.6.12. 호스팅된 컨트롤 플레인에 대한 AWS 인프라 및 IAM 권한 관리 (기술 프리뷰)

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

1.7.6.12.1. 사전 요구 사항

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

1.7.6.12.2. AWS 인프라 요구사항

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

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

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

1.7.6.12.2.1. 임의의 AWS 계정에서 HyperShift Operator에 대한 사전 요구 사항 및 관리되지 않는 인프라

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

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

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

  • S3 버킷 1개

    • OpenID Connect(OIDC)

  • Route 53 호스팅 영역

    • 호스팅된 클러스터의 프라이빗 및 공용 항목을 호스트하는 도메인
1.7.6.12.2.2. 호스트 클러스터 AWS 계정에서 사전 요구 사항 및 관리되지 않는 인프라

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

  • VPC 1개
  • DHCP 옵션 1개

  • 두 개의 서브넷

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

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

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

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

1.7.6.12.2.3. 관리 AWS 계정에서 호스팅되는 컨트롤 플레인 관리 인프라

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

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

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

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

  • volumes

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

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

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

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

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

  • volumes:

    • etcd의 경우 (고용도에 따라 1개 또는 3개)
    • OVN-Kube의 경우
1.7.6.12.2.4. 호스트 클러스터 AWS 계정에서 호스팅된 컨트롤 플레인 관리 인프라

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

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

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

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

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

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

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

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

  • 기본 Ingress의 네트워크 로드 밸런서
  • 레지스트리의 S3 버킷
1.7.6.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
...

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

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

  • 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": "\*"
        }
    ]
}

  • 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": "\*"
        }
    ]
}

  • 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": "\*"
        }
    ]
}

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

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

  • 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"
        }
    ]
}
1.7.6.12.4. AWS 인프라 및 IAM 리소스를 별도로 생성

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

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

1.7.6.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
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의 필드를 채울 수 있습니다.

참고: 하이퍼shift CLI를 다운로드할 수 없습니다. 다음 명령을 사용하여 hypershift 네임스페이스에 있는 HyperShift Operator Pod를 사용하여 압축을 풉니다. & lt;hypershift-operator-pod-name >을 HyperShift Operator Pod 이름으로 교체합니다.

+ 

oc project hypershift
oc rsync <hypershift-operator-pod-name>:/usr/bin/hypershift-no-cgo .
mv hypershift-no-cgo hypershift

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

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

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

1.7.6.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
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.6.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
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
  • A NodePool
  • 컨트롤 플레인 구성 요소에 대한 세 가지 AWS STS 시크릿
  • --generate-ssh 플래그를 지정한 경우 SSH 키 시크릿 1개

1.7.6.13. AWS에서 호스트된 클러스터 삭제

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

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

    oc delete managedcluster <managed_cluster_name>

    여기서 <managed_cluster_name >은 관리 클러스터의 이름입니다.

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

    hcp destroy cluster aws --name <hosted_cluster_name> --infra-id <infra_id> --aws-creds <path_to_aws_creds> --base-domain <basedomain>

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

1.7.7. 베어 메탈에서 호스팅된 컨트롤 플레인 클러스터 구성

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

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

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

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

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

중요:

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

1.7.7.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
  • 관리 클러스터의 베어 메탈 호스트에 topology.kubernetes.io/zone 레이블을 추가해야 합니다. 그렇지 않으면 호스팅되는 모든 컨트롤 플레인 Pod가 단일 노드에 예약되므로 단일 장애 지점이 발생합니다.
  • 중앙 인프라 관리를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
  • 호스팅된 컨트롤 플레인 명령줄 인터페이스를 설치해야 합니다.

1.7.7.2. 베어 메탈 방화벽, 포트 및 서비스 요구 사항

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

참고: 서비스는 기본 포트에서 실행됩니다. 그러나 NodePort 게시 전략을 사용하는 경우 서비스는 NodePort 서비스에서 할당한 포트에서 실행됩니다.

방화벽 규칙, 보안 그룹 또는 기타 액세스 제어를 사용하여 필요한 소스만 액세스를 제한합니다. 필요한 경우 포트를 공개적으로 노출하지 마십시오. 프로덕션 배포의 경우 로드 밸런서를 사용하여 단일 IP 주소를 통한 액세스를 단순화합니다.

호스팅된 컨트롤 플레인은 베어 메탈에 다음 서비스를 노출합니다.

  • apiserver

    • APIServer 서비스는 기본적으로 포트 6443에서 실행되며 컨트롤 플레인 구성 요소 간 통신을 위해 수신 액세스가 필요합니다.
    • MetalLB 로드 밸런싱을 사용하는 경우 로드 밸런서 IP 주소에 사용되는 IP 범위에 대한 수신 액세스를 허용합니다.

  • OAuthServer

    • OAuthServer 서비스는 경로 및 수신을 사용하여 서비스를 노출할 때 기본적으로 포트 443에서 실행됩니다.
    • NodePort 게시 전략을 사용하는 경우 OAuthServer 서비스에 방화벽 규칙을 사용합니다.

  • Konnectivity

    • Konnectivity 서비스는 경로 및 Ingress를 사용하여 서비스를 노출할 때 기본적으로 포트 443에서 실행됩니다.
    • 호스팅된 클러스터에서 양방향 통신을 허용하도록 역방향 터널을 설정하는 Konnectivity 에이전트에는 포트 6443의 클러스터 API 서버 주소에 대한 송신 액세스가 필요합니다. 해당 송신 액세스를 사용하면 에이전트가 APIServer 서비스에 도달할 수 있습니다.
    • 클러스터 API 서버 주소가 내부 IP 주소인 경우 워크로드 서브넷에서 포트 6443의 IP 주소로 액세스를 허용합니다.
    • 주소가 외부 IP 주소인 경우 6443 포트에서 노드에서 해당 외부 IP 주소로 송신을 허용합니다.

  • Ignition

    • Ignition 서비스는 경로 및 수신을 사용하여 서비스를 노출할 때 기본적으로 포트 443에서 실행됩니다.
    • NodePort 게시 전략을 사용하는 경우 Ignition 서비스에 방화벽 규칙을 사용합니다.

베어 메탈에는 다음 서비스가 필요하지 않습니다.

  • OVNSbDb
  • OIDC

1.7.7.3. 베어 메탈 인프라 요구 사항

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

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

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

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

  • 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

  • 듀얼 스택 네트워크에서 연결이 끊긴 환경에 대해 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]

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

1.7.7.5. 베어 메탈에서 호스트 클러스터 생성

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

  1. 다음 명령을 입력하여 호스팅된 컨트롤 플레인 네임스페이스를 생성합니다. 

    oc create ns <hosted_cluster_namespace>-<hosted_cluster_name>

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

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

    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
1.7.7.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. 컨트롤 플레인 구성 요소가 준비될 때까지 기다립니다. 이 프로세스는 몇 분 정도 걸릴 수 있습니다.
  10. 노드 풀 상태를 보려면 NodePool 섹션으로 스크롤합니다. 노드를 설치하는 프로세스에는 약 10분이 걸립니다. 노드를 클릭하여 노드가 호스팅된 클러스터에 참여하고 있는지 확인할 수도 있습니다.
1.7.7.5.2. 미러 레지스트리를 사용하여 베어 메탈에서 호스팅 클러스터 생성

미러 레지스트리를 사용하여 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
  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
    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.7.5.3. 추가 리소스

1.7.7.6. 호스트된 클러스터 생성 확인

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

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

    oc extract -n <hosted-control-plane-namespace> secret/admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

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

    oc get co --kubeconfig=kubeconfig-<hosted-cluster-name>

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

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
console                                    4.10.26   True        False         False      2m38s
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

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

    oc get pods -A --kubeconfig=kubeconfig-<hosted-cluster-name>

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

    NAMESPACE                                          NAME                                                      READY   STATUS             RESTARTS        AGE
kube-system                                        konnectivity-agent-khlqv                                  0/1     Running            0               3m52s
openshift-cluster-node-tuning-operator             tuned-dhw5p                                               1/1     Running            0               109s
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-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-kfqnh                                         2/2     Running            0               113s

1.7.7.7. 호스트 클러스터의 NodePool 오브젝트 스케일링

호스팅된 클러스터에 노드를 추가하여 NodePool 오브젝트를 확장할 수 있습니다.

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

    oc -n <hosted-cluster-namespace> scale nodepool <nodepool-name> --replicas 2

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

    • 바인딩
    • 검색
    • insufficient
    • 설치
    • install-in-progress
    • add-to-existing-cluster

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

    oc -n <hosted-control-plane-namespace> get agent

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

    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

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

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

    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

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

    oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

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

    oc --kubeconfig kubeconfig-<hosted-cluster-name> get nodes

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

    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

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

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

    oc -n <hosted-control-plane-namespace> get machines

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

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

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

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

    oc --kubeconfig kubeconfig-<hosted-cluster-name> get clusterversion,co

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

    NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version             False       True          40m     Unable to apply 4.13z: 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
1.7.7.7.1. 노드 풀 추가

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

  1. 노드 풀을 생성하려면 다음 정보를 입력합니다. 

    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"}}' 1
    1
    --agentLabelSelector 는 선택 사항입니다. 노드 풀은 "size" : "medium" 라벨이 있는 에이전트를 사용합니다.

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

    oc get nodepools --namespace clusters

  3. 다음 명령을 입력하여 admin-kubeconfig 시크릿을 추출합니다. 

    oc extract -n <hosted-control-plane-namespace> secret/admin-kubeconfig --to=./hostedcluster-secrets --confirm

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

    hostedcluster-secrets/kubeconfig

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

    oc --kubeconfig ./hostedcluster-secrets get nodes

  5. 다음 명령을 입력하여 사용 가능한 노드 풀 수가 예상 노드 풀 수와 일치하는지 확인합니다. 

    oc get nodepools --namespace clusters
1.7.7.7.2. 추가 리소스

1.7.7.8. 베어 메탈의 호스트 클러스터에서 수신 처리

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

*.apps 도메인의 로드 밸런서 및 와일드카드 DNS 레코드를 설정하려면 게스트 클러스터에서 다음 작업을 수행합니다.

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

    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
  2. 파일을 metallb-operator-config.yaml 로 저장합니다.

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

    oc apply -f metallb-operator-config.yaml

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

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

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

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

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

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

      1. 구성을 포함할 YAML 파일을 생성합니다. 
    apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: <ip_address_pool_name> 1
  namespace: metallb
spec:
  protocol: layer2
  autoAssign: false
  addresses:
    - <ingress_ip>-<ingress_ip> 2
---
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: <bgp_advertisement_name> 3
  namespace: metallb
spec:
  ipAddressPools:
    - <ip_address_pool_name> 4
1 4
IPAddressPool 리소스 이름을 지정합니다.
2
환경의 IP 주소를 지정합니다(예: 192.168.122.23 ).
3
BGPAdvertisement 리소스 이름을 지정합니다.
  1. 파일을 ipaddresspool-bgpadvertisement-config.yaml 로 저장합니다.

  2. 다음 명령을 입력하여 리소스를 생성합니다. 

    oc apply -f ipaddresspool-bgpadvertisement-config.yaml
    1. LoadBalancer 유형의 서비스를 생성한 후 MetalLB는 서비스에 대한 외부 IP 주소를 추가합니다.

  3. metallb-loadbalancer-service.yaml 이라는 YAML 파일을 생성하여 Ingress 트래픽을 Ingress 배포로 라우팅하는 새 로드 밸런서 서비스를 구성합니다. 

    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
  4. metallb-loadbalancer-service.yaml 파일을 저장합니다.

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

    oc apply -f metallb-loadbalancer-service.yaml

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

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

HTTP/1.1 200 OK

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

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co

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

NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.x.y      True        False         3m32s   Cluster version is 4.x.y

NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.x.y     True        False         False      3m50s
clusteroperator.config.openshift.io/ingress                                    4.x.y     True        False         False      53m

+ 4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다(예: 4.14.0-x86_64 ).

1.7.7.8.1. 추가 리소스

1.7.7.9. 호스트 클러스터의 노드 자동 확장 활성화

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

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

    oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'

참고: 이 예에서 최소 노드 수는 2이고 최대값은 5입니다. 추가할 수 있는 최대 노드 수는 플랫폼에 바인딩될 수 있습니다. 예를 들어 에이전트 플랫폼을 사용하는 경우 사용 가능한 에이전트 수에 따라 최대 노드 수가 바인딩됩니다.

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

    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: {}
    2. 파일을 workload-config.yaml 로 저장합니다.
    3. 다음 명령을 입력하여 YAML을 적용합니다. 
    oc apply -f workload-config.yaml

  2. 다음 명령을 입력하여 admin-kubeconfig 시크릿을 추출합니다. 

    oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=./hostedcluster-secrets --confirm

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

    hostedcluster-secrets/kubeconfig

  3. 다음 명령을 입력하여 새 노드가 Ready 상태에 있는지 확인할 수 있습니다. 

    oc --kubeconfig ./hostedcluster-secrets get nodes

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

    oc --kubeconfig ./hostedcluster-secrets -n default delete deployment reversewords

  5. 추가 용량을 요구하지 않고 몇 분 정도 경과할 때까지 기다립니다. 에이전트 플랫폼에서 에이전트는 해제되어 재사용될 수 있습니다. 다음 명령을 입력하여 노드가 제거되었는지 확인할 수 있습니다. 

    oc --kubeconfig ./hostedcluster-secrets get nodes
1.7.7.9.1. 호스트 클러스터의 노드 자동 확장 비활성화

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

oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify-value-to-scale-replicas>]'

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

1.7.7.10. 베어 메탈에서 호스트 클러스터 삭제

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

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

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

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

    hcp destroy cluster agent --name <hosted_cluster_name>

    & lt;hosted_cluster_name& gt;을 호스트된 클러스터 이름으로 바꿉니다.

1.7.8. 베어 메탈이 아닌 에이전트를 사용하여 호스팅되는 컨트롤 플레인 클러스터 구성 (기술 프리뷰)

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

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

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

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

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

중요:

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

1.7.8.1. 사전 요구 사항

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

  • Kubernetes Operator 2.5 이상용 멀티 클러스터 엔진이 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 가 자동으로 가져옵니다. local-cluster 에 대한 자세한 내용은 고급 구성 을 참조하십시오. 다음 명령을 실행하여 허브 클러스터의 상태를 확인할 수 있습니다. 

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

1.7.8.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.8.3. 베어 메탈이 아닌 에이전트 머신에 대한 인프라 요구 사항

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

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

1.7.8.4. 베어 메탈이 아닌 에이전트 머신에서 DNS 구성

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

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

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

    api-int.example.krnl.es.    IN A 192.168.122.22
`*`.apps.example.krnl.es. IN A 192.168.122.23

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

    api-int.example.krnl.es.    IN A 2620:52:0:1306::7
`*`.apps.example.krnl.es. IN A 2620:52:0:1306::10

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

    host-record=api-int.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]

1.7.8.5. 베어 메탈이 아닌 에이전트 머신에서 호스트 클러스터 생성

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

  1. 다음 명령을 입력하여 호스팅된 컨트롤 플레인 네임스페이스를 생성합니다. 

    oc create ns <hosted-cluster-namespace>-<hosted-cluster-name>

    &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-key> \ 6
    --namespace <hosted-cluster-namespace> \ 7
    --control-plane-availability-policy SingleReplica \
    --release-image=quay.io/openshift-release-dev/ocp-release:<ocp-release> 8
    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 ).

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

    oc -n <hosted-control-plane-namespace> get pods

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

    NAME                                             READY   STATUS    RESTARTS   AGE
catalog-operator-6cd867cc7-phb2q                 2/2     Running   0          2m50s
control-plane-operator-f6b4c8465-4k5dh           1/1     Running   0          4m32s
1.7.8.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. 노드 풀 상태를 보려면 NodePool 섹션으로 스크롤합니다. 노드를 설치하는 프로세스에는 약 10분이 걸립니다. 노드를 클릭하여 노드가 호스팅된 클러스터에 참여하고 있는지 확인할 수도 있습니다.
1.7.8.5.2. 추가 리소스

1.7.8.6. 호스트된 클러스터 생성 확인

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

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

    oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

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

    oc get co --kubeconfig=kubeconfig-<hosted_cluster_name>

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

    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

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

    oc get pods -A --kubeconfig=kubeconfig-<hosted-cluster-name>

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

    NAMESPACE                                          NAME                                                      READY   STATUS             RESTARTS        AGE
kube-system                                        konnectivity-agent-khlqv                                  0/1     Running            0               3m52s
openshift-cluster-samples-operator                 cluster-samples-operator-6b5bcb9dff-kpnbc                 2/2     Running            0               20m
openshift-monitoring                               alertmanager-main-0                                       6/6     Running            0               100s
openshift-monitoring                               openshift-state-metrics-677b9fb74f-qqp6g                  3/3     Running            0               104s

1.7.8.7. 호스트 클러스터의 NodePool 오브젝트 스케일링

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

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

    oc -n <hosted-cluster-namespace> scale nodepool <nodepool-name> --replicas 2

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

    • 바인딩
    • 검색
    • insufficient
    • 설치
    • install-in-progress
    • add-to-existing-cluster

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

    oc -n <hosted-control-plane-namespace> get agent

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

    NAME                                   CLUSTER         APPROVED   ROLE          STAGE
4dac1ab2-7dd5-4894-a220-6a3473b67ee6   hypercluster1   true       auto-assign

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

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

    BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient

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

    oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

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

    oc --kubeconfig kubeconfig-<hosted-cluster-name> get nodes

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

    NAME           STATUS   ROLES    AGE     VERSION
ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f

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

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

    oc -n <hosted-control-plane-namespace> get machines

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

    NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.13z

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

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

    oc --kubeconfig kubeconfig-<hosted-cluster-name> get clusterversion,co

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

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

NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.13z    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.13z    True        False         False      10m
clusteroperator.config.openshift.io/dns                                        4.13z    True        False         False      9m16s
1.7.8.7.1. 노드 풀 추가

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

  1. 노드 풀을 생성하려면 다음 정보를 입력합니다. 

    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"}}' 1
    1
    --agentLabelSelector 는 선택 사항입니다. 노드 풀은 "size" : "medium" 라벨이 있는 에이전트를 사용합니다.

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

    oc get nodepools --namespace clusters

  3. 다음 명령을 입력하여 admin-kubeconfig 시크릿을 추출합니다. 

    oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=./hostedcluster-secrets --confirm

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

    hostedcluster-secrets/kubeconfig

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

    oc --kubeconfig ./hostedcluster-secrets get nodes

  5. 다음 명령을 입력하여 사용 가능한 노드 풀 수가 예상되는 노드 풀 수와 일치하는지 확인합니다. 

    oc get nodepools --namespace clusters
1.7.8.7.2. 추가 리소스

1.7.8.8. 베어 메탈이 아닌 에이전트 머신의 호스트 클러스터에서 수신 처리

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

*.apps 도메인의 로드 밸런서 및 와일드카드 DNS 레코드를 설정하려면 게스트 클러스터에서 다음 작업을 수행합니다.

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

    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
  2. 파일을 metallb-operator-config.yaml 로 저장합니다.

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

    oc apply -f metallb-operator-config.yaml

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

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

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

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

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

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

      1. 구성을 포함할 YAML 파일을 생성합니다. 
    apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: <ip_address_pool_name> 1
  namespace: metallb
spec:
  protocol: layer2
  autoAssign: false
  addresses:
    - <ingress_ip>-<ingress_ip> 2
---
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: <bgp_advertisement_name> 3
  namespace: metallb
spec:
  ipAddressPools:
    - <ip_address_pool_name> 4
1 4
IPAddressPool 리소스 이름을 지정합니다.
2
환경의 IP 주소를 지정합니다(예: 192.168.122.23 ).
3
BGPAdvertisement 리소스 이름을 지정합니다.
  1. 파일을 ipaddresspool-bgpadvertisement-config.yaml 로 저장합니다.

  2. 다음 명령을 입력하여 리소스를 생성합니다. 

    oc apply -f ipaddresspool-bgpadvertisement-config.yaml
    1. LoadBalancer 유형의 서비스를 생성한 후 MetalLB는 서비스에 대한 외부 IP 주소를 추가합니다.

  3. metallb-loadbalancer-service.yaml 이라는 YAML 파일을 생성하여 Ingress 트래픽을 Ingress 배포로 라우팅하는 새 로드 밸런서 서비스를 구성합니다. 

    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
  4. 파일을 metallb-loadbalancer-service.yaml 로 저장합니다.

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

    oc apply -f metallb-loadbalancer-service.yaml

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

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

HTTP/1.1 200 OK

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

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co

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

NAME                                         VERSION           AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.x.y             True        False         3m32s   Cluster version is 4.x.y

NAME                                                                           VERSION           AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.x.y             True        False         False      3m50s
clusteroperator.config.openshift.io/ingress                                    4.x.y             True        False         False      53m

+ 4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다(예: 4.14.0-x86_64 ).

1.7.8.8.1. 추가 리소스

1.7.8.9. 호스트 클러스터의 노드 자동 확장 활성화

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

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

    oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'

  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: {}
    2. 파일을 workload-config.yaml 로 저장합니다.
    3. 다음 명령을 입력하여 YAML을 적용합니다. 
    oc apply -f workload-config.yaml

  3. 다음 명령을 입력하여 admin-kubeconfig 시크릿을 추출합니다. 

    oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>admin-kubeconfig --to=./hostedcluster-secrets --confirm

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

    hostedcluster-secrets/kubeconfig

  4. 다음 명령을 입력하여 새 노드가 Ready 상태에 있는지 확인할 수 있습니다. 

    oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes

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

    oc --kubeconfig <hosted-cluster-name>.kubeconfig -n default delete deployment reversewords

  6. 추가 용량을 요구하지 않고 몇 분 정도 경과할 때까지 기다립니다. 에이전트 플랫폼에서 에이전트는 해제되어 재사용될 수 있습니다. 다음 명령을 입력하여 노드가 제거되었는지 확인할 수 있습니다. 

    oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes
1.7.8.9.1. 호스트 클러스터의 노드 자동 확장 비활성화

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

oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify-value-to-scale-replicas>]'

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

1.7.8.10. 베어 메탈이 아닌 에이전트 머신에서 호스트 클러스터 제거

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

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

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

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

    hcp destroy cluster agent --name <hosted_cluster_name>

    & lt;hosted_cluster_name& gt;을 호스트된 클러스터 이름으로 바꿉니다.

1.7.9. IBM Power 컴퓨팅 노드의 호스팅 컨트롤 플레인을 생성하도록 64비트 x86 OpenShift Container Platform 클러스터에서 호스팅 클러스터 구성 (기술 프리뷰)

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

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

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

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

중요:

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

1.7.9.1. 사전 요구 사항

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

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

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

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

1.7.9.2. IBM Power 인프라 요구사항

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

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

1.7.9.3. IBM Power 구성 문서

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

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

1.7.9.4. InfraEnv 리소스에 에이전트 추가

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

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

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

    oc -n <hosted-control-plane-namespace> get agents

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

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

  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

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

    oc -n <hosted-control-plane-namespace> get agents

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

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

1.7.9.5. IBM Power에서 호스팅된 컨트롤 플레인을 위한 DNS 구성

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

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

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

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

$ cat /var/named/<example.krnl.es.zone>

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

$ 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
1
레코드는 호스팅된 컨트롤 플레인의 수신 및 송신 트래픽을 처리하는 API 로드 밸런서의 IP 주소를 나타냅니다.

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

compute-0              IN A 1xx.2x.2xx.1yy
compute-1              IN A 1xx.2x.2xx.1yy

1.7.9.6. IBM Power 컴퓨팅 노드의 64비트 x86 베어 메탈에서 호스팅된 컨트롤 플레인에 대한 InfraEnv 리소스 생성

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-public-key>
  2. 파일을 infraenv-config.yaml 로 저장합니다.

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

    oc apply -f infraenv-config.yaml

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

    oc -n <hosted-control-plane-namespace> get InfraEnv <hosted-cluster-name> -o json

1.7.9.7. IBM Power에서 호스팅된 클러스터의 NodePool 오브젝트 확장

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

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

    oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2

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

    • 바인딩
    • 검색
    • insufficient
    • 설치
    • install-in-progress
    • add-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}'

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

    BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound
BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient

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

    oc -n <hosted_control_plane_namespace> get agent

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

    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

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

    hcp create kubeconfig --namespace <clusters_namespace> --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig

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

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes

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

    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

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

    oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io

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

    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.15.0
hosted-forwarder-79558597ff-lfjfk   hosted-forwarder-crqq5   worker-zvm-1.hostedn.example.com   agent://5e498cd3-542c-e54f-0c58-ed43e28b568a   Running   41h   4.15.0

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

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion

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

    NAME                                         VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.15.0   True        False         40h     Cluster version is 4.15.0

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

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators

클러스터의 각 구성 요소에 대해 출력에는 NAME,VERSION,AVAILABLE,PROGRESSING,DEGRADED,SINCE, MESSAGE.

출력 예제는 OpenShift Container Platform 설명서의 Initial Operator 구성 섹션을 참조하십시오.

1.7.9.7.1. 추가 리소스

1.7.10. IBM Z 컴퓨팅 노드의 x86 베어 메탈에서 호스팅 클러스터 구성 (기술 프리뷰)

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

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

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

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

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

중요:

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

1.7.10.1. 사전 요구 사항

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

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

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

1.7.10.2. IBM Z 인프라 요구사항

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

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

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

1.7.10.3. IBM Z 구성 문서

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

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

1.7.10.4. InfraEnv 리소스에 IBM Z 에이전트 추가 (기술 프리뷰)

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

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

1.7.10.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"

ISO 부팅의 경우 InfraEnv 리소스에서 ISO를 다운로드하고 다음 명령을 실행하여 노드를 부팅합니다. 

virt-install \
  --name "<vm_name>" \
  --autostart \
  --memory=16384 \
  --cpu host \
  --vcpus=4 \
  --network network:macvtap-net,mac=<mac_address> \
  --cdrom "<path_to_image.iso>" \
  --disk <qcow_image_path> \
  --graphics none \
  --noautoconsole \
  --os-variant <os_version> \
  --wait=-1 \
1.7.10.4.2. z/VM을 사용하여 IBM용 에이전트 추가

참고: z/VM 게스트에 고정 IP를 사용하려면 두 번째 부팅 시 IP 매개 변수가 유지되도록 z/VM 에이전트에 대한 NMStateConfig 특성을 구성해야 합니다.

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
    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>
    vmur pun -r -u -N generic.parm $PARMFILELOCATION/paramfilename
    vmur pun -r -u -N initrd.img $INSTALLERINITRAMFSLOCATION/<image name>

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

    cp ipl c

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

    oc -n <hosted_control_plane_namespace> get agents

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

    NAME    CLUSTER APPROVED    ROLE    STAGE
50c23cda-cedc-9bbd-bcf1-9b3a5c75804d    auto-assign
5e498cd3-542c-e54f-0c58-ed43e28b568a    auto-assign

  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

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

    oc -n <hosted_control_plane_namespace> get agents

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

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

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

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

$ 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
1
레코드는 호스팅된 컨트롤 플레인의 수신 및 송신 트래픽을 처리하는 API 로드 밸런서의 IP 주소를 나타냅니다.

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

compute-0              IN A 1xx.2x.2xx.1yy
compute-1              IN A 1xx.2x.2xx.1yy

1.7.10.6. IBM Z 컴퓨팅 노드의 x86 베어 메탈에서 호스팅된 컨트롤 플레인에 대한 InfraEnv 리소스 생성

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-public-key>
  2. 파일을 infraenv-config.yaml 로 저장합니다.

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

    oc apply -f infraenv-config.yaml

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

    oc -n <hosted-control-plane-namespace> get InfraEnv <hosted-cluster-name> -o json

1.7.10.7. IBM Z에서 호스팅된 클러스터의 NodePool 오브젝트 확장

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

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

    oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2

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

    • 바인딩
    • 검색
    • insufficient
    • 설치
    • install-in-progress
    • add-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}'

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

    BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound
BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient

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

    oc -n <hosted_control_plane_namespace> get agent

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

    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

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

    hcp create kubeconfig --namespace <clusters_namespace> --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig

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

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes

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

    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

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

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

    oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io

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

    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.15.0
hosted-forwarder-79558597ff-lfjfk   hosted-forwarder-crqq5   worker-zvm-1.hostedn.example.com   agent://5e498cd3-542c-e54f-0c58-ed43e28b568a   Running   41h   4.15.0

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

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co

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

    NAME                                         VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.15.0-ec.2   True        False         40h     Cluster version is 4.15.0-ec.2

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

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators

클러스터의 각 구성 요소에 대해 출력에는 NAME,VERSION,AVAILABLE,PROGRESSING,DEGRADED,SINCE, MESSAGE.

출력 예제는 OpenShift Container Platform 설명서의 Initial Operator 구성 섹션을 참조하십시오.

1.7.10.7.1. 추가 리소스

1.7.11. 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.11.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"}}]'
  • 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"}}}'
  • 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 가 자동으로 가져옵니다. local-cluster 에 대한 자세한 내용은 고급 구성 을 참조하십시오. 다음 명령을 실행하여 허브 클러스터의 상태를 확인할 수 있습니다. 

    oc get managedclusters local-cluster

1.7.11.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.11.3. KubeVirt 플랫폼을 사용하여 호스트 클러스터 생성

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

1.7.11.3.1. 호스트 클러스터 생성

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

    hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 1
--node-pool-replicas <worker-count> \ 2
--pull-secret <path-to-pull-secret> \ 3
--memory <value-for-memory> \ 4
--cores <value-for-cpu> \ 5
--etcd-storage-class=<etcd-storage-class> 6
    1
    호스팅된 클러스터의 이름을 지정합니다( 예: ).
    2
    작업자 수를 지정합니다(예: 2).
    3
    풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
    4
    메모리 값을 지정합니다(예: 6Gi ).
    5
    CPU 값을 지정합니다(예: 2 ).
    6
    etcd 스토리지 클래스 이름을 지정합니다(예: lvm-storageclass ).

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

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

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

    oc -n clusters-<hosted-cluster-name> get pods

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

    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

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

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

    oc get --namespace clusters hostedclusters

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

    NAMESPACE   NAME      VERSION   KUBECONFIG                 PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
clusters    example   4.x.0     example-admin-kubeconfig   Completed   True        False         The hosted control plane is available

    4.x.0 을 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

  4. 호스트 클러스터 액세스 지침에 따라 호스팅된 클러스터에 액세스 합니다.
1.7.11.3.2. 외부 인프라를 사용하여 호스트된 클러스터 생성

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

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

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

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

    hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 1
--node-pool-replicas <worker-count> \ 2
--pull-secret <path-to-pull-secret> \ 3
--memory <value-for-memory> \ 4
--cores <value-for-cpu> \ 5
--infra-namespace=<hosted-cluster-namespace>-<hosted-cluster-name> \ 6
--infra-kubeconfig-file=<path-to-external-infra-kubeconfig> 7
    1
    호스팅된 클러스터의 이름을 지정합니다( 예: ).
    2
    작업자 수를 지정합니다(예: 2).
    3
    풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
    4
    메모리 값을 지정합니다(예: 6Gi ).
    5
    CPU 값을 지정합니다(예: 2 ).
    6
    인프라 네임스페이스를 지정합니다(예: clusters-example ).
    7
    인프라 클러스터의 kubeconfig 파일의 경로를 지정합니다(예: /user/name/external-infra-kubeconfig ).

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

  2. 호스트 클러스터 액세스 지침에 따라 호스팅된 클러스터에 액세스 합니다.
1.7.11.3.3. 콘솔을 사용하여 호스트 클러스터 생성

콘솔을 사용하여 KubeVirt 플랫폼으로 호스팅된 클러스터를 생성하려면 다음 단계를 완료하십시오.

  1. OpenShift Container Platform 웹 콘솔을 열고 관리자 인증 정보를 입력하여 로그인합니다. 콘솔을 여는 방법은 OpenShift Container Platform 설명서 의 웹 콘솔 액세스를 참조하십시오.
  2. 콘솔 헤더에서 모든 클러스터 가 선택되어 있는지 확인합니다.
  3. Infrastructure > Clusters를 클릭합니다.
  4. Create cluster > Red Hat OpenShift Virtualization > Hosted를 클릭합니다.

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

    참고:

    • 사전 정의된 값을 사용하여 콘솔에서 필드를 자동으로 채우려면 Red Hat OpenShift Virtualization 인증 정보를 생성할 수 있습니다. 자세한 내용은 온-프레미스 환경에 대한 인증 정보 만들기 를 참조하십시오.
    • 클러스터 세부 정보 페이지에서 풀 시크릿은 OpenShift Container Platform 리소스에 액세스하는 데 사용하는 OpenShift Container Platform 풀 시크릿입니다. Red Hat OpenShift Virtualization 인증 정보를 선택한 경우 풀 시크릿이 자동으로 채워집니다.

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

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

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

1.7.11.4. 기본 수신 및 DNS 동작

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

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

*.apps.mgmt-cluster.example.com

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

*.apps.guest.apps.mgmt-cluster.example.com

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

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

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

1.7.11.4.1. 수신 및 DNS 동작 사용자 정의

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

1.7.11.4.1.1. 기본 도메인을 지정하는 호스팅된 클러스터 배포

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

    hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 1
--node-pool-replicas <worker-count> \ 2
--pull-secret <path-to-pull-secret> \ 3
--memory <value-for-memory> \ 4
--cores <value-for-cpu> \ 5
--base-domain <basedomain> 6
1
호스팅된 클러스터의 이름을 지정합니다( 예: ).
2
작업자 수를 지정합니다(예: 2).
3
풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
4
메모리 값을 지정합니다(예: 6Gi ).
5
CPU 값을 지정합니다(예: 2 ).
6
기본 도메인을 지정합니다(예: hypershift.lab ).

결과적으로 호스팅된 클러스터에는 클러스터 이름과 기본 도메인(예: .apps.example.hypershift.lab )에 대해 구성된 수신 와일드카드가 있습니다. 호스트 클러스터는 부분 상태로 유지됩니다. 고유 기본 도메인을 사용하여 호스팅 클러스터를 생성한 후 필요한 DNS 레코드 및 로드 밸런서를 구성해야 합니다.

  1. 다음 명령을 입력하여 호스팅 클러스터의 상태를 확인합니다. 

    oc get --namespace clusters hostedclusters

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

    NAME            VERSION   KUBECONFIG                       PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
example                   example-admin-kubeconfig         Partial    True        False         The hosted control plane is available

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

    hcp create kubeconfig --name <hosted-cluster-name> > <hosted-cluster-name>-kubeconfig
    oc --kubeconfig <hosted-cluster-name>-kubeconfig get co

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

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
console                                    4.x.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.x.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)

    4.x.0 을 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

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

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

1.7.11.4.1.2. 로드 밸런서 설정

Ingress 트래픽을 KubeVirt VM으로 라우팅하고 로드 밸런서 IP 주소에 와일드카드 DNS 항목을 할당하는 로드 밸런서 서비스를 설정합니다.

  1. 호스팅된 클러스터 인그레스를 노출하는 NodePort 서비스가 이미 존재합니다. 노드 포트를 내보내고 해당 포트를 대상으로 하는 로드 밸런서 서비스를 생성할 수 있습니다.

    1. 다음 명령을 입력하여 HTTP 노드 포트를 가져옵니다. 

      oc --kubeconfig <hosted-cluster-name>-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}'

      다음 단계에서 사용할 HTTP 노드 포트 값을 확인합니다.

    2. 다음 명령을 입력하여 HTTPS 노드 포트를 가져옵니다. 

      oc --kubeconfig <hosted-cluster-name>-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}'

    다음 단계에서 사용할 HTTPS 노드 포트 값을 확인합니다.

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

    oc apply -f -
apiVersion: v1
kind: Service
metadata:
  labels:
    app: <hosted-cluster-name>
  name: <hosted-cluster-name>-apps
  namespace: clusters-<hosted-cluster-name>
spec:
  ports:
  - name: https-443
    port: 443
    protocol: TCP
    targetPort: <https-node-port> 1
  - name: http-80
    port: 80
    protocol: TCP
    targetPort: <http-node-port> 2
  selector:
    kubevirt.io: virt-launcher
  type: LoadBalancer
    1
    이전 단계에서 기록한 HTTPS 노드 포트 값을 지정합니다.
    2
    이전 단계에서 기록한 HTTP 노드 포트 값을 지정합니다.
1.7.11.4.1.3. 와일드카드 DNS 설정

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

  1. 다음 명령을 입력하여 외부 IP 주소를 가져옵니다. 

    oc -n clusters-<hosted-cluster-name> get service <hosted-cluster-name>-apps -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

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

    192.168.20.30

  2. 외부 IP 주소를 참조하는 와일드카드 DNS 항목을 구성합니다. 다음 예제 DNS 항목을 확인합니다. 

    *.apps.<hosted-cluster-name\>.<base-domain\>.

    DNS 항목은 클러스터 내부 및 외부에서 라우팅할 수 있어야 합니다. 다음 DNS 확인 예를 참조하십시오. 

    dig +short test.apps.example.hypershift.lab

192.168.20.30

  3. 다음 명령을 입력하여 호스팅 클러스터 상태가 Partial 에서 Completed 로 이동했는지 확인합니다. 

    oc get --namespace clusters hostedclusters

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

    NAME            VERSION   KUBECONFIG                       PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
example         4.x.0     example-admin-kubeconfig         Completed   True        False         The hosted control plane is available

    4.x.0 을 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

1.7.11.4.1.4. 추가 리소스

1.7.11.5. 선택사항: MetalLB 구성

MetalLB를 구성하기 전에 MetalLB Operator를 설치해야 합니다. 자세한 내용은 OpenShift Container Platform 설명서에서 MetalLB Operator 설치를 참조하십시오.

게스트 클러스터에서 MetalLB를 구성하려면 다음 단계를 수행합니다.

  1. 다음 샘플 YAML 콘텐츠를 configure-metallb.yaml 파일에 저장하여 MetalLB 리소스를 생성합니다. 

    apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system

  2. 다음 명령을 입력하여 YAML 콘텐츠를 적용합니다. 

    oc apply -f configure-metallb.yaml

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

    metallb.metallb.io/metallb created

  3. create-ip-address-pool.yaml 파일에 다음 샘플 YAML 콘텐츠를 저장하여 IPAddressPool 리소스를 만듭니다. 

    apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: metallb
  namespace: metallb-system
spec:
  addresses:
  - 192.168.216.32-192.168.216.122 1
    1
    노드 네트워크 내에서 사용 가능한 IP 주소 범위를 사용하여 주소 풀을 생성합니다. IP 주소 범위를 네트워크에서 사용 가능한 IP 주소의 사용되지 않는 풀로 바꿉니다.

  4. 다음 명령을 입력하여 YAML 콘텐츠를 적용합니다. 

    oc apply -f create-ip-address-pool.yaml

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

    ipaddresspool.metallb.io/metallb created

  5. l2advertisement.yaml 파일에 다음 샘플 YAML 콘텐츠를 저장하여 L2Advertisement 리소스를 생성합니다. 

    apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertisement
  namespace: metallb-system
spec:
  ipAddressPools:
   - metallb

  6. 다음 명령을 입력하여 YAML 콘텐츠를 적용합니다. 

    oc apply -f l2advertisement.yaml

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

    l2advertisement.metallb.io/metallb created
1.7.11.5.1. 추가 리소스

1.7.11.6. 노드 풀에 대한 추가 네트워크, 보장된 CPU 및 VM 스케줄링 구성

노드 풀에 대한 추가 네트워크를 구성해야 하는 경우 가상 머신(VM)에 대한 보장된 CPU 액세스를 요청하거나 KubeVirt VM의 스케줄링을 관리해야 하는 경우 다음 절차를 참조하십시오.

1.7.11.6.1. 노드 풀에 여러 네트워크 추가

기본적으로 노드 풀에서 생성한 노드는 Pod 네트워크에 연결됩니다. Multus 및 NetworkAttachmentDefinitions를 사용하여 추가 네트워크를 노드에 연결할 수 있습니다.

노드에 여러 네트워크를 추가하려면 다음 명령을 실행하여 --additional-network 인수를 사용합니다. 

hcp create cluster kubevirt \
--name <hosted_cluster_name> \ 1
--node-pool-replicas <worker_node_count> \ 2
--pull-secret <path_to_pull_secret> \ 3
--memory <memory> \ 4
--cores <cpu> \ 5
--additional-network name:<namespace/name> \ 6
–-additional-network name:<namespace/name>
1
호스팅된 클러스터의 이름을 지정합니다( 예: ).
2
작업자 노드 수를 지정합니다(예: 2 ).
3
풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
4
메모리 값을 지정합니다(예: 8Gi ).
5
CPU 값을 지정합니다(예: 2 ).
6
-additional-network 인수의 값을 name:<namespace/name> 로 설정합니다. & lt;namespace/name& gt;을 NetworkAttachmentDefinitions의 네임스페이스 및 이름으로 바꿉니다.
1.7.11.6.2. 보장된 CPU 리소스 요청

기본적으로 KubeVirt VM은 노드의 다른 워크로드와 해당 CPU를 공유할 수 있습니다. 이는 VM의 성능에 영향을 미칠 수 있습니다. 성능에 미치는 영향을 방지하기 위해 VM에 대해 보장된 CPU 액세스를 요청할 수 있습니다.

보장된 CPU 리소스를 요청하려면 다음 명령을 실행하여 --qos-class 인수를 Guaranteed 로 설정합니다. 

hcp create cluster kubevirt \
--name <hosted_cluster_name> \ 1
--node-pool-replicas <worker_node_count> \ 2
--pull-secret <path_to_pull_secret> \ 3
--memory <memory> \ 4
--cores <cpu> \ 5
--qos-class Guaranteed 6
1
호스팅된 클러스터의 이름을 지정합니다( 예: ).
2
작업자 노드 수를 지정합니다(예: 2 ).
3
풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
4
메모리 값을 지정합니다(예: 8Gi ).
5
CPU 값을 지정합니다(예: 2 ).
6
--qos-class Guaranteed 인수를 사용하면 지정된 수의 CPU 리소스가 VM에 할당됩니다.
1.7.11.6.3. 노드 세트에서 KubeVirt VM 예약

기본적으로 노드 풀에서 생성한 KubeVirt VM은 사용 가능한 모든 노드에 예약됩니다. VM을 실행하는 데 충분한 용량이 있는 특정 노드 세트에서 KubeVirt VM을 예약할 수 있습니다.

특정 노드 세트의 노드 풀 내에서 KubeVirt VM을 예약하려면 다음 명령을 실행하여 --vm-node-selector 인수를 사용합니다. 

hcp create cluster kubevirt \
--name <hosted_cluster_name> \ 1
--node-pool-replicas <worker_node_count> \ 2
--pull-secret <path_to_pull_secret> \ 3
--memory <memory> \ 4
--cores <cpu> \ 5
--vm-node-selector <label_key>=<label_value>,<label_key>=<label_value> 6
1
호스팅된 클러스터의 이름을 지정합니다( 예: ).
2
작업자 노드 수를 지정합니다(예: 2 ).
3
풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
4
메모리 값을 지정합니다(예: 8Gi ).
5
CPU 값을 지정합니다(예: 2 ).
6
--vm-node-selector 플래그는 키-값 쌍을 포함하는 특정 노드 세트를 정의합니다. & lt;label_key > 및 < label_value >를 각각 레이블의 키와 값으로 바꿉니다.

1.7.11.7. 노드 풀 확장

  1. oc scale 명령을 사용하여 노드 풀을 수동으로 확장할 수 있습니다. 

    NODEPOOL_NAME=${CLUSTER_NAME}-work
NODEPOOL_REPLICAS=5

oc scale nodepool/$NODEPOOL_NAME --namespace clusters --replicas=$NODEPOOL_REPLICAS

  2. 잠시 후 다음 명령을 입력하여 노드 풀의 상태를 확인합니다. 

    oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes

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

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

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

    oc get nodepools --namespace clusters

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

    NAME                      CLUSTER         DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
example                   example         5               5               False         False        4.x.0
example-extra-cpu         example         2                               False         False                  True              True             Minimum availability requires 2 replicas, current 0 available

    4.x.0 을 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

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

    oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes

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

    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

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

    oc get nodepools --namespace clusters

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

    NAME                      CLUSTER         DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
example                   example         5               5               False         False        4.x.0
example-extra-cpu         example         2               2               False         False        4.x.0

    4.x.0 을 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

1.7.11.7.1.1. 추가 리소스

1.7.11.8. OpenShift Virtualization에서 호스트된 클러스터 생성 확인

호스팅 클러스터가 성공적으로 생성되었는지 확인하려면 다음 단계를 완료합니다.

  1. 다음 명령을 입력하여 HostedCluster 리소스가 완료된 상태로 전환되었는지 확인합니다. 

    oc get --namespace clusters hostedclusters ${CLUSTER_NAME}

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

    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

  2. 다음 명령을 입력하여 호스팅 클러스터의 모든 클러스터 운영자가 온라인 상태인지 확인합니다. 

    hcp create kubeconfig --name $CLUSTER_NAME > $CLUSTER_NAME-kubeconfig
    oc get co --kubeconfig=$CLUSTER_NAME-kubeconfig

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

    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

1.7.11.9. OpenShift Virtualization에서 호스팅된 컨트롤 플레인을 위한 스토리지 구성

고급 구성이 제공되지 않으면 KubeVirt 가상 머신(VM) 이미지, KubeVirt CSI 매핑 및 etcd 볼륨에 기본 스토리지 클래스가 사용됩니다.

1.7.11.9.1. KubeVirt CSI 스토리지 클래스 매핑

kubevirt CSI를 사용하면 ReadWriteMany 액세스 모드가 있는 모든 인프라 스토리지 클래스를 호스트된 클러스터에 노출할 수 있습니다. --infra-storage-class-mapping 인수를 사용하여 클러스터 생성 중에 클러스터 스토리지 클래스를 호스팅하도록 인프라 클러스터 스토리지 클래스의 매핑을 구성할 수 있습니다.

인프라 스토리지 클래스를 호스팅 스토리지 클래스에 매핑하려면 다음 예제를 참조하십시오. 

hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 1
--node-pool-replicas <worker-count> \ 2
--pull-secret <path-to-pull-secret> \ 3
--memory <value-for-memory> \ 4
--cores <value-for-cpu> \ 5
--infra-storage-class-mapping=<storage-class>/<hosted-storage-class> \ 6
1
호스팅된 클러스터의 이름을 지정합니다( 예: ).
2
작업자 수를 지정합니다(예: 2).
3
풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
4
메모리 값을 지정합니다(예: 6Gi ).
5
CPU 값을 지정합니다(예: 2 ).
6
< storage-class >를 인프라 스토리지 클래스 이름으로 바꾸고 < hosted-storage-class >를 호스팅된 클러스터 스토리지 클래스 이름으로 바꿉니다. create 명령에서 --infra-storage-class-mapping 인수를 여러 번 사용할 수 있습니다.

호스팅된 클러스터를 생성하면 인프라 스토리지 클래스가 호스팅된 클러스터 내에서 표시됩니다. 이러한 스토리지 클래스 중 하나를 사용하는 호스트 클러스터 내에서 PVC를 생성하면 KubeVirt CSI는 클러스터 생성 중에 구성한 인프라 스토리지 클래스 매핑을 사용하여 해당 볼륨을 프로비저닝합니다.

참고: KubeVirt CSI는 RWX( ReadWriteMany ) 액세스를 수행할 수 있는 인프라 스토리지 클래스만 매핑을 지원합니다.

1.7.11.9.2. KubeVirt VM 루트 볼륨 구성

클러스터 생성 시 --root-volume-storage-class 인수를 사용하여 KubeVirt VM 루트 볼륨을 호스팅하는 데 사용되는 스토리지 클래스를 구성할 수 있습니다.

KubeVirt VM의 사용자 정의 스토리지 클래스 및 볼륨 크기를 설정하려면 다음 예제를 참조하십시오. 

hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 1
--node-pool-replicas <worker-count> \ 2
--pull-secret <path-to-pull-secret> \ 3
--memory <value-for-memory> \ 4
--cores <value-for-cpu> \ 5
--root-volume-storage-class <root-volume-storage-class> \ 6
--root-volume-size <volume-size> 7
1
호스팅된 클러스터의 이름을 지정합니다( 예: ).
2
작업자 수를 지정합니다(예: 2).
3
풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
4
메모리 값을 지정합니다(예: 6Gi ).
5
CPU 값을 지정합니다(예: 2 ).
6
KubeVirt VM 루트 볼륨을 호스팅하는 데 사용되는 스토리지 클래스의 이름을 지정합니다(예: ocs-storagecluster-ceph-rbd ).
7
볼륨 크기를 지정합니다(예: 64 ).

결과적으로 ocs-storagecluster-ceph-rdb 스토리지 클래스에서 호스팅하는 PVC에서 호스팅되는 VM이 있는 호스팅 클러스터입니다.

1.7.11.9.3. KubeVirt VM 이미지 캐싱 활성화

kubevirt 이미지 캐싱은 클러스터 시작 시간과 스토리지 사용률을 모두 최적화하는 데 사용할 수 있는 고급 기능입니다. 이 기능을 사용하려면 스마트 복제 및 ReadWriteMany 액세스 모드가 가능한 스토리지 클래스를 사용해야 합니다. 스마트 복제에 대한 자세한 내용은 스마트 복제 를 사용하여 데이터 볼륨 복제를 참조하십시오.

이미지 캐싱은 다음과 같이 작동합니다.

  1. VM 이미지는 호스팅된 클러스터와 연결된 PVC로 가져옵니다.
  2. 해당 PVC의 고유한 복제본은 클러스터에 작업자 노드로 추가되는 모든 KubeVirt VM에 대해 생성됩니다.

이미지 캐싱은 단일 이미지 가져오기만 요구하여 VM 시작 시간을 줄입니다. 스토리지 클래스가 COW(Copy-On-Write) 복제를 지원하는 경우 전체 클러스터 스토리지 사용량을 추가로 줄일 수 있습니다.

이미지 캐싱을 활성화하려면 클러스터 생성 중에 다음 예와 같이 --root-volume-cache-strategy=PVC 인수를 사용합니다. 

hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 1
--node-pool-replicas <worker-count> \ 2
--pull-secret <path-to-pull-secret> \ 3
--memory <value-for-memory> \ 4
--cores <value-for-cpu> \ 5
--root-volume-cache-strategy=PVC 6
1
호스팅된 클러스터의 이름을 지정합니다( 예: ).
2
작업자 수를 지정합니다(예: 2).
3
풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
4
메모리 값을 지정합니다(예: 6Gi ).
5
CPU 값을 지정합니다(예: 2 ).
6
이미지 캐싱 전략을 지정합니다(예: PVC ).
1.7.11.9.4. etcd 스토리지 구성

클러스터 생성 시 --etcd-storage-class 인수를 사용하여 etcd 데이터를 호스팅하는 데 사용되는 스토리지 클래스를 구성할 수 있습니다.

etcd의 스토리지 클래스를 구성하려면 다음 예제를 참조하십시오. 

hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 1
--node-pool-replicas <worker-count> \ 2
--pull-secret <path-to-pull-secret> \ 3
--memory <value-for-memory> \ 4
--cores <value-for-cpu> \ 5
--etcd-storage-class=<etcd-storage-class-name> 6
1
호스팅된 클러스터의 이름을 지정합니다( 예: ).
2
작업자 수를 지정합니다(예: 2).
3
풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
4
메모리 값을 지정합니다(예: 6Gi ).
5
CPU 값을 지정합니다(예: 2 ).
6
etcd 스토리지 클래스 이름을 지정합니다(예: lvm-storageclass ). --etcd-storage-class 인수를 제공하지 않으면 기본 스토리지 클래스가 사용됩니다.
1.7.11.9.4.1. 추가 리소스

1.7.11.10. OpenShift Virtualization에서 호스트된 클러스터 삭제

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

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

    oc delete managedcluster <managed_cluster_name>

    여기서 <managed_cluster_name >은 관리 클러스터의 이름입니다.

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

    hcp destroy cluster kubevirt --name <hosted_cluster_name>

    &lt ;hosted_cluster_name> 을 호스트된 클러스터 이름으로 교체합니다.

1.7.12. 연결이 끊긴 환경에서 호스트된 컨트롤 플레인 구성

연결이 끊긴 환경은 인터넷에 연결되어 있지 않으며 호스팅된 컨트롤 플레인을 기반으로 사용하는 OpenShift Container Platform 클러스터입니다.

기술 프리뷰: IPv4 또는 IPv6 네트워크를 사용하여 베어 메탈 플랫폼의 연결이 끊긴 환경에 호스팅된 컨트롤 플레인을 배포할 수 있습니다. 또한 연결이 끊긴 환경의 호스팅 컨트롤 플레인은 듀얼 스택 네트워크에서 기술 프리뷰 기능으로 사용할 수 있습니다. Red Hat OpenShift Virtualization 플랫폼을 사용하는 경우 연결이 끊긴 환경에서 호스팅되는 컨트롤 플레인을 기술 프리뷰 기능으로만 사용할 수 있습니다.

1.7.12.1. 연결이 끊긴 환경 아키텍처

에이전트 플랫폼을 사용하여 베어 메탈에서 호스팅되는 컨트롤 플레인을 프로비저닝할 수 있습니다. 에이전트 플랫폼은 중앙 인프라 관리 서비스를 사용하여 호스트된 클러스터에 작업자 노드를 추가합니다. 중앙 인프라 관리 서비스에 대한 소개는 중앙 인프라 관리 서비스 활성화를 참조하십시오.

연결이 끊긴 환경의 다음 아키텍처 다이어그램을 참조하십시오.

Disconnected architecture diagram

  1. 연결이 끊긴 배포가 작동하는지 확인하기 위해 TLS 지원, 웹 서버 및 DNS를 사용하여 레지스트리 인증서 배포를 포함한 인프라 서비스를 구성합니다.

  2. openshift-config 네임스페이스에 구성 맵을 생성합니다. 구성 맵의 내용은 레지스트리 CA 인증서입니다. 구성 맵의 data 필드에는 다음 키와 값이 포함되어야 합니다.

    • 키: < registry_dns_domain_name>..<port > (예: registry.hypershiftdomain.lab..5000: ). 포트를 지정할 때 레지스트리 DNS 도메인 이름 뒤에 .. 를 배치해야 합니다.
    • value: 인증서 콘텐츠

    구성 맵 생성에 대한 자세한 내용은 IPv4 네트워크의 TLS 인증서 구성을 참조하십시오.

  3. images.config.openshift.io CR(사용자 정의 리소스)에 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: | 1
    -----BEGIN CERTIFICATE-----
    ...
    ...
    ...
    -----END CERTIFICATE-----
  registries.conf: | 2
    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
...
...
1
레지스트리의 CA 인증서를 포함합니다.
2
RAW 형식의 registries.conf 파일 콘텐츠를 포함합니다.
  1. 다중 클러스터 엔진 Operator 네임스페이스에서 Agent 및 hypershift-addon 애드온을 둘 다 활성화하는 multiclusterengine CR을 생성합니다. 다중 클러스터 엔진 Operator 네임스페이스에는 연결이 끊긴 배포에서 동작을 수정하려면 구성 맵이 포함되어야 합니다. 네임스페이스에는 multicluster-engine,assisted-service, hypershift-addon-manager Pod도 포함되어 있습니다.

  2. 다음 구성 요소에 대한 오브젝트를 생성하여 호스팅된 클러스터를 배포합니다.

    • 보안: 시크릿에는 풀 시크릿, SSH 키 및 etcd 암호화 키가 포함됩니다.
    • 구성 맵: 구성 맵에는 프라이빗 레지스트리의 CA 인증서가 포함되어 있습니다.
    • HostedCluster: HostedCluster 리소스는 호스팅된 클러스터에 대한 구성을 정의합니다.
    • NodePool: NodePool 리소스는 데이터 플레인에 사용할 머신을 참조하는 노드 풀을 식별합니다.
  3. 호스팅된 클러스터 오브젝트를 생성한 후 HyperShift Operator는 HostedControlPlane 네임스페이스에 컨트롤 플레인 Pod를 생성합니다. HostedControlPlane 네임스페이스는 에이전트, 베어 메탈 호스트 및 InfraEnv 리소스와 같은 구성 요소도 호스팅합니다.
  4. InfraEnv 리소스를 만듭니다. ISO 이미지를 생성한 후 베어 메탈 호스트와 BMC(Baseboard Management Controller) 인증 정보가 포함된 시크릿을 생성합니다.
  5. openshift-machine-api 네임스페이스의 Metal3 Operator는 새 베어 메탈 호스트를 검사합니다.
  6. Metal3 Operator는 LiveISO 및 RootFS 값을 사용하여 BMC를 연결하고 시작합니다. 다중 클러스터 엔진 Operator 네임스페이스의 AgentServiceConfig CR을 통해 LiveISO 및 RootFS 값을 지정할 수 있습니다.
  7. HostedCluster 리소스의 작업자 노드가 시작되면 에이전트 컨테이너가 시작됩니다.
  8. NodePool 리소스를 HostedCluster 리소스의 작업자 노드 수로 스케일링합니다.
  9. 배포 프로세스가 완료될 때까지 기다립니다.

1.7.12.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.12.3. OpenShift Container Platform 릴리스 이미지 다이제스트 추출

태그된 이미지를 사용하여 OpenShift Container Platform 릴리스 이미지 다이제스트를 추출할 수 있습니다. 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 이미지 다이제스트를 가져옵니다. 

    oc adm release info <tagged_openshift_release_image> | grep "Pull From"

    < 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

    이미지 태그 및 다이제스트에 대한 자세한 내용은 OpenShift Container Platform 설명서의 이미지 스트림 참조 에서 참조하십시오.

1.7.12.3.1. 추가 리소스

1.7.12.4. 연결이 끊긴 환경에서 사용자 워크로드 모니터링

하이퍼shift-addon 관리 클러스터 애드온은 HyperShift Operator에서 --enable-uwm-telemetry-remote-write 옵션을 활성화합니다. 이 옵션을 활성화하면 사용자 워크로드 모니터링이 활성화되고 컨트롤 플레인에서 Telemetry 메트릭을 원격으로 작성할 수 있습니다.

인터넷에 연결되지 않은 OpenShift Container Platform 클러스터에 다중 클러스터 엔진 Operator를 설치한 경우 다음 명령을 입력하여 HyperShift Operator의 사용자 워크로드 모니터링 기능을 실행하려고 하면 오류와 함께 기능이 실패합니다. 

oc get events -n hypershift

오류는 다음과 같을 수 있습니다. 

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

이 오류를 방지하려면 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"
1.7.12.4.1. 호스트된 컨트롤 플레인 기능의 상태 확인

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

  1. 기능이 비활성화되고 이를 활성화하려면 다음 명령을 입력합니다. multiclusterengine 을 다중 클러스터 엔진 Operator 인스턴스의 이름으로 교체합니다. 

    oc patch mce <multiclusterengine> --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}'

    기능을 활성화하면 hypershift-addon 관리 클러스터 애드온이 로컬 클러스터 관리 클러스터에 설치되고 애드온 에이전트는 다중 클러스터 엔진 Operator 허브 클러스터에 HyperShift Operator를 설치합니다.

  2. 다음 명령을 입력하여 hypershift-addon 관리 클러스터 애드온이 설치되었는지 확인합니다. 

    oc get managedclusteraddons -n local-cluster hypershift-addon

  3. 결과 출력을 확인합니다. 

    NAME               AVAILABLE   DEGRADED   PROGRESSING
hypershift-addon   True        False

  4. 이 프로세스 중에 시간 초과를 방지하려면 다음 명령을 입력합니다. 

    oc wait --for=condition=Degraded=True managedclusteraddons/hypershift-addon -n local-cluster --timeout=5m
    oc wait --for=condition=Available=True managedclusteraddons/hypershift-addon -n local-cluster --timeout=5m

    프로세스가 완료되면 hypershift-addon 관리 클러스터 애드온 및 HyperShift Operator가 설치되고 로컬 클러스터 관리 클러스터를 호스팅 및 관리할 수 있습니다.

1.7.12.4.2. 인프라 노드에서 실행되도록 하이퍼shift-addon 관리 클러스터 애드온 구성

기본적으로 hypershift-addon 관리 클러스터 애드온에 노드 배치 기본 설정은 지정되지 않습니다. 인프라 노드에서 애드온을 실행하는 것이 좋습니다. 이렇게 하면 서브스크립션 수와 별도의 유지 관리 및 관리 작업에 대해 청구 비용이 발생하지 않도록 할 수 있습니다.

  1. hub 클러스터에 로그인합니다.

  2. 다음 명령을 입력하여 편집할 hypershift-addon-deploy-config 배포 구성 사양을 엽니다. 

    oc edit addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine

  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
  4. 변경 사항을 저장합니다. 하이퍼shift-addon 관리 클러스터 애드온은 신규 및 기존 관리 클러스터를 위해 인프라 노드에 배포됩니다.

1.7.12.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.12.5.1. IPv4 네트워크에 대한 하이퍼바이저 구성

다음 정보는 가상 머신 환경에만 적용됩니다.

1.7.12.5.1.1. 가상 OpenShift Container Platform 클러스터용 패키지 액세스 및 배포

  1. 가상 OpenShift Container Platform 관리 클러스터를 배포하려면 다음 명령을 입력하여 필요한 패키지에 액세스합니다. 

    sudo dnf install dnsmasq radvd vim golang podman bind-utils net-tools httpd-tools tree htop strace tmux -y

  2. 다음 명령을 입력하여 Podman 서비스를 활성화하고 시작합니다. 

    systemctl enable --now podman

  3. kcli 를 사용하여 OpenShift Container Platform 관리 클러스터 및 기타 가상 구성 요소를 배포하려면 다음 명령을 입력하여 하이퍼바이저를 설치 및 구성합니다. 

    sudo yum -y install libvirt libvirt-daemon-driver-qemu qemu-kvm
    sudo usermod -aG qemu,libvirt $(id -un)
    sudo newgrp libvirt
    sudo systemctl enable --now libvirtd
    sudo dnf -y copr enable karmab/kcli
    sudo dnf -y install kcli
    sudo kcli create pool -p /var/lib/libvirt/images default
    kcli create host kvm -H 127.0.0.1 local
    sudo setfacl -m u:$(id -un):rwx /var/lib/libvirt/images
    kcli create network  -c 192.168.122.0/24 default
1.7.12.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"
    1
    OpenShift Container Platform 관리 클러스터를 호스팅하는 하이퍼바이저 인터페이스의 IP 주소를 가리키도록 IP 변수를 수정합니다.
    2
    dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

  2. 파일을 생성한 후 다음 명령을 입력하여 권한을 추가합니다. 

    chmod 755 /etc/NetworkManager/dispatcher.d/forcedns
  3. 스크립트를 실행하고 출력이 ok 를 반환하는지 확인합니다.
1.7.12.5.1.3. BMC 액세스 구성

  1. 가상 머신의 BMC(Baseboard Management Controller)를 시뮬레이션하도록 ksushy 를 구성합니다. 다음 명령을 입력합니다. 

    sudo dnf install python3-pyOpenSSL.noarch python3-cherrypy -y
    kcli create sushy-service --ssl --port 9000
    sudo systemctl daemon-reload
    systemctl enable --now ksushy

  2. 다음 명령을 입력하여 서비스가 올바르게 작동하는지 테스트합니다. 

    systemctl status ksushy
1.7.12.5.1.4. 연결을 허용하도록 하이퍼바이저 시스템 구성

개발 환경에서 작업하는 경우 환경 내에서 다양한 가상 네트워크를 통한 다양한 유형의 연결을 허용하도록 하이퍼바이저 시스템을 구성합니다.

참고: 프로덕션 환경에서 작업하는 경우 firewalld 서비스에 대한 적절한 규칙을 설정하고 안전한 환경을 유지 관리하도록 SELinux 정책을 구성해야 합니다.

  • SELinux의 경우 다음 명령을 입력합니다. 

    sed -i s/^SELINUX=.*$/SELINUX=permissive/ /etc/selinux/config; setenforce 0

  • firewalld 의 경우 다음 명령을 입력합니다. 

    systemctl disable --now firewalld

  • libvirtd 의 경우 다음 명령을 입력합니다. 

    systemctl restart libvirtd
    systemctl enable --now libvirtd

다음으로 환경에 맞게 DNS를 구성합니다.

1.7.12.5.1.5. 추가 리소스
1.7.12.5.2. IPv4 네트워크에 대한 DNS 구성

이 단계는 가상 및 베어 메탈 환경 모두에서 연결이 끊긴 환경과 연결된 환경 모두에 필요합니다. 가상 환경과 베어 메탈 환경 간의 주요 차이점은 리소스를 구성하는 위치에 있습니다. 베어 메탈 환경에서는 dnsmasq 와 같은 경량 솔루션이 아닌 바인딩과 같은 솔루션을 사용합니다.

다음으로 레지스트리를 배포합니다.

1.7.12.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
    1
    PULL_SECRET 위치를 설정에 적합한 위치로 교체합니다.

  2. 스크립트 파일 이름을 registry.sh 로 지정하고 저장합니다. 스크립트를 실행하면 다음 정보를 가져옵니다.

    • 하이퍼바이저 호스트 이름을 기반으로 하는 레지스트리 이름
    • 필요한 인증 정보 및 사용자 액세스 세부 정보

  3. 다음과 같이 실행 플래그를 추가하여 권한을 조정합니다. 

    chmod u+x ${HOME}/registry.sh

  4. 매개변수 없이 스크립트를 실행하려면 다음 명령을 입력합니다. 

    ${HOME}/registry.sh

    스크립트가 서버를 시작합니다.

  5. 스크립트는 관리 목적으로 systemd 서비스를 사용합니다. 스크립트를 관리해야 하는 경우 다음 명령을 사용할 수 있습니다. 

    systemctl status
    systemctl start
    systemctl stop

레지스트리의 루트 폴더는 /opt/registry 디렉터리에 있으며 다음 하위 디렉터리가 포함되어 있습니다.

  • 인증서에는 TLS 인증서가 포함되어 있습니다.
  • auth 에는 인증 정보가 포함됩니다.
  • 데이터에 는 레지스트리 이미지가 포함되어 있습니다.
  • conf 에는 레지스트리 구성이 포함되어 있습니다.
1.7.12.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

    다음과 같습니다.

    • -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  |
+---------+--------+---------------------+-------+------------------+------+
    [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

  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.x.y-x86_64" 1
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
    1
    4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

  4. 관리 클러스터를 프로비저닝하려면 다음 명령을 입력합니다. 

    kcli create cluster openshift --pf mgmt-compact-hub-ipv4.yaml
1.7.12.5.4.1. 추가 리소스
  • kcli 계획 파일의 매개변수에 대한 자세한 내용은 공식 kcli 문서의 parameters.yml 만들기 를 참조하십시오.
1.7.12.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}"

  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
    1
    ROOTFS_IMG_URL 값은 OpenShift CI 릴리스 페이지에서 찾을 수 있습니다.
    2
    LIVE_ISO_URL 값은 OpenShift CI 릴리스 페이지에서 확인할 수 있습니다.

다운로드가 완료되면 컨테이너가 실행되어 웹 서버에서 이미지를 호스팅합니다. 컨테이너는 공식 HTTPd 이미지의 변형을 사용하여 IPv6 네트워크에서도 작업할 수 있습니다.

1.7.12.5.6. IPv4 네트워크의 이미지 미러링 구성

이미지 미러링은 registry.redhat.com 또는 quay.io 와 같은 외부 레지스트리에서 이미지를 가져와서 프라이빗 레지스트리에 저장하는 프로세스입니다.

1.7.12.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.x.y-x86_64 2
      maxVersion: 4.x.y-x86_64
      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
    1
    dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.
    2
    4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

  3. 다음 명령을 입력하여 미러링 프로세스를 시작합니다. 

    oc-mirror --source-skip-tls --config imagesetconfig.yaml docker://${REGISTRY}

    미러링 프로세스가 완료되면 호스트 클러스터에 적용할 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.x.y-x86_64 \
  --to=${REGISTRY}/openshift/release \
  --to-release-image=${REGISTRY}/openshift/release-images:4.x.y-x86_64

    4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

  5. 연결이 끊긴 네트워크에 설치 단계에 따라 최신 다중 클러스터 엔진 Operator 이미지를 미러링합니다.
1.7.12.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

  2. 아티팩트를 적용하려면 다음 단계를 완료합니다.

    1. 다음 명령을 입력하여 ICSP(ICSP) 또는 IDMS 아티팩트를 생성합니다. 

      oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
    2. 노드가 준비될 때까지 기다린 다음 다음 명령을 입력합니다. 
    oc apply -f catalogSource-XXXXXXXX-index.yaml

  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.12.5.6.3. 추가 리소스
1.7.12.5.7. IPv4 네트워크용 다중 클러스터 엔진 Operator 배포

다중 클러스터 엔진 Operator는 공급업체에 클러스터를 배포하는 데 중요한 역할을 합니다. Red Hat Advanced Cluster Management를 이미 설치한 경우 자동으로 설치되므로 다중 클러스터 엔진 Operator를 설치할 필요가 없습니다.

다중 클러스터 엔진 Operator가 설치되어 있지 않은 경우 다음 문서를 검토하여 사전 요구 사항 및 설치 단계를 이해하십시오.

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

    이 명령은 이 예제 출력에 표시된 대로 두 개의 Pod를 트리거합니다. 

    assisted-image-service-0                               1/1     Running   2             11d 1
assisted-service-668b49548-9m7xw                       2/2     Running   5             11d 2
    1
    assisted-image-service Pod는 배포하는 각 클러스터에 대해 사용자 지정되는 RHCOS(Red Hat Enterprise Linux CoreOS) 부팅 이미지 템플릿을 생성합니다.
    2
    assisted-service 는 Operator를 나타냅니다.
1.7.12.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}

    • 네임스페이스에 해당 구성 맵이 포함되지 않은 경우 다음 명령을 입력합니다. 

      ## 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 -
1.7.12.5.9. IPv4 네트워크용 호스트 클러스터 배포

호스팅 클러스터는 관리 클러스터에서 호스팅되는 컨트롤 플레인 및 API 끝점이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 클러스터에는 컨트롤 플레인과 해당 데이터 플레인이 포함됩니다.

Red Hat Advanced Cluster Management에서 콘솔을 사용하여 호스트 클러스터를 생성할 수 있지만 다음 절차에서는 관련 아티팩트를 수정하는 데 더 유연하게 사용할 수 있는 매니페스트를 사용합니다.

1.7.12.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: {}

  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

  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:
  - '*'

  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.x.y-x86_64
  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

    여기서 dns.base.domain.name 은 DNS 기본 도메인 이름이며 4.x.y 는 사용하려는 지원되는 OpenShift Container Platform 버전입니다.

    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.x.y-x86_64 | grep hypershift

      여기서 dns.base.domain.name 은 DNS 기본 도메인 이름이며 4.x.y 는 사용하려는 지원되는 OpenShift Container Platform 버전입니다.

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

      hypershift                                     sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8

    3. OpenShift Container Platform 이미지 네임스페이스를 사용하여 다음 명령을 입력하여 다이제스트를 확인합니다. 

      podman pull registry.dns.base.domain.name:5000/openshift-release-dev/ocp-v4.0-art-dev@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8

      여기서 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

    참고: HostedCluster 오브젝트에 설정된 릴리스 이미지는 태그가 아닌 다이제스트를 사용해야 합니다. 예를 들어 quay.io/openshift-release-dev/ocp-release@sha256:e3ba11bd1e5e8ea5a0b36a75791c90f29afb0fdbe4125be4e48f69c76a5c.

  6. YAML 파일에 정의된 모든 오브젝트를 파일에 연결하고 관리 클러스터에 적용하여 해당 오브젝트를 생성합니다. 이렇게 하려면 다음 명령을 입력합니다. 

    oc apply -f 01-4.14-hosted_cluster-nodeport.yaml

  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

  8. 호스트 클러스터의 출력을 참조하십시오. 

    NAMESPACE   NAME         VERSION   KUBECONFIG                PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
clusters    hosted-ipv4            hosted-admin-kubeconfig   Partial    True          False         The hosted control plane is available

다음으로 NodePool 오브젝트를 생성합니다.

1.7.12.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.x.y-x86_64 3
  replicas: 0
status:
  replicas: 0 4
    1
    노드가 제거되면 노드가 다시 생성되지 않기 때문에 autoRepair 필드가 false 로 설정됩니다.
    2
    upgradeType 은 업그레이드 중에 동일한 베어 메탈 노드가 재사용됨을 나타내는 InPlace 로 설정됩니다.
    3
    이 NodePool 에 포함된 모든 노드는 다음 OpenShift Container Platform 버전 4.x.y-x86_64 를 기반으로 합니다. dns.base.domain.name 을 DNS 기본 도메인 이름으로 바꾸고 4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
    4
    필요한 경우 스케일링할 수 있도록 replicas 값은 0 으로 설정됩니다. 모든 단계가 완료될 때까지 NodePool 복제본을 0으로 유지하는 것이 중요합니다.

  2. 다음 명령을 입력하여 NodePool 오브젝트를 생성합니다. 

    oc apply -f 02-nodepool.yaml

  3. 출력을 참조하십시오. 

    NAMESPACE   NAME          CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted-ipv4   hosted    0                               False         False        4.x.y-x86_64

    4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

다음으로 InfraEnv 리소스를 생성합니다.

1.7.12.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
    1
    pullSecretRef 는 가져오기 보안이 사용되는 InfraEnv 와 동일한 네임스페이스에서 구성 맵 참조를 나타냅니다.
    2
    sshAuthorizedKey 는 부팅 이미지에 배치된 SSH 공개 키를 나타냅니다. SSH 키를 사용하면 core 사용자로 작업자 노드에 액세스할 수 있습니다.

  2. 다음 명령을 입력하여 InfraEnv 리소스를 생성합니다. 

    oc apply -f 03-infraenv.yaml

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

    NAMESPACE              NAME     ISO CREATED AT
clusters-hosted-ipv4   hosted   2023-09-11T15:14:10Z

다음으로 작업자 노드를 생성합니다.

1.7.12.5.9.4. 호스트된 클러스터의 작업자 노드 생성

베어 메탈 플랫폼에서 작업하는 경우 작업자 노드를 생성하는 것은 BareMetalHost 의 세부 정보가 올바르게 구성되었는지 확인하는 데 중요합니다.

가상 머신으로 작업하는 경우 다음 단계를 완료하여 Metal3 Operator에서 사용하는 빈 작업자 노드를 생성할 수 있습니다. 이렇게 하려면 kcli 를 사용합니다.

  1. 이것이 작업자 노드 생성을 처음 시도하지 않은 경우 먼저 이전 설정을 삭제해야 합니다. 이렇게 하려면 다음 명령을 입력하여 계획을 삭제합니다. 

    kcli delete plan hosted-ipv4
    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
    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
    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
    systemctl restart ksushy

    다음과 같습니다.

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

다음으로 호스팅된 클러스터에 대한 베어 메탈 호스트를 생성합니다.

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

    프로세스 중에 다음 출력을 볼 수 있습니다.

    • 이 출력은 프로세스가 노드에 연결을 시도 중임을 나타냅니다. 

      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

    • 이 출력은 노드가 시작됨을 나타냅니다. 

      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
    • 이 출력은 노드가 성공적으로 시작되었음을 나타냅니다. 
    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

  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

    에이전트는 설치에 사용할 수 있는 노드를 나타냅니다. 호스트 클러스터에 노드를 할당하려면 노드 풀을 확장합니다.

1.7.12.5.9.6. 노드 풀 확장

베어 메탈 호스트를 생성한 후 해당 상태가 Registering 에서 Provisioning (프로비저닝)으로 변경됨. 노드는 에이전트의 LiveISO 및 에이전트 라는 기본 Pod로 시작합니다. 해당 에이전트는 OpenShift Container Platform 페이로드를 설치하기 위해 Assisted Service Operator에서 지침을 받습니다.

  1. 노드 풀을 확장하려면 다음 명령을 입력합니다. 

    oc -n clusters scale nodepool hosted-ipv4 --replicas 3

  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

  3. 또한 노드 풀 복제본이 설정되어 있습니다. 

    NAMESPACE   NAME     CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted   hosted    3                               False         False        4.x.y-x86_64                                      Minimum availability requires 3 replicas, current 0 available

    4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

  4. 노드가 클러스터에 참여할 때까지 기다립니다. 프로세스 중에 에이전트는 단계 및 상태에 대한 업데이트를 제공합니다.

다음으로 호스트 클러스터의 배포를 모니터링합니다.

1.7.12.5.10. IPv4 네트워크의 호스트 클러스터 배포 완료

컨트롤 플레인과 데이터 플레인의 두 가지 관점에서 호스팅 클러스터 배포를 모니터링할 수 있습니다.

1.7.12.5.10.1. 컨트롤 플레인 모니터링

호스팅 클러스터를 배포하는 동안 다음 명령을 입력하여 컨트롤 플레인을 모니터링할 수 있습니다. 

export KUBECONFIG=/root/.kcli/clusters/hub-ipv4/auth/kubeconfig
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;"

이러한 명령은 다음 아티팩트에 대한 정보를 제공합니다.

  • The HyperShift Operator
  • HostedControlPlane Pod
  • 베어 메탈 호스트
  • 에이전트
  • InfraEnv 리소스
  • HostedCluster 및 NodePool 리소스
1.7.12.5.10.2. 데이터 플레인 모니터링

배포 프로세스 중에 Operator가 진행 중인 방식을 모니터링하려면 다음 명령을 입력합니다. 

oc get secret -n clusters-hosted-ipv4 admin-kubeconfig -o jsonpath='{.data.kubeconfig}' |base64 -d > /root/hc_admin_kubeconfig.yaml
export KUBECONFIG=/root/hc_admin_kubeconfig.yaml
watch "oc get clusterversion,nodes,co"

이러한 명령은 다음 아티팩트에 대한 정보를 제공합니다.

  • 클러스터 버전
  • 특히 노드가 클러스터에 참여하는지 여부에 대한 노드
  • 클러스터 Operator

1.7.12.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.12.6.1. IPv6 네트워크에 대한 하이퍼바이저 구성

다음 정보는 가상 머신 환경에만 적용됩니다.

1.7.12.6.1.1. 가상 OpenShift Container Platform 클러스터용 패키지 액세스 및 배포

  1. 가상 OpenShift Container Platform 관리 클러스터를 배포하려면 다음 명령을 입력하여 필요한 패키지에 액세스합니다. 

    sudo dnf install dnsmasq radvd vim golang podman bind-utils net-tools httpd-tools tree htop strace tmux -y

  2. 다음 명령을 입력하여 Podman 서비스를 활성화하고 시작합니다. 

    systemctl enable --now podman

  3. kcli 를 사용하여 OpenShift Container Platform 관리 클러스터 및 기타 가상 구성 요소를 배포하려면 다음 명령을 입력하여 하이퍼바이저를 설치 및 구성합니다. 

    sudo yum -y install libvirt libvirt-daemon-driver-qemu qemu-kvm
    sudo usermod -aG qemu,libvirt $(id -un)
    sudo newgrp libvirt
    sudo systemctl enable --now libvirtd
    sudo dnf -y copr enable karmab/kcli
    sudo dnf -y install kcli
    sudo kcli create pool -p /var/lib/libvirt/images default
    kcli create host kvm -H 127.0.0.1 local
    sudo setfacl -m u:$(id -un):rwx /var/lib/libvirt/images
    kcli create network  -c 192.168.122.0/24 default
1.7.12.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"
    1
    OpenShift Container Platform 관리 클러스터를 호스팅하는 하이퍼바이저 인터페이스의 IP 주소를 가리키도록 IP 변수를 수정합니다.
    2
    dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

  2. 파일을 생성한 후 다음 명령을 입력하여 권한을 추가합니다. 

    chmod 755 /etc/NetworkManager/dispatcher.d/forcedns
  3. 스크립트를 실행하고 출력이 ok 를 반환하는지 확인합니다.
1.7.12.6.1.3. BMC 액세스 구성

  1. 가상 머신의 BMC(Baseboard Management Controller)를 시뮬레이션하도록 ksushy 를 구성합니다. 다음 명령을 입력합니다. 

    sudo dnf install python3-pyOpenSSL.noarch python3-cherrypy -y
    kcli create sushy-service --ssl --ipv6 --port 9000
    sudo systemctl daemon-reload
    systemctl enable --now ksushy

  2. 다음 명령을 입력하여 서비스가 올바르게 작동하는지 테스트합니다. 

    systemctl status ksushy
1.7.12.6.1.4. 연결을 허용하도록 하이퍼바이저 시스템 구성

개발 환경에서 작업하는 경우 환경 내에서 다양한 가상 네트워크를 통한 다양한 유형의 연결을 허용하도록 하이퍼바이저 시스템을 구성합니다.

참고: 프로덕션 환경에서 작업하는 경우 firewalld 서비스에 대한 적절한 규칙을 설정하고 안전한 환경을 유지 관리하도록 SELinux 정책을 구성해야 합니다.

  • SELinux의 경우 다음 명령을 입력합니다. 

    sed -i s/^SELINUX=.*$/SELINUX=permissive/ /etc/selinux/config; setenforce 0

  • firewalld 의 경우 다음 명령을 입력합니다. 

    systemctl disable --now firewalld

  • libvirtd 의 경우 다음 명령을 입력합니다. 

    systemctl restart libvirtd
    systemctl enable --now libvirtd

다음으로 환경에 맞게 DNS를 구성합니다.

1.7.12.6.1.5. 추가 리소스
1.7.12.6.2. IPv6 네트워크에 대한 DNS 구성

이 단계는 가상 및 베어 메탈 환경 모두에서 연결이 끊긴 환경과 연결된 환경 모두에 필요합니다. 가상 환경과 베어 메탈 환경 간의 주요 차이점은 리소스를 구성하는 위치에 있습니다. 베어 메탈 환경에서는 dnsmasq 와 같은 경량 솔루션이 아닌 바인딩과 같은 솔루션을 사용합니다.

다음으로 레지스트리를 배포합니다.

1.7.12.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
    1
    PULL_SECRET 위치를 설정에 적합한 위치로 교체합니다.

  2. 스크립트 파일 이름을 registry.sh 로 지정하고 저장합니다. 스크립트를 실행하면 다음 정보를 가져옵니다.

    • 하이퍼바이저 호스트 이름을 기반으로 하는 레지스트리 이름
    • 필요한 인증 정보 및 사용자 액세스 세부 정보

  3. 다음과 같이 실행 플래그를 추가하여 권한을 조정합니다. 

    chmod u+x ${HOME}/registry.sh

  4. 매개변수 없이 스크립트를 실행하려면 다음 명령을 입력합니다. 

    ${HOME}/registry.sh

    스크립트가 서버를 시작합니다.

  5. 스크립트는 관리 목적으로 systemd 서비스를 사용합니다. 스크립트를 관리해야 하는 경우 다음 명령을 사용할 수 있습니다. 

    systemctl status
    systemctl start
    systemctl stop

레지스트리의 루트 폴더는 /opt/registry 디렉터리에 있으며 다음 하위 디렉터리가 포함되어 있습니다.

  • 인증서에는 TLS 인증서가 포함되어 있습니다.
  • auth 에는 인증 정보가 포함됩니다.
  • 데이터에 는 레지스트리 이미지가 포함되어 있습니다.
  • conf 에는 레지스트리 구성이 포함되어 있습니다.
1.7.12.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

    다음과 같습니다.

    • -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  |
+---------+--------+---------------------+-------+------------------+------+
    [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

  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.x.y-x86_64"
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

  4. 관리 클러스터를 프로비저닝하려면 다음 명령을 입력합니다. 

    kcli create cluster openshift --pf mgmt-compact-hub-ipv6.yaml
1.7.12.6.4.1. 추가 리소스
  • kcli 계획 파일의 매개변수에 대한 자세한 내용은 공식 kcli 문서의 parameters.yml 만들기 를 참조하십시오.
1.7.12.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}"

  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
    1
    ROOTFS_IMG_URL 값은 OpenShift CI 릴리스 페이지에서 찾을 수 있습니다.
    2
    LIVE_ISO_URL 값은 OpenShift CI 릴리스 페이지에서 확인할 수 있습니다.

다운로드가 완료되면 컨테이너가 실행되어 웹 서버에서 이미지를 호스팅합니다. 컨테이너는 공식 HTTPd 이미지의 변형을 사용하여 IPv6 네트워크에서도 작업할 수 있습니다.

1.7.12.6.6. IPv6 네트워크에 대한 이미지 미러링 구성

이미지 미러링은 registry.redhat.com 또는 quay.io 와 같은 외부 레지스트리에서 이미지를 가져와서 프라이빗 레지스트리에 저장하는 프로세스입니다.

1.7.12.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.x.y-x86_64
      maxVersion: 4.x.y-x86_64
      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
    1
    dns.base.domain.name 을 DNS 기본 도메인 이름으로 바꾸고 4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.

  3. 다음 명령을 입력하여 미러링 프로세스를 시작합니다. 

    oc-mirror --source-skip-tls --config imagesetconfig.yaml docker://${REGISTRY}

    미러링 프로세스가 완료되면 호스트 클러스터에 적용할 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.x.y-x86_64 \
  --to=${REGISTRY}/openshift/release \
  --to-release-image=${REGISTRY}/openshift/release-images:4.x.y-x86_64

    4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

  5. 연결이 끊긴 네트워크에 설치 단계에 따라 최신 다중 클러스터 엔진 Operator 이미지를 미러링합니다.
1.7.12.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

  2. 아티팩트를 적용하려면 다음 단계를 완료합니다.

    1. 다음 명령을 입력하여 ICSP 또는 IDMS 아티팩트를 생성합니다. 

      oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
    2. 노드가 준비될 때까지 기다린 다음 다음 명령을 입력합니다. 
    oc apply -f catalogSource-XXXXXXXX-index.yaml
1.7.12.6.6.3. 추가 리소스
1.7.12.6.7. IPv6 네트워크용 다중 클러스터 엔진 Operator 배포

다중 클러스터 엔진 Operator는 공급업체에 클러스터를 배포하는 데 중요한 역할을 합니다. Red Hat Advanced Cluster Management를 이미 설치한 경우 자동으로 설치되므로 다중 클러스터 엔진 Operator를 설치할 필요가 없습니다.

다중 클러스터 엔진 Operator가 설치되어 있지 않은 경우 다음 문서를 검토하여 사전 요구 사항 및 설치 단계를 이해하십시오.

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

    이 명령은 이 예제 출력에 표시된 대로 두 개의 Pod를 트리거합니다. 

    assisted-image-service-0                               1/1     Running   2             11d 1
assisted-service-668b49548-9m7xw                       2/2     Running   5             11d 2
    1
    assisted-image-service Pod는 배포하는 각 클러스터에 대해 사용자 지정되는 RHCOS(Red Hat Enterprise Linux CoreOS) 부팅 이미지 템플릿을 생성합니다.
    2
    assisted-service 는 Operator를 나타냅니다.
1.7.12.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}

    • 네임스페이스에 해당 구성 맵이 포함되지 않은 경우 다음 명령을 입력합니다. 

      ## 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 -
1.7.12.6.9. IPv6 네트워크에 대해 호스트된 클러스터 배포

호스팅 클러스터는 관리 클러스터에서 호스팅되는 컨트롤 플레인 및 API 끝점이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 클러스터에는 컨트롤 플레인과 해당 데이터 플레인이 포함됩니다.

Red Hat Advanced Cluster Management에서 콘솔을 사용하여 호스트 클러스터를 생성할 수 있지만 다음 절차에서는 관련 아티팩트를 수정하는 데 더 유연하게 사용할 수 있는 매니페스트를 사용합니다.

1.7.12.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: {}

  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

  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:
  - '*'

  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.x.y-x86_64
  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

    여기서 dns.base.domain.name 은 DNS 기본 도메인 이름이며 4.x.y 는 사용하려는 지원되는 OpenShift Container Platform 버전입니다.

    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.x.y-x86_64 | grep hypershift

      여기서 dns.base.domain.name 은 DNS 기본 도메인 이름이며 4.x.y 는 사용하려는 지원되는 OpenShift Container Platform 버전입니다.

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

      hypershift                                     sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8

    3. OpenShift Container Platform 이미지 네임스페이스를 사용하여 다음 명령을 입력하여 다이제스트를 확인합니다. 

      podman pull registry.dns.base.domain.name:5000/openshift-release-dev/ocp-v4.0-art-dev@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8

      여기서 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

    참고: HostedCluster 오브젝트에 설정된 릴리스 이미지는 태그가 아닌 다이제스트를 사용해야 합니다. 예를 들어 quay.io/openshift-release-dev/ocp-release@sha256:e3ba11bd1e5e8ea5a0b36a75791c90f29afb0fdbe4125be4e48f69c76a5c.

  6. YAML 파일에 정의된 모든 오브젝트를 파일에 연결하고 관리 클러스터에 적용하여 해당 오브젝트를 생성합니다. 이렇게 하려면 다음 명령을 입력합니다. 

    oc apply -f 01-4.14-hosted_cluster-nodeport.yaml

  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

  8. 호스트 클러스터의 출력을 참조하십시오. 

    NAMESPACE   NAME         VERSION   KUBECONFIG                PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
clusters    hosted-ipv6            hosted-admin-kubeconfig   Partial    True          False         The hosted control plane is available

다음으로 NodePool 오브젝트를 생성합니다.

1.7.12.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.x.y-x86_64 3
  replicas: 0
status:
  replicas: 0 4
    1
    노드가 제거되면 노드가 다시 생성되지 않기 때문에 autoRepair 필드가 false 로 설정됩니다.
    2
    upgradeType 은 업그레이드 중에 동일한 베어 메탈 노드가 재사용됨을 나타내는 InPlace 로 설정됩니다.
    3
    이 NodePool 에 포함된 모든 노드는 다음 OpenShift Container Platform 버전 4.x.y-x86_64 를 기반으로 합니다. dns.base.domain.name 을 DNS 기본 도메인 이름으로 바꾸고 4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
    4
    필요한 경우 스케일링할 수 있도록 replicas 값은 0 으로 설정됩니다. 모든 단계가 완료될 때까지 NodePool 복제본을 0으로 유지하는 것이 중요합니다.

  2. 다음 명령을 입력하여 NodePool 오브젝트를 생성합니다. 

    oc apply -f 02-nodepool.yaml

  3. 출력을 참조하십시오. 

    NAMESPACE   NAME          CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted-ipv6   hosted    0                               False         False        4.x.y-x86_64

다음으로 InfraEnv 리소스를 생성합니다.

1.7.12.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
    1
    pullSecretRef 는 가져오기 보안이 사용되는 InfraEnv 와 동일한 네임스페이스에서 구성 맵 참조를 나타냅니다.
    2
    sshAuthorizedKey 는 부팅 이미지에 배치된 SSH 공개 키를 나타냅니다. SSH 키를 사용하면 core 사용자로 작업자 노드에 액세스할 수 있습니다.

  2. 다음 명령을 입력하여 InfraEnv 리소스를 생성합니다. 

    oc apply -f 03-infraenv.yaml

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

    NAMESPACE              NAME     ISO CREATED AT
clusters-hosted-ipv6   hosted   2023-09-11T15:14:10Z

다음으로 작업자 노드를 생성합니다.

1.7.12.6.9.4. 호스트된 클러스터의 작업자 노드 생성

베어 메탈 플랫폼에서 작업하는 경우 작업자 노드를 생성하는 것은 BareMetalHost 의 세부 정보가 올바르게 구성되었는지 확인하는 데 중요합니다.

가상 머신으로 작업하는 경우 다음 단계를 완료하여 Metal3 Operator에서 사용하는 빈 작업자 노드를 생성할 수 있습니다. 이렇게 하려면 kcli 툴을 사용합니다.

  1. 이것이 작업자 노드 생성을 처음 시도하지 않은 경우 먼저 이전 설정을 삭제해야 합니다. 이렇게 하려면 다음 명령을 입력하여 계획을 삭제합니다. 

    kcli delete plan hosted-ipv6
    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
    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
    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
    systemctl restart ksushy

    다음과 같습니다.

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

다음으로 호스팅된 클러스터에 대한 베어 메탈 호스트를 생성합니다.

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

    프로세스 중에 다음 출력을 볼 수 있습니다.

    • 이 출력은 프로세스가 노드에 연결을 시도 중임을 나타냅니다. 

      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

    • 이 출력은 노드가 시작됨을 나타냅니다. 

      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
    • 이 출력은 노드가 성공적으로 시작되었음을 나타냅니다. 
    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

  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

    에이전트는 설치에 사용할 수 있는 노드를 나타냅니다. 호스트 클러스터에 노드를 할당하려면 노드 풀을 확장합니다.

1.7.12.6.9.6. 노드 풀 확장

베어 메탈 호스트를 생성한 후 해당 상태가 Registering 에서 Provisioning (프로비저닝)으로 변경됨. 노드는 에이전트의 LiveISO 및 에이전트 라는 기본 Pod로 시작합니다. 해당 에이전트는 OpenShift Container Platform 페이로드를 설치하기 위해 Assisted Service Operator에서 지침을 받습니다.

  1. 노드 풀을 확장하려면 다음 명령을 입력합니다. 

    oc -n clusters scale nodepool hosted-ipv6 --replicas 3

  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

  3. 또한 노드 풀 복제본이 설정되어 있습니다. 

    NAMESPACE   NAME     CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION             UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted   hosted    3                               False         False        4.x.y-x86_64                                           Minimum availability requires 3 replicas, current 0 available
  4. 노드가 클러스터에 참여할 때까지 기다립니다. 프로세스 중에 에이전트는 단계 및 상태에 대한 업데이트를 제공합니다.

다음으로 호스트 클러스터의 배포를 모니터링합니다.

1.7.12.6.10. IPv6 네트워크의 호스트 클러스터 배포 완료

컨트롤 플레인과 데이터 플레인의 두 가지 관점에서 호스팅 클러스터 배포를 모니터링할 수 있습니다.

1.7.12.6.10.1. 컨트롤 플레인 모니터링

호스팅 클러스터를 배포하는 동안 다음 명령을 입력하여 컨트롤 플레인을 모니터링할 수 있습니다. 

export KUBECONFIG=/root/.kcli/clusters/hub-ipv4/auth/kubeconfig
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;"

이러한 명령은 다음 아티팩트에 대한 정보를 제공합니다.

  • The HyperShift Operator
  • HostedControlPlane Pod
  • 베어 메탈 호스트
  • 에이전트
  • InfraEnv 리소스
  • HostedCluster 및 NodePool 리소스
1.7.12.6.10.2. 데이터 플레인 모니터링

배포 프로세스 중에 Operator가 진행 중인 방식을 모니터링하려면 다음 명령을 입력합니다. 

oc get secret -n clusters-hosted-ipv4 admin-kubeconfig -o jsonpath='{.data.kubeconfig}' |base64 -d > /root/hc_admin_kubeconfig.yaml
export KUBECONFIG=/root/hc_admin_kubeconfig.yaml
watch "oc get clusterversion,nodes,co"

이러한 명령은 다음 아티팩트에 대한 정보를 제공합니다.

  • 클러스터 버전
  • 특히 노드가 클러스터에 참여하는지 여부에 대한 노드
  • 클러스터 Operator

1.7.12.7. 듀얼 스택 네트워크에서 호스팅된 컨트롤 플레인 구성 (기술 프리뷰)

호스팅된 컨트롤 플레인의 컨텍스트에서 연결이 끊긴 환경은 인터넷에 연결되지 않고 호스팅된 컨트롤 플레인을 기반으로 사용하는 OpenShift Container Platform 클러스터입니다. 원격 레지스트리가 IPv6에서 작동하지 않기 때문에 연결이 끊긴 환경에서만 이중 스택 네트워크에서 호스팅되는 컨트롤 플레인을 구성할 수 있습니다.

듀얼 스택 네트워크에서 호스팅된 컨트롤 플레인을 구성하려면 다음 단계를 검토하십시오.

  1. 듀얼 스택 네트워크에 대한 하이퍼바이저 구성
  2. 듀얼 스택 네트워크에 대한 DNS 구성
  3. 듀얼 스택 네트워크의 레지스트리 배포
  4. 듀얼 스택 네트워크에 대한 관리 클러스터 설정
  5. 듀얼 스택 네트워크에 대한 웹 서버 구성
  6. 듀얼 스택 네트워크의 이미지 미러링 구성
  7. 듀얼 스택 네트워크용 다중 클러스터 엔진 Operator 배포
  8. 듀얼 스택 네트워크에 대한 TLS 인증서 구성
  9. 듀얼 스택 네트워크용 호스트 클러스터 배포
  10. 듀얼 스택 네트워크의 배포 완료
1.7.12.7.1. 듀얼 스택 네트워크에 대한 하이퍼바이저 구성

다음 정보는 가상 머신 환경에만 적용됩니다.

1.7.12.7.1.1. 가상 OpenShift Container Platform 클러스터용 패키지 액세스 및 배포

  1. 가상 OpenShift Container Platform 관리 클러스터를 배포하려면 다음 명령을 입력하여 필요한 패키지에 액세스합니다. 

    sudo dnf install dnsmasq radvd vim golang podman bind-utils net-tools httpd-tools tree htop strace tmux -y

  2. 다음 명령을 입력하여 Podman 서비스를 활성화하고 시작합니다. 

    systemctl enable --now podman

  3. kcli 를 사용하여 OpenShift Container Platform 관리 클러스터 및 기타 가상 구성 요소를 배포하려면 다음 명령을 입력하여 하이퍼바이저를 설치 및 구성합니다. 

    sudo yum -y install libvirt libvirt-daemon-driver-qemu qemu-kvm
    sudo usermod -aG qemu,libvirt $(id -un)
    sudo newgrp libvirt
    sudo systemctl enable --now libvirtd
    sudo dnf -y copr enable karmab/kcli
    sudo dnf -y install kcli
    sudo kcli create pool -p /var/lib/libvirt/images default
    kcli create host kvm -H 127.0.0.1 local
    sudo setfacl -m u:$(id -un):rwx /var/lib/libvirt/images
    kcli create network  -c 192.168.122.0/24 default
1.7.12.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"
    1
    OpenShift Container Platform 관리 클러스터를 호스팅하는 하이퍼바이저 인터페이스의 IP 주소를 가리키도록 IP 변수를 수정합니다.
    2
    dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

  2. 파일을 생성한 후 다음 명령을 입력하여 권한을 추가합니다. 

    chmod 755 /etc/NetworkManager/dispatcher.d/forcedns
  3. 스크립트를 실행하고 출력이 ok 를 반환하는지 확인합니다.
1.7.12.7.1.3. BMC 액세스 구성

  1. 가상 머신의 BMC(Baseboard Management Controller)를 시뮬레이션하도록 ksushy 를 구성합니다. 다음 명령을 입력합니다. 

    sudo dnf install python3-pyOpenSSL.noarch python3-cherrypy -y
    kcli create sushy-service --ssl --ipv6 --port 9000
    sudo systemctl daemon-reload
    systemctl enable --now ksushy

  2. 다음 명령을 입력하여 서비스가 올바르게 작동하는지 테스트합니다. 

    systemctl status ksushy
1.7.12.7.1.4. 연결을 허용하도록 하이퍼바이저 시스템 구성

개발 환경에서 작업하는 경우 환경 내에서 다양한 가상 네트워크를 통한 다양한 유형의 연결을 허용하도록 하이퍼바이저 시스템을 구성합니다.

참고: 프로덕션 환경에서 작업하는 경우 firewalld 서비스에 대한 적절한 규칙을 설정하고 안전한 환경을 유지 관리하도록 SELinux 정책을 구성해야 합니다.

  • SELinux의 경우 다음 명령을 입력합니다. 

    sed -i s/^SELINUX=.*$/SELINUX=permissive/ /etc/selinux/config; setenforce 0

  • firewalld 의 경우 다음 명령을 입력합니다. 

    systemctl disable --now firewalld

  • libvirtd 의 경우 다음 명령을 입력합니다. 

    systemctl restart libvirtd
    systemctl enable --now libvirtd

다음으로 환경에 맞게 DNS를 구성합니다.

1.7.12.7.1.5. 추가 리소스
1.7.12.7.2. 듀얼 스택 네트워크에 대한 DNS 구성

가상 및 베어 메탈 환경 모두에서 연결이 끊긴 환경과 연결된 환경 모두에 대해 DNS를 구성해야 합니다. 가상 환경과 베어 메탈 환경 간의 주요 차이점은 리소스를 구성하는 위치에 있습니다. 비가상 환경에서 dnsmasq 와 같은 경량 솔루션을 사용하는 대신 바인딩과 같은 솔루션을 사용하십시오.

다음으로 레지스트리를 배포합니다.

1.7.12.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
    1
    PULL_SECRET 위치를 설정에 적합한 위치로 교체합니다.

  2. 스크립트 파일 이름을 registry.sh 로 지정하고 저장합니다. 스크립트를 실행하면 다음 정보를 가져옵니다.

    • 하이퍼바이저 호스트 이름을 기반으로 하는 레지스트리 이름
    • 필요한 인증 정보 및 사용자 액세스 세부 정보

  3. 다음과 같이 실행 플래그를 추가하여 권한을 조정합니다. 

    chmod u+x ${HOME}/registry.sh

  4. 매개변수 없이 스크립트를 실행하려면 다음 명령을 입력합니다. 

    ${HOME}/registry.sh

    스크립트가 서버를 시작합니다.

  5. 스크립트는 관리 목적으로 systemd 서비스를 사용합니다. 스크립트를 관리해야 하는 경우 다음 명령을 사용할 수 있습니다. 

    systemctl status
    systemctl start
    systemctl stop

레지스트리의 루트 폴더는 /opt/registry 디렉터리에 있으며 다음 하위 디렉터리가 포함되어 있습니다.

  • 인증서에는 TLS 인증서가 포함되어 있습니다.
  • auth 에는 인증 정보가 포함됩니다.
  • 데이터에 는 레지스트리 이미지가 포함되어 있습니다.
  • conf 에는 레지스트리 구성이 포함되어 있습니다.
1.7.12.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

    다음과 같습니다.

    • -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  |
+---------+--------+---------------------+-------+------------------+------+
    [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

  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: stable
tag: "4.x.y-x86_64" 1
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
    1
    4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

  4. 관리 클러스터를 프로비저닝하려면 다음 명령을 입력합니다. 

    kcli create cluster openshift --pf mgmt-compact-hub-dual.yaml

다음으로 웹 서버를 구성합니다.

1.7.12.7.4.1. 추가 리소스
  • kcli 계획 파일의 매개변수에 대한 자세한 내용은 공식 kcli 문서의 parameters.yml 만들기 를 참조하십시오.
1.7.12.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}"

  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
    1
    ROOTFS_IMG_URL 값은 OpenShift CI 릴리스 페이지에서 찾을 수 있습니다.
    2
    LIVE_ISO_URL 값은 OpenShift CI 릴리스 페이지에서 확인할 수 있습니다.

다운로드가 완료되면 컨테이너가 실행되어 웹 서버에서 이미지를 호스팅합니다. 컨테이너는 공식 HTTPd 이미지의 변형을 사용하여 IPv6 네트워크에서도 작업할 수 있습니다.

1.7.12.7.6. 듀얼 스택 네트워크의 이미지 미러링 구성

이미지 미러링은 registry.redhat.com 또는 quay.io 와 같은 외부 레지스트리에서 이미지를 가져와서 프라이빗 레지스트리에 저장하는 프로세스입니다.

1.7.12.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.x.y-x86_64  1
      maxVersion: 4.x.y-x86_64
      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
    1
    4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

  3. 다음 명령을 입력하여 미러링 프로세스를 시작합니다. 

    oc-mirror --source-skip-tls --config imagesetconfig.yaml docker://${REGISTRY}

    미러링 프로세스가 완료되면 호스트 클러스터에 적용할 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.x.y-x86_64 \
  --to=${REGISTRY}/openshift/release \
  --to-release-image=${REGISTRY}/openshift/release-images:registry.dns.base.domain.name:5000/openshift/release-images:4.x.y-x86_64

    4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

  5. 연결이 끊긴 네트워크에 설치 단계에 따라 최신 다중 클러스터 엔진 Operator 이미지를 미러링합니다.
1.7.12.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

  2. 아티팩트를 적용하려면 다음 단계를 완료합니다.

    1. 다음 명령을 입력하여 ICSP 또는 IDMS 아티팩트를 생성합니다. 

      oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
    2. 노드가 준비될 때까지 기다린 다음 다음 명령을 입력합니다. 
    oc apply -f catalogSource-XXXXXXXX-index.yaml

다음으로 다중 클러스터 엔진 Operator를 배포합니다.

1.7.12.7.6.3. 추가 리소스
1.7.12.7.7. 듀얼 스택 네트워크용 다중 클러스터 엔진 Operator 배포

다중 클러스터 엔진 Operator는 공급업체에 클러스터를 배포하는 데 중요한 역할을 합니다. Red Hat Advanced Cluster Management를 이미 설치한 경우 자동으로 설치되므로 다중 클러스터 엔진 Operator를 설치할 필요가 없습니다.

다중 클러스터 엔진 Operator가 설치되어 있지 않은 경우 다음 문서를 검토하여 사전 요구 사항 및 설치 단계를 이해하십시오.

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

    이 명령은 이 예제 출력에 표시된 대로 두 개의 Pod를 트리거합니다. 

    assisted-image-service-0                               1/1     Running   2             11d 1
assisted-service-668b49548-9m7xw                       2/2     Running   5             11d 2
    1
    assisted-image-service Pod는 배포하는 각 클러스터에 대해 사용자 지정되는 RHCOS(Red Hat Enterprise Linux CoreOS) 부팅 이미지 템플릿을 생성합니다.
    2
    assisted-service 는 Operator를 나타냅니다.
1.7.12.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}

    • 네임스페이스에 해당 구성 맵이 포함되지 않은 경우 다음 명령을 입력합니다. 

      ## 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 -
1.7.12.7.9. 듀얼 스택 네트워크에 대해 호스트된 클러스터 배포

호스팅 클러스터는 관리 클러스터에서 호스팅되는 컨트롤 플레인 및 API 끝점이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 클러스터에는 컨트롤 플레인과 해당 데이터 플레인이 포함됩니다.

Red Hat Advanced Cluster Management에서 콘솔을 사용하여 호스트 클러스터를 생성할 수 있지만 다음 절차에서는 관련 아티팩트를 수정하는 데 더 유연하게 사용할 수 있는 매니페스트를 사용합니다.

1.7.12.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: {}

  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

  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:
  - '*'

  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.x.y-x86_64 3
  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
    1
    imageContentSources 섹션에는 호스팅된 클러스터 내의 사용자 워크로드에 대한 미러 참조가 포함되어 있습니다.
    2
    YAML 파일 전체에서 dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.
    3
    4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

  5. OpenShift Container Platform 릴리스의 HyperShift Operator 릴리스를 가리키는 HostedCluster 오브젝트에 주석을 추가합니다.

    1. 다음 명령을 입력하여 이미지 페이로드를 가져옵니다. 

      oc adm release info registry.dns.base.domain.name:5000/openshift-release-dev/ocp-release:4.x.y-x86_64 | grep hypershift

      여기서 dns.base.domain.name 은 DNS 기본 도메인 이름이며 4.x.y 는 사용하려는 지원되는 OpenShift Container Platform 버전입니다.

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

      hypershift                                     sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8

    3. OpenShift Container Platform 이미지 네임스페이스를 사용하여 다음 명령을 입력하여 다이제스트를 확인합니다. 

      podman pull registry.dns.base.domain.name:5000/openshift-release-dev/ocp-v4.0-art-dev@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8

      여기서 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

    참고: HostedCluster 오브젝트에 설정된 릴리스 이미지는 태그가 아닌 다이제스트를 사용해야 합니다. 예를 들어 quay.io/openshift-release-dev/ocp-release@sha256:e3ba11bd1e5e8ea5a0b36a75791c90f29afb0fdbe4125be4e48f69c76a5c.

  6. YAML 파일에 정의된 모든 오브젝트를 파일에 연결하고 관리 클러스터에 적용하여 해당 오브젝트를 생성합니다. 이렇게 하려면 다음 명령을 입력합니다. 

    oc apply -f 01-4.14-hosted_cluster-nodeport.yaml

  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

  8. 호스트 클러스터의 출력을 참조하십시오. 

    NAMESPACE   NAME         VERSION   KUBECONFIG                PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
clusters    hosted-dual            hosted-admin-kubeconfig   Partial    True          False         The hosted control plane is available

다음으로 NodePool 오브젝트를 생성합니다.

1.7.12.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.x.y-x86_64 3
  replicas: 0
status:
  replicas: 0 4
    1
    노드가 제거되면 노드가 다시 생성되지 않기 때문에 autoRepair 필드가 false 로 설정됩니다.
    2
    upgradeType 은 업그레이드 중에 동일한 베어 메탈 노드가 재사용됨을 나타내는 InPlace 로 설정됩니다.
    3
    이 NodePool 에 포함된 모든 노드는 다음 OpenShift Container Platform 버전 4.x.y-x86_64 를 기반으로 합니다. dns.base.domain.name 값을 DNS 기본 도메인 이름으로 바꾸고 4.x.y 값을 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
    4
    필요한 경우 스케일링할 수 있도록 replicas 값은 0 으로 설정됩니다. 모든 단계가 완료될 때까지 NodePool 복제본을 0으로 유지하는 것이 중요합니다.

  2. 다음 명령을 입력하여 NodePool 오브젝트를 생성합니다. 

    oc apply -f 02-nodepool.yaml

  3. 출력을 참조하십시오. 

    NAMESPACE   NAME          CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted-dual   hosted    0                               False         False        4.x.y-x86_64

다음으로 InfraEnv 리소스를 생성합니다.

1.7.12.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
    1
    pullSecretRef 는 가져오기 보안이 사용되는 InfraEnv 와 동일한 네임스페이스에서 구성 맵 참조를 나타냅니다.
    2
    sshAuthorizedKey 는 부팅 이미지에 배치된 SSH 공개 키를 나타냅니다. SSH 키를 사용하면 core 사용자로 작업자 노드에 액세스할 수 있습니다.

  2. 다음 명령을 입력하여 InfraEnv 리소스를 생성합니다. 

    oc apply -f 03-infraenv.yaml

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

    NAMESPACE              NAME     ISO CREATED AT
clusters-hosted-dual   hosted   2023-09-11T15:14:10Z

다음으로 작업자 노드를 생성합니다.

1.7.12.7.9.4. 호스트된 클러스터의 작업자 노드 생성

베어 메탈 플랫폼에서 작업하는 경우 작업자 노드를 생성하는 것은 BareMetalHost 의 세부 정보가 올바르게 구성되었는지 확인하는 데 중요합니다.

가상 머신으로 작업하는 경우 다음 단계를 완료하여 Metal3 Operator에서 사용할 빈 작업자 노드를 생성할 수 있습니다. 이렇게 하려면 kcli 툴을 사용합니다.

  1. 이것이 작업자 노드 생성을 처음 시도하지 않은 경우 먼저 이전 설정을 삭제해야 합니다. 이렇게 하려면 다음 명령을 입력하여 계획을 삭제합니다. 

    kcli delete plan hosted-dual
    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
    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
    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
    systemctl restart ksushy

    다음과 같습니다.

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

다음으로 호스팅된 클러스터에 대한 베어 메탈 호스트를 생성합니다.

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

    프로세스 중에 다음 출력을 볼 수 있습니다.

    • 이 출력은 프로세스가 노드에 연결을 시도 중임을 나타냅니다. 

      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

    • 이 출력은 노드가 시작됨을 나타냅니다. 

      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
    • 이 출력은 노드가 성공적으로 시작되었음을 나타냅니다. 
    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

  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

    에이전트는 설치에 사용할 수 있는 노드를 나타냅니다. 호스트 클러스터에 노드를 할당하려면 노드 풀을 확장합니다.

1.7.12.7.9.6. 노드 풀 확장

베어 메탈 호스트를 생성한 후 해당 상태가 Registering 에서 Provisioning (프로비저닝)으로 변경됨. 노드는 에이전트의 LiveISO 및 에이전트 라는 기본 Pod로 시작합니다. 해당 에이전트는 OpenShift Container Platform 페이로드를 설치하기 위해 Assisted Service Operator에서 지침을 받습니다.

  1. 노드 풀을 확장하려면 다음 명령을 입력합니다. 

    oc -n clusters scale nodepool hosted-dual --replicas 3

  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

  3. 또한 노드 풀 복제본이 설정되어 있습니다. 

    NAMESPACE   NAME     CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted   hosted    3                               False         False        4.x.y-x86_64                                      Minimum availability requires 3 replicas, current 0 available

    4.x.y 를 사용하려는 지원되는 OpenShift Container Platform 버전으로 교체합니다.

  4. 노드가 클러스터에 참여할 때까지 기다립니다. 프로세스 중에 에이전트는 단계 및 상태에 대한 업데이트를 제공합니다.

다음으로 호스트 클러스터의 배포를 모니터링합니다.

1.7.12.7.10. 듀얼 스택 네트워크에 대해 호스트된 클러스터 배포 완료

컨트롤 플레인과 데이터 플레인의 두 가지 관점에서 호스팅 클러스터 배포를 모니터링할 수 있습니다.

1.7.12.7.10.1. 컨트롤 플레인을 사용하여 호스트된 클러스터 배포 모니터링

컨트롤 플레인을 사용하여 호스팅된 클러스터 배포를 모니터링할 수 있습니다.

  1. 다음 명령을 입력하여 호스팅 클러스터 kubeconfig 파일을 내보냅니다. 

    export KUBECONFIG=<path_to_hosted_cluster_kubeconfig>

  2. 다음 명령을 입력하여 호스팅된 클러스터 배포 진행 상황을 관찰합니다. 

    watch "oc get pod -n hypershift;echo;echo;oc get pod -n <hosted_control_plane_namespace>;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;"

이 명령은 다음 아티팩트에 대한 정보를 제공합니다.

  • The HyperShift Operator
  • HostedControlPlane Pod
  • 베어 메탈 호스트
  • 에이전트
  • InfraEnv 리소스
  • HostedCluster 및 NodePool 리소스
1.7.12.7.10.2. 데이터 플레인을 사용하여 호스트된 클러스터 배포 모니터링

데이터 플레인을 사용하여 호스트 클러스터 배포 프로세스 중에 Operator가 진행 중인 방식을 모니터링할 수 있습니다.

  1. 다음 명령을 입력하여 호스팅된 클러스터에 대한 kubeconfig 파일을 생성합니다. 

    hcp create kubeconfig --name <hosted_cluster_name> --namespace <hosted_cluster_namespace>

  2. 다음 명령을 입력하여 호스팅 클러스터 kubeconfig 파일을 내보냅니다. 

    export KUBECONFIG=<path_to_hosted_cluster_kubeconfig>

  3. 다음 명령을 입력하여 클러스터 버전, 노드 및 클러스터 Operator의 상태를 확인합니다. 

    watch "oc get clusterversion,nodes,co"

1.7.13. 수동으로 호스팅된 컨트롤 플레인 클러스터 가져오기

호스팅된 컨트롤 플레인을 사용할 수 있게 되면 호스팅된 클러스터는 멀티 클러스터 엔진 Operator로 자동으로 가져옵니다. 호스트 클러스터를 수동으로 가져오려면 다음 단계를 완료합니다.

  1. 콘솔에서 Infrastructure > Clusters 를 클릭하고 가져올 호스팅 클러스터를 선택합니다.

  2. 호스팅 클러스터 가져오기 를 클릭합니다.

    참고: 검색된 호스트 클러스터의 경우 콘솔에서 가져올 수도 있지만 클러스터는 업그레이드 가능한 상태여야 합니다. 호스팅된 컨트롤 플레인을 사용할 수 없기 때문에 호스팅된 클러스터가 업그레이드 가능한 상태가 아닌 경우 클러스터의 가져오기가 비활성화됩니다. 가져오기 를 클릭하여 프로세스를 시작합니다. 클러스터가 업데이트를 수신하는 동안 상태가 Importing 된 다음 Ready 로 변경됩니다.

1.7.13.1. AWS에서 호스팅된 컨트롤 플레인 클러스터를 수동으로 가져오기

다음 단계를 완료하여 명령줄 인터페이스를 사용하여 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

    & lt;cluster_name& gt;을 호스트된 클러스터 이름으로 바꿉니다.

  2. 다음 명령을 실행하여 리소스를 적용합니다. 

    oc apply -f <file_name>

    <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

    & lt;cluster_name& gt;을 호스트된 클러스터 이름으로 바꿉니다.

  4. 다음 명령을 실행하여 리소스를 적용합니다. 

    oc apply -f <file_name>

    <file_name>을 이전 단계에서 생성한 YAML 파일 이름으로 바꿉니다.

  5. 가져오기 프로세스가 완료되면 콘솔에 호스팅된 클러스터가 표시됩니다. 다음 명령을 실행하여 호스팅 클러스터의 상태를 확인할 수도 있습니다. 

    oc get managedcluster <cluster_name>

1.7.13.2. 추가 리소스

1.7.13.3. 호스트 클러스터 자동 가져오기를 다중 클러스터 엔진 Operator로 비활성화

컨트롤 플레인을 사용할 수 있게 되면 호스팅된 클러스터를 자동으로 다중 클러스터 엔진 Operator로 가져와서 호스트된 클러스터의 자동 가져오기를 비활성화할 수 있습니다.

자동 가져오기를 비활성화하더라도 이전에 가져온 호스팅 클러스터는 영향을 받지 않습니다. 다중 클러스터 엔진 Operator 2.5로 업그레이드하고 자동 가져오기가 활성화되면 컨트롤 플레인을 사용할 수 있는 경우 가져오지 않은 모든 호스팅 클러스터를 자동으로 가져옵니다.

참고: Red Hat Advanced Cluster Management가 설치된 경우 모든 Red Hat Advanced Cluster Management 애드온도 활성화됩니다.

자동 가져오기가 비활성화되면 새로 생성된 호스팅 클러스터만 자동으로 가져오지 않습니다. 이미 가져온 호스트 클러스터는 영향을 받지 않습니다. 콘솔을 사용하거나 ManagedCluster 및 KlusterletAddonConfig 사용자 정의 리소스를 생성하여 클러스터를 수동으로 가져올 수 있습니다.

호스트 클러스터의 자동 가져오기를 비활성화하려면 다음 단계를 완료합니다.

  1. 다중 클러스터 엔진 Operator 허브 클러스터에서 AddonDeploymentConfig 리소스를 열어 multicluster-engine 네임스페이스에서 hypershift-addon-deploy-config 사양을 편집합니다. 다음 명령을 실행합니다. 

    oc edit addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine

  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: autoImportDisabled
    value: "true"
  3. 자동 가져오기를 다시 활성화하려면 autoImportDisabled 변수 값을 "false" 로 설정하거나 AddonDeploymentConfig 리소스에서 변수를 제거합니다.
1.7.13.3.1. 추가 리소스

호스트 클러스터를 수동으로 가져오는 방법은 호스팅된 컨트롤 플레인 클러스터 수동 가져오기를 참조하십시오.

1.7.14. 호스팅된 컨트롤 플레인 기능 활성화 또는 비활성화

호스팅된 컨트롤 플레인 기능 및 hypershift-addon 관리 클러스터 애드온은 기본적으로 활성화되어 있습니다. 기능을 비활성화하거나 비활성화한 후 수동으로 활성화하려면 다음 절차를 참조하십시오.

1.7.14.1. 수동으로 호스트된 컨트롤 플레인 기능 활성화

  1. 다음 명령을 실행하여 기능을 활성화할 수 있습니다. 

    oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}' 1
    1
    기본 MultiClusterEngine 리소스 인스턴스 이름은 multiclusterengine 이지만 다음 명령을 실행하여 클러스터에서 MultiClusterEngine 이름을 가져올 수 있습니다. $ oc get mce.

  2. 다음 명령을 실행하여 MultiClusterEngine 사용자 정의 리소스에서 hypershift 및 hypershift-local-hosting 기능이 활성화되어 있는지 확인합니다. 

    oc get mce multiclusterengine -o yaml 1
    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
1.7.14.1.1. local-cluster의 하이퍼shift-addon 관리 클러스터 애드온 수동 활성화

호스팅된 컨트롤 플레인 기능을 활성화하면 하이퍼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

  2. 다음 명령을 실행하여 파일을 적용합니다. 

    oc apply -f <filename>

    filename 을 생성한 파일의 이름으로 바꿉니다.

  3. 다음 명령을 실행하여 hypershift-addon 이 설치되었는지 확인합니다. 

    oc get managedclusteraddons -n local-cluster hypershift-addon

    애드온이 설치된 경우 출력은 다음 예와 유사합니다. 

    NAME               AVAILABLE   DEGRADED   PROGRESSING
hypershift-addon   True

HyperShift 애드온이 설치되고 호스팅 클러스터를 사용하여 호스팅 클러스터를 생성하고 관리할 수 있습니다.

1.7.14.2. 호스트된 컨트롤 플레인 기능 비활성화

HyperShift Operator를 설치 제거하고 호스팅된 컨트롤 플레인을 비활성화할 수 있습니다. 호스팅된 컨트롤 플레인 클러스터 기능을 비활성화할 때 호스트된 컨트롤 플레인 클러스터 관리 항목에 설명된 대로 멀티 클러스터 엔진 Operator에서 호스팅 클러스터 및 관리 클러스터 리소스를 제거해야 합니다.

1.7.14.2.1. HyperShift Operator 설치 제거

HyperShift Operator를 설치 제거하고 local-cluster 에서 hypershift-addon 을 비활성화하려면 다음 단계를 완료하십시오.

  1. 다음 명령을 실행하여 호스트 클러스터가 실행되고 있지 않은지 확인합니다. 

    oc get hostedcluster -A

    중요: 호스트 클러스터가 실행 중인 경우 hypershift-addon 이 비활성화된 경우에도 HyperShift Operator가 제거되지 않습니다.

  2. 다음 명령을 실행하여 hypershift-addon 을 비활성화합니다. 

    oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": false}]}}}' 1
    1
    기본 MultiClusterEngine 리소스 인스턴스 이름은 multiclusterengine 이지만 다음 명령을 실행하여 클러스터에서 MultiClusterEngine 이름을 가져올 수 있습니다. $ oc get mce.

    참고: hypershift-addon 을 비활성화한 후 다중 클러스터 엔진 Operator 콘솔에서 local-cluster 의 hypershift-addon 을 비활성화할 수도 있습니다.

1.7.14.2.2. 호스트된 컨트롤 플레인 기능 비활성화

먼저 호스팅된 컨트롤 플레인 기능을 비활성화하기 전에 HyperShift Operator를 설치 제거해야 합니다. 다음 명령을 실행하여 호스팅된 컨트롤 플레인 기능을 비활성화합니다. 

oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": false}]}}}' 1
1
기본 MultiClusterEngine 리소스 인스턴스 이름은 multiclusterengine 이지만 다음 명령을 실행하여 클러스터에서 MultiClusterEngine 이름을 가져올 수 있습니다. $ oc get mce.

다음 명령을 실행하여 hypershift 및 hypershift-local-hosting 기능이 MultiClusterEngine 사용자 정의 리소스에서 비활성화되어 있는지 확인할 수 있습니다. 

oc get mce multiclusterengine -o yaml 1
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

1.7.14.3. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.