설치

Red Hat Advanced Cluster Management for Kubernetes 2.5

연결 및 연결이 끊긴 네트워크에 설치하고, 설치 요구 사항 및 권장 사항, 다중 클러스터 고급 구성, 업그레이드 및 설치 제거에 대한 지침을 참조하십시오.

초록

연결 및 연결이 끊긴 네트워크에 설치하고, 설치 요구 사항 및 권장 사항, 다중 클러스터 고급 구성, 업그레이드 및 설치 제거에 대한 지침을 참조하십시오.

1장. 설치

Red Hat Advanced Cluster Management for Kubernetes 설치 및 설치 제거 방법을 알아보십시오. Red Hat Advanced Cluster Management for Kubernetes를 설치하기 전에 각 제품에 필요한 하드웨어 및 시스템 구성을 검토하십시오. 지원되는 Red Hat OpenShift Container Platform 버전을 사용하여 Linux에 Red Hat Advanced Cluster Management for Kubernetes를 온라인으로 설치할 수 있습니다.

  1. 지원되는 OpenShift Container Platform 버전이 있어야 합니다. 예를 들어 AWS에서 Red Hat OpenShift Service 또는 Red Hat OpenShift Dedicated를 사용할 수 있습니다.
  2. 카탈로그에서 Red Hat Advanced Cluster Management for Kubernetes operator를 설치해야 합니다.

FIPS 알림: spec.ingress.sslCiphers 에서 자체 암호를 지정하지 않으면 multiclusterhub-operator 에서 기본 암호 목록을 제공합니다. 2.3의 경우 이 목록에는 FIPS에서 승인하지 않은 두 개의 암호가 포함되어 있습니다. 버전 2.3.x 또는 이전 버전에서 업그레이드하고 FIPS 준수를 원하는 경우 다중 클러스터 허브 리소스에서 다음 두 암호를 제거하십시오. ECDHE-ECDSA-CHACHA20-POLY1305ECDHE-RSA-CHACHA20-POLY1305.

Kubernetes용 Red Hat Advanced Cluster Management를 설치하면 다중 노드 클러스터 프로덕션 환경이 설정됩니다. Kubernetes용 Red Hat Advanced Cluster Management는 표준 또는 고가용성 구성에서 설치할 수 있습니다. 설치 절차에 대한 자세한 내용은 다음 설명서를 참조하십시오.

1.1. 요구 사항 및 권장 사항

Red Hat Advanced Cluster Management for Kubernetes를 설치하기 전에 다음 시스템 구성 요구 사항 및 설정을 검토하십시오.

1.1.1. 지원되는 운영 체제 및 플랫폼

hub 클러스터 및 관리형 클러스터 플랫폼에 대한 최신 정보는 Red Hat Advanced Cluster Management 2.5 지원 매트릭스 를 참조하십시오.

1.1.2. 지원되는 브라우저

Mozilla Firefox, Google Chrome, Microsoft Edge 및 Safari에서 Red Hat Advanced Cluster Management 콘솔에 액세스할 수 있습니다. 테스트 및 지원되는 다음 버전을 참조하십시오.

플랫폼지원되는 브라우저

Microsoft Windows

Microsoft Edge - 44 이상, Mozilla Firefox 82.0 이상, Google Chrome - 버전 86.0 이상

Linux

Mozilla Firefox - 82.0 이상, Google Chrome - 버전 86.0 이상

macOS

Mozilla Firefox - 82.0 이상, Google Chrome - 버전 86.0 이상, Safari - 14.0 이상

1.1.3. 네트워크 구성

다음 섹션에서 연결을 허용하도록 네트워크 설정을 구성합니다.

1.1.3.1. Hub 클러스터 네트워킹 요구 사항

허브 클러스터 네트워킹 요구 사항은 다음 표를 참조하십시오.

direction프로토콜연결포트(지정된 경우)

아웃바운드로 관리되는 클러스터

HTTPS

관리 클러스터의 Pod를 위해 Search Console에서 로그를 동적으로 검색합니다. 이 연결은 관리 클러스터의 open-cluster-management-agent-addon 네임스페이스에 klusterlet-addon-workmgr 라는 경로를 생성합니다. 경로의 호스트는 < route name>-<namespace>.apps.<cluster domain >입니다.

443

아웃바운드로 관리되는 클러스터

HTTPS

Klusterlet을 설치하기 위해 설치 중에 프로비저닝된 관리형 클러스터의 Kubernetes API 서버

6443

채널 소스에 대한 아웃 바운드

HTTPS

GitHub, Object Store 및 Helm 리포지토리를 포함한 채널 소스입니다. 이는 애플리케이션 라이프사이클, OpenShift GitOps 또는 ArgoCD를 사용하여 이러한 소스에 연결하는 경우에만 필요합니다.

443

관리형 클러스터의 인바운드

HTTPS

메트릭 및 경고를 푸시하기 위한 관리형 클러스터(상단은 OpenShift Container Platform 버전 4.8 이상을 실행하는 관리 클러스터의 경우에만 수집됨)

443

관리형 클러스터의 인바운드

HTTPS

관리 클러스터에서 변경 사항을 감시하는 hub 클러스터의 kube API Server

6443

ObjectStore로 아웃 바운드

HTTPS

ObjectStore 및/또는 Cluster Backup Operator가 실행 중일 때 장기 스토리지에 대한 Observability의 지표 데이터를 보냅니다.

443

이미지 리포지터리의 아웃 바운드

HTTPS

OpenShift Container Platform 및 Red Hat Advanced Cluster Management의 이미지에 액세스

443

1.1.3.2. 관리형 클러스터 네트워킹 요구 사항

참고: 관리형 클러스터의 등록 에이전트 및 작업 에이전트는 프록시를 통과할 수 없는 mTLS 연결을 설정하여 허브 클러스터에서 apiserver 와 통신하기 때문에 프록시 설정을 지원하지 않습니다.

관리형 클러스터 네트워킹 요구 사항은 다음 표를 참조하십시오.

direction프로토콜연결포트(지정된 경우)

hub 클러스터에서 인바운드

HTTPS

관리형 클러스터의 Pod에 대해 동적으로 로그 전송 이 연결에서는 - klusterlet-addon-workmgr라는 관리 클러스터에서 실행 중인 서비스를 사용합니다.

443

hub 클러스터에서 인바운드

HTTPS

Klusterlet을 설치하기 위해 설치 중에 프로비저닝된 관리형 클러스터의 Kubernetes API 서버

6443

이미지 리포지터리의 아웃 바운드

HTTPS

OpenShift Container Platform 및 Red Hat Advanced Cluster Management의 이미지에 액세스

443

hub 클러스터의 아웃 바운드

HTTPS

메트릭 및 경고를 푸시하기 위한 관리형 클러스터(상단은 OpenShift Container Platform 버전 4.8 이상을 실행하는 관리 클러스터의 경우에만 수집됨)

443

hub 클러스터의 아웃 바운드

HTTPS

hub 클러스터의 Kubernetes API 서버에서 변경 사항을 감시합니다.

6443

채널 소스에 대한 아웃 바운드

HTTPS

GitHub, Object Store 및 Helm 리포지토리가 포함된 채널 소스에 대한 관리형 클러스터입니다. 애플리케이션 라이프사이클을 사용하여 이러한 소스에 연결하는 경우에만 필요합니다.

443

hub 클러스터의 아웃 바운드

HTTPS

관리형 클러스터의 cluster-proxy 애드온의 경우 등록할 수 있습니다.

443

1.2. 성능 및 확장

Red Hat Advanced Cluster Management for Kubernetes는 특정 확장성 및 성능 데이터를 확인하기 위해 테스트되었습니다. 테스트된 주요 영역은 클러스터 확장성 및 검색 성능입니다.

이 정보를 사용하여 환경을 계획하는 데 도움이 될 수 있습니다.

참고: 데이터는 테스트 시 랩 환경의 결과를 기반으로 합니다. 환경, 네트워크 속도 및 제품 변경 사항에 따라 결과가 다를 수 있습니다.

1.2.1. 최대 관리형 클러스터 수

Red Hat Advanced Cluster Management에서 관리할 수 있는 최대 클러스터 수는 다음과 같은 여러 요인에 따라 다릅니다.

  • 배포된 정책 및 애플리케이션 수와 같은 요인에 따라 클러스터의 리소스 수입니다.
  • 확장에 사용되는 Pod 수와 같은 hub 클러스터 구성

다음 표에서는 이 테스트 중에 사용된 Amazon Web Services 클라우드 플랫폼의 클러스터 구성 정보를 보여줍니다.

노드플레이버vCPURAM(GiB)디스크 유형디스크 크기(GiB)수량리전

Master

m5.2xlarge

8

32

gp2

100

3

us-east-1

작업자 또는 인프라

m5.2xlarge

8

32

gp2

100

노드 3개 또는 5개

us-east-1

인프라 노드에 대한 자세한 내용은 인프라 노드에 Red Hat Advanced Cluster Management hub 클러스터 설치를 참조하십시오. 또한 인프라 머신 세트 생성을 참조하십시오.

1.2.2. 검색 확장성

검색 구성 요소의 확장성은 데이터 저장소의 성능에 따라 다릅니다. 검색 성능을 분석할 때 다음 변수가 중요합니다.

  • 물리적 메모리
  • 쓰기 처리량 (Cache 복구 시간)
  • 쿼리 실행 시간

1.2.2.1. 물리적 메모리

검색은 데이터를 메모리 내로 유지하여 빠른 응답 시간을 달성합니다. 필요한 메모리는 Kubernetes 리소스 수 및 클러스터의 관계에 비례합니다.

클러스터Kubernetes 리소스관계관찰된 크기(감시 데이터 포함)

1 중간

5000

9500

50 Mi

5 중간

25,000

75,000

120 Mi

15 중간

75,000

20,0000

492 Mi

30 중간

150,000

450,000

1GI

50개 중간

250,000

750,000

2GI

검색 구성 요소에 사용되는 메모리 크기를 변경하는 방법에 대한 자세한 내용은 옵션을 참조하여 redisgraph 메모리를 늘립니다.

1.2.2.2. 쓰기 처리량(캐시 복구 시간)

대부분의 정상 상태의 클러스터는 적은 수의 리소스 업데이트를 생성합니다. RedisGraph의 데이터를 지우면 가장 높은 업데이트가 발생하여 원격 수집기가 동시에 전체 상태를 동기화합니다. 데이터 저장소를 지우면 다른 수의 관리형 클러스터에 대해 복구 시간이 측정됩니다.

클러스터Kubernetes 리소스관계시뮬레이션에서 평균 복구 시간

1 중간

5000

9500

2초 미만

5 중간

25,000

75,000

15초 미만

15 중간

75,000

200,000

2분 40초

30 중간

150,000

450,000

5-8분

참고: 허브에 대한 네트워크 연결이 느린 클러스터의 시간이 증가할 수 있습니다. 이전에 명시된 쓰기 처리량 정보는 지속성 이 비활성화된 경우에만 적용됩니다.

1.2.2.3. 쿼리 실행 고려 사항

쿼리의 결과를 실행하고 반환하는 데 걸리는 시간에 영향을 줄 수 있는 몇 가지 사항이 있습니다. 환경을 계획 및 구성할 때 다음 항목을 고려하십시오.

  • 키워드를 검색하는 것은 효율적이지 않습니다.

    RedHat 을 검색하고 많은 수의 클러스터를 관리하는 경우 검색 결과를 얻는 데 시간이 더 걸릴 수 있습니다.

  • 첫 번째 검색은 사용자 역할 기반 액세스 제어 규칙을 수집하는 데 추가 시간이 걸리기 때문에 이후 검색보다 오래 걸립니다.
  • 요청을 완료하는 데 걸리는 시간은 사용자가 액세스할 수 있는 네임스페이스 및 리소스 수에 비례합니다.

    참고: 다른 사용자와 검색 쿼리를 저장하고 공유하는 경우 반환된 결과는 해당 사용자의 액세스 수준에 따라 달라집니다. 역할 액세스에 대한 자세한 내용은 OpenShift Container Platform 설명서에서 RBAC를 사용하여 권한 정의 및 적용을 참조하십시오.

  • 관리자가 아닌 사용자가 모든 네임스페이스 또는 모든 관리 클러스터에 액세스할 수 있는 요청으로 최악의 성능이 확인됩니다.

1.2.3. 관찰성을 위한 스케일링

관찰 서비스를 활성화하고 사용하려면 환경을 계획해야 합니다. 나중에 리소스 사용은 관찰 가능 구성 요소가 설치된 OpenShift Container Platform 프로젝트용입니다. 사용할 값은 모든 관찰 가능 구성 요소에 대한 합계입니다.

참고: 데이터는 테스트 시 랩 환경의 결과를 기반으로 합니다. 환경, 네트워크 속도 및 제품 변경 사항에 따라 결과가 다를 수 있습니다.

1.2.3.1. 샘플 관찰 가능 환경

샘플 환경에서 허브 클러스터 및 관리 클러스터는 Amazon Web Services 클라우드 플랫폼에 있으며 다음과 같은 토폴로지 및 구성이 있습니다.

노드플레이버vCPURAM(GiB)디스크 유형디스크 크기(GiB)수량리전

마스터 노드

m5.4xlarge

16

64

gp2

100

3

sa-east-1

작업자 노드

m5.4xlarge

16

64

gp2

100

3

sa-east-1

관찰성 배포는 고가용성 환경을 위해 구성됩니다. 고가용성 환경에서 각 Kubernetes 배포에는 두 개의 인스턴스가 있으며 각 StatefulSet에는 세 개의 인스턴스가 있습니다.

샘플 테스트 중에 지표를 푸시하기 위해 다른 수의 관리형 클러스터가 시뮬레이션되며 각 테스트는 24시간 동안 지속됩니다. 다음 처리량을 확인합니다.

1.2.3.2. 쓰기 처리량

Pods간격(분)min당 시계열

400

1

83000

1.2.3.3. CPU 사용량(밀리코어)

테스트 중에 CPU 사용량이 안정적입니다.

크기CPU 사용량

클러스터 10개

400

클러스터 20개

800

1.2.3.4. RSS 및 작업 세트 메모리

RSS 및 작업 세트 메모리에 대한 다음 설명을 확인합니다.

  • 메모리 사용량 RSS: 지표 container_memory_rss 에서 테스트 중에 안정적으로 유지됩니다.
  • 메모리 사용량 작업 세트: 메트릭 container_memory_working_set_bytes 는 테스트와 함께 증가합니다.

다음 결과는 24 시간 테스트에서 가져온 것입니다.

크기메모리 사용량 RSS메모리 사용량 작업 세트

클러스터 10개

9.84

4.93

클러스터 20개

13.10

8.76

1.2.3.5. thanos-receive 구성 요소에 대한 영구 볼륨

중요: 지표는 보존 시간(4일)에 도달할 때까지 thanos-receive 에 저장됩니다. 다른 구성 요소에는 thanos-receive 구성 요소만큼 많은 볼륨이 필요하지 않습니다.

디스크 사용량이 테스트와 함께 증가합니다. 데이터는 1일 후 디스크 사용량을 나타내므로 최종 디스크 사용량이 4배 증가합니다.

다음 디스크 사용량을 확인합니다.

크기디스크 사용량(GiB)

클러스터 10개

2

클러스터 20개

3

1.2.3.6. 네트워크 전송

테스트 중에 네트워크 전송은 안정성을 제공합니다. 크기 및 네트워크 전송 값을 참조하십시오.

크기인바운드 네트워크 전송아웃바운드 네트워크 전송

클러스터 10개

초당 6.55MBS

초당 5.80MBS

클러스터 20개

초당 13.08MBS

초당 10.9MBS

1.2.3.7. Amazon Simple Storage Service (S3)

Amazon Simple Storage Service(S3)의 총 사용량이 증가합니다. 지표 데이터는 기본 보존 시간(5일)에 도달할 때까지 S3에 저장됩니다. 다음 디스크 사용량을 참조하십시오.

크기디스크 사용량(GiB)

클러스터 10개

16.2

클러스터 20개

23.8

1.2.4. hub 클러스터 크기 조정

각 Red Hat Advanced Cluster Management for Kubernetes 클러스터는 고유하며 다음 지침은 배포 크기를 샘플로 제공합니다. 권장 사항은 크기와 목적에 따라 분류됩니다. Red Hat Advanced Cluster Management는 지원 서비스의 규모 및 배치에 다음과 같은 차원을 적용합니다.

  • 가용성 영역은 클러스터 전체에서 잠재적인 오류 도메인을 격리합니다. 일반적인 클러스터에는 3개 이상의 가용성 영역에 거의 동일한 작업자 노드 용량이 있어야 합니다.
  • vCPU 예약 및 제한: 컨테이너에 할당할 작업자 노드에서 vCPU 용량을 설정합니다. vCPU는 Kubernetes 컴퓨팅 단위와 동일합니다. 자세한 내용은 Kubernetes CPU 메커니즘을 참조하십시오.
  • 컨테이너에 할당할 작업자 노드에서 메모리 용량을 설정하는 메모리 예약 및 제한입니다.
  • 제품에서 관리하고 Kubernetes에서 사용하는 etcd 클러스터에 저장된 영구 데이터입니다.

중요: OpenShift Container Platform의 경우 3개의 가용성 영역에 클러스터의 마스터 노드를 배포합니다.

1.2.4.1. 제품 환경

참고: 다음 요구 사항은 최소 요구사항이 아닙니다.

표 1.1. 제품 환경

노드 유형

가용성 영역

etcd

예약된 총 메모리

예약된 총 CPU

Master

3

3

OpenShift Container Platform 크기 조정 지침

OpenShift Container Platform 크기 조정 지침

작업자 또는 인프라

3

1

12GB

6

OpenShift Container Platform 클러스터는 Red Hat Advanced Cluster Management 외에도 클러스터 기능을 지원하기 위해 추가 서비스를 실행합니다. 자세한 내용은 인프라 노드에 Red Hat Advanced Cluster Management hub 클러스터 설치를 참조하십시오.

1.2.4.1.1. Amazon Web Services의 OpenShift Container Platform

자세한 내용은 OpenShift Container Platform 제품 설명서의 Amazon Web Services 정보를 참조하십시오.

또한 머신 유형에 대해 자세히 알아보십시오.

  • 노드 수: 3
  • 가용 영역: 3
  • 인스턴스 크기: m5.xlarge

    • vCPU: 4
    • 메모리: 16GB
    • 스토리지 크기: 120GB
1.2.4.1.2. Google Cloud Platform의 OpenShift 클러스터

할당량에 대한 자세한 내용은 Google Cloud Platform 제품 설명서를 참조하십시오.

또한 머신 유형에 대해 자세히 알아보십시오.

  • 노드 수: 3
  • 가용 영역: 3
  • 인스턴스 크기: N1-standard-4 (0.95-6.5GB)

    • vCPU: 4
    • 메모리: 15GB
    • 스토리지 크기: 120GB
1.2.4.1.3. Microsoft Azure의 OpenShift 클러스터

자세한 내용은 다음 제품 설명서 를 참조하십시오.

  • 노드 수: 3
  • 가용 영역: 3
  • 인스턴스 크기: Standard_D4_v3

    • vCPU: 4
    • 메모리: 16GB
    • 스토리지 크기: 120GB
1.2.4.1.4. VMware vSphere의 OpenShift 클러스터

자세한 내용은 다음 제품 설명서 를 참조하십시오.

  • 노드 수: 3
  • 가용 영역: 3
  • 인스턴스 크기:

    • 메모리: 16GB
    • 스토리지 크기: 120GB
    • vCPUs: 4
    • 소켓당 코어 수: 2
1.2.4.1.5. IBM Z 시스템의 OpenShift Container Platform

자세한 내용은 OpenShift Container Platform 설명서에서 IBM Z 시스템에 클러스터 설치를 참조하십시오.

  • 노드 수: 3
  • 가용 영역: 3
  • 인스턴스 크기:

    • 메모리: 16GB
    • 스토리지 크기: 100GB
    • vCPU: 10

      IBM Z 시스템은 동시 멀티스레딩(SMT)을 구성할 수 있는 기능을 제공하며 각 코어에서 실행할 수 있는 vCPU 수를 확장합니다. SMT를 구성한 경우 하나의 물리적 코어(IFL)는 두 개의 논리 코어(스레드)를 제공합니다. 하이퍼바이저는 두 개 이상의 vCPU를 제공할 수 있습니다.

      SMT(동시 멀티스레딩) 또는 하이퍼 스레딩이 활성화되지 않은 경우 하나의 vCPU는 하나의 물리적 코어와 동일합니다. 활성화하면 다음과 같은 공식을 사용하여 해당 비율을 계산합니다. (코어 당 스레드 수 × 코어 수) × 소켓 수 = vCPU 수

      SMT에 대한 자세한 내용은 Simultaneous multithreading 을 참조하십시오.

1.2.4.1.6. IBM Power 시스템의 OpenShift Container Platform

자세한 내용은 OpenShift Container Platform 설명서의 Power 시스템에 클러스터 설치를 참조하십시오.

  • 노드 수: 3
  • 가용 영역: 3
  • 인스턴스 크기:

    • 메모리: 16GB
    • 스토리지 크기: 120GB
    • vCPU: 16

      IBM Power 시스템은 동시 멀티스레딩(SMT)을 구성할 수 있는 기능을 제공하며 각 코어에서 실행할 수 있는 vCPU 수를 확장합니다. SMT를 구성한 경우 SMT 수준은 16 vCPU 요구 사항을 충족하는 방법을 결정합니다. 가장 일반적인 구성은 다음과 같습니다.

      • SMT-8에서 실행 중인 코어 두 개(IBM PowerVM을 실행하는 시스템의 기본 구성)는 필요한 16개의 vCPU를 제공합니다.
      • SMT-4에서 실행되는 코어 4개는 필요한 16개의 vCPU를 제공합니다.

        SMT에 대한 자세한 내용은 Simultaneous multithreading 을 참조하십시오.

1.2.4.1.7. 베어 메탈 자산의 OpenShift Container Platform 클러스터

자세한 내용은 다음 제품 설명서 를 참조하십시오.

OpenShift Container Platform 베어 메탈에 Red Hat Advanced Cluster Management for Kubernetes hub 클러스터를 설치하고 지원할 수 있습니다. 허브 클러스터는 컴팩트한 베어 메탈 토폴로지에서 실행할 수 있으며, 여기에는 3개의 스케줄링 가능한 컨트롤 플레인 노드와 0개의 추가 작업자가 있습니다.

  • 노드 수: 3
  • 가용 영역: 3
  • 인스턴스 크기:

    • 메모리: 16GB
    • 스토리지 크기: 120GB
    • vCPUs: 4
1.2.4.1.8. 단일 노드 OpenShift Container Platform 클러스터 생성 및 관리

2200개의 단일 노드 OpenShift Container Platform 클러스터를 생성하고 관리하는 데 필요한 요구사항의 예를 참조하십시오. Red Hat Advanced Cluster Management를 사용하여 단일 노드 OpenShift (SNO) 클러스터를 생성하고 허브 클러스터가 있는 SNO 클러스터를 관리하기 위한 최소 요구사항을 참조하십시오.

  • 마스터 (예약 가능)

    • 노드 수: 3
    • 메모리: 289GB(클러스터 최대)
    • 메모리: 110GB(단일 노드 최대)
    • CPU 클러스터 최대: 90
    • CPU 단일 노드 최대: 44

참고: 여러 개의 클러스터가 동시에 생성되는 동안 CPU 사용률 값이 급증했습니다.

1.3. 온라인 연결 중 설치

Red Hat Advanced Cluster Management for Kubernetes는 Red Hat Advanced Cluster Management hub 클러스터를 포함하는 구성 요소의 설치, 업그레이드 및 제거를 관리하는 Operator Lifecycle Manager를 통해 설치됩니다.

시작하기 전에 요구 사항 및 권장 사항 섹션을 검토한 다음 다음 설명서를 참조하십시오.

필수 액세스: 클러스터 관리자. OpenShift Container Platform Dedicated 환경에 액세스해야 합니다. cluster-admin 권한이 있어야 합니다. 기본적으로 dedicated-admin 역할에는 OpenShift Container Platform Dedicated 환경에서 네임스페이스를 생성하는 데 필요한 권한이 없습니다.

  • 기본적으로 허브 클러스터 구성 요소는 추가 구성없이 OpenShift Container Platform 클러스터의 작업자 노드에 설치됩니다. OpenShift Container Platform OperatorHub 웹 콘솔 인터페이스를 사용하거나 OpenShift Container Platform CLI를 사용하여 작업자 노드에 hub 클러스터를 설치할 수 있습니다.
  • 인프라 노드로 OpenShift Container Platform 클러스터를 구성한 경우 추가 리소스 매개변수가 포함된 OpenShift Container Platform CLI를 사용하여 해당 인프라 노드에 hub 클러스터를 설치할 수 있습니다. 자세한 내용은 인프라 노드에 Red Hat Advanced Cluster Management hub 클러스터 설치 섹션을 참조하십시오.
  • OpenShift Container Platform 또는 Red Hat Advanced Cluster Management에서 생성하지 않은 Kubernetes 클러스터를 가져오려면 이미지 가져오기 보안을 구성해야 합니다.

고급 구성을 구성하는 방법에 대한 자세한 내용은 문서의 MultiClusterHub 고급 구성 섹션의 옵션을 참조하십시오.

1.3.1. 사전 요구 사항

Red Hat Advanced Cluster Management를 설치하기 전에 다음 요구사항을 참조하십시오.

  • Red Hat OpenShift Container Platform 클러스터는 OpenShift Container Platform 콘솔에서 OperatorHub 카탈로그의 Red Hat Advanced Cluster Management Operator에 액세스할 수 있어야 합니다.
  • catalog.redhat.com 에 액세스해야 합니다.
  • OpenShift Container Platform 버전 4.8 이상은 사용자 환경에 배포해야 하며 OpenShift Container Platform CLI로 로그인해야 합니다. OpenShift Container Platform 버전 4.8 이상은 사용자 환경에 배포해야 하며 OpenShift Container Platform CLI로 로그인해야 합니다. OpenShift Container Platform에 대한 다음 설치 문서를 확인하고 필요한 이전 버전 OpenShift Container Platform 버전 4.10으로 변경합니다.
  • oc 명령을 실행하려면 OpenShift Container Platform CLI(명령줄 인터페이스)를 구성해야 합니다. OpenShift Container Platform CLI 설치 및 구성에 대한 정보는 CLI 시작하기 를 참조하십시오.
  • OpenShift Container Platform 권한을 통해 네임스페이스를 생성할 수 있어야 합니다. 네임스페이스가 없으면 설치에 실패합니다.
  • Operator의 종속성에 액세스하려면 인터넷 연결이 있어야 합니다.
  • 중요: OpenShift Container Platform Dedicated 환경에 설치하려면 다음 요구 사항을 참조하십시오.

    • OpenShift Container Platform Dedicated 환경이 구성 및 실행되고 있어야 합니다.
    • hub 클러스터를 설치하는 OpenShift Container Platform Dedicated 환경에 대한 cluster-admin 권한이 있어야 합니다.
    • 가져오려면 klusterlet Operator의 stable-2.0 채널을 2.5에 사용해야 합니다.

1.3.2. OpenShift Container Platform 설치 확인

레지스트리 및 스토리지 서비스를 포함하여 지원되는 OpenShift Container Platform 버전이 설치되어 작동해야 합니다. OpenShift Container Platform 설치에 대한 자세한 내용은 OpenShift Container Platform 설명서를 참조하십시오.

  1. Red Hat Advanced Cluster Management hub 클러스터가 OpenShift Container Platform 클러스터에 아직 설치되어 있지 않은지 확인합니다. Red Hat Advanced Cluster Management는 각 OpenShift Container Platform 클러스터에 하나의 Red Hat Advanced Cluster Management 허브 클러스터만 설치할 수 있습니다. Red Hat Advanced Cluster Management hub 클러스터가 설치되지 않은 경우 다음 단계를 계속합니다.
  2. OpenShift Container Platform 클러스터가 올바르게 설정되었는지 확인하려면 다음 명령을 사용하여 OpenShift Container Platform 웹 콘솔에 액세스합니다.

    kubectl -n openshift-console get route

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

    openshift-console console console-openshift-console.apps.new-coral.purple-chesterfield.com
    console   https   reencrypt/Redirect     None
  3. 브라우저에서 URL을 열고 결과를 확인합니다. 콘솔 URL에 console-openshift-console.router.default.svc.cluster.local 이 표시되면 OpenShift Container Platform을 설치할 때 openshift_master_default_subdomain 의 값을 설정합니다. URL의 다음 예제를 참조하십시오. https://console-openshift-console.apps.new-coral.purple-chesterfield.com.

콘솔 또는 CLI에서 Red Hat Advanced Cluster Management를 설치할 수 있습니다. 두 절차를 모두 문서화합니다.

1.3.3. OperatorHub 웹 콘솔 인터페이스에서 설치

모범 사례: OpenShift Container Platform 탐색의 관리자 보기에서 OpenShift Container Platform과 함께 제공되는 OperatorHub 웹 콘솔 인터페이스를 설치합니다.

  1. Operator > OperatorHub 를 선택하여 사용 가능한 Operator 목록에 액세스하고 Kubernetes Operator용 고급 클러스터 관리를 선택합니다.
  2. Operator 서브스크립션 페이지에서 설치 옵션을 선택합니다.

    • 네임스페이스 정보:

      • Red Hat Advanced Cluster Management hub 클러스터를 자체 네임스페이스 또는 프로젝트에 설치해야 합니다.
      • 기본적으로 OperatorHub 콘솔 설치 프로세스는 open-cluster-management 라는 네임스페이스를 생성합니다. 모범 사례: 사용 가능한 경우 open-cluster-management 네임스페이스를 계속 사용합니다.
      • open-cluster-management 라는 네임스페이스가 이미 있는 경우 다른 네임스페이스를 선택합니다.
    • Channel: 선택한 채널은 설치 중인 릴리스에 해당합니다. 채널을 선택하면 확인된 릴리스를 설치하고 해당 릴리스 내에서 향후 에라타 업데이트를 가져옵니다.
    • 업데이트 승인 전략: 승인 전략은 구독한 채널에 업데이트를 적용하는 데 필요한 사람의 상호 작용을 식별합니다.

      • 자동 을 선택하여 해당 릴리스 내의 모든 업데이트가 자동으로 적용되도록 합니다.
      • 업데이트를 사용할 수 있을 때 알림을 받으려면 수동 을 선택합니다. 언제 업데이트가 적용되었는지에 대한 우려가 있는 경우 이 방법이 모범 사례일 수 있습니다.

    중요: 다음 마이너 릴리스로 업그레이드하려면 OperatorHub 페이지로 돌아가 최신 릴리스의 새 채널을 선택해야 합니다.

  3. 설치를 선택하여 변경 사항을 적용하고 Operator를 생성합니다.
  4. MultiClusterHub 사용자 정의 리소스를 만듭니다.

    1. OpenShift Container Platform 콘솔 탐색에서 설치된 Operator > Kubernetes용 고급 클러스터 관리를 선택합니다.
    2. MultiClusterHub 탭을 선택합니다.
    3. MultiClusterHub 만들기를 선택합니다.
    4. YAML 파일에서 기본값을 업데이트합니다. 설명서의 MultiClusterHub 고급 구성 섹션에서 옵션을 참조하십시오.

      • 다음 예제에서는 기본 템플릿을 보여줍니다. 네임스페이스가 프로젝트 네임스페이스 인지 확인합니다. 샘플을 참조하십시오.
      apiVersion: operator.open-cluster-management.io/v1
      kind: MultiClusterHub
      metadata:
        name: multiclusterhub
        namespace: <namespace>
  5. 생성을 선택하여 사용자 정의 리소스를 초기화합니다. Red Hat Advanced Cluster Management hub 클러스터가 구축 및 시작하는 데 최대 10분이 걸릴 수 있습니다.

    Red Hat Advanced Cluster Management hub 클러스터를 생성한 후 MultiClusterHub 리소스 상태에 Red Hat Advanced Cluster Management Operator 세부 정보의 MultiClusterHub 탭에서 Running 이 표시됩니다. 이제 Red Hat Advanced Cluster Management hub 클러스터의 콘솔에 액세스할 수 있습니다. 다음 단계를 참조하십시오.

  6. OpenShift Container Platform 콘솔 탐색에서 네트워킹 > 경로 를 선택합니다.
  7. 목록에서 Red Hat Advanced Cluster Management hub 클러스터의 URL을 보고 해당 클러스터로 이동하여 콘솔에 액세스합니다.

1.3.4. OpenShift Container Platform CLI에서 설치

  1. Operator 요구 사항이 포함된 Red Hat Advanced Cluster Management hub 클러스터 네임스페이스를 생성합니다. 다음 명령을 실행합니다. 여기서 namespace 는 Red Hat Advanced Cluster Management hub 클러스터 네임스페이스의 이름입니다. 네임스페이스 값은 OpenShift Container Platform 환경에서 Project 라고 할 수 있습니다.

    oc create namespace <namespace>
  2. 프로젝트 네임스페이스를 생성한 네임스페이스로 전환합니다. namespace 를 1단계에서 생성한 Red Hat Advanced Cluster Management hub 클러스터 네임스페이스의 이름으로 교체합니다.

    oc project <namespace>
  3. YAML 파일을 생성하여 OperatorGroup 리소스를 구성합니다. 각 네임스페이스에는 Operator 그룹이 하나만 있을 수 있습니다. default 를 Operator 그룹의 이름으로 바꿉니다. namespace 를 프로젝트 네임스페이스의 이름으로 바꿉니다. 다음 샘플을 참조하십시오.

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: <default>
    spec:
      targetNamespaces:
      - <namespace>
  4. 다음 명령을 실행하여 OperatorGroup 리소스를 생성합니다. operator-group 을 생성한 Operator 그룹 YAML 파일의 이름으로 변경합니다.

    oc apply -f <path-to-file>/<operator-group>.yaml
  5. YAML 파일을 생성하여 OpenShift Container Platform 서브스크립션을 구성합니다. 파일은 다음 샘플과 유사합니다.

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: acm-operator-subscription
    spec:
      sourceNamespace: openshift-marketplace
      source: redhat-operators
      channel: release-2.5
      installPlanApproval: Automatic
      name: advanced-cluster-management

    참고: 인프라 노드에 Red Hat Advanced Cluster Management hub 클러스터를 설치하려면 Operator Lifecycle Manager 서브스크립션 추가 구성 섹션을 참조하십시오.

  6. 다음 명령을 실행하여 OpenShift Container Platform 서브스크립션을 생성합니다. 서브스크립션을 생성한 서브스크립션 파일의 이름으로 변경합니다.

    oc apply -f <path-to-file>/<subscription>.yaml
  7. YAML 파일을 생성하여 MultiClusterHub 사용자 정의 리소스를 구성합니다. 기본 템플릿은 다음 예와 유사해야 합니다. namespace 를 프로젝트 네임스페이스의 이름으로 변경합니다.

    apiVersion: operator.open-cluster-management.io/v1
    kind: MultiClusterHub
    metadata:
      name: multiclusterhub
      namespace: <namespace>
    spec: {}

    참고: 인프라 노드에 Red Hat Advanced Cluster Management hub 클러스터를 설치하려면 MultiClusterHub 사용자 정의 리소스 추가 구성 섹션을 참조하십시오.

  8. 다음 명령을 실행하여 MultiClusterHub 사용자 정의 리소스를 만듭니다. custom-resource 를 사용자 정의 리소스 파일의 이름으로 교체합니다.

    oc apply -f <path-to-file>/<custom-resource>.yaml

    이 단계가 다음 오류와 함께 실패하면 리소스가 계속 생성되고 적용되는 것입니다. 리소스가 생성되면 몇 분 후에 명령을 다시 실행합니다.

    error: unable to recognize "./mch.yaml": no matches for kind "MultiClusterHub" in version "operator.open-cluster-management.io/v1"
  9. 다음 명령을 실행하여 사용자 정의 리소스를 가져옵니다. 명령을 실행한 후 MultiClusterHub 사용자 정의 리소스 상태가 status.phase 필드에 Running 으로 표시되는 데 최대 10분이 걸릴 수 있습니다.

    oc get mch -o=jsonpath='{.items[0].status.phase}'
  10. 상태가 Running 이면 경로를 찾을 경로 목록을 확인합니다.

    oc get routes

Red Hat Advanced Cluster Management를 재설치하고 Pod가 시작되지 않는 경우 이 문제를 해결하기 위한 단계의 재설치 실패 문제 해결을 참조하십시오.

참고:

  • ClusterRoleBinding 이 있는 ServiceAccount 는 Red Hat Advanced Cluster Management 및 Red Hat Advanced Cluster Management를 설치하는 네임스페이스에 대한 액세스 권한이 있는 모든 사용자 자격 증명에 대한 클러스터 관리자 권한을 자동으로 부여합니다.
  • 설치에서는 자체적으로 관리할 때 Red Hat Advanced Cluster Management hub 클러스터용으로 예약된 local-cluster 라는 네임스페이스도 생성합니다. local-cluster 라는 기존 네임스페이스가 있을 수 없습니다. 보안상의 이유로 클러스터 관리자 액세스 권한이 없는 사용자에게 로컬 클러스터 네임스페이스에 대한 액세스를 릴리스하지 마십시오.

1.3.5. 인프라 노드에 Red Hat Advanced Cluster Management hub 클러스터 설치

OpenShift Container Platform 클러스터는 승인된 관리 구성 요소를 실행하기 위한 인프라 노드를 포함하도록 구성할 수 있습니다. 인프라 노드에서 구성 요소를 실행하면 해당 관리 구성 요소를 실행하는 노드에 OpenShift Container Platform 서브스크립션 할당량이 할당되지 않습니다.

OpenShift Container Platform 클러스터에 인프라 노드를 추가한 후 OpenShift Container Platform CLI 명령에서 설치 후 Operator Lifecycle Manager 서브스크립션 및 MultiClusterHub 사용자 정의 리소스에 구성을 추가합니다.

1.3.5.1. OpenShift Container Platform 클러스터에 인프라 노드 추가

OpenShift Container Platform 설명서의 인프라 머신 세트 생성에 설명된 절차를 따르십시오. 인프라 노드는 관리 이외의 워크로드가 실행되지 않도록 쿠버네티스 테인트라벨 을 사용하여 구성됩니다.

Red Hat Advanced Cluster Management에서 제공하는 인프라 노드 활성화와 호환하려면 인프라 노드에 다음과 같은 테인트라벨 이 적용되었는지 확인하십시오.

metadata:
  labels:
    node-role.kubernetes.io/infra: ""
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/infra

1.3.5.2. Operator Lifecycle Manager 서브스크립션 추가 구성

Operator Lifecycle Manager 서브스크립션을 적용하기 전에 다음 추가 구성을 추가합니다.

spec:
  config:
    nodeSelector:
      node-role.kubernetes.io/infra: ""
    tolerations:
    - key: node-role.kubernetes.io/infra
      effect: NoSchedule
      operator: Exists

1.3.5.3. MultiClusterHub 사용자 정의 리소스 추가 구성

MultiClusterHub 사용자 정의 리소스를 적용하기 전에 다음 추가 구성을 추가합니다.

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

1.4. 연결이 끊긴 네트워크에 설치

인터넷에 연결되지 않은 Red Hat OpenShift Container Platform 클러스터에 Kubernetes용 Red Hat Advanced Cluster Management for Kubernetes를 설치해야 할 수 있습니다. 연결이 끊긴 허브에 설치하려면 연결된 설치와 동일한 몇 가지 단계가 필요합니다.

설치하는 동안 네트워크에서 직접 액세스하는 대신 설치 중에 액세스하려면 패키지 사본을 다운로드해야 합니다.

시작하기 전에 요구 사항 및 권장 사항 섹션을 검토한 다음 다음 설명서를 참조하십시오.

1.4.1. 사전 요구 사항

Red Hat Advanced Cluster Management for Kubernetes를 설치하기 전에 다음 요구 사항을 충족해야 합니다.

  • Red Hat OpenShift Container Platform 버전 4.8 이상은 사용자 환경에 배포해야 하며 CLI(명령줄 인터페이스)로 로그인해야 합니다.
  • catalog.redhat.com 에 액세스해야 합니다.

    참고: 베어 메탈 클러스터를 관리하려면 OpenShift Container Platform 버전 4.8 이상이 있어야 합니다.

    OpenShift Container Platform 버전 4.10,OpenShift Container Platform 버전 4.10 을 참조하십시오.

  • Red Hat OpenShift Container Platform CLI는 버전 4.8 이상이어야 하며 oc 명령을 실행하도록 구성해야 합니다. Red Hat OpenShift CLI 설치 및 구성에 대한 정보는 CLI 시작하기 를 참조하십시오.
  • Red Hat OpenShift Container Platform 권한을 통해 네임스페이스를 생성할 수 있어야 합니다. 네임스페이스 없이 설치에 실패합니다.
  • Operator의 종속성을 다운로드하려면 인터넷 연결이 있는 워크스테이션이 있어야 합니다.

1.4.2. OpenShift Container Platform 설치 확인

  • 클러스터에서 설치 및 작동하는 레지스트리 및 스토리지 서비스를 포함하여 지원되는 OpenShift Container Platform 버전이 있어야 합니다. OpenShift Container Platform 버전 4.10에 대한 자세한 내용은 OpenShift Container Platform 문서를 참조하십시오.
  • 연결되면 kubectl -n openshift-console get route 명령을 실행하여 OpenShift Container Platform 웹 콘솔에 액세스합니다. 다음 예제 출력을 참조하십시오.

    openshift-console          console             console-openshift-console.apps.new-coral.purple-chesterfield.com                       console              https   reencrypt/Redirect     None

    이 예의 콘솔 URL은 https:// console-openshift-console.apps.new-coral.purple-chesterfield.com 입니다. 브라우저에서 URL을 열고 결과를 확인합니다.

    콘솔 URL에 console-openshift-console.router.default.svc.cluster.local 이 표시되면 OpenShift Container Platform을 설치할 때 openshift_master_default_subdomain 의 값을 설정합니다.

hub 클러스터에 대한 용량 설정에 대한 자세한 내용은 클러스터 스케일링을 참조하십시오.

1.4.3. 연결이 끊긴 환경에 설치

중요: 연결이 끊긴 환경에서 운영자를 설치하려면 필요한 이미지를 미러링 레지스트리에 다운로드해야 합니다. 다운로드하지 않으면 배포 중에 ImagePullBackOff 오류가 발생할 수 있습니다.

다음 단계에 따라 연결이 끊긴 환경에 Red Hat Advanced Cluster Management를 설치합니다.

  1. 미러 레지스트리를 생성합니다. 미러 레지스트리가 아직 없는 경우 Red Hat OpenShift Container Platform 설명서의 연결이 끊긴 설치 주제의 이미지 미러링 에 있는 절차를 완료하여 생성합니다.

    미러 레지스트리가 이미 있는 경우 기존 레지스트리를 구성하고 사용할 수 있습니다.

    참고: 미러링된 Operator 카탈로그에서 OperatorHub를 채우는 OpenShift Container Platform 설명서의 단계를 따르십시오.

  2. 미러 운영자 카탈로그. 연결이 끊긴 클러스터에 사용할 Operator 카탈로그 미러링 절차의 절차에 따라 Operator 카탈로그를 미러링해야 합니다.

참고:

  • 기존 Red Hat Operator 인덱스 이미지에서 패키지를 정리하는 경우 advanced-cluster-managementmulticluster-engine 패키지가 모두 정리되었는지 확인합니다. 자세한 내용은 VMDK 기반 인덱스 이미지 필터링 을 참조하십시오.
  • 매니페스트 생성 프로세스 중에 매니페스트 디렉터리에 catalogSource.yaml 파일을 생성합니다. 연결이 끊긴 Operator Lifecycle Manager를 구성할 때 이 샘플 파일을 사용합니다.
  • 베어 메탈의 경우에만 install-config.yaml 파일에 연결이 끊긴 레지스트리의 인증서 정보를 제공해야 합니다. 연결이 끊긴 레지스트리에서 이미지에 액세스하려면 Red Hat Advanced Cluster Management가 레지스트리에 액세스할 수 있도록 인증서 정보를 제공해야 합니다.

    1. 레지스트리에서 인증서 정보를 복사합니다.
    2. 편집기에서 install-config.yaml 파일을 엽니다.
    3. additionalTrustBundle: | 에 대한 항목을 찾습니다.
    4. additionalTrustBundle 행 뒤에 인증서 정보를 추가합니다. 콘텐츠 결과는 다음 예와 유사합니다.

      additionalTrustBundle: |
        -----BEGIN CERTIFICATE-----
        certificate_content
        -----END CERTIFICATE-----
      sshKey: >-

      중요: 다음 관리 정책이 필요한 경우 연결 해제된 이미지 레지스트리의 미러가 필요합니다.

      • 컨테이너 보안 운영자 정책: 이미지는 소스 registry.redhat.io/quay 에 있습니다.
      • 규정 준수 Operator 정책: 이미지는 소스 registry.redhat.io/compliance 에 있습니다.
      • 게이트키퍼 운영자 정책: 이미지는 소스 registry.redhat.io/rhacm2 에 있습니다.

        세 가지 Operator 모두의 미러 목록의 다음 예제를 참조하십시오.

            - mirrors:
              - <your_registry>/rhacm2
              source: registry.redhat.io/rhacm2
            - mirrors:
              - <your_registry>/quay
              source: registry.redhat.io/quay
            - mirrors:
              - <your_registry>/compliance
              source: registry.redhat.io/compliance
        1. install-config.yaml 파일을 저장합니다.
        2. rhacm-policy.yaml 이라는 ImageContentSourcePolicy 가 포함된 YAML 파일을 생성합니다. 참고: 실행 중인 클러스터에서 이 값을 수정하면 모든 노드가 롤링 재시작됩니다.

          apiVersion: operator.openshift.io/v1alpha1
          kind: ImageContentSourcePolicy
          metadata:
            name: rhacm-repo
          spec:
            repositoryDigestMirrors:
            - mirrors:
              - mirror.registry.com:5000/rhacm2
              source: registry.redhat.io/rhacm2
        3. 다음 명령을 입력하여 ImageContentSourcePolicy 파일을 적용합니다.

          oc apply -f rhacm-policy.yaml
        4. 연결이 끊긴 Operator Lifecycle Manager Red Hat Operator 및 커뮤니티 Operator를 활성화합니다. Red Hat Advanced Cluster Management는 Operator Lifecycle Manager Red Hat Operator 카탈로그에 포함되어 있습니다.
        5. Red Hat Operator 카탈로그에 대해 연결이 끊긴 Operator Lifecycle Manager를 구성합니다. Red Hat OpenShift Container Platform 설명서의 제한된 네트워크에서 Operator Lifecycle Manager 사용 주제의 단계를 따르십시오.

          • 클러스터에 카탈로그 소스 추가 단계의 경우 Operator 카탈로그를 미러링할 때 생성한 catalogSource.yaml 파일을 사용합니다.
          • 자체 catalogSource.yaml 파일을 사용하고 카탈로그 소스 이름이 예상 redhat-operator-index 와 다른 경우 my-operator-catalog 대신 카탈로그 소스와 함께 다음 주석을 MultiClusterHub 사용자 정의 리소스에 추가해야 합니다.
    apiVersion: operator.open-cluster-management.io/v1
    kind: MultiClusterHub
    metadata:
      annotations:
        installer.open-cluster-management.io/mce-subscription-spec: '{"source": "my-operator-catalog"}'

연결이 끊긴 Operator Lifecycle Manager에 이미지가 있으므로 Operator Lifecycle Manager 카탈로그에서 Kubernetes용 Red Hat Advanced Cluster Management를 계속 설치합니다.

필요한 단계는 온라인에 연결된 동안 설치를 참조하거나 설치 개요로 돌아갑니다.

1.5. MultiClusterHub 고급 구성

Red Hat Advanced Cluster Management for Kubernetes는 필요한 모든 구성 요소를 배포하는 Operator를 사용하여 설치됩니다. Red Hat Advanced Cluster Management는 MultiClusterHub 사용자 정의 리소스에 다음 속성 중 하나 이상을 추가하여 설치 중 또는 설치 후에 추가로 구성할 수 있습니다.

1.5.1. 사용자 정의 이미지 가져오기 시크릿

OpenShift Container Platform 또는 Red Hat Advanced Cluster Management에서 생성하지 않은 Kubernetes 클러스터를 가져오려면 OpenShift Container Platform 풀 시크릿 정보가 포함된 시크릿을 생성하여 배포 레지스트리에서 권한이 있는 콘텐츠에 액세스합니다.

OpenShift Container Platform 클러스터의 시크릿 요구 사항은 OpenShift Container Platform 및 Red Hat Advanced Cluster Management에서 자동으로 해결되므로 관리할 다른 유형의 Kubernetes 클러스터를 가져오지 않는 경우 시크릿을 생성할 필요가 없습니다. OpenShift Container Platform 풀 시크릿은 Red Hat 고객 포털 ID와 연결되어 있으며 모든 Kubernetes 공급자에서 동일합니다.

중요: 이러한 보안은 네임스페이스별이므로 hub 클러스터에 사용하는 네임스페이스에 있는지 확인합니다.

  1. cloud.redhat.com/openshift/install/pull-secret 으로 이동하여 OpenShift Container Platform 풀 시크릿 파일을 다운로드합니다.
  2. 풀 시크릿 다운로드를 클릭합니다.
  3. 다음 명령을 실행하여 보안을 생성합니다.

    oc create secret generic <secret> -n <namespace> --from-file=.dockerconfigjson=<path-to-pull-secret> --type=kubernetes.io/dockerconfigjson
    • 보안을 생성하려는 보안의 이름으로 교체합니다.
    • 보안이 네임스페이스 와 일치하므로 네임스페이스를 프로젝트 네임스페이스로 바꿉니다.
    • 다운로드한 OpenShift Container Platform 풀 시크릿의 경로로 path-to-pull-secret 을 교체합니다.

다음 예제에서는 사용자 정의 풀 시크릿을 사용하려는 경우 사용할 spec.imagePullSecret 템플릿을 표시합니다. secret을 풀 시크릿의 이름으로 교체합니다.

apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterHub
metadata:
  name: multiclusterhub
  namespace: <namespace>
spec:
  imagePullSecret: <secret>

1.5.2. availabilityConfig

Red Hat Advanced Cluster Management hub 클러스터에는 HighBasic 이라는 두 가지 기능이 있습니다. 기본적으로 hub 클러스터는 고가용성으로, 허브 클러스터 구성 요소에 2replicaCount 를 제공합니다. 이를 통해 페일오버의 경우 지원이 향상되지만 기본 가용성보다 많은 리소스를 소비하여 구성 요소에 1replicaCount 를 제공합니다.

다음 예제에서는 기본 가용성이 있는 spec.availabilityConfig 템플릿을 보여줍니다.

apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterHub
metadata:
  name: multiclusterhub
  namespace: <namespace>
spec:
  availabilityConfig: "Basic"

1.5.3. nodeSelector

Red Hat Advanced Cluster Management hub 클러스터에서 노드 선택기 세트를 정의하여 클러스터의 특정 노드에 설치할 수 있습니다. 다음 예제에서는 node-role.kubernetes.io/infra 레이블이 있는 노드에 Red Hat Advanced Cluster Management Pod를 할당하는 spec.nodeSelector 를 보여줍니다.

apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterHub
metadata:
  name: multiclusterhub
  namespace: <namespace>
spec:
  nodeSelector:
    node-role.kubernetes.io/infra: ""

1.5.4. 허용 오차

Red Hat Advanced Cluster Management hub 클러스터에서 클러스터에 정의된 특정 테인트를 허용할 수 있도록 허용 오차 목록을 정의할 수 있습니다.

다음 예제는 node-role.kubernetes.io/infra 테인트와 일치하는 spec.tolerations 를 보여줍니다.

apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterHub
metadata:
  name: multiclusterhub
  namespace: <namespace>
spec:
  tolerations:
  - key: node-role.kubernetes.io/infra
    effect: NoSchedule
    operator: Exists

이전 infra-node 허용 오차는 구성에서 허용 오차를 지정하지 않고 기본적으로 Pod에 설정됩니다. 구성에서 허용 오차를 사용자 정의하면 이 기본값이 대체됩니다.

1.5.5. disableHubSelfManagement

기본적으로 Red Hat Advanced Cluster Management hub 클러스터는 자체적으로 자동으로 가져오고 관리됩니다. 이 관리 허브 클러스터 이름은 로컬 클러스터 입니다.

Red Hat Advanced Cluster Management hub 클러스터가 자체 관리하기를 원하지 않는 경우, spec의 설정을 disableHubSelfManagement 에서 false 로 변경해야 합니다. 사용자 정의 리소스를 정의하는 YAML 파일에 설정이 포함되지 않은 경우 이를 추가해야 합니다. hub 클러스터는 이 옵션으로만 관리할 수 있습니다.

이 옵션을 true 로 설정하고 허브를 수동으로 관리하려고 하면 예기치 않은 동작이 발생합니다.

다음 예제는 허브 클러스터 자체 관리 기능을 비활성화하려는 경우 사용할 기본 템플릿을 보여줍니다. 네임스페이스를 프로젝트 이름으로 교체합니다.

apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterHub
metadata:
  name: multiclusterhub
  namespace: <namespace>
spec:
  disableHubSelfManagement: true

1.5.6. disableUpdateClusterImageSets

모든 클러스터에 동일한 릴리스 이미지를 사용하려면 클러스터를 생성할 때 사용 가능한 자체 사용자 정의 릴리스 이미지 목록을 생성할 수 있습니다.

사용 가능한 릴리스 이미지를 관리하는 데 연결된 경우 릴리스 이미지의 사용자 정의 목록을 유지 관리하고 사용자 정의 이미지 목록을 덮어쓰지 않도록 spec.disableUpdateClusterImageSets 속성을 설정하려면 다음 지침을 참조하십시오.

다음 예제에서는 클러스터 이미지 세트에 대한 업데이트를 비활성화하는 기본 템플릿을 보여줍니다. 네임스페이스를 프로젝트 이름으로 교체합니다.

apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterHub
metadata:
  name: multiclusterhub
  namespace: <namespace>
spec:
  disableUpdateClusterImageSets: true

1.5.7. customCAConfigmap

기본적으로 Red Hat OpenShift Container Platform은 Ingress Operator를 사용하여 내부 CA를 생성합니다.

다음 예는 사용자 정의된 OpenShift Container Platform 기본 수신 CA 인증서를 Red Hat Advanced Cluster Management에 제공하는 데 사용되는 기본 템플릿을 보여줍니다. namespace 를 프로젝트 이름으로 바꿉니다. spec.customCAConfigmap 값을 ConfigMap 이름으로 교체합니다.

apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterHub
metadata:
  name: multiclusterhub
  namespace: <namespace>
spec:
  customCAConfigmap: <configmap>

1.5.8. sslCiphers

기본적으로 Red Hat Advanced Cluster Management hub 클러스터에는 지원되는 전체 SSL 암호화 목록이 포함되어 있습니다.

다음 예제에서는 관리 인그레스 sslCiphers 를 나열하는 데 사용되는 기본 spec.ingress.sslCiphers 템플릿을 보여줍니다. 네임스페이스를 프로젝트 이름으로 교체합니다.

apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterHub
metadata:
  name: multiclusterhub
  namespace: <namespace>
spec:
  ingress:
    sslCiphers:
    - "ECDHE-ECDSA-AES128-GCM-SHA256"
    - "ECDHE-RSA-AES128-GCM-SHA256"

1.5.9. ClusterProxyAddon (기술 프리뷰)

다음 예제에서는 cluster-proxy-addon 을 활성화하는 데 사용되는 기본 spec.overrides 템플릿을 보여줍니다. 네임스페이스를 프로젝트 이름으로 교체합니다.

apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterHub
metadata:
  name: multiclusterhub
  namespace: <namespace>
spec:
  overrides:
    components:
    - name: cluster-proxy-addon
      enabled: true

또는 다음 명령을 실행할 수 있습니다. 네임스페이스를 프로젝트 이름으로 교체합니다.

oc patch MultiClusterHub multiclusterhub -n <namespace> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"cluster-proxy-addon","enabled":true}}]'

enableClusterProxyAddon 필드의 사용은 더 이상 지원되지 않으며 위로 대체됩니다.

1.5.10. ClusterBackup

enableClusterBackup 필드는 더 이상 지원되지 않으며 이 구성 요소로 교체됩니다.

다음 예제에서는 ClusterBackup 을 활성화하는 데 사용되는 spec.overrides 기본 템플릿을 보여줍니다. 네임스페이스를 프로젝트 이름으로 교체합니다.

apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterHub
metadata:
  name: multiclusterhub
  namespace: <namespace>
spec:
  overrides:
    components:
    - name: cluster-backup
      enabled: true

또는 다음 명령을 실행할 수 있습니다. namespace 를 프로젝트 이름으로 바꿉니다.

oc patch MultiClusterHub multiclusterhub -n <namespace> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"cluster-backup","enabled":true}}]'

1.5.11. ManagedServiceAccount 애드온 (기술 프리뷰)

다음 예제에서는 ManagedServiceAccount 를 활성화하는 데 사용되는 spec.overrides 기본 템플릿을 보여줍니다. 네임스페이스를 프로젝트 이름으로 교체합니다.

apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterHub
metadata:
  name: multiclusterhub
  namespace: <namespace>
spec:
  overrides:
    components:
    - name: managedserviceaccount-preview
      enabled: true

또는 다음 명령을 실행할 수 있습니다. namespace 를 프로젝트 이름으로 바꿉니다.

oc patch MultiClusterHub multiclusterhub -n <namespace> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"managedserviceaccount-preview","enabled":true}}]'

1.5.12. Hypershift 애드온 (기술 프리뷰)

다음 예제에서는 Hypershift 를 활성화하는 데 사용되는 spec.overrides 기본 템플릿을 보여줍니다. 네임스페이스를 프로젝트 이름으로 교체합니다.

apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterHub
metadata:
  name: multiclusterhub
  namespace: <namespace>
spec:
  overrides:
    components:
    - name: hypershift-preview
      enabled: true

또는 다음 명령을 실행할 수 있습니다. namespace 를 프로젝트 이름으로 바꿉니다.

oc patch MultiClusterHub multiclusterhub -n <namespace> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"hypershift-preview","enabled":true}}]'

1.6. 네트워크 구성

hub 클러스터 및 관리형 클러스터 네트워크의 구성과 추가 네트워킹 정보를 참조할 수 있습니다.

1.6.1. hub 클러스터 네트워크 구성 테이블

다음 표에서 허브 클러스터 네트워크 요구 사항을 참조하십시오.

direction프로토콜연결포트(지정된 경우)소스 주소대상 주소

관리형 클러스터의 아웃 바운드

HTTPS

Search Console에서 관리되는 클러스터의 Pod로 로그를 동적으로 검색하고 관리 클러스터에서 실행 중인 klusterlet-addon-workmgr 서비스를 사용합니다.

443

없음

관리형 클러스터 경로에 액세스하기 위한 IP 주소

관리형 클러스터의 아웃 바운드

HTTPS

klusterlet을 설치하기 위해 설치 중에 프로비저닝된 관리형 클러스터의 Kubernetes API 서버

6443

없음

Kubernetes 관리 클러스터 API 서버의 IP

채널 소스에 대한 아웃 바운드

HTTPS

GitHub, Object Store, Helm 리포지토리를 포함한 채널 소스는 애플리케이션 라이프사이클, OpenShift GitOps 또는 ArgoCD를 사용하여 연결하는 경우에만 필요합니다.

443

없음

채널 소스의 IP

관리형 클러스터의 인바운드

HTTPS

OpenShift Container Platform 버전 4.8 이상을 실행하는 관리형 클러스터에 대해서만 수집된 메트릭 및 경고를 푸시하는 관리형 클러스터

443

없음

hub 클러스터 액세스 경로로 IP 주소

관리형 클러스터의 인바운드

HTTPS

관리 클러스터에서 변경 사항을 조사하는 Kubernetes API 서버 허브 클러스터

6443

없음

hub 클러스터 Kubernetes API 서버의 IP 주소

ObjectStore에 대한 아웃 바운드

HTTPS

Cluster Backup Operator가 실행 중일 때 장기 스토리지에 대한 관찰성 지표 데이터를 보냅니다.

443

없음

ObjectStore의 IP 주소

이미지 리포지터리의 아웃 바운드

HTTPS

OpenShift Container Platform 및 Red Hat Advanced Cluster Management의 이미지에 액세스

443

없음

이미지 리포지토리의 IP 주소

1.6.2. 관리형 클러스터 네트워크 구성 테이블

참고: 관리형 클러스터의 등록 에이전트 및 작업 에이전트는 프록시를 통과할 수 없는 mTLS 연결을 설정하여 허브 클러스터에서 apiserver 와 통신하기 때문에 프록시 설정을 지원하지 않습니다.

다음 표의 관리형 클러스터 네트워크 요구 사항을 참조하십시오.

direction프로토콜연결포트(지정된 경우)소스 주소대상 주소

hub 클러스터에서 인바운드

HTTPS

관리 클러스터의 Pod에 대해 검색 콘솔에서 동적으로 로그를 전송하는 경우 관리 클러스터에서 실행 중인 klusterlet-addon-workmgr 서비스를 사용합니다.

443

없음

관리형 클러스터 경로에 액세스하기 위한 IP 주소

hub 클러스터에서 인바운드

HTTPS

klusterlet을 설치하기 위해 설치 중에 프로비저닝된 관리형 클러스터의 Kubernetes API 서버

6443

없음

Kubernetes 관리 클러스터 API 서버의 IP

이미지 리포지터리의 아웃 바운드

HTTPS

OpenShift Container Platform 및 Red Hat Advanced Cluster Management의 이미지에 액세스

443

없음

이미지 리포지토리의 IP 주소

hub 클러스터의 아웃 바운드

HTTPS

OpenShift Container Platform 버전 4.8 이상을 실행하는 관리형 클러스터에 대해서만 수집된 메트릭 및 경고를 푸시하는 관리형 클러스터

443

없음

hub 클러스터 액세스 경로로 IP 주소

hub 클러스터의 아웃 바운드

HTTPS

hub 클러스터의 Kubernetes API 서버에서 변경 사항을 감시합니다.

6443

없음

hub 클러스터 Kubernetes API 서버의 IP 주소

채널 소스에 대한 아웃 바운드

HTTPS

GitHub, Object Store, Helm 리포지토리를 포함한 채널 소스는 애플리케이션 라이프사이클, OpenShift GitOps 또는 ArgoCD를 사용하여 연결하는 경우에만 필요합니다.

443

없음

채널 소스의 IP

1.6.3. 인프라 운영자 테이블에 대한 추가 네트워킹 요구 사항

Infrastructure Operator를 사용하여 베어 메탈 관리 클러스터를 설치할 때 추가 네트워킹 요구 사항은 다음 표를 참조하십시오.

direction프로토콜연결포트(지정된 경우)

ISO/rootfs 이미지 리포지토리에 대한 Hub 클러스터 아웃바운드

HTTPS(연결이 끊긴 환경의 HTTP)

Red Hat Advanced Cluster Management 허브에서 ISO 이미지를 생성하는 데 사용

443 (연결이 끊긴 환경에서 80)

단일 노드 OpenShift Container Platform 관리 클러스터의 BMC 인터페이스에 대한 Hub 클러스터 아웃바운드

HTTPS(연결이 끊긴 환경의 HTTP)

OpenShift Container Platform 클러스터를 부팅

443

OpenShift Container Platform 관리 클러스터에서 허브 클러스터로의 아웃 바운드

HTTPS

assistedService 경로를 사용하여 하드웨어 정보를 보고합니다.

443

OpenShift Container Platform 관리 클러스터에서 ISO/rootfs 이미지 리포지토리로의 아웃 바운드

HTTP

rootfs 이미지 다운로드

80

1.6.4. Submariner 네트워킹 요구 사항 표

Submariner를 사용하는 클러스터에는 세 개의 열린 포트가 필요합니다. 다음 표에서는 사용할 수 있는 포트를 보여줍니다.

direction프로토콜연결포트(지정된 경우)

아웃바운드 및 인바운드

UDP

각 관리형 클러스터

4800

아웃바운드 및 인바운드

UDP

각 관리형 클러스터

4500, 500 및 게이트웨이 노드에서 IPSec 트래픽에 사용되는 다른 모든 포트

인바운드

TCP

각 관리형 클러스터

8080

1.6.5. Hive 테이블에 대한 추가 네트워킹 요구 사항

중앙 인프라 관리 사용을 포함하는 Hive Operator를 사용하여 베어 메탈 관리 클러스터를 설치하는 경우 허브 클러스터와 libvirt 프로비저닝 호스트 간에 계층 2 또는 계층 3 포트 연결을 구성해야 합니다. 이 프로비저닝 호스트에 대한 연결은 Hive를 사용하여 기본 메탈 클러스터를 생성하는 동안 필요합니다. 자세한 내용은 다음 표를 참조하십시오.

direction프로토콜연결포트(지정된 경우)

Hub 클러스터 아웃바운드 및 libvirt 프로비저닝 호스트에 대한 인바운드

IP

베어 메탈 클러스터를 생성할 때 부트스트랩 역할을 하는 libvirt 프로비저닝 호스트에 Hive Operator가 설치된 hub 클러스터를 연결합니다.

 

참고: 이 요구 사항은 설치 시에만 적용되며 Infrastructure Operator와 함께 설치된 클러스터를 업그레이드할 때 필요하지 않습니다.

1.6.6. 애플리케이션 배포 네트워크 요구 사항 표

일반적으로 애플리케이션 배포 통신은 관리 클러스터에서 허브 클러스터로의 한 가지 방법입니다. 연결에서는 관리 클러스터의 에이전트에 의해 구성된 kubeconfig 를 사용합니다. 관리형 클러스터의 애플리케이션 배포는 hub 클러스터의 다음 네임스페이스에 액세스해야 합니다.

  • 채널 리소스의 네임스페이스
  • 관리형 클러스터의 네임스페이스

1.6.7. 네임스페이스 연결 네트워크 요구 사항 표

  • 애플리케이션 라이프사이클 연결:

    • 네임스페이스 open-cluster-management 는 포트 4000의 콘솔 API에 액세스해야 합니다.
    • 네임스페이스 open-cluster-management 는 포트 3001에 애플리케이션 UI를 노출해야 합니다.
  • 애플리케이션 라이프사이클 백엔드 구성 요소(Pod):

    hub 클러스터에서는 다음 Pod를 포함하여 모든 애플리케이션 라이프사이클 Pod가 open-cluster-management 네임스페이스에 설치됩니다.

    • multicluster-operators-hub-subscription
    • multicluster-operators-standalone-subscription
    • multicluster-operators-channel
    • multicluster-operators-application
    • multicluster-integrations

      이러한 Pod가 open-cluster-management 네임스페이스에 있기 때문입니다.

    • 네임스페이스 open-cluster-management 는 포트 6443의 Kube API에 액세스해야 합니다.

    관리형 클러스터에서 klusterlet-addon-appmgr 애플리케이션 라이프사이클 Pod만 open-cluster-management-agent-addon 네임스페이스에 설치됩니다.

    • 네임스페이스 open-cluster-management-agent-addon 은 포트 6443의 Kube API에 액세스해야 합니다.
  • 거버넌스 및 위험:

    hub 클러스터에서는 다음 액세스가 필요합니다.

    • 네임스페이스 open-cluster-management 는 포트 6443의 Kube API에 액세스해야 합니다.
    • 네임스페이스 open-cluster-management 는 포트 5353의 OpenShift DNS에 액세스해야 합니다.

    관리형 클러스터에서는 다음 액세스가 필요합니다.

    • 네임스페이스 open-cluster-management-addon 은 포트 6443의 Kube API에 액세스해야 합니다.

자세한 내용은 Red Hat Advanced Cluster Management for Kubernetes 2.5 지원 매트릭스 를 참조하십시오.

1.7. Operator를 사용하여 업그레이드

Red Hat OpenShift Container Platform 콘솔의 operator 서브스크립션 설정을 사용하여 Kubernetes 업그레이드용 Red Hat Advanced Cluster Management를 제어할 수 있습니다. Operator를 사용하여 Red Hat Advanced Cluster Management를 처음 배포할 때 다음과 같은 옵션을 선택할 수 있습니다.

  • 채널: 설치 중인 제품의 버전에 맞게 조정됩니다. 초기 채널 설정은 종종 설치 시 사용 가능한 가장 최신 채널입니다.
  • 승인: 채널 내 업데이트에 승인이 필요한지 또는 자동으로 수행되는지 여부를 지정합니다.

    • 자동으로 설정하면 선택한 채널에서 마이너 릴리스 업데이트가 관리자 개입 없이 배포됩니다.
    • Manual 로 설정하면 채널 내의 마이너 릴리스로의 각 업데이트마다 관리자가 업데이트를 승인해야 합니다.

Operator를 사용하여 Red Hat Advanced Cluster Management를 업그레이드하는 경우에도 이러한 설정을 사용합니다.

필수 액세스 권한: OpenShift Container Platform 관리자

Operator를 업그레이드하려면 다음 단계를 완료합니다.

중요: 채널 선택에서 이후 버전으로 업그레이드한 후에는 이전 버전으로 되돌릴 수 없습니다. 이전 버전을 사용하려면 Operator를 제거한 후 이전 버전으로 다시 설치해야 합니다.

  1. OpenShift Container Platform Operator 허브에 로그인합니다.
  2. OpenShift Container Platform 탐색에서 Operator > 설치된 Operator 를 선택합니다.
  3. Red Hat Advanced Cluster Management for Kubernetes Operator를 선택합니다.
  4. 서브스크립션 탭을 선택하여 서브스크립션 설정을 편집합니다.
  5. Upgrade Status (업그레이드 상태에 최신) 레이블이 지정되어 있는지 확인합니다. 이 상태는 Operator가 선택한 채널에서 사용 가능한 최신 수준에 있음을 나타냅니다. 업그레이드 상태가 보류 중임을 나타내는 경우 다음 단계를 완료하여 채널에서 사용 가능한 최신 마이너 릴리스로 업데이트합니다.

    1. Approval 필드에서 Manual 설정을 클릭하여 값을 편집합니다.
    2. 자동 업데이트를 활성화하려면 자동 업데이트를 선택합니다.
    3. 저장 을 선택하여 변경 사항을 커밋합니다.
    4. Operator에 자동 업데이트가 적용될 때까지 기다립니다. 업데이트는 선택한 채널의 최신 버전에 필요한 업데이트를 자동으로 추가합니다. 업데이트된 업데이트가 모두 완료되면 Upgrade Status 필드에 Up to date 가 표시됩니다.

      팁: MultiClusterHub 사용자 정의 리소스 업그레이드를 완료하는 데 최대 10분이 걸릴 수 있습니다. 다음 명령을 입력하여 업그레이드가 여전히 진행 중인지 확인할 수 있습니다.

      oc get mch

      업그레이드하는 동안 Status 필드에 Updating 이 표시됩니다. 업그레이드가 완료되면 Status 필드에 Running 이 표시됩니다.

  6. 업그레이드 상태가 최신이면 채널 필드에서 값을 클릭하여 편집합니다.
  7. 다음 사용 가능한 기능 릴리스에 대한 채널을 선택합니다. 더 이상 사용되지 않음: release-2.4release-2.3 채널에서는 업데이트를 받지 않습니다. 가져오려면 klusterlet Operator의 stable-2.0 채널을 2.5에 사용해야 합니다. 업그레이드할 때 채널을 건너뛸 수 없습니다. 예를 들어 2.2.z에서 2.4까지 버전을 건너뛸 수 없습니다.
  8. 저장 을 선택하여 변경 사항을 저장합니다.
  9. 자동 업그레이드가 완료될 때까지 기다립니다. 다음 기능 릴리스로 업그레이드하면 채널 내의 최신 패치 릴리스에 대한 업데이트가 배포됩니다.
  10. 이후 기능 릴리스로 업그레이드해야 하는 경우 운영자가 원하는 채널의 최신 수준에 도달할 때까지 7-9단계를 반복합니다. 최종 채널에 모든 패치 릴리스가 배포되었는지 확인합니다.
  11. 선택 사항: 채널 내의 향후 업데이트에 수동 승인이 필요한 경우 승인 설정을 Manual로 설정할 수 있습니다.

Red Hat Advanced Cluster Management는 선택한 채널의 최신 버전에서 실행되고 있습니다.

Operator 업그레이드에 대한 자세한 내용은 OpenShift Container Platform 설명서의 Operator 를 참조하십시오.

1.7.1. 업그레이드를 사용하여 클러스터 풀 관리

클러스터 풀(기술 프리뷰)을 관리하는 경우 업그레이드 후 이러한 클러스터 풀의 자동 관리를 중지하려면 추가 구성이 필요합니다.

ClusterClaim metadata.annotations에서 cluster.open-cluster-management.io/createmanagedcluster: "false" 를 설정합니다.

이 설정을 변경하지 않는 한 제품을 업그레이드하면 기존 클러스터 클레임이 모두 자동으로 가져옵니다.

1.8. OpenShift Container Platform 업그레이드

Kubernetes 허브 클러스터를 Red Hat Advanced Cluster Management를 호스팅하는 Red Hat OpenShift Container Platform 버전을 업그레이드할 수 있습니다. 클러스터 전체 업그레이드를 시작하기 전에 데이터를 백업하십시오.

OpenShift Container Platform 버전을 업그레이드하는 동안 페이지 또는 데이터를 사용할 수 없는 경우 Red Hat Advanced Cluster Management 웹 콘솔에 짧은 기간이 표시될 수 있습니다. 지표에는 HTTP 500 (Internal Server Error), HTTP 504 (Gateway Timeout Error) 또는 이전에 사용 가능한 데이터를 사용할 수 없는 오류가 포함될 수 있습니다. 이는 업그레이드의 정상적인 부분이며 이러한 상황이 발생하면 데이터가 손실되지 않습니다. 가용성은 결국 복원됩니다.

이 업그레이드 중에 검색 인덱스도 다시 빌드되므로 업그레이드 중에 제출된 쿼리가 불완전할 수 있습니다.

다음 표에는 OpenShift Container Platform 버전 4.4.3에서 4.4.10으로의 업그레이드에서 몇 가지 참고 사항이 설명되어 있습니다.

표 1.2. OpenShift Container Platform의 표 관찰은 버전 4.3.3에서 4.4.10으로 업그레이드됩니다.

업그레이드 프로세스 경과 시간(분:seconds)관찰된 변경기간

03:40

거버넌스 콘솔 경험 HTTP 500

20초 이내에 복원

05:30

AppUI 경험 HTTP 504 게이트웨이 시간 제한

60초 이내에 복원

06:05

클러스터 및 검색 콘솔 경험 HTTP 504 게이트웨이 시간 제한

20초 이내에 복원

07:00

클러스터 및 검색 콘솔 경험 HTTP 504 게이트웨이 시간 제한

20초 이내에 복원

07:10

토폴로지 및 클러스터 콘솔 페이지 내에 오류 메시지를 표시

20초 이내에 복원

07:35

대부분의 콘솔 페이지의 경우 HTTP 500

60초 이내에 복원

08:30

모든 페이지에 대해 복원된 서비스

 

1.9. 설치 제거

Kubernetes용 Red Hat Advanced Cluster Management를 설치 제거할 때 사용자 정의 리소스 제거 및 전체 Operator 설치 제거라는 두 가지 수준의 설치 제거 프로세스가 표시됩니다. 설치 제거 프로세스에는 최대 20분이 걸릴 수 있습니다.

  • 첫 번째 수준은 사용자 정의 리소스 제거로, MultiClusterHub 인스턴스의 사용자 정의 리소스를 제거하는 가장 기본적인 설치 제거 유형이지만 다른 필수 Operator 리소스를 남겨 둡니다. 이 설치 제거 수준은 동일한 설정 및 구성 요소를 사용하여 다시 설치하려는 경우 유용합니다.
  • 두 번째 수준은 사용자 정의 리소스 정의와 같은 구성 요소를 제외하고 대부분의 Operator 구성 요소를 제거하는 더 완전한 설치 제거입니다. 이 단계를 계속 수행하면 사용자 정의 리소스 제거로 제거되지 않은 모든 구성 요소와 서브스크립션이 제거됩니다. 이 제거 후 사용자 정의 리소스를 다시 설치하기 전에 Operator를 다시 설치해야 합니다.

1.9.1. 사전 요구 사항: Detach enabled services

Red Hat Advanced Cluster Management hub 클러스터를 설치 제거하기 전에 해당 허브 클러스터에서 관리하는 모든 클러스터를 분리해야 합니다. 오류를 해결하려면 hub 클러스터에서 계속 관리하는 모든 클러스터를 분리한 다음 제거를 다시 시도합니다.

  • Discovery를 사용하는 경우 제거를 시도할 때 다음 오류가 표시될 수 있습니다.

    Cannot delete MultiClusterHub resource because DiscoveryConfig resource(s) exist

    Discovery를 비활성화하려면 다음 단계를 완료합니다.

    • 콘솔에서 Discovered Clusters 테이블로 이동하여 클러스터 검색 비활성화 를 클릭합니다. 서비스를 제거할지 확인합니다.
    • 터미널을 사용할 수도 있습니다. 다음 명령을 실행하여 Discover를 비활성화합니다.
    $ oc delete discoveryconfigs --all --all-namespaces
  • 관리 클러스터가 연결된 경우 다음 메시지가 표시될 수 있습니다. 참고: 자체 관리 허브 클러스터인 로컬 클러스터는 포함되지 않습니다.

    Cannot delete MultiClusterHub resource because ManagedCluster resource(s) exist

    클러스터 분리에 대한 자세한 내용은 클러스터 생성에서 공급자에 대한 정보를 선택하여 관리에서 클러스터 제거 섹션을 참조하십시오.

  • 베어 메탈 자산이 있는 경우 다음이 표시될 수 있습니다.

    Cannot delete MultiClusterHub resource because BareMetalAssets resource(s) exist

    베어 메탈 자산 제거에 대한 자세한 내용은 베어 메탈 자산 제거를 참조하십시오.

  • 관찰 기능이 있는 경우 다음을 볼 수 있습니다.

    Cannot delete MultiClusterHub resource because MultiClusterObservability resource(s) exist
    • 터미널을 사용하여 MultiClusterObservability 를 비활성화하고 제거하려면 다음 절차를 참조하십시오.

      1. hub 클러스터에 로그인합니다.
      2. 다음 명령을 입력하여 MultiClusterObservability 사용자 정의 리소스를 삭제합니다.

        oc delete mco observability
    • 콘솔을 사용하여 MultiClusterObservability 사용자 정의 리소스를 제거하려면 다음 절차를 참조하십시오.

      1. MultiClusterObservability 사용자 정의 리소스가 설치된 경우 MultiClusterObservability 용으로 탭을 선택합니다.
      2. MultiClusterObservability 사용자 정의 리소스의 옵션 메뉴를 선택합니다.
      3. Delete MultiClusterObservability 를 선택합니다.

        리소스를 삭제하면 Red Hat Advanced Cluster Management hub 클러스터의 open-cluster-management-observability 네임스페이스의 Pod와 모든 관리 클러스터에서 open-cluster-management-addon-observability 네임스페이스의 Pod가 제거됩니다.

    참고: 관찰 서비스를 제거한 후 오브젝트 스토리지는 영향을 받지 않습니다.

1.9.2. 명령을 사용하여 리소스 제거

  1. 아직 없는 경우 OpenShift Container Platform CLI가 oc 명령을 실행하도록 구성되어 있는지 확인합니다. oc 명령을 구성하는 방법에 대한 자세한 내용은 OpenShift Container Platform 설명서에서 OpenShift CLI 시작하기 를 참조하십시오.
  2. 다음 명령을 입력하여 프로젝트 네임스페이스로 변경합니다. namespace 를 프로젝트 네임스페이스의 이름으로 변경합니다.

    oc project <namespace>
  3. 다음 명령을 입력하여 MultiClusterHub 사용자 정의 리소스를 제거합니다.

    oc delete multiclusterhub --all

    다음 명령을 입력하여 진행 상황을 볼 수 있습니다.

    oc get mch -o yaml
  4. 정리 스크립트를 실행하여 남아 있는 잠재적인 아티팩트를 제거합니다. 동일한 클러스터에서 이전 버전의 Red Hat Advanced Cluster Management로 다시 설치하려는 경우 이 정리 스크립트를 실행합니다.

    1. Helm 설치 지침에 따라 Helm CLI 바이너리 버전 3.2.0 이상을 설치합니다. https://helm.sh/docs/intro/install/
    2. 다음 스크립트를 파일에 복사합니다.

      #!/bin/bash
      ACM_NAMESPACE=<namespace>
      oc delete mch --all -n $ACM_NAMESPACE
      helm ls --namespace $ACM_NAMESPACE | cut -f 1 | tail -n +2 | xargs -n 1 helm delete --namespace $ACM_NAMESPACE
      oc delete apiservice v1beta2.webhook.certmanager.k8s.io v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io
      oc delete clusterimageset --all
      oc delete configmap -n $ACM_NAMESPACE cert-manager-controller cert-manager-cainjector-leader-election cert-manager-cainjector-leader-election-core
      oc delete consolelink acm-console-link
      oc delete crd klusterletaddonconfigs.agent.open-cluster-management.io placementbindings.policy.open-cluster-management.io policies.policy.open-cluster-management.io userpreferences.console.open-cluster-management.io searchservices.search.acm.com discoveredclusters.discovery.open-cluster-management.io discoveryconfigs.discovery.open-cluster-management.io
      oc delete mutatingwebhookconfiguration cert-manager-webhook cert-manager-webhook-v1alpha1 ocm-mutating-webhook managedclustermutators.admission.cluster.open-cluster-management.io
      oc delete oauthclient multicloudingress
      oc delete rolebinding -n kube-system cert-manager-webhook-webhook-authentication-reader
      oc delete scc kui-proxy-scc
      oc delete validatingwebhookconfiguration cert-manager-webhook cert-manager-webhook-v1alpha1 channels.apps.open.cluster.management.webhook.validator application-webhook-validator multiclusterhub-operator-validating-webhook ocm-validating-webhook

      스크립트의 & lt;namespace >를 Red Hat Advanced Cluster Management가 설치된 네임스페이스 이름으로 바꿉니다. 네임스페이스가 정리되고 삭제되므로 올바른 네임스페이스를 지정해야 합니다.

    3. 스크립트를 실행하여 이전 설치에서 남아 있는 가능한 모든 아티팩트를 제거합니다. 나머지 아티팩트가 없는 경우 리소스를 찾을 수 없다는 메시지가 반환됩니다.

      참고: 동일한 Red Hat Advanced Cluster Management 버전을 다시 설치하려는 경우 이 절차의 다음 단계를 건너뛰고 사용자 정의 리소스를 다시 설치할 수 있습니다. 전체 Operator 제거를 진행합니다.

  5. 다음 명령을 입력하여 설치된 네임스페이스에서 Red Hat Advanced Cluster Management ClusterServiceVersion서브스크립션을 삭제합니다.
❯ oc get csv
NAME                                 DISPLAY                                      VERSION   REPLACES   PHASE
advanced-cluster-management.v2.4.0   Advanced Cluster Management for Kubernetes   2.4.0                Succeeded

❯ oc delete clusterserviceversion advanced-cluster-management.v2.4.0

❯ oc get sub
NAME                        PACKAGE                       SOURCE                CHANNEL
acm-operator-subscription   advanced-cluster-management   acm-custom-registry   release-2.5

❯ oc delete sub acm-operator-subscription

참고: 서브스크립션 이름과 CSV 버전은 다를 수 있습니다.

1.9.3. 콘솔을 사용하여 구성 요소 삭제

Red Hat OpenShift Container Platform 콘솔을 사용하여 제거할 때 Operator를 제거합니다. 콘솔을 사용하여 설치 제거하려면 다음 단계를 완료합니다.

  1. OpenShift Container Platform 콘솔 탐색에서 Operator > 설치된 Operator > Kubernetes용 Advanced Cluster Manager를 선택합니다.
  2. MultiClusterHub 사용자 정의 리소스를 제거합니다.

    1. Multiclusterhub 탭을 선택합니다.
    2. MultiClusterHub 사용자 정의 리소스의 옵션 메뉴를 선택합니다.
    3. Delete MultiClusterHub 를 선택합니다.
  3. 명령을 사용하여 MultiClusterHub 인스턴스 제거 절차에 따라 정리 스크립트를 실행합니다.

    팁: 동일한 Red Hat Advanced Cluster Management 버전을 다시 설치하려는 경우 이 절차의 나머지 단계를 건너뛰고 사용자 정의 리소스를 다시 설치할 수 있습니다.

  4. 설치된 Operator로 이동합니다.
  5. 옵션 메뉴를 선택하고 Uninstall operator 를 선택하여 Red Hat Advanced Cluster Management Operator를 제거합니다.

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.