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

클러스터

Red Hat Advanced Cluster Management for Kubernetes 2.14

다중 클러스터 엔진 Operator 절차, 릴리스 노트 및 문제 해결 정보를 사용하여 클러스터 관리를 찾습니다. Red Hat Advanced Cluster Management 없이 다중 클러스터 엔진 Operator도 설치합니다.

초록

독립 실행형 다중 클러스터 엔진 Operator 설치 및 Red Hat Advanced Cluster Management 클러스터 관리 기능에 대한 정보를 찾습니다. 클러스터 생성, 클러스터 가져오기 등에 대해 알아보십시오.

멀티 클러스터 엔진 Operator는 OpenShift Container Platform 및 Red Hat Advanced Cluster Management Hub 클러스터에 대한 클러스터 관리 기능을 제공하는 클러스터 라이프사이클 Operator입니다. 허브 클러스터에서 클러스터를 생성 및 관리하고 생성한 클러스터를 제거할 수 있습니다. 또한 클러스터를 hibernate, 재개 및 분리할 수도 있습니다.

멀티 클러스터 엔진 Operator는 Red Hat OpenShift Container Platform 및 Red Hat Advanced Cluster Management Hub 클러스터를 위한 클러스터 관리 기능을 제공하는 클러스터 라이프사이클 Operator입니다. Red Hat Advanced Cluster Management를 설치한 경우 자동으로 설치되므로 다중 클러스터 엔진 Operator를 설치할 필요가 없습니다. 다중 클러스터 엔진 Operator가 있는 클러스터 라이프사이클에 대한 기타 중요한 정보를 참조하십시오.

1.1. 콘솔 개요
링크 복사

OpenShift Container Platform 콘솔 플러그인은 OpenShift Container Platform 웹 콘솔에서 사용할 수 있으며 통합할 수 있습니다. 이 기능을 사용하려면 콘솔 플러그인을 계속 활성화해야 합니다. 다중 클러스터 엔진 Operator는 인프라 및 인증 정보 탐색 항목의 특정 콘솔 기능을 표시합니다. Red Hat Advanced Cluster Management를 설치하는 경우 더 많은 콘솔 기능이 표시됩니다.

참고: 플러그인을 활성화하면 드롭다운 메뉴에서 모든 클러스터를 선택하여 클러스터 전환기에서 OpenShift Container Platform 콘솔 내에서 Red Hat Advanced Cluster Management에 액세스할 수 있습니다.

  1. 플러그인을 비활성화하려면 OpenShift Container Platform 콘솔의 관리자 화면에 있는지 확인합니다.
  2. 탐색에서 Administration 을 찾고 Cluster Settings 를 클릭한 다음 Configuration 탭을 클릭합니다.
  3. 구성 리소스 목록에서 웹 콘솔에 대한 클러스터 전체 구성이 포함된 operator.openshift.io API 그룹이 있는 Console 리소스를 클릭합니다.
  4. 콘솔 플러그인 탭을 클릭합니다. mce 플러그인이 나열됩니다. 참고: Red Hat Advanced Cluster Management가 설치된 경우 acm 로도 나열됩니다.
  5. 표에서 플러그인 상태를 수정합니다. 잠시 후 콘솔을 새로 고침하라는 메시지가 표시됩니다.

1.2. 다중 클러스터 엔진 Operator 역할 기반 액세스 제어
링크 복사

RBAC는 콘솔 수준 및 API 수준에서 검증됩니다. 콘솔의 작업은 사용자 액세스 역할 권한에 따라 활성화하거나 비활성화할 수 있습니다. 제품의 특정 라이프사이클에 대한 RBAC에 대한 자세한 내용은 다음 섹션을 참조하십시오.

1.2.1. 역할 개요
링크 복사

일부 제품 리소스는 클러스터 전체이며 일부는 네임스페이스 범위입니다. 일관된 액세스 제어를 위해 사용자에게 클러스터 역할 바인딩 및 네임스페이스 역할 바인딩을 적용해야 합니다. 지원되는 다음 역할 정의의 표 목록을 확인합니다.

1.2.1.1. 역할 정의 표
링크 복사
Expand
Role정의

cluster-admin

OpenShift Container Platform 기본 역할입니다. cluster-admin 역할에 클러스터 바인딩이 있는 사용자는 모든 액세스 권한이 있는 OpenShift Container Platform 슈퍼 사용자입니다.

open-cluster-management:cluster-manager-admin

open-cluster-management:cluster-manager-admin 역할에 대한 클러스터 바인딩이 있는 사용자는 모든 액세스 권한이 있는 슈퍼유저입니다. 이 역할을 사용하면 ManagedCluster 리소스를 생성할 수 있습니다.

open-cluster-management:admin:<managed_cluster_name>

open-cluster-management:admin:<managed_cluster_name> 역할에 대한 클러스터 바인딩 사용자는 < managed_cluster_name >이라는 ManagedCluster 리소스에 대한 관리자 액세스 권한이 있습니다. 사용자에게 관리 클러스터가 있으면 이 역할이 자동으로 생성됩니다.

open-cluster-management:view:<managed_cluster_name>

open-cluster-management:view:<managed_cluster_name> 역할에 대한 클러스터 바인딩 사용자는 < managed_cluster_name >이라는 ManagedCluster 리소스에 대한 보기 액세스 권한이 있습니다.

open-cluster-management:managedclusterset:admin:<managed_clusterset_name>

open-cluster-management:managedclusterset:admin:<managed_clusterset_name> 역할에 대한 클러스터 바인딩 사용자는 <managed_ clusterset _name >이라는 ManagedCluster 리소스에 대한 관리자 액세스 권한이 있습니다. 또한 사용자는 관리 클러스터 설정 레이블이 cluster.open-cluster-management.io ,clusterclaim.hive.openshift.io, clusterdeployment.hive.openshift.io 및 clusterset=< managed_clusterset_name >에 대한 관리자 액세스 권한도 있습니다. 클러스터 세트를 사용하는 경우 역할 바인딩이 자동으로 생성됩니다. 리소스 를 관리하는 방법을 알아보려면 ManagedClusterSet생성 을 참조하십시오.

open-cluster-management:managedclusterset:view:<managed_clusterset_name>

open-cluster-management:managedclusterset:view:<managed_clusterset_name > 역할에 대한 클러스터 바인딩 사용자는 <managed_clusterset_name>'이라는 ManagedCluster 리소스에 대한 보기 액세스 권한이 있습니다. 또한 사용자는 관리 클러스터 설정 라벨이 cluster.open-cluster-management.io,clusterclaim. hive.openshift.io,clusterdeployment.hive.openshift.io 및 clusterpool.hive.openshift.io 에 대한 보기 액세스 권한도 있습니다. cluster.open-cluster-management.io , clusterset=<managed_clusterset_name > . 관리 클러스터 세트 리소스를 관리하는 방법에 대한 자세한 내용은 ManagedClusterSet생성을 참조하십시오.

관리자, 편집, 보기

admin, edit, view는 OpenShift Container Platform 기본 역할입니다. 이러한 역할에 대한 네임스페이스 범위 바인딩이 있는 사용자는 특정 네임스페이스의 open-cluster-management 리소스에 액세스할 수 있지만 동일한 역할에 대한 클러스터 전체 바인딩은 클러스터 전체에서 모든 오픈 클러스터 관리 리소스에 액세스할 수 있습니다.

중요:

  • 모든 사용자는 OpenShift Container Platform에서 프로젝트를 생성할 수 있으므로 네임스페이스에 대한 관리자 역할 권한이 부여됩니다.
  • 사용자에게 클러스터에 대한 역할 액세스 권한이 없는 경우 클러스터 이름이 표시되지 않습니다. 클러스터 이름은 다음 기호와 함께 표시됩니다. -.

RBAC는 콘솔 수준 및 API 수준에서 검증됩니다. 콘솔의 작업은 사용자 액세스 역할 권한에 따라 활성화하거나 비활성화할 수 있습니다. 제품의 특정 라이프사이클에 대한 RBAC에 대한 자세한 내용은 다음 섹션을 참조하십시오.

1.2.2. 클러스터 라이프사이클 RBAC
링크 복사

다음 클러스터 라이프사이클 RBAC 작업을 확인합니다.

  • 모든 관리 클러스터에 대한 클러스터 역할 바인딩을 생성하고 관리합니다. 예를 들어 다음 명령을 입력하여 클러스터 역할 open-cluster-management:cluster-manager-admin 에 대한 클러스터 역할 바인딩을 생성합니다. 

    oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:cluster-manager-admin --user=<username>
    Copy to Clipboard Toggle word wrap

    이 역할은 모든 리소스 및 작업에 액세스할 수 있는 슈퍼유저입니다. 클러스터 범위의 관리 클러스터 리소스, 관리 클러스터를 관리하는 리소스의 네임스페이스, 이 역할이 있는 네임스페이스의 리소스를 생성할 수 있습니다. 권한 오류를 방지하기 위해 역할 연결이 필요한 ID의 사용자 이름을 추가해야 할 수 있습니다.

  • 다음 명령을 실행하여 cluster-name 이라는 관리 클러스터의 클러스터 역할 바인딩을 관리합니다. 

    oc create clusterrolebinding (role-binding-name) --clusterrole=open-cluster-management:admin:<cluster-name> --user=<username>
    Copy to Clipboard Toggle word wrap

    이 역할에는 클러스터 범위의 managedcluster 리소스에 대한 읽기 및 쓰기 권한이 있습니다. 이는 managedcluster 가 네임스페이스 범위 리소스가 아닌 클러스터 범위 리소스이므로 필요합니다.

    • 다음 명령을 입력하여 클러스터 역할 admin 에 대한 네임스페이스 역할 바인딩을 생성합니다. 

      oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=admin --user=<username>
      Copy to Clipboard Toggle word wrap

      이 역할에는 관리 클러스터의 네임스페이스의 리소스에 대한 읽기 및 쓰기 권한이 있습니다.

  • open-cluster-management:view:<cluster-name > 클러스터 역할에 대한 클러스터 역할 바인딩을 생성하여 cluster-name 이라는 관리 클러스터를 확인합니다. 

    oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:view:<cluster-name> --user=<username>
    Copy to Clipboard Toggle word wrap

    이 역할은 클러스터 범위의 managedcluster 리소스에 대한 읽기 액세스 권한이 있습니다. 이는 managedcluster 가 클러스터 범위 리소스이므로 필요합니다.

  • 다음 명령을 입력하여 클러스터 역할 뷰에 대한 네임스페이스 역할 바인딩을 생성합니다. 

    oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=view --user=<username>
    Copy to Clipboard Toggle word wrap

    이 역할에는 관리 클러스터의 네임스페이스의 리소스에 대한 읽기 전용 권한이 있습니다.

  • 다음 명령을 입력하여 액세스할 수 있는 관리 클러스터 목록을 확인합니다. 

    oc get managedclusters.clusterview.open-cluster-management.io
    Copy to Clipboard Toggle word wrap

    이 명령은 클러스터 관리자 권한이 없는 관리자와 사용자가 사용합니다.

  • 다음 명령을 입력하여 액세스할 수 있는 관리 클러스터 세트 목록을 확인합니다. 

    oc get managedclustersets.clusterview.open-cluster-management.io
    Copy to Clipboard Toggle word wrap

    이 명령은 클러스터 관리자 권한이 없는 관리자와 사용자가 사용합니다.

1.2.2.1. 클러스터 풀 RBAC
링크 복사

다음 클러스터 풀 RBAC 작업을 확인합니다.

  • 클러스터 관리자는 관리 클러스터 세트를 생성하고 그룹에 역할을 추가하여 관리자 권한을 부여하여 클러스터 풀 프로비저닝 클러스터를 사용합니다. 다음 예제를 확인합니다.

    • 다음 명령을 사용하여 server-foundation-clusterset 관리 클러스터 세트에 관리자 권한을 부여합니다. 

      oc adm policy add-cluster-role-to-group open-cluster-management:clusterset-admin:server-foundation-clusterset
server-foundation-team-admin
      Copy to Clipboard Toggle word wrap

    • 다음 명령을 사용하여 server-foundation-clusterset 관리 클러스터 세트에 보기 권한을 부여합니다. 

      oc adm policy add-cluster-role-to-group open-cluster-management:clusterset-view:server-foundation-clusterset server-foundation-team-user
      Copy to Clipboard Toggle word wrap

  • 클러스터 풀 server-foundation-clusterpool 의 네임스페이스를 만듭니다. 역할 권한을 부여하려면 다음 예제를 확인합니다.

    • 다음 명령을 실행하여 server-foundation- team- admin 에 대한 관리자 권한을 server-foundation- clusterpool 에 부여합니다. 

      oc adm new-project server-foundation-clusterpool

oc adm policy add-role-to-group admin server-foundation-team-admin --namespace  server-foundation-clusterpool
      Copy to Clipboard Toggle word wrap

  • 팀 관리자로 클러스터 세트 레이블 cluster.open-cluster-management.io/clusterset=server-foundation-clusterset 를 사용하여 ocp46-aws-clusterpool 이라는 클러스터 풀을 생성합니다.

    • server-foundation-webhook 는 클러스터 풀에 클러스터 세트 레이블이 있는지, 사용자가 클러스터 세트에 클러스터 풀을 생성할 수 있는 권한이 있는지 확인합니다.
    • server-foundation-controller 는 server-foundation-team-user 의 server-foundation-clusterpool 네임스페이스에 대한 보기 권한을 부여합니다.

  • 클러스터 풀이 생성되면 클러스터 풀이 클러스터 배포를 생성합니다. 자세한 내용은 계속 읽으십시오.

    • server-foundation-controller 는 server-foundation-team- admin 의 clusterdeployment 네임스페이스에 대한 관리자 권한을 부여합니다.

    • server-foundation-controller 는 server-foundation-team-user 에 대한 보기 권한 클러스터 배포 네임스페이스를 부여합니다.

      참고: team-admin 및 team-user 로 clusterpool,clusterdeployment, clusterclaim 에 대한 관리자 권한이 있습니다.

1.2.2.2. 클러스터 라이프사이클을 위한 콘솔 및 API RBAC 테이블
링크 복사

클러스터 라이프사이클에 대해 다음 콘솔 및 API RBAC 테이블을 확인합니다.

Expand
표 1.1. 클러스터 라이프사이클에 대한 콘솔 RBAC 테이블
리소스관리자편집view

클러스터

읽기, 업데이트, 삭제

-

읽기

클러스터 세트

get, update, bind, join

언급되지 않은 편집 역할

get

관리형 클러스터

읽기, 업데이트, 삭제

언급된 편집 역할 없음

get

공급자 연결

생성, 읽기, 업데이트 및 삭제

-

읽기

Expand
표 1.2. 클러스터 라이프사이클을 위한 API RBAC 테이블
API관리자편집view

managedclusters.cluster.open-cluster-management.io

이 API의 명령에 mcl (singular) 또는 m cl(plural)을 사용할 수 있습니다.

생성, 읽기, 업데이트, 삭제

읽기, 업데이트

읽기

managedclusters.view.open-cluster-management.io

이 API의 명령에서 mcv (singular) 또는 mcvs (plural)를 사용할 수 있습니다.

읽기

읽기

읽기

managedclusters.register.open-cluster-management.io/accept

업데이트

업데이트

 

managedclusterset.cluster.open-cluster-management.io

이 API의 명령에 mclset (singular) 또는 mclsets (plural)를 사용할 수 있습니다.

생성, 읽기, 업데이트, 삭제

읽기, 업데이트

읽기

managedclustersets.view.open-cluster-management.io

읽기

읽기

읽기

managedclustersetbinding.cluster.open-cluster-management.io

이 API의 명령에 mclsetbinding (singular) 또는 mclsetbindings (plural)를 사용할 수 있습니다.

생성, 읽기, 업데이트, 삭제

읽기, 업데이트

읽기

klusterletaddonconfigs.agent.open-cluster-management.io

생성, 읽기, 업데이트, 삭제

읽기, 업데이트

읽기

managedclusteractions.action.open-cluster-management.io

생성, 읽기, 업데이트, 삭제

읽기, 업데이트

읽기

managedclusterviews.view.open-cluster-management.io

생성, 읽기, 업데이트, 삭제

읽기, 업데이트

읽기

managedclusterinfos.internal.open-cluster-management.io

생성, 읽기, 업데이트, 삭제

읽기, 업데이트

읽기

manifestworks.work.open-cluster-management.io

생성, 읽기, 업데이트, 삭제

읽기, 업데이트

읽기

submarinerconfigs.submarineraddon.open-cluster-management.io

생성, 읽기, 업데이트, 삭제

읽기, 업데이트

읽기

placements.cluster.open-cluster-management.io

생성, 읽기, 업데이트, 삭제

읽기, 업데이트

읽기

1.2.2.3. 인증 정보 역할 기반 액세스 제어
링크 복사

인증 정보에 대한 액세스는 Kubernetes에서 제어합니다. 인증 정보는 Kubernetes 시크릿으로 저장되고 보호됩니다. 다음 권한은 Red Hat Advanced Cluster Management for Kubernetes의 보안에 적용됩니다.

  • 네임스페이스에서 보안을 생성할 수 있는 액세스 권한이 있는 사용자는 인증 정보를 생성할 수 있습니다.
  • 네임스페이스에서 시크릿 읽기에 대한 액세스 권한이 있는 사용자는 인증 정보를 볼 수도 있습니다.
  • admin 의 Kubernetes 클러스터 역할이 있는 사용자는 시크릿을 생성하고 편집할 수 있습니다.
  • Kubernetes 클러스터 역할의 사용자는 시크릿 내용을 읽을 수 없으므로 시크릿을 볼 수 없습니다. 서비스 계정 자격 증명에 액세스할 수 있기 때문입니다.

1.3. 네트워크 구성
링크 복사

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

중요: 신뢰할 수 있는 CA 번들은 다중 클러스터 엔진 Operator 네임스페이스에서 사용할 수 있지만 이를 개선하려면 네트워크를 변경해야 합니다. 신뢰할 수 있는 CA 번들 ConfigMap은 기본 이름 trusted-ca-bundle 을 사용합니다. TRUSTED_CA_BUNDLE 이라는 환경 변수에 Operator에 제공하여 이 이름을 변경할 수 있습니다. 자세한 내용은 Red Hat OpenShift Container Platform의 네트워킹 섹션에서 클러스터 전체 프록시 구성 을 참조하십시오.

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

Expand
표 1.3. 네트워킹 요구 사항 표 목록
방향소스대상프로토콜포트설명

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

hub 클러스터의 Hive 및 import-controller

프로비저닝된 관리형 클러스터의 Kubernetes API 서버

HTTPS

6443

프로비저닝된 관리형 클러스터의 Kubernetes API 서버

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

hub 클러스터의 Ironic 서비스

관리 클러스터의 Ironic Python Agent

TCP

9999

Ironic Python Agent가 실행 중인 베어 메탈 노드와 Ironic conductor 서비스 간의 통신

관리 클러스터에서 인바운드

BMC(Baseboard Management Controller)

Ironic 서비스 옆에 있는 HTTP 서버

TCP

6180, 6183

BMC(Baseboard Management Controller)는 가상 미디어의 경우 포트 6180 및 6183에 액세스합니다. 부팅 펌웨어가 포트 6180에 액세스

관리 클러스터에서 인바운드

관리 클러스터의 Ironic Python Agent

hub 클러스터의 Ironic 서비스

TCP

6385

hub 클러스터에서 Ironic Python Agent와 Ironic 서비스 간 통신

관리 클러스터에서 인바운드

관리 클러스터의 클러스터 프록시 애드온 에이전트

클러스터 프록시 ANP 서비스

TCP

443

관리 클러스터의 클러스터 프록시 애드온 에이전트와 허브 클러스터의 Cluster Proxy 애드온 ANP 서비스 간 통신

관리 클러스터에서 인바운드

Klusterlet 에이전트 및 애드온 에이전트

허브 클러스터의 Kubernetes API 서버

HTTPS

6443

관리 클러스터의 다중 클러스터 엔진 Operator 클러스터의 Kubernetes API 서버

참고: 관리 클러스터의 klusterlet 에이전트에 직접 연결하는 대신 hub 클러스터의 apiserver 설정에 액세스해야 하는 경우 허브 클러스터와 관리 클러스터 간의 프록시 구성 을 참조하십시오.

다중 클러스터 엔진 Operator가 있는 클러스터 라이프사이클의 새로운 기능 및 개선 사항, 지원, 사용 중단, 제거 및 수정된 문제에 대해 알아보십시오.

중요: OpenShift Container Platform 릴리스 노트는 이 제품 문서에 포함되어 있지 않습니다. OpenShift Container Platform 클러스터의 경우 OpenShift Container Platform 릴리스 노트를 참조하십시오.

더 이상 사용되지 않음: 다중 클러스터 엔진 Operator 2.4 및 이전 버전은 더 이상 지원되지 않습니다. 문서는 사용할 수 있지만 수정된 문제 또는 기타 업데이트에 대한 에라타 릴리스는 없습니다.

모범 사례: 최신 버전으로 업그레이드합니다.

Kubernetes operator 2.9의 새로운 기능 및 개선 사항, 지원, 사용 중단, 제거 및 에라타 릴리스의 수정된 문제에 대해 설명합니다.

멀티 클러스터 엔진 Operator 버전 2.9는 클러스터 라이프사이클 관리를 위해 Red Hat Advanced Cluster Management 버전 2.14와 함께 릴리스되지만 OpenShift Container Platform Hub 클러스터와 함께 독립형 다중 클러스터 엔진 Operator도 사용할 수 있습니다.

지원되는 OpenShift Container Platform 버전을 포함한 전체 지원 정보는 다중 클러스터 엔진 Operator 지원 매트릭스 를 참조하십시오. 라이프 사이클 정보는 Red Hat OpenShift Container Platform 라이프 사이클 정책을 참조하십시오.

다중 클러스터 엔진 Operator 기능을 사용하여 다양한 인프라 클라우드 공급자, 프라이빗 클라우드 및 온프레미스 데이터 센터에서 Kubernetes 클러스터를 생성, 가져오기, 관리 및 제거합니다.

중요:

  • 클러스터 관리는 CCNCF(Cloud Native Computing Foundation) Kubernetes 적합성 프로그램을 통해 인증된 모든 공급자를 지원합니다. 하이브리드 클라우드 멀티 클러스터 관리를 위해 CNFC에서 인식하는 공급 업체를 선택합니다. CNFC 공급자 사용에 대한 다음 정보를 참조하십시오.
  • CNFC 공급자가 인증된 Kubernetes 적합성에서 인증 하는 방법을 알아보십시오.
  • CNFC 타사 공급자에 대한 Red Hat 지원 정보는 타사 구성 요소와의 Red Hat 지원 또는 Red Hat 지원 문의 를 참조하십시오.
  • 자체 CNFC 적합성 인증 클러스터를 가져오는 경우 OpenShift Container Platform CLI oc 명령을 Kubernetes CLI 명령 kubectl 로 변경해야 합니다.
1.4.1.1. 각 구성 요소에 대한 새로운 기능 및 개선 사항
링크 복사

특정 구성 요소의 새로운 기능에 대해 자세히 알아보십시오.

참고: 일부 기능 및 구성 요소는 기술 프리뷰로 확인 및 릴리스됩니다.

중요: OpenShift Container Platform 설명서의 호스팅된 컨트롤 플레인 은 OpenShift Container Platform 설명서에 있습니다. 호스팅 컨트롤 플레인 개요 를 참조하십시오.

다중 클러스터 엔진 Operator 설치와 함께 제공되는 새로운 기능 및 개선 사항에 대해 알아보십시오.

  • 이제 로컬 클러스터의 이름을 변경할 수 있습니다. 기본적으로 다중 클러스터 엔진 Operator를 실행 중인 클러스터는 자체적으로 관리하는 허브 클러스터인 로컬 클러스터입니다. 활성화된 필드가 false 로 설정되어 로컬 클러스터 기능을 비활성화하면 이름을 변경할 수 있습니다. < your-local-cluster-name > 값에 34개 이하의 문자를 사용합니다. local-cluster 리소스와 네임스페이스는 변경 사항을 반영합니다.

다중 클러스터 엔진 Operator가 있는 클러스터 라이프사이클의 새로운 기능 및 개선 사항에 대해 알아보십시오.

  • 이제 cluster-api 구성 요소를 다중 클러스터 엔진 Operator 설치 중에 일반적으로 사용할 수 있으므로 관리형 클러스터 내에서 클러스터 API 라이프사이클에 사용할 수 있습니다. cluster-api-provider-aws 는 일반적으로 설치 중에 호스팅되는 컨트롤 플레인을 통해 AWS의 Red Hat OpenShift Service에 대한 클러스터 생성, 구성 및 관리를 위해 Kubernetes 스타일 API를 제공합니다. 두 구성 요소는 기본적으로 비활성화되어 있습니다.
  • metal3 인프라 공급자와 OpenShift Container Platform 지원 부트스트랩 및 컨트롤 플레인 공급자를 사용하여 클러스터 API로 OpenShift Container Platform 관리 클러스터를 설치할 수 있습니다. 클러스터 API를 사용하여 관리 클러스터 설치를 참조하십시오.
  • hub 클러스터 사용자 토큰을 사용하여 kube-apiserver 리소스에 액세스하여 특정 리소스를 수집하고, 로그를 가져오고, 데이터를 볼 수 있습니다. 자세한 내용은 hub 클러스터 사용자 토큰을 사용하여 데이터 수집을 참조하십시오.
  • 이제 격리된 레지스트리 구성이 필요한 다중 클러스터 환경에서 각 클러스터에 대한 고유한 미러 레지스트리를 정의할 수 있습니다. 자세한 내용은 각 클러스터의 미러 레지스트리 구성을 참조하십시오.
  • 관리 클러스터를 일회성 프로세스에 대해 ImportOnly 로 자동 가져오기 또는 연속 프로세스의 경우 ImportAndSync 로 사용자 지정합니다. 자세한 내용은 자동 가져오기 전략 사용자 지정을 참조하십시오.
  • 이제 중앙 인프라 관리를 활성화할 때 OSImageCACert ConfigMap 에 모든 파일 이름을 사용할 수 있습니다. 자세한 내용은 연결이 끊긴 환경에서 중앙 인프라 관리 활성화를 참조하십시오.

Red Hat Advanced Cluster Management가 설치된 다중 클러스터 엔진 Operator를 사용하는 경우 이번 릴리스에서는 Red Hat Advanced Cluster Management의 새로운 기능 및 개선 사항을 참조하십시오.

기본적으로 에라타 릴리스의 수정된 문제는 릴리스될 때 자동으로 적용됩니다. 자세한 내용은 릴리스가 릴리스될 때 여기에 게시됩니다. 나열된 릴리스 정보가 없는 경우 현재 제품에 에라타 릴리스가 없습니다.

중요: 참조를 위해 Jira 링크 및 Jira 번호가 콘텐츠에 추가되고 내부적으로 사용될 수 있습니다. 액세스가 필요한 링크는 사용자에게 제공되지 않을 수 있습니다. Red Hat의 에라타 유형에 대해 알아보십시오.

이 릴리스에 대해 다중 클러스터 엔진 Operator가 있는 클러스터 라이프사이클 의 알려진 문제 또는 이전 릴리스에서 계속되는 알려진 문제를 검토하십시오.

클러스터 관리 알려진 문제 및 제한 사항은 다중 클러스터 엔진 Operator 문서가 있는 클러스터 라이프사이클 의 일부입니다. Red Hat Advanced Cluster Management 와 통합된 다중 클러스터 엔진 Operator의 알려진 문제는 Red Hat Advanced Cluster Management의 릴리스 노트에 설명되어 있습니다.

중요: OpenShift Container Platform 릴리스 노트는 이 제품 문서에 포함되어 있지 않습니다. OpenShift Container Platform 클러스터의 경우 OpenShift Container Platform 릴리스 노트를 참조하십시오.

1.4.3.1. 설치
링크 복사

다중 클러스터 엔진 Operator 설치 중에 알려진 문제 및 제한 사항에 대해 알아봅니다.

1.4.3.1.1. installNamespace 필드에는 하나의 값만 있을 수 있습니다.
링크 복사

managed-serviceaccount 애드온을 활성화할 때 ManagedClusterAddOn 리소스의 installNamespace 필드에 값으로 open-cluster-management-agent-addon 이 있어야 합니다. 다른 값은 무시됩니다. managed-serviceaccount 애드온 에이전트는 항상 관리 클러스터의 open-cluster-management-agent-addon 네임스페이스에 배포됩니다.

1.4.3.2. 클러스터 관리
링크 복사

멀티 클러스터 엔진 Operator 생성, 검색, 가져오기 및 제거 문제 및 다중 클러스터 엔진 Operator의 클러스터 관리 문제 등 다중 클러스터 엔진 Operator의 알려진 문제에 대해 알아봅니다.

1.4.3.2.1. cluster-api-provider-aws webhooks 블록 호스팅 컨트롤 플레인 배포
링크 복사

OpenShift Container Platform의 호스트된 컨트롤 플레인은 cluster-api-provider-aws 리소스와 hypershift - local-hosting 구성 요소에서 설치한 하이퍼shift 리소스 간의 API 충돌로 인해 AWS에서 인프라 리소스를 관리할 수 없습니다.

AWS 플랫폼 호스팅 클러스터에 hypershift 구성 요소를 사용하려면 기본적으로 enabled: false 로 설정된 cluster-api 및 cluster-api-provider-aws 구성 요소를 활성화 하지 마십시오. 구성 요소가 비활성화된 다음 기본 설정을 참조하십시오. 

      - configOverrides: {}
        enabled: false
        name: cluster-api
      - configOverrides: {}
        enabled: false
        name: cluster-api-provider-aws
Copy to Clipboard Toggle word wrap

다음 YAML 샘플에서와 같이 hypershift-local-hosting 이 활성화된 경우 이전 구성 요소가 활성화되지 않았는지 확인합니다. 

      - configOverrides: {}
        enabled: true
        name: hypershift-local-hosting
Copy to Clipboard Toggle word wrap

인프라 노드에 NoExecute 효과가 있는 node-role.kubernetes.io/infra 테인트를 사용하는 경우 애드온 Pod가 중단될 수 있습니다.

이 문제를 해결하려면 node-role.kubernetes.io/infra 테인트에 NoExecute 대신 NoSchedule 효과를 사용하거나 인프라 노드에서 node-role.kubernetes.io/infra 테인트를 제거합니다.

1.4.3.2.3. nmstate로 제한
링크 복사

복사 및 붙여넣기 기능을 구성하여 더 빠르게 개발하십시오. assisted-installer 에서 copy-from-mac 기능을 구성하려면 nmstate 정의 인터페이스 및 mac-mapping 인터페이스에 mac-address 를 추가해야 합니다. mac-mapping 인터페이스는 nmstate 정의 인터페이스 외부에 제공됩니다. 따라서 동일한 mac-address 를 두 번 제공해야 합니다.

ManagedClusterSet 을 삭제한 후 클러스터를 클러스터 세트에 연결하는 각 관리 클러스터에 추가된 레이블은 자동으로 제거되지 않습니다. 삭제된 관리 클러스터 세트에 포함된 각 관리 클러스터에서 레이블을 수동으로 제거합니다. 레이블은 cluster.open-cluster-management.io/clusterset:<ManagedClusterSet Name> 과 유사합니다.

1.4.3.2.5. ClusterClaim 오류
링크 복사

ClusterPool 에 대해 Hive ClusterClaim 을 생성하고 ClusterClaimspec 라이프 사이클 필드를 잘못된 golang 시간 값으로 수동으로 설정하는 경우 제품은 잘못된 형식의 클레임뿐만 아니라 모든 ClusterClaims 이행 및 재조정을 중지합니다.

poolName 및 invalid lifetime 이 포함된 특정 예인 clusterclaim-controller Pod 로그에 다음 오류가 표시됩니다. 

E0203 07:10:38.266841       1 reflector.go:138] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:224: Failed to watch *v1.ClusterClaim: failed to list *v1.ClusterClaim: v1.ClusterClaimList.Items: []v1.ClusterClaim: v1.ClusterClaim.v1.ClusterClaim.Spec: v1.ClusterClaimSpec.Lifetime: unmarshalerDecoder: time: unknown unit "w" in duration "1w", error found in #10 byte of ...|time":"1w"}},{"apiVe|..., bigger context ...|clusterPoolName":"policy-aas-hubs","lifetime":"1w"}},{"apiVersion":"hive.openshift.io/v1","kind":"Cl|...
Copy to Clipboard Toggle word wrap

유효하지 않은 클레임을 삭제할 수 있습니다.

잘못된 클레임이 삭제되면 클레임이 추가 상호 작용 없이 성공적으로 조정되기 시작합니다.

1.4.3.2.6. 제품 채널이 프로비저닝된 클러스터와 동기화되지 않음
링크 복사

clusterimageset 은 fast 채널이지만 프로비저닝된 클러스터는 stable 채널에 있습니다. 현재 제품은 채널을 프로비저닝된 OpenShift Container Platform 클러스터와 동기화하지 않습니다.

OpenShift Container Platform 콘솔에서 올바른 채널로 변경합니다. Administration > Cluster Settings > Details Channel 을 클릭합니다.

관리 클러스터를 자동으로 프로비저닝하도록 구성된 자동화 템플릿은 다음 두 조건이 충족되면 실패할 수 있습니다.

  • hub 클러스터에는 클러스터 전체 프록시가 활성화되어 있습니다.
  • Ansible Automation Platform은 프록시를 통해서만 연결할 수 있습니다.

관리 클러스터의 네임스페이스를 수동으로 삭제할 수 없습니다. 관리형 클러스터 네임스페이스는 관리 클러스터를 분리한 후 자동으로 삭제됩니다. 관리 클러스터가 분리되기 전에 관리 클러스터 네임스페이스를 수동으로 삭제하는 경우 관리 클러스터에 관리 클러스터를 삭제한 후 지속적인 종료 상태가 표시됩니다. 이 종료 관리 클러스터를 삭제하려면 분리된 관리 클러스터에서 종료자를 수동으로 제거합니다.

클라우드 공급자 측에서 클라우드 공급자 액세스 키를 변경하는 경우 다중 클러스터 엔진 Operator 콘솔에서 이 클라우드 공급자에 대한 해당 인증 정보도 업데이트해야 합니다. 이는 관리 클러스터가 호스팅되는 클라우드 공급자에서 인증 정보가 만료되고 관리 클러스터를 삭제하려고 할 때 필요합니다.

1.4.3.2.10. 클러스터 제거 프로세스가 완료되지 않음
링크 복사

관리 클러스터를 삭제하면 1시간 후에도 상태가 계속 Destroying 으로 표시되고 클러스터가 삭제되지 않습니다. 이 문제를 해결하려면 다음 단계를 완료합니다.

  1. 클라우드에 고립된 리소스가 없고 관리 클러스터와 연결된 모든 공급자 리소스가 정리되었는지 수동으로 확인합니다.

  2. 다음 명령을 입력하여 제거 중인 관리 클러스터의 ClusterDeployment 정보를 엽니다. 

    oc edit clusterdeployment/<mycluster> -n <namespace>
    Copy to Clipboard Toggle word wrap

    mycluster 를 제거하려는 관리 클러스터의 이름으로 바꿉니다.

    namespace 를 관리 클러스터의 네임스페이스로 바꿉니다.

  3. hive.openshift.io/deprovision 종료자를 제거하여 클라우드에서 클러스터 리소스를 정리하려는 프로세스를 강제로 중지합니다.
  4. 변경 사항을 저장하고 ClusterDeployment 이 사라졌는지 확인합니다.

  5. 다음 명령을 실행하여 관리 클러스터의 네임스페이스를 수동으로 제거합니다. 

    oc delete ns <namespace>
    Copy to Clipboard Toggle word wrap

    namespace 를 관리 클러스터의 네임스페이스로 바꿉니다.

Red Hat Advanced Cluster Management 콘솔을 사용하여 OpenShift Container Platform Dedicated 환경에 있는 OpenShift Container Platform 관리 클러스터를 업그레이드할 수 없습니다.

ManagedServiceAccount 및 클러스터 프록시 애드온은 Red Hat Advanced Cluster Management 버전 2.10 이상에서 기본적으로 활성화됩니다. 업그레이드 후 애드온이 비활성화된 경우 Pod 로그 기능을 사용하려면 ManagedServiceAccount 및 클러스터 프록시 애드온을 수동으로 활성화해야 합니다.

ManagedServiceAccount를 활성화하는 방법을 알아보고 클러스터 프록시 애드온을 활성화하는 방법을 알아보려면 ManagedServiceAccount 애드온을 참조하십시오.

1.4.3.2.13. 클라이언트가 iPXE 스크립트에 연결할 수 없음
링크 복사

iPXE는 오픈 소스 네트워크 부팅 펌웨어입니다. 자세한 내용은 iPXE 를 참조하십시오.

노드를 부팅할 때 일부 DHCP 서버의 URL 길이 제한이 InfraEnv 사용자 정의 리소스 정의의 ipxeScript URL을 차단하여 콘솔에 다음과 같은 오류 메시지가 표시됩니다.

부팅 가능한 장치 없음

이 문제를 해결하려면 다음 단계를 완료하십시오.

  1. 지원 설치를 사용할 때 다음 파일과 유사할 수 있는 bootArtifacts 를 노출할 때 InfraEnv 사용자 정의 리소스 정의를 적용합니다. 
status:
  agentLabelSelector:
    matchLabels:
      infraenvs.agent-install.openshift.io: qe2
  bootArtifacts:
    initrd: https://assisted-image-service-multicluster-engine.redhat.com/images/0000/pxe-initrd?api_key=0000000&arch=x86_64&version=4.11
    ipxeScript: https://assisted-service-multicluster-engine.redhat.com/api/assisted-install/v2/infra-envs/00000/downloads/files?api_key=000000000&file_name=ipxe-script
    kernel: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.12/latest/rhcos-live-kernel-x86_64
    rootfs: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.12/latest/rhcos-live-rootfs.x86_64.img
Copy to Clipboard Toggle word wrap
  1. 짧은 URL로 bootArtifacts 를 노출하는 프록시 서버를 생성합니다.

  2. bootArtifacts 를 복사하여 다음 명령을 실행하여 프록시에 추가합니다. 

    for artifact in oc get infraenv qe2 -ojsonpath="{.status.bootArtifacts}" | jq ". | keys[]" | sed "s/\"//g"
do curl -k oc get infraenv qe2 -ojsonpath="{.status.bootArtifacts.${artifact}}"` -o $artifact
    Copy to Clipboard Toggle word wrap
  3. libvirt.xml 의 bootp 매개변수에 ipxeScript 아티팩트 프록시 URL을 추가합니다.

Red Hat Advanced Cluster Management 2.6에서 삭제된 BareMetalAssets API를 사용하는 경우 BareMetalAssets API가 ClusterDeployment 에 바인딩되어 있으므로 Red Hat Advanced Cluster Management 2.7로 업그레이드한 후 ClusterDeployment 을 삭제할 수 없습니다.

이 문제를 해결하려면 Red Hat Advanced Cluster Management 2.7로 업그레이드하기 전에 종료자 를 제거하려면 다음 명령을 실행합니다. 

oc patch clusterdeployment <clusterdeployment-name> -p '{"metadata":{"finalizers":null}}' --type=merge
Copy to Clipboard Toggle word wrap
1.4.3.2.15. ManagedClusterSet API 사양 제한
링크 복사

Clustersets API 를 사용하는 경우 selectorType: LaberSelector 설정은 지원되지 않습니다. selectorType: ExclusiveClusterSetLabel 설정이 지원됩니다.

ClusterCurator 리소스를 사용하여 OpenShift Container Platform Dedicated 클러스터를 업그레이드하면 클러스터 큐레이터가 OpenShift Container Platform Dedicated 클러스터를 지원하지 않기 때문에 업그레이드가 실패합니다.

1.4.3.2.17. 사용자 정의 수신 도메인이 올바르게 적용되지 않음
링크 복사

관리형 클러스터를 설치하는 동안 ClusterDeployment 리소스를 사용하여 사용자 정의 인그레스 도메인을 지정할 수 있지만, SyncSet 리소스를 사용하여 설치 후에만 변경 사항을 적용합니다. 결과적으로 clusterdeployment.yaml 파일의 spec 필드에 사용자가 지정한 Ingress 도메인이 표시되지만 상태는 여전히 기본 도메인을 표시합니다.

1.4.3.2.18. ManagedClusterAddon 상태가 고정됨
링크 복사

ManagedClusterAddon 에서 구성을 정의하여 ClusterManagementAddon 의 일부 구성을 재정의하면 ManagedClusterAddon 이 다음 상태로 고정될 수 있습니다. 

progressing... mca and work configs mismatch
Copy to Clipboard Toggle word wrap

ManagedClusterAddon 상태를 확인할 때 구성의 일부에는 구성이 있더라도 빈 사양 해시가 있습니다. 다음 예제를 참조하십시오. 

status:
  conditions:
  - lastTransitionTime: "20xx-09-09T16:08:42Z"
    message: progressing... mca and work configs mismatch
    reason: Progressing
    status: "True"
    type: Progressing
...
  configReferences:
  - desiredConfig:
      name: deploy-config
      namespace: open-cluster-management-hub
      specHash: b81380f1f1a1920388d90859a5d51f5521cecd77752755ba05ece495f551ebd0
    group: addon.open-cluster-management.io
    lastObservedGeneration: 1
    name: deploy-config
    namespace: open-cluster-management-hub
    resource: addondeploymentconfigs
  - desiredConfig:
      name: cluster-proxy
      specHash: ""
    group: proxy.open-cluster-management.io
    lastObservedGeneration: 1
    name: cluster-proxy
    resource: managedproxyconfigurations
Copy to Clipboard Toggle word wrap

문제를 해결하려면 다음 명령을 실행하여 ManagedClusterAddon 을 다시 설치하고 복구하여 ManagedClusterAddon 을 삭제합니다. &lt ;cluster-name&gt;을 ManagedClusterAddon 네임스페이스로 바꿉니다. & lt;addon-name& gt;을 ManagedClusterAddon 이름으로 바꿉니다. 

oc -n <cluster-name> delete managedclusteraddon <addon-name>
Copy to Clipboard Toggle word wrap

MultiClusterEngine 및 MultiClusterHub 리소스에 구성된 tolerations 및 nodeSelector 설정은 로컬 클러스터에 배포된 관리-serviceaccount 에이전트에 영향을 미치지 않습니다. 로컬 클러스터에서 managed-serviceaccount 애드온이 항상 필요한 것은 아닙니다.

managed-serviceaccount 애드온이 필요한 경우 다음 단계를 완료하여 문제를 해결할 수 있습니다.

  1. addonDeploymentConfig 사용자 정의 리소스를 생성합니다.
  2. 로컬 클러스터 및 managed-serviceaccount 에이전트의 tolerations 및 nodeSelector 값을 설정합니다.
  3. 생성한 addonDeploymentConfig 사용자 정의 리소스를 사용하도록 로컬 클러스터 네임스페이스에서 managed-serviceaccount ManagedClusterAddon 을 업데이트합니다.

addonDeploymentConfig 사용자 정의 리소스를 사용하여 애드온 허용 오차 및 nodeSelector 를 구성하는 방법에 대한 자세한 내용은 klusterlet 애드온 구성을 참조하십시오.

1.4.3.3. 중앙 인프라 관리
링크 복사

4.19 이전 Red Hat OpenShift Container Platform 버전으로 단일 노드 OpenShift 클러스터를 설치하려면 InfraEnv 사용자 정의 리소스 및 부팅된 호스트에서 단일 노드 OpenShift 클러스터를 설치하기 위해 사용 중인 동일한 OpenShift Container Platform 버전을 사용해야 합니다. 버전이 일치하지 않으면 설치에 실패합니다.

이 문제를 해결하려면 Discovery ISO로 호스트를 부팅하고 다음 콘텐츠를 포함하기 전에 InfraEnv 리소스를 편집합니다. & lt;4.x >를 설치하려는 osImageVersion 으로 바꿉니다. 

apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
spec:
  osImageVersion: "<4.x>"
Copy to Clipboard Toggle word wrap

검색 이미지로 부팅하고 호스트를 자동으로 추가하기 위해 호스트 인벤토리 또는 InfraEnv 사용자 정의 리소스를 사용할 수 없습니다. BareMetalHost 리소스에 이전 InfraEnv 리소스를 사용한 후 이미지를 직접 부팅하려는 경우 새 InfraEnv 리소스를 생성하여 문제를 해결할 수 있습니다.

1.4.3.3.3. BareMetalHost 리소스를 제거한 후 노드 종료
링크 복사

hub 클러스터에서 BareMetalHost 리소스를 제거하면 노드가 종료됩니다. 노드의 전원을 수동으로 다시 켜면 됩니다.

제품의 일부가 다중 클러스터 엔진 Operator에서 더 이상 사용되지 않거나 제거되는 시기를 알아봅니다. 현재 릴리스와 두 개의 이전 릴리스의 테이블에 표시되는 권장 작업 및 세부 사항의 대체 작업을 고려하십시오. 이 릴리스에 대한 항목이 추가되지 않으면 테이블이 제거됩니다.

더 이상 사용되지 않음: 다중 클러스터 엔진 Operator 2.4 및 이전 버전은 더 이상 지원되지 않습니다. 문서는 사용할 수 있지만 수정된 문제 또는 기타 업데이트에 대한 에라타 릴리스는 없습니다.

모범 사례: 최신 버전으로 업그레이드합니다.

1.4.4.1. 제품 사용 중단 및 제거
링크 복사

더 이상 사용되지 않는 구성 요소, 기능 또는 서비스가 지원되지만 더 이상 사용하지 않는 것은 권장되지 않으며 향후 릴리스에서 더 이상 사용되지 않을 수 있습니다. 권장 작업 및 다음 표에 제공되는 세부 사항의 대체 작업을 고려하십시오.

Expand
표 1.4. 다중 클러스터 엔진 Operator에 대해 더 이상 사용되지 않는 항목의 표 목록
제품 또는 카테고리영향을 받는 항목버전권장 작업자세한 내용 및 링크

API 설명서

다중 클러스터 엔진 Operator API 문서

다중 클러스터 엔진 operator 2.8

문서 대신 콘솔 또는 터미널에서 현재 및 지원되는 API 보기

없음

KlusterletConfig

hubKubeAPIServerProxyConfig 필드는 KlusterletConfig 사양에서 더 이상 사용되지 않습니다.

2.7

hubKubeAPIServerConfig.proxyURL 및 hubKubeAPIServerConfig.trustedCABundles 필드를 사용합니다.

없음

KlusterletConfig

hubKubeAPIServerURL 필드는 KlusterletConfig 사양에서 더 이상 사용되지 않습니다.

2.7

hubKubeAPIServerConfig.url 필드를 사용합니다.

없음

KlusterletConfig

KlusterletConfig 사양에서 hubKubeAPIServerCABundle 필드가 더 이상 사용되지 않음

2.7

hubKubeAPIServerConfig.serverVerificationStrategy 및 hubKubeAPIServerConfig.trustedCABundles 필드를 사용합니다.

없음

삭제된 항목은 일반적으로 이전 릴리스에서 더 이상 사용되지 않으며 제품에서 더 이상 사용할 수 없는 기능입니다. 제거된 함수에 대한 대안을 사용해야 합니다. 권장 작업 및 다음 표에 제공되는 세부 사항의 대체 작업을 고려하십시오.

Expand
표 1.5. 다중 클러스터 엔진 Operator에 대해 제거된 항목의 표 목록
제품 또는 카테고리영향을 받는 항목버전권장 작업자세한 내용 및 링크

클러스터 라이프사이클

auto-import-secret.yaml의 autoImportRetry 필드

2.9

없음

없음

클러스터 라이프사이클

Red Hat Virtualization에서 클러스터 생성

2.6

없음

없음

클러스터 라이프사이클

Klusterlet Operator Lifecycle Manager Operator

2.6

없음

없음

1.5. 다중 클러스터 엔진 Operator 설치 및 업그레이드
링크 복사

다중 클러스터 엔진 Operator는 클러스터 플릿 관리를 개선하는 소프트웨어 운영자입니다. 멀티 클러스터 엔진 Operator는 클라우드 및 데이터 센터 전체에서 Red Hat OpenShift Container Platform 및 Kubernetes 클러스터 라이프사이클 관리를 지원합니다.

이 문서는 특정 구성 요소 또는 기능이 도입되어 최신 버전의 OpenShift Container Platform에서만 테스트되지 않는 한 가장 빨리 지원되는 OpenShift Container Platform 버전을 참조합니다.

전체 지원 정보는 다중 클러스터 엔진 Operator 지원 매트릭스 를 참조하십시오. 라이프 사이클 정보는 Red Hat OpenShift Container Platform 라이프 사이클 정책을 참조하십시오.

중요: Red Hat Advanced Cluster Management를 사용하는 경우 Kubernetes Operator를 위한 다중 클러스터 엔진이 클러스터에 이미 설치되어 있습니다.

더 이상 사용되지 않음: 다중 클러스터 엔진 Operator 2.4 및 이전 버전은 더 이상 지원되지 않습니다. 문서는 사용할 수 있지만 수정된 문제 또는 기타 업데이트에 대한 에라타 릴리스는 없습니다.

모범 사례: 최신 버전으로 업그레이드합니다.

다음 설명서를 참조하십시오.

1.5.1. 온라인으로 연결하는 동안 설치
링크 복사

다중 클러스터 엔진 Operator는 다중 클러스터 엔진 Operator를 포함하는 구성 요소의 설치, 업그레이드 및 제거를 관리하는 Operator Lifecycle Manager와 함께 설치됩니다.

필수 액세스: 클러스터 관리자

중요:

  • 외부 클러스터에 구성된 ManagedCluster 리소스가 있는 클러스터에 다중 클러스터 엔진 Operator를 설치할 수 없습니다. 다중 클러스터 엔진 Operator를 설치하려면 먼저 외부 클러스터에서 ManagedCluster 리소스를 제거해야 합니다.
  • OpenShift Container Platform Dedicated 환경의 경우 cluster-admin 권한이 있어야 합니다. 기본적으로 dedicated-admin 역할에는 OpenShift Container Platform Dedicated 환경에서 네임스페이스를 생성하는 데 필요한 권한이 없습니다.
  • 기본적으로 다중 클러스터 엔진 Operator 구성 요소는 추가 구성없이 OpenShift Container Platform 클러스터의 작업자 노드에 설치됩니다. OpenShift Container Platform OperatorHub 웹 콘솔 인터페이스를 사용하거나 OpenShift Container Platform CLI를 사용하여 다중 클러스터 엔진 Operator를 작업자 노드에 설치할 수 있습니다.
  • 인프라 노드를 사용하여 OpenShift Container Platform 클러스터를 구성하는 경우 추가 리소스 매개변수와 함께 OpenShift Container Platform CLI를 사용하여 다중 클러스터 엔진 Operator를 해당 인프라 노드에 설치할 수 있습니다. 자세한 내용은 인프라 노드에 다중 클러스터 엔진 설치 섹션을 참조하십시오.

  • OpenShift Container Platform 또는 다중 클러스터 엔진 Operator에서 생성하지 않은 Kubernetes 클러스터를 가져오려면 이미지 가져오기 보안을 구성해야 합니다. 이미지 풀 시크릿 및 기타 고급 구성을 구성하는 방법에 대한 자세한 내용은 이 문서의 고급 구성 섹션의 옵션을 참조하십시오.

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

다중 클러스터 엔진 Operator를 설치하기 전에 다음 사전 요구 사항을 참조하십시오.

  • OpenShift Container Platform 클러스터는 콘솔에서 OperatorHub 카탈로그의 다중 클러스터 엔진 Operator에 액세스할 수 있어야 합니다.
  • catalog.redhat.com 에 액세스해야 합니다.
  • 클러스터에 외부 클러스터에 구성된 ManagedCluster 리소스가 없습니다.

  • 지원되는 OpenShift Container Platform 버전은 환경에 배포해야 하며 OpenShift Container Platform CLI로 로그인해야 합니다. 다음 설치 설명서를 참조하십시오.

  • oc 명령을 실행하도록 OpenShift Container Platform CLI(명령줄 인터페이스)를 구성해야 합니다. OpenShift Container Platform CLI 설치 및 구성에 대한 정보는 CLI로 시작하기 를 참조하십시오.
  • OpenShift Container Platform 권한에서 네임스페이스를 생성할 수 있어야 합니다.
  • Operator의 종속 항목에 액세스하려면 인터넷 연결이 있어야 합니다.

  • OpenShift Container Platform Dedicated 환경에 설치하려면 다음을 참조하십시오.

    • OpenShift Container Platform Dedicated 환경이 구성되어 실행되고 있어야 합니다.
    • 엔진을 설치하는 OpenShift Container Platform Dedicated 환경에 대한 cluster-admin 권한이 있어야 합니다.
  • Red Hat OpenShift Container Platform과 함께 제공되는 지원 설치 관리자를 사용하여 관리 클러스터를 생성하려면 요구 사항에 대한 OpenShift Container Platform 설명서의 지원 설치 관리자 준비를 참조하십시오.
1.5.1.2. OpenShift Container Platform 설치 확인
링크 복사

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

  1. 다중 클러스터 엔진 Operator가 OpenShift Container Platform 클러스터에 아직 설치되지 않았는지 확인합니다. 다중 클러스터 엔진 Operator는 각 OpenShift Container Platform 클러스터에서 하나의 단일 설치만 허용합니다. 설치가 없는 경우 다음 단계를 계속 진행합니다.

  2. OpenShift Container Platform 클러스터가 올바르게 설정되었는지 확인하려면 다음 명령을 사용하여 OpenShift Container Platform 웹 콘솔에 액세스합니다. 

    kubectl -n openshift-console get route console
    Copy to Clipboard Toggle word wrap

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

    console console-openshift-console.apps.new-coral.purple-chesterfield.com
console   https   reencrypt/Redirect     None
    Copy to Clipboard Toggle word wrap
  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.

다중 클러스터 엔진 Operator 설치를 진행할 수 있습니다.

1.5.1.3. OperatorHub 웹 콘솔 인터페이스에서 설치
링크 복사

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

  1. Operator > OperatorHub 를 선택하여 사용 가능한 Operator 목록에 액세스하고 Kubernetes Operator의 다중 클러스터 엔진을 선택합니다.
  2. 설치를 클릭합니다.

  3. Operator 설치 페이지에서 설치 옵션을 선택합니다.

    • namespace:

      • 다중 클러스터 엔진 Operator 엔진은 자체 네임스페이스 또는 프로젝트에 설치해야 합니다.
      • 기본적으로 OperatorHub 콘솔 설치 프로세스는 multicluster-engine 이라는 네임스페이스를 생성합니다. 모범 사례: 사용 가능한 경우 multicluster-engine 네임스페이스를 계속 사용합니다.
      • 이미 multicluster-engine 이라는 네임스페이스가 있는 경우 다른 네임스페이스를 선택합니다.
    • 채널: 선택한 채널은 설치 중인 릴리스에 해당합니다. 채널을 선택하면 식별된 릴리스를 설치하고 해당 릴리스 내에서 향후 에라타가 업데이트되도록 설정합니다.

    • 승인 전략: 승인 전략은 서브스크립션한 채널 또는 릴리스에 업데이트를 적용하는 데 필요한 인적 상호 작용을 식별합니다.

      • 기본적으로 선택한 자동 을 선택하여 해당 릴리스 내의 업데이트가 자동으로 적용되도록 합니다.
      • 업데이트를 사용할 수 있을 때 알림을 받으려면 수동 을 선택합니다. 업데이트가 적용되는 시기에 대해 우려 사항이 있는 경우 이 방법을 사용하는 것이 좋습니다.

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

  4. 설치를 선택하여 변경 사항을 적용하고 Operator를 생성합니다.

  5. MultiClusterEngine 사용자 정의 리소스를 생성하려면 다음 프로세스를 참조하십시오.

    1. OpenShift Container Platform 콘솔 탐색에서 Installed Operators > multicluster engine for Kubernetes 를 선택합니다.
    2. MultiCluster Engine 탭을 선택합니다.
    3. Create MultiClusterEngine 을 선택합니다.

    4. YAML 파일에서 기본값을 업데이트합니다. 문서의 MultiClusterEngine 고급 구성 섹션의 옵션을 참조하십시오.

      • 다음 예제에서는 편집기에 복사할 수 있는 기본 템플릿을 보여줍니다. 
      apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec: {}
      Copy to Clipboard Toggle word wrap

  6. 생성 을 선택하여 사용자 지정 리소스를 초기화합니다. 다중 클러스터 엔진 Operator 엔진을 빌드하고 시작하는 데 최대 10분이 걸릴 수 있습니다.

    MultiClusterEngine 리소스가 생성되면 MultiCluster Engine 탭에서 리소스 상태가 Available (사용 가능)입니다.

1.5.1.4. OpenShift Container Platform CLI에서 설치
링크 복사

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

    oc create namespace <namespace>
    Copy to Clipboard Toggle word wrap

  2. 프로젝트 네임스페이스를 생성한 네임스페이스로 전환합니다. 1단계에서 생성한 Kubernetes Operator 네임스페이스의 다중 클러스터 엔진 이름으로 namespace 를 바꿉니다. 

    oc project <namespace>
    Copy to Clipboard Toggle word wrap

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

    apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: <default>
  namespace: <namespace>
spec:
  targetNamespaces:
  - <namespace>
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 OperatorGroup 리소스를 생성합니다. operator-group 을 생성한 operator 그룹 YAML 파일의 이름으로 교체합니다. 

    oc apply -f <path-to-file>/<operator-group>.yaml
    Copy to Clipboard Toggle word wrap

  5. YAML 파일을 생성하여 OpenShift Container Platform 서브스크립션을 구성합니다. 파일이 다음 예제와 유사하게 표시되고 < stable-2.x >가 사용 중인 지원되는 버전을 나타내도록 변경되었습니다. 

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: multicluster-engine
spec:
  sourceNamespace: openshift-marketplace
  source: redhat-operators
  channel: stable-2.x
  installPlanApproval: Automatic
  name: multicluster-engine
    Copy to Clipboard Toggle word wrap

    참고: 인프라 노드를 구성하려면 다중 클러스터 엔진 Operator를 위한 인프라 노드 구성 을 참조하십시오.

=

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

+ 

oc apply -f <path-to-file>/<subscription>.yaml
Copy to Clipboard Toggle word wrap

  1. YAML 파일을 생성하여 MultiClusterEngine 사용자 정의 리소스를 구성합니다. 기본 템플릿은 다음 예와 유사해야 합니다. 

    apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec: {}
    Copy to Clipboard Toggle word wrap

    참고: 인프라 노드에 다중 클러스터 엔진 Operator를 설치하는 경우 MultiClusterEngine 사용자 정의 리소스 추가 구성 섹션을 참조하십시오.

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

    oc apply -f <path-to-file>/<custom-resource>.yaml
    Copy to Clipboard Toggle word wrap

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

    error: unable to recognize "./mce.yaml": no matches for kind "MultiClusterEngine" in version "operator.multicluster-engine.io/v1"
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 사용자 정의 리소스를 가져옵니다. 다음 명령을 실행한 후 MultiClusterEngine 사용자 정의 리소스 상태가 Available 으로 Available로 표시되는 데 최대 10분이 걸릴 수 있습니다 . 

    oc get mce -o=jsonpath='{.items[0].status.phase}'
    Copy to Clipboard Toggle word wrap

다중 클러스터 엔진 Operator를 다시 설치하고 Pod가 시작되지 않는 경우 이 문제를 해결하기 위한 단계의 재생성 문제 해결을 참조하십시오.

참고:

  • ClusterRoleBinding 이 있는 ServiceAccount 는 다중 클러스터 엔진 Operator 및 다중 클러스터 엔진 Operator를 설치하는 네임스페이스에 대한 액세스 권한이 있는 모든 사용자 인증 정보에 자동으로 클러스터 관리자 권한을 부여합니다.

이제 승인된 관리 구성 요소를 실행하기 위해 인프라 노드를 포함하도록 OpenShift Container Platform 클러스터를 구성할 수 있습니다. 인프라 노드에서 구성 요소를 실행하면 해당 관리 구성 요소를 실행하는 노드에 OpenShift Container Platform 서브스크립션 할당량이 할당되지 않습니다. 해당 절차 를 위해 다중 클러스터 엔진 Operator의 인프라 노드 구성 을 참조하십시오.

1.5.2. 다중 클러스터 엔진 Operator를 위한 인프라 노드 구성
링크 복사

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

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

1.5.2.1. OpenShift Container Platform 클러스터에 인프라 노드 구성
링크 복사

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

다중 클러스터 엔진 Operator에서 제공하는 인프라 노드 활성화와의 호환성을 위해 인프라 노드에 다음과 같은 테인트 및 라벨이 적용되었는지 확인합니다. 

metadata:
  labels:
    node-role.kubernetes.io/infra: ""
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/infra
Copy to Clipboard Toggle word wrap
1.5.2.2. Operator Lifecycle Manager 서브스크립션 구성
링크 복사

Operator Lifecycle Manager 서브스크립션을 구성합니다.

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

    spec:
  config:
    nodeSelector:
      node-role.kubernetes.io/infra: ""
    tolerations:
    - key: node-role.kubernetes.io/infra
      effect: NoSchedule
      operator: Exists
    Copy to Clipboard Toggle word wrap

  2. 다음 노드 선택기 및 허용 오차를 포함하도록 모든 애드온을 업데이트합니다. klusterlet 애드온 구성 지침을 사용해야 합니다. 

        nodeSelector:
      node-role.kubernetes.io/infra: ""
    tolerations:
    - key: node-role.kubernetes.io/infra
      effect: NoSchedule
      operator: Exists
    Copy to Clipboard Toggle word wrap
  3. Red Hat OpenShift Data Foundation을 스토리지 프로비저너로 사용한 경우 Container Storage Interface Pod가 인프라 노드에서 실행될 수 있는지 확인합니다. Red Hat OpenShift Data Foundation 설명서에서 CSI(Container Storage Interface) 구성 요소 배치 관리에 대해 자세히 알아보십시오.
1.5.2.3. MultiClusterEngine 사용자 정의 리소스 추가 구성
링크 복사

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

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

1.5.3. 연결이 끊긴 네트워크에 설치
링크 복사

인터넷에 연결되지 않은 Red Hat OpenShift Container Platform 클러스터에 다중 클러스터 엔진 Operator를 설치해야 할 수 있습니다. 연결이 끊긴 엔진에 설치하려면 연결된 설치와 동일한 단계가 필요합니다.

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

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

다중 클러스터 엔진 Operator를 설치하기 전에 다음 요구 사항을 충족해야 합니다.

  • 지원되는 OpenShift Container Platform 버전은 환경에 배포해야 하며 CLI(명령줄 인터페이스)로 로그인해야 합니다.

  • catalog.redhat.com 에 액세스해야 합니다.

    참고: 베어 메탈 클러스터를 관리하려면 지원되는 OpenShift Container Platform 버전이 필요합니다.

    OpenShift Container Platform 설치를 참조하십시오.

  • Red Hat OpenShift Container Platform 권한에서 네임스페이스를 생성할 수 있도록 허용해야 합니다.
  • Operator에 대한 종속성을 다운로드하려면 인터넷 연결이 있는 워크스테이션이 있어야 합니다.
1.5.3.2. OpenShift Container Platform 설치 확인
링크 복사
  • 레지스트리 및 스토리지 서비스를 포함하여 지원되는 OpenShift Container Platform 버전이 클러스터에 설치되어 작동해야 합니다. OpenShift Container Platform에 대한 자세한 내용은 OpenShift Container Platform 설명서를 참조하십시오.

  • 연결된 경우 다음 명령을 사용하여 OpenShift Container Platform 웹 콘솔에 액세스하여 확인합니다. 

    oc -n openshift-console get route console
    Copy to Clipboard Toggle word wrap

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

    console console-openshift-console.apps.new-name.purple-name.com
console   https   reencrypt/Redirect     None
    Copy to Clipboard Toggle word wrap

    이 예제의 콘솔 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 값을 설정합니다.

1.5.3.3. 연결이 끊긴 환경에 설치
링크 복사

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

다음 단계에 따라 연결이 끊긴 환경에 다중 클러스터 엔진 Operator를 설치합니다.

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

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

  2. 참고: 베어 메탈의 경우 install-config.yaml 파일에서 연결이 끊긴 레지스트리에 대한 인증서 정보를 제공해야 합니다. 보호된 연결이 끊긴 레지스트리에서 이미지에 액세스하려면 다중 클러스터 엔진 운영자가 레지스트리에 액세스할 수 있도록 인증서 정보를 제공해야 합니다.

    1. 레지스트리에서 인증서 정보를 복사합니다.
    2. 편집기에서 install-config.yaml 파일을 엽니다.
    3. additionalTrustBundle: | 의 항목을 찾습니다.

    4. additionalTrustBundle 줄 뒤에 인증서 정보를 추가합니다. 결과 콘텐츠는 다음 예와 유사해야 합니다. 

      additionalTrustBundle: |
  -----BEGIN CERTIFICATE-----
  certificate_content
  -----END CERTIFICATE-----
sshKey: >-
      Copy to Clipboard Toggle word wrap

  3. 선택 사항: 설치 후 호스트에 액세스할 수 있도록 하나 이상의 SSH 공개 키를 지정할 수 있습니다. 다음 예제를 참조하십시오. 

    sshKey: |
  ssh-rsa <public-key-1>
  ssh-rsa <public-key-2>
  ssh-rsa <public-key-3>
    Copy to Clipboard Toggle word wrap

  4. 중요: 다음 Governance 정책이 필요한 경우 연결이 끊긴 이미지 레지스트리에 대한 추가 미러가 필요합니다.

    • Container Security Operator 정책: registry.redhat.io/quay 소스의 이미지를 찾습니다.
    • Compliance Operator 정책: registry.redhat.io/compliance 소스의 이미지를 찾습니다.

    • Gatekeeper Operator 정책: registry.redhat.io/gatekeeper 소스에 이미지를 찾습니다.

      세 가지 연산자 모두에 대한 미러 목록의 다음 예제를 참조하십시오. 

        - 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
    Copy to Clipboard Toggle word wrap
  5. install-config.yaml 파일을 저장합니다.

  6. mce-policy.yaml 이라는 이름으로 ImageContentSourcePolicy 가 포함된 YAML 파일을 생성합니다. 참고: 실행 중인 클러스터에서 이 값을 수정하면 모든 노드가 롤링 재시작됩니다. 

    apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: mce-repo
spec:
  repositoryDigestMirrors:
  - mirrors:
    - mirror.registry.com:5000/multicluster-engine
    source: registry.redhat.io/multicluster-engine
    Copy to Clipboard Toggle word wrap

  7. 다음 명령을 입력하여 ImageContentSourcePolicy 파일을 적용합니다. 

    oc apply -f mce-policy.yaml
    Copy to Clipboard Toggle word wrap

  8. 연결이 끊긴 Operator Lifecycle Manager Red Hat Operator 및 Community Operator를 활성화합니다.

    멀티 클러스터 엔진 Operator는 Operator Lifecycle Manager Red Hat Operator 카탈로그에 포함되어 있습니다.

  9. Red Hat Operator 카탈로그에 대해 연결이 끊긴 Operator Lifecycle Manager를 구성합니다. Red Hat OpenShift Container Platform 설명서의 제한된 네트워크에서 Operator Lifecycle Manager 사용 주제의 단계를 따르십시오.
  10. Operator Lifecycle Manager 카탈로그에서 Kubernetes용 다중 클러스터 엔진 Operator를 계속 설치합니다.

필요한 단계는 온라인에 연결된 동안 설치를 참조하십시오.

1.5.4. 정책을 사용하여 연결이 끊긴 클러스터 업그레이드
링크 복사

MultiClusterHub Operator를 사용하여 허브 클러스터 구성 요소를 관리, 업그레이드 및 설치하는 Red Hat Advanced Cluster Management for Kubernetes Hub 클러스터가 있는 경우 Red Hat Advanced Cluster Management 정책과 함께 OpenShift Update Service를 사용하여 연결이 끊긴 환경에서 여러 클러스터를 업그레이드할 수 있습니다.

OpenShift Update Service는 관리 클러스터의 사용 가능한 버전을 모니터링하고 연결이 끊긴 환경에서 업그레이드할 수 있도록 하는 별도의 Operator 및 피연산자입니다. OpenShift Update Service는 다음 작업을 수행할 수 있습니다.

외부 레지스트리 CA 인증서에 대한 자세한 내용은 OpenShift Container Platform 설명서의 이미지 레지스트리 액세스에 대한 추가 신뢰 저장소 구성 을 참조하십시오.

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

OpenShift Update Service를 사용하여 연결이 끊긴 클러스터를 업그레이드하려면 다음 사전 요구 사항이 있어야 합니다.

  • Red Hat Advanced Cluster Management를 설치해야 합니다. Red Hat Advanced Cluster Management 설치 및 업그레이드 설명서를 참조하십시오.
  • 제한된 OLM이 구성된 지원되는 Red Hat OpenShift Container Platform 버전에서 실행 중인 허브 클러스터가 필요합니다. 제한된 OLM 을 구성하는 방법에 대한 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오. 제한된 OLM을 구성할 때 카탈로그 소스 이미지를 기록해 두십시오.
  • hub 클러스터에서 관리하는 OpenShift Container Platform 클러스터가 필요합니다.

  • 클러스터 이미지를 미러링할 수 있는 로컬 저장소에 대한 액세스 인증 정보가 필요합니다. 자세한 내용은 연결이 끊긴 환경에서 미러링 을 참조하십시오.

    참고: 업그레이드한 클러스터의 현재 버전의 이미지를 미러링된 이미지 중 하나로 계속 사용할 수 있어야 합니다. 업그레이드에 실패하면 클러스터에서 업그레이드하려고 할 때 클러스터 버전으로 되돌아갑니다.

1.5.4.2. 연결이 끊긴 미러 레지스트리 준비
링크 복사

업그레이드할 이미지와 로컬 미러 레지스트리로 업그레이드할 현재 이미지를 모두 미러링해야 합니다.

이미지를 미러링하려면 다음 단계를 완료합니다.

  1. 다음 예제와 유사한 콘텐츠로 스크립트 파일을 생성합니다. & lt;pull-secret& gt;을 OpenShift Container Platform 풀 시크릿의 경로로 바꿉니다. 

    UPSTREAM_REGISTRY=quay.io
PRODUCT_REPO=openshift-release-dev
RELEASE_NAME=ocp-release
OCP_RELEASE=4.17.2-x86_64
LOCAL_REGISTRY=$(hostname):5000
LOCAL_SECRET_JSON=<pull-secret>

oc adm -a ${LOCAL_SECRET_JSON} release mirror \
--from=${UPSTREAM_REGISTRY}/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE} \
--to=${LOCAL_REGISTRY}/ocp4 \
--to-release-image=${LOCAL_REGISTRY}/ocp4/release:${OCP_RELEASE}
    Copy to Clipboard Toggle word wrap
  2. 스크립트를 실행하여 이미지를 미러링하고, 설정을 구성하고, 릴리스 이미지와 릴리스 콘텐츠를 분리합니다.
1.5.4.3. OpenShift Update Service용 Operator 배포
링크 복사

OpenShift Container Platform 환경에서 OpenShift Update Service용 Operator를 배포하려면 다음 단계를 완료하십시오.

  1. 허브 클러스터에서 OpenShift Container Platform Operator 허브에 액세스합니다.
  2. OpenShift Update Service Operator 를 선택하여 Operator를 배포하고 필요한 경우 기본값을 업데이트합니다. Operator 배포는 openshift-update-service 라는 새 프로젝트를 생성합니다.
  3. Operator 설치가 완료될 때까지 기다립니다.

oc get pods 명령을 실행하여 설치 상태를 확인할 수 있습니다. Operator가 running 상태인지 확인합니다.

1.5.4.4. 그래프 데이터 init 컨테이너 빌드
링크 복사

OpenShift Update Service는 그래프 데이터 정보를 사용하여 사용 가능한 업그레이드를 찾습니다. 연결된 환경에서 OpenShift Update Service는 update-service 그래프 데이터 GitHub 리포지토리에서 직접 업그레이드할 수 있는 그래프 데이터 정보를 가져옵니다.

연결이 끊긴 환경에서는 init 컨테이너 를 사용하여 로컬 리포지토리에서 그래프 데이터를 사용할 수 있도록 설정해야 합니다.

그래프 데이터 init 컨테이너 를 생성하려면 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 그래프 데이터 Git 리포지토리를 복제합니다. 

    git clone https://github.com/openshift/cincinnati-graph-data
    Copy to Clipboard Toggle word wrap

  2. 그래프 데이터 init 에 대한 정보가 포함된 파일을 생성합니다. cincinnati-operator GitHub 리포지토리에서 샘플 Dockerfile 을 찾을 수 있습니다.

    • FROM 값은 OpenShift Update Service가 이미지를 찾는 외부 레지스트리입니다.
    • RUN 명령은 디렉터리를 생성하고 업그레이드 파일을 패키징합니다.
    • CMD 명령은 패키지 파일을 로컬 리포지토리에 복사하고 업그레이드를 위해 파일을 추출합니다.

  3. 다음 명령을 실행하여 그래프 데이터 init 컨테이너 를 빌드합니다. 

    podman build -f <docker-path> -t <graph-path>:latest
    Copy to Clipboard Toggle word wrap

    & lt;docker-path >를 이전 단계에서 생성한 파일의 경로로 바꿉니다.

    로컬 그래프 데이터 init 컨테이너의 경로로 바꿉니다 .

  4. 다음 명령을 실행하여 그래프 데이터 init 컨테이너 를 푸시합니다. 

    podman push <graph-path>:latest --authfile=<pull-secret>.json
    Copy to Clipboard Toggle word wrap

    로컬 그래프 데이터 init 컨테이너의 경로로 바꿉니다 .

    & lt;pull-secret& gt;을 풀 시크릿 파일의 경로로 바꿉니다.

선택 사항: podman 을 설치하지 않은 경우 3단계와 4단계에서 podman 을 docker 로 교체합니다.

1.5.4.5. 미러링된 레지스트리의 인증서 구성
링크 복사

미러링된 OpenShift Container Platform 릴리스 이미지를 저장하기 위해 보안 외부 컨테이너 레지스트리를 사용하는 경우 OpenShift Update Service는 업그레이드 그래프를 빌드하기 위해 이 레지스트리에 액세스해야 합니다.

OpenShift Update Service Pod에서 작동하도록 CA 인증서를 구성하려면 다음 단계를 완료합니다.

  1. image.config.openshift.io 에 있는 OpenShift Container Platform 외부 레지스트리 API를 찾습니다. 외부 레지스트리 CA 인증서가 저장되는 위치입니다. 자세한 내용은 추가 리소스 섹션에서 이미지 레지스트리 액세스에 대한 추가 신뢰 저장소 구성 을 참조하십시오.

  2. openshift-config 네임스페이스에 ConfigMap을 생성하고 updateservice-registry 섹션에 CA 인증서를 추가합니다. 다음 예제를 참조하십시오. 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: trusted-ca
data:
  updateservice-registry: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap

  3. image.config.openshift.io API에서 클러스터 리소스를 편집하여 additionalTrustedCA 필드를 생성한 ConfigMap의 이름으로 설정합니다. 다음 명령을 실행하고 < trusted_ca&gt;를 새 ConfigMap의 경로로 바꿉니다. 

    oc patch image.config.openshift.io cluster -p '{"spec":{"additionalTrustedCA":{"name":"<trusted_ca>"}}}' --type merge
    Copy to Clipboard Toggle word wrap

OpenShift Update Service Operator는 openshift-config 네임스페이스에서 생성한 image.config.openshift.io API 및 openshift-config 네임스페이스에서 생성한 ConfigMap을 모니터링한 다음 CA 인증서가 변경된 경우 배포를 다시 시작합니다.

1.5.4.6. OpenShift Update Service 인스턴스 배포
링크 복사

허브 클러스터에 OpenShift Update Service 인스턴스 배포를 완료하면 클러스터 업그레이드의 이미지를 미러링하고 연결이 끊긴 관리 클러스터에서 사용할 수 있는 인스턴스가 있습니다.

인스턴스를 배포하려면 다음 단계를 완료합니다.

  1. Operator의 기본 네임스페이스를 사용하지 않으려면 콘솔에서 Administration > Namespaces 로 이동하여 변경합니다.
  2. OpenShift Container Platform 콘솔의 설치된 Operator 섹션에서 OpenShift Update Service Operator 를 선택합니다.
  3. 메뉴에서 Create Instance 를 선택합니다.

  4. OpenShift Update Service 인스턴스에서 콘텐츠를 붙여넣습니다. YAML 인스턴스는 다음 매니페스트와 유사할 수 있습니다. 

    apiVersion: update-service.openshift.io/v1beta2
kind: update-service
metadata:
  name: openshift-cincinnati-instance
  namespace: openshift-update-service
spec:
  registry: <registry-host-name>:<port>
    1 
    
  replicas: 1
  repository: ${LOCAL_REGISTRY}/ocp4/release
  graphDataImage: '<host-name>:<port>/cincinnati-graph-data-container'
    2
    Copy to Clipboard Toggle word wrap
    1
    이미지의 로컬 연결이 끊긴 레지스트리의 경로로 바꿉니다.
    2
    그래프 데이터 init 컨테이너의 경로로 바꿉니다. 그래프 데이터 init 컨테이너를 푸시하기 위해 podman push 명령을 실행할 때 사용한 값과 동일합니다.
  5. 만들기 를 선택하여 인스턴스를 만듭니다.
  6. hub 클러스터 CLI에서 oc get pods 명령을 입력하여 인스턴스 생성 상태를 확인합니다.

이 작업을 수행하는 데 몇 분 정도 걸릴 수 있습니다. 명령 결과에 인스턴스 및 Operator가 실행 중임을 표시되면 프로세스가 완료됩니다.

1.5.4.7. 선택 사항: 기본 레지스트리를 덮어쓰도록 정책 배포
링크 복사

다음 단계는 릴리스를 미러링된 레지스트리에 미러링한 경우에만 적용됩니다.

더 이상 사용되지 않음: PlacementRule

OpenShift Container Platform에는 업그레이드 패키지를 찾는 위치를 지정하는 기본 이미지 레지스트리 값이 있습니다. 연결이 끊긴 환경에서는 해당 값을 릴리스 이미지를 미러링한 로컬 이미지 레지스트리의 경로로 교체하는 정책을 생성할 수 있습니다.

정책을 생성하려면 다음 단계를 완료합니다.

  1. hub 클러스터의 OpenShift Container Platform 환경에 로그인합니다.
  2. 콘솔에서 Governance > Create policy 를 선택합니다.
  3. YAML 스위치를 On 으로 설정하여 정책의 YAML 버전을 확인합니다.
  4. YAML 코드의 모든 콘텐츠를 삭제합니다.

  5. 다음 YAML 콘텐츠를 창에 붙여넣어 사용자 정의 정책을 생성합니다. 

    apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-mirror
  namespace: default
spec:
  disabled: false
  remediationAction: enforce
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-image-content-source-policy
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: operator.openshift.io/v1alpha1
                kind: ImageContentSourcePolicy
                metadata:
                  name: <your-local-mirror-name>
    1 
    
                spec:
                  repositoryDigestMirrors:
                    - mirrors:
                        - <your-registry>
    2 
    
                      source: registry.redhat.io
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-mirror
  namespace: default
placementRef:
  name: placement-policy-mirror
  kind: PlacementRule
  apiGroup: apps.open-cluster-management.io
subjects:
- name: policy-mirror
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-mirror
  namespace: default
spec:
  clusterSelector:
    matchExpressions:
      []
    3
    Copy to Clipboard Toggle word wrap
    1
    로컬 미러 이름으로 바꿉니다.
    2
    을 로컬 미러 저장소의 경로로 바꿉니다. oc adm release mirror 명령을 실행하여 로컬 미러의 경로를 찾을 수 있습니다.
    3
    지정하지 않는 경우 모든 클러스터를 선택합니다.
  6. 지원되는 경우 Enforce 를 선택합니다.
  7. 만들기 를 선택하여 정책을 생성합니다.
1.5.4.8. 연결이 끊긴 카탈로그 소스 배포
링크 복사

Catalogsource 정책을 관리 클러스터로 내보내 연결된 위치에서 연결이 끊긴 로컬 레지스트리로 기본 위치를 변경할 수 있습니다.

기본 위치를 변경하려면 다음 단계를 완료합니다.

  1. 콘솔 메뉴에서 Governance > Create policy 를 선택합니다.
  2. YAML 스위치를 On 으로 설정하여 정책의 YAML 버전을 확인합니다.
  3. YAML 코드의 모든 콘텐츠를 삭제합니다.

  4. 다음 YAML 콘텐츠를 창에 붙여넣어 사용자 정의 정책을 생성합니다. 

    apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-catalog
  namespace: default
spec:
  disabled: false
  remediationAction: enforce
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-catalog
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: config.openshift.io/v1
                kind: OperatorHub
                metadata:
                  name: cluster
                spec:
                  disableAllDefaultSources: true
            - complianceType: musthave
              objectDefinition:
                apiVersion: operators.coreos.com/v1alpha1
                kind: CatalogSource
                metadata:
                  name: my-operator-catalog
                  namespace: openshift-marketplace
                spec:
                  sourceType: grpc
                  image: '<registry_host_name>:<port>/olm/redhat-operators:v1'
    1 
    
                  displayName: My Operator Catalog
                  publisher: grpc
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-catalog
  namespace: default
placementRef:
  name: placement-policy-catalog
  kind: PlacementRule
  apiGroup: apps.open-cluster-management.io
subjects:
- name: policy-catalog
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-catalog
  namespace: default
spec:
  clusterSelector:
    matchExpressions:
      []
    2
    Copy to Clipboard Toggle word wrap
    1
    로컬 제한된 카탈로그 소스 이미지의 경로로 바꿉니다.
    2
    지정하지 않는 경우 모든 클러스터를 선택합니다.
  5. 지원되는 경우 Enforce 를 선택합니다.
  6. 만들기 를 선택하여 정책을 생성합니다.
1.5.4.9. 관리 클러스터 매개변수를 변경하는 정책 배포
링크 복사

ClusterVersion 정책을 관리 클러스터로 푸시하여 업그레이드를 검색하는 기본 위치를 변경할 수 있습니다.

다음 단계를 완료합니다.

  1. 관리형 클러스터에서 다음 명령을 실행하여 ClusterVersion 업스트림 매개변수가 현재 기본 공용 OpenShift Update Service 피연산자인지 확인합니다. 

    oc get clusterversion -o yaml
    Copy to Clipboard Toggle word wrap

  2. 허브 클러스터에서 다음 명령을 실행하여 OpenShift Update Service 피연산자의 경로 URL을 식별합니다. 

    oc get routes
    Copy to Clipboard Toggle word wrap

    나중에 결과를 확인합니다.

  3. 허브 클러스터 콘솔 메뉴에서 Governance > Create a policy 를 선택합니다.
  4. YAML 스위치를 On 으로 설정하여 정책의 YAML 버전을 확인합니다.
  5. YAML 코드의 모든 콘텐츠를 삭제합니다.

  6. 다음 YAML 콘텐츠를 창에 붙여넣어 사용자 정의 정책을 생성합니다. 

    apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-cluster-version
  namespace: default
  annotations:
    policy.open-cluster-management.io/standards: null
    policy.open-cluster-management.io/categories: null
    policy.open-cluster-management.io/controls: null
spec:
  disabled: false
  remediationAction: enforce
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-cluster-version
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: config.openshift.io/v1
                kind: ClusterVersion
                metadata:
                  name: version
                spec:
                  channel: stable-4.4
                  upstream: >-
                    https://example-cincinnati-policy-engine-uri/api/upgrades_info/v1/graph
    1 
    

---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-cluster-version
  namespace: default
placementRef:
  name: placement-policy-cluster-version
  kind: PlacementRule
  apiGroup: apps.open-cluster-management.io
subjects:
- name: policy-cluster-version
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-cluster-version
  namespace: default
spec:
  clusterSelector:
    matchExpressions:
      []
    2
    Copy to Clipboard Toggle word wrap
    1
    hub 클러스터 OpenShift Update Service 피연산자의 경로로 바꿉니다. 지정하지 않는 경우 모든 클러스터를 선택합니다.

    다음 단계를 완료하여 피연산자의 경로를 확인할 수 있습니다.

    1. hub 클러스터에서 oc get get routes -A 명령을 실행합니다.

    2. update-service 경로를 찾습니다.

      피연산자의 경로는 HOST/PORT 필드의 값입니다.

  7. 지원되는 경우 Enforce 를 선택합니다.
  8. 만들기 를 선택하여 정책을 생성합니다.

  9. 관리 클러스터 CLI에서 다음 명령을 실행하여 ClusterVersion 의 upstream 매개변수가 로컬 허브 클러스터 OpenShift Update Service URL로 업데이트되었는지 확인합니다. 

    oc get clusterversion -o yaml
    Copy to Clipboard Toggle word wrap

  10. 결과가 다음 콘텐츠와 유사한지 확인합니다. 

    apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: ClusterVersion
[..]
  spec:
    channel: stable-4.4
    upstream: https://<hub-cincinnati-uri>/api/upgrades_info/v1/graph
    Copy to Clipboard Toggle word wrap
1.5.4.10. 사용 가능한 업그레이드 보기
링크 복사

다음 단계를 완료하여 관리 클러스터에 사용 가능한 업그레이드 목록을 볼 수 있습니다.

  1. 콘솔에서 Infrastructure > Clusters 를 선택합니다.
  2. Ready 상태에 있는 클러스터를 선택합니다.
  3. 작업 메뉴에서 클러스터 업그레이드 를 선택합니다.
  4. 선택적 업그레이드 경로를 사용할 수 있는지 확인합니다.

참고: 현재 버전이 로컬 이미지 저장소에 미러링되지 않은 경우 사용 가능한 업그레이드 버전이 표시되지 않습니다.

1.5.4.11. 채널 선택
링크 복사

Red Hat Advanced Cluster Management 콘솔을 사용하여 OpenShift Container Platform에서 클러스터 업그레이드 채널을 선택할 수 있습니다. 이러한 버전은 미러 레지스트리에서 사용할 수 있어야 합니다.

채널 선택 단계를 완료하여 업그레이드 채널을 지정합니다.

1.5.4.12. 클러스터 업그레이드
링크 복사

연결이 끊긴 레지스트리를 구성한 후 Red Hat Advanced Cluster Management 및 OpenShift Update Service는 연결이 끊긴 레지스트리를 사용하여 업그레이드를 사용할 수 있는지 확인합니다.

사용 가능한 업그레이드가 표시되지 않는 경우 클러스터의 현재 수준의 릴리스 이미지와 로컬 저장소에 미러링된 하나 이상의 이후 수준이 있는지 확인합니다.

현재 클러스터 버전의 릴리스 이미지를 사용할 수 없는 경우 업그레이드를 사용할 수 없습니다.

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

  1. 콘솔에서 Infrastructure > Clusters 를 선택합니다.
  2. 사용 가능한 업그레이드가 있는지 선택할 클러스터를 찾습니다.
  3. 업그레이드를 사용할 수 있는 경우 클러스터 의 배포 버전 열에 사용 가능한 업그레이드가 표시됩니다.
  4. 클러스터의 옵션 메뉴를 선택하고 클러스터 업그레이드 를 선택합니다.
  5. 업그레이드 대상 버전을 선택하고 업그레이드를 선택합니다.

클러스터 업그레이드에 실패하면 Operator는 일반적으로 업그레이드를 몇 번 재시도하고 중지한 후 실패한 구성 요소의 상태를 보고합니다. 경우에 따라 업그레이드 프로세스가 프로세스를 완료하려는 시도를 계속 순환합니다. 업그레이드 실패 후 클러스터를 이전 버전으로 롤백하는 것은 지원되지 않습니다. 클러스터 업그레이드에 실패하는 경우 Red Hat 지원에 문의하십시오.

1.5.4.12.1. 추가 리소스
링크 복사

외부 레지스트리 CA 인증서에 대한 자세한 내용은 OpenShift Container Platform 설명서의 이미지 레지스트리 액세스에 대한 추가 신뢰 저장소 구성 을 참조하십시오.

1.5.5. 고급 구성
링크 복사

다중 클러스터 엔진 Operator는 필요한 모든 구성 요소를 배포하는 Operator를 사용하여 설치됩니다. 멀티 클러스터 엔진 Operator는 설치 중 또는 설치 후 추가로 구성할 수 있습니다. 고급 구성 옵션에 대해 자세히 알아보십시오.

1.5.5.1. 배포된 구성 요소
링크 복사

MultiClusterEngine 사용자 정의 리소스에 다음 속성 중 하나 이상을 추가합니다.

Expand
표 1.6. 배포된 구성 요소의 표 목록

이름

설명

활성화됨

assisted-service

최소한의 인프라 사전 요구 사항 및 포괄적인 사전 요구 사항으로 OpenShift Container Platform 설치

True

cluster-api

관리형 클러스터 내에서 클러스터 API 라이프사이클을 처리하는 기능 제공

False

cluster-api-provider-aws

AWS의 클러스터 생성, 구성 및 관리를 위한 Kubernetes 스타일 API 제공

False

cluster-api-provider-openshift-assisted-preview

지원 설치 관리자를 사용하여 클러스터 생성, 구성 및 관리를 위한 Kubernetes 스타일 API 제공

False

cluster-api-provider-metal3-preview

베어 메탈 인프라에서 클러스터 생성, 구성 및 관리를 위한 Kubernetes 스타일 API 제공

False

cluster-lifecycle

OpenShift Container Platform 및 Kubernetes 허브 클러스터를 위한 클러스터 관리 기능 제공

True

cluster-manager

클러스터 환경 내에서 다양한 클러스터 관련 작업 관리

True

cluster-proxy-addon

역방향 프록시 서버를 사용하여 허브 및 관리 클러스터에 apiserver-network-proxy 설치를 자동화합니다.

True

console-mce

다중 클러스터 엔진 Operator 콘솔 플러그인 활성화

True

discovery

OpenShift Cluster Manager 내에서 새 클러스터를 검색하고 식별합니다.

True

Hive

OpenShift Container Platform 클러스터의 초기 구성 프로비저닝 및 수행

True

Hypershift

비용 및 시간 효율성과 클라우드 간 이식성으로 규모에 맞게 OpenShift Container Platform 컨트롤 플레인 호스트

True

hypershift-local-hosting

로컬 클러스터 환경 내의 로컬 호스팅 기능 활성화

True

image-based-install-operator

설치를 완료하기 위해 단일 노드 OpenShift 클러스터에 사이트 구성 제공

False

local-cluster

다중 클러스터 엔진 Operator가 배포된 로컬 허브 클러스터의 가져오기 및 자체 관리를 활성화합니다.

True

managedserviceacccount

서비스 계정을 관리 클러스터에 동기화하고, 토큰을 시크릿 리소스로 수집하여 허브 클러스터로 다시 제공

True

server-foundation

다중 클러스터 환경 내에서 서버 측 작업에 대한 기본 서비스 제공

True

다중 클러스터 엔진 Operator를 클러스터에 설치할 때 나열된 모든 구성 요소가 기본적으로 활성화되어 있는 것은 아닙니다.

MultiClusterEngine 사용자 정의 리소스에 하나 이상의 속성을 추가하여 설치 중 또는 설치 후 다중 클러스터 엔진 Operator를 추가로 구성할 수 있습니다. 추가할 수 있는 속성에 대한 정보를 계속 읽습니다.

1.5.5.2. 콘솔 및 구성 요소 구성
링크 복사

다음 예제는 구성 요소를 활성화하거나 비활성화하는 데 사용할 수 있는 spec.overrides 기본 템플릿을 표시합니다. 

apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  overrides:
    components:
    - name: <name>
1 

      enabled: true
Copy to Clipboard Toggle word wrap
  1. name 을 구성 요소의 이름으로 바꿉니다.

또는 다음 명령을 실행할 수 있습니다. namespace 를 프로젝트 및 name 의 이름으로 구성 요소 이름으로 교체합니다. 

oc patch MultiClusterEngine <multiclusterengine-name> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"<name>","enabled":true}}]'
Copy to Clipboard Toggle word wrap
1.5.5.3. local-cluster 활성화
링크 복사

기본적으로 다중 클러스터 엔진 Operator를 실행 중인 클러스터는 로컬 클러스터 이며, 이는 자체적으로 관리하고 클러스터 목록에서 local-cluster 로 지정된 허브 클러스터입니다.

MultiClusterEngine 리소스의 로컬 클러스터 이름은 spec.localClusterName 값에서 설정됩니다. enabled 설정은 기능이 활성화되어 있는지 여부를 지정합니다.

enabled: true 설정은 클러스터를 local-cluster 로 지정하고 enabled: false 설정은 지정하지 않습니다. enabled: true 값을 사용하여 local-cluster 가 활성화된 다음 샘플을 참조하십시오. 

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  localClusterName: <your-local-cluster-name>
  overrides:
    components:
    - name: local-cluster
      enabled: true
Copy to Clipboard Toggle word wrap

enabled 필드가 false 로 설정된 경우 local-cluster 이름을 변경할 수 있습니다. < your-local-cluster-name& gt; 값에 34자 이하의 문자를 사용해야 합니다. local-cluster 는 enabled: true 로 설정된 경우 이름을 변경할 수 없습니다.

로컬 클러스터로 지정하지 않고 다중 클러스터 엔진 Operator를 설치하려면 spec.overrides.components 설정을 enabled: false 로 변경합니다. 다음 YAML 샘플을 참조하십시오. 

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  localClusterName: <your-local-cluster-name>
  overrides:
    components:
    - name: local-cluster
      enabled: false
Copy to Clipboard Toggle word wrap
1.5.5.4. 사용자 정의 이미지 풀 시크릿
링크 복사

OpenShift Container Platform 또는 다중 클러스터 엔진 Operator에서 생성하지 않은 Kubernetes 클러스터를 가져오려면 배포 레지스트리에서 권한이 있는 콘텐츠에 액세스하기 위해 OpenShift Container Platform pull secret 정보가 포함된 시크릿을 생성합니다.

OpenShift Container Platform 클러스터의 시크릿 요구 사항은 Kubernetes Operator의 OpenShift Container Platform 및 다중 클러스터 엔진에서 자동으로 해결되므로 관리할 다른 유형의 Kubernetes 클러스터를 가져오지 않는 경우 시크릿을 생성할 필요가 없습니다.

중요: 이러한 시크릿은 네임스페이스에 고유하므로 엔진에 사용하는 네임스페이스에 있는지 확인합니다.

  1. 풀 시크릿 다운로드를 선택하여 cloud.redhat.com/openshift/install/pull-secret 에서 OpenShift Container Platform 풀 시크릿 파일을 다운로드합니다. OpenShift Container Platform 풀 시크릿은 Red Hat Customer Portal ID와 연결되며 모든 Kubernetes 공급자에서 동일합니다.

  2. 다음 명령을 실행하여 보안을 생성합니다. 

    oc create secret generic <secret> -n <namespace> --from-file=.dockerconfigjson=<path-to-pull-secret> --type=kubernetes.io/dockerconfigjson
    Copy to Clipboard Toggle word wrap
    • secret 을 생성하려는 시크릿 이름으로 교체합니다.
    • 시크릿은 네임스페이스에 따라 네임스페이스를 사용하므로 네임스페이스를 프로젝트 네임스페이스로 교체합니다.
    • 다운로드한 OpenShift Container Platform 풀 시크릿의 경로로 path-to-pull-secret 을 교체합니다.

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

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  imagePullSecret: <secret>
Copy to Clipboard Toggle word wrap
1.5.5.5. 대상 네임스페이스
링크 복사

피연산자는 MultiClusterEngine 사용자 정의 리소스에 위치를 지정하여 지정된 네임스페이스에 설치할 수 있습니다. 이 네임스페이스는 MultiClusterEngine 사용자 정의 리소스의 애플리케이션 시 생성됩니다.

중요: 대상 네임스페이스를 지정하지 않으면 Operator는 multicluster-engine 네임스페이스에 설치하고 MultiClusterEngine 사용자 정의 리소스 사양에 설정합니다.

다음 예제는 대상 네임스페이스를 지정하는 데 사용할 수 있는 spec.targetNamespace 템플릿을 표시합니다. target 을 대상 네임스페이스의 이름으로 교체합니다. 참고: 대상 네임스페이스는 기본 네임스페이스가 될 수 없습니다. 

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  targetNamespace: <target>
Copy to Clipboard Toggle word wrap
1.5.5.6. availabilityConfig
링크 복사

hub 클러스터에는 High 및 Basic 이라는 두 가지 가능성이 있습니다. 기본적으로 허브 클러스터의 가용성은 High 이며 hub 클러스터 구성 요소에 2 의 replicaCount 를 제공합니다. 이는 장애 조치의 경우 더 나은 지원을 제공하지만 기본 가용성보다 많은 리소스를 사용하므로 구성 요소에 1 의 replicaCount 가 제공됩니다.

중요: 단일 노드 OpenShift 클러스터에서 다중 클러스터 엔진 Operator를 사용하는 경우 spec.availabilityConfig 를 Basic 으로 설정합니다.

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

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  availabilityConfig: "Basic"
Copy to Clipboard Toggle word wrap
1.5.5.7. nodeSelector
링크 복사

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

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

Red Hat Advanced Cluster Management for Kubernetes Hub 클러스터에 대한 노드 선택기 세트를 정의하려면 Red Hat Advanced Cluster Management 설명서의 nodeSelector 를 참조하십시오.

1.5.5.8. 허용 오차
링크 복사

허용 오차 목록을 정의하여 MultiClusterEngine 이 클러스터에 정의된 특정 테인트를 허용할 수 있습니다. 다음 예제는 node-role.kubernetes.io/infra 테인트와 일치하는 spec.tolerations 를 보여줍니다. 

spec:
  tolerations:
  - key: node-role.kubernetes.io/infra
    effect: NoSchedule
    operator: Exists
Copy to Clipboard Toggle word wrap

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

Red Hat Advanced Cluster Management for Kubernetes Hub 클러스터의 허용 오차 목록을 정의하려면 Red Hat Advanced Cluster Management 설명서의 허용 오차 를 참조하십시오.

1.5.5.9. ManagedServiceAccount 애드온
링크 복사

ManagedServiceAccount 애드온을 사용하면 관리 클러스터에서 서비스 계정을 생성하거나 삭제할 수 있습니다. 이 애드온을 사용하여 설치하려면 spec.overrides 의 MultiClusterEngine 사양에 다음을 포함합니다. 

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  overrides:
    components:
    - name: managedserviceaccount
      enabled: true
Copy to Clipboard Toggle word wrap

명령줄에서 리소스를 편집하고 managedserviceaccount 구성 요소를 enabled: true 로 설정하여 ManagedServiceAccount 애드온을 MultiClusterEngine 을 생성한 후 활성화할 수 있습니다. 또는 다음 명령을 실행하고 <multiclusterengine-name>을 MultiClusterEngine 리소스의 이름으로 교체할 수 있습니다. 

oc patch MultiClusterEngine <multiclusterengine-name> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"managedserviceaccount","enabled":true}}]'
Copy to Clipboard Toggle word wrap

1.5.6. 설치 제거
링크 복사

Kubernetes Operator에 대한 다중 클러스터 엔진을 설치 제거할 때 프로세스의 두 가지 수준인 사용자 정의 리소스 제거 및 전체 Operator 설치 제거가 표시됩니다. 제거 프로세스를 완료하는 데 최대 5분이 걸릴 수 있습니다.

  • 사용자 정의 리소스 제거는 MultiClusterEngine 인스턴스의 사용자 정의 리소스를 제거하지만 다른 필요한 Operator 리소스를 제거하는 가장 기본적인 유형의 설치 제거입니다. 이 설치 제거 수준은 동일한 설정 및 구성 요소를 사용하여 다시 설치하려는 경우 유용합니다.
  • 두 번째 수준은 사용자 정의 리소스 정의와 같은 구성 요소를 제외하고 대부분의 Operator 구성 요소를 제거하는 더 완전한 제거 사항입니다. 이 단계를 계속할 때 사용자 정의 리소스 제거와 함께 제거되지 않은 모든 구성 요소 및 서브스크립션을 제거합니다. 이 제거 후 사용자 정의 리소스를 다시 설치하기 전에 Operator를 다시 설치해야 합니다.
1.5.6.1. 사전 요구 사항: 사용 가능한 서비스 분리
링크 복사

Kubernetes Operator용 다중 클러스터 엔진을 제거하기 전에 해당 엔진에서 관리하는 모든 클러스터를 분리해야 합니다. 오류를 방지하려면 엔진에서 계속 관리하는 모든 클러스터를 분리한 다음 다시 제거하십시오.

  • 관리 클러스터가 연결되어 있는 경우 다음 메시지가 표시될 수 있습니다. 

    Cannot delete MultiClusterEngine resource because ManagedCluster resource(s) exist
    Copy to Clipboard Toggle word wrap

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

1.5.6.2. 명령을 사용하여 리소스 제거
링크 복사
  1. 아직 설치되지 않은 경우 OpenShift Container Platform CLI가 oc 명령을 실행하도록 구성되어 있는지 확인합니다. oc 명령 구성에 대한 자세한 내용은 OpenShift Container Platform 설명서에서 OpenShift CLI 시작하기 를 참조하십시오.

  2. 다음 명령을 입력하여 프로젝트 네임스페이스로 변경합니다. namespace 를 프로젝트 네임스페이스의 이름으로 교체합니다. 

    oc project <namespace>
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 입력하여 MultiClusterEngine 사용자 정의 리소스를 제거합니다. 

    oc delete multiclusterengine --all
    Copy to Clipboard Toggle word wrap

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

    oc get multiclusterengine -o yaml
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 입력하여 설치된 네임스페이스에서 multicluster-engine ClusterServiceVersion 을 삭제하고 v2.x.0 변수를 대체하는 버전을 입력합니다. 
❯ oc get csv
NAME                         DISPLAY                              VERSION   REPLACES   PHASE
multicluster-engine.v2.x.0   multicluster engine for Kubernetes   2.x.0                Succeeded

❯ oc delete clusterserviceversion multicluster-engine.v2.x.0
❯ oc delete sub multicluster-engine
Copy to Clipboard Toggle word wrap

여기에 표시된 CSV 버전은 다를 수 있습니다.

1.5.6.3. 콘솔을 사용하여 구성 요소 삭제
링크 복사

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

  1. OpenShift Container Platform 콘솔 탐색에서 Operator > 설치된 Operator > Kubernetes용 멀티 클러스터 엔진을 선택합니다.

  2. MultiClusterEngine 사용자 정의 리소스를 제거합니다.

    1. Multiclusterengine 의 탭을 선택합니다.
    2. MultiClusterEngine 사용자 정의 리소스의 옵션 메뉴를 선택합니다.
    3. MultiClusterEngine 삭제를 선택합니다.

  3. 다음 섹션의 절차에 따라 정리 스크립트를 실행합니다.

    팁: Kubernetes Operator 버전에 대해 동일한 다중 클러스터 엔진을 다시 설치하려는 경우 이 절차의 나머지 단계를 건너뛰고 사용자 정의 리소스를 다시 설치할 수 있습니다.

  4. 설치된 Operator로 이동합니다.
  5. 옵션 메뉴를 선택하고 Uninstall operator 를 선택하여 Kubernetes_ operator의 _ 다중 클러스터 엔진을 제거합니다.
1.5.6.4. 문제 해결 설치 제거
링크 복사

다중 클러스터 엔진 사용자 정의 리소스가 제거되지 않는 경우 정리 스크립트를 실행하여 나머지 아티팩트를 제거합니다.

  1. 다음 스크립트를 파일에 복사합니다. 

    #!/bin/bash
oc delete apiservice v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io
oc delete validatingwebhookconfiguration multiclusterengines.multicluster.openshift.io
oc delete mce --all
    Copy to Clipboard Toggle word wrap

자세한 내용은 연결이 끊긴 환경에서 미러링 을 참조하십시오.

1.6. 인증 정보 관리
링크 복사

다중 클러스터 엔진 Operator가 있는 클라우드 서비스 공급자에서 Red Hat OpenShift Container Platform 클러스터를 생성하고 관리하려면 인증 정보가 필요합니다. 자격 증명은 클라우드 공급자의 액세스 정보를 저장합니다. 각 공급자 계정에는 단일 공급자의 각 도메인과 마찬가지로 자체 인증 정보가 필요합니다.

클러스터 인증 정보를 생성하고 관리할 수 있습니다. 인증 정보는 Kubernetes 시크릿으로 저장됩니다. 관리 클러스터의 컨트롤러에서 시크릿에 액세스할 수 있도록 보안이 관리되는 클러스터의 네임스페이스에 복사됩니다. 인증 정보가 업데이트되면 관리 클러스터 네임스페이스에서 시크릿 복사본이 자동으로 업데이트됩니다.

참고: 클라우드 공급자 인증 정보의 풀 시크릿, SSH 키 또는 기본 도메인에 대한 변경 사항은 기존 관리 클러스터에 반영되지 않습니다. 원래 인증 정보를 사용하여 이미 프로비저닝되었기 때문입니다.

필요한 액세스: 편집

1.6.1. Amazon Web Services의 인증 정보 생성
링크 복사

다중 클러스터 엔진 Operator 콘솔을 사용하여 AWS(Amazon Web Services)에서 Red Hat OpenShift Container Platform 클러스터를 배포하고 관리하려면 인증 정보가 필요합니다.

필요한 액세스: 편집

참고: 다중 클러스터 엔진 Operator를 사용하여 클러스터를 생성하려면 이 절차를 수행해야 합니다.

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

인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.

  • 배포된 다중 클러스터 엔진 Operator 허브 클러스터
  • 다중 클러스터 엔진 Operator 허브 클러스터에 대한 인터넷 액세스를 통해 AWS(Amazon Web Services)에서 Kubernetes 클러스터를 생성할 수 있습니다.
  • AWS 로그인 인증 정보: 액세스 키 ID 및 시크릿 액세스 키가 포함됩니다. 보안 인증 정보 이해 및 가져오기를 참조하십시오.
  • AWS에 클러스터를 설치할 수 있는 계정 권한 AWS 계정 구성 방법에 대한 지침은 AWS 계정 구성을 참조하십시오.
1.6.1.2. 콘솔을 사용하여 인증 정보 관리
링크 복사

다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.

탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의를 위해 보안을 강화하기 위해 특별히 네임스페이스를 생성하여 인증 정보를 호스팅합니다.

선택적으로 인증 정보에 대한 기본 DNS 도메인 을 추가할 수 있습니다. 기본 DNS 도메인을 인증 정보에 추가하면 이 인증 정보가 있는 클러스터를 생성할 때 올바른 필드에 자동으로 채워집니다. 다음 단계를 참조하십시오.

  1. AWS 계정의 AWS 액세스 키 ID 를 추가합니다. ID 를 찾으려면 AWS 에 로그인을 참조하십시오.
  2. 새 AWS Secret Access 키 의 콘텐츠를 제공합니다.

  3. 프록시를 활성화하려면 프록시 정보를 입력합니다.

    • HTTP 프록시 URL: HTTP 트래픽의 프록시로 사용해야 하는 URL입니다.
    • HTTPS 프록시 URL: HTTPS 트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면 HTTP 및 HTTPS 모두에 HTTP 프록시 URL 과 동일한 값이 사용됩니다.
    • 프록시 도메인 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 마침표로 도메인 이름을 시작합니다 . 를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표 * 를 추가합니다.
    • 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.
  4. Red Hat OpenShift 풀 시크릿을 입력합니다. 풀 시크릿 을 다운로드하려면 Red Hat OpenShift 풀 시크릿 다운로드를 참조하십시오.
  5. 클러스터에 연결할 수 있는 SSH 개인 키 및 SSH 공개 키를 추가합니다. 기존 키 쌍을 사용하거나 키 생성 프로그램으로 새 키 쌍을 만들 수 있습니다.

Amazon Web Services에서 클러스터 생성 또는 Amazon Web Services GovCloud에서 클러스터 생성 단계를 완료하여 이 인증 정보를 사용하는 클러스터를 생성할 수 있습니다.

콘솔에서 인증 정보를 편집할 수 있습니다. 이 공급자 연결을 사용하여 클러스터가 생성된 경우 < cluster- namespace>의 <cluster-name>-aws- creds > 시크릿이 새 인증 정보로 업데이트됩니다.

참고: 인증 정보를 업데이트해도 클러스터 풀 클레임 클러스터에서는 작동하지 않습니다.

인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.

1.6.1.2.1. S3 시크릿 생성
링크 복사

Amazon S3(Simple Storage Service) 시크릿을 생성하려면 콘솔에서 다음 작업을 완료합니다.

  1. Add credential > AWS > S3 Bucket 을 클릭합니다. For Hosted Control Plane 을 클릭하면 이름과 네임스페이스가 제공됩니다.

  2. 제공된 다음 필드에 대한 정보를 입력합니다.

    • bucket name: S3 버킷의 이름을 추가합니다.
    • AWS _ACCESS_KEY_ID: AWS 계정의 AWS 액세스 키 ID를 추가합니다. AWS에 로그인하여 ID를 찾습니다.
    • AWS _SECRET_ACCESS_KEY: 새로운 AWS Secret Access 키의 콘텐츠를 제공합니다.
    • 리전: AWS 리전을 입력합니다.
1.6.1.3. API를 사용하여 불투명 보안 생성
링크 복사

API를 사용하여 Amazon Web Services에 대한 불투명 시크릿을 생성하려면 다음 예와 유사한 YAML 프리뷰 창에 YAML 콘텐츠를 적용합니다. 

kind: Secret
metadata:
    name: <managed-cluster-name>-aws-creds
    namespace: <managed-cluster-namespace>
type: Opaque
data:
    aws_access_key_id: $(echo -n "${AWS_KEY}" | base64 -w0)
    aws_secret_access_key: $(echo -n "${AWS_SECRET}" | base64 -w0)
Copy to Clipboard Toggle word wrap

참고:

  • 불투명한 시크릿은 콘솔에 표시되지 않습니다.
  • opaque 보안은 선택한 관리 클러스터 네임스페이스에서 생성됩니다. Hive는 불투명 시크릿을 사용하여 클러스터를 프로비저닝합니다. Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 프로비저닝할 때 미리 생성된 인증 정보가 opaque 시크릿으로 관리 클러스터 네임스페이스에 복사됩니다.
  • 인증 정보에 라벨을 추가하여 콘솔에서 시크릿을 확인합니다. 예를 들어 다음 AWS S3 Bucket oc 레이블 시크릿에 는 type=awss3 및 인증 정보 --from-file=…​이 추가됩니다. 
oc label secret hypershift-operator-oidc-provider-s3-credentials -n <your-local-cluster-name> "cluster.open-cluster-management.io/type=awss3"
oc label secret hypershift-operator-oidc-provider-s3-credentials -n <your-local-cluster-name> "cluster.open-cluster-management.io/credentials=credentials="
Copy to Clipboard Toggle word wrap
1.6.1.4. 추가 리소스
링크 복사

1.6.2. Microsoft Azure에 대한 인증 정보 생성
링크 복사

Microsoft Azure 또는 Microsoft Azure Government에서 다중 클러스터 엔진 Operator 콘솔을 사용하여 Red Hat OpenShift Container Platform 클러스터를 생성하고 관리하려면 인증 정보가 필요합니다.

필요한 액세스: 편집

참고: 이 절차는 다중 클러스터 엔진 Operator가 있는 클러스터를 생성하기 위한 사전 요구 사항입니다.

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

인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.

  • 배포된 다중 클러스터 엔진 Operator 허브 클러스터입니다.
  • Azure에서 Kubernetes 클러스터를 생성할 수 있도록 다중 클러스터 엔진 Operator 허브 클러스터에 대한 인터넷 액세스
  • 기본 도메인 리소스 그룹 및 Azure 서비스 주체 JSON을 포함하는 Azure 로그인 자격 증명입니다. 로그인 인증 정보를 얻으려면 Microsoft Azure Portal 을 참조하십시오.
  • Azure에 클러스터를 설치할 수 있는 계정 권한 자세한 내용은 클라우드 서비스 구성 및 Azure 계정 구성을 참조하십시오.
1.6.2.2. 콘솔을 사용하여 인증 정보 관리
링크 복사

다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다. 탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의를 위해 보안을 강화하기 위해 특별히 네임스페이스를 생성하여 인증 정보를 호스팅합니다.

  1. 선택 사항: 인증 정보에 대한 기본 DNS 도메인 을 추가합니다. 기본 DNS 도메인을 인증 정보에 추가하면 이 인증 정보가 있는 클러스터를 생성할 때 올바른 필드에 자동으로 채워집니다.
  2. 클러스터의 환경이 AzurePublicCloud 또는 AzureUSGovernmentCloud 인지 여부를 선택합니다. Azure Government 환경에 대해 설정이 다르므로 이 설정이 올바르게 설정되어 있는지 확인합니다.
  3. Azure 계정에 대한 기본 도메인 리소스 그룹 이름을 추가합니다. 이 항목은 Azure 계정으로 생성한 리소스 이름입니다. Azure 인터페이스에서 홈 > DNS 영역을 선택하여 기본 도메인 리소스 그룹 이름을 찾을 수 있습니다. Azure CLI를 사용하여 Azure 서비스 주체 생성 을 참조하여 기본 도메인 리소스 그룹 이름을 찾습니다.

  4. 클라이언트 ID 의 콘텐츠를 제공합니다. 이 값은 다음 명령을 사용하여 서비스 주체를 생성할 때 appId 속성으로 생성됩니다. 

    az ad sp create-for-rbac --role Contributor --name <service_principal> --scopes <subscription_path>
    Copy to Clipboard Toggle word wrap

    service_principal 을 서비스 주체의 이름으로 교체합니다.

  5. 클라이언트 시크릿 을 추가합니다. 이 값은 다음 명령을 사용하여 서비스 주체를 생성할 때 password 속성으로 생성됩니다. 

    az ad sp create-for-rbac --role Contributor --name <service_principal> --scopes <subscription_path>
    Copy to Clipboard Toggle word wrap

    service_principal 을 서비스 주체의 이름으로 교체합니다.

  6. 서브스크립션 ID 를 추가합니다. 이 값은 다음 명령의 출력에 있는 id 속성입니다. 

    az account show
    Copy to Clipboard Toggle word wrap

  7. 테넌트 ID 를 추가합니다. 이 값은 다음 명령의 출력에 있는 tenantId 속성입니다. 

    az account show
    Copy to Clipboard Toggle word wrap

  8. 프록시를 활성화하려면 프록시 정보를 입력합니다.

    • HTTP 프록시 URL: HTTP 트래픽의 프록시로 사용해야 하는 URL입니다.
    • HTTPS 프록시 URL: HTTPS 트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면 HTTP 및 HTTPS 모두에 HTTP 프록시 URL 과 동일한 값이 사용됩니다.
    • 프록시 도메인 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 마침표로 도메인 이름을 시작합니다 . 를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표 * 를 추가합니다.
    • 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.
  9. Red Hat OpenShift 풀 시크릿 을 입력합니다. 풀 시크릿 을 다운로드하려면 Red Hat OpenShift 풀 시크릿 다운로드를 참조하십시오.
  10. 클러스터에 연결하는 데 사용할 SSH 개인 키 및 SSH 공개 키를 추가합니다. 기존 키 쌍을 사용하거나 키 생성 프로그램을 사용하여 새 쌍을 만들 수 있습니다.

Microsoft Azure에서 클러스터 생성 단계를 완료하여 이 인증 정보를 사용하는 클러스터를 생성할 수 있습니다.

콘솔에서 인증 정보를 편집할 수 있습니다.

인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.

1.6.2.3. API를 사용하여 불투명 보안 생성
링크 복사

콘솔 대신 API를 사용하여 Microsoft Azure에 대한 불투명 시크릿을 생성하려면 다음 예와 유사한 YAML 프리뷰 창에 YAML 콘텐츠를 적용합니다. 

kind: Secret
metadata:
    name: <managed-cluster-name>-azure-creds
    namespace: <managed-cluster-namespace>
type: Opaque
data:
    baseDomainResourceGroupName: $(echo -n "${azure_resource_group_name}" | base64 -w0)
    osServicePrincipal.json: $(base64 -w0 "${AZURE_CRED_JSON}")
Copy to Clipboard Toggle word wrap

참고:

  • 불투명한 시크릿은 콘솔에 표시되지 않습니다.
  • opaque 보안은 선택한 관리 클러스터 네임스페이스에서 생성됩니다. Hive는 불투명 시크릿을 사용하여 클러스터를 프로비저닝합니다. Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 프로비저닝할 때 미리 생성된 인증 정보가 opaque 시크릿으로 관리 클러스터 네임스페이스에 복사됩니다.
1.6.2.4. 추가 리소스
링크 복사

1.6.3. Google Cloud Platform의 인증 정보 생성
링크 복사

다중 클러스터 엔진 Operator 콘솔을 사용하여 GCP(Google Cloud Platform)에서 Red Hat OpenShift Container Platform 클러스터를 생성하고 관리하려면 인증 정보가 필요합니다.

필요한 액세스: 편집

참고: 이 절차는 다중 클러스터 엔진 Operator가 있는 클러스터를 생성하기 위한 사전 요구 사항입니다.

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

인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.

  • 배포된 다중 클러스터 엔진 Operator 허브 클러스터
  • GCP에서 Kubernetes 클러스터를 생성할 수 있도록 다중 클러스터 엔진 Operator 허브 클러스터에 대한 인터넷 액세스
  • 사용자 Google Cloud Platform 프로젝트 ID 및 Google Cloud Platform 서비스 계정 JSON 키가 포함된 GCP 로그인 인증 정보입니다. 프로젝트 생성 및 관리를 참조하십시오.
  • GCP에 클러스터를 설치할 수 있는 계정 권한. 계정 구성 방법에 대한 지침은 GCP 프로젝트 구성을 참조하십시오.
1.6.3.2. 콘솔을 사용하여 인증 정보 관리
링크 복사

다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.

탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의성과 보안을 위해 인증 정보를 호스팅하기 위해 특별히 네임스페이스를 만듭니다.

선택적으로 인증 정보에 대한 기본 DNS 도메인 을 추가할 수 있습니다. 기본 DNS 도메인을 인증 정보에 추가하면 이 인증 정보가 있는 클러스터를 생성할 때 올바른 필드에 자동으로 채워집니다. 다음 단계를 참조하십시오.

  1. GCP 계정의 Google Cloud Platform 프로젝트 ID 를 추가합니다. 설정을 검색하려면 GCP에 로그인을 참조하십시오.
  2. Google Cloud Platform 서비스 계정 JSON 키를 추가합니다. 서비스 계정 JSON 키를 생성하려면 서비스 계정 생성 설명서를 참조하십시오. GCP 콘솔의 단계를 따르십시오.
  3. 새 Google Cloud Platform 서비스 계정 JSON 키 의 콘텐츠를 제공합니다.

  4. 프록시를 사용하려면 프록시 정보를 입력합니다.

    • HTTP 프록시 URL: HTTP 트래픽의 프록시로 사용해야 하는 URL입니다.
    • HTTPS 프록시 URL: HTTPS 트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면 HTTP 및 HTTPS 모두에 HTTP 프록시 URL 과 동일한 값이 사용됩니다.
    • 프록시 도메인 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 마침표로 도메인 이름을 시작합니다 . 를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 * 를 추가하고 별표를 추가합니다.
    • 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.
  5. Red Hat OpenShift 풀 시크릿을 입력합니다. 풀 시크릿 을 다운로드하려면 Red Hat OpenShift 풀 시크릿 다운로드를 참조하십시오.
  6. 클러스터에 액세스할 수 있도록 SSH 개인 키 및 SSH 공개 키를 추가합니다. 기존 키 쌍을 사용하거나 키 생성 프로그램을 사용하여 새 쌍을 만들 수 있습니다.

Google Cloud Platform에서 클러스터 생성 단계를 완료하여 클러스터를 생성할 때 이 연결을 사용할 수 있습니다.

콘솔에서 인증 정보를 편집할 수 있습니다.

인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.

1.6.3.3. API를 사용하여 불투명 보안 생성
링크 복사

콘솔 대신 API를 사용하여 Google Cloud Platform에 대한 불투명 시크릿을 생성하려면 다음 예와 유사한 YAML 프리뷰 창에 YAML 콘텐츠를 적용합니다. 

kind: Secret
metadata:
    name: <managed-cluster-name>-gcp-creds
    namespace: <managed-cluster-namespace>
type: Opaque
data:
    osServiceAccount.json: $(base64 -w0 "${GCP_CRED_JSON}")
Copy to Clipboard Toggle word wrap

참고:

  • 불투명한 시크릿은 콘솔에 표시되지 않습니다.
  • opaque 보안은 선택한 관리 클러스터 네임스페이스에서 생성됩니다. Hive는 불투명 시크릿을 사용하여 클러스터를 프로비저닝합니다. Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 프로비저닝할 때 미리 생성된 인증 정보가 opaque 시크릿으로 관리 클러스터 네임스페이스에 복사됩니다.
1.6.3.4. 추가 리소스
링크 복사

Google Cloud Platform의 인증 정보 생성 으로 돌아갑니다.

1.6.4. VMware vSphere의 인증 정보 생성
링크 복사

VMware vSphere에서 Red Hat OpenShift Container Platform 클러스터를 배포하고 관리하려면 다중 클러스터 엔진 Operator 콘솔을 사용하려면 인증 정보가 필요합니다.

필요한 액세스: 편집

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

인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.

  • 다중 클러스터 엔진 Operator로 클러스터를 생성하려면 먼저 VMware vSphere에 대한 인증 정보를 생성해야 합니다.
  • 지원되는 OpenShift Container Platform 버전의 배포된 허브 클러스터입니다.
  • VMware vSphere에서 Kubernetes 클러스터를 생성할 수 있도록 허브 클러스터에 대한 인터넷 액세스.

  • 설치 관리자 프로비저닝 인프라를 사용하는 경우 OpenShift Container Platform에 대해 구성된 VMware vSphere 로그인 인증 정보 및 vCenter 요구 사항 사용자 지정을 사용하여 vSphere에 클러스터 설치를 참조하십시오. 이러한 인증 정보에는 다음 정보가 포함됩니다.

    • vCenter 계정 권한.
    • 클러스터 리소스.
    • DHCP 사용 가능
    • ESXi 호스트는 시간 동기화(예: NTP)입니다.
1.6.4.2. 콘솔을 사용하여 인증 정보 관리
링크 복사

다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.

탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의를 위해 보안을 강화하기 위해 특별히 네임스페이스를 생성하여 인증 정보를 호스팅합니다.

선택적으로 인증 정보에 대한 기본 DNS 도메인 을 추가할 수 있습니다. 기본 DNS 도메인을 인증 정보에 추가하면 이 인증 정보가 있는 클러스터를 생성할 때 올바른 필드에 자동으로 채워집니다. 다음 단계를 참조하십시오.

  1. VMware vCenter 서버 정규화된 호스트 이름 또는 IP 주소를 추가합니다. 값은 vCenter 서버 루트 CA 인증서에 정의해야 합니다. 가능한 경우 정규화된 호스트 이름을 사용합니다.
  2. VMware vCenter 사용자 이름을 추가합니다.
  3. VMware vCenter 암호를 추가합니다.

  4. VMware vCenter 루트 CA 인증서를 추가합니다.

    1. VMware vCenter 서버에서 인증서를 사용하여 https://<vCenter_address>/certs/ download.zip.zip 패키지에 인증서를 다운로드할 수 있습니다. vCenter_address 를 vCenter 서버의 주소로 바꿉니다.
    2. download.zip 의 패키지를 해제합니다.

    3. .0 확장자가 있는 certs/<platform > 디렉터리의 인증서를 사용합니다.

      팁: ls certs/<platform > 명령을 사용하여 플랫폼에 사용 가능한 모든 인증서를 나열할 수 있습니다.

      & lt;platform >을 플랫폼의 약어로 바꿉니다. lin,mac 또는 win.

      예: certs/lin/3a343545.0

      모범 사례: cat certs/lin/* .0 > ca.crt 명령을 실행하여 .0 확장자와 여러 인증서를 연결합니다.

    4. VMware vSphere 클러스터 이름을 추가합니다.
    5. VMware vSphere 데이터 센터를 추가합니다.
    6. VMware vSphere 기본 데이터 저장소를 추가합니다.
    7. VMware vSphere 디스크 유형을 추가합니다.
    8. VMware vSphere 폴더 를 추가합니다.
    9. VMware vSphere 리소스 풀 을 추가합니다.

  5. 연결 해제된 설치의 경우: 필요한 정보를 사용하여 구성 연결이 끊긴 설치 하위 섹션의 필드를 완료합니다.

    • Cluster OS image: 이 값에는 Red Hat OpenShift Container Platform 클러스터 머신에 사용할 이미지의 URL이 포함되어 있습니다.

    • 이미지 콘텐츠 소스: 이 값에는 연결이 끊긴 레지스트리 경로가 포함됩니다. 경로에는 연결이 끊긴 설치를 위한 모든 설치 이미지의 호스트 이름, 포트, 리포지토리 경로가 포함됩니다. 예: repository.com:5000/openshift/ocp-release.

      경로는 install-config.yaml 에서 Red Hat OpenShift Container Platform 릴리스 이미지로 이미지 콘텐츠 소스 정책 매핑을 생성합니다. 예를 들어 repository.com:5000 은 이 imageContentSource 콘텐츠를 생성합니다. 

      - mirrors:
  - registry.example.com:5000/ocp4
  source: quay.io/openshift-release-dev/ocp-release-nightly
- mirrors:
  - registry.example.com:5000/ocp4
  source: quay.io/openshift-release-dev/ocp-release
- mirrors:
  - registry.example.com:5000/ocp4
  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
      Copy to Clipboard Toggle word wrap

    • 추가 신뢰 번들: 이 값은 미러 레지스트리에 액세스하는 데 필요한 인증서 파일의 내용을 제공합니다.

      참고: 연결이 끊긴 환경에 있는 허브에서 관리 클러스터를 배포하고 자동으로 설치되도록 하려면 YAML 편집기를 사용하여 Image Content Source Policy를 install-config.yaml 파일에 추가합니다. 다음 예제에 샘플 항목이 표시되어 있습니다. 

      - mirrors:
  - registry.example.com:5000/rhacm2
  source: registry.redhat.io/rhacm2
      Copy to Clipboard Toggle word wrap

  6. 프록시를 활성화하려면 프록시 정보를 입력합니다.

    • HTTP 프록시 URL: HTTP 트래픽의 프록시로 사용해야 하는 URL입니다.
    • HTTPS 프록시 URL: HTTPS 트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면 HTTP 및 HTTPS 모두에 HTTP 프록시 URL 과 동일한 값이 사용됩니다.
    • 프록시 도메인 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 마침표로 도메인 이름을 시작합니다 . 를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 * 를 추가하고 별표를 추가합니다.
    • 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.
  7. Red Hat OpenShift 풀 시크릿을 입력합니다. 풀 시크릿 을 다운로드하려면 Red Hat OpenShift 풀 시크릿 다운로드를 참조하십시오.

  8. 클러스터에 연결할 수 있는 SSH 개인 키 및 SSH 공개 키를 추가합니다.

    기존 키 쌍을 사용하거나 키 생성 프로그램으로 새 키 쌍을 만들 수 있습니다.

VMware vSphere에서 클러스터 생성 단계를 완료하여 이 인증 정보를 사용하는 클러스터를 생성할 수 있습니다.

콘솔에서 인증 정보를 편집할 수 있습니다.

인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.

1.6.4.3. API를 사용하여 불투명 보안 생성
링크 복사

콘솔 대신 API를 사용하여 VMware vSphere에 대한 불투명 시크릿을 생성하려면 다음 예와 유사한 YAML 프리뷰 창에 YAML 콘텐츠를 적용합니다. 

kind: Secret
metadata:
    name: <managed-cluster-name>-vsphere-creds
    namespace: <managed-cluster-namespace>
type: Opaque
data:
    username: $(echo -n "${VMW_USERNAME}" | base64 -w0)
    password.json: $(base64 -w0 "${VMW_PASSWORD}")
Copy to Clipboard Toggle word wrap

참고:

  • 불투명한 시크릿은 콘솔에 표시되지 않습니다.
  • opaque 보안은 선택한 관리 클러스터 네임스페이스에서 생성됩니다. Hive는 불투명 시크릿을 사용하여 클러스터를 프로비저닝합니다. Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 프로비저닝할 때 미리 생성된 인증 정보가 opaque 시크릿으로 관리 클러스터 네임스페이스에 복사됩니다.
1.6.4.4. 추가 리소스
링크 복사

1.6.5. Red Hat OpenStack의 인증 정보 생성
링크 복사

다중 클러스터 엔진 Operator 콘솔을 사용하여 Red Hat OpenStack Platform에서 지원되는 Red Hat OpenShift Container Platform 클러스터를 배포하고 관리하려면 인증 정보가 필요합니다.

참고: 다중 클러스터 엔진 Operator로 클러스터를 생성하려면 Red Hat OpenStack Platform에 대한 인증 정보를 생성해야 합니다.

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

인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.

  • 지원되는 OpenShift Container Platform 버전의 배포된 허브 클러스터입니다.
  • 허브 클러스터에 대한 인터넷 액세스를 통해 Red Hat OpenStack Platform에서 Kubernetes 클러스터를 생성할 수 있습니다.
  • 설치 관리자 프로비저닝 인프라를 사용할 때 OpenShift Container Platform에 대해 구성된 Red Hat OpenStack Platform 로그인 인증 정보 및 Red Hat OpenStack Platform 요구 사항. 사용자 지정을 사용하여 OpenStack에 클러스터 설치를 참조하십시오.

  • CloudStack API에 액세스하기 위한 clouds.yaml 파일을 다운로드하거나 생성합니다. clouds.yaml 파일 내에서 다음을 수행합니다.

    • 사용할 클라우드 인증 섹션 이름을 확인합니다.
    • username 행 바로 뒤에 암호에 대한 행을 추가합니다.
1.6.5.2. 콘솔을 사용하여 인증 정보 관리
링크 복사

다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.

탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 보안 및 편의성을 개선하기 위해 특별히 인증 정보를 호스팅하는 네임스페이스를 생성할 수 있습니다.

  1. 선택 사항: 인증 정보에 대한 기본 DNS 도메인을 추가할 수 있습니다. 기본 DNS 도메인을 추가하면 이 인증 정보를 사용하여 클러스터를 생성할 때 올바른 필드에 자동으로 채워집니다.
  2. Red Hat OpenStack Platform clouds.yaml 파일 내용을 추가합니다. password를 포함하여 clouds.yaml 파일의 내용은 Red Hat OpenStack Platform 서버에 연결하는 데 필요한 정보를 제공합니다. 파일 콘텐츠에는 사용자 이름 직후 새 행에 추가하는 암호가 포함되어야 합니다.
  3. Red Hat OpenStack Platform 클라우드 이름을 추가합니다. 이 항목은 Red Hat OpenStack Platform 서버와의 통신을 설정하는 데 사용할 clouds.yaml 의 cloud 섹션에 지정된 이름입니다.
  4. 선택 사항: 내부 인증 기관을 사용하는 구성의 경우 내부 CA 인증서 필드에 인증서를 입력하여 인증서 정보를 사용하여 clouds.yaml 을 자동으로 업데이트합니다.

  5. 연결이 끊긴 설치의 경우에만 해당: 필요한 정보를 사용하여 구성 연결이 끊긴 설치 하위 섹션의 필드를 완료합니다.

    • Cluster OS image: 이 값에는 Red Hat OpenShift Container Platform 클러스터 머신에 사용할 이미지의 URL이 포함되어 있습니다.

    • 이미지 콘텐츠 소스: 이 값에는 연결이 끊긴 레지스트리 경로가 포함됩니다. 경로에는 연결이 끊긴 설치를 위한 모든 설치 이미지의 호스트 이름, 포트, 리포지토리 경로가 포함됩니다. 예: repository.com:5000/openshift/ocp-release.

      경로는 install-config.yaml 에서 Red Hat OpenShift Container Platform 릴리스 이미지로 이미지 콘텐츠 소스 정책 매핑을 생성합니다. 예를 들어 repository.com:5000 은 이 imageContentSource 콘텐츠를 생성합니다. 

      - mirrors:
  - registry.example.com:5000/ocp4
  source: quay.io/openshift-release-dev/ocp-release-nightly
- mirrors:
  - registry.example.com:5000/ocp4
  source: quay.io/openshift-release-dev/ocp-release
- mirrors:
  - registry.example.com:5000/ocp4
  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
      Copy to Clipboard Toggle word wrap

    • 추가 신뢰 번들: 이 값은 미러 레지스트리에 액세스하는 데 필요한 인증서 파일의 내용을 제공합니다.

      참고: 연결이 끊긴 환경에 있는 허브에서 관리 클러스터를 배포하고 자동으로 설치되도록 하려면 YAML 편집기를 사용하여 Image Content Source Policy를 install-config.yaml 파일에 추가합니다. 다음 예제에 샘플 항목이 표시되어 있습니다. 

      - mirrors:
  - registry.example.com:5000/rhacm2
  source: registry.redhat.io/rhacm2
      Copy to Clipboard Toggle word wrap

  6. 프록시를 활성화하려면 프록시 정보를 입력합니다.

    • HTTP 프록시 URL: HTTP 트래픽의 프록시로 사용해야 하는 URL입니다.
    • HTTPS 프록시 URL: HTTPS 트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면 HTTP 및 HTTPS 모두에 HTTP 프록시 URL 과 동일한 값이 사용됩니다.
    • 프록시 도메인 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 마침표로 도메인 이름을 시작합니다 . 를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표 * 를 추가합니다.
    • 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.
  7. Red Hat OpenShift 풀 시크릿을 입력합니다. 풀 시크릿 을 다운로드하려면 Red Hat OpenShift 풀 시크릿 다운로드를 참조하십시오.
  8. 클러스터에 연결할 수 있는 SSH 개인 키 및 SSH 공개 키를 추가합니다. 기존 키 쌍을 사용하거나 키 생성 프로그램으로 새 키 쌍을 만들 수 있습니다.
  9. 생성을 클릭합니다.
  10. 새 인증 정보 를 검토한 다음 추가 를 클릭합니다. 인증 정보를 추가하면 인증 정보 목록에 추가됩니다.

Red Hat OpenStack Platform에서 클러스터 생성 단계를 완료하여 이 인증 정보를 사용하는 클러스터를 생성할 수 있습니다.

콘솔에서 인증 정보를 편집할 수 있습니다.

인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.

1.6.5.3. API를 사용하여 불투명 보안 생성
링크 복사

콘솔 대신 API를 사용하여 Red Hat OpenStack Platform에 대한 불투명 시크릿을 생성하려면 다음 예와 유사한 YAML 프리뷰 창에 YAML 콘텐츠를 적용합니다. 

kind: Secret
metadata:
    name: <managed-cluster-name>-osp-creds
    namespace: <managed-cluster-namespace>
type: Opaque
data:
    clouds.yaml: $(base64 -w0 "${OSP_CRED_YAML}") cloud: $(echo -n "openstack" | base64 -w0)
Copy to Clipboard Toggle word wrap

참고:

  • 불투명한 시크릿은 콘솔에 표시되지 않습니다.
  • opaque 보안은 선택한 관리 클러스터 네임스페이스에서 생성됩니다. Hive는 불투명 시크릿을 사용하여 클러스터를 프로비저닝합니다. Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 프로비저닝할 때 미리 생성된 인증 정보가 opaque 시크릿으로 관리 클러스터 네임스페이스에 복사됩니다.
1.6.5.4. 추가 리소스
링크 복사

1.6.6. Red Hat OpenShift Cluster Manager의 인증 정보 생성
링크 복사

클러스터를 검색할 수 있도록 OpenShift Cluster Manager 인증 정보를 추가합니다.

필수 액세스: 관리자

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

OpenShift Cluster Manager 계정에 API 토큰이 필요하거나 별도의 서비스 계정을 사용할 수 있습니다.

  • API 토큰을 얻으려면 OpenShift Cluster Manager API 토큰 다운로드를 참조하십시오.
  • 서비스 계정을 사용하려면 서비스 계정을 생성할 때 클라이언트 ID 및 클라이언트 시크릿을 가져와야 합니다. 인증 정보를 입력하여 Kubernetes 운영자의 다중 클러스터 엔진에 OpenShift Cluster Manager 자격 증명을 생성합니다. 서비스 계정 생성 및 관리를 참조하십시오.
1.6.6.2. 콘솔을 사용하여 인증 정보 추가
링크 복사

클러스터를 검색하려면 인증 정보를 추가해야 합니다. 다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.

  1. 클러스터에 로그인합니다.
  2. 인증 정보 > 인증 정보 유형을 클릭하여 기존 인증 정보 옵션에서 선택합니다.
  3. 편의성과 추가된 보안을 위해 자격 증명을 호스팅할 네임스페이스를 생성합니다.
  4. 인증 정보 추가를 클릭합니다.
  5. Red Hat OpenShift Cluster Manager 옵션을 선택합니다.
  6. 인증 방법 중 하나를 선택합니다.

참고:

  • 인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다.
  • 인증 정보가 제거되거나 OpenShift Cluster Manager API 토큰이 만료되거나 취소되면 관련 검색 클러스터가 제거됩니다.

1.6.7. Ansible Automation Platform의 인증 정보 생성
링크 복사

다중 클러스터 엔진 Operator 콘솔을 사용하여 Red Hat Ansible Automation Platform을 사용하는 Red Hat OpenShift Container Platform 클러스터를 배포하고 관리하려면 인증 정보가 필요합니다.

필요한 액세스: 편집

참고: 클러스터에서 자동화를 활성화하려면 자동화 템플릿을 생성하기 전에 이 절차를 수행해야 합니다.

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

인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.

  • 배포된 다중 클러스터 엔진 Operator 허브 클러스터
  • 다중 클러스터 엔진 Operator 허브 클러스터에 대한 인터넷 액세스
  • Ansible Automation Platform 호스트 이름 및 OAuth 토큰이 포함된 Ansible 로그인 인증 정보는 Ansible Automation Platform용 인증 정보를 참조하십시오.
  • 허브 클러스터를 설치하고 Ansible을 사용할 수 있는 계정 권한. Ansible 사용자에 대해 자세히 알아보기 .
1.6.7.2. 콘솔을 사용하여 인증 정보 관리
링크 복사

다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.

탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의를 위해 보안을 강화하기 위해 특별히 네임스페이스를 생성하여 인증 정보를 호스팅합니다.

Ansible 인증 정보를 생성할 때 제공하는 Ansible 토큰 및 호스트 URL은 인증 정보를 편집할 때 해당 인증 정보를 사용하는 자동화에 대해 자동으로 업데이트됩니다. 업데이트는 클러스터 라이프사이클, 거버넌스 및 애플리케이션 관리 자동화와 관련된 Ansible 자격 증명을 사용하는 모든 자동화에 복사됩니다. 이렇게 하면 인증 정보를 업데이트한 후 자동화가 계속 실행됩니다.

콘솔에서 인증 정보를 편집할 수 있습니다. Ansible 인증 정보는 인증 정보에서 업데이트할 때 해당 인증 정보를 사용하는 자동화에서 자동으로 업데이트됩니다.

관리 클러스터에서 실행되도록 Ansible Automation Platform 작업 구성 단계를 완료하여 이 인증 정보를 사용하는 Ansible 작업을 생성할 수 있습니다.

인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.

1.6.8. 온-프레미스 환경에 대한 인증 정보 생성
링크 복사

온-프레미스 환경에서 Red Hat OpenShift Container Platform 클러스터를 배포하고 관리하려면 콘솔을 사용하는 인증 정보가 필요합니다. 인증 정보는 클러스터에 사용되는 연결을 지정합니다.

필요한 액세스: 편집

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

인증 정보를 생성하기 전에 다음 사전 요구 사항이 필요합니다.

  • 배포된 허브 클러스터입니다.
  • 인프라 환경에서 Kubernetes 클러스터를 생성할 수 있도록 허브 클러스터에 대한 인터넷 액세스.
  • 연결이 끊긴 환경의 경우 클러스터 생성을 위해 릴리스 이미지를 복사할 수 있는 구성된 미러 레지스트리가 있어야 합니다. 자세한 내용은 OpenShift Container Platform 설명서의 연결이 끊긴 환경 미러링 을 참조하십시오.
  • 온-프레미스 환경에 클러스터 설치를 지원하는 계정 권한.
1.6.8.2. 콘솔을 사용하여 인증 정보 관리
링크 복사

콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.

탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의를 위해 보안을 강화하기 위해 특별히 네임스페이스를 생성하여 인증 정보를 호스팅합니다.

  1. 인증 정보 유형에 대한 호스트 인벤토리 를 선택합니다.
  2. 선택적으로 인증 정보에 대한 기본 DNS 도메인 을 추가할 수 있습니다. 기본 DNS 도메인을 인증 정보에 추가하면 이 인증 정보가 있는 클러스터를 생성할 때 올바른 필드에 자동으로 채워집니다. DNS 도메인을 추가하지 않으면 클러스터를 생성할 때 추가할 수 있습니다.
  3. Red Hat OpenShift 풀 시크릿 을 입력합니다. 이 풀 시크릿은 클러스터를 생성하고 이 인증 정보를 지정할 때 자동으로 입력됩니다. Pull secret 에서 풀 시크릿을 다운로드할 수 있습니다. 가져오기 보안에 대한 자세한 내용은 이미지 풀 시크릿 사용을 참조하십시오.
  4. SSH 공개 키를 입력합니다. 클러스터를 생성하고 이 인증 정보를 지정할 때 이 SSH 공개 키도 자동으로 입력됩니다.
  5. 추가 를 선택하여 인증 정보를 생성합니다.

온-프레미스 환경에서 클러스터 생성 단계를 완료하여 이 인증 정보를 사용하는 클러스터를 만들 수 있습니다.

인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.

1.7. 클러스터 라이프사이클 소개
링크 복사

멀티 클러스터 엔진 Operator는 OpenShift Container Platform 및 Red Hat Advanced Cluster Management Hub 클러스터에 대한 클러스터 관리 기능을 제공하는 클러스터 라이프사이클 Operator입니다. 다중 클러스터 엔진 Operator는 클러스터 관리를 개선하고 클라우드 및 데이터 센터 전체에서 OpenShift Container Platform 클러스터 라이프사이클 관리를 지원하는 소프트웨어 운영자입니다. Red Hat Advanced Cluster Management를 사용하거나 사용하지 않고 다중 클러스터 엔진 Operator를 사용할 수 있습니다. Red Hat Advanced Cluster Management는 멀티 클러스터 엔진 Operator도 자동으로 설치하고 추가 다중 클러스터 기능을 제공합니다.

다음 설명서를 참조하십시오.

1.7.1. 클러스터 라이프사이클 아키텍처
링크 복사

클러스터 라이프사이클에는 허브 클러스터와 관리 클러스터의 두 가지 유형이 필요합니다.

hub 클러스터는 다중 클러스터 엔진 Operator가 자동으로 설치된 OpenShift Container Platform (또는 Red Hat Advanced Cluster Management) 기본 클러스터입니다. hub 클러스터를 사용하여 다른 Kubernetes 클러스터를 생성, 관리 및 모니터링할 수 있습니다. hub 클러스터에서 관리할 기존 클러스터를 가져오는 동안 hub 클러스터를 사용하여 클러스터를 생성할 수 있습니다.

관리형 클러스터를 생성할 때 Hive 리소스와 함께 Red Hat OpenShift Container Platform 클러스터 설치 프로그램을 사용하여 클러스터가 생성됩니다. OpenShift Container Platform 설명서에서 OpenShift Container Platform 클러스터 설치 및 구성을 읽고 OpenShift Container Platform 설치 프로그램을 사용하여 클러스터 설치 프로세스에 대한 자세한 내용을 참조하십시오.

다음 다이어그램은 클러스터 관리를 위해 Kubernetes Operator용 다중 클러스터 엔진과 함께 설치된 구성 요소를 보여줍니다.

Cluster lifecycle architecture diagram

클러스터 라이프사이클 관리 아키텍처의 구성 요소에는 다음 항목이 포함됩니다.

1.7.1.1. hub 클러스터
링크 복사
  • 관리 클러스터 가져오기 컨트롤러는 klusterlet Operator를 관리 클러스터에 배포합니다.
  • Hive 컨트롤러는 Kubernetes Operator에 다중 클러스터 엔진을 사용하여 생성하는 클러스터를 프로비저닝합니다. Hive 컨트롤러는 Kubernetes Operator를 위해 다중 클러스터 엔진에 의해 생성된 관리형 클러스터도 제거합니다.
  • 클러스터 큐레이터 컨트롤러는 관리 클러스터를 생성하거나 업그레이드할 때 클러스터 인프라 환경을 구성하기 위해 pre-hook 또는 post-hook로 Ansible 작업을 생성합니다.
  • hub 클러스터에서 관리되는 클러스터 애드온이 활성화되면 허브 클러스터에 해당 애드온 허브 컨트롤러가 배포됩니다. 애드온 허브 컨트롤러는 관리형 클러스터에 애드온 에이전트 를 배포합니다.
1.7.1.2. 관리형 클러스터
링크 복사
  • klusterlet Operator 는 관리 클러스터에 등록 및 작업 컨트롤러를 배포합니다.

  • 등록 에이전트 는 관리 클러스터와 관리형 클러스터 애드온을 hub 클러스터에 등록합니다. 또한 등록 에이전트는 관리 클러스터 및 관리 클러스터 애드온의 상태를 유지 관리합니다. 다음 권한은 관리 클러스터가 hub 클러스터에 액세스할 수 있도록 Clusterrole 내에 자동으로 생성됩니다.

    • 에이전트가 hub 클러스터에서 관리하는 소유 클러스터를 가져오거나 업데이트할 수 있습니다.
    • 에이전트가 hub 클러스터에서 관리하는 소유 클러스터의 상태를 업데이트할 수 있습니다.
    • 에이전트가 인증서를 회전하도록 허용
    • 에이전트가 reconcile .k8s.io 리스를 얻거나 업데이트 하도록 허용
    • 에이전트가 관리 클러스터 애드온을 가져올 수 있도록 허용
    • 에이전트가 관리 클러스터 애드온의 상태를 업데이트하도록 허용
  • 작업 에이전트 는 Add-on Agent를 관리 클러스터에 적용합니다. 관리 클러스터가 hub 클러스터에 액세스할 수 있도록 허용하는 권한은 Clusterrole 내에서 자동으로 생성되고 에이전트가 hub 클러스터에 이벤트를 보낼 수 있습니다.

클러스터를 계속 추가하고 관리하려면 클러스터 라이프사이클 소개 를 참조하십시오.

1.7.2. 이미지 릴리스
링크 복사

클러스터를 빌드할 때 릴리스 이미지가 지정하는 Red Hat OpenShift Container Platform 버전을 사용하십시오. 기본적으로 OpenShift Container Platform은 clusterImageSets 리소스를 사용하여 지원되는 릴리스 이미지 목록을 가져옵니다.

계속 읽고 릴리스 이미지에 대한 자세한 내용을 확인하십시오.

1.7.2.1. 릴리스 이미지 지정
링크 복사

Kubernetes Operator에 다중 클러스터 엔진을 사용하여 공급자에 클러스터를 생성하는 경우 새 클러스터에 사용할 릴리스 이미지를 지정합니다. 릴리스 이미지를 지정하려면 다음 항목을 참조하십시오.

1.7.2.1.1. ClusterImageSets위치
링크 복사

릴리스 이미지를 참조하는 YAML 파일은 acm-hive-openshift-releases GitHub 리포지토리에서 유지 관리됩니다. 파일은 콘솔에서 사용 가능한 릴리스 이미지 목록을 생성하는 데 사용됩니다. 여기에는 OpenShift Container Platform의 최신 빠른 채널 이미지가 포함됩니다.

콘솔에는 세 가지 최신 버전의 OpenShift Container Platform의 최신 릴리스 이미지만 표시됩니다. 예를 들어 콘솔 옵션에 다음 릴리스 이미지가 표시되고 <4.x>가 사용 중인 적절한 릴리스 버전으로 변경될 수 있습니다.

quay.io/openshift-release-dev/ocp-release:<4.x>.1-x86_64

콘솔에 최신 릴리스 이미지로 클러스터를 생성하는 데 도움이 되는 최신 버전이 표시됩니다. 특정 버전의 클러스터를 생성해야 하는 경우 이전 릴리스 이미지 버전도 사용할 수 있습니다.

참고: 콘솔에 클러스터를 생성할 때 표시되는 이미지: 'true' 레이블이 있는 이미지만 선택할 수 있습니다. ClusterImageSet 리소스의 이 레이블의 예는 다음 콘텐츠에 제공됩니다. 4.x.1 을 제품의 현재 버전으로 바꿉니다. 

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: fast
    visible: 'true'
  name: img4.x.1-x86-64-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.x.1-x86_64
Copy to Clipboard Toggle word wrap

추가 릴리스 이미지가 저장되지만 콘솔에는 표시되지 않습니다. 사용 가능한 모든 릴리스 이미지를 보려면 다음 명령을 실행합니다. 

oc get clusterimageset
Copy to Clipboard Toggle word wrap

리포지토리에는 릴리스 이미지로 작업할 때 사용하는 디렉터리인 clusterImageSets 디렉터리가 있습니다. clusterImageSets 디렉터리에는 다음과 같은 디렉터리가 있습니다.

  • fast: 지원되는 각 OpenShift Container Platform 버전에 대한 최신 버전의 릴리스 이미지를 참조하는 파일이 포함되어 있습니다. 이 폴더의 릴리스 이미지는 테스트, 확인 및 지원됩니다.

  • 릴리스: 각 OpenShift Container Platform 버전 (stable, fast, and candidate 채널)의 모든 릴리스 이미지를 참조하는 파일이 포함되어 있습니다.

    참고: 이 릴리스는 모두 테스트된 것이 아니며 안정적인 것으로 확인되었습니다.

  • stable: 지원되는 각 OpenShift Container Platform 버전에 대해 안정적인 최신 버전의 릴리스 이미지를 참조하는 파일이 포함되어 있습니다.

    참고: 기본적으로 현재 릴리스 이미지 목록은 시간마다 한 번씩 업데이트됩니다. 제품을 업그레이드한 후 새 버전의 제품에 권장되는 릴리스 이미지 버전을 반영하는 데 최대 1시간이 걸릴 수 있습니다.

1.7.2.1.2. ClusterImageSets구성
링크 복사

다음 옵션을 사용하여 ClusterImageSet 을 구성할 수 있습니다.

  • 옵션 1: 콘솔에서 클러스터를 만들려면 원하는 특정 ClusterImageSet 에 대한 이미지 참조를 지정합니다. 유지를 지정하는 각 새 항목은 향후 모든 클러스터 프로비저닝에 대해 사용할 수 있으며 다음 예제 항목을 참조하십시오. 

    quay.io/openshift-release-dev/ocp-release:4.6.8-x86_64
    Copy to Clipboard Toggle word wrap
  • 옵션 2: acm-hive-openshift-releases GitHub 리포지토리에서 ClusterImageSets YAML 파일을 수동으로 생성하고 적용합니다.
  • 옵션 3: 분기된 GitHub 리포지토리에서 ClusterImageSets 의 자동 업데이트를 활성화하려면 cluster-image-set-controller GitHub 리포지토리의 README.md 를 따릅니다.
1.7.2.1.3. 다른 아키텍처에 클러스터를 배포할 릴리스 이미지 생성
링크 복사

두 아키텍처의 파일이 있는 릴리스 이미지를 수동으로 생성하여 허브 클러스터의 아키텍처와 다른 아키텍처에 클러스터를 생성할 수 있습니다.

예를 들어 ppc64le,aarch64 또는 s390x 아키텍처에서 실행 중인 hub 클러스터에서 x86_64 클러스터를 생성해야 할 수 있습니다. 두 파일 세트를 모두 사용하여 릴리스 이미지를 생성하는 경우 새 릴리스 이미지를 사용하면 OpenShift Container Platform 릴리스 레지스트리에서 다중 아키텍처 이미지 매니페스트를 제공할 수 있으므로 클러스터 생성이 성공합니다.

OpenShift Container Platform은 기본적으로 여러 아키텍처를 지원합니다. 다음 clusterImageSet 을 사용하여 클러스터를 프로비저닝할 수 있습니다. 4.x.0 을 현재 지원되는 버전으로 교체합니다. 

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: fast
    visible: 'true'
  name: img4.x.0-multi-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.x.0-multi
Copy to Clipboard Toggle word wrap

여러 아키텍처를 지원하지 않는 OpenShift Container Platform 이미지의 릴리스 이미지를 생성하려면 아키텍처 유형에 대해 다음 예와 유사한 단계를 완료합니다.

  1. OpenShift Container Platform 릴리스 레지스트리에서 x86_64,s390x,aarch64, ppc64le 릴리스 이미지가 포함된 매니페스트 목록을 생성합니다.

    1. 다음 예제 명령을 실행하여 Quay 리포지토리에서 두 아키텍처 모두에 대한 매니페스트 목록을 가져옵니다. 4.x.1 을 제품의 현재 버전으로 바꿉니다. 

      podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-x86_64
podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-ppc64le
podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-s390x
podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-aarch64
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 이미지를 유지 관리하는 개인 리포지토리에 로그인합니다. & lt;private-repo >를 리포지토리 경로로 바꿉니다. 

      podman login <private-repo>
      Copy to Clipboard Toggle word wrap

    3. 환경에 적용되는 다음 명령을 실행하여 프라이빗 리포지토리에 릴리스 이미지 매니페스트를 추가합니다. 4.x.1 을 제품의 현재 버전으로 바꿉니다. & lt;private-repo >를 리포지토리 경로로 바꿉니다. 

      podman push quay.io/openshift-release-dev/ocp-release:4.x.1-x86_64 <private-repo>/ocp-release:4.x.1-x86_64
podman push quay.io/openshift-release-dev/ocp-release:4.x.1-ppc64le <private-repo>/ocp-release:4.x.1-ppc64le
podman push quay.io/openshift-release-dev/ocp-release:4.x.1-s390x <private-repo>/ocp-release:4.x.1-s390x
podman push quay.io/openshift-release-dev/ocp-release:4.x.1-aarch64 <private-repo>/ocp-release:4.x.1-aarch64
      Copy to Clipboard Toggle word wrap

    4. 다음 명령을 실행하여 새 정보에 대한 매니페스트를 생성합니다. 

      podman manifest create mymanifest
      Copy to Clipboard Toggle word wrap

    5. 다음 명령을 실행하여 두 릴리스 이미지에 대한 참조를 매니페스트 목록에 추가합니다. 4.x.1 을 제품의 현재 버전으로 바꿉니다. & lt;private-repo >를 리포지토리 경로로 바꿉니다. 

      podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-x86_64
podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-ppc64le
podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-s390x
podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-aarch64
      Copy to Clipboard Toggle word wrap

    6. 다음 명령을 실행하여 매니페스트 목록의 목록을 기존 매니페스트와 병합합니다. & lt;private-repo >를 리포지토리 경로로 바꿉니다. 4.x.1 을 현재 버전으로 바꿉니다. 

      podman manifest push mymanifest docker://<private-repo>/ocp-release:4.x.1
      Copy to Clipboard Toggle word wrap

  2. 허브 클러스터에서 리포지토리의 매니페스트를 참조하는 릴리스 이미지를 생성합니다.

    1. 다음 예와 유사한 정보가 포함된 YAML 파일을 생성합니다. & lt;private-repo >를 리포지토리 경로로 바꿉니다. 4.x.1 을 현재 버전으로 바꿉니다. 

      apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: fast
    visible: "true"
  name: img4.x.1-appsub
spec:
  releaseImage: <private-repo>/ocp-release:4.x.1
      Copy to Clipboard Toggle word wrap

    2. 허브 클러스터에서 다음 명령을 실행하여 변경 사항을 적용합니다. & lt;file-name >을 이전 단계에서 생성한 YAML 파일의 이름으로 바꿉니다. 

      oc apply -f <file-name>.yaml
      Copy to Clipboard Toggle word wrap
  3. OpenShift Container Platform 클러스터를 생성할 때 새 릴리스 이미지를 선택합니다.
  4. Red Hat Advanced Cluster Management 콘솔을 사용하여 관리 클러스터를 배포하는 경우 클러스터 생성 프로세스 중 Architecture 필드에 관리 클러스터의 아키텍처를 지정합니다.

생성 프로세스에서는 병합된 릴리스 이미지를 사용하여 클러스터를 생성합니다.

1.7.2.1.4. 추가 리소스
링크 복사
1.7.2.2. 연결된 경우 사용자 정의 릴리스 이미지 목록 유지
링크 복사

모든 클러스터에 동일한 릴리스 이미지를 사용해야 할 수 있습니다. 단순화하려면 클러스터를 생성할 때 사용할 수 있는 고유한 릴리스 이미지 목록을 생성합니다. 사용 가능한 릴리스 이미지를 관리하려면 다음 단계를 완료합니다.

  1. acm-hive-openshift-releases GitHub 를 분기합니다.
  2. 클러스터를 생성할 때 사용할 수 있는 이미지의 YAML 파일을 추가합니다. Git 콘솔 또는 터미널을 사용하여 이미지를 ./clusterImageSets/stable/ 또는 ./clusterImageSets/fast/ 디렉터리에 추가합니다.

  3. cluster-image-set-git-repo 라는 multicluster-engine 네임스페이스에 ConfigMap 을 생성합니다. 다음 예제를 참조하되 2.x 를 2.9로 바꿉니다. 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-image-set-git-repo
  namespace: multicluster-engine
data:
  gitRepoUrl:
    1 
    
  gitRepoBranch: backplane-<2.x>
  gitRepoPath: clusterImageSets
  channel:
    2 
    
  insecureSkipVerify:
    3 
    
  caCerts:
    4
    Copy to Clipboard Toggle word wrap
    1 1
    acm-hive-openshift-releases 리포지토리를 분기하여 가져온 URL을 사용합니다.
    2
    지원되는 값 중 하나를 fast 또는 stable 로 사용하도록 선택합니다.
    3
    비보안 연결을 빌드하려면 insecureSkipVerify 를 true 로 지정합니다. 지원되는 값은 true 또는 false 입니다.
    4
    보안 HTTPS 연결을 구축하기 위한 인증 기관(CA) 인증서를 나열합니다.

다음 절차에 따라 분기된 리포지토리에 변경 사항을 병합하여 기본 리포지토리에서 사용 가능한 YAML 파일을 검색할 수 있습니다.

  1. 분기된 리포지토리에 변경 사항을 커밋하고 병합합니다.
  2. acm-hive-openshift-releases 리포지토리를 복제한 후 빠른 릴리스 이미지 목록을 동기화하려면 cluster-image-set-git-repo ConfigMap 의 channel 필드를 fast 로 업데이트합니다.
  3. 안정적인 릴리스 이미지를 동기화하고 표시하려면 cluster-image-set-git-repo ConfigMap 의 channel 필드 값을 stable 로 업데이트합니다.

ConfigMap 을 업데이트한 후 사용 가능한 안정적인 릴리스 이미지 목록이 약 1분 내에 현재 사용 가능한 이미지로 업데이트됩니다.

  1. 다음 명령을 사용하여 사용 가능한 항목을 나열하고 기본값을 제거할 수 있습니다. & lt;clusterImageSet_NAME&gt;을 올바른 이름으로 바꿉니다. 

    oc get clusterImageSets
oc delete clusterImageSet <clusterImageSet_NAME>
    Copy to Clipboard Toggle word wrap
  2. 클러스터를 생성할 때 콘솔에서 현재 사용 가능한 릴리스 이미지 목록을 확인합니다.

ConfigMap 을 통해 사용할 수 있는 다른 필드에 대한 자세한 내용은 cluster-image-set-controller GitHub 리포지토리 README를 참조하십시오.

1.7.2.3. 연결이 끊긴 동안 사용자 정의 릴리스 이미지 목록 유지 관리
링크 복사

hub 클러스터에 인터넷 연결이 없는 경우 사용자 정의 릴리스 이미지 목록을 유지 관리해야 하는 경우도 있습니다. 클러스터를 생성할 때 사용 가능한 자체 릴리스 이미지 목록을 생성할 수 있습니다. 연결이 끊긴 동안 사용 가능한 릴리스 이미지를 관리하려면 다음 단계를 완료합니다.

  1. 연결된 시스템에서 acm-hive-openshift-releases GitHub 리포지토리로 이동하여 사용 가능한 클러스터 이미지 세트에 액세스합니다.
  2. 연결이 끊긴 다중 클러스터 엔진 Operator 클러스터에 액세스할 수 있는 시스템에 clusterImageSets 디렉터리를 복사합니다.

  3. 관리 클러스터에 적합한 다음 단계를 완료하여 관리 클러스터와 클러스터 이미지 세트와 연결이 끊긴 리포지토리 간의 매핑을 추가합니다.

  4. 콘솔 또는 CLI를 사용하여 clusterImageSet YAML 콘텐츠를 수동으로 추가하여 클러스터를 생성할 때 사용할 수 있는 이미지의 YAML 파일을 추가합니다.

  5. 이미지를 저장하는 올바른 오프라인 리포지토리를 참조하도록 나머지 OpenShift Container Platform 릴리스 이미지의 clusterImageSet YAML 파일을 수정합니다. 업데이트는 spec.releaseImage 에서 릴리스 이미지의 오프라인 이미지 레지스트리를 사용하고 다이제스트에서 릴리스 이미지를 참조하는 다음 예와 유사합니다. 

    apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: fast
  name: img<4.x.x>-x86-64-appsub
spec:
  releaseImage: IMAGE_REGISTRY_IPADDRESS_or__DNSNAME/REPO_PATH/ocp-release@sha256:073a4e46289be25e2a05f5264c8f1d697410db66b960c9ceeddebd1c61e58717
    Copy to Clipboard Toggle word wrap
  6. 이미지가 YAML 파일에서 참조되는 오프라인 이미지 레지스트리에 로드되었는지 확인합니다.

  7. 다음 명령을 실행하여 이미지 다이제스트를 가져옵니다. 

    oc adm release info <tagged_openshift_release_image> | grep "Pull From"
    Copy to Clipboard Toggle word wrap

    & lt;tagged_openshift_release_image >를 지원되는 OpenShift Container Platform 버전에 대한 태그된 이미지로 바꿉니다. 다음 예제 출력을 참조하십시오. 

    Pull From: quay.io/openshift-release-dev/ocp-release@sha256:69d1292f64a2b67227c5592c1a7d499c7d00376e498634ff8e1946bc9ccdddfe
    Copy to Clipboard Toggle word wrap

    이미지 태그 및 다이제스트에 대한 자세한 내용은 이미지 스트림의 이미지 참조를 참조하십시오.

  8. 각 YAML 파일에 다음 명령을 입력하여 각 clusterImageSets 를 생성합니다. 

    oc create -f <clusterImageSet_FILE>
    Copy to Clipboard Toggle word wrap

    clusterImageSet_FILE 을 클러스터 이미지 세트 파일의 이름으로 교체합니다. 예를 들면 다음과 같습니다. 

    oc create -f img4.11.9-x86_64.yaml
    Copy to Clipboard Toggle word wrap

    추가할 각 리소스에 대해 이 명령을 실행하면 사용 가능한 릴리스 이미지 목록을 사용할 수 있습니다.

  9. 또는 클러스터 콘솔 생성에 이미지 URL을 직접 붙여넣을 수 있습니다. 이미지 URL을 추가하면 새 clusterImageSets 가 없는 경우 생성됩니다.
  10. 클러스터를 생성할 때 콘솔에서 현재 사용 가능한 릴리스 이미지 목록을 확인합니다.
1.7.2.4. 사용 가능한 릴리스 이미지 동기화
링크 복사

MultiClusterHub Operator를 사용하여 허브 클러스터 구성 요소를 관리, 업그레이드 및 설치하는 Red Hat Advanced Cluster Management Hub 클러스터가 있는 경우 릴리스 이미지 목록을 동기화하여 사용 가능한 최신 버전을 선택할 수 있습니다. 릴리스 이미지는 acm-hive-openshift-releases 리포지토리에서 사용할 수 있으며 자주 업데이트됩니다.

1.7.2.4.1. 안정성 수준
링크 복사

다음 표에 표시된 대로 릴리스 이미지의 안정성에는 세 가지 수준이 있습니다.

Expand
표 1.7. 릴리스 이미지의 안정성 수준
카테고리설명

candidate

테스트되지 않았으며 버그가 있을 수 있는 최신 이미지입니다.

fast

부분적으로 테스트되었지만 안정적인 버전보다 안정적이지 않은 이미지입니다.

안정적

이러한 완전한 테스트 이미지는 클러스터를 올바르게 설치하고 빌드하도록 확인됩니다.

1.7.2.4.2. 릴리스 이미지 목록 새로 고침
링크 복사

Linux 또는 Mac 운영 체제를 사용하여 이미지 목록을 새로 고치고 동기화하려면 다음 단계를 완료합니다.

  1. 설치 관리자 관리 acm-hive-openshift-releases 서브스크립션이 활성화된 경우 MultiClusterHub 리소스에서 disableUpdateClusterImageSets 값을 true 로 설정하여 서브스크립션을 비활성화합니다.
  2. acm-hive-openshift-releases GitHub 리포지토리를 복제합니다.

  3. 다음 명령을 실행하여 서브스크립션을 제거합니다. 

    oc delete -f subscribe/subscription-fast
    Copy to Clipboard Toggle word wrap

  4. 후보 릴리스 이미지를 동기화하고 표시하려면 Linux 또는 Mac 운영 체제를 사용하여 다음 명령을 실행합니다. 

    make subscribe-candidate
    Copy to Clipboard Toggle word wrap

    약 1분 후에 후보 릴리스 이미지의 최신 목록을 사용할 수 있습니다.

  5. 빠른 릴리스 이미지를 동기화하고 표시하려면 다음 명령을 실행합니다. 

    make subscribe-fast
    Copy to Clipboard Toggle word wrap

    약 1분 후에 빠른 릴리스 이미지의 최신 목록을 사용할 수 있습니다.

  6. 안정적인 릴리스 이미지에 연결하고 Red Hat Advanced Cluster Management Hub 클러스터를 동기화합니다. Linux 또는 Mac 운영 체제를 사용하여 다음 명령을 실행합니다. 

    make subscribe-stable
    Copy to Clipboard Toggle word wrap

    약 1분 후에 사용 가능한 후보,빠른 릴리스 이미지 목록이 현재 사용 가능한 이미지로 업데이트됩니다.

  7. 클러스터를 생성할 때 Red Hat Advanced Cluster Management 콘솔에서 현재 사용 가능한 릴리스 이미지 목록을 확인합니다.

  8. 다음 명령을 실행하여 이러한 채널에서 서브스크립션을 취소하여 업데이트 보기를 중지합니다. 

    oc delete -f subscribe/subscription-fast
    Copy to Clipboard Toggle word wrap

1.7.3. 클러스터 생성
링크 복사

다중 클러스터 엔진 Operator를 사용하여 클라우드 공급자 간에 Red Hat OpenShift Container Platform 클러스터를 생성하는 방법을 알아봅니다.

다중 클러스터 엔진 Operator는 OpenShift Container Platform과 함께 제공되는 Hive Operator를 사용하여 온프레미스 클러스터 및 호스팅 컨트롤 플레인을 제외한 모든 공급자의 클러스터를 프로비저닝합니다. 온프레미스 클러스터를 프로비저닝할 때 다중 클러스터 엔진 Operator는 OpenShift Container Platform과 함께 제공되는 중앙 인프라 관리 및 지원 설치 관리자 기능을 사용합니다. 호스팅된 컨트롤 플레인의 호스트 클러스터는 HyperShift Operator를 사용하여 프로비저닝됩니다.

1.7.3.1. CLI를 사용하여 클러스터 생성
링크 복사

Kubernetes Operator용 멀티 클러스터 엔진은 내부 Hive 구성 요소를 사용하여 Red Hat OpenShift Container Platform 클러스터를 생성합니다. 클러스터 생성 방법을 알아보려면 다음 정보를 참조하십시오.

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

  • 다음 명령을 실행하여 Hub 클러스터에서 ClusterImageSet 리소스를 사용할 수 있는지 확인합니다. 

    oc get clusterimageset -A
    Copy to Clipboard Toggle word wrap

    출력은 다음 예와 유사할 수 있습니다. 

    img4.18.4-multi-appsub     quay.io/openshift-release-dev/ocp-release:4.18.4-multi
img4.18.4-x86-64-appsub    quay.io/openshift-release-dev/ocp-release:4.18.4-x86_64
    Copy to Clipboard Toggle word wrap

    참고: 각 ClusterImageSet은 OpenShift Container Platform 릴리스 이미지를 참조합니다. ClusterImageSet 리소스는 Kubernetes Operator를 위해 다중 클러스터 엔진의 cluster-image-set-controller 에 의해 채워집니다.

  • Nutanix 플랫폼을 사용하는 경우 ClusterImageSet 리소스의 releaseImage 에 x86_64 아키텍처를 사용하고 표시되는 라벨 값을 'true' 로 설정합니다. 다음 예제를 참조하십시오. 

    apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: stable
    visible: 'true'
  name: img4.x.47-x86-64-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.x.47-x86_64
    Copy to Clipboard Toggle word wrap
  • 허브 클러스터 KubeAPIServer 인증서 확인 전략을 검토하고 필요한 경우 전략을 업데이트합니다. 설정에 사용할 전략을 알아보려면 허브 클러스터 KubeAPIServer 확인 전략 구성을 참조하십시오.
1.7.3.1.2. ClusterDeployment을 사용하여 클러스터 생성
링크 복사

ClusterDeployment 은 클러스터의 라이프사이클을 제어하는 데 사용되는 Hive 사용자 정의 리소스입니다.

Hive 사용 설명서에 따라 ClusterDeployment 사용자 정의 리소스를 생성하고 개별 클러스터를 생성합니다.

1.7.3.1.3. ClusterPool로 클러스터 생성
링크 복사

ClusterPool 은 여러 클러스터를 생성하는 데 사용되는 Hive 사용자 정의 리소스이기도 합니다.

Cluster Pools 문서에 따라 Hive ClusterPool API로 클러스터를 생성합니다.

1.7.3.2. 클러스터 생성 중 추가 매니페스트 구성
링크 복사

클러스터를 생성하는 설치 프로세스 중에 추가 Kubernetes 리소스 매니페스트를 구성할 수 있습니다. 이는 네트워킹 구성 또는 로드 밸런서 설정과 같은 시나리오에 대한 추가 매니페스트를 구성해야 하는 경우 도움이 될 수 있습니다.

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

추가 리소스 매니페스트가 포함된 구성 맵 리소스를 지정하는 ClusterDeployment 리소스에 참조를 추가합니다.

참고: ClusterDeployment 리소스 및 구성 맵은 동일한 네임스페이스에 있어야 합니다.

1.7.3.2.2. 예제를 사용하여 클러스터 생성 중 추가 매니페스트 구성
링크 복사

리소스 매니페스트가 있는 구성 맵을 사용하여 추가 매니페스트를 구성하려면 다음 단계를 완료합니다.

  1. YAML 파일을 생성하고 다음 예제 콘텐츠를 추가합니다. 

    kind: ConfigMap
apiVersion: v1
metadata:
  name: <my-baremetal-cluster-install-manifests>
  namespace: <mynamespace>
data:
  99_metal3-config.yaml: |
    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: metal3-config
      namespace: openshift-machine-api
    data:
      http_port: "6180"
      provisioning_interface: "enp1s0"
      provisioning_ip: "172.00.0.3/24"
      dhcp_range: "172.00.0.10,172.00.0.100"
      deploy_kernel_url: "http://172.00.0.3:6180/images/ironic-python-agent.kernel"
      deploy_ramdisk_url: "http://172.00.0.3:6180/images/ironic-python-agent.initramfs"
      ironic_endpoint: "http://172.00.0.3:6385/v1/"
      ironic_inspector_endpoint: "http://172.00.0.3:5150/v1/"
      cache_url: "http://192.168.111.1/images"
      rhcos_image_url: "https://releases-art-rhcos.svc.ci.openshift.org/art/storage/releases/rhcos-4.3/43.81.201911192044.0/x86_64/rhcos-43.81.201911192044.0-openstack.x86_64.qcow2.gz"
    Copy to Clipboard Toggle word wrap

    참고: 예제 ConfigMap 에는 다른 ConfigMap 리소스가 있는 매니페스트가 포함되어 있습니다. 리소스 매니페스트 ConfigMap 은 다음 패턴에 추가된 리소스 구성으로 여러 키를 포함할 수 있습니다 . data.<resource_name>\.yaml.

  2. 다음 명령을 실행하여 파일을 적용합니다. 

    oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

    리소스 매니페스트 ConfigMap 을 참조하여 ClusterDeployment 을 사용하여 추가 매니페스트를 구성하려면 다음 단계를 완료합니다.

  3. YAML 파일을 생성하고 다음 예제 콘텐츠를 추가합니다. 리소스 매니페스트 ConfigMap 은 spec.provisioning.manifestsConfigMapRef:에서 참조됩니다. 

    apiVersion: hive.openshift.io/v1
kind: ClusterDeployment
metadata:
  name: <my-baremetal-cluster>
  namespace: <mynamespace>
  annotations:
    hive.openshift.io/try-install-once: "true"
spec:
  baseDomain: test.example.com
  clusterName: <my-baremetal-cluster>
  controlPlaneConfig:
    servingCertificates: {}
  platform:
    baremetal:
      libvirtSSHPrivateKeySecretRef:
        name: provisioning-host-ssh-private-key
  provisioning:
    installConfigSecretRef:
      name: <my-baremetal-cluster-install-config>
    sshPrivateKeySecretRef:
      name: <my-baremetal-hosts-ssh-private-key>
    manifestsConfigMapRef:
      name: <my-baremetal-cluster-install-manifests>
    imageSetRef:
      name: <my-clusterimageset>
    sshKnownHosts:
    - "10.1.8.90 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXvVVVKUYVkuyvkuygkuyTCYTytfkufTYAAAAIbmlzdHAyNTYAAABBBKWjJRzeUVuZs4yxSy4eu45xiANFIIbwE3e1aPzGD58x/NX7Yf+S8eFKq4RrsfSaK2hVJyJjvVIhUsU9z2sBJP8="
  pullSecretRef:
    name: <my-baremetal-cluster-pull-secret>
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 파일을 적용합니다. 

    oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap
1.7.3.3. Amazon Web Services에서 클러스터 생성
링크 복사

다중 클러스터 엔진 Operator 콘솔을 사용하여 AWS(Amazon Web Services)에서 Red Hat OpenShift Container Platform 클러스터를 생성할 수 있습니다.

클러스터를 생성할 때 생성 프로세스는 OpenShift Container Platform 설치 프로그램을 Hive 리소스와 함께 사용합니다. 이 절차를 완료한 후 클러스터 생성에 대한 질문이 있는 경우 OpenShift Container Platform 설명서에서 AWS에 설치 프로세스를 참조하십시오.

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

AWS에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.

  • 배포된 허브 클러스터가 있어야 합니다.
  • AWS 인증 정보가 필요합니다. 자세한 내용은 Amazon Web Services의 인증 정보 생성을 참조하십시오.
  • AWS에 구성된 도메인이 필요합니다. 도메인 구성 방법에 대한 자세한 내용은 AWS 에 설치를 참조하십시오.
  • 사용자 이름, 암호, 액세스 키 ID 및 시크릿 액세스 키가 포함된 AWS(Amazon Web Services) 로그인 인증 정보가 있어야 합니다. 보안 인증 정보 이해 및 가져오기를 참조하십시오.

  • OpenShift Container Platform 이미지 풀 시크릿이 있어야 합니다. 이미지 풀 시크릿 사용을 참조하십시오.

    참고: 클라우드 공급자의 클라우드 공급자 액세스 키를 변경하는 경우 콘솔에서 클라우드 공급자에 대한 해당 인증 정보도 수동으로 업데이트해야 합니다. 이는 관리 클러스터가 호스팅되는 클라우드 공급자에서 인증 정보가 만료되고 관리 클러스터를 삭제하려고 할 때 필요합니다.

1.7.3.3.2. AWS 클러스터 생성
링크 복사

AWS 클러스터 생성에 대한 다음 중요한 정보를 참조하십시오.

  • 정보를 검토하고 선택적으로 클러스터를 생성하기 전에 사용자 지정할 때 YAML: On 을 선택하여 패널의 install-config.yaml 파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.
  • 클러스터를 생성할 때 컨트롤러는 클러스터 및 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다.
  • 클러스터를 삭제하면 네임스페이스와 모든 리소스가 삭제됩니다.
  • 기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin 권한이 없는 경우 clusterset-admin 권한이 있는 클러스터 세트를 선택해야 합니다.
  • 지정된 클러스터 세트에 대한 올바른 권한이 없는 경우 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 클러스터 세트에 clusterset-admin 권한을 제공하려면 클러스터 관리자에게 문의하십시오.
  • 모든 관리 클러스터는 관리 클러스터 세트와 연결되어 있어야 합니다. ManagedClusterSet 에 관리 클러스터를 할당하지 않으면 기본 관리 클러스터 세트에 자동으로 추가됩니다.
  • AWS 계정으로 구성한 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 값이 필드에 채워집니다. 값을 덮어 쓰기하여 변경할 수 있습니다. 이 이름은 클러스터의 호스트 이름에 사용됩니다.
  • 릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용 가능한 이미지 목록에서 이미지를 선택합니다. 사용하려는 이미지를 사용할 수 없는 경우 사용하려는 이미지의 URL을 입력할 수 있습니다.

  • 노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동 관리를 공유합니다. 정보에는 다음 필드가 포함됩니다.

    • region: 노드 풀을 원하는 리전을 지정합니다.
    • CPU 아키텍처: 관리 클러스터의 아키텍처 유형이 허브 클러스터의 아키텍처와 동일하지 않으면 풀에 있는 시스템의 명령 집합 아키텍처 값을 입력합니다. 유효한 값은 amd64,ppc64le,s390x 및 arm64 입니다.
    • zones: 컨트롤 플레인 풀을 실행할 위치를 지정합니다. 더 분산된 컨트롤 플레인 노드 그룹에 대해 리전 내에서 여러 영역을 선택할 수 있습니다. 더 가까운 영역은 더 빠른 성능을 제공할 수 있지만 더 멀리 있는 영역이 더 분산될 수 있습니다.
    • 인스턴스 유형: 컨트롤 플레인 노드의 인스턴스 유형을 지정합니다. 인스턴스 유형 및 크기를 생성한 후 변경할 수 있습니다.
    • 루트 스토리지: 클러스터에 할당할 루트 스토리지 크기를 지정합니다.

  • 작업자 풀에 0개 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 이는 단일 작업자 풀에 있거나 여러 작업자 풀에 분산될 수 있습니다. 제로 작업자 노드가 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 선택적 정보에는 다음 필드가 포함됩니다.

    • zones: 작업자 풀을 실행할 위치를 지정합니다. 더 분산된 노드 그룹에 대해 리전 내에서 여러 영역을 선택할 수 있습니다. 더 가까운 영역은 더 빠른 성능을 제공할 수 있지만 더 멀리 있는 영역이 더 분산될 수 있습니다.
    • 인스턴스 유형: 작업자 풀의 인스턴스 유형을 지정합니다. 인스턴스 유형 및 크기를 생성한 후 변경할 수 있습니다.
    • 노드 수: 작업자 풀의 노드 수를 지정합니다. 이 설정은 작업자 풀을 정의할 때 필요합니다.
    • 루트 스토리지: 작업자 풀에 할당된 루트 스토리지의 양을 지정합니다. 이 설정은 작업자 풀을 정의할 때 필요합니다.
  • 클러스터에 네트워킹 세부 정보가 필요하며 IPv6를 사용하려면 여러 네트워크가 필요합니다. 네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다.

  • 인증 정보에 제공된 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나, 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시를 생성하는 데 필요한 정보가 포함되어 있습니다.

    • HTTP 프록시: HTTP 트래픽의 프록시로 사용해야 하는 URL을 지정합니다.
    • HTTPS 프록시: HTTPS 트래픽에 사용해야 하는 보안 프록시 URL을 지정합니다. 값을 제공하지 않으면 HTTP 및 HTTPS 모두에 HTTP 프록시 URL 과 동일한 값이 사용됩니다.
    • 프록시 사이트 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 사이트 목록입니다. 마침표로 도메인 이름을 시작합니다 . 를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표 * 를 추가합니다.
    • 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.
1.7.3.3.3. 콘솔을 사용하여 클러스터 생성
링크 복사

새 클러스터를 생성하려면 다음 절차를 참조하십시오. 대신 가져올 기존 클러스터가 있는 경우 클러스터 가져오기 를 참조하십시오.

참고: 클러스터를 가져오기 위해 클러스터 세부 정보가 제공된 oc 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator 관리 아래에 자동으로 구성됩니다.

  1. Infrastructure > Clusters 로 이동합니다.
  2. 클러스터 페이지에서 다음을 수행합니다. 클러스터 > 클러스터 생성 을 클릭하고 콘솔의 단계를 완료합니다.
  3. 선택 사항: 콘솔에서 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML 을 선택합니다.

인증 정보를 생성해야 하는 경우 자세한 내용은 Amazon Web Services에 대한 인증 정보 생성 을 참조하십시오.

클러스터 이름은 클러스터의 호스트 이름에 사용됩니다.

Kubernetes용 Red Hat Advanced Cluster Management를 사용하고 관리 클러스터 klusterlet을 특정 노드에서 실행하도록 구성하려면 선택 사항: 필요한 단계를 위해 특정 노드에서 실행되도록 klusterlet 구성 을 참조하십시오.

1.7.3.3.4. 추가 리소스
링크 복사
1.7.3.4. Amazon Web Services GovCloud에서 클러스터 생성
링크 복사

콘솔을 사용하여 AWS(Amazon Web Services) 또는 AWS GovCloud에 Red Hat OpenShift Container Platform 클러스터를 생성할 수 있습니다. 다음 절차에서는 AWS GovCloud에 클러스터를 생성하는 방법을 설명합니다. AWS 에서 클러스터를 생성하는 방법은 Amazon Web Services 에서 클러스터 생성을 참조하십시오.

AWS GovCloud는 정부 문서를 클라우드에 저장하는 데 필요한 추가 요구 사항을 충족하는 클라우드 서비스를 제공합니다. AWS GovCloud에서 클러스터를 생성할 때 환경을 준비하려면 추가 단계를 완료해야 합니다.

클러스터를 생성할 때 생성 프로세스는 OpenShift Container Platform 설치 프로그램을 Hive 리소스와 함께 사용합니다. 이 절차를 완료한 후 클러스터 생성에 대한 질문이 있는 경우 OpenShift Container Platform 설명서의 정부 리전에 AWS의 클러스터 설치를 참조하십시오. 다음 섹션에서는 AWS GovCloud에 클러스터를 생성하는 단계를 제공합니다.

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

AWS GovCloud 클러스터를 생성하기 전에 다음 사전 요구 사항이 있어야합니다.

  • 사용자 이름, 암호, 액세스 키 ID 및 시크릿 액세스 키가 포함된 AWS 로그인 인증 정보가 있어야 합니다. 보안 인증 정보 이해 및 가져오기를 참조하십시오.
  • AWS 인증 정보가 필요합니다. 자세한 내용은 Amazon Web Services의 인증 정보 생성을 참조하십시오.
  • AWS에 구성된 도메인이 필요합니다. 도메인 구성 방법에 대한 자세한 내용은 AWS 에 설치를 참조하십시오.
  • OpenShift Container Platform 이미지 풀 시크릿이 있어야 합니다. 이미지 풀 시크릿 사용을 참조하십시오.
  • 허브 클러스터용 기존 Red Hat OpenShift Container Platform 클러스터가 있는 Amazon VPC(Virtual Private Cloud)가 있어야 합니다. 이 VPC는 관리 클러스터 리소스 또는 관리형 클러스터 서비스 엔드 포인트에 사용되는 VPC와 달라야 합니다.
  • 관리 클러스터 리소스가 배포되는 VPC가 필요합니다. 허브 클러스터 또는 관리 클러스터 서비스 엔드 포인트에 사용되는 VPC와 같을 수 없습니다.
  • 관리 클러스터 서비스 엔드 포인트를 제공하는 VPC가 하나 이상 필요합니다. Hub 클러스터 또는 관리 클러스터 리소스에 사용되는 VPC와 같을 수 없습니다.
  • CIDR(Classless Inter-Domain Routing)으로 지정된 VPC의 IP 주소가 겹치지 않는지 확인합니다.
  • Hive 네임스페이스 내에서 인증 정보를 참조하는 HiveConfig 사용자 정의 리소스가 필요합니다. 이 사용자 정의 리소스는 관리형 클러스터 서비스 엔드포인트에 대해 생성한 VPC에 리소스를 생성할 수 있어야 합니다.

참고: 클라우드 공급자의 클라우드 공급자 액세스 키를 변경하는 경우 다중 클러스터 엔진 Operator 콘솔에서 클라우드 공급자에 대한 해당 인증 정보도 수동으로 업데이트해야 합니다. 이는 관리 클러스터가 호스팅되는 클라우드 공급자에서 인증 정보가 만료되고 관리 클러스터를 삭제하려고 할 때 필요합니다.

1.7.3.4.2. AWS GovCloud에 배포하도록 Hive 구성
링크 복사

AWS GovCloud에서 클러스터를 생성하는 것은 표준 AWS에서 클러스터를 생성하는 것과 거의 동일하지만 AWS GovCloud에서 클러스터에 대한 AWS PrivateLink를 준비하기 위해 몇 가지 추가 단계를 완료해야 합니다.

1.7.3.4.2.1. 리소스 및 엔드포인트에 대한 VPC 생성
링크 복사

사전 요구 사항에 나열된 대로 허브 클러스터가 포함된 VPC 외에도 두 개의 VPC가 필요합니다. VPC를 생성하기 위한 특정 단계는 Amazon Web Services 설명서에서 VPC 생성을 참조하십시오.

  1. 프라이빗 서브넷을 사용하여 관리형 클러스터의 VPC를 생성합니다.
  2. 프라이빗 서브넷을 사용하여 관리형 클러스터 서비스 엔드 포인트에 대해 VPC를 하나 이상 생성합니다. 리전의 각 VPC에는 255개의 VPC 끝점이 있으므로 해당 리전에서 255개 이상의 클러스터를 지원하려면 여러 VPC가 필요합니다.

  3. 각 VPC에 대해 해당 리전의 지원되는 모든 가용성 영역에 서브넷을 생성합니다. 각 서브넷에는 컨트롤러 요구 사항으로 인해 최소 255개의 사용 가능한 IP 주소가 있어야 합니다.

    다음 예제에서는 us-gov-east-1 리전에 6개의 가용성 영역이 있는 VPC의 서브넷을 구조화하는 방법을 보여줍니다. 

    vpc-1 (us-gov-east-1) : 10.0.0.0/20
  subnet-11 (us-gov-east-1a): 10.0.0.0/23
  subnet-12 (us-gov-east-1b): 10.0.2.0/23
  subnet-13 (us-gov-east-1c): 10.0.4.0/23
  subnet-12 (us-gov-east-1d): 10.0.8.0/23
  subnet-12 (us-gov-east-1e): 10.0.10.0/23
  subnet-12 (us-gov-east-1f): 10.0.12.0/2
    Copy to Clipboard Toggle word wrap 
    vpc-2 (us-gov-east-1) : 10.0.16.0/20
  subnet-21 (us-gov-east-1a): 10.0.16.0/23
  subnet-22 (us-gov-east-1b): 10.0.18.0/23
  subnet-23 (us-gov-east-1c): 10.0.20.0/23
  subnet-24 (us-gov-east-1d): 10.0.22.0/23
  subnet-25 (us-gov-east-1e): 10.0.24.0/23
  subnet-26 (us-gov-east-1f): 10.0.28.0/23
    Copy to Clipboard Toggle word wrap
  4. 모든 허브 환경(hub 클러스터 VPC)이 피어링, 전송 게이트웨이를 사용하는 VPC 끝점에 대해 생성한 VPC에 대한 네트워크 연결이 있고 모든 DNS 설정이 활성화되어 있는지 확인합니다.
  5. AWS GovCloud 연결에 필요한 AWS PrivateLink의 DNS 설정을 확인하는 데 필요한 VPC 목록을 수집합니다. 여기에는 최소한 구성 중인 다중 클러스터 엔진 Operator 인스턴스의 VPC가 포함되며, 다양한 Hive 컨트롤러가 존재하는 모든 VPC 목록을 포함할 수 있습니다.
1.7.3.4.2.2. VPC 끝점의 보안 그룹 구성
링크 복사

AWS의 각 VPC 끝점에는 끝점에 대한 액세스를 제어하기 위해 연결된 보안 그룹이 있습니다. Hive는 VPC 끝점을 생성할 때 보안 그룹을 지정하지 않습니다. VPC의 기본 보안 그룹은 VPC 끝점에 연결되어 있습니다. VPC의 기본 보안 그룹에는 Hive 설치 프로그램 Pod에서 VPC 엔드 포인트가 생성되는 트래픽을 허용하기 위한 규칙이 있어야 합니다. 자세한 내용은 AWS 문서의 엔드 포인트 정책을 사용하여 VPC 끝점에 대한 액세스 제어를 참조하십시오.

예를 들어 Hive가 hive-vpc(10.1.0.0/16) 에서 실행되는 경우 VPC의 기본 보안 그룹에는 10.1.0.0/16 에서 수신할 수 있는 VPC 끝점이 생성되는 규칙이 있어야 합니다.

1.7.3.4.3. 콘솔을 사용하여 클러스터 생성
링크 복사

콘솔에서 클러스터를 생성하려면 Infrastructure > Clusters > Create cluster > Standalone 로 이동하여 콘솔의 단계를 완료합니다.

참고: 이 절차는 클러스터를 생성하기 위한 것입니다. 가져올 기존 클러스터가 있는 경우 해당 단계에 대한 클러스터 가져오기 를 참조하십시오.

선택한 인증 정보는 AWS GovCloud 클러스터를 생성하는 경우 AWS GovCloud 리전의 리소스에 액세스할 수 있어야 합니다. 클러스터를 배포하는 데 필요한 권한이 있는 경우 Hive 네임스페이스에 이미 있는 AWS GovCloud 시크릿을 사용할 수 있습니다. 기존 인증 정보가 콘솔에 표시됩니다. 인증 정보를 생성해야 하는 경우 자세한 내용은 Amazon Web Services에 대한 인증 정보 생성 을 참조하십시오.

클러스터 이름은 클러스터의 호스트 이름에 사용됩니다.

중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 모든 리소스가 삭제됩니다.

팁: 콘솔에서 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML 을 선택합니다.

기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin 권한이 없는 경우 clusterset-admin 권한이 있는 클러스터 세트를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없는 경우 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 클러스터 세트에 clusterset-admin 권한을 제공하려면 클러스터 관리자에게 문의하십시오.

모든 관리 클러스터는 관리 클러스터 세트와 연결되어 있어야 합니다. ManagedClusterSet 에 관리 클러스터를 할당하지 않으면 기본 관리 클러스터 세트에 자동으로 추가됩니다.

AWS 또는 AWS GovCloud 계정으로 구성한 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 값이 필드에 채워집니다. 값을 덮어 쓰기하여 변경할 수 있습니다. 이 이름은 클러스터의 호스트 이름에 사용됩니다. 자세한 내용은 AWS에 설치를 참조하십시오.

릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전을 사용할 수 있는 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지의 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지 릴리스를 참조하십시오.

노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동 관리를 공유합니다. 정보에는 다음 필드가 포함됩니다.

  • region: 클러스터 리소스를 생성하는 리전입니다. AWS GovCloud 공급자에 클러스터를 생성하는 경우 노드 풀의 AWS GovCloud 리전을 포함해야 합니다. 예를 들면 us-gov-west-1 입니다.
  • CPU 아키텍처: 관리 클러스터의 아키텍처 유형이 허브 클러스터의 아키텍처와 동일하지 않으면 풀에 있는 시스템의 명령 집합 아키텍처 값을 입력합니다. 유효한 값은 amd64,ppc64le,s390x 및 arm64 입니다.
  • zones: 컨트롤 플레인 풀을 실행할 위치를 지정합니다. 더 분산된 컨트롤 플레인 노드 그룹에 대해 리전 내에서 여러 영역을 선택할 수 있습니다. 더 가까운 영역은 더 빠른 성능을 제공할 수 있지만 더 멀리 있는 영역이 더 분산될 수 있습니다.
  • 인스턴스 유형: 이전에 지정한 CPU 아키텍처와 동일해야 하는 컨트롤 플레인 노드의 인스턴스 유형을 지정합니다. 인스턴스 유형 및 크기를 생성한 후 변경할 수 있습니다.
  • 루트 스토리지: 클러스터에 할당할 루트 스토리지 크기를 지정합니다.

작업자 풀에 0개 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 단일 작업자 풀에 있거나 여러 작업자 풀에 배포할 수 있습니다. 제로 작업자 노드가 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 선택적 정보에는 다음 필드가 포함됩니다.

  • 풀 이름: 풀에 고유한 이름을 제공합니다.
  • zones: 작업자 풀을 실행할 위치를 지정합니다. 더 분산된 노드 그룹에 대해 리전 내에서 여러 영역을 선택할 수 있습니다. 더 가까운 영역은 더 빠른 성능을 제공할 수 있지만 더 멀리 있는 영역이 더 분산될 수 있습니다.
  • 인스턴스 유형: 작업자 풀의 인스턴스 유형을 지정합니다. 인스턴스 유형 및 크기를 생성한 후 변경할 수 있습니다.
  • 노드 수: 작업자 풀의 노드 수를 지정합니다. 이 설정은 작업자 풀을 정의할 때 필요합니다.
  • 루트 스토리지: 작업자 풀에 할당된 루트 스토리지의 양을 지정합니다. 이 설정은 작업자 풀을 정의할 때 필요합니다.

클러스터에 네트워킹 세부 정보가 필요하며 IPv6를 사용하려면 여러 네트워크가 필요합니다. AWS GovCloud 클러스터의 경우 Machine CIDR 필드에 Hive VPC의 주소 블록 값을 입력합니다. 네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다.

인증 정보에 제공된 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나, 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시를 생성하는 데 필요한 정보가 포함되어 있습니다.

  • HTTP 프록시 URL: HTTP 트래픽의 프록시로 사용해야 하는 URL을 지정합니다.
  • HTTPS 프록시 URL: HTTPS 트래픽에 사용해야 하는 보안 프록시 URL을 지정합니다. 값을 제공하지 않으면 HTTP 및 HTTPS 모두에 HTTP 프록시 URL 과 동일한 값이 사용됩니다.
  • 프록시 도메인 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 마침표로 도메인 이름을 시작합니다 . 를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표 * 를 추가합니다.
  • 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.

AWS GovCloud 클러스터를 생성하거나 프라이빗 환경을 사용하는 경우 AMI ID 및 서브넷 값을 사용하여 AWS 개인 구성 페이지의 필드를 완료합니다. ClusterDeployment.yaml 파일에서 spec:platform:aws:privateLink:enabled 값이 true 로 설정되어 있는지 확인합니다. 이 값은 개인 구성 사용을 선택할 때 자동으로 설정됩니다.

정보를 검토하고 선택적으로 클러스터를 생성하기 전에 사용자 지정할 때 YAML: On 을 선택하여 패널의 install-config.yaml 파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.

참고: 클러스터를 가져오기 위해 클러스터 세부 정보가 제공된 oc 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 Kubernetes 운영자를 위한 다중 클러스터 엔진 관리 아래에 자동으로 구성됩니다.

Kubernetes용 Red Hat Advanced Cluster Management를 사용하고 관리 클러스터 klusterlet을 특정 노드에서 실행하도록 구성하려면 선택 사항: 필요한 단계를 위해 특정 노드에서 실행되도록 klusterlet 구성 을 참조하십시오.

클러스터에 액세스하는 방법에 대한 지침은 클러스터 액세스를 계속합니다.

1.7.3.5. Microsoft Azure에 클러스터 생성
링크 복사

다중 클러스터 엔진 Operator 콘솔을 사용하여 Microsoft Azure 또는 Microsoft Azure Government에 Red Hat OpenShift Container Platform 클러스터를 배포할 수 있습니다.

클러스터를 생성할 때 생성 프로세스는 OpenShift Container Platform 설치 프로그램을 Hive 리소스와 함께 사용합니다. 이 절차를 완료한 후 클러스터 생성에 대한 질문이 있는 경우 OpenShift Container Platform 설명서의 Azure에 프로세스에 대한 자세한 내용은 설치를 참조하십시오.

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

Azure에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.

참고: 클라우드 공급자의 클라우드 공급자 액세스 키를 변경하는 경우 다중 클러스터 엔진 Operator 콘솔에서 클라우드 공급자에 대한 해당 인증 정보도 수동으로 업데이트해야 합니다. 이는 관리 클러스터가 호스팅되는 클라우드 공급자에서 인증 정보가 만료되고 관리 클러스터를 삭제하려고 할 때 필요합니다.

1.7.3.5.2. 콘솔을 사용하여 클러스터 생성
링크 복사

다중 클러스터 엔진 Operator 콘솔에서 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 생성 을 클릭하고 콘솔의 단계를 완료합니다.

참고: 이 절차는 클러스터를 생성하기 위한 것입니다. 가져올 기존 클러스터가 있는 경우 해당 단계에 대한 클러스터 가져오기 를 참조하십시오.

인증 정보를 생성해야 하는 경우 자세한 내용은 Microsoft Azure에 대한 인증 정보 생성 을 참조하십시오.

클러스터 이름은 클러스터의 호스트 이름에 사용됩니다.

중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 모든 리소스가 삭제됩니다.

팁: 콘솔에서 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML 을 선택합니다.

기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin 권한이 없는 경우 clusterset-admin 권한이 있는 클러스터 세트를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없는 경우 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 클러스터 세트에 clusterset-admin 권한을 제공하려면 클러스터 관리자에게 문의하십시오.

모든 관리 클러스터는 관리 클러스터 세트와 연결되어 있어야 합니다. ManagedClusterSet 에 관리 클러스터를 할당하지 않으면 기본 관리 클러스터 세트에 자동으로 추가됩니다.

Azure 계정에 대해 구성한 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 값이 해당 필드에 채워집니다. 값을 덮어 쓰기하여 변경할 수 있습니다. 자세한 내용은 Azure 클라우드 서비스의 사용자 정의 도메인 이름 구성 을 참조하십시오. 이 이름은 클러스터의 호스트 이름에 사용됩니다.

릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전을 사용할 수 있는 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지의 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지 릴리스를 참조하십시오.

노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동 관리를 공유합니다. 정보에는 다음과 같은 선택적 필드가 포함됩니다.

  • region: 노드 풀을 실행할 리전을 지정합니다. 더 분산된 컨트롤 플레인 노드 그룹에 대해 리전 내에서 여러 영역을 선택할 수 있습니다. 더 가까운 영역은 더 빠른 성능을 제공할 수 있지만 더 멀리 있는 영역이 더 분산될 수 있습니다.
  • CPU 아키텍처: 관리 클러스터의 아키텍처 유형이 허브 클러스터의 아키텍처와 동일하지 않으면 풀에 있는 시스템의 명령 집합 아키텍처 값을 입력합니다. 유효한 값은 amd64,ppc64le,s390x 및 arm64 입니다.

클러스터를 생성한 후 컨트롤 플레인 풀의 인스턴스 유형 및 크기 및 루트 스토리지 할당(필수)을 변경할 수 있습니다.

작업자 풀에서 하나 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 단일 작업자 풀에 있거나 여러 작업자 풀에 배포할 수 있습니다. 제로 작업자 노드가 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 정보에는 다음 필드가 포함됩니다.

  • zones: 작업자 풀을 실행할 위치를 지정합니다. 더 분산된 노드 그룹에 대해 리전 내에서 여러 영역을 선택할 수 있습니다. 더 가까운 영역은 더 빠른 성능을 제공할 수 있지만 더 멀리 있는 영역이 더 분산될 수 있습니다.
  • 인스턴스 유형: 인스턴스 유형을 만든 후 인스턴스의 유형과 크기를 변경할 수 있습니다.

네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다. IPv6 주소를 사용하는 경우 두 개 이상의 네트워크가 있어야 합니다.

인증 정보에 제공된 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나, 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시를 생성하는 데 필요한 정보가 포함되어 있습니다.

  • HTTP 프록시: HTTP 트래픽의 프록시로 사용해야 하는 URL입니다.
  • HTTPS 프록시: HTTPS 트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면 HTTP 및 HTTPS 모두에 HTTP 프록시 URL 과 동일한 값이 사용됩니다.
  • 프록시 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 마침표로 도메인 이름을 시작합니다 . 를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표 * 를 추가합니다.
  • 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.

정보를 검토하고 선택적으로 클러스터를 생성하기 전에 사용자 지정할 때 YAML 스위치를 클릭하여 패널의 install-config.yaml 파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.

Kubernetes용 Red Hat Advanced Cluster Management를 사용하고 관리 클러스터 klusterlet을 특정 노드에서 실행하도록 구성하려면 선택 사항: 필요한 단계를 위해 특정 노드에서 실행되도록 klusterlet 구성 을 참조하십시오.

참고: 클러스터를 가져오기 위해 클러스터 세부 정보가 제공된 oc 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator 관리 아래에 자동으로 구성됩니다.

클러스터에 액세스하는 방법에 대한 지침은 클러스터 액세스를 계속합니다.

1.7.3.6. Google Cloud Platform에서 클러스터 생성
링크 복사

GCP(Google Cloud Platform)에 Red Hat OpenShift Container Platform 클러스터를 생성하려면 절차를 따르십시오. GCP에 대한 자세한 내용은 Google Cloud Platform 을 참조하십시오.

클러스터를 생성할 때 생성 프로세스는 OpenShift Container Platform 설치 프로그램을 Hive 리소스와 함께 사용합니다. 이 절차를 완료한 후 클러스터 생성에 대한 질문이 있는 경우 OpenShift Container Platform 설명서의 GCP에 프로세스에 대한 자세한 내용은 설치를 참조하십시오.

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

GCP에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.

참고: 클라우드 공급자의 클라우드 공급자 액세스 키를 변경하는 경우 다중 클러스터 엔진 Operator 콘솔에서 클라우드 공급자에 대한 해당 인증 정보도 수동으로 업데이트해야 합니다. 이는 관리 클러스터가 호스팅되는 클라우드 공급자에서 인증 정보가 만료되고 관리 클러스터를 삭제하려고 할 때 필요합니다.

1.7.3.6.2. 콘솔을 사용하여 클러스터 생성
링크 복사

다중 클러스터 엔진 Operator 콘솔에서 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 생성 을 클릭하고 콘솔의 단계를 완료합니다.

참고: 이 절차는 클러스터를 생성하기 위한 것입니다. 가져올 기존 클러스터가 있는 경우 해당 단계에 대한 클러스터 가져오기 를 참조하십시오.

인증 정보를 생성해야 하는 경우 자세한 내용은 Google Cloud Platform의 인증 정보 생성 을 참조하십시오.

클러스터 이름은 클러스터의 호스트 이름에 사용됩니다. GCP 클러스터 이름 지정에 적용되는 몇 가지 제한 사항이 있습니다. 이러한 제한에는 goog 로 이름을 시작하거나 이름에 Google 과 유사한 문자 및 숫자 그룹이 포함되어 있지 않습니다. 전체 제한 목록은 버킷 이름 지정 지침을 참조하십시오.

중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 모든 리소스가 삭제됩니다.

팁: 콘솔에서 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML 을 선택합니다.

기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin 권한이 없는 경우 clusterset-admin 권한이 있는 클러스터 세트를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없는 경우 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 클러스터 세트에 clusterset-admin 권한을 제공하려면 클러스터 관리자에게 문의하십시오.

모든 관리 클러스터는 관리 클러스터 세트와 연결되어 있어야 합니다. ManagedClusterSet 에 관리 클러스터를 할당하지 않으면 기본 관리 클러스터 세트에 자동으로 추가됩니다.

GCP 계정에 대해 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 값이 필드에 채워집니다. 값을 덮어 쓰기하여 변경할 수 있습니다. 자세한 내용은 사용자 정의 도메인 설정을 참조하십시오. 이 이름은 클러스터의 호스트 이름에 사용됩니다.

릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전을 사용할 수 있는 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지의 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지 릴리스를 참조하십시오.

노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동 관리를 공유합니다. 정보에는 다음 필드가 포함됩니다.

  • region: 컨트롤 플레인 풀을 실행할 리전을 지정합니다. 가까운 리전은 더 빠른 성능을 제공할 수 있지만 더 멀리 있는 영역이 더 분산될 수 있습니다.
  • CPU 아키텍처: 관리 클러스터의 아키텍처 유형이 허브 클러스터의 아키텍처와 동일하지 않으면 풀에 있는 시스템의 명령 집합 아키텍처 값을 입력합니다. 유효한 값은 amd64,ppc64le,s390x 및 arm64 입니다.

컨트롤 플레인 풀의 인스턴스 유형을 지정할 수 있습니다. 인스턴스 유형 및 크기를 생성한 후 변경할 수 있습니다.

작업자 풀에서 하나 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 단일 작업자 풀에 있거나 여러 작업자 풀에 배포할 수 있습니다. 제로 작업자 노드가 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 정보에는 다음 필드가 포함됩니다.

  • 인스턴스 유형: 인스턴스 유형을 만든 후 인스턴스의 유형과 크기를 변경할 수 있습니다.
  • 노드 수: 이 설정은 작업자 풀을 정의할 때 필요합니다.

네트워킹 세부 정보가 필요하며 IPv6 주소를 사용하려면 여러 네트워크가 필요합니다. 네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다.

인증 정보에 제공된 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나, 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시를 생성하는 데 필요한 정보가 포함되어 있습니다.

  • HTTP 프록시: HTTP 트래픽의 프록시로 사용해야 하는 URL입니다.
  • HTTPS 프록시: HTTPS 트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면 HTTP 및 HTTPS 모두에 HTTP 프록시 URL 과 동일한 값이 사용됩니다.
  • 프록시 사이트 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 사이트 목록입니다. 마침표로 도메인 이름을 시작합니다 . 를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표 * 를 추가합니다.
  • 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.

정보를 검토하고 선택적으로 클러스터를 생성하기 전에 사용자 지정할 때 YAML: On 을 선택하여 패널의 install-config.yaml 파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.

Kubernetes용 Red Hat Advanced Cluster Management를 사용하고 관리 클러스터 klusterlet을 특정 노드에서 실행하도록 구성하려면 선택 사항: 필요한 단계를 위해 특정 노드에서 실행되도록 klusterlet 구성 을 참조하십시오.

참고: 클러스터를 가져오기 위해 클러스터 세부 정보가 제공된 oc 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator 관리 아래에 자동으로 구성됩니다.

클러스터에 액세스하는 방법에 대한 지침은 클러스터 액세스를 계속합니다.

1.7.3.7. VMware vSphere에서 클러스터 생성
링크 복사

다중 클러스터 엔진 Operator 콘솔을 사용하여 VMware vSphere에 Red Hat OpenShift Container Platform 클러스터를 배포할 수 있습니다.

클러스터를 생성할 때 생성 프로세스는 OpenShift Container Platform 설치 프로그램을 Hive 리소스와 함께 사용합니다. 이 절차를 완료한 후 클러스터 생성에 대한 자세한 내용은 OpenShift Container Platform 설명서의 VMware vSphere에 설치를 참조하십시오.

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

vSphere에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.

  • 지원되는 OpenShift Container Platform 버전에 배포된 허브 클러스터가 있어야 합니다.
  • vSphere 인증 정보가 필요합니다. 자세한 내용은 VMware vSphere의 인증 정보 생성 을 참조하십시오.
  • OpenShift Container Platform 이미지 풀 시크릿이 필요합니다. 이미지 풀 시크릿 사용을 참조하십시오.

  • 배포 중인 VMware 인스턴스에 대한 다음 정보가 있어야 합니다.

    • API 및 Ingress 인스턴스에 필요한 고정 IP 주소

    • DNS 레코드:

      • 다음 API 기본 도메인은 정적 API VIP를 가리켜야 합니다. 

        api.<cluster_name>.<base_domain>
        Copy to Clipboard Toggle word wrap
      • 다음 애플리케이션 기본 도메인에서 Ingress VIP의 고정 IP 주소를 가리켜야 합니다 . *.apps.<cluster_name>.<base_domain>
1.7.3.7.2. 콘솔을 사용하여 클러스터 생성
링크 복사

다중 클러스터 엔진 Operator 콘솔에서 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 생성 을 클릭하고 콘솔의 단계를 완료합니다.

참고: 이 절차는 클러스터를 생성하기 위한 것입니다. 가져올 기존 클러스터가 있는 경우 해당 단계에 대한 클러스터 가져오기 를 참조하십시오.

인증 정보를 생성해야 하는 경우 인증 정보 생성에 대한 자세한 내용은 VMware vSphere의 인증 정보 생성 을 참조하십시오.

클러스터 이름은 클러스터의 호스트 이름에 사용됩니다.

중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 모든 리소스가 삭제됩니다.

팁: 콘솔에서 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML 을 선택합니다.

기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin 권한이 없는 경우 clusterset-admin 권한이 있는 클러스터 세트를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없는 경우 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 클러스터 세트에 clusterset-admin 권한을 제공하려면 클러스터 관리자에게 문의하십시오.

모든 관리 클러스터는 관리 클러스터 세트와 연결되어 있어야 합니다. ManagedClusterSet 에 관리 클러스터를 할당하지 않으면 기본 관리 클러스터 세트에 자동으로 추가됩니다.

vSphere 계정에 대해 구성한 선택한 인증 정보와 연결된 기본 도메인이 이미 있는 경우 해당 값이 필드에 채워집니다. 값을 덮어 쓰기하여 변경할 수 있습니다. 자세한 내용은 사용자 지정으로 vSphere에 클러스터 설치를 참조하십시오. 이 값은 사전 요구 사항 섹션에 나열된 DNS 레코드를 생성하는 데 사용한 이름과 일치해야 합니다. 이 이름은 클러스터의 호스트 이름에 사용됩니다.

릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전을 사용할 수 있는 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지의 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지 릴리스를 참조하십시오.

참고: 지원되는 OpenShift Container Platform 버전의 릴리스 이미지를 선택합니다.

노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동 관리를 공유합니다. 정보에는 CPU 아키텍처 필드가 포함됩니다. 다음 필드 설명을 표시합니다.

  • CPU 아키텍처: 관리 클러스터의 아키텍처 유형이 허브 클러스터의 아키텍처와 동일하지 않으면 풀에 있는 시스템의 명령 집합 아키텍처 값을 입력합니다. 유효한 값은 amd64,ppc64le,s390x 및 arm64 입니다.

작업자 풀에서 하나 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 단일 작업자 풀에 있거나 여러 작업자 풀에 배포할 수 있습니다. 제로 작업자 노드가 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 정보에는 소켓당 코어,CPU,Memory_min MiB, _Disk 크기 (GiB) 및 노드 수가 포함됩니다.

네트워킹 정보가 필요합니다. IPv6를 사용하려면 여러 네트워크가 필요합니다. 필수 네트워킹 정보 중 일부는 다음 필드를 포함합니다.

  • vSphere 네트워크 이름: VMware vSphere 네트워크 이름을 지정합니다.

  • API VIP: 내부 API 통신에 사용할 IP 주소를 지정합니다.

    참고: 이 값은 사전 요구 사항 섹션에 나열된 DNS 레코드를 생성하는 데 사용한 이름과 일치해야 합니다. 제공되지 않는 경우 api. 가 올바르게 확인되도록 DNS를 사전 구성해야 합니다.

  • Ingress VIP: 인그레스 트래픽에 사용할 IP 주소를 지정합니다.

    참고: 이 값은 사전 요구 사항 섹션에 나열된 DNS 레코드를 생성하는 데 사용한 이름과 일치해야 합니다. 제공되지 않는 경우 test.apps. 가 올바르게 확인되도록 DNS를 사전 구성해야 합니다.

네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다. IPv6 주소를 사용하는 경우 두 개 이상의 네트워크가 있어야 합니다.

인증 정보에 제공된 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나, 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시를 생성하는 데 필요한 정보가 포함되어 있습니다.

  • HTTP 프록시: HTTP 트래픽의 프록시로 사용해야 하는 URL을 지정합니다.
  • HTTPS 프록시: HTTPS 트래픽에 사용해야 하는 보안 프록시 URL을 지정합니다. 값을 제공하지 않으면 HTTP 및 HTTPS 모두에 HTTP 프록시 URL 과 동일한 값이 사용됩니다.
  • 프록시 사이트 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 사이트 목록을 제공합니다. 마침표로 도메인 이름을 시작합니다 . 를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표 * 를 추가합니다.
  • 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.

Disconnected installation 을 클릭하여 연결이 끊긴 설치를 정의합니다. VMware vSphere 공급자 및 연결이 끊긴 설치를 사용하여 클러스터를 생성할 때 미러 레지스트리에 액세스하는 데 인증서가 필요한 경우 인증 정보를 구성할 때 구성 섹션의 추가 신뢰 번들 필드에 또는 클러스터를 생성할 때 연결 해제된 설치 섹션에 입력해야 합니다.

자동화 템플릿 추가를 클릭하여 템플릿을 생성할 수 있습니다.

정보를 검토하고 선택적으로 클러스터를 생성하기 전에 사용자 지정할 때 YAML 스위치를 클릭하여 패널의 install-config.yaml 파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.

Kubernetes용 Red Hat Advanced Cluster Management를 사용하고 관리 클러스터 klusterlet을 특정 노드에서 실행하도록 구성하려면 선택 사항: 필요한 단계를 위해 특정 노드에서 실행되도록 klusterlet 구성 을 참조하십시오.

참고: 클러스터를 가져오기 위해 클러스터 세부 정보가 제공된 oc 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator 관리 아래에 자동으로 구성됩니다.

클러스터에 액세스하는 방법에 대한 지침은 클러스터 액세스를 계속합니다.

1.7.3.8. Red Hat OpenStack Platform에서 클러스터 생성
링크 복사

다중 클러스터 엔진 Operator 콘솔을 사용하여 Red Hat OpenStack Platform에 Red Hat OpenShift Container Platform 클러스터를 배포할 수 있습니다.

클러스터를 생성할 때 생성 프로세스는 OpenShift Container Platform 설치 프로그램을 Hive 리소스와 함께 사용합니다. 이 절차를 완료한 후 클러스터 생성에 대한 질문이 있는 경우 OpenShift Container Platform 설명서의 OpenStack에 프로세스에 대한 자세한 내용은 설치를 참조하십시오.

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

Red Hat OpenStack Platform에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.

  • OpenShift Container Platform 버전 4.6 이상에 배포된 허브 클러스터가 있어야 합니다.
  • Red Hat OpenStack Platform 인증 정보가 있어야 합니다. 자세한 내용은 Red Hat OpenStack Platform의 인증 정보 생성을 참조하십시오.
  • OpenShift Container Platform 이미지 풀 시크릿이 필요합니다. 이미지 풀 시크릿 사용을 참조하십시오.

  • 배포 중인 Red Hat OpenStack Platform 인스턴스에 대한 다음 정보가 필요합니다.

    • 컨트롤 플레인 및 작업자 인스턴스의 플레이버 이름(예: m1.xlarge)
    • 유동 IP 주소를 제공하는 외부 네트워크의 네트워크 이름
    • API 및 수신 인스턴스에 필요한 유동 IP 주소

    • DNS 레코드:

      • 다음 API 기본 도메인은 API의 유동 IP 주소를 가리켜야 합니다. 

        api.<cluster_name>.<base_domain>
        Copy to Clipboard Toggle word wrap

      • 다음 애플리케이션 기본 도메인은 ingress:app-name의 유동 IP 주소를 가리켜야 합니다. 

        *.apps.<cluster_name>.<base_domain>
        Copy to Clipboard Toggle word wrap
1.7.3.8.2. 콘솔을 사용하여 클러스터 생성
링크 복사

다중 클러스터 엔진 Operator 콘솔에서 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 생성 을 클릭하고 콘솔의 단계를 완료합니다.

참고: 이 절차는 클러스터를 생성하기 위한 것입니다. 가져올 기존 클러스터가 있는 경우 해당 단계에 대한 클러스터 가져오기 를 참조하십시오.

인증 정보를 생성해야 하는 경우 자세한 내용은 Red Hat OpenStack Platform의 인증 정보 생성 을 참조하십시오.

클러스터 이름은 클러스터의 호스트 이름에 사용됩니다. 이름에는 15자 미만이 포함되어야 합니다. 이 값은 인증 정보 사전 요구 사항 섹션에 나열된 DNS 레코드를 생성하는 데 사용한 이름과 일치해야 합니다.

중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 모든 리소스가 삭제됩니다.

팁: 콘솔에서 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML 을 선택합니다.

기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin 권한이 없는 경우 clusterset-admin 권한이 있는 클러스터 세트를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없는 경우 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 클러스터 세트에 clusterset-admin 권한을 제공하려면 클러스터 관리자에게 문의하십시오.

모든 관리 클러스터는 관리 클러스터 세트와 연결되어 있어야 합니다. ManagedClusterSet 에 관리 클러스터를 할당하지 않으면 기본 관리 클러스터 세트에 자동으로 추가됩니다.

Red Hat OpenStack Platform 계정에 대해 구성한 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 값이 필드에 채워집니다. 값을 덮어 쓰기하여 변경할 수 있습니다. 자세한 내용은 Red Hat OpenStack Platform 설명서의 도메인 관리를 참조하십시오. 이 이름은 클러스터의 호스트 이름에 사용됩니다.

릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전을 사용할 수 있는 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지의 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지 릴리스를 참조하십시오. OpenShift Container Platform 버전 4.6.x 이상의 릴리스 이미지만 지원됩니다.

노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동 관리를 공유합니다. 관리 클러스터의 아키텍처 유형이 허브 클러스터의 아키텍처와 동일하지 않은 경우 풀에 있는 시스템의 명령 집합 아키텍처 값을 입력합니다. 유효한 값은 amd64,ppc64le,s390x 및 arm64 입니다.

컨트롤 플레인 풀에 인스턴스 유형을 추가해야 하지만 생성된 후 인스턴스의 유형과 크기를 변경할 수 있습니다.

작업자 풀에서 하나 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 단일 작업자 풀에 있거나 여러 작업자 풀에 배포할 수 있습니다. 제로 작업자 노드가 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 정보에는 다음 필드가 포함됩니다.

  • 인스턴스 유형: 인스턴스 유형을 만든 후 인스턴스의 유형과 크기를 변경할 수 있습니다.
  • 노드 수: 작업자 풀의 노드 수를 지정합니다. 이 설정은 작업자 풀을 정의할 때 필요합니다.

클러스터에 네트워킹 세부 정보가 필요합니다. IPv4 네트워크에 대해 하나 이상의 네트워크에 대한 값을 제공해야 합니다. IPv6 네트워크의 경우 둘 이상의 네트워크를 정의해야 합니다.

네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다. IPv6 주소를 사용하는 경우 두 개 이상의 네트워크가 있어야 합니다.

인증 정보에 제공된 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나, 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시를 생성하는 데 필요한 정보가 포함되어 있습니다.

  • HTTP 프록시: HTTP 트래픽의 프록시로 사용해야 하는 URL을 지정합니다.
  • HTTPS 프록시: HTTPS 트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면 HTTP 및 HTTPS 모두에 HTTP 프록시 와 동일한 값이 사용됩니다.
  • 프록시 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 사이트 목록을 정의합니다. 마침표로 도메인 이름을 시작합니다 . 를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표 * 를 추가합니다.
  • 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.

연결 해제된 설치를 클릭하여 연결 해제된 설치 이미지를 정의할 수 있습니다. Red Hat OpenStack Platform 공급자 및 연결이 끊긴 설치를 사용하여 클러스터를 생성할 때 인증서가 미러 레지스트리에 액세스해야 하는 경우, 클러스터를 생성할 때 연결 해제된 설치 구성 섹션의 추가 신뢰 번들 필드에 입력해야 합니다.

정보를 검토하고 선택적으로 클러스터를 생성하기 전에 사용자 지정할 때 YAML 스위치를 클릭하여 패널의 install-config.yaml 파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.

내부 CA(인증 기관)를 사용하는 클러스터를 생성할 때 다음 단계를 완료하여 클러스터의 YAML 파일을 사용자 지정해야 합니다.

  1. 검토 단계에서 YAML 스위치를 사용하여 CA 인증서 번들로 목록 상단에 Secret 오브젝트를 삽입합니다. 참고: Red Hat OpenStack Platform 환경에서 여러 기관에서 서명한 인증서를 사용하여 서비스를 제공하는 경우 번들에 필요한 모든 엔드포인트를 검증하기 위해 인증서가 포함되어야 합니다. ocp3 이라는 클러스터 추가는 다음 예와 유사합니다. 

    apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: ocp3-openstack-trust
  namespace: ocp3
stringData:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    <Base64 certificate contents here>
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    <Base64 certificate contents here>
    -----END CERTIFICATE----
    Copy to Clipboard Toggle word wrap

  2. Hive ClusterDeployment 오브젝트를 수정하여 다음 예와 유사하게 spec.platform.openstack 에서 certificatesSecretRef 값을 지정합니다. 

    platform:
  openstack:
    certificatesSecretRef:
      name: ocp3-openstack-trust
    credentialsSecretRef:
      name: ocp3-openstack-creds
    cloud: openstack
    Copy to Clipboard Toggle word wrap

    이전 예제에서는 clouds.yaml 파일의 클라우드 이름이 openstack 이라고 가정합니다.

Kubernetes용 Red Hat Advanced Cluster Management를 사용하고 관리 클러스터 klusterlet을 특정 노드에서 실행하도록 구성하려면 선택 사항: 필요한 단계를 위해 특정 노드에서 실행되도록 klusterlet 구성 을 참조하십시오.

참고: 클러스터를 가져오기 위해 클러스터 세부 정보가 제공된 oc 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator 관리 아래에 자동으로 구성됩니다.

클러스터에 액세스하는 방법에 대한 지침은 클러스터 액세스를 계속합니다.

1.7.3.9. 온-프레미스 환경에서 클러스터 생성
링크 복사

콘솔을 사용하여 온프레미스 Red Hat OpenShift Container Platform 클러스터를 생성할 수 있습니다. 단일 노드 OpenShift 클러스터, 다중 노드 클러스터, 컴팩트 3 노드 클러스터를 생성할 수 있습니다. VMware vSphere, Red Hat OpenStack, Nutanix, External 또는 베어 메탈 환경에서 이러한 클러스터를 생성할 수 있습니다.

platform 값은 platform=none 으로 설정되므로 클러스터를 설치하는 플랫폼과 플랫폼 통합이 없습니다. 단일 노드 OpenShift 클러스터에는 컨트롤 플레인 서비스와 사용자 워크로드를 호스팅하는 단일 노드만 있습니다. 클러스터의 리소스 공간을 최소화하려면 이 구성을 사용합니다.

Red Hat OpenShift Container Platform에서 사용할 수 있는 기능인 제로 터치 프로비저닝 기능을 사용하여 에지 리소스에 여러 개의 단일 노드 OpenShift 클러스터를 프로비저닝할 수도 있습니다. 제로 터치 프로비저닝에 대한 자세한 내용은 OpenShift Container Platform 설명서 의 네트워크 맨 위 엣지의 클러스터를 참조하십시오.

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

온-프레미스 환경에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.

  • 지원되는 OpenShift Container Platform 버전에 배포된 허브 클러스터가 있어야 합니다.
  • 구성된 호스트의 호스트 인벤토리를 사용하여 구성된 인프라 환경이 필요합니다.
  • 허브 클러스터(연결됨)에 대한 인터넷 액세스 권한이 있거나 클러스터를 생성하는 데 필요한 이미지를 검색하려면 인터넷에 연결되어 있는 내부 또는 미러 레지스트리에 대한 연결이 있어야 합니다.
  • 구성된 온-프레미스 인증 정보가 필요합니다.
  • OpenShift Container Platform 이미지 풀 시크릿이 필요합니다. 이미지 풀 시크릿 사용을 참조하십시오.

  • 다음 DNS 레코드가 필요합니다.

    • 다음 API 기본 도메인은 정적 API VIP를 가리켜야 합니다.

      api.<cluster_name>.<base_domain>

    • 다음 애플리케이션 기본 도메인은 Ingress VIP의 고정 IP 주소를 가리켜야 합니다.

      *.apps.<cluster_name>.<base_domain>

  • 허브 클러스터 KubeAPIServer 인증서 확인 전략을 검토하고 필요한 경우 전략을 업데이트합니다. 설정에 사용할 전략을 알아보려면 허브 클러스터 KubeAPIServer 확인 전략 구성을 참조하십시오.
1.7.3.9.2. 콘솔을 사용하여 클러스터 생성
링크 복사

콘솔에서 클러스터를 생성하려면 다음 단계를 완료합니다.

  1. Infrastructure > Clusters 로 이동합니다.
  2. 클러스터 페이지에서 클러스터 생성 을 클릭하고 콘솔의 단계를 완료합니다.
  3. 클러스터 유형으로 Host inventory 를 선택합니다.

지원되는 설치에 다음 옵션을 사용할 수 있습니다.

  • 기존 호스트 사용: 기존 호스트 인벤토리에 있는 호스트 목록에서 호스트를 선택합니다.
  • 새 호스트 검색: 기존 인프라 환경에 없는 호스트를 검색합니다. 이미 인프라 환경에 있는 호스트를 사용하는 대신 자체 호스트를 검색합니다.

인증 정보를 생성해야 하는 경우 자세한 내용은 온-프레미스 환경에 대한 인증 정보 만들기 를 참조하십시오.

클러스터 이름은 클러스터의 호스트 이름에 사용됩니다.

중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 모든 리소스가 삭제됩니다.

참고: 콘솔에서 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML 을 선택합니다.

기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin 권한이 없는 경우 clusterset-admin 권한이 있는 클러스터 세트를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없는 경우 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 클러스터 세트에 clusterset-admin 권한을 제공하려면 클러스터 관리자에게 문의하십시오.

모든 관리 클러스터는 관리 클러스터 세트와 연결되어 있어야 합니다. ManagedClusterSet 에 관리 클러스터를 할당하지 않으면 기본 관리 클러스터 세트에 자동으로 추가됩니다.

공급자 계정에 대해 구성한 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 값이 해당 필드에 채워집니다. 값을 덮어 쓰기하여 변경할 수 있지만 클러스터를 생성한 후에는 이 설정을 변경할 수 없습니다. 공급자의 기본 도메인은 Red Hat OpenShift Container Platform 클러스터 구성 요소에 대한 경로를 생성하는 데 사용됩니다. 클러스터 공급자의 DNS에서 SOA(시작 기관) 레코드로 구성됩니다.

OpenShift 버전은 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전을 사용할 수 있는 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지의 URL을 입력할 수 있습니다. 자세한 내용은 릴리스 이미지를 참조하십시오.

지원되는 OpenShift Container Platform 버전을 선택하면 Install single-node OpenShift 를 선택하는 옵션이 표시됩니다. 단일 노드 OpenShift 클러스터에는 컨트롤 플레인 서비스와 사용자 워크로드를 호스팅하는 단일 노드가 포함되어 있습니다. 생성된 후 단일 노드 OpenShift 클러스터에 노드를 추가하는 방법에 대한 자세한 내용은 인프라 환경으로 호스트 스케일링을 참조하십시오.

클러스터가 단일 노드 OpenShift 클러스터로 전환하려면 단일 노드 OpenShift 옵션을 선택합니다. 다음 단계를 완료하여 단일 노드 OpenShift 클러스터에 작업자를 추가할 수 있습니다.

  1. 콘솔에서 Infrastructure > Clusters 로 이동하여 생성 또는 액세스하려는 클러스터의 이름을 선택합니다.
  2. 작업 > 호스트 추가를 선택하여 추가 작업자를 추가합니다.

참고: 단일 노드 OpenShift 컨트롤 플레인에는 8개의 CPU 코어가 필요하지만 다중 노드 컨트롤 플레인 클러스터의 컨트롤 플레인 노드는 4개의 CPU 코어만 필요합니다.

클러스터를 검토하고 저장하면 클러스터가 초안 클러스터로 저장됩니다. 클러스터 페이지에서 클러스터 이름을 선택하여 생성 프로세스를 종료하고 나중에 프로세스를 완료할 수 있습니다.

기존 호스트를 사용하는 경우 호스트를 직접 선택할지 아니면 자동으로 선택하려는 경우 선택합니다. 호스트 수는 선택한 노드 수를 기반으로 합니다. 예를 들어 단일 노드 OpenShift 클러스터에는 하나의 호스트만 필요하지만 표준 3-노드 클러스터에는 3개의 호스트가 필요합니다.

이 클러스터의 요구 사항을 충족하는 사용 가능한 호스트의 위치는 호스트 위치 목록에 표시됩니다. 호스트 배포 및 고가용성 구성을 위해 여러 위치를 선택합니다.

기존 인프라 환경이 없는 새 호스트를 검색하는 경우 Discovery Image를 사용하여 호스트 인벤토리에 호스트 추가 단계를 완료합니다.

호스트가 바인딩되고 검증이 통과되면 다음 IP 주소를 추가하여 클러스터의 네트워킹 정보를 완료합니다.

  • API VIP: 내부 API 통신에 사용할 IP 주소를 지정합니다.

    참고: 이 값은 사전 요구 사항 섹션에 나열된 DNS 레코드를 생성하는 데 사용한 이름과 일치해야 합니다. 제공되지 않는 경우 api. 가 올바르게 확인되도록 DNS를 사전 구성해야 합니다.

  • Ingress VIP: 인그레스 트래픽에 사용할 IP 주소를 지정합니다.

    참고: 이 값은 사전 요구 사항 섹션에 나열된 DNS 레코드를 생성하는 데 사용한 이름과 일치해야 합니다. 제공되지 않는 경우 test.apps. 가 올바르게 확인되도록 DNS를 사전 구성해야 합니다.

Kubernetes용 Red Hat Advanced Cluster Management를 사용하고 관리 클러스터 klusterlet을 특정 노드에서 실행하도록 구성하려면 선택 사항: 필요한 단계를 위해 특정 노드에서 실행되도록 klusterlet 구성 을 참조하십시오.

클러스터 탐색 페이지에서 설치 상태를 볼 수 있습니다.

클러스터에 액세스하는 방법에 대한 지침은 클러스터 액세스를 계속합니다.

1.7.3.9.3. 명령줄을 사용하여 클러스터 생성
링크 복사

중앙 인프라 관리 구성 요소 내에서 지원 설치 관리자 기능을 사용하여 콘솔 없이 클러스터를 생성할 수도 있습니다. 이 절차를 완료하면 생성된 검색 이미지에서 호스트를 부팅할 수 있습니다. 절차 순서는 일반적으로 중요하지 않지만 필요한 순서가 있을 때 표시됩니다.

1.7.3.9.3.1. 네임스페이스 생성
링크 복사

리소스에 대한 네임스페이스가 필요합니다. 공유 네임스페이스의 모든 리소스를 유지하는 것이 더 편리합니다. 이 예제에서는 네임스페이스 이름에 sample-namespace 를 사용하지만 assisted-installer 를 제외한 모든 이름을 사용할 수 있습니다. 다음 파일을 생성하고 적용하여 네임스페이스를 생성합니다. 

apiVersion: v1
kind: Namespace
metadata:
  name: sample-namespace
Copy to Clipboard Toggle word wrap
1.7.3.9.3.2. 네임스페이스에 풀 시크릿 추가
링크 복사

다음 사용자 정의 리소스를 생성하고 적용하여 네임스페이스에 풀 시크릿 을 추가합니다. 

apiVersion: v1
kind: Secret
type: kubernetes.io/dockerconfigjson
metadata:
  name: <pull-secret>
  namespace: sample-namespace
stringData:
  .dockerconfigjson: 'your-pull-secret-json'
1
Copy to Clipboard Toggle word wrap
1
풀 시크릿의 콘텐츠를 추가합니다. 예를 들어 cloud.openshift.com,quay.io 또는 registry.redhat.io 인증이 포함될 수 있습니다.
1.7.3.9.3.3. Generate a ClusterImageSet
링크 복사

다음 사용자 정의 리소스를 생성하고 적용하여 클러스터의 OpenShift Container Platform 버전을 지정하는 CustomImageSet 을 생성합니다. & lt;4.x.0 >을 이름과 releaseImage 모두에 ClusterImageSet 에 사용하는 지원되는 버전으로 바꿉니다. 

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  name: openshift-v<4.x.0>
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:<4.x.0>-rc.0-x86_64
Copy to Clipboard Toggle word wrap

참고: hub 클러스터와 다른 아키텍처가 있는 관리 클러스터를 설치하는 경우 다중 아키텍처 ClusterImageSet 을 생성해야 합니다. 자세한 내용은 다른 아키텍처에 클러스터를 배포할 릴리스 이미지 생성을 참조하십시오.

1.7.3.9.3.4. ClusterDeployment 사용자 정의 리소스 생성
링크 복사

ClusterDeployment 사용자 정의 리소스 정의는 클러스터의 라이프사이클을 제어하는 API입니다. 클러스터 매개변수를 정의하는 spec.ClusterInstallRef 설정에서 AgentClusterInstall 사용자 정의 리소스를 참조합니다.

다음 예제를 기반으로 ClusterDeployment 사용자 정의 리소스를 생성하고 적용합니다. 

apiVersion: hive.openshift.io/v1
kind: ClusterDeployment
metadata:
  name: single-node
  namespace: demo-worker4
spec:
  baseDomain: hive.example.com
  clusterInstallRef:
    group: extensions.hive.openshift.io
    kind: AgentClusterInstall
    name: test-agent-cluster-install
1 

    version: v1beta1
  clusterName: test-cluster
  controlPlaneConfig:
    servingCertificates: {}
  platform:
    agentBareMetal:
      agentSelector:
        matchLabels:
          location: internal
  pullSecretRef:
    name: <pull-secret>
2
Copy to Clipboard Toggle word wrap
1
AgentClusterInstall 리소스의 이름을 사용합니다.
2
네임스페이스에 풀 시크릿 추가에서 다운로드한 풀 시크릿을 사용합니다.
1.7.3.9.3.5. AgentClusterInstall 사용자 정의 리소스 생성
링크 복사

AgentClusterInstall 사용자 정의 리소스에서 클러스터에 대한 많은 요구 사항을 지정할 수 있습니다. 예를 들어 클러스터 네트워크 설정, 플랫폼, 컨트롤 플레인 수 및 작업자 노드를 지정할 수 있습니다.

다음 예와 유사한 사용자 정의 리소스를 생성하고 추가합니다. 

apiVersion: extensions.hive.openshift.io/v1beta1
kind: AgentClusterInstall
metadata:
  name: test-agent-cluster-install
  namespace: demo-worker4
spec:
  platformType: BareMetal
1 

  clusterDeploymentRef:
    name: single-node
2 

  imageSetRef:
    name: openshift-v4.16.0
3 

  networking:
    clusterNetwork:
    - cidr: 10.128.0.0/14
      hostPrefix: 23
    machineNetwork:
    - cidr: 192.168.111.0/24
    serviceNetwork:
    - 172.30.0.0/16
  provisionRequirements:
    controlPlaneAgents: 1
4 

  sshPublicKey: |
5 

    ssh-rsa <public-key-1>
    ssh-rsa <public-key-2>
    ssh-rsa <public-key-3>
Copy to Clipboard Toggle word wrap
1
클러스터가 생성되는 환경의 플랫폼 유형을 지정합니다. 가능한 값은 BareMetal,None,VSphere,Nutanix 또는 External 입니다.
2
ClusterDeployment 리소스에 사용한 것과 동일한 이름을 사용합니다.
3
Generate a ClusterImageSet 에서 생성한 ClusterImageSet을 사용합니다.
4
가능한 값은 1 과 3 입니다. OpenShift Container Platform 버전 4.18 이상을 사용하는 경우 platformType 필드가 BareMetal 또는 None 으로 설정되고 CPU 아키텍처는 x86_64 이므로 4 및 5 를 사용할 수도 있습니다. 컨트롤 플레인 노드는 워크로드를 관리하고 클러스터 상태를 유지 관리하며 안정성을 보장합니다. 3개 이상의 노드를 사용하는 경우 내결함성 및 가용성을 늘리고 실패한 동안 다운타임을 줄일 수 있습니다.
5
설치 후 호스트에 액세스할 수 있도록 하나 이상의 SSH 공개 키를 지정할 수 있습니다.

platformType: 을 External 로 설정하는 경우 외부 사양을 추가해야 합니다. 다음 예제를 참조하십시오. 

apiVersion: extensions.hive.openshift.io/v1beta1
kind: AgentClusterInstall
metadata:
  name: test-agent-cluster-install
  namespace: demo-worker4
spec:
  platformType: External
  external:
    platformName: "myplatform"
1 

    cloudControllerManager: External
2
Copy to Clipboard Toggle word wrap
1
플랫폼 이름을 추가합니다.
2
필드를 empty로 설정하는 경우 {} 은 설치 중에 Cloud Controller Manager를 비활성화합니다. 외부 로 설정하는 경우 Cloud Controller Manager를 활성화하려면 사용자 정의 매니페스트를 추가해야 합니다.
1.7.3.9.3.6. 선택 사항: NMStateConfig 사용자 정의 리소스 생성
링크 복사

NMStateConfig 사용자 지정 리소스는 정적 IP 주소와 같은 호스트 수준 네트워크 구성이 있는 경우에만 필요합니다. NMStateConfig 사용자 지정 리소스를 생성하는 경우 InfraEnv 사용자 정의 리소스를 생성하기 전에 이 단계를 완료해야 합니다. InfraEnv 사용자 정의 리소스의 spec.nmStateConfigLabelSelector 값은 NMStateConfig 사용자 지정 리소스를 참조합니다.

다음 예와 유사한 NMStateConfig 사용자 지정 리소스를 생성하고 적용합니다. 필요한 경우 값을 바꿉니다. 

apiVersion: agent-install.openshift.io/v1beta1
kind: NMStateConfig
metadata:
  name: <mynmstateconfig>
  namespace: <demo-worker4>
  labels:
    demo-nmstate-label: <value>
spec:
  config:
    interfaces:
      - name: eth0
        type: ethernet
        state: up
        mac-address: 02:00:00:80:12:14
        ipv4:
          enabled: true
          address:
            - ip: 192.168.111.30
              prefix-length: 24
          dhcp: false
      - name: eth1
        type: ethernet
        state: up
        mac-address: 02:00:00:80:12:15
        ipv4:
          enabled: true
          address:
            - ip: 192.168.140.30
              prefix-length: 24
          dhcp: false
    dns-resolver:
      config:
        server:
          - 192.168.126.1
    routes:
      config:
        - destination: 0.0.0.0/0
          next-hop-address: 192.168.111.1
          next-hop-interface: eth1
          table-id: 254
        - destination: 0.0.0.0/0
          next-hop-address: 192.168.140.1
          next-hop-interface: eth1
          table-id: 254
  interfaces:
    - name: "eth0"
      macAddress: "02:00:00:80:12:14"
    - name: "eth1"
      macAddress: "02:00:00:80:12:15"
Copy to Clipboard Toggle word wrap

중요:

  • InfraEnv 사용자 정의 리소스에 의 spec.nmStateConfigLabelSelector.matchLabels 필드에 demo-nmstate-label 레이블 이름과 값을 포함해야 합니다.
  • DHCP 또는 정적 네트워크 프로토콜을 사용할 때 MAC 주소를 추가해야 합니다.

spec.config 필드에 추가할 수 있는 NMState에 대한 추가 예제를 보려면 OpenShift Container Platform 설명서의 지원 설치 관리자의 추가 NMState 구성 예제 를 참조하십시오.

1.7.3.9.3.7. InfraEnv 사용자 정의 리소스 생성
링크 복사

InfraEnv 사용자 지정 리소스는 검색 ISO를 생성하는 구성을 제공합니다. 이 사용자 정의 리소스 내에서 프록시 설정, ignition 덮어쓰기 및 NMState 레이블의 값을 식별합니다. 이 사용자 정의 리소스의 spec.nmStateConfigLabelSelector 값은 NMStateConfig 사용자 지정 리소스를 참조합니다.

참고: optional NMStateConfig 사용자 지정 리소스를 포함하려는 경우 InfraEnv 사용자 정의 리소스에서 참조해야 합니다. NMStateConfig 사용자 지정 리소스를 생성하기 전에 InfraEnv 사용자 지정 리소스를 생성하는 경우 InfraEnv 사용자 정의 리소스를 편집하여 NMStateConfig 사용자 지정 리소스를 참조하고 참조가 추가된 후 ISO를 다운로드합니다.

다음 사용자 정의 리소스를 생성하고 적용합니다. 

apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: myinfraenv
  namespace: demo-worker4
spec:
  clusterRef:
    name: single-node
1 

    namespace: demo-worker4
2 

  pullSecretRef:
    name: pull-secret
  sshAuthorizedKey: <your_public_key_here>
  nmStateConfigLabelSelector:
    matchLabels:
      demo-nmstate-label: value
  proxy:
    httpProxy: http://USERNAME:PASSWORD@proxy.example.com:PORT
    httpsProxy: https://USERNAME:PASSWORD@proxy.example.com:PORT
    noProxy: .example.com,172.22.0.0/24,10.10.0.0/24
Copy to Clipboard Toggle word wrap
1
ClusterDeployment 만들기 에서 clusterDeployment 리소스 이름을 바꿉니다.
2
ClusterDeployment 만들기에서 clusterDeployment 리소스 네임스페이스를 교체합니다.
1.7.3.9.3.7.1. InfraEnv 필드 테이블
링크 복사
Expand
필드선택 사항 또는 필수설명

sshAuthorizedKey

선택 사항

검색 ISO 이미지에서 부팅될 때 호스트에 액세스할 수 있는 SSH 공개 키를 지정할 수 있습니다.

nmStateConfigLabelSelector

선택 사항

호스트의 고정 IP, 브리지 및 본딩과 같은 고급 네트워크 구성을 통합합니다. 호스트 네트워크 구성은 선택한 라벨을 사용하여 하나 이상의 NMStateConfig 리소스에 지정됩니다. nmStateConfigLabelSelector 속성은 선택한 라벨과 일치하는 Kubernetes 라벨 선택기입니다. 이 라벨 선택기와 일치하는 모든 NMStateConfig 라벨의 네트워크 구성은 Discovery Image에 포함됩니다. 부팅 시 각 호스트를 네트워크 인터페이스와 비교하고 적절한 구성을 적용합니다.

proxy

선택 사항

proxy 섹션에서 검색하는 동안 호스트에 필요한 프록시 설정을 지정할 수 있습니다.

참고: IPv6로 프로비저닝할 때 noProxy 설정에서 CIDR 주소 블록을 정의할 수 없습니다. 각 주소를 별도로 정의해야 합니다.

1.7.3.9.3.8. 검색 이미지에서 호스트 부팅
링크 복사

나머지 단계에서는 이전 절차의 결과 검색 ISO 이미지에서 호스트를 부팅하는 방법을 설명합니다.

  1. 다음 명령을 실행하여 네임스페이스에서 검색 이미지를 다운로드합니다. 

    curl --insecure -o image.iso $(kubectl -n sample-namespace get infraenvs.agent-install.openshift.io myinfraenv -o=jsonpath="{.status.isoDownloadURL}")
    Copy to Clipboard Toggle word wrap
  2. 검색 이미지를 가상 미디어, USB 드라이브 또는 다른 스토리지 위치로 이동하고 다운로드한 검색 이미지에서 호스트를 부팅합니다.

  3. 에이전트 리소스는 자동으로 생성됩니다. 클러스터에 등록되어 있으며 검색 이미지에서 부팅되는 호스트를 나타냅니다. Agent 사용자 정의 리소스를 승인하고 다음 명령을 실행하여 설치를 시작합니다. 

    oc -n sample-namespace patch agents.agent-install.openshift.io 07e80ea9-200c-4f82-aff4-4932acb773d4 -p '{"spec":{"approved":true}}' --type merge
    Copy to Clipboard Toggle word wrap

    에이전트 이름 및 UUID를 값으로 바꿉니다.

    이전 명령의 출력에 APPROVED 매개변수에 true 값이 포함된 대상 클러스터의 항목이 포함될 때 승인되었는지 확인할 수 있습니다.

1.7.3.9.4. 추가 리소스
링크 복사
1.7.3.10. 프록시 환경에서 클러스터 생성
링크 복사

허브 클러스터가 프록시 서버를 통해 연결된 경우 Red Hat OpenShift Container Platform 클러스터를 생성할 수 있습니다. 클러스터 생성이 성공하려면 다음 상황 중 하나가 true여야 합니다.

  • 다중 클러스터 엔진 Operator는 프록시를 사용하여 인터넷에 대한 관리 클러스터 액세스 권한이 있는 관리형 클러스터와의 개인 네트워크 연결이 있습니다.
  • 관리 클러스터는 인프라 공급자에 있지만 방화벽 포트를 사용하면 관리 클러스터에서 허브 클러스터로 통신할 수 있습니다.

프록시로 구성된 클러스터를 생성하려면 다음 단계를 완료합니다.

  1. Secret에 저장된 install-config YAML에 다음 정보를 추가하여 hub 클러스터에서 cluster-wide-proxy 설정을 구성합니다. 

    apiVersion: v1
kind: Proxy
baseDomain: <domain>
proxy:
  httpProxy: http://<username>:<password>@<proxy.example.com>:<port>
  httpsProxy: https://<username>:<password>@<proxy.example.com>:<port>
  noProxy: <wildcard-of-domain>,<provisioning-network/CIDR>,<BMC-address-range/CIDR>
    Copy to Clipboard Toggle word wrap

    username 을 프록시 서버의 사용자 이름으로 바꿉니다.

    프록시 서버에 액세스하려면 password 를 암호로 바꿉니다.

    proxy.example.com 을 프록시 서버의 경로로 바꿉니다.

    port 를 프록시 서버로 통신 포트로 교체합니다.

    wildcard-of-domain 을 프록시를 바이패스해야 하는 도메인의 항목으로 교체합니다.

    CIDR 표기법에서 provisioning-network/CIDR 를 provisioning 네트워크의 IP 주소 및 할당된 IP 주소 수로 바꿉니다.

    CIDR 표기법에서 BMC-address-range/CIDR 를 BMC 주소 및 주소 수로 바꿉니다.

  2. 클러스터 생성 절차를 완료하여 클러스터를 프로비저닝합니다. 공급자 를 선택하려면 클러스터 생성 을 참조하십시오.

참고: 클러스터를 배포할 때 install-config YAML만 사용할 수 있습니다. 클러스터를 배포한 후 install-config YAML에 대한 새 변경 사항이 적용되지 않습니다. 배포 후 구성을 업데이트하려면 정책을 사용해야 합니다. 자세한 내용은 Pod 정책을 참조하십시오.

1.7.3.10.1. 추가 리소스
링크 복사
1.7.3.11. AgentClusterInstall 프록시 구성
링크 복사

AgentClusterInstall 프록시 필드는 설치 중에 프록시 설정을 결정하고 생성된 클러스터에서 클러스터 전체 프록시 리소스를 생성하는 데 사용됩니다.

1.7.3.11.1. Configuring AgentClusterInstall
링크 복사

AgentClusterInstall 프록시를 구성하려면 AgentClusterInstall 리소스에 프록시 설정을 추가합니다. httpProxy,httpsProxy, noProxy:를 사용하여 다음 YAML 샘플을 참조하십시오. 

apiVersion: extensions.hive.openshift.io/v1beta1
kind: AgentClusterInstall
spec:
  proxy:
    httpProxy: http://<username>:<password>@<proxy.example.com>:<port>
1 

    httpsProxy: https://<username>:<password>@<proxy.example.com>:<port>
2 

    noProxy: <wildcard-of-domain>,<provisioning-network/CIDR>,<BMC-address-range/CIDR>
3
Copy to Clipboard Toggle word wrap
1
httpProxy 는 HTTP 요청에 대한 프록시의 URL입니다. 사용자 이름 및 암호 값을 프록시 서버의 인증 정보로 바꿉니다. proxy.example.com 을 프록시 서버의 경로로 바꿉니다.
2
httpsProxy 는 HTTPS 요청의 프록시 URL입니다. 값을 자격 증명으로 바꿉니다. port 를 프록시 서버로 통신 포트로 교체합니다.
3
noProxy 는 프록시를 사용하지 않아야 하는 쉼표로 구분된 도메인 및 CIDR 목록입니다. wildcard-of-domain 을 프록시를 바이패스해야 하는 도메인의 항목으로 교체합니다. CIDR 표기법에서 provisioning-network/CIDR 를 provisioning 네트워크의 IP 주소 및 할당된 IP 주소 수로 바꿉니다. CIDR 표기법에서 BMC-address-range/CIDR 를 BMC 주소 및 주소 수로 바꿉니다.
1.7.3.11.2. 추가 리소스
링크 복사

1.7.4. 클러스터 가져오기
링크 복사

다른 Kubernetes 클라우드 공급자에서 클러스터를 가져올 수 있습니다. 가져오기 후 대상 클러스터는 다중 클러스터 엔진 Operator 허브 클러스터의 관리 클러스터가 됩니다. 별도로 지정하지 않는 한 일반적으로 hub 클러스터 및 대상 관리 클러스터에 액세스할 수 있는 가져오기 작업을 완료할 수 있습니다.

  • 허브 클러스터는 다른 허브 클러스터를 관리할 수 없지만 자체적으로 관리할 수 있습니다. 허브 클러스터는 자동으로 가져와 자체 관리하도록 구성됩니다. 허브 클러스터를 수동으로 가져올 필요가 없습니다.
  • 허브 클러스터를 제거하고 다시 가져오려고 하는 경우 ManagedCluster 리소스에 local-cluster:true 레이블을 추가해야 합니다.

중요: 클러스터 라이프사이클은 이제 CCNCF(Cloud Native Computing Foundation) Kubernetes 적합성 프로그램을 통해 인증된 모든 공급자를 지원합니다. 하이브리드 클라우드 멀티 클러스터 관리를 위해 CNFC에서 인식하는 공급 업체를 선택합니다.

CNFC 공급자 사용에 대한 다음 정보를 참조하십시오.

다음 주제를 읽고 클러스터를 관리할 수 있도록 클러스터 가져오기에 대해 자세히 알아보십시오.

필수 사용자 유형 또는 액세스 수준: 클러스터 관리자

1.7.4.1. 콘솔을 사용하여 관리 클러스터 가져오기
링크 복사

Kubernetes Operator용 다중 클러스터 엔진을 설치한 후 관리할 클러스터를 가져올 준비가 된 것입니다. 다음 주제를 계속 읽으십시오. 콘솔을 사용하여 관리 클러스터를 가져오는 방법에 대해 알아봅니다.

1.7.4.1.1. 사전 요구 사항
링크 복사
  • 배포된 허브 클러스터입니다. 베어 메탈 클러스터를 가져오는 경우 지원되는 Red Hat OpenShift Container Platform 버전에 hub 클러스터를 설치해야 합니다.
  • 관리할 클러스터입니다.
  • base64 명령줄 툴입니다.
  • OpenShift Container Platform에서 생성하지 않은 클러스터를 가져오는 경우 정의된 multiclusterhub.spec.imagePullSecret 입니다. 이 시크릿은 Kubernetes Operator의 다중 클러스터 엔진을 설치할 때 생성될 수 있습니다. 이 보안을 정의하는 방법에 대한 자세한 내용은 사용자 정의 이미지 가져오기 보안을 참조하십시오.
  • 허브 클러스터 KubeAPIServer 인증서 확인 전략을 검토하고 필요한 경우 전략을 업데이트합니다. 설정에 사용할 전략을 알아보려면 허브 클러스터 KubeAPIServer 확인 전략 구성을 참조하십시오.

필수 사용자 유형 또는 액세스 수준: 클러스터 관리자

1.7.4.1.2. 새 풀 시크릿 생성
링크 복사

새 풀 시크릿을 생성해야 하는 경우 다음 단계를 완료합니다.

  1. cloud.redhat.com 에서 Kubernetes 풀 시크릿을 다운로드합니다.
  2. 허브 클러스터의 네임스페이스에 풀 시크릿을 추가합니다.

  3. 다음 명령을 실행하여 open-cluster-management 네임스페이스에 새 시크릿을 생성합니다. 

    oc create secret generic pull-secret -n <open-cluster-management> --from-file=.dockerconfigjson=<path-to-pull-secret> --type=kubernetes.io/dockerconfigjson
    Copy to Clipboard Toggle word wrap

    open-cluster-management 를 hub 클러스터의 네임스페이스 이름으로 교체합니다. hub 클러스터의 기본 네임스페이스는 open-cluster-management 입니다.

    path-to-pull-secret 을 다운로드한 풀 시크릿 경로로 교체합니다.

    시크릿을 가져올 때 관리 클러스터에 자동으로 복사됩니다.

    • 이전에 설치한 에이전트가 가져올 클러스터에서 삭제되었는지 확인합니다. 오류를 방지하려면 open-cluster-management-agent 및 open-cluster-management-agent-addon 네임스페이스를 제거해야 합니다.

    • Red Hat OpenShift Dedicated 환경에서 가져오려면 다음 노트를 참조하십시오.

      • Red Hat OpenShift Dedicated 환경에 hub 클러스터가 배포되어 있어야 합니다.
      • Red Hat OpenShift Dedicated의 기본 권한은 dedicated-admin이지만 네임스페이스를 생성할 수 있는 모든 권한이 포함되지는 않습니다. 다중 클러스터 엔진 Operator를 사용하여 클러스터를 가져오고 관리하려면 cluster-admin 권한이 있어야 합니다.
1.7.4.1.3. 클러스터 가져오기
링크 복사

사용 가능한 각 클라우드 공급자에 대해 콘솔에서 기존 클러스터를 가져올 수 있습니다.

참고: 허브 클러스터는 다른 허브 클러스터를 관리할 수 없습니다. 허브 클러스터는 자동으로 자체적으로 가져오기 및 관리하도록 설정되어 있으므로 자체적으로 관리하기 위해 허브 클러스터를 수동으로 가져올 필요가 없습니다.

기본적으로 네임스페이스는 클러스터 이름과 네임스페이스에 사용되지만 변경할 수 있습니다.

중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 모든 리소스가 삭제됩니다.

모든 관리 클러스터는 관리 클러스터 세트와 연결되어 있어야 합니다. ManagedClusterSet 에 관리 클러스터를 할당하지 않으면 클러스터가 기본 관리 클러스터 세트에 자동으로 추가됩니다.

다른 클러스터 세트에 클러스터를 추가하려면 클러스터 세트에 clusterset-admin 권한이 있어야 합니다. 클러스터를 가져올 때 cluster-admin 권한이 없는 경우 clusterset-admin 권한이 있는 클러스터 세트를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없는 경우 클러스터 가져오기에 실패합니다. 클러스터에서 선택할 수 있는 옵션이 없는 경우 클러스터 세트에 clusterset-admin 권한을 제공하려면 클러스터 관리자에게 문의하십시오.

OpenShift Container Platform Dedicated 클러스터를 가져오고 vendor=OpenShiftDedicated 의 레이블을 추가하여 공급 업체를 지정하지 않거나 vendor=auto-detect 에 대한 레이블을 추가하면 managed-by=platform 레이블이 클러스터에 자동으로 추가됩니다. 이 추가된 레이블을 사용하여 OpenShift Container Platform Dedicated 클러스터로 클러스터를 식별하고 OpenShift Container Platform Dedicated 클러스터를 그룹으로 검색할 수 있습니다.

다음 표에서는 클러스터를 가져오는 방법을 지정하는 가져오기 모드에 사용할 수 있는 옵션을 제공합니다.

Expand

수동으로 가져오기 명령 실행

Red Hat Ansible Automation Platform 템플릿을 포함하여 콘솔에 정보를 작성하고 제출한 후 대상 클러스터에서 제공된 명령을 실행하여 클러스터를 가져옵니다.

기존 클러스터의 서버 URL 및 API 토큰을 입력합니다.

가져오려는 클러스터의 서버 URL 및 API 토큰을 제공합니다. 클러스터를 업그레이드할 때 실행할 Red Hat Ansible Automation Platform 템플릿을 지정할 수 있습니다.

kubeconfig 파일 제공

가져오려는 클러스터의 kubeconfig 파일 내용을 복사하여 붙여넣습니다. 클러스터를 업그레이드할 때 실행할 Red Hat Ansible Automation Platform 템플릿을 지정할 수 있습니다.

참고: Ansible Automation Platform 작업을 생성하고 실행하려면 OperatorHub에서 Red Hat Ansible Automation Platform Resource Operator가 설치되어 있어야 합니다.

클러스터 API 주소를 구성하려면 선택 사항: 클러스터 API 주소 구성을 참조하십시오.

관리 클러스터 klusterlet을 특정 노드에서 실행하도록 구성하려면 선택 사항: 특정 노드에서 실행되도록 klusterlet 구성을 참조하십시오.

1.7.4.1.3.1. 선택사항: 클러스터 API 주소 구성
링크 복사

oc get managedcluster 명령을 실행할 때 표에 표시되는 URL을 구성하여 클러스터 세부 정보 페이지에 있는 클러스터 API 주소를 선택적으로 구성하려면 다음 단계를 완료합니다.

  1. cluster-admin 권한이 있는 ID를 사용하여 허브 클러스터에 로그인합니다.
  2. 대상 관리 클러스터에 대한 kubeconfig 파일을 구성합니다.

  3. 다음 명령을 실행하여 가져오는 클러스터의 관리 클러스터 항목을 편집하고 cluster-name 을 관리 클러스터의 이름으로 교체합니다. 

    oc edit managedcluster <cluster-name>
    Copy to Clipboard Toggle word wrap

  4. 다음 예와 같이 ManagedClusterClientConfigs 섹션을 YAML 파일의 ManagedCluster 사양에 추가합니다. 

    spec:
  hubAcceptsClient: true
  managedClusterClientConfigs:
  - url: <https://api.new-managed.dev.redhat.com>
    1
    Copy to Clipboard Toggle word wrap
    1
    URL 값을 가져오는 관리 클러스터에 대한 외부 액세스를 제공하는 URL로 바꿉니다.
1.7.4.1.3.2. 선택 사항: 특정 노드에서 실행되도록 klusterlet 구성
링크 복사

관리 클러스터에 대한 nodeSelector 및 허용 오차 주석을 구성하여 관리 클러스터 klusterlet을 실행할 노드를 지정할 수 있습니다. 다음 설정을 구성하려면 다음 단계를 완료합니다.

  1. 콘솔의 클러스터 페이지에서 업데이트할 관리 클러스터를 선택합니다.

  2. YAML 스위치를 On 으로 설정하여 YAML 콘텐츠를 확인합니다.

    참고: YAML 편집기는 클러스터를 가져오거나 생성하는 경우에만 사용할 수 있습니다. 가져오기 또는 생성 후 관리형 클러스터 YAML 정의를 편집하려면 OpenShift Container Platform 명령줄 인터페이스 또는 Red Hat Advanced Cluster Management 검색 기능을 사용해야 합니다.

  3. 관리 클러스터 YAML 정의에 nodeSelector 주석을 추가합니다. 이 주석의 키는 open-cluster-management/nodeSelector 입니다. 이 주석의 값은 JSON 형식의 문자열 맵입니다.

  4. 관리 클러스터 YAML 정의에 허용 오차 항목을 추가합니다. 이 주석의 키는 open-cluster-management/tolerations 입니다. 이 주석의 값은 JSON 형식의 허용 오차 목록을 나타냅니다. 결과 YAML은 다음 예와 유사할 수 있습니다. 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    open-cluster-management/nodeSelector: '{"dedicated":"acm"}'
    open-cluster-management/tolerations: '[{"key":"dedicated","operator":"Equal","value":"acm","effect":"NoSchedule"}]'
    Copy to Clipboard Toggle word wrap

KlusterletConfig 를 사용하여 관리 클러스터에 대한 nodeSelector 및 허용 오차 를 구성할 수도 있습니다. 다음 설정을 구성하려면 다음 단계를 완료합니다.

참고: KlusterletConfig 를 사용하는 경우 관리 클러스터는 관리 클러스터 주석의 설정 대신 KlusterletConfig 설정의 구성을 사용합니다.

  1. 다음 샘플 YAML 콘텐츠를 적용합니다. 필요한 경우 값을 바꿉니다. 

    apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: <klusterletconfigName>
spec:
  nodePlacement:
    nodeSelector:
      dedicated: acm
    tolerations:
      - key: dedicated
        operator: Equal
        value: acm
        effect: NoSchedule
    Copy to Clipboard Toggle word wrap
  2. agent.open-cluster-management.io/klusterlet-config: '<klusterletconfigName > 주석을 관리 클러스터에 추가하고 < klusterletconfigName >을 KlusterletConfig 의 이름으로 교체합니다.
1.7.4.1.4. 가져온 클러스터 제거
링크 복사

가져온 클러스터와 관리 클러스터에서 생성된 open-cluster-management-agent-addon 을 제거하려면 다음 절차를 완료합니다.

클러스터 페이지에서 Actions > Detach cluster 를 클릭하여 관리에서 클러스터를 제거합니다.

중요: < your-local-cluster-name>이라는 허브 클러스터를 분리하려고 하면 disableHubSelfManagement 의 기본 설정이 false 이고 hub 클러스터는 자체적으로 관리하는 local-cluster 임을 유의하십시오. 이 설정으로 인해 허브 클러스터가 분리될 때 자체적으로 다시 가져와서 자체적으로 관리되고 MultiClusterHub 컨트롤러를 조정합니다. hub 클러스터에서 분리 프로세스를 완료하고 다시 가져오는 데 몇 시간이 걸릴 수 있습니다. 프로세스가 완료될 때까지 기다리지 않고 허브 클러스터를 다시 가져오려면 다음 명령을 실행하여 multiclusterhub-operator Pod를 재시작하고 더 빨리 다시 가져올 수 있습니다. 

oc -n open-cluster-management delete -l name=multiclusterhub-operator pods
Copy to Clipboard Toggle word wrap

disableHubSelfManagement 값을 true 로 변경하여 hub 클러스터의 값을 자동으로 가져오지 않도록 할 수 있습니다. 자세한 내용은 disableHubSelfManagement 주제를 참조하십시오.

1.7.4.1.4.1. 추가 리소스
링크 복사
1.7.4.2. CLI를 사용하여 관리 클러스터 가져오기
링크 복사

Kubernetes Operator용 다중 클러스터 엔진을 설치한 후 Red Hat OpenShift Container Platform CLI를 사용하여 클러스터를 가져오고 관리할 수 있습니다. 자동 가져오기 보안을 사용하거나 수동 명령을 사용하여 CLI로 관리 클러스터를 가져오는 방법을 알아보려면 다음 주제를 계속 읽으십시오.

중요: 허브 클러스터는 다른 허브 클러스터를 관리할 수 없습니다. 허브 클러스터는 로컬 클러스터로 자동으로 가져오기 및 관리하도록 설정됩니다. 자체적으로 관리하기 위해 허브 클러스터를 수동으로 가져올 필요는 없습니다. 허브 클러스터를 제거하고 다시 가져오려고 하는 경우 local-cluster:true 레이블을 추가해야 합니다.

1.7.4.2.1. 사전 요구 사항
링크 복사
  • 배포된 허브 클러스터입니다. 베어 메탈 클러스터를 가져오는 경우 hub 클러스터를 지원되는 OpenShift Container Platform 버전에 설치해야 합니다.
  • 관리할 별도의 클러스터입니다.
  • OpenShift Container Platform CLI입니다. OpenShift Container Platform CLI 설치 및 구성에 대한 정보는 OpenShift CLI 시작하기 를 참조하십시오.
  • OpenShift Container Platform에서 생성하지 않은 클러스터를 가져오는 경우 정의된 multiclusterhub.spec.imagePullSecret 입니다. 이 시크릿은 Kubernetes Operator의 다중 클러스터 엔진을 설치할 때 생성될 수 있습니다. 이 보안을 정의하는 방법에 대한 자세한 내용은 사용자 정의 이미지 가져오기 보안을 참조하십시오.
  • 허브 클러스터 KubeAPIServer 인증서 확인 전략을 검토하고 필요한 경우 전략을 업데이트합니다. 설정에 사용할 전략을 알아보려면 허브 클러스터 KubeAPIServer 확인 전략 구성을 참조하십시오.
1.7.4.2.2. 지원되는 아키텍처
링크 복사
  • Linux (x86_64, s390x, ppc64le)
  • macOS
1.7.4.2.3. 클러스터 가져오기 준비
링크 복사

CLI를 사용하여 관리 클러스터를 가져오기 전에 다음 단계를 완료해야 합니다.

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

    oc login
    Copy to Clipboard Toggle word wrap

  2. 허브 클러스터에서 다음 명령을 실행하여 프로젝트와 네임스페이스를 생성합니다. < cluster_name& gt;에 정의된 클러스터 이름은 YAML 파일 및 명령에서 클러스터 네임스페이스로도 사용됩니다. 

    oc new-project <cluster_name>
    Copy to Clipboard Toggle word wrap

    중요: cluster.open-cluster-management.io/managedCluster 레이블이 관리 클러스터 네임스페이스에 자동으로 추가되고 제거됩니다. 관리 클러스터 네임스페이스에서 수동으로 추가하거나 제거하지 마십시오.

  3. 다음 예제 콘텐츠를 사용하여 managed-cluster.yaml 이라는 파일을 생성합니다. 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: <cluster_name>
  labels:
    cloud: auto-detect
    vendor: auto-detect
spec:
  hubAcceptsClient: true
    Copy to Clipboard Toggle word wrap

    클라우드 및 벤더 의 값이 자동 감지 로 설정된 경우 Red Hat Advanced Cluster Management는 가져오는 클러스터에서 클라우드 및 벤더 유형을 자동으로 감지합니다. 선택적으로 자동 감지 값을 클러스터의 클라우드 및 벤더 값으로 교체할 수 있습니다. 다음 예제를 참조하십시오. 

    cloud: Amazon
vendor: OpenShift
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 ManagedCluster 리소스에 YAML 파일을 적용합니다. 

    oc apply -f managed-cluster.yaml
    Copy to Clipboard Toggle word wrap

자동 가져오기 보안을 사용하거나 클러스터를 수동으로 가져와서 클러스터를 가져올 수 있습니다.

1.7.4.2.4. 자동 가져오기 보안을 사용하여 클러스터 가져오기
링크 복사

자동 가져오기 보안을 사용하여 관리 클러스터를 가져오려면 클러스터의 kubeconfig 파일 또는 클러스터의 kube API 서버 및 토큰 쌍에 대한 참조가 포함된 시크릿을 생성해야 합니다. 자동 가져오기 보안을 사용하여 클러스터를 가져오려면 다음 단계를 완료합니다.

  1. 가져올 관리 클러스터의 kubeconfig 파일 또는 kube API 서버 및 토큰을 검색합니다. kubeconfig 파일 또는 kube API 서버 및 토큰을 찾을 위치를 알아보려면 Kubernetes 클러스터에 대한 설명서를 참조하십시오.

  2. ${CLUSTER_NAME} 네임스페이스에 auto-import-secret.yaml 파일을 생성합니다.

    1. 다음 템플릿과 유사한 콘텐츠를 사용하여 auto-import-secret.yaml 이라는 YAML 파일을 생성합니다. 

      apiVersion: v1
kind: Secret
metadata:
  name: auto-import-secret
  namespace: <cluster_name>
      1 
      
stringData:
  kubeconfig: |- <kubeconfig_file>
      2 
      
  token: <token_cluster>
      3 
      
  server: <cluster_api_url>
      4 
      
type: Opaque
      Copy to Clipboard Toggle word wrap
1
클러스터 이름을 추가합니다.
2
kubeconfig 파일을 사용하는 경우 가져올 클러스터로 컨텍스트가 설정된 kubeconfig 파일의 값을 추가합니다.
3 4
토큰 및 서버 쌍을 사용하는 경우 kubeconfig 파일 대신 클러스터 액세스 토큰 및 클러스터 API URL을 추가합니다.

  1. 다음 명령을 실행하여 <cluster_name> 네임스페이스에 YAML 파일을 적용합니다. 

    oc apply -f auto-import-secret.yaml
    Copy to Clipboard Toggle word wrap

    참고: 기본적으로 자동 가져오기 보안은 한 번 사용되며 가져오기 프로세스가 완료되면 삭제됩니다. 자동 가져오기 보안을 유지하려면 managedcluster-import-controller.open-cluster-management.io/keeping-auto-import-secret 을 시크릿에 추가합니다. 다음 명령을 실행하여 추가할 수 있습니다. 

    oc -n <cluster_name> annotate secrets auto-import-secret managedcluster-import-controller.open-cluster-management.io/keeping-auto-import-secret=""
    Copy to Clipboard Toggle word wrap

    1. 가져온 클러스터에 대한 JOINED 및 AVAILABLE 상태를 확인합니다. hub 클러스터에서 다음 명령을 실행합니다. 

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

    2. 클러스터에서 다음 명령을 실행하여 관리 클러스터에 로그인합니다. 

      oc login
      Copy to Clipboard Toggle word wrap

    3. 다음 명령을 실행하여 가져오기 중인 클러스터에서 Pod 상태를 확인할 수 있습니다. 

      oc get pod -n open-cluster-management-agent
      Copy to Clipboard Toggle word wrap

이제 klusterlet 애드온 가져오기를 계속할 수 있습니다.

1.7.4.2.5. 수동으로 클러스터 가져오기
링크 복사

중요: 가져오기 명령에는 가져온 각 관리 클러스터에 복사되는 풀 시크릿 정보가 포함되어 있습니다. 가져온 클러스터에 액세스할 수 있는 사용자는 풀 시크릿 정보도 볼 수 있습니다.

관리 클러스터를 수동으로 가져오려면 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 허브 클러스터에서 가져오기 컨트롤러에서 생성한 klusterlet-crd.yaml 파일을 가져옵니다. 

    oc get secret <cluster_name>-import -n <cluster_name> -o jsonpath={.data.crds\\.yaml} | base64 --decode > klusterlet-crd.yaml
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 허브 클러스터의 가져오기 컨트롤러에서 생성한 import.yaml 파일을 가져옵니다. 

    oc get secret <cluster_name>-import -n <cluster_name> -o jsonpath={.data.import\\.yaml} | base64 --decode > import.yaml
    Copy to Clipboard Toggle word wrap

    가져올 클러스터에서 다음 단계를 진행합니다.

  3. 다음 명령을 입력하여 가져오는 관리 클러스터에 로그인합니다. 

    oc login
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 1단계에서 생성한 klusterlet-crd.yaml 을 적용합니다. 

    oc apply -f klusterlet-crd.yaml
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 이전에 생성한 import.yaml 파일을 적용합니다. 

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

  6. hub 클러스터에서 다음 명령을 실행하여 가져오는 관리 클러스터에 대한 JOINED 및 AVAILABLE 상태를 확인할 수 있습니다. 

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

이제 klusterlet 애드온 가져오기를 계속할 수 있습니다.

1.7.4.2.6. klusterlet 애드온 가져오기
링크 복사

KlusterletAddonConfig klusterlet 애드온 구성을 구현하여 관리 클러스터에서 다른 애드온을 활성화합니다. 다음 단계를 완료하여 구성 파일을 생성하고 적용합니다.

  1. 다음 예와 유사한 YAML 파일을 생성합니다. 

    apiVersion: agent.open-cluster-management.io/v1
kind: KlusterletAddonConfig
metadata:
  name: <cluster_name>
  namespace: <cluster_name>
spec:
  applicationManager:
    enabled: true
  certPolicyController:
    enabled: true
  policyController:
    enabled: true
  searchCollector:
    enabled: true
    Copy to Clipboard Toggle word wrap
  2. 파일을 klusterlet-addon-config.yaml 로 저장합니다.

  3. 다음 명령을 실행하여 YAML을 적용합니다. 

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

    추가 기능은 가져오는 관리 클러스터 상태가 AVAILABLE 이면 설치됩니다.

  4. 다음 명령을 실행하여 가져오는 클러스터에서 애드온의 Pod 상태를 확인할 수 있습니다. 

    oc get pod -n open-cluster-management-agent-addon
    Copy to Clipboard Toggle word wrap
1.7.4.2.7. 명령줄 인터페이스를 사용하여 가져온 클러스터 제거
링크 복사

명령줄 인터페이스를 사용하여 관리 클러스터를 제거하려면 다음 명령을 실행합니다. 

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

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

1.7.4.3. 에이전트 등록을 사용하여 관리 클러스터 가져오기
링크 복사

Kubernetes Operator용 다중 클러스터 엔진을 설치한 후 에이전트 등록 끝점을 사용하여 클러스터를 가져오고 관리할 수 있습니다. 에이전트 등록 끝점을 사용하여 관리 클러스터를 가져오는 방법을 알아보려면 다음 주제를 계속 읽으십시오.

1.7.4.3.1. 사전 요구 사항
링크 복사
  • 배포된 허브 클러스터입니다. 베어 메탈 클러스터를 가져오는 경우 hub 클러스터를 지원되는 OpenShift Container Platform 버전에 설치해야 합니다.
  • 관리할 클러스터입니다.
  • base64 명령줄 툴입니다.

  • OpenShift Container Platform에서 생성하지 않은 클러스터를 가져오는 경우 정의된 multiclusterhub.spec.imagePullSecret 입니다. 이 시크릿은 Kubernetes Operator의 다중 클러스터 엔진을 설치할 때 생성될 수 있습니다. 이 보안을 정의하는 방법에 대한 자세한 내용은 사용자 정의 이미지 가져오기 보안을 참조하십시오.

    새 보안을 생성해야 하는 경우 새 풀 시크릿 생성 을 참조하십시오.

1.7.4.3.2. 지원되는 아키텍처
링크 복사
  • Linux (x86_64, s390x, ppc64le)
  • macOS
1.7.4.3.3. 클러스터 가져오기
링크 복사

에이전트 등록 끝점을 사용하여 관리 클러스터를 가져오려면 다음 단계를 완료합니다.

  1. hub 클러스터에서 다음 명령을 실행하여 에이전트 등록 서버 URL을 가져옵니다. 

    export agent_registration_host=$(oc get route -n multicluster-engine agent-registration -o=jsonpath="{.spec.host}")
    Copy to Clipboard Toggle word wrap

    참고: 허브 클러스터가 클러스터 전체 프록시를 사용하는 경우 관리 클러스터가 액세스할 수 있는 URL을 사용하고 있는지 확인합니다.

  2. 다음 명령을 실행하여 cacert를 가져옵니다. 

    oc get configmap -n kube-system kube-root-ca.crt -o=jsonpath="{.data['ca\.crt']}" > ca.crt_
    Copy to Clipboard Toggle word wrap

    참고: kube-root-ca 발행 엔드포인트를 사용하지 않는 경우 kube-root-ca CA 대신 공용 agent-registration API 끝점 CA를 사용합니다.

  3. 다음 YAML 콘텐츠를 적용하여 에이전트 등록용 토큰을 가져옵니다. 

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: managed-cluster-import-agent-registration-sa
  namespace: multicluster-engine
---
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: managed-cluster-import-agent-registration-sa-token
  namespace: multicluster-engine
  annotations:
    kubernetes.io/service-account.name: "managed-cluster-import-agent-registration-sa"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: managedcluster-import-controller-agent-registration-client
rules:
- nonResourceURLs: ["/agent-registration/*"]
  verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: managed-cluster-import-agent-registration
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: managedcluster-import-controller-agent-registration-client
subjects:
  - kind: ServiceAccount
    name: managed-cluster-import-agent-registration-sa
    namespace: multicluster-engine
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 토큰을 내보냅니다. 

    export token=$(oc get secret -n multicluster-engine managed-cluster-import-agent-registration-sa-token -o=jsonpath='{.data.token}' | base64 -d)
    Copy to Clipboard Toggle word wrap

  5. 자동 승인을 활성화하고 다음 명령을 실행하여 콘텐츠를 cluster-manager 에 패치합니다. 

    oc patch clustermanager cluster-manager --type=merge -p '{"spec":{"registrationConfiguration":{"featureGates":[
{"feature": "ManagedClusterAutoApproval", "mode": "Enable"}], "autoApproveUsers":["system:serviceaccount:multicluster-engine:agent-registration-bootstrap"]}}}'
    Copy to Clipboard Toggle word wrap

    참고: 자동 승인을 비활성화하고 관리 클러스터에서 인증서 서명 요청을 수동으로 승인할 수도 있습니다.

  6. 관리 클러스터로 전환하고 다음 명령을 실행하여 cacert를 가져옵니다. 

    curl --cacert ca.crt -H "Authorization: Bearer $token" https://$agent_registration_host/agent-registration/crds/v1 | oc apply -f -
    Copy to Clipboard Toggle word wrap

  7. 다음 명령을 실행하여 관리 클러스터를 hub 클러스터로 가져옵니다. & lt;clusterName >을 클러스터 이름으로 바꿉니다. &lt ;duration& gt;을 시간 값으로 바꿉니다. 예: 4h:

    선택 사항: & lt;klusterletconfigName >을 KlusterletConfig의 이름으로 바꿉니다. 

    curl --cacert ca.crt -H "Authorization: Bearer $token" https://$agent_registration_host/agent-registration/manifests/<clusterName>?klusterletconfig=<klusterletconfigName>&duration=<duration> | oc apply -f -
    Copy to Clipboard Toggle word wrap

    참고: 기간을 설정하지 않으면 klusterlet 매니페스트의 kubeconfig 부트스트랩이 만료되지 않습니다.

Kubernetes Operator용 다중 클러스터 엔진을 설치한 후 관리 클러스터를 가져올 준비가 된 것입니다. 추가 노드를 추가할 수 있도록 기존 OpenShift Container Platform 클러스터를 가져올 수 있습니다. 자세한 내용을 보려면 다음 항목을 계속 읽으십시오.

1.7.4.4.1. 사전 요구 사항
링크 복사
  • 중앙 인프라 관리 기능을 활성화합니다.
1.7.4.4.2. 클러스터 가져오기
링크 복사

정적 네트워크 또는 베어 메탈 호스트 없이 수동으로 OpenShift Container Platform 클러스터를 가져오려면 다음 단계를 완료하고 노드 추가를 준비합니다.

  1. 다음 YAML 콘텐츠를 적용하여 가져올 OpenShift Container Platform 클러스터의 네임스페이스를 생성합니다. 

    apiVersion: v1
kind: Namespace
metadata:
  name: managed-cluster
    Copy to Clipboard Toggle word wrap

  2. 다음 YAML 콘텐츠를 적용하여 가져오는 OpenShift Container Platform 클러스터와 일치하는 ClusterImageSet이 있는지 확인합니다. 

    apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  name: openshift-v4.16
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release@sha256:22e149142517dfccb47be828f012659b1ccf71d26620e6f62468c264a7ce7863
    Copy to Clipboard Toggle word wrap

  3. 다음 YAML 콘텐츠를 적용하여 이미지에 액세스할 풀 시크릿을 추가합니다. 

    apiVersion: v1
kind: Secret
type: kubernetes.io/dockerconfigjson
metadata:
  name: pull-secret
  namespace: managed-cluster
stringData:
  .dockerconfigjson: <pull-secret-json>
    1
    Copy to Clipboard Toggle word wrap
    1
    <pull-secret-json>을 풀 시크릿 JSON으로 바꿉니다.

  4. OpenShift Container Platform 클러스터에서 hub 클러스터에 kubeconfig 를 복사합니다.

    1. 다음 명령을 실행하여 OpenShift Container Platform 클러스터에서 kubeconfig 를 가져옵니다. kubeconfig 를 가져오는 클러스터로 설정되어 있는지 확인합니다. 

      oc get secret -n openshift-kube-apiserver node-kubeconfigs -ojson | jq '.data["lb-ext.kubeconfig"]' --raw-output | base64 -d > /tmp/kubeconfig.some-other-cluster
      Copy to Clipboard Toggle word wrap

      참고: 사용자 정의 도메인을 통해 클러스터 API에 액세스하는 경우 먼저 certificate-authority-data 필드에 사용자 정의 인증서를 추가하고 사용자 정의 도메인과 일치하도록 server 필드를 변경하여 이 kubeconfig 를 편집해야 합니다.

    2. 다음 명령을 실행하여 kubeconfig 를 hub 클러스터에 복사합니다. kubeconfig 가 hub 클러스터로 설정되어 있는지 확인합니다. 

      oc -n managed-cluster create secret generic some-other-cluster-admin-kubeconfig --from-file=kubeconfig=/tmp/kubeconfig.some-other-cluster
      Copy to Clipboard Toggle word wrap

  5. 다음 YAML 콘텐츠를 적용하여 AgentClusterInstall 사용자 지정 리소스를 생성합니다. 필요한 경우 값을 바꿉니다. 

    apiVersion: extensions.hive.openshift.io/v1beta1
kind: AgentClusterInstall
metadata:
  name: <your-cluster-name>
    1 
    
  namespace: <managed-cluster>
spec:
  networking:
    userManagedNetworking: true
  clusterDeploymentRef:
    name: <your-cluster>
  imageSetRef:
    name: openshift-v4.x.z
  provisionRequirements:
    controlPlaneAgents:
    2 
    
  sshPublicKey: <"">
    3
    Copy to Clipboard Toggle word wrap
    1
    클러스터의 이름을 선택합니다.
    2
    단일 노드 OpenShift 클러스터를 사용하는 경우 1 을 사용합니다. 다중 노드 클러스터를 사용하는 경우 3 을 사용합니다.
    3
    선택적 sshPublicKey 필드를 추가하여 문제 해결을 위해 노드에 로그인합니다.

  6. 다음 YAML 콘텐츠를 적용하여 ClusterDeployment 을 생성합니다. 필요한 경우 값을 바꿉니다. 

    apiVersion: hive.openshift.io/v1
kind: ClusterDeployment
metadata:
  name: <your-cluster-name>
    1 
    
  namespace: managed-cluster
spec:
  baseDomain: <redhat.com>
    2 
    
  installed: <true>
    3 
    
  clusterMetadata:
      adminKubeconfigSecretRef:
        name: <your-cluster-name-admin-kubeconfig>
    4 
    
      clusterID: <"">
    5 
    
      infraID: <"">
    6 
    
  clusterInstallRef:
    group: extensions.hive.openshift.io
    kind: AgentClusterInstall
    name: your-cluster-name-install
    version: v1beta1
  clusterName: your-cluster-name
  platform:
    agentBareMetal:
  pullSecretRef:
    name: pull-secret
    Copy to Clipboard Toggle word wrap
    1
    클러스터의 이름을 선택합니다.
    2
    baseDomain 이 OpenShift Container Platform 클러스터에 사용 중인 도메인과 일치하는지 확인합니다.
    3
    OpenShift Container Platform 클러스터를 프로덕션 환경 클러스터로 자동으로 가져오려면 true 로 설정합니다.
    4
    4단계에서 생성한 kubeconfig 를 참조합니다.
    5 6
    프로덕션 환경에서 clusterID 및 infraID 를 비워 둡니다.

  7. InfraEnv 사용자 지정 리소스를 추가하여 다음 YAML 콘텐츠를 적용하여 클러스터에 추가할 새 호스트를 검색합니다. 필요한 경우 값을 바꿉니다.

    참고: 고정 IP 주소를 사용하지 않는 경우 다음 예제에 추가 구성이 필요할 수 있습니다. 

    apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: your-infraenv
  namespace: managed-cluster
spec:
  clusterRef:
    name: your-cluster-name
    namespace: managed-cluster
  pullSecretRef:
    name: pull-secret
  sshAuthorizedKey: ""
    Copy to Clipboard Toggle word wrap
Expand
표 1.8. InfraEnv 필드 테이블
필드선택 사항 또는 필수설명

clusterRef

선택 사항

late binding을 사용하는 경우 clusterRef 필드는 선택 사항입니다. 늦은 바인딩을 사용하지 않는 경우 clusterRef 를 추가해야 합니다.

sshAuthorizedKey

선택 사항

선택적 sshAuthorizedKey 필드를 추가하여 문제 해결을 위해 노드에 로그인합니다.

  1. 가져오기에 성공하면 ISO 파일을 다운로드할 URL이 표시됩니다. 다음 명령을 실행하여 ISO 파일을 다운로드하여 <url>을 표시되는 URL로 바꿉니다.

    참고: 베어 메탈 호스트를 사용하여 호스트 검색을 자동화할 수 있습니다. 

    oc get infraenv -n managed-cluster some-other-infraenv -ojson | jq ".status.<url>" --raw-output | xargs curl -k -o /storage0/isos/some-other.iso
    Copy to Clipboard Toggle word wrap
  2. 선택 사항: OpenShift Container Platform 클러스터에서 정책과 같은 Red Hat 고급 클러스터 관리 기능을 사용하려면 ManagedCluster 리소스를 생성합니다. ManagedCluster 리소스의 이름이 ClusterDeplpoyment 리소스의 이름과 일치하는지 확인합니다. ManagedCluster 리소스가 없으면 콘솔에서 클러스터 상태가 분리됩니다.
1.7.4.4.3. 클러스터 리소스 가져오기
링크 복사

지원 설치 관리자에서 OpenShift Container Platform 관리 클러스터를 설치한 경우 관리 클러스터 및 해당 리소스를 Hub 클러스터에서 다른 허브 클러스터로 이동할 수 있습니다.

원래 리소스의 복사본을 저장하고 새 허브 클러스터에 적용한 후 원래 리소스를 삭제하여 새 허브 클러스터에서 클러스터를 관리할 수 있습니다. 그런 다음 새 허브 클러스터에서 관리 클러스터를 축소하거나 확장할 수 있습니다.

중요: 지원 설치 관리자가 설치한 경우에만 가져온 OpenShift Container Platform 관리 클러스터를 축소할 수 있습니다.

다음 리소스를 가져오고 클러스터를 계속 관리할 수 있습니다.

Expand
표 1.9. 관리형 클러스터 리소스 테이블
리소스선택 사항 또는 필수설명

agent

필수 항목

 

AgentClassification

선택 사항

필터 쿼리를 사용하여 에이전트를 분류하려면 필수 항목입니다.

AgentClusterInstall

필수 항목

 

BareMetalHost

선택 사항

baremetal 플랫폼을 사용하는 경우 필요합니다.

ClusterDeployment

필수 항목

 

InfraEnv

필수 항목

 

NMStateConfig

선택 사항

호스트에 네트워크 구성을 적용하려면 필수 항목입니다.

ManagedCluster

필수 항목

 

Secret

필수 항목

admin-kubeconfig 시크릿이 필요합니다. bmc-secret 시크릿은 BareMetalHosts 를 사용하는 경우에만 필요합니다.

1.7.4.4.3.1. 관리되는 클러스터 리소스 저장 및 적용
링크 복사

관리 클러스터 리소스의 사본을 저장하고 새 허브 클러스터에 적용하려면 다음 단계를 완료하십시오.

  1. 다음 명령을 실행하여 소스 허브 클러스터에서 리소스를 가져옵니다. 필요한 경우 값을 바꿉니다. 

    oc –kubeconfig <source_hub_kubeconfig> -n <managed_cluster_name> get <resource_name> <cluster_provisioning_namespace> -oyaml > <resource_name>.yaml
    Copy to Clipboard Toggle word wrap
    1. <resource _name>을 리소스 이름으로 교체하여 가져올 모든 리소스에 대해 명령을 반복합니다.

  2. 다음 명령을 실행하여 ownerReferences 속성을 다음 리소스에서 제거합니다.

    1. AgentClusterInstall 

      yq --in-place -y 'del(.metadata.ownerReferences)' AgentClusterInstall.yaml
      Copy to Clipboard Toggle word wrap

    2. secret (admin-kubeconfig) 

      yq --in-place -y 'del(.metadata.ownerReferences)' AdminKubeconfigSecret.yaml
      Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 소스 허브 클러스터에서 관리되는 클러스터를 분리합니다. 필요한 경우 값을 바꿉니다. 

    oc –kubeconfig <target_hub_kubeconfig> delete ManagedCluster <cluster_name>
    Copy to Clipboard Toggle word wrap
  4. 관리 클러스터의 대상 허브 클러스터에 네임스페이스를 생성합니다. 소스 허브 클러스터와 유사한 이름을 사용합니다.

  5. 다음 명령을 실행하여 대상 허브 클러스터에 저장된 리소스를 개별적으로 적용합니다. 필요한 경우 값을 바꿉니다.

    참고: 개별적으로 모든 리소스를 그룹으로 적용하려면 <resource_name> . yaml 을 .로 바꿉니다. 

    oc –kubeconfig <target_hub_kubeconfig> apply -f <resource_name>.yaml
    Copy to Clipboard Toggle word wrap
1.7.4.4.3.2. 소스 허브 클러스터에서 관리 클러스터 제거
링크 복사

클러스터 리소스를 가져온 후 다음 단계를 완료하여 소스 허브 클러스터에서 관리 클러스터를 제거합니다.

  1. 관리 클러스터를 제거하지 않도록 ClusterDeployment 사용자 정의 리소스에서 spec.preserveOnDelete 매개변수를 true 로 설정합니다.
  2. 관리에서 클러스터 제거 단계를 완료합니다.
1.7.4.5. 자동 가져오기 전략 사용자 정의
링크 복사

관리 클러스터의 자동 가져오기 동작을 일회성 프로세스 또는 연속 프로세스로 설정합니다. 다음 두 가지 자동 가져오기 전략이 있습니다.

ImportOnly
관리 클러스터에 ManagedClusterImportSucceeded 조건이 없거나 조건이 True 로 설정되지 않은 경우 허브 클러스터 컨트롤러는 klusterlet 매니페스트를 관리 클러스터에 적용하여 가져오기를 시작합니다. 클러스터가 허브 클러스터에 가입하면 허브 컨트롤러가 klusterlet 매니페스트 적용을 중지합니다. 이제 관리 클러스터의 klusterlet 에이전트만 허브 구성을 동기화합니다. klusterlet 에이전트가 작동을 중지하면 매니페스트가 오래되어 관리 클러스터가 hub 클러스터의 Unknown 상태로 표시될 수 있습니다. 그런 다음 클러스터를 수동으로 가져와야 합니다.
ImportAndSync
허브 클러스터 컨트롤러는 관리 클러스터가 참여할 때까지 klusterlet 매니페스트를 적용합니다. 가입한 후 허브 클러스터 컨트롤러와 klusterlet 에이전트 모두 klusterlet 매니페스트를 허브 클러스터 구성과 지속적으로 동기화하여 하나의 구성 요소가 작동을 중지하더라도 일관성을 보장합니다.

기본 자동 가져오기 전략은 ImportOnly 입니다. 가져오기 전략을 변경하려면 다중 클러스터 엔진 Operator 설치 네임스페이스에서 import-controller-config 라는 ConfigMap 오브젝트를 사용합니다. 다음 단계를 완료합니다.

  1. 사용자 정의 전략을 설정하려면 다음 명령을 실행합니다. 

    oc -n <mce_install_namespace> create configmap import-controller-config \
  --from-literal=autoImportStrategy=<ImportOnly|ImportAndSync>
    Copy to Clipboard Toggle word wrap

    참고: 기본 다중 클러스터 엔진 Operator 설치 네임스페이스는 multicluster-engine 입니다.

  2. 업데이트된 전략을 클러스터 백업에 포함하려면 다음 명령을 실행하여 backup=true 레이블을 ConfigMap 에 추가합니다. 

    oc -n <mce_install_namespace> label configmap import-controller-config \

  cluster.open-cluster-management.io/backup=true
    Copy to Clipboard Toggle word wrap
1.7.4.6. 가져오기를 위해 관리 클러스터에서 이미지 레지스트리 지정
링크 복사

가져오는 관리 클러스터에서 이미지 레지스트리를 재정의해야 할 수 있습니다. ManagedClusterImageRegistry 사용자 정의 리소스 정의를 생성하여 이 작업을 수행할 수 있습니다.

ManagedClusterImageRegistry 사용자 정의 리소스 정의는 네임스페이스 범위 리소스입니다.

ManagedClusterImageRegistry 사용자 정의 리소스 정의는 배치를 선택할 수 있도록 관리 클러스터 세트를 지정하지만 사용자 정의 이미지 레지스트리의 다른 이미지가 필요합니다. 관리 클러스터가 새 이미지로 업데이트되면 식별을 위해 각 관리 클러스터에 다음 레이블이 추가됩니다. open-cluster-management.io/image-registry=<namespace>.<managedClusterImageRegistryName > .

다음 예제는 ManagedClusterImageRegistry 사용자 정의 리소스 정의를 보여줍니다. 

apiVersion: imageregistry.open-cluster-management.io/v1alpha1
kind: ManagedClusterImageRegistry
metadata:
  name: <imageRegistryName>
  namespace: <namespace>
spec:
  placementRef:
    group: cluster.open-cluster-management.io
    resource: placements
    name: <placementName>
1 

  pullSecret:
    name: <pullSecretName>
2 

  registries:
3 

  - mirror: <mirrored-image-registry-address>
    source: <image-registry-address>
  - mirror: <mirrored-image-registry-address>
    source: <image-registry-address>
Copy to Clipboard Toggle word wrap
1
을 관리 클러스터 세트를 선택하는 동일한 네임스페이스에서 배치 이름으로 바꿉니다.
2
을 사용자 정의 이미지 레지스트리에서 이미지를 가져오는 데 사용되는 풀 시크릿의 이름으로 바꿉니다.
3
각 소스 및 미러 레지스트리의 값을 나열합니다. mirrored-image-registry-address 및 image-registry-address 를 레지스트리의 각 미러 및 소스 값 값으로 바꿉니다.
  • 예 1: registry.redhat.io/rhacm2 라는 소스 이미지 레지스트리를 localhost:5000/rhacm2 로 교체하고 registry.redhat.io/multicluster-engine 을 localhost:5000/multicluster-engine 으로 교체하려면 다음 예제를 사용합니다. 
registries:
- mirror: localhost:5000/rhacm2/
    source: registry.redhat.io/rhacm2
- mirror: localhost:5000/multicluster-engine
    source: registry.redhat.io/multicluster-engine
Copy to Clipboard Toggle word wrap

  • 예 2: 소스 이미지 registry.redhat.io/rhacm2/registration-rhel8-operator 를 localhost:5000/rhacm2-registration-rhel8-operator 로 교체하려면 다음 예제를 사용합니다. 

    registries:
- mirror: localhost:5000/rhacm2-registration-rhel8-operator
    source: registry.redhat.io/rhacm2/registration-rhel8-operator
    Copy to Clipboard Toggle word wrap

중요: 에이전트 등록을 사용하여 관리 클러스터를 가져오는 경우 이미지 레지스트리가 포함된 KlusterletConfig 를 생성해야 합니다. 다음 예제를 참조하십시오. 필요한 경우 값을 바꿉니다. 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: <klusterletconfigName>
spec:
  pullSecret:
    namespace: <pullSecretNamespace>
    name: <pullSecretName>
  registries:
    - mirror: <mirrored-image-registry-address>
      source: <image-registry-address>
    - mirror: <mirrored-image-registry-address>
      source: <image-registry-address>
Copy to Clipboard Toggle word wrap

자세한 내용은 에이전트 등록 끝점을 사용하여 관리 클러스터 가져오기 를 참조하십시오.

1.7.4.6.1. ManagedClusterImageRegistry가 있는 클러스터 가져오기
링크 복사

ManagedClusterImageRegistry 사용자 정의 리소스 정의로 사용자 지정된 클러스터를 가져오려면 다음 단계를 완료합니다.

  1. 클러스터를 가져올 네임스페이스에 풀 시크릿을 생성합니다. 이러한 단계의 경우 네임스페이스는 myNamespace 입니다. 

    $ kubectl create secret docker-registry myPullSecret \
  --docker-server=<your-registry-server> \
  --docker-username=<my-name> \
  --docker-password=<my-password>
    Copy to Clipboard Toggle word wrap

  2. 생성한 네임스페이스에 배치를 생성합니다. 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: myPlacement
  namespace: myNamespace
spec:
  clusterSets:
  - myClusterSet
  tolerations:
  - key: "cluster.open-cluster-management.io/unreachable"
    operator: Exists
    Copy to Clipboard Toggle word wrap

    참고: 배치에서 클러스터를 선택할 수 있으려면 연결할 수 없는 허용 오차가 필요합니다.

  3. ManagedClusterSet 리소스를 생성하여 네임스페이스에 바인딩합니다. 

    apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSet
metadata:
  name: myClusterSet

---
apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSetBinding
metadata:
  name: myClusterSet
  namespace: myNamespace
spec:
  clusterSet: myClusterSet
    Copy to Clipboard Toggle word wrap

  4. 네임스페이스에 ManagedClusterImageRegistry 사용자 정의 리소스 정의를 생성합니다. 

    apiVersion: imageregistry.open-cluster-management.io/v1alpha1
kind: ManagedClusterImageRegistry
metadata:
  name: myImageRegistry
  namespace: myNamespace
spec:
  placementRef:
    group: cluster.open-cluster-management.io
    resource: placements
    name: myPlacement
  pullSecret:
    name: myPullSecret
  registry: myRegistryAddress
    Copy to Clipboard Toggle word wrap
  5. 콘솔에서 관리 클러스터를 가져와서 관리 클러스터 세트에 추가합니다.
  6. open-cluster-management.io/image-registry=myNamespace.myImageRegistry 레이블이 관리 클러스터에 추가된 후 관리 클러스터에서 가져오기 명령을 복사하여 실행합니다.

1.7.5. 클러스터에 액세스
링크 복사

생성 및 관리되는 Red Hat OpenShift Container Platform 클러스터에 액세스하려면 다음 단계를 완료하십시오.

  1. 콘솔에서 Infrastructure > Clusters 로 이동하여 생성 또는 액세스하려는 클러스터의 이름을 선택합니다.

  2. Reveal 인증 정보를 선택하여 클러스터의 사용자 이름 및 암호를 확인합니다. 클러스터에 로그인할 때 사용할 값을 확인합니다.

    참고: 가져온 클러스터에는 Reveal credentials 옵션을 사용할 수 없습니다.

  3. Console URL 을 선택하여 클러스터에 연결합니다.
  4. 3단계에서 찾은 사용자 ID 및 암호를 사용하여 클러스터에 로그인합니다.

1.7.6. 관리형 클러스터 확장
링크 복사

생성한 클러스터의 경우 가상 머신 크기 및 노드 수와 같은 관리형 클러스터 사양을 사용자 지정하고 조정할 수 있습니다. 클러스터 배포를 위해 설치 관리자 프로비저닝 인프라를 사용하는 경우 다음 옵션을 참조하십시오.

클러스터 배포를 위해 중앙 인프라 관리를 사용하는 경우 다음 옵션을 참조하십시오.

1.7.6.1. MachinePool로 스케일링
링크 복사

다중 클러스터 엔진 Operator로 프로비저닝하는 클러스터의 경우 MachinePool 리소스가 자동으로 생성됩니다. MachinePool 을 사용하여 가상 머신 크기 및 노드 수와 같은 관리형 클러스터 사양을 추가로 사용자 지정하고 크기를 조정할 수 있습니다.

  • 베어 메탈 클러스터에서는 MachinePool 리소스 사용이 지원되지 않습니다.
  • MachinePool 리소스는 hub 클러스터의 Kubernetes 리소스로, 관리 클러스터에서 MachineSet 리소스를 함께 그룹화합니다.
  • MachinePool 리소스는 영역 구성, 인스턴스 유형 및 루트 스토리지를 포함하여 머신 리소스 세트를 균일하게 구성합니다.
  • MachinePool 을 사용하면 원하는 수의 노드를 수동으로 구성하거나 관리 클러스터에서 노드 자동 스케일링을 구성할 수 있습니다.
1.7.6.1.1. 자동 스케일링 구성
링크 복사

자동 스케일링을 구성하면 트래픽이 낮을 때 축소하여 리소스 비용을 낮추고 리소스 수요가 많을 때 리소스가 충분한지 확인하기 위해 확장 가능한 클러스터의 유연성을 제공합니다.

  • 콘솔을 사용하여 MachinePool 리소스에서 자동 스케일링을 활성화하려면 다음 단계를 완료합니다.

    1. 탐색에서 Infrastructure > Clusters 를 선택합니다.
    2. 대상 클러스터의 이름을 클릭하고 머신 풀 탭을 선택합니다.
    3. 머신 풀 페이지의 대상 머신 풀의 옵션 메뉴에서 자동 스케일링 사용을 선택합니다.

    4. 최소 및 최대 머신 세트 복제본 수를 선택합니다. 머신 세트 복제본은 클러스터의 노드에 직접 매핑됩니다.

      크기 조정을 클릭한 후 콘솔을 반영하는 데 몇 분이 걸릴 수 있습니다. 머신 풀 알림에서 머신 풀 보기를 클릭하여 스케일링 작업의 상태를 볼 수 있습니다.

  • 명령줄을 사용하여 MachinePool 리소스에서 자동 스케일링을 활성화하려면 다음 단계를 완료합니다.

    1. 다음 명령을 입력하여 머신 풀 목록을 보고 managed-cluster-namespace 를 대상 관리 클러스터의 네임스페이스로 교체합니다. 

      oc get machinepools -n <managed-cluster-namespace>
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 입력하여 머신 풀의 YAML 파일을 편집합니다. 

      oc edit machinepool <MachinePool-resource-name> -n <managed-cluster-namespace>
      Copy to Clipboard Toggle word wrap
      • MachinePool-resource-name 을 MachinePool 리소스의 이름으로 바꿉니다.
      • managed-cluster-namespace 를 관리 클러스터의 네임스페이스 이름으로 교체합니다.
    3. YAML 파일에서 spec.replicas 필드를 삭제합니다.
    4. spec.autoscaling.minReplicas 설정 및 spec.autoscaling.maxReplicas 필드를 리소스 YAML에 추가합니다.
    5. minReplicas 설정에 최소 복제본 수를 추가합니다.
    6. maxReplicas 설정에 최대 복제본 수를 추가합니다.
    7. 파일을 저장하여 변경 사항을 제출합니다.
1.7.6.1.2. 자동 스케일링 비활성화
링크 복사

콘솔 또는 명령줄을 사용하여 자동 스케일링을 비활성화할 수 있습니다.

  • 콘솔을 사용하여 자동 스케일링을 비활성화하려면 다음 단계를 완료합니다.

    1. 탐색에서 Infrastructure > Clusters 를 선택합니다.
    2. 대상 클러스터의 이름을 클릭하고 머신 풀 탭을 선택합니다.
    3. 시스템 풀 페이지의 대상 시스템 풀의 옵션 메뉴에서 자동 스케일링 비활성화 를 선택합니다.

    4. 원하는 머신 세트 복제본 수를 선택합니다. 머신 세트 복제본은 클러스터의 노드와 직접 매핑됩니다.

      스케일 을 클릭하면 콘솔에 표시되는 데 몇 분이 걸릴 수 있습니다. 머신 풀 탭의 알림에서 머신 보기를 클릭하여 스케일링 상태를 볼 수 있습니다.

  • 명령줄을 사용하여 자동 스케일링을 비활성화하려면 다음 단계를 완료합니다.

    1. 다음 명령을 입력하여 머신 풀 목록을 확인합니다. 

      oc get machinepools -n <managed-cluster-namespace>
      Copy to Clipboard Toggle word wrap

      managed-cluster-namespace 를 대상 관리 클러스터의 네임스페이스로 교체합니다.

    2. 다음 명령을 입력하여 머신 풀의 YAML 파일을 편집합니다. 

      oc edit machinepool <name-of-MachinePool-resource> -n <namespace-of-managed-cluster>
      Copy to Clipboard Toggle word wrap

      name-of-MachinePool-resource 를 MachinePool 리소스의 이름으로 교체합니다.

      namespace-of-managed-cluster 를 관리 클러스터의 네임스페이스 이름으로 교체합니다.

    3. YAML 파일에서 spec.autoscaling 필드를 삭제합니다.
    4. spec.replicas 필드를 리소스 YAML에 추가합니다.
    5. replicas 설정에 복제본 수를 추가합니다.
    6. 파일을 저장하여 변경 사항을 제출합니다.
1.7.6.1.3. 수동 스케일링 활성화
링크 복사

콘솔과 명령줄에서 수동으로 확장할 수 있습니다.

1.7.6.1.3.1. 콘솔을 사용하여 수동 스케일링 활성화
링크 복사

콘솔을 사용하여 MachinePool 리소스를 확장하려면 다음 단계를 완료합니다.

  1. MachinePool 이 활성화된 경우 자동 스케일링을 비활성화합니다. 이전 단계를 참조하십시오.
  2. 콘솔에서 인프라 > 클러스터를 클릭합니다.
  3. 대상 클러스터의 이름을 클릭하고 머신 풀 탭을 선택합니다.
  4. 머신 풀 페이지의 대상 머신 풀 의 옵션 메뉴에서 머신 풀 스케일링을 선택합니다.
  5. 원하는 머신 세트 복제본 수를 선택합니다. 머신 세트 복제본은 클러스터의 노드와 직접 매핑됩니다. 크기 조정을 클릭한 후 콘솔을 반영하는 데 몇 분이 걸릴 수 있습니다. 머신 풀 탭 알림에서 머신 보기를 클릭하여 스케일링 작업의 상태를 볼 수 있습니다.
1.7.6.1.3.2. 명령줄을 사용하여 수동 스케일링 활성화
링크 복사

명령줄을 사용하여 MachinePool 리소스를 확장하려면 다음 단계를 완료합니다.

  1. 다음 명령을 입력하여 머신 풀 목록을 보고 < managed-cluster-namespace >를 대상 관리 클러스터 네임스페이스의 네임스페이스로 교체합니다. 

    oc get machinepools.hive.openshift.io -n <managed-cluster-namespace>
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 머신 풀의 YAML 파일을 편집합니다. 

    oc edit machinepool.hive.openshift.io <MachinePool-resource-name> -n <managed-cluster-namespace>
    Copy to Clipboard Toggle word wrap
    • MachinePool-resource-name 을 MachinePool 리소스의 이름으로 바꿉니다.
    • managed-cluster-namespace 를 관리 클러스터의 네임스페이스 이름으로 교체합니다.
  3. YAML 파일에서 spec.autoscaling 필드를 삭제합니다.
  4. YAML 파일의 spec.replicas 필드를 원하는 복제본 수로 수정합니다.
  5. 파일을 저장하여 변경 사항을 제출합니다.
1.7.6.2. OpenShift Container Platform 클러스터에 작업자 노드 추가
링크 복사

중앙 인프라 관리를 사용하는 경우 추가 프로덕션 환경 노드를 추가하여 OpenShift Container Platform 클러스터를 사용자 지정할 수 있습니다.

필수 액세스: 관리자

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

관리 클러스터 API를 신뢰하는 데 필요한 새 CA 인증서가 있어야 합니다.

1.7.6.2.2. 유효한 kubeconfig생성
링크 복사

프로덕션 환경 작업자 노드를 OpenShift Container Platform 클러스터에 추가하기 전에 유효한 kubeconfig 가 있는지 확인해야 합니다.

관리 클러스터의 API 인증서가 변경되면 다음 단계를 완료하여 kubeconfig 를 새 CA 인증서로 업데이트합니다.

  1. 다음 명령을 실행하여 clusterDeployment 의 kubeconfig 가 유효한지 확인합니다. & lt;kubeconfig_name >을 현재 kubeconfig 이름으로 바꾸고 < cluster_name >을 클러스터 이름으로 바꿉니다. 

    export <kubeconfig_name>=$(oc get cd $<cluster_name> -o "jsonpath={.spec.clusterMetadata.adminKubeconfigSecretRef.name}")
oc extract secret/$<kubeconfig_name> --keys=kubeconfig --to=- > original-kubeconfig
oc --kubeconfig=original-kubeconfig get node
    Copy to Clipboard Toggle word wrap

  2. 다음 오류 메시지가 표시되면 kubeconfig 시크릿을 업데이트해야 합니다. 오류 메시지가 표시되지 않으면 계속 작업자 노드 추가: 

    Unable to connect to the server: tls: failed to verify certificate: x509: certificate signed by unknown authority
    Copy to Clipboard Toggle word wrap

  3. kubeconfig certificate-authority-data 필드에서 base64 로 인코딩된 인증서 번들을 가져오고 다음 명령을 실행하여 디코딩합니다. 

    echo <base64 encoded blob> | base64 --decode > decoded-existing-certs.pem
    Copy to Clipboard Toggle word wrap

  4. 원본 파일을 복사하여 업데이트된 kubeconfig 파일을 생성합니다. 다음 명령을 실행하고 < new_kubeconfig_name&gt;을 새 kubeconfig 파일의 이름으로 바꿉니다. 

    cp original-kubeconfig <new_kubeconfig_name>
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 디코딩된 pem에 새 인증서를 추가합니다. 

    cat decoded-existing-certs.pem new-ca-certificate.pem | openssl base64 -A
    Copy to Clipboard Toggle word wrap
  6. 이전 명령의 base64 출력을 텍스트 편집기를 사용하여 새 kubeconfig 파일의 certificate-authority-data 키 값으로 추가합니다.

  7. 새 kubeconfig 로 API를 쿼리하여 새 kubeconfig 가 유효한지 확인합니다. 다음 명령을 실행합니다. & lt;new_kubeconfig_name& gt;을 새 kubeconfig 파일의 이름으로 바꿉니다. 

    KUBECONFIG=<new_kubeconfig_name> oc get nodes
    Copy to Clipboard Toggle word wrap

    성공적인 출력이 표시되면 kubeconfig 가 유효합니다.

  8. 다음 명령을 실행하여 Red Hat Advanced Cluster Management Hub 클러스터에서 kubeconfig 시크릿을 업데이트합니다. & lt;new_kubeconfig_name& gt;을 새 kubeconfig 파일의 이름으로 바꿉니다. 

    oc patch secret $original-kubeconfig --type='json' -p="[{'op': 'replace', 'path': '/data/kubeconfig', 'value': '$(openssl base64 -A -in <new_kubeconfig_name>)'},{'op': 'replace', 'path': '/data/raw-kubeconfig', 'value': '$(openssl base64 -A -in <new_kubeconfig_name>)'}]"
    Copy to Clipboard Toggle word wrap
1.7.6.2.3. 작업자 노드 추가
링크 복사

유효한 kubeconfig 가 있는 경우 다음 단계를 완료하여 OpenShift Container Platform 클러스터에 프로덕션 환경 작업자 노드를 추가합니다.

  1. 이전에 다운로드한 ISO에서 작업자 노드로 사용할 시스템을 부팅합니다.

    참고: 작업자 노드가 OpenShift Container Platform 작업자 노드의 요구 사항을 충족하는지 확인합니다.

  2. 다음 명령을 실행한 후 에이전트가 등록할 때까지 기다립니다. 

    watch -n 5 "oc get agent -n managed-cluster"
    Copy to Clipboard Toggle word wrap

  3. 에이전트 등록이 성공하면 에이전트가 나열됩니다. 설치를 위한 에이전트를 승인합니다. 이 작업은 몇 분 정도 걸릴 수 있습니다.

    참고: 에이전트가 나열되지 않은 경우 Ctrl 및 C를 눌러 watch 명령을 종료한 다음 작업자 노드에 로그인하여 문제를 해결합니다.

  4. 늦은 바인딩을 사용하는 경우 다음 명령을 실행하여 보류 중인 바인딩되지 않은 에이전트를 OpenShift Container Platform 클러스터와 연결합니다. late binding을 사용하지 않는 경우 5 단계로 건너뜁니다. 

    oc get agent -n managed-cluster -ojson | jq -r '.items[] | select(.spec.approved==false) |select(.spec.clusterDeploymentName==null) | .metadata.name'| xargs oc -n managed-cluster patch -p '{"spec":{"clusterDeploymentName":{"name":"some-other-cluster","namespace":"managed-cluster"}}}' --type merge agent
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 설치 대기 중인 에이전트를 승인합니다. 

    oc get agent -n managed-cluster -ojson | jq -r '.items[] | select(.spec.approved==false) | .metadata.name'| xargs oc -n managed-cluster patch -p '{"spec":{"approved":true}}' --type merge agent
    Copy to Clipboard Toggle word wrap

작업자 노드의 설치를 기다립니다. 작업자 노드 설치가 완료되면 작업자 노드는 가입 프로세스를 시작하기 위해 작업자 노드에 CSR(인증서 서명 요청)과 함께 관리 클러스터에 연결합니다. CSR이 자동으로 서명됩니다.

1.7.6.3. 관리 클러스터에 컨트롤 플레인 노드 추가
링크 복사

정상 또는 비정상적인 관리 클러스터에 컨트롤 플레인 노드를 추가하여 실패한 컨트롤 플레인을 교체할 수 있습니다.

필수 액세스: 관리자

1.7.6.3.1. 정상 관리형 클러스터에 컨트롤 플레인 노드 추가
링크 복사

정상 관리 클러스터에 컨트롤 플레인 노드를 추가하려면 다음 단계를 완료합니다.

  1. 새 컨트롤 플레인 노드를 추가하려면 OpenShift Container Platform 클러스터에 작업자 노드 추가 단계를 완료합니다.

  2. Discovery ISO를 사용하여 노드를 추가하는 경우 에이전트를 승인하기 전에 에이전트를 master 로 설정합니다. 다음 명령을 실행합니다. 

    oc patch agent <agent-name> -p '{"spec":{"role": "master"}}' --type=merge
    Copy to Clipboard Toggle word wrap

    참고: CSR(인증서 서명 요청)은 자동으로 승인되지 않습니다.

  3. BareMetalHost 를 사용하여 노드를 추가하는 경우 BareMetalHost 리소스를 생성할 때 BareMetalHost 주석에 다음 행을 추가합니다. 

        bmac.agent-install.openshift.io/role: master
    Copy to Clipboard Toggle word wrap
  4. OpenShift Container Platform 설명서의 지원 설치 관리자에서 정상 클러스터에서 컨트롤 플레인 노드 교체 의 단계를 따르십시오.

API를 사용하여 정상 관리형 클러스터에 컨트롤 플레인 노드를 추가하려면 다음 단계를 완료합니다.

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

    oc login --token=sha256~value--server=https://api.<cluster-name>.basedomain:6443
    Copy to Clipboard Toggle word wrap

  2. Discovery ISO에서 컨트롤 플레인 노드로 사용할 시스템을 부팅합니다.

    참고: 또는 BareMetalHost YAML을 적용하여 InfraEnv 에 새 호스트를 적용합니다.

  3. 에이전트 상태를 확인하여 에이전트가 클러스터에 다시 바인딩할 준비가 되었는지 확인합니다. 다음 명령을 실행하고 필요한 경우 변수를 교체합니다.

    1. 다음 명령을 실행하여 인벤토리를 전환합니다. &lt ;host-inventory-namespace> 를 네임스페이스로 바꿉니다. 

      oc project <host-inventory-namespace>
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 에이전트의 상태를 가져옵니다. & lt;agent-name >을 에이전트 이름으로 바꿉니다. 

      oc get agent <agent-name> -oyaml | grep state
      Copy to Clipboard Toggle word wrap
    3. 출력에서 stateInfo 행을 확인하여 호스트가 클러스터에 바인딩할 준비가 되었는지 확인합니다.

  4. 호스트의 역할을 master 로 설정합니다.

    1. Discovery ISO를 사용하여 노드를 추가하는 경우 에이전트를 승인하고 역할을 master 로 설정합니다. 다음 명령을 실행합니다. 

      oc patch agent <agent-name> -p '{"spec":{"approved":true,"role":"master"}}' --type=merge
      Copy to Clipboard Toggle word wrap
    2. BareMetalHost 를 사용하여 노드를 추가하는 경우 BareMetalHost 리소스를 생성할 때 BareMetalHost 주석에 다음 행을 추가합니다. 
        bmac.agent-install.openshift.io/role: master
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 패치를 확인합니다. 

    oc get agent
    Copy to Clipboard Toggle word wrap

    출력에서 APPROVED 열의 각 줄이 true 이고 ROLE 이 master 인지 확인합니다. 다음 예제를 참조하십시오. 

    NAME                                   CLUSTER    APPROVED    ROLE    STAGE
c6e00642-0e11-1689-a79d-0e131d2c6ecf              true        master
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 실행하여 클러스터에 에이전트를 추가합니다. 

    oc patch agent <agent name> -p '{"spec":{"clusterDeploymentName":{"name":"<managed-cluster-name>","namespace":"<managed-cluster-namespace>"}}}' --type=merge
    Copy to Clipboard Toggle word wrap

  7. 다음 명령을 실행하여 에이전트가 클러스터에 바인딩되었는지 확인합니다. 

    oc get agent
    Copy to Clipboard Toggle word wrap

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

    NAME                                   CLUSTER    APPROVED    ROLE    STAGE
c6e00642-0e11-1689-a79d-0e131d2c6ecf   hcpagent   true        master
    Copy to Clipboard Toggle word wrap

  8. 다음 명령을 실행하여 에이전트 상태를 확인합니다. 에이전트가 클러스터를 설치하고 참여하는 동안 몇 분 정도 기다려야 할 수 있습니다. 

    oc get agent -w
    Copy to Clipboard Toggle word wrap

    참고: CSR(인증서 서명 요청)은 자동으로 승인되지 않습니다.

  9. 에이전트가 재부팅 단계에 도달한 후 CSR을 수동으로 승인해야 합니다. 다음 단계를 완료합니다.

    1. 다음 명령을 실행하여 관리 클러스터 kubeconfig 파일을 가져옵니다. 

      kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')
oc -n ${cluster_name} get secret ${kubeconfig_secret_name} -ojsonpath={.data.kubeconfig} | base64 -d > managed-cluster.kubeconfig
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 관리 클러스터에서 보류 중인 CSR을 찾습니다. 

      oc --kubeconfig managed-cluster.kubeconfig get csr | grep Pending
      Copy to Clipboard Toggle word wrap

    3. 관리 클러스터의 에이전트에 대해 보류 중인 CSR을 승인합니다. 다음 명령을 실행하고 < csr-name> 을 CSR 이름으로 교체합니다. 

      oc  --kubeconfig managed-cluster.kubeconfig  adm certificate approve <csr-name>
      Copy to Clipboard Toggle word wrap

STAGE 에 Done 이 표시되면 호스트가 설치됩니다. 다음 출력 예제를 참조하십시오. 

NAME                                   CLUSTER    APPROVED   ROLE     STAGE
c6e00642-0e11-1689-a79d-0e131d2c6ecf   hcpagent   true       master   Done
Copy to Clipboard Toggle word wrap
1.7.6.3.3. 비정상 관리형 클러스터에 컨트롤 플레인 노드 추가
링크 복사

비정상적인 관리 클러스터에 컨트롤 플레인 노드를 추가하려면 다음 단계를 완료합니다.

  1. 비정상 컨트롤 플레인 노드의 에이전트를 제거합니다.
  2. 배포에 제로터치 프로비저닝 흐름을 사용한 경우 베어 메탈 호스트를 제거합니다.
  3. 새 컨트롤 플레인 노드의 OpenShift Container Platform 클러스터에 작업자 노드 추가 단계를 완료합니다.

  4. 다음 명령을 실행하여 에이전트를 승인하기 전에 에이전트를 master 로 설정합니다. 

    oc patch agent <AGENT-NAME> -p '{"spec":{"role": "master"}}' --type=merge
    Copy to Clipboard Toggle word wrap

    참고: CSR은 자동으로 승인되지 않습니다.

  5. OpenShift Container Platform 설명서의 지원 설치 관리자의 비정상 클러스터에 기본 컨트롤 플레인 노드 설치 단계를 따르십시오.

1.7.7. 생성된 클러스터 완화
링크 복사

리소스를 절약하기 위해 다중 클러스터 엔진 Operator를 사용하여 생성된 클러스터를 구성할 수 있습니다. 하이버네이션 클러스터의 경우 실행 중인 리소스보다 리소스가 훨씬 적기 때문에 클러스터를 하이버네이트 상태로 전환하여 공급자 비용을 줄일 수 있습니다. 이 기능은 다음 환경에서 다중 클러스터 엔진 Operator가 생성한 클러스터에만 적용됩니다.

  • Amazon Web Services
  • Microsoft Azure
  • Google Cloud Platform
1.7.7.1. 콘솔을 사용하여 클러스터 Hibernate
링크 복사

콘솔을 사용하여 다중 클러스터 엔진 Operator가 생성한 클러스터를 hibernate하려면 다음 단계를 완료하십시오.

  1. 탐색 메뉴에서 Infrastructure > Clusters 를 선택합니다. Manage clusters 탭이 선택되어 있는지 확인합니다.
  2. 클러스터의 옵션 메뉴에서 Hibernate 클러스터를 선택합니다. 참고: Hibernate 클러스터 옵션을 사용할 수 없는 경우 클러스터를 최대로 설정할 수 없습니다. 이는 클러스터를 가져오고 다중 클러스터 엔진 Operator에 의해 생성되지 않을 때 발생할 수 있습니다.

프로세스가 완료되면 Clusters 페이지의 클러스터 상태는 Hibernating 입니다.

팁: 클러스터 페이지에서 hibernate를 선택하고 작업 > Hibernate 클러스터를 선택하여 여러 클러스터를 구성할 수 있습니다.

선택한 클러스터가 손상되고 있습니다.

1.7.7.2. CLI를 사용하여 클러스터 Hibernate
링크 복사

CLI를 사용하여 다중 클러스터 엔진 Operator가 생성한 클러스터를 hibernate하려면 다음 단계를 완료하십시오.

  1. 다음 명령을 입력하여 hibernate로 클러스터 설정을 편집합니다. 

    oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>
    Copy to Clipboard Toggle word wrap

    name-of-cluster 를 hibernate할 클러스터 이름으로 교체합니다.

    hibernate로 namespace-of-cluster 를 클러스터의 네임스페이스로 바꿉니다.

  2. spec.powerState 의 값을 Hibernating 로 변경합니다.

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

    oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml
    Copy to Clipboard Toggle word wrap

    name-of-cluster 를 hibernate할 클러스터 이름으로 교체합니다.

    hibernate로 namespace-of-cluster 를 클러스터의 네임스페이스로 바꿉니다.

    클러스터 완화 프로세스가 완료되면 클러스터 유형 값은 type=Hibernating 입니다.

선택한 클러스터가 손상되고 있습니다.

콘솔을 사용하여 하이버네이트 클러스터의 정상적인 작업을 다시 시작하려면 다음 단계를 완료하십시오.

  1. 탐색 메뉴에서 Infrastructure > Clusters 를 선택합니다. Manage clusters 탭이 선택되어 있는지 확인합니다.
  2. 재개할 클러스터의 옵션 메뉴에서 Resume 클러스터를 선택합니다.

프로세스가 완료되면 클러스터 페이지의 클러스터 상태는 Ready 입니다.

팁: 클러스터 페이지에서 다시 시작하려는 클러스터를 선택하고 작업 > 클러스터 재배치를 선택하여 여러 클러스터를 재개할 수 있습니다.

선택한 클러스터가 정상적인 작업을 다시 시작합니다.

CLI를 사용하여 하이버네이트 클러스터의 정상적인 작업을 다시 시작하려면 다음 단계를 완료하십시오.

  1. 다음 명령을 입력하여 클러스터 설정을 편집합니다. 

    oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>
    Copy to Clipboard Toggle word wrap

    name-of-cluster 를 hibernate할 클러스터 이름으로 교체합니다.

    hibernate로 namespace-of-cluster 를 클러스터의 네임스페이스로 바꿉니다.

  2. spec.powerState 의 값을 Running 으로 변경합니다.

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

    oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml
    Copy to Clipboard Toggle word wrap

    name-of-cluster 를 hibernate할 클러스터 이름으로 교체합니다.

    hibernate로 namespace-of-cluster 를 클러스터의 네임스페이스로 바꿉니다.

    클러스터 재시작 프로세스가 완료되면 클러스터 유형 값은 type=Running 입니다.

선택한 클러스터가 정상적인 작업을 다시 시작합니다.

1.7.8. 클러스터 업그레이드
링크 복사

다중 클러스터 엔진 Operator로 관리하려는 Red Hat OpenShift Container Platform 클러스터를 생성한 후 다중 클러스터 엔진 Operator 콘솔을 사용하여 해당 클러스터를 관리 클러스터가 사용하는 버전 채널에서 사용 가능한 최신 마이너 버전으로 업그레이드할 수 있습니다.

연결된 환경에서는 콘솔에서 업그레이드가 필요한 각 클러스터에 대해 제공되는 알림으로 업데이트가 자동으로 식별됩니다.

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

  • 해당 버전으로 업그레이드하기 위한 모든 사전 요구 사항을 충족하는지 확인합니다. 콘솔을 사용하여 클러스터를 업그레이드하기 전에 관리 클러스터에서 버전 채널을 업데이트해야 합니다.

    참고: 관리 클러스터에서 버전 채널을 업데이트한 후 다중 클러스터 엔진 Operator 콘솔에 업그레이드에 사용 가능한 최신 버전이 표시됩니다.

  • OpenShift Container Platform 관리 클러스터는 Ready 상태에 있어야 합니다.

중요: 다중 클러스터 엔진 Operator 콘솔을 사용하여 Red Hat OpenShift Dedicated에서 Red Hat OpenShift Kubernetes Service 관리 클러스터 또는 OpenShift Container Platform 관리 클러스터를 업그레이드할 수 없습니다.

1.7.8.2. 연결된 환경에서 클러스터 업그레이드
링크 복사

연결된 환경에서 클러스터를 업그레이드하려면 다음 단계를 완료합니다.

  1. 탐색 메뉴에서 Infrastructure > Clusters 로 이동합니다. 업그레이드를 사용할 수 있는 경우 배포 버전 열에 표시됩니다.
  2. 업그레이드할 클러스터를 Ready 상태로 선택합니다. 콘솔의 OpenShift Container Platform 클러스터만 업그레이드할 수 있습니다.
  3. 업그레이드 를 선택합니다.
  4. 각 클러스터의 새 버전을 선택합니다.
  5. 업그레이드 를 선택합니다.

클러스터 업그레이드에 실패하면 Operator는 일반적으로 업그레이드를 몇 번 재시도하고 중지한 후 실패한 구성 요소의 상태를 보고합니다. 경우에 따라 업그레이드 프로세스가 프로세스를 완료하려는 시도를 계속 순환합니다. 업그레이드 실패 후 클러스터를 이전 버전으로 롤백하는 것은 지원되지 않습니다. 클러스터 업그레이드에 실패하는 경우 Red Hat 지원에 문의하십시오.

1.7.8.3. 채널 선택
링크 복사

콘솔을 사용하여 OpenShift Container Platform에서 클러스터 업그레이드 채널을 선택할 수 있습니다. 채널을 선택하면 에라타 버전 및 릴리스 버전 둘 다에 사용할 수 있는 클러스터 업그레이드에 대해 자동으로 알립니다.

클러스터의 채널을 선택하려면 다음 단계를 완료하십시오.

  1. 탐색에서 Infrastructure > Clusters 를 선택합니다.
  2. 클러스터 세부 정보 페이지를 보려면 변경할 클러스터 이름을 선택합니다. 클러스터에 다른 채널을 사용할 수 있는 경우 채널 필드에 편집 아이콘이 표시됩니다.
  3. 편집 아이콘을 클릭하여 필드의 설정을 변경합니다.
  4. 새 채널 필드에서 채널을 선택합니다.

사용 가능한 채널 업데이트에 대한 알림은 클러스터의 클러스터 세부 정보 페이지에서 확인할 수 있습니다.

1.7.8.4. 연결이 끊긴 클러스터 업그레이드
링크 복사

다중 클러스터 엔진 Operator와 함께 OpenShift Update Service를 사용하여 연결이 끊긴 환경에서 클러스터를 업그레이드할 수 있습니다.

보안 문제로 인해 클러스터가 인터넷에 직접 연결되지 않는 경우도 있습니다. 이로 인해 업그레이드할 수 있는 시기와 이러한 업그레이드를 처리하는 방법을 알기가 어렵습니다. OpenShift Update Service를 구성하는 것이 도움이 될 수 있습니다.

OpenShift Update Service는 연결이 끊긴 환경에서 사용 가능한 관리 클러스터 버전을 모니터링하고 연결이 끊긴 환경에서 클러스터를 업그레이드하는 데 사용할 수 있도록 하는 별도의 Operator 및 피연산자입니다. OpenShift Update Service를 구성한 후 다음 작업을 수행할 수 있습니다.

  • 연결이 끊긴 클러스터에 대한 업그레이드를 사용할 수 있는 시기를 모니터링합니다.
  • 그래프 데이터 파일을 사용하여 업그레이드하기 위해 로컬 사이트로 미러링되는 업데이트를 확인합니다.
  • 콘솔을 사용하여 클러스터에 업그레이드를 사용할 수 있음을 알립니다.

다음 주제에서는 연결이 끊긴 클러스터를 업그레이드하는 절차를 설명합니다.

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

OpenShift Update Service를 사용하여 연결이 끊긴 클러스터를 업그레이드하려면 다음 사전 요구 사항이 있어야 합니다.

  • 제한된 OLM이 구성된 지원되는 OpenShift Container Platform 버전에서 실행 중인 배포된 허브 클러스터입니다. 제한된 OLM 을 구성하는 방법에 대한 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.

    참고: 제한된 OLM을 구성할 때 카탈로그 소스 이미지를 기록합니다.

  • hub 클러스터에서 관리하는 OpenShift Container Platform 클러스터

  • 클러스터 이미지를 미러링할 수 있는 로컬 저장소에 대한 인증 정보에 액세스합니다. 이 리포지토리를 생성하는 방법에 대한 자세한 내용은 연결이 끊긴 환경에서 미러링 을 참조하십시오.

    참고: 업그레이드할 현재 버전의 클러스터의 이미지를 미러링된 이미지 중 하나로 항상 사용할 수 있어야 합니다. 업그레이드에 실패하면 업그레이드 시도 시 클러스터가 클러스터 버전으로 되돌아갑니다.

1.7.8.4.2. 연결이 끊긴 미러 레지스트리 준비
링크 복사

업그레이드할 이미지와 로컬 미러 레지스트리로 업그레이드할 현재 이미지를 모두 미러링해야 합니다. 이미지를 미러링하려면 다음 단계를 완료합니다.

  1. 지원되는 버전인 < 4.x.z> :과 유사한 콘텐츠가 포함된 스크립트 파일을 생성합니다. 

    UPSTREAM_REGISTRY=quay.io
PRODUCT_REPO=openshift-release-dev
RELEASE_NAME=ocp-release
OCP_RELEASE=<4.x.z>-x86_64
LOCAL_REGISTRY=$(hostname):5000
LOCAL_SECRET_JSON=/path/to/pull/secret
    1 
    

oc adm -a ${LOCAL_SECRET_JSON} release mirror \
--from=${UPSTREAM_REGISTRY}/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE} \
--to=${LOCAL_REGISTRY}/ocp4 \
--to-release-image=${LOCAL_REGISTRY}/ocp4/release:${OCP_RELEASE}
    Copy to Clipboard Toggle word wrap
    1
    /path/to/pull/secret 을 OpenShift Container Platform 풀 시크릿의 경로로 바꿉니다.

  2. 스크립트를 실행하여 이미지를 미러링하고, 설정을 구성하고, 릴리스 이미지와 릴리스 콘텐츠를 분리합니다.

    ImageContentSourcePolicy 를 생성할 때 이 스크립트의 마지막 줄의 출력을 사용할 수 있습니다.

1.7.8.4.3. OpenShift Update Service용 Operator 배포
링크 복사

OpenShift Container Platform 환경에서 OpenShift Update Service용 Operator를 배포하려면 다음 단계를 완료하십시오.

  1. hub 클러스터에서 OpenShift Container Platform Operator 허브에 액세스합니다.
  2. OpenShift Update Service Operator 를 선택하여 Operator를 배포합니다. 필요한 경우 기본값을 업데이트합니다. Operator 배포는 openshift-cincinnati 라는 새 프로젝트를 생성합니다.

  3. Operator 설치가 완료될 때까지 기다립니다.

    OpenShift Container Platform 명령줄에 oc get pods 명령을 입력하여 설치 상태를 확인할 수 있습니다. Operator가 running 상태인지 확인합니다.

1.7.8.4.4. 그래프 데이터 init 컨테이너 빌드
링크 복사

OpenShift Update Service는 그래프 데이터 정보를 사용하여 사용 가능한 업그레이드를 결정합니다. 연결된 환경에서 OpenShift Update Service는 Cincinnati 그래프 데이터 GitHub 리포지토리에서 직접 업그레이드할 수 있는 그래프 데이터 정보를 가져옵니다. 연결이 끊긴 환경을 구성하기 때문에 init 컨테이너 를 사용하여 로컬 리포지토리에서 그래프 데이터를 사용할 수 있도록 설정해야 합니다. 그래프 데이터 init 컨테이너 를 생성하려면 다음 단계를 완료합니다.

  1. 다음 명령을 입력하여 그래프 데이터 Git 리포지토리를 복제합니다. 

    git clone https://github.com/openshift/cincinnati-graph-data
    Copy to Clipboard Toggle word wrap

  2. 그래프 데이터 init 에 대한 정보가 포함된 파일을 생성합니다. 이 샘플 Dockerfile 은 cincinnati-operator GitHub 리포지토리에서 찾을 수 있습니다. 파일의 내용은 다음 샘플에 표시됩니다. 

    FROM registry.access.redhat.com/ubi8/ubi:8.1
    1 
    

RUN curl -L -o cincinnati-graph-data.tar.gz https://github.com/openshift/cincinnati-graph-data/archive/master.tar.gz
    2 
    

RUN mkdir -p /var/lib/cincinnati/graph-data/
    3 
    

CMD exec /bin/bash -c "tar xvzf cincinnati-graph-data.tar.gz -C /var/lib/
cincinnati/graph-data/ --strip-components=1"
    4
    Copy to Clipboard Toggle word wrap

    이 예제에서는 다음을 수행합니다.

    1
    FROM 값은 OpenShift Update Service가 이미지를 찾는 외부 레지스트리입니다.
    2 3
    RUN 명령은 디렉터리를 생성하고 업그레이드 파일을 패키징합니다.
    4
    CMD 명령은 패키지 파일을 로컬 리포지토리에 복사하고 업그레이드를 위해 파일을 추출합니다.

  3. 다음 명령을 실행하여 그래프 데이터 init 컨테이너 를 빌드합니다. 

    podman build -f <path_to_Dockerfile> -t <${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container>:latest
    1
    2 
    
podman push <${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container><2>:latest --authfile=</path/to/pull_secret>.json
    3
    Copy to Clipboard Toggle word wrap
    1
    path_to_Dockerfile 을 이전 단계에서 생성한 파일의 경로로 바꿉니다.
    2
    ${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-data-container 를 로컬 그래프 데이터 init 컨테이너의 경로로 교체합니다.
    3
    /path/to/pull_secret 을 풀 시크릿 파일의 경로로 바꿉니다.

    참고: podman 이 설치되어 있지 않은 경우 명령의 podman 을 docker 로 교체할 수도 있습니다.

1.7.8.4.5. 미러링된 레지스트리에 대한 인증서 구성
링크 복사

미러링된 OpenShift Container Platform 릴리스 이미지를 저장하기 위해 보안 외부 컨테이너 레지스트리를 사용하는 경우 OpenShift Update Service는 업그레이드 그래프를 빌드하기 위해 이 레지스트리에 액세스해야 합니다. OpenShift Update Service Pod에서 작동하도록 CA 인증서를 구성하려면 다음 단계를 완료합니다.

  1. image.config.openshift.io 에 있는 OpenShift Container Platform 외부 레지스트리 API를 찾습니다. 외부 레지스트리 CA 인증서가 저장되는 위치입니다.

    자세한 내용은 OpenShift Container Platform 설명서에서 이미지 레지스트리 액세스에 대한 추가 신뢰 저장소 구성 을 참조하십시오.

  2. openshift-config 네임스페이스에 ConfigMap을 생성합니다.

  3. updateservice-registry 키 아래에 CA 인증서를 추가합니다. OpenShift Update Service는 이 설정을 사용하여 인증서를 찾습니다. 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: trusted-ca
data:
  updateservice-registry: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap

  4. image.config.openshift.io API에서 클러스터 리소스를 편집하여 additionalTrustedCA 필드를 생성한 ConfigMap의 이름으로 설정합니다. 

    oc patch image.config.openshift.io cluster -p '{"spec":{"additionalTrustedCA":{"name":"trusted-ca"}}}' --type merge
    Copy to Clipboard Toggle word wrap

    trusted-ca 를 새 ConfigMap의 경로로 교체합니다.

OpenShift Update Service Operator는 openshift-config 네임스페이스에서 생성한 image.config.openshift.io API 및 openshift-config 네임스페이스에서 생성한 ConfigMap을 모니터링한 다음 CA 인증서가 변경된 경우 배포를 다시 시작합니다.

1.7.8.4.6. OpenShift Update Service 인스턴스 배포
링크 복사

허브 클러스터에 OpenShift Update Service 인스턴스 배포를 완료하면 클러스터 업그레이드의 이미지를 미러링하고 연결이 끊긴 관리 클러스터에서 사용할 수 있는 이 인스턴스가 있습니다. 인스턴스를 배포하려면 다음 단계를 완료합니다.

  1. openshift-cincinnati 인 Operator의 기본 네임스페이스를 사용하지 않으려면 OpenShift Update Service 인스턴스에 대한 네임스페이스를 생성합니다.

    1. OpenShift Container Platform 허브 클러스터 콘솔 탐색 메뉴에서 관리 > 네임스페이스 를 선택합니다.
    2. 네임스페이스 생성을 선택합니다.
    3. 네임스페이스의 이름과 네임스페이스에 대한 기타 정보를 추가합니다.
    4. 생성 을 선택하여 네임스페이스를 생성합니다.
  2. OpenShift Container Platform 콘솔의 설치된 Operator 섹션에서 OpenShift Update Service Operator 를 선택합니다.
  3. 메뉴에서 Create Instance 를 선택합니다.

  4. OpenShift Update Service 인스턴스에서 콘텐츠를 붙여넣습니다. YAML 인스턴스는 다음 매니페스트와 유사할 수 있습니다. 

    apiVersion: cincinnati.openshift.io/v1beta2
kind: Cincinnati
metadata:
  name: openshift-update-service-instance
  namespace: openshift-cincinnati
spec:
  registry: <registry_host_name>:<port>
    1 
    
  replicas: 1
  repository: ${LOCAL_REGISTRY}/ocp4/release
  graphDataImage: '<host_name>:<port>/cincinnati-graph-data-container'
    2
    Copy to Clipboard Toggle word wrap
    1
    spec.registry 값을 이미지의 로컬 연결이 끊긴 레지스트리의 경로로 바꿉니다.
    2
    spec.graphDataImage 값을 그래프 데이터 init 컨테이너의 경로로 교체합니다. 그래프 데이터 init 컨테이너를 푸시하기 위해 podman push 명령을 실행할 때 사용한 값과 동일합니다.
  5. 만들기 를 선택하여 인스턴스를 만듭니다.
  6. hub 클러스터 CLI에서 oc get pods 명령을 입력하여 인스턴스 생성 상태를 확인합니다. 다소 시간이 걸릴 수 있지만 명령 결과에 인스턴스 및 Operator가 실행 중임을 표시하는 경우 프로세스가 완료됩니다.
1.7.8.4.7. 기본 레지스트리 덮어쓰기 (선택 사항)
링크 복사

참고: 이 섹션의 단계는 릴리스를 미러링된 레지스트리로 미러링한 경우에만 적용됩니다.

OpenShift Container Platform에는 업그레이드 패키지를 찾는 위치를 지정하는 기본 이미지 레지스트리 값이 있습니다. 연결이 끊긴 환경에서는 덮어쓰기를 생성하여 릴리스 이미지를 미러링한 로컬 이미지 레지스트리의 경로로 해당 값을 교체할 수 있습니다.

기본 레지스트리를 덮어쓰려면 다음 단계를 완료합니다.

  1. 다음 콘텐츠와 유사한 mirror.yaml 이라는 YAML 파일을 생성합니다. 

    apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: <your-local-mirror-name>
    1 
    
spec:
  repositoryDigestMirrors:
    - mirrors:
        - <your-registry>
    2 
    
      source: registry.redhat.io
    Copy to Clipboard Toggle word wrap
    1
    your-local-mirror-name 을 로컬 미러 이름으로 바꿉니다.
    2
    your-registry 를 로컬 미러 저장소의 경로로 바꿉니다.

    참고: oc adm release mirror 명령을 입력하여 로컬 미러의 경로를 찾을 수 있습니다.

  2. 관리 클러스터의 명령줄을 사용하여 다음 명령을 실행하여 기본 레지스트리를 재정의합니다. 

    oc apply -f mirror.yaml
    Copy to Clipboard Toggle word wrap
1.7.8.4.8. 연결이 끊긴 카탈로그 소스 배포
링크 복사

관리 클러스터에서 모든 기본 카탈로그 소스를 비활성화하고 새 카탈로그 소스를 생성합니다. 기본 위치를 연결된 위치에서 연결이 끊긴 로컬 레지스트리로 변경하려면 다음 단계를 완료합니다.

  1. 다음 콘텐츠와 유사한 source.yaml 이라는 YAML 파일을 생성합니다. 

    apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
spec:
  disableAllDefaultSources: true

---
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: my-operator-catalog
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: '<registry_host_name>:<port>/olm/redhat-operators:v1'
    1 
    
  displayName: My Operator Catalog
  publisher: grpc
    Copy to Clipboard Toggle word wrap
    1
    spec.image 값을 로컬 제한된 카탈로그 소스 이미지의 경로로 바꿉니다.

  2. 관리 클러스터의 명령줄에서 다음 명령을 실행하여 카탈로그 소스를 변경합니다. 

    oc apply -f source.yaml
    Copy to Clipboard Toggle word wrap
1.7.8.4.9. 관리 클러스터 매개변수 변경
링크 복사

관리 클러스터에서 ClusterVersion 리소스 정보를 업데이트하여 업그레이드를 검색하는 위치에서 기본 위치를 변경합니다.

  1. 관리형 클러스터에서 다음 명령을 입력하여 ClusterVersion 업스트림 매개변수가 현재 기본 공용 OpenShift Update Service 피연산자인지 확인합니다. 

    oc get clusterversion -o yaml
    Copy to Clipboard Toggle word wrap

    반환된 콘텐츠는 지원되는 버전으로 4.x 가 설정된 다음 내용과 유사할 수 있습니다. 

    apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: ClusterVersion
[..]
  spec:
    channel: stable-4.x
    upstream: https://api.openshift.com/api/upgrades_info/v1/graph
    Copy to Clipboard Toggle word wrap

  2. 허브 클러스터에서 다음 명령을 입력하여 OpenShift Update Service 피연산자의 경로 URL을 식별합니다. 

    oc get routes
    Copy to Clipboard Toggle word wrap

    이후 단계에서 반환된 값을 기록해 둡니다.

  3. 관리 클러스터의 명령줄에서 다음 명령을 입력하여 ClusterVersion 리소스를 편집합니다. 

    oc edit clusterversion version
    Copy to Clipboard Toggle word wrap

    spec.channel 값을 새 버전으로 바꿉니다.

    spec.upstream 값을 hub 클러스터 OpenShift Update Service 피연산자의 경로로 바꿉니다. 다음 단계를 완료하여 피연산자의 경로를 확인할 수 있습니다.

    1. hub 클러스터에서 다음 명령을 실행합니다. 

      oc get routes -A
      Copy to Clipboard Toggle word wrap
    2. Cincinnati의 경로를 찾으십시오. 피연산자가 HOST/PORT 필드의 값인 경로입니다.

  4. 관리 클러스터의 명령줄에서 다음 명령을 입력하여 ClusterVersion 의 upstream 매개변수가 로컬 허브 클러스터 OpenShift Update Service URL로 업데이트되었는지 확인합니다. 

    oc get clusterversion -o yaml
    Copy to Clipboard Toggle word wrap

    결과는 다음 콘텐츠와 유사합니다. 

    apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: ClusterVersion
[..]
  spec:
    channel: stable-4.x
    upstream: https://<hub-cincinnati-uri>/api/upgrades_info/v1/graph
    Copy to Clipboard Toggle word wrap
1.7.8.4.10. 사용 가능한 업그레이드 보기
링크 복사

클러스터 페이지에서 클러스터 의 배포 버전은 연결이 끊긴 레지스트리에 업그레이드가 있는 경우 사용 가능한 업그레이드가 있음을 나타냅니다. 클러스터를 선택하고 Actions 메뉴에서 Upgrade Cluster를 선택하여 사용 가능한 업그레이드를 볼 수 있습니다. 선택적 업그레이드 경로를 사용할 수 있는 경우 사용 가능한 업그레이드가 나열됩니다.

참고: 현재 버전이 로컬 이미지 저장소에 미러링되지 않은 경우 사용 가능한 업그레이드 버전이 표시되지 않습니다.

1.7.8.4.11. 채널 선택
링크 복사

콘솔을 사용하여 OpenShift Container Platform 버전 4.6 이상에서 클러스터 업그레이드 채널을 선택할 수 있습니다. 이러한 버전은 미러 레지스트리에서 사용할 수 있어야 합니다. 채널 선택 단계를 완료하여 업그레이드 채널을 지정합니다.

1.7.8.4.12. 클러스터 업그레이드
링크 복사

연결이 끊긴 레지스트리를 구성한 후 다중 클러스터 엔진 Operator 및 OpenShift Update Service는 연결이 끊긴 레지스트리를 사용하여 업그레이드를 사용할 수 있는지 확인합니다. 사용 가능한 업그레이드가 표시되지 않는 경우 클러스터의 현재 수준의 릴리스 이미지와 로컬 저장소에 미러링된 하나 이상의 이후 수준이 있는지 확인합니다. 현재 클러스터 버전의 릴리스 이미지를 사용할 수 없는 경우 업그레이드를 사용할 수 없습니다.

클러스터 페이지에서 클러스터 의 배포 버전은 연결이 끊긴 레지스트리에 업그레이드가 있는 경우 사용 가능한 업그레이드가 있음을 나타냅니다. 사용 가능한 업그레이드를 클릭하고 업그레이드 버전을 선택하여 이미지를 업그레이드할 수 있습니다.

관리 클러스터가 선택한 버전으로 업데이트되었습니다.

클러스터 업그레이드에 실패하면 Operator는 일반적으로 업그레이드를 몇 번 재시도하고 중지한 후 실패한 구성 요소의 상태를 보고합니다. 경우에 따라 업그레이드 프로세스가 프로세스를 완료하려는 시도를 계속 순환합니다. 업그레이드 실패 후 클러스터를 이전 버전으로 롤백하는 것은 지원되지 않습니다. 클러스터 업그레이드에 실패하는 경우 Red Hat 지원에 문의하십시오.

1.7.9. 클러스터 프록시 애드온 활성화
링크 복사

일부 환경에서는 관리 클러스터가 방화벽 뒤에 있으며 허브 클러스터를 통해 직접 액세스할 수 없습니다. 액세스 권한을 얻으려면 프록시 애드온을 설정하여 보다 안전한 연결로 관리형 클러스터의 kube-apiserver 에 액세스할 수 있습니다.

중요: 클러스터 프록시 애드온을 사용하려면 허브 클러스터에 클러스터 전체 프록시 구성이 있을 수 없습니다.

필요한 액세스: 편집기

허브 클러스터 또는 관리 클러스터에 대한 클러스터 프록시 애드온을 구성하려면 다음 단계를 완료하십시오.

  1. 다음 단계를 완료하여 관리 클러스터 kube-apiserver 에 액세스하도록 kubeconfig 파일을 구성합니다.

    1. 관리 클러스터에 유효한 액세스 토큰을 제공합니다.

      참고: 서비스 계정의 해당 토큰을 사용할 수 있습니다. 기본 네임스페이스에 있는 기본 서비스 계정을 사용할 수도 있습니다.

      1. 다음 명령을 실행하여 관리 클러스터의 kubeconfig 파일을 내보냅니다. 

        export KUBECONFIG=<managed-cluster-kubeconfig>
        Copy to Clipboard Toggle word wrap

      2. 다음 명령을 실행하여 포드에 액세스할 수 있는 서비스 계정에 역할을 추가합니다. 

        oc create role -n default test-role --verb=list,get --resource=pods
oc create rolebinding -n default test-rolebinding --serviceaccount=default:default --role=test-role
        Copy to Clipboard Toggle word wrap

      3. 다음 명령을 실행하여 서비스 계정 토큰의 시크릿을 찾습니다. 

        oc get secret -n default | grep <default-token>
        Copy to Clipboard Toggle word wrap

        default-token 을 시크릿 이름으로 교체합니다.

      4. 다음 명령을 실행하여 토큰을 복사합니다. 

        export MANAGED_CLUSTER_TOKEN=$(kubectl -n default get secret <default-token> -o jsonpath={.data.token} | base64 -d)
        Copy to Clipboard Toggle word wrap

        default-token 을 시크릿 이름으로 교체합니다.

    2. Red Hat Advanced Cluster Management Hub 클러스터에서 kubeconfig 파일을 구성합니다.

      1. 다음 명령을 실행하여 허브 클러스터에서 현재 kubeconfig 파일을 내보냅니다. 

        oc config view --minify --raw=true > cluster-proxy.kubeconfig
        Copy to Clipboard Toggle word wrap

      2. 편집기로 서버 파일을 수정합니다. 이 예에서는 sed 를 사용할 때 명령을 사용합니다. OSX를 사용하는 경우 alias sed=gsed 를 실행합니다. 

        export TARGET_MANAGED_CLUSTER=<managed-cluster-name>

export NEW_SERVER=https://$(oc get route -n multicluster-engine cluster-proxy-addon-user -o=jsonpath='{.spec.host}')/$TARGET_MANAGED_CLUSTER

sed -i'' -e '/server:/c\    server: '"$NEW_SERVER"'' cluster-proxy.kubeconfig

export CADATA=$(oc get configmap -n openshift-service-ca kube-root-ca.crt -o=go-template='{{index .data "ca.crt"}}' | base64)

sed -i'' -e '/certificate-authority-data:/c\    certificate-authority-data: '"$CADATA"'' cluster-proxy.kubeconfig
        Copy to Clipboard Toggle word wrap

      3. 다음 명령을 입력하여 원래 사용자 인증 정보를 삭제합니다. 

        sed -i'' -e '/client-certificate-data/d' cluster-proxy.kubeconfig
sed -i'' -e '/client-key-data/d' cluster-proxy.kubeconfig
sed -i'' -e '/token/d' cluster-proxy.kubeconfig
        Copy to Clipboard Toggle word wrap

      4. 서비스 계정의 토큰을 추가합니다. 

        sed -i'' -e '$a\    token: '"$MANAGED_CLUSTER_TOKEN"'' cluster-proxy.kubeconfig
        Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 대상 관리 클러스터의 대상 네임스페이스에 있는 모든 Pod를 나열합니다. 

    oc get pods --kubeconfig=cluster-proxy.kubeconfig -n <default>
    Copy to Clipboard Toggle word wrap

    default 네임스페이스를 사용하려는 네임스페이스로 바꿉니다.

  3. 관리 클러스터에서 다른 서비스에 액세스합니다. 이 기능은 관리 클러스터가 Red Hat OpenShift Container Platform 클러스터인 경우 사용할 수 있습니다. 서비스는 service-serving-certificate 를 사용하여 서버 인증서를 생성해야 합니다.

    • 관리 클러스터에서 다음 서비스 계정 토큰을 사용합니다. 

      export PROMETHEUS_TOKEN=$(kubectl get secret -n openshift-monitoring $(kubectl get serviceaccount -n openshift-monitoring prometheus-k8s -o=jsonpath='{.secrets[0].name}') -o=jsonpath='{.data.token}' | base64 -d)
      Copy to Clipboard Toggle word wrap

    • hub 클러스터에서 다음 명령을 실행하여 인증 기관을 파일로 변환합니다. 

      oc get configmap kube-root-ca.crt -o=jsonpath='{.data.ca\.crt}' > hub-ca.crt
      Copy to Clipboard Toggle word wrap

  4. 다음 명령을 사용하여 관리 클러스터의 Prometheus 지표를 가져옵니다. 

    export SERVICE_NAMESPACE=openshift-monitoring
export SERVICE_NAME=prometheus-k8s
export SERVICE_PORT=9091
export SERVICE_PATH="api/v1/query?query=machine_cpu_sockets"
curl --cacert hub-ca.crt $NEW_SERVER/api/v1/namespaces/$SERVICE_NAMESPACE/services/$SERVICE_NAME:$SERVICE_PORT/proxy-service/$SERVICE_PATH -H "Authorization: Bearer $PROMETHEUS_TOKEN"
    Copy to Clipboard Toggle word wrap
1.7.9.2. 클러스터 프록시 애드온의 프록시 설정 구성
링크 복사

관리 클러스터가 HTTP 및 HTTPS 프록시 서버를 통해 hub 클러스터와 통신할 수 있도록 클러스터 프록시 애드온의 프록시 설정을 구성할 수 있습니다. 클러스터 프록시 애드온 에이전트가 프록시 서버를 통해 hub 클러스터에 액세스해야 하는 경우 프록시 설정을 구성해야 할 수 있습니다.

클러스터 프록시 애드온에 대한 프록시 설정을 구성하려면 다음 단계를 완료합니다.

  1. hub 클러스터에 AddOnDeploymentConfig 리소스를 생성하고 spec.proxyConfig 매개변수를 추가합니다. 다음 예제를 참조하십시오. 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: AddOnDeploymentConfig
metadata:
  name: <name>
    1 
    
  namespace: <namespace>
    2 
    
spec:
  agentInstallNamespace: open-cluster-management-agent-addon
  proxyConfig:
    httpsProxy: "http://<username>:<password>@<ip>:<port>"
    3 
    
    noProxy: ".cluster.local,.svc,172.30.0.1"
    4 
    
    caBundle: <value>
    5
    Copy to Clipboard Toggle word wrap
    1
    애드온 배포 구성 이름을 추가합니다.
    2
    관리되는 클러스터 이름을 추가합니다.
    3
    HTTP 프록시 또는 HTTPS 프록시를 지정합니다.
    4
    kube-apiserver 의 IP 주소를 추가합니다. IP 주소를 가져오려면 관리 클러스터에서 다음 명령을 실행합니다. oc -n default describe svc kubernetes | grep IP:
    5
    httpsProxy 필드에 HTTPS 프록시를 지정하는 경우 프록시 서버 CA 번들을 설정합니다.

  2. 생성한 AddOnDeploymentConfig 리소스를 참조하여 ManagedClusterAddOn 리소스를 업데이트합니다. 다음 예제를 참조하십시오. 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: ManagedClusterAddOn
metadata:
  name: cluster-proxy
  namespace: <namespace>
    1 
    
spec:
installNamespace: open-cluster-management-addon
configs:
  group: addon.open-cluster-management.io
  resource: addondeploymentconfigs
  name: <name>
    2 
    
  namespace: <namespace>
    3
    Copy to Clipboard Toggle word wrap
1
관리되는 클러스터 이름을 추가합니다.
2
애드온 배포 구성 이름을 추가합니다.
3
관리되는 클러스터 이름을 추가합니다.
  1. open-cluster-management-addon 네임스페이스의 클러스터 프록시 에이전트 포드에 관리 클러스터에 HTTPS_PROXY 또는 NO_PROXY 환경 변수가 있는지 확인하여 프록시 설정을 확인합니다.

클러스터 프록시 애드온을 사용하여 관리 클러스터 kube-apiserver 리소스 또는 관리 클러스터 서비스에 액세스하여 특정 리소스를 수집하고 로그를 가져오고 콘솔에서 데이터를 봅니다. 세 가지 방법을 사용하여 kube-apiserver 에 액세스합니다. 다음 항목을 참조하십시오.

필요한 액세스: 편집기

1.7.10.1. 사전 요구 사항
링크 복사
1.7.10.2. 관리 클러스터 사용자 토큰을 사용하여 데이터 수집
링크 복사

관리 클러스터 사용자 토큰을 사용하여 데이터를 수집하려면 다음 단계를 완료하여 관리 클러스터의 기본 네임스페이스에 있는 Pod를 나열합니다.

  1. 다음 명령을 실행하여 클러스터 프록시 URL을 내보냅니다. 필요한 경우 값을 바꿉니다. 

    export CLUSTER_PROXY_URL=https://$(oc get route -n multicluster-engine cluster-proxy-addon-user -o=jsonpath='{.spec.host}')/<managed-cluster-name>
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 ConfigMap 을 가져옵니다. 

    oc get configmap kube-root-ca.crt -o=jsonpath='{.data.ca\.crt}' > hub-ca.crt
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 CA(인증 기관) 인증서를 전송합니다. 

    curl --cacert hub-ca.crt -H "Authorization: Bearer $TOKEN" https://$CLUSTER_PROXY_URL/api/v1/namespaces/default/pods
    Copy to Clipboard Toggle word wrap

    참고: 관리 클러스터의 기본 네임스페이스에 Pod를 나열할 수 있는 권한이 있는 사용자 토큰이 필요합니다.

1.7.10.3. 허브 클러스터 사용자 토큰을 사용하여 데이터 수집
링크 복사

허브 클러스터 사용자 토큰을 사용하여 데이터를 수집하려면 대상 허브 클러스터 및 대상 관리 클러스터는 두 클러스터가 동일한 사용자를 인식할 수 있도록 동일한 외부 ID 공급자를 사용해야 합니다.

hub 클러스터 개발자 사용자 토큰을 사용하여 default 네임스페이스의 Pod를 나열하려면 먼저 관리 클러스터에서 개발자를 위한 올바른 Role 및 RoleBinding 을 생성해야 합니다.

Red Hat Advanced Cluster Management for Kubernetes를 사용하는 경우 ClusterPermission API를 사용하여 hub 클러스터에서 Role 및 RoleBinding 오브젝트를 생성할 수 있습니다.

Pod의 get 및 list 권한을 사용자 개발자에 바인딩하는 다음 예제를 참조하십시오. 

apiVersion: rbac.open-cluster-management.io/v1alpha1
kind: ClusterPermission
metadata:
  name: <name>
  namespace: <cluster-namespace>
spec:
  roles:
  - namespace: default
    rules:
    - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get","list"]
  roleBindings:
  - namespace: default
    roleRef:
      kind: Role
    subject:
      apiGroup: rbac.authorization.k8s.io
      kind: User
      name: developer
Copy to Clipboard Toggle word wrap
1.7.10.4. 관리형 클러스터 서비스를 사용하여 데이터 수집
링크 복사

관리형 클러스터 서비스에 액세스하여 데이터를 수집하려면 관리형 클러스터는 Red Hat OpenShift Container Platform 클러스터여야 하며 서비스는 services-serving-certificate 서비스를 사용하여 서버 인증서를 생성해야 합니다.

다음 단계를 완료합니다.

  1. 관리 클러스터에서 Prometheus 서비스 토큰을 가져옵니다. 다음 명령을 실행합니다. 

    export PROMETHEUS_TOKEN=$(kubectl get secret -n openshift-monitoring $(kubectl get serviceaccount -n openshift-monitoring prometheus-k8s -o=jsonpath='{.secrets[0].name}') -o=jsonpath='{.data.token}' | base64 -d)
    Copy to Clipboard Toggle word wrap

  2. hub 클러스터에서 Prometheus 관리 클러스터 지표를 가져옵니다. 다음 명령을 실행합니다. 

    export SERVICE_NAMESPACE=openshift-monitoring
export SERVICE_NAME=prometheus-k8s
export SERVICE_PORT=9091
export SERVICE_PATH="api/v1/query?query=machine_cpu_sockets"
curl --cacert hub-ca.crt $CLUSTER_PROXY_URL/api/v1/namespaces/$SERVICE_NAMESPACE/services/$SERVICE_NAME:$SERVICE_PORT/proxy-service/$SERVICE_PATH -H "Authorization: Bearer $PROMETHEUS_TOKEN"
    Copy to Clipboard Toggle word wrap

1.7.11. 관리 클러스터에서 실행되도록 Ansible Automation Platform 작업 구성
링크 복사

멀티 클러스터 엔진 Operator는 Red Hat Ansible Automation Platform과 통합되어 클러스터를 생성하거나 업그레이드하기 전이나 후에 발생하는 prehook 및 posthook Ansible 작업 인스턴스를 생성할 수 있습니다. 클러스터 제거를 위한 prehook 및 posthook 작업을 구성하고 클러스터 확장 작업은 지원되지 않습니다.

필수 액세스: 클러스터 관리자

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

클러스터에서 자동화 템플릿을 실행하려면 다음 사전 요구 사항을 충족해야 합니다.

  • OpenShift Container Platform을 설치합니다.
  • Ansible Automation Platform Resource Operator를 설치하여 Ansible 작업을 Git 서브스크립션의 라이프사이클에 연결합니다. 자동화 템플릿을 사용하여 Ansible Automation Platform 작업을 시작할 때 최상의 결과를 얻으려면 Ansible Automation Platform 작업 템플릿이 실행될 때 멱등이어야 합니다. OpenShift Container Platform OperatorHub 에서 Ansible Automation Platform Resource Operator를 찾을 수 있습니다.
  • Ansible Automation Platform Resource Operator를 설치할 때 *-cluster 범위 채널을 선택하고 모든 네임스페이스 설치 모드를 선택해야 합니다.

클러스터를 생성할 때, 클러스터를 가져올 때 또는 클러스터를 생성한 후 클러스터에 사용할 자동화 템플릿을 지정할 수 있습니다.

클러스터를 생성하거나 가져올 때 템플릿을 지정하려면 자동화 단계에서 클러스터에 적용할 Ansible 템플릿을 선택합니다. 자동화 템플릿이 없는 경우 자동화 템플릿 추가 를 클릭하여 하나를 생성합니다.

클러스터를 생성한 후 템플릿을 지정하려면 기존 클러스터의 작업 메뉴에서 자동화 템플릿 업데이트를 클릭합니다. 업데이트 자동화 템플릿 옵션을 사용하여 기존 자동화 템플릿을 업데이트할 수도 있습니다.

1.7.11.3. 자동화 템플릿 생성
링크 복사

클러스터 설치 또는 업그레이드를 사용하여 Ansible 작업을 시작하려면 작업을 실행할 시기를 지정하는 자동화 템플릿을 생성해야 합니다. 클러스터 설치 또는 업그레이드 전후에 실행되도록 구성할 수 있습니다.

템플릿을 생성하는 동안 Ansible 템플릿 실행에 대한 세부 정보를 지정하려면 콘솔의 단계를 완료합니다.

  1. 탐색에서 Infrastructure > Automation 을 선택합니다.

  2. 상황에 적합한 경로를 선택합니다.

    • 새 템플릿을 생성하려면 Ansible 템플릿 생성 을 클릭하고 3단계를 계속합니다.
    • 기존 템플릿을 수정하려면 수정할 템플릿의 옵션 메뉴에서 템플릿 편집을 클릭하고 5단계를 계속합니다.
  3. 소문자 영숫자 또는 하이픈(-)을 포함하는 템플릿의 고유한 이름을 입력합니다.
  4. 새 템플릿에 사용할 인증 정보를 선택합니다.

  5. 인증 정보를 선택한 후 모든 작업에 사용할 Ansible 인벤토리를 선택할 수 있습니다. Ansible 인증 정보를 Ansible 템플릿에 연결하려면 다음 단계를 완료합니다.

    1. 탐색에서 자동화 를 선택합니다. 인증 정보에 연결되지 않은 템플릿 목록에 있는 템플릿에는 템플릿을 기존 인증 정보에 연결하는 데 사용할 수 있는 인증 정보에 대한 링크가 포함되어 있습니다. 템플릿과 동일한 네임스페이스에 있는 인증 정보만 표시됩니다.
    2. 선택할 수 있는 인증 정보가 없거나 기존 인증 정보를 사용하지 않으려면 연결할 템플릿의 옵션 메뉴에서 템플릿 편집을 선택합니다.
    3. 인증 정보 추가 를 클릭하고 인증 정보를 생성해야 하는 경우 Ansible Automation Platform에 대한 인증 정보 생성 절차를 완료합니다.
    4. 템플릿과 동일한 네임스페이스에 인증 정보를 생성한 후 템플릿을 편집할 때 Ansible Automation Platform 인증 정보 필드에서 인증 정보를 선택합니다.
  6. 클러스터가 설치되기 전에 Ansible 작업을 시작하려면 사전 설치 자동화 템플릿 섹션에서 자동화 템플릿 추가 를 선택합니다.

  7. 표시되는 모달의 작업 템플릿 또는 워크플로 작업 템플릿 중에서 선택합니다. job_tags,skip_tags, 워크플로우 유형을 추가할 수도 있습니다.

    • Extra variables 필드를 사용하여 key=value 쌍의 형태로 AnsibleJob 리소스에 데이터를 전달합니다.
    • 특수 키 cluster_deployment 및 install_config 는 추가 변수로 자동으로 전달됩니다. 클러스터에 대한 일반 정보와 클러스터 설치 구성에 대한 세부 정보가 포함되어 있습니다.
  8. 클러스터 설치 또는 업그레이드에 추가할 prehook 및 posthook Ansible 작업의 이름을 선택합니다.
  9. 필요한 경우 Ansible 작업을 끌어 순서를 변경합니다.
  10. 클러스터를 설치한 후 시작하려는 모든 자동화 템플릿, 업그레이드 후 자동화 템플릿 섹션, 업그레이드 전 자동화 템플릿 섹션, 업그레이드 후 자동화 템플릿 섹션에 대해 5 - 7단계를 반복합니다. 클러스터를 업그레이드할 때 Extra variables 필드를 사용하여 key=value 쌍 형식으로 AnsibleJob 리소스에 데이터를 전달할 수 있습니다. cluster_deployment 및 install_config 특수 키 외에도 cluster_info 특수 키는 ManagedClusterInfo 리소스의 데이터를 포함하는 추가 변수로 자동으로 전달됩니다.

Ansible 템플릿은 지정된 작업이 발생할 때 이 템플릿을 지정하는 클러스터에서 실행되도록 구성되어 있습니다.

1.7.11.4. Ansible 작업의 상태 보기
링크 복사

실행 중인 Ansible 작업의 상태를 확인하여 시작된 후 성공적으로 실행 중인지 확인할 수 있습니다. 실행 중인 Ansible 작업의 현재 상태를 보려면 다음 단계를 완료합니다.

  1. 메뉴에서 Infrastructure > Clusters를 선택하여 Clusters 페이지에 액세스합니다.
  2. 세부 정보를 보려면 클러스터 이름을 선택합니다.

  3. 클러스터 정보에서 Ansible 작업의 마지막 실행 상태를 확인합니다. 항목은 다음 상태 중 하나를 표시합니다.

    • 설치 prehook 또는 posthook 작업이 실패하면 클러스터 상태가 Failed 를 표시합니다.
    • 업그레이드 prehook 또는 posthook 작업이 실패하면 업그레이드에 실패한 배포 필드에 경고가 표시됩니다.
1.7.11.5. 실패한 Ansible 작업 다시 실행
링크 복사

클러스터 prehook 또는 posthook가 실패한 경우 클러스터 페이지에서 업그레이드를 재시도할 수 있습니다.

시간을 절약하기 위해 클러스터 자동화 템플릿의 일부인 실패한 Ansible posthook만 실행할 수도 있습니다. 전체 업그레이드를 재시도하지 않고 posthooks만 다시 실행하려면 다음 단계를 완료합니다.

  1. ClusterCurator 리소스의 루트에 다음 내용을 추가하여 설치 posthook를 다시 실행합니다. 

    operation:
  retryPosthook: installPosthook
    Copy to Clipboard Toggle word wrap

  2. ClusterCurator 리소스의 루트에 다음 콘텐츠를 추가하여 업그레이드 posthook를 다시 실행합니다. 

    operation:
  retryPosthook: upgradePosthook
    Copy to Clipboard Toggle word wrap

콘텐츠를 추가한 후 Ansible posthook를 실행하기 위해 새 작업이 생성됩니다.

1.7.11.6. 모든 작업에 사용할 Ansible 인벤토리 지정
링크 복사

ClusterCurator 리소스를 사용하여 모든 작업에 사용할 Ansible 인벤토리를 지정할 수 있습니다. 다음 예제를 참조하십시오. channel 및 desiredUpdate 를 ClusterCurator 의 올바른 값으로 바꿉니다. 

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: test-inno
  namespace: test-inno
spec:
  desiredCuration: upgrade
  destroy: {}
  install: {}
  scale: {}
  upgrade:
    channel: stable-4.x
    desiredUpdate: 4.x.1
    monitorTimeout: 150
    posthook:
    - extra_vars: {}
      clusterName: test-inno
      type: post_check
      name: ACM Upgrade Checks
    prehook:
    - extra_vars: {}
      clusterName: test-inno
      type: pre_check
      name: ACM Upgrade Checks
    towerAuthSecret: awx
    inventory: Demo Inventory
Copy to Clipboard Toggle word wrap

참고: 예제 리소스를 사용하려면 인벤토리가 이미 Ansible에 있어야 합니다.

콘솔에서 사용 가능한 Ansible 인벤토리 목록을 확인하여 인벤토리가 생성되었는지 확인할 수 있습니다.

ClusterCurator 리소스를 사용하여 클러스터 Curator에서 생성한 자동화 작업 Pod에 사용자 정의 레이블을 내보낼 수 있습니다. 모든 큐레이션 유형에 사용자 지정 레이블을 푸시할 수 있습니다. 다음 예제를 참조하십시오. 

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: cluster1
{{{}  namespace: cluster1
  labels:
    test1: test1
    test2: test2
{}}}spec:
  desiredCuration: install
  install:
    jobMonitorTimeout: 5
    posthook:
      - extra_vars: {}
        name: Demo Job Template
        type: Job
    prehook:
      - extra_vars: {}
        name: Demo Job Template
        type: Job
    towerAuthSecret: toweraccess
Copy to Clipboard Toggle word wrap
1.7.11.8. EUS (Extended Update Support) 업그레이드에 ClusterCurator 사용
링크 복사

ClusterCurator 리소스를 사용하여 EUS 릴리스 간에 더 쉽고 자동 업그레이드를 수행할 수 있습니다.

  1. 중간 릴리스 값을 사용하여 spec.upgrade.intermediateUpdate 를 ClusterCurator 리소스에 추가합니다. 중간 릴리스가 4.17.x 이고 desiredUpdate 는 4.18.x 인 다음 샘플을 참조하십시오. 

    spec:
  desiredCuration: upgrade
  upgrade:
    intermediateUpdate: 4.17.x
    desiredUpdate: 4.18.x
    monitorTimeout: 120
    Copy to Clipboard Toggle word wrap

  2. 선택 사항: machineconfigpools 를 일시 중지하여 더 빠른 업그레이드를 위해 중간 릴리스를 건너뛸 수 있습니다. posthook 작업에 Un pause machinepool 을 입력하고 prehook 작업에 machinepool을 일시 중지합니다. 다음 예제를 참조하십시오. 

        posthook:
      - extra_vars: {}
        name: Unpause machinepool
        type: Job
    prehook:
      - extra_vars: {}
        name: Pause machinepool
        type: Job
    Copy to Clipboard Toggle word wrap

EUS를 EUS로 업그레이드하도록 구성된 ClusterCurator 의 다음 전체 예를 참조하십시오. 

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  annotations:
    cluster.open-cluster-management.io/upgrade-clusterversion-backoff-limit: "10"
  name: your-name
  namespace: your-namespace
spec:
  desiredCuration: upgrade
 upgrade:
    intermediateUpdate: 4.17.x
    desiredUpdate: 4.18.x
    monitorTimeout: 120
    posthook:
      - extra_vars: {}
        name: Unpause machinepool
        type: Job
    prehook:
      - extra_vars: {}
        name: Pause machinepool
        type: Job
Copy to Clipboard Toggle word wrap

Red Hat Ansible Automation Platform은 멀티 클러스터 엔진 Operator와 통합되어 호스트 클러스터를 생성하거나 업데이트하기 전이나 후에 발생하는 prehook 및 posthook Ansible Automation Platform 작업 인스턴스를 생성할 수 있습니다.

필수 액세스: 클러스터 관리자

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

클러스터에서 자동화 템플릿을 실행하려면 다음 사전 요구 사항을 충족해야 합니다.

  • 지원되는 OpenShift Container Platform 버전
  • Ansible Automation Platform Resource Operator를 설치하여 Ansible Automation Platform 작업을 Git 서브스크립션 라이프사이클에 연결합니다. 자동화 템플릿을 사용하여 Ansible Automation Platform 작업을 시작할 때 Ansible Automation Platform 작업 템플릿이 실행될 때 멱등인지 확인합니다. OpenShift Container Platform OperatorHub 에서 Ansible Automation Platform Resource Operator를 찾을 수 있습니다.

호스트 클러스터를 설치하는 Ansible Automation Platform 작업을 시작하려면 다음 단계를 완료합니다.

  1. pausedUntil: true 필드를 포함하여 HostedCluster 및 NodePool 리소스를 생성합니다. hcp create cluster 명령줄 interface 명령을 사용하는 경우 --pausedUntil: true 플래그를 지정할 수 있습니다.

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

    apiVersion: hypershift.openshift.io/v1beta1
kind: HostedCluster
metadata:
  name: my-cluster
  namespace: clusters
spec:
  pausedUntil: 'true'
    Copy to Clipboard Toggle word wrap 
    apiVersion: hypershift.openshift.io/v1beta1
kind: NodePool
metadata:
  name: my-cluster-us-east-2
  namespace: clusters
spec:
  pausedUntil: 'true'
    Copy to Clipboard Toggle word wrap

  2. HostedCluster 리소스와 동일한 이름 및 HostedCluster 리소스와 동일한 네임스페이스에 ClusterCurator 리소스를 생성합니다. 다음 예제를 참조하십시오. 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: my-cluster
  namespace: clusters
  labels:
    open-cluster-management: curator
spec:
  desiredCuration: install
  install:
    jobMonitorTimeout: 5
    prehook:
      - name: Demo Job Template
        extra_vars:
          variable1: something-interesting
          variable2: 2
      - name: Demo Job Template
    posthook:
      - name: Demo Job Template
    towerAuthSecret: toweraccess
    Copy to Clipboard Toggle word wrap

  3. Ansible Automation Platform Tower에 인증이 필요한 경우 시크릿 리소스를 생성합니다. 다음 예제를 참조하십시오. 

    apiVersion: v1
kind: Secret
metadata:
  name: toweraccess
  namespace: clusters
stringData:
  host: https://my-tower-domain.io
  token: ANSIBLE_TOKEN_FOR_admin
    Copy to Clipboard Toggle word wrap

호스트 클러스터를 업데이트하는 Ansible Automation Platform 작업을 실행하려면 업데이트할 호스팅 클러스터의 ClusterCurator 리소스를 편집합니다. 다음 예제를 참조하십시오. 

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: my-cluster
  namespace: clusters
  labels:
    open-cluster-management: curator
spec:
  desiredCuration: upgrade
  upgrade:
    desiredUpdate: 4.17.1
1 

    monitorTimeout: 120
    prehook:
      - name: Demo Job Template
        extra_vars:
          variable1: something-interesting
          variable2: 2
      - name: Demo Job Template
    posthook:
      - name: Demo Job Template
    towerAuthSecret: toweraccess
Copy to Clipboard Toggle word wrap
1
지원되는 버전에 대한 자세한 내용은 호스팅 컨트롤 플레인 을 참조하십시오.

참고: 호스팅된 클러스터를 이러한 방식으로 업데이트할 때 호스팅된 컨트롤 플레인과 노드 풀을 동일한 버전으로 업데이트합니다. 호스팅된 컨트롤 플레인 및 노드 풀을 다른 버전으로 업데이트할 수 없습니다.

호스팅된 클러스터를 삭제하는 Ansible Automation Platform 작업을 실행하려면 삭제하려는 호스팅 클러스터의 ClusterCurator 리소스를 편집합니다. 다음 예제를 참조하십시오. 

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: my-cluster
  namespace: clusters
  labels:
    open-cluster-management: curator
spec:
  desiredCuration: destroy
  destroy:
    jobMonitorTimeout: 5
    prehook:
      - name: Demo Job Template
        extra_vars:
          variable1: something-interesting
          variable2: 2
      - name: Demo Job Template
    posthook:
      - name: Demo Job Template
    towerAuthSecret: toweraccess
Copy to Clipboard Toggle word wrap

참고: AWS에서 호스팅 클러스터를 삭제하는 것은 지원되지 않습니다.

1.7.12.5. 추가 리소스
링크 복사

1.7.13. ClusterClaims
링크 복사

ClusterClaim 은 관리 클러스터의 클러스터 범위 CRD(사용자 정의 리소스 정의)입니다. ClusterClaim 은 관리 클러스터가 요구하는 정보를 나타냅니다. ClusterClaim 을 사용하여 대상 클러스터에서 리소스의 배치를 확인할 수 있습니다.

다음 예제는 YAML 파일에서 식별되는 ClusterClaim 을 보여줍니다. 

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: ClusterClaim
metadata:
  name: id.openshift.io
spec:
  value: 95f91f25-d7a2-4fc3-9237-2ef633d8451c
Copy to Clipboard Toggle word wrap

다음 표에서는 다중 클러스터 엔진 운영자가 관리하는 클러스터의 정의된 ClusterClaim 목록을 보여줍니다.

Expand
클레임 이름예약됨변경 가능설명

id.k8s.io

true

false

업스트림 제안에 정의된 ClusterID

kubeversion.open-cluster-management.io

true

true

Kubernetes 버전

platform.open-cluster-management.io

true

false

AWS, GCE, Equinix Metal과 같은 관리형 클러스터가 실행 중인 플랫폼

product.open-cluster-management.io

true

false

OpenShift, Cryostathos, EKS 및 GKE와 같은 제품 이름

id.openshift.io

false

false

OpenShift Container Platform 클러스터에서만 사용할 수 있는 OpenShift Container Platform 외부 ID

consoleurl.openshift.io

false

true

OpenShift Container Platform 클러스터에서만 사용할 수 있는 관리 콘솔의 URL

version.openshift.io

false

true

OpenShift Container Platform 클러스터에서만 사용할 수 있는 OpenShift Container Platform 버전

관리 클러스터에서 이전 클레임 중 삭제 또는 업데이트되는 경우 이전 클레임이 자동으로 복원되거나 이전 버전으로 롤백됩니다.

관리되는 클러스터가 허브에 가입하면 관리 클러스터에서 생성된 모든 ClusterClaim 이 허브 클러스터에서 ManagedCluster 리소스의 상태와 동기화됩니다. ManagedCluster 의 clusterClaims 다음 예제를 참조하여 4.x 를 지원되는 OpenShift Container Platform 버전으로 교체합니다. 

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  labels:
    cloud: Amazon
    clusterID: 95f91f25-d7a2-4fc3-9237-2ef633d8451c
    installer.name: multiclusterhub
    installer.namespace: open-cluster-management
    name: cluster1
    vendor: OpenShift
  name: cluster1
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60
status:
  allocatable:
    cpu: '15'
    memory: 65257Mi
  capacity:
    cpu: '18'
    memory: 72001Mi
  clusterClaims:
    - name: id.k8s.io
      value: cluster1
    - name: kubeversion.open-cluster-management.io
      value: v1.18.3+6c42de8
    - name: platform.open-cluster-management.io
      value: AWS
    - name: product.open-cluster-management.io
      value: OpenShift
    - name: id.openshift.io
      value: 95f91f25-d7a2-4fc3-9237-2ef633d8451c
    - name: consoleurl.openshift.io
      value: 'https://console-openshift-console.apps.xxxx.dev04.red-chesterfield.com'
    - name: version.openshift.io
      value: '4.x'
  conditions:
    - lastTransitionTime: '2020-10-26T07:08:49Z'
      message: Accepted by hub cluster admin
      reason: HubClusterAdminAccepted
      status: 'True'
      type: HubAcceptedManagedCluster
    - lastTransitionTime: '2020-10-26T07:09:18Z'
      message: Managed cluster joined
      reason: ManagedClusterJoined
      status: 'True'
      type: ManagedClusterJoined
    - lastTransitionTime: '2020-10-30T07:20:20Z'
      message: Managed cluster is available
      reason: ManagedClusterAvailable
      status: 'True'
      type: ManagedClusterConditionAvailable
  version:
    kubernetes: v1.18.3+6c42de8
Copy to Clipboard Toggle word wrap
1.7.13.1. 사용자 정의 클러스터 클레임 생성
링크 복사

관리 클러스터에서 사용자 지정 이름으로 ClusterClaim 리소스를 생성하면 쉽게 식별할 수 있습니다. 사용자 정의 ClusterClaim 리소스는 hub 클러스터에서 ManagedCluster 리소스의 상태와 동기화됩니다. 다음 콘텐츠는 사용자 지정된 ClusterClaim 리소스의 정의 예를 보여줍니다. 

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: ClusterClaim
metadata:
  name: <custom_claim_name>
spec:
  value: <custom_claim_value>
Copy to Clipboard Toggle word wrap

spec.value 필드의 길이는 1024 이상이어야 합니다. ClusterClaim 리소스 를 생성하려면 리소스 clusterclaims.cluster.open-cluster-management.io 에 대한 생성 권한이 필요합니다.

1.7.13.2. 기존 클러스터 클레임 나열
링크 복사

kubectl 명령을 사용하여 관리 클러스터에 적용되는 ClusterClaim을 나열하여 ClusterClaim을 오류 메시지와 비교할 수 있습니다.

참고: 리소스 clusterclaims.cluster.open-cluster-management.io 에 대한 목록 권한이 있는지 확인합니다.

다음 명령을 실행하여 관리 클러스터에 있는 기존 ClusterClaim을 모두 나열합니다. 

kubectl get clusterclaims.cluster.open-cluster-management.io
Copy to Clipboard Toggle word wrap

1.7.14. ManagedClusterSets
링크 복사

ManagedClusterSet 은 관리 클러스터 그룹입니다. 관리되는 클러스터 세트는 모든 관리 클러스터에 대한 액세스를 관리하는 데 도움이 될 수 있습니다. ManagedClusterSetBinding 리소스를 생성하여 ManagedClusterSet 리소스를 네임스페이스에 바인딩할 수도 있습니다.

각 클러스터는 관리 클러스터 세트의 멤버여야 합니다. 허브 클러스터를 설치하면 ManagedClusterSet 리소스가 기본 이라는 리소스가 생성됩니다. 관리 클러스터 세트에 할당되지 않은 모든 클러스터는 기본 관리 클러스터 세트에 자동으로 할당됩니다. 기본 관리 클러스터 세트를 삭제하거나 업데이트할 수 없습니다.

관리 클러스터 세트를 생성하고 관리하는 방법에 대한 자세한 내용은 계속 읽으십시오.

1.7.14.1. ManagedClusterSet생성
링크 복사

관리 클러스터 세트에서 관리 클러스터를 그룹화하여 관리 클러스터에서 사용자 액세스를 제한할 수 있습니다.

필수 액세스: 클러스터 관리자

ManagedClusterSet 은 클러스터 범위 리소스이므로 ManagedClusterSet 을 생성하는 클러스터에 대한 클러스터 관리 권한이 있어야 합니다. 관리되는 클러스터는 둘 이상의 ManagedClusterSet 에 포함될 수 없습니다. 다중 클러스터 엔진 Operator 콘솔 또는 CLI에서 관리 클러스터 세트를 생성할 수 있습니다.

참고: 관리형 클러스터 세트에 추가되지 않은 클러스터 풀은 기본 ManagedClusterSet 리소스에 추가되지 않습니다. 클러스터 풀에서 클러스터를 요청하면 기본 ManagedClusterSet 에 클러스터가 추가됩니다.

다중 클러스터 엔진 Operator를 설치하면 쉽게 관리할 수 있도록 허브 클러스터에 다음 리소스가 자동으로 생성됩니다.

  • global 이라는 ManagedClusterSet 입니다.
  • open-cluster-management-global-set 이라는 네임스페이스입니다.

  • 글로벌 ManagedClusterSet 을 open-cluster-management- global -set 네임스페이스에 바인딩하기 위해 global라는 ManagedClusterSetBinding 입니다.

    생성하는 관리형 클러스터는 기본적으로 글로벌 ManagedClusterSet 에 속합니다.

    중요: 글로벌 관리 클러스터 세트를 삭제, 업데이트 또는 편집할 수 없습니다. 글로벌 관리 클러스터 세트에는 모든 관리 클러스터가 포함됩니다. 다음 예제를 참조하십시오. 

    apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSetBinding
metadata:
  name: global
  namespace: open-cluster-management-global-set
spec:
  clusterSet: global
    Copy to Clipboard Toggle word wrap
1.7.14.1.1. CLI를 사용하여 ManagedClusterSet 생성
링크 복사

CLI를 사용하여 설정된 관리 클러스터의 다음 정의를 YAML 파일에 추가하여 관리 클러스터 세트를 생성합니다. 

apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSet
metadata:
  name: <cluster_set>
Copy to Clipboard Toggle word wrap

& lt;cluster_set >을 관리되는 클러스터 세트의 이름으로 바꿉니다.

1.7.14.1.2. ManagedClusterSet에 클러스터 추가
링크 복사

ManagedClusterSet 을 생성한 후 콘솔의 지침에 따라 또는 CLI를 사용하여 설정된 관리 클러스터에 클러스터를 추가할 수 있습니다.

1.7.14.1.3. CLI를 사용하여 ManagedClusterSet 에 클러스터 추가
링크 복사

CLI를 사용하여 설정된 관리 클러스터에 클러스터를 추가하려면 다음 단계를 완료합니다.

  1. managedclustersets/join 의 가상 하위 리소스에서 생성할 수 있는 RBAC ClusterRole 항목이 있는지 확인합니다.

    참고: 이 권한이 없으면 ManagedClusterSet 에 관리 클러스터를 할당할 수 없습니다. 이 항목이 없는 경우 YAML 파일에 추가합니다. 다음 예제를 참조하십시오. 

    kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: clusterrole1
rules:
  - apiGroups: ["cluster.open-cluster-management.io"]
    resources: ["managedclustersets/join"]
    resourceNames: ["<cluster_set>"]
    verbs: ["create"]
    Copy to Clipboard Toggle word wrap

    & lt;cluster_set& gt;을 ManagedClusterSet 의 이름으로 바꿉니다.

    참고: ManagedClusterSet 에서 다른 클러스터로 관리되는 클러스터를 이동하는 경우 두 관리 클러스터 세트 모두에서 사용 가능한 권한이 있어야 합니다.

  2. YAML 파일에서 관리 클러스터의 정의를 찾습니다. 다음 예제 정의를 참조하십시오. 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: <cluster_name>
spec:
  hubAcceptsClient: true
    Copy to Clipboard Toggle word wrap

  3. cluster.open-cluster-management.io/clusterset paremeter를 추가하고 ManagedClusterSet 의 이름을 지정합니다. 다음 예제를 참조하십시오. 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: <cluster_name>
  labels:
    cluster.open-cluster-management.io/clusterset: <cluster_set>
spec:
  hubAcceptsClient: true
    Copy to Clipboard Toggle word wrap
1.7.14.2. ManagedClusterSet에 RBAC 권한 할당
링크 복사

허브 클러스터에서 구성된 ID 공급자가 제공하는 클러스터 세트에 사용자 또는 그룹을 할당할 수 있습니다.

필수 액세스: 클러스터 관리자

ManagedClusterSet API RBAC 권한 수준은 다음 표를 참조하십시오.

Expand
클러스터 세트액세스 권한권한 생성

admin

관리 클러스터 세트에 할당된 모든 클러스터 및 클러스터 풀 리소스에 대한 전체 액세스 권한.

클러스터 생성, 클러스터 가져오기 및 클러스터 풀을 생성할 수 있는 권한 권한을 생성할 때 관리 클러스터 세트에 할당해야 합니다.

bind

ManagedClusterSetBinding 을 생성하여 네임스페이스로 설정된 클러스터를 바인딩할 수 있는 권한입니다. 사용자 또는 그룹에 대상 네임스페이스에서 ManagedClusterSetBinding 을 생성할 수 있는 권한도 있어야 합니다. 관리 클러스터 세트에 할당된 모든 클러스터 및 클러스터 풀 리소스에 대한 권한만 읽습니다.

클러스터 생성, 클러스터 가져오기 또는 클러스터 풀을 생성할 수 있는 권한이 없습니다.

view

관리 클러스터 세트에 할당된 모든 클러스터 및 클러스터 풀 리소스에 대한 권한만 읽습니다.

클러스터 생성, 클러스터 가져오기 또는 클러스터 풀을 생성할 수 있는 권한이 없습니다.

참고: 글로벌 클러스터 세트에 대한 클러스터 세트 관리자 권한을 적용할 수 없습니다.

콘솔에서 관리 클러스터 세트에 사용자 또는 그룹을 할당하려면 다음 단계를 완료합니다.

  1. OpenShift Container Platform 콘솔에서 Infrastructure > Clusters 로 이동합니다.
  2. Cluster sets 탭을 선택합니다.
  3. 대상 클러스터 세트를 선택합니다.
  4. 액세스 관리 탭을 선택합니다.
  5. 사용자 또는 그룹 추가를 선택합니다.
  6. 액세스를 제공할 사용자 또는 그룹을 검색하고 선택합니다.
  7. 선택한 사용자 또는 사용자 그룹에 제공할 Cluster set admin 또는 Cluster set view 역할을 선택합니다. 자세한 내용은 다중 클러스터 엔진 Operator 역할 기반 액세스 제어 의 역할 개요 를 참조하십시오.
  8. 추가 를 선택하여 변경 사항을 제출합니다.

사용자 또는 그룹이 테이블에 표시됩니다. 모든 관리 클러스터 세트 리소스에 대한 권한 할당을 사용자 또는 그룹으로 전파하는 데 몇 초가 걸릴 수 있습니다.

배치 정보는 ManagedCusterSets 에서 ManagedCluster필터링 을 참조하십시오.

1.7.14.3. ManagedClusterSetBinding 리소스 생성
링크 복사

ManagedClusterSetBinding 리소스는 ManagedClusterSet 리소스를 네임스페이스에 바인딩합니다. 동일한 네임스페이스에서 생성된 애플리케이션 및 정책은 바인딩된 관리 클러스터 세트 리소스에 포함된 클러스터에만 액세스할 수 있습니다.

네임스페이스에 대한 액세스 권한은 해당 네임스페이스에 바인딩된 관리형 클러스터 세트에 자동으로 적용됩니다. 해당 네임스페이스에 대한 액세스 권한이 있는 경우 해당 네임스페이스에 바인딩된 모든 관리 클러스터 세트에 액세스할 수 있는 권한이 자동으로 부여됩니다. 관리 클러스터 세트에 액세스할 수 있는 권한만 있는 경우 네임스페이스의 다른 관리 클러스터 세트에 액세스할 수 있는 권한이 자동으로 없습니다.

콘솔 또는 명령줄을 사용하여 관리 클러스터 세트 바인딩을 생성할 수 있습니다.

1.7.14.3.1. 콘솔을 사용하여 ManagedClusterSetBinding 생성
링크 복사

콘솔을 사용하여 ManagedClusterSetBinding 을 생성하려면 다음 단계를 완료합니다.

  1. OpenShift Container Platform 콘솔에서 Infrastructure > Clusters 로 이동하여 Cluster set 탭을 선택합니다.
  2. 바인딩을 생성할 클러스터 세트의 이름을 선택합니다.
  3. 작업 > 네임스페이스 바인딩 편집 으로 이동합니다.
  4. 네임스페이스 바인딩 편집 페이지의 드롭다운 메뉴에서 클러스터 세트를 바인딩할 네임스페이스를 선택합니다.
1.7.14.3.2. CLI를 사용하여 ManagedClusterSetBinding 생성
링크 복사

CLI를 사용하여 ManagedClusterSetBinding 을 생성하려면 다음 단계를 완료합니다.

  1. YAML 파일에 ManagedClusterSetBinding 리소스를 생성합니다.

    참고: 관리형 클러스터 세트 바인딩을 생성할 때 관리 클러스터 세트 바인딩의 이름은 바인딩할 관리 클러스터 세트의 이름과 일치해야 합니다. ManagedClusterSetBinding 리소스는 다음 정보와 유사할 수 있습니다. 

    apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSetBinding
metadata:
  namespace: <namespace>
  name: <cluster_set>
spec:
  clusterSet: <cluster_set>
    Copy to Clipboard Toggle word wrap

  2. 대상 관리 클러스터 세트에 대한 바인딩 권한이 있는지 확인합니다. 사용자가 < cluster_set >에 바인딩할 수 있는 규칙이 포함된 ClusterRole 리소스의 다음 예제를 봅니다. 

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: <clusterrole>
rules:
  - apiGroups: ["cluster.open-cluster-management.io"]
    resources: ["managedclustersets/bind"]
    resourceNames: ["<cluster_set>"]
    verbs: ["create"]
    Copy to Clipboard Toggle word wrap
1.7.14.4. 테인트 및 톨러레이션을 사용하여 관리형 클러스터 배치
링크 복사

테인트 및 허용 오차를 사용하여 관리 클러스터 또는 관리형 클러스터 세트의 배치를 제어할 수 있습니다. 테인트 및 허용 오차는 관리 클러스터가 특정 배치에 대해 선택되지 않도록 하는 방법을 제공합니다. 이 제어는 특정 관리 클러스터가 일부 배치에 포함되지 않도록 하려는 경우 유용할 수 있습니다. 관리 클러스터에 테인트를 추가하고 배치에 허용 오차를 추가할 수 있습니다. 테인트 및 허용 오차가 일치하지 않으면 해당 배치에 대해 관리 클러스터가 선택되지 않습니다.

1.7.14.4.1. 관리 클러스터에 테인트 추가
링크 복사

테인트는 관리 클러스터의 속성에 지정되며, 배치에서 관리 클러스터 또는 관리 클러스터 세트를 거절할 수 있습니다.

taint 섹션이 없는 경우 다음 예와 유사한 명령을 실행하여 관리 클러스터에 테인트를 추가할 수 있습니다. 

oc patch managedcluster <managed_cluster_name> -p '{"spec":{"taints":[{"key": "key", "value": "value", "effect": "NoSelect"}]}}' --type=merge
Copy to Clipboard Toggle word wrap

또는 다음 예와 유사한 명령을 실행하여 기존 테인트에 테인트를 추가할 수 있습니다. 

oc patch managedcluster <managed_cluster_name> --type='json' -p='[{"op": "add", "path": "/spec/taints/-", "value": {"key": "key", "value": "value", "effect": "NoSelect"}}]'
Copy to Clipboard Toggle word wrap

테인트의 사양에는 다음 필드가 포함됩니다.

  • 필수 키 - 클러스터에 적용되는 taint 키입니다. 이 값은 해당 배치에 추가되는 기준을 충족하기 위해 관리 클러스터의 허용 오차 값과 일치해야 합니다. 이 값을 확인할 수 있습니다. 예를 들어 이 값은 bar 또는 foo.example.com/bar 일 수 있습니다.
  • 선택적 값 - taint 키의 taint 값입니다. 이 값은 해당 배치에 추가되는 기준을 충족하기 위해 관리 클러스터의 허용 오차 값과 일치해야 합니다. 예를 들어 이 값은 값이 될 수 있습니다.

  • 필수 효과 - 테인트를 허용하지 않는 배치에 대한 테인트의 효과 또는 테인트 및 배치 허용 오차가 일치하지 않을 때 발생하는 상황입니다. effect 값은 다음 값 중 하나여야 합니다.

    • NoSelect - 배치는 이 테인트를 허용하지 않는 한 클러스터를 선택할 수 없습니다. 테인트를 설정하기 전에 배치에서 클러스터를 선택한 경우 배치 결정에 따라 클러스터가 제거됩니다.
    • NoSelectIfNew - 스케줄러에서 새 클러스터인 경우 클러스터를 선택할 수 없습니다. 배치는 테인트를 허용하고 이미 클러스터 결정에 클러스터가 있는 경우에만 클러스터를 선택할 수 있습니다.
  • 필수 TimeAdded - 테인트가 추가된 시간입니다. 이 값은 자동으로 설정됩니다.

관리 클러스터에 액세스할 수 없는 경우 클러스터를 배치에 추가하지 않아도 됩니다. 다음 테인트는 액세스할 수 없는 관리형 클러스터에 자동으로 추가됩니다.

  • cluster.open-cluster-management.io/unavailable - 클러스터 상태가 False 인 ManagedClusterConditionAvailable 조건이 있는 경우 이 테인트가 관리 클러스터에 추가됩니다. 테인트에는 사용할 수 없는 클러스터가 예약되지 않도록 NoSelect 및 빈 값이 적용됩니다. 이 테인트의 예는 다음 콘텐츠에 제공됩니다. 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
 name: cluster1
spec:
 hubAcceptsClient: true
 taints:
   - effect: NoSelect
     key: cluster.open-cluster-management.io/unavailable
     timeAdded: '2022-02-21T08:11:54Z'
    Copy to Clipboard Toggle word wrap

  • cluster.open-cluster-management.io/unreachable - ManagedClusterConditionAvailable 조건 상태가 알 수 없거나 조건이 없는 경우 이 테인트가 관리 클러스터에 추가됩니다. 테인트는 연결할 수 없는 클러스터가 예약되지 않도록 NoSelect 및 빈 값이 적용됩니다. 이 테인트의 예는 다음 콘텐츠에 제공됩니다. 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: cluster.open-cluster-management.io/unreachable
      timeAdded: '2022-02-21T08:11:06Z'
    Copy to Clipboard Toggle word wrap
1.7.14.4.3. 배치에 허용 오차 추가
링크 복사

허용 오차는 배치에 적용되며 배치의 허용 오차와 일치하는 테인트가 없는 관리 클러스터를 복구할 수 있습니다. 허용 오차 사양에는 다음 필드가 포함됩니다.

  • 선택적 키 - 키가 taint 키와 일치하여 배치를 허용합니다.
  • 선택적 값 - 허용 오차의 값은 배치를 허용하기 위해 허용 오차의 값과 일치해야 합니다.

  • 선택적 Operator - Operator는 키와 값 간의 관계를 나타냅니다. 유효한 연산자 는 동일하며 존재합니다. 기본값은 동일합니다. 허용 오차는 키가 동일할 때 테인트와 일치하며 효과가 동일하며 Operator는 다음 값 중 하나입니다.

    • 동일한 - 연산자는 동일하고 테인트 및 톨러레이션에서 값이 동일합니다.
    • exists - 값은 와일드카드이므로 배치에서 특정 카테고리의 모든 테인트를 허용할 수 있습니다.
  • 선택적 Effect - 일치시킬 테인트 효과입니다. 비워 두면 모든 테인트 효과와 일치합니다. 지정된 경우 허용되는 값은 NoSelect 또는 NoSelectIfNew 입니다.
  • optional TolerationSeconds - 관리되는 클러스터를 새 배치로 이동하기 전에 허용 오차에서 테인트를 허용하는 시간(초)입니다. effect 값이 NoSelect 또는 PreferNoSelect 가 아닌 경우 이 필드는 무시됩니다. 기본값은 nil 이며, 이는 시간 제한이 없음을 나타냅니다. TolerationSeconds 계산 시작 시간은 클러스터 예약 시간 또는 TolerationSeconds 값이 추가되는 대신 테인트의 TimeAdded 값으로 자동으로 나열됩니다.

다음 예제에서는 테인트가 있는 클러스터를 허용하는 허용 오차를 구성하는 방법을 보여줍니다.

  • 이 예는 관리 클러스터의 테인트입니다. 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: gpu
      value: "true"
      timeAdded: '2022-02-21T08:11:06Z'
    Copy to Clipboard Toggle word wrap

  • 테인트를 허용할 수 있는 배치에 대한 허용 오차 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement1
  namespace: default
spec:
  tolerations:
    - key: gpu
      value: "true"
      operator: Equal
    Copy to Clipboard Toggle word wrap

    허용 오차 예제를 정의하면 key: gpu 및 value: "true" 가 일치하기 때문에 배치로 cluster1 을 선택할 수 있었습니다.

참고: 관리형 클러스터는 테인트에 대한 허용 오차가 포함된 배치에 배치되지 않습니다. 다른 배치에 동일한 허용 오차가 포함된 경우 관리 클러스터가 해당 배치 중 하나에 배치될 수 있습니다.

1.7.14.4.4. 임시 허용 오차 지정
링크 복사

TolerationSeconds 의 값은 허용 오차에서 테인트를 허용하는 기간을 지정합니다. 이 임시 허용 오차는 관리 클러스터가 오프라인 상태일 때 유용할 수 있으며 이 클러스터에 배포된 애플리케이션을 허용 시간 동안 다른 관리 클러스터로 전송할 수 있습니다.

예를 들어 다음 테인트가 있는 관리 클러스터에 연결할 수 없습니다. 

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: cluster.open-cluster-management.io/unreachable
      timeAdded: '2022-02-21T08:11:06Z'
Copy to Clipboard Toggle word wrap

다음 예제에서와 같이 TolerationSeconds 의 값으로 배치를 정의하는 경우 워크로드는 5분 후에 사용 가능한 다른 관리 클러스터로 전송합니다. 

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: demo4
  namespace: demo1
spec:
  tolerations:
    - key: cluster.open-cluster-management.io/unreachable
      operator: Exists
      tolerationSeconds: 300
Copy to Clipboard Toggle word wrap

관리형 클러스터에 5분 동안 연결할 수 없는 경우 애플리케이션이 다른 관리 클러스터로 이동됩니다.

1.7.14.4.5. 추가 리소스
링크 복사
  • oc patch를 사용하는 방법을 알아보려면 oc patch the OpenShift Container Platform 문서를 참조하십시오.
1.7.14.5. ManagedClusterSet에서 관리 클러스터 제거
링크 복사

관리 클러스터 세트에서 관리 클러스터를 제거하여 다른 관리 클러스터 세트로 이동하거나 세트의 관리 설정에서 제거할 수 있습니다. 콘솔 또는 CLI를 사용하여 설정된 관리 클러스터에서 관리 클러스터를 제거할 수 있습니다.

참고:

  • 모든 관리 클러스터는 관리 클러스터 세트에 할당되어야 합니다. ManagedClusterSet에서 관리 클러스터를 제거하고 다른 ManagedClusterSet 에 할당하지 않으면 클러스터가 기본 관리 클러스터 세트에 자동으로 추가됩니다.
  • 관리 클러스터에 Submariner 애드온이 설치된 경우 ManagedClusterSet 에서 관리 클러스터를 제거하기 전에 애드온을 제거해야 합니다.
1.7.14.5.1. 콘솔을 사용하여 ManagedClusterSet에서 클러스터 제거
링크 복사

콘솔을 사용하여 설정된 관리 클러스터에서 클러스터를 제거하려면 다음 단계를 완료합니다.

  1. Infrastructure > Clusters 를 클릭하고 Cluster sets 탭이 선택되어 있는지 확인합니다.
  2. 관리 클러스터 세트에서 제거할 클러스터 세트의 이름을 선택하여 클러스터 세트 세부 정보를 확인합니다.
  3. 작업 > 리소스 할당 관리를 선택합니다.

  4. 리소스 할당 관리 페이지에서 클러스터 세트에서 제거할 리소스의 확인란을 제거합니다.

    이 단계에서는 이미 클러스터 세트의 멤버인 리소스를 제거합니다. 관리 클러스터의 세부 정보를 확인하여 리소스가 이미 설정된 클러스터의 멤버인지 확인할 수 있습니다.

참고: 하나의 관리형 클러스터에서 다른 관리 클러스터로 관리되는 클러스터를 이동하는 경우 두 관리 클러스터 세트에 대해 필요한 RBAC 권한이 있어야 합니다.

1.7.14.5.2. CLI를 사용하여 ManagedClusterSet에서 클러스터 제거
링크 복사

명령줄을 사용하여 관리 클러스터 세트에서 클러스터를 제거하려면 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 관리 클러스터 세트의 관리 클러스터 목록을 표시합니다. 

    oc get managedclusters -l cluster.open-cluster-management.io/clusterset=<cluster_set>
    Copy to Clipboard Toggle word wrap

    cluster_set 을 관리 클러스터 세트의 이름으로 교체합니다.

  2. 제거할 클러스터의 항목을 찾습니다.

  3. 제거하려는 클러스터의 YAML 항목에서 레이블을 제거합니다. 라벨 예제를 보려면 다음 코드를 참조하십시오. 

    labels:
   cluster.open-cluster-management.io/clusterset: clusterset1
    Copy to Clipboard Toggle word wrap

참고: 한 클러스터에서 다른 클러스터로 관리되는 클러스터를 이동하는 경우 두 관리 클러스터 세트에 대해 필요한 RBAC 권한이 있어야 합니다.

1.7.15. 배치
링크 복사

배치 리소스는 배치 네임스페이스에 바인딩된 ManagedClusterSets 에서 ManagedCluster Sets 집합을 선택하는 규칙을 정의하는 네임스페이스 범위 리소스입니다.

필수 액세스: 클러스터 관리자, 클러스터 세트 관리자

배치 사용 방법에 대해 자세히 알아보려면 계속 읽으십시오.

1.7.15.1. 배치 개요
링크 복사

관리 클러스터의 배치 작동 방법에 대한 다음 정보를 참조하십시오.

  • Kubernetes 클러스터는 hub 클러스터에 클러스터 범위의 ManagedCluster 로 등록됩니다.
  • ManagedCluster는 클러스터 범위의 ManagedClusterSets 로 구성됩니다.
  • ManagedClusterSets 는 워크로드 네임스페이스에 바인딩됩니다.
  • 네임스페이스 범위의 배치는 잠재적인 ManagedClusters 의 작업 세트를 선택하는 ManagedClusterSet 의 일부를 지정합니다.
  • 배치는 labelSelector 및 claimSelector 를 사용하여 ManagedClusterSets 의 ManagedClusters 를 필터링합니다.
  • ManagedCluster의 배치는 테인트 및 허용 오차를 사용하여 제어할 수 있습니다.
  • 배치는 우선순위 별로 클러스터를 정렬하고 해당 그룹에서 상위 n 개의 클러스터를 선택합니다. numberOfClusters 에서 n 을 정의할 수 있습니다.
  • 배치는 삭제 중인 관리 클러스터를 선택하지 않습니다.

참고:

  • 해당 네임스페이스에서 ManagedClusterSet 을 생성하여 하나 이상의 ManagedClusterSet을 네임스페이스에 바인딩 해야 합니다.
  • managedclustersets/bind 의 가상 하위 리소스에서 CREATE 에 대한 역할 기반 액세스 권한이 있어야 합니다.
1.7.15.1.1. 추가 리소스
링크 복사
1.7.15.2. ManagedCluster 오브젝트로 필터링
링크 복사

labelSelector,claimSelector 또는 celSelector 필드를 사용하여 필터링할 ManagedCluster 오브젝트를 선택할 수 있습니다. 필터 사용 방법을 알아보려면 다음 예제를 참조하십시오.

  • 다음 예에서 labelSelector 필드는 vendor: OpenShift 레이블이 있는 클러스터와만 일치합니다. 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchLabels:
            vendor: OpenShift
    Copy to Clipboard Toggle word wrap

  • 다음 예에서 claimSelector 는 region.open-cluster-management.io 가 us-west-1 인 클러스터와 일치합니다. 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        claimSelector:
          matchExpressions:
            - key: region.open-cluster-management.io
              operator: In
              values:
                - us-west-1
    Copy to Clipboard Toggle word wrap

    • clusterSets 매개변수를 사용하여 특정 클러스터 세트의 ManagedClusters 를 필터링할 수도 있습니다. 다음 예에서 claimSelector 는 clusterset1 및 clusterset2 를 설정하는 클러스터와만 일치합니다. 

      apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  clusterSets:
    - clusterset1
    - clusterset2
  predicates:
    - requiredClusterSelector:
        claimSelector:
          matchExpressions:
            - key: region.open-cluster-management.io
              operator: In
              values:
                - us-west-1
      Copy to Clipboard Toggle word wrap
  • 다음 예제에서는 Common Expression Language에서 celSelector 필드를 사용하는 방법의 5가지 방법을 표시합니다. 하나 또는 여러 표현식을 사용하여 ManagedCluster 오브젝트를 필터링할 수 있습니다. 
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement1
  namespace: ns1
spec:
  numberOfClusters: 3
  clusterSets:
    - clusterset1
  predicates:
  - requiredClusterSelector:
      celSelector:
        celExpressions:
          - managedCluster.status.version.kubernetes == "v1.31.0"
1 

          - managedCluster.status.clusterClaims.exists(c, c.name == "kubeversion.open-cluster-management.io" && c.value == "v1.31.0")
2 

          - managedCluster.metadata.labels["version"].matches('^1\\.(30|31).d+$')
3 

          - semver(managedCluster.metadata.labels["version"]).isGreaterThan(semver("1.30.0"))
4 

          - managedCluster.scores("resource-usage-score").filter(s, s.name == 'memNodeAvailable').all(e, e.value > 0)
5
Copy to Clipboard Toggle word wrap
1
managedCluster.Status.version.kubernetes 필드에 나열된 Kubernetes 버전별 클러스터를 선택합니다.
2
clusterClaims 필드에 저장된 정보로 클러스터를 선택합니다.
3
managedCluster 필드에서 Common Expression Language 표준 매크로 및 표준 함수를 사용합니다.
4
Kubernetes semver 라이브러리 함수는 LessThan 이고 isGreaterThan 을 사용하여 버전 비교로 클러스터를 선택합니다.
5
사용자 지정 함수 점수를 사용하여 AddonPlacementScore 필드에 따라 클러스터를 선택합니다.

자세한 내용은 추가 리소스 섹션에서 Kubernetes의 Common Expression Language 를 참조하십시오.

numberOfClusters paremeter를 사용하여 필터링할 ManagedClusters 수를 선택할 수도 있습니다. 다음 예제를 참조하십시오. 

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  numberOfClusters: 3
1 

  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchLabels:
            vendor: OpenShift
        claimSelector:
          matchExpressions:
            - key: region.open-cluster-management.io
              operator: In
              values:
                - us-west-1
Copy to Clipboard Toggle word wrap
1
선택할 ManagedCluster 수를 지정합니다. 이전 예제는 3 으로 설정됩니다.
1.7.15.2.1. 배치로 허용 오차 를 정의하여 ManagedCluster 필터링
링크 복사

일치하는 테인트를 사용하여 ManagedCluster를 필터링하는 방법을 알아보려면 다음 예제를 참조하십시오.

  • 기본적으로 배치는 다음 예에서 cluster1 을 선택할 수 없습니다. 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: gpu
      value: "true"
      timeAdded: '2022-02-21T08:11:06Z'
    Copy to Clipboard Toggle word wrap

    cluster1 을 선택하려면 허용 오차를 정의해야 합니다. 다음 예제를 참조하십시오. 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  tolerations:
    - key: gpu
      value: "true"
      operator: Equal
    Copy to Clipboard Toggle word wrap

tolerationSeconds 매개변수를 사용하여 지정된 시간 동안 테인트가 일치하는 ManagedClusters 를 선택할 수도 있습니다. tolerationSeconds 는 허용 오차가 테인트에 바인딩된 기간을 정의합니다. tolerationSeconds 는 지정된 기간 후에 다른 관리 클러스터로 오프라인으로 이동하는 클러스터에 배포된 애플리케이션을 자동으로 전송할 수 있습니다.

다음 예제를 확인하여 tolerationSeconds 를 사용하는 방법을 알아봅니다.

  • 다음 예에서는 관리 클러스터에 연결할 수 없습니다. 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: cluster.open-cluster-management.io/unreachable
      timeAdded: '2022-02-21T08:11:06Z'
    Copy to Clipboard Toggle word wrap

    tolerationSeconds 를 사용하여 배치를 정의하면 워크로드가 사용 가능한 다른 관리 클러스터로 전송됩니다. 다음 예제를 참조하십시오. 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  tolerations:
    - key: cluster.open-cluster-management.io/unreachable
      operator: Exists
      tolerationSeconds: 300
    1
    Copy to Clipboard Toggle word wrap
    1
    워크로드를 전송할 시간(초)을 지정합니다.
1.7.15.2.2. 애드온 상태를 기반으로 ManagedCluster 필터링
링크 복사

배포된 애드온의 상태에 따라 배치의 관리 클러스터를 선택할 수 있습니다. 예를 들어 관리 클러스터에서 활성화된 특정 애드온이 있는 경우에만 배치에 대해 관리형 클러스터를 선택할 수 있습니다.

배치를 생성할 때 애드온 레이블과 해당 상태를 지정할 수 있습니다. 관리형 클러스터에서 추가 기능이 활성화된 경우 ManagedCluster 리소스에서 레이블이 자동으로 생성됩니다. 추가 기능이 비활성화되면 레이블이 자동으로 제거됩니다.

각 애드온은 feature.open-cluster-management.io/addon-<addon_name>=<status_of_addon > 형식의 레이블로 표시됩니다.

addon_name 을 선택한 관리 클러스터에서 활성화할 애드온의 이름으로 교체합니다.

status_of_addon 을 관리 클러스터를 선택하는 경우 애드온에 포함할 상태로 바꿉니다.

status_of_addon:에 대해 가능한 값의 다음 표를 참조하십시오.

Expand
현재의설명

사용 가능

애드온이 활성화되어 있고 사용할 수 있습니다.

비정상

애드온이 활성화되어 있지만 리스가 지속적으로 업데이트되지는 않습니다.

연결할 수 없음

애드온이 활성화되어 있지만 리스를 찾을 수 없습니다. 이는 관리 클러스터가 오프라인 상태일 때도 발생할 수 있습니다.

예를 들어 사용 가능한 application-manager 애드온은 다음을 읽는 관리 클러스터의 레이블로 표시됩니다. 

feature.open-cluster-management.io/addon-application-manager: available
Copy to Clipboard Toggle word wrap

애드온 및 해당 상태를 기반으로 배치를 생성하는 방법을 알아보려면 다음 예제를 참조하십시오.

  • 다음 배치 예제에는 application-manager 가 활성화된 모든 관리 클러스터가 포함됩니다. 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement1
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchExpressions:
            - key: feature.open-cluster-management.io/addon-application-manager
              operator: Exists
    Copy to Clipboard Toggle word wrap

  • 다음 배치 예제에서는 사용 가능한 상태로 application-manager 가 활성화된 모든 관리 클러스터를 포함합니다. 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement2
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchLabels:
            "feature.open-cluster-management.io/addon-application-manager": "available"
    Copy to Clipboard Toggle word wrap

  • 다음 배치 예제에는 application-manager 가 비활성화된 모든 관리 클러스터가 포함됩니다. 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement3
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchExpressions:
            - key: feature.open-cluster-management.io/addon-application-manager
              operator: DoesNotExist
    Copy to Clipboard Toggle word wrap

배치와 함께 prioritizerPolicy 매개변수를 사용하여 ManagedCluster의 우선 순위를 지정하는 방법을 알아보려면 다음 예제를 확인합니다.

  • 다음 예제에서는 가장 큰 할당 가능 메모리가 있는 클러스터를 선택합니다.

    참고: Kubernetes Node Allocatable, 'allocatable'은 각 클러스터의 Pod에 사용할 수 있는 컴퓨팅 리소스의 양으로 정의됩니다. 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  numberOfClusters: 1
  prioritizerPolicy:
    configurations:
      - scoreCoordinate:
          builtIn: ResourceAllocatableMemory
    Copy to Clipboard Toggle word wrap

  • 다음 예제에서는 가장 큰 할당 가능 CPU 및 메모리가 있는 클러스터를 선택하고 리소스 변경에 대한 배치를 수행합니다. 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  numberOfClusters: 1
  prioritizerPolicy:
    configurations:
      - scoreCoordinate:
          builtIn: ResourceAllocatableCPU
        weight: 2
      - scoreCoordinate:
          builtIn: ResourceAllocatableMemory
        weight: 2
    Copy to Clipboard Toggle word wrap

  • 다음 예제에서는 addOn 이 가장 큰 CPU 비율을 가진 두 클러스터를 선택하고 배치 결정을 고정합니다. 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  numberOfClusters: 2
  prioritizerPolicy:
    mode: Exact
    configurations:
      - scoreCoordinate:
          builtIn: Steady
        weight: 3
      - scoreCoordinate:
          type: AddOn
          addOn:
            resourceName: default
            scoreName: cpuratio
    Copy to Clipboard Toggle word wrap
1.7.15.2.4. 추가 리소스
링크 복사
1.7.15.3. PlacementDecision s 를 사용하여 선택한 ManagedCluster확인
링크 복사

클러스터에서 선택한 ManagedCluster 를 나타내기 위해 cluster.open-cluster-management.io/placement={placement_name} 레이블이 있는 하나 이상의 PlacementDecision 종류가 생성됩니다.

ManagedCluster 를 선택하고 PlacementDecision 에 추가하는 경우 이 배치를 사용하는 구성 요소가 이 ManagedCluster 에 워크로드를 적용할 수 있습니다.

ManagedCluster 를 선택하지 않고 PlacementDecision 에서 제거하면 이 ManagedCluster 에 적용되는 워크로드가 제거됩니다. 허용 오차를 정의하여 워크로드 제거를 방지할 수 있습니다.

허용 오차 정의에 대한 자세한 내용은 배치로 허용 오차를 정의하여 ManagedCluster 필터링 을 참조하십시오.

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

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: PlacementDecision
metadata:
  labels:
    cluster.open-cluster-management.io/placement: placement1
  name: placement1-kbc7q
  namespace: ns1
  ownerReferences:
    - apiVersion: cluster.open-cluster-management.io/v1beta1
      blockOwnerDeletion: true
      controller: true
      kind: Placement
      name: placement1
      uid: 05441cf6-2543-4ecc-8389-1079b42fe63e
status:
  decisions:
    - clusterName: cluster1
      reason: ''
    - clusterName: cluster2
      reason: ''
    - clusterName: cluster3
      reason: ''
Copy to Clipboard Toggle word wrap
1.7.15.3.1. 추가 리소스
링크 복사

1.7.16. 클러스터 풀 관리 (기술 프리뷰)
링크 복사

클러스터 풀은 온디맨드 및 대규모로 구성된 Red Hat OpenShift Container Platform 클러스터에 빠르고 비용 효율적으로 액세스할 수 있습니다. 클러스터 풀은 필요한 경우 요청할 수 있는 Amazon Web Services, Google Cloud Platform 또는 Microsoft Azure에 구성 가능하고 확장 가능한 수의 OpenShift Container Platform 클러스터를 프로비저닝합니다. 개발, 연속 통합 및 프로덕션 시나리오를 위해 클러스터 환경을 제공하거나 교체할 때 특히 유용합니다. 즉시 클레임할 수 있도록 계속 실행할 클러스터를 지정할 수 있으며 나머지 클러스터는 몇 분 내에 다시 시작하고 클레임할 수 있도록 하이버네이트 상태로 유지됩니다.

ClusterClaim 리소스는 클러스터 풀에서 클러스터를 확인하는 데 사용됩니다. 클러스터 클레임이 생성되면 풀에 실행 중인 클러스터를 할당합니다. 실행 중인 클러스터를 사용할 수 없는 경우 클러스터를 제공하기 위해 하이버네이트 클러스터가 다시 시작되거나 새 클러스터가 프로비저닝됩니다. 클러스터 풀은 자동으로 새 클러스터를 생성하고 하이버네이터레이션 클러스터를 재개하여 풀에서 사용 가능한 클러스터의 지정된 크기와 수를 유지합니다.

클러스터 풀을 생성하는 절차는 클러스터를 생성하는 절차와 유사합니다. 클러스터 풀의 클러스터는 즉시 사용할 수 있도록 생성되지 않습니다.

1.7.16.1. 클러스터 풀 생성
링크 복사

클러스터 풀을 생성하는 절차는 클러스터를 생성하는 절차와 유사합니다. 클러스터 풀의 클러스터는 즉시 사용할 수 있도록 생성되지 않습니다.

필요한 액세스: 관리자

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

클러스터 풀을 생성하기 전에 다음 사전 요구 사항을 참조하십시오.

  • 다중 클러스터 엔진 Operator 허브 클러스터를 배포해야 합니다.
  • 공급자 환경에서 Kubernetes 클러스터를 생성할 수 있도록 다중 클러스터 엔진 Operator 허브 클러스터에 대한 인터넷 액세스가 필요합니다.
  • AWS, GCP 또는 Microsoft Azure 공급자 인증 정보가 필요합니다. 자세한 내용은 인증 정보 관리 개요 를 참조하십시오.
  • 공급자 환경에 구성된 도메인이 필요합니다. 도메인 구성 방법에 대한 지침은 공급자 설명서를 참조하십시오.
  • 공급자 로그인 인증 정보가 필요합니다.
  • OpenShift Container Platform 이미지 풀 시크릿이 필요합니다. 이미지 풀 시크릿 사용을 참조하십시오.

참고: 이 절차를 사용하여 클러스터 풀을 추가하면 풀에서 클러스터를 요청할 때 다중 클러스터 엔진 Operator 관리용 클러스터를 자동으로 가져옵니다. 클러스터 클레임과 관리를 위해 클레임된 클러스터를 자동으로 가져오지 않는 클러스터 풀을 생성하려면 clusterClaim 리소스에 다음 주석을 추가합니다. 

kind: ClusterClaim
metadata:
  annotations:
    cluster.open-cluster-management.io/createmanagedcluster: "false"
1
Copy to Clipboard Toggle word wrap
1
"false" 라는 단어가 문자열임을 나타내기 위해 따옴표로 묶어야 합니다.
1.7.16.1.2. 클러스터 풀을 생성합니다.
링크 복사

클러스터 풀을 생성하려면 탐색 메뉴에서 Infrastructure > Clusters 를 선택합니다. 클러스터 풀 탭에는 액세스할 수 있는 클러스터 풀이 나열됩니다. 클러스터 풀 생성 을 선택하고 콘솔의 단계를 완료합니다.

클러스터 풀에 사용할 인프라 인증 정보가 없는 경우 인증 정보 추가 를 선택하여 생성할 수 있습니다.

목록에서 기존 네임스페이스를 선택하거나 새로 생성할 새 네임스페이스를 입력할 수 있습니다. 클러스터 풀이 클러스터와 동일한 네임스페이스에 있을 필요는 없습니다.

클러스터 풀의 RBAC 역할이 기존 클러스터 세트의 역할 할당을 공유하도록 하려면 클러스터 세트 이름을 선택할 수 있습니다. 클러스터 풀의 클러스터 세트는 클러스터 풀을 생성할 때만 설정할 수 있습니다. 클러스터 풀을 생성한 후에는 클러스터 풀 또는 클러스터 풀의 클러스터에 대한 클러스터 세트 연결을 변경할 수 없습니다. 클러스터 풀에서 요청하는 클러스터는 클러스터 풀과 동일한 클러스터 세트에 자동으로 추가됩니다.

참고: 클러스터 관리자 권한이 없는 경우 클러스터 세트를 선택해야 합니다. 이 경우 클러스터 세트 생성 요청은 클러스터 세트 이름을 포함하지 않는 경우 금지 오류와 함께 거부됩니다. 선택할 수 있는 클러스터 세트가 없는 경우 클러스터 관리자에게 문의하여 클러스터 세트를 생성하고 clusterset 관리자 권한을 부여합니다.

클러스터 풀 크기는 클러스터 풀에서 프로비저닝할 클러스터 수를 지정하는 반면, 클러스터 풀 실행 수는 풀이 계속 실행 중인 클러스터 수를 지정하고 즉시 사용할 준비가 된 클러스터 수를 지정합니다.

절차는 클러스터를 생성하는 절차와 매우 유사합니다.

공급자에 필요한 정보에 대한 자세한 내용은 다음 정보를 참조하십시오.

1.7.16.2. 클러스터 풀에서 클러스터 클레임
링크 복사

ClusterClaim 리소스는 클러스터 풀에서 클러스터를 확인하는 데 사용됩니다. 클러스터가 실행되고 클러스터 풀에서 준비되면 클레임이 완료됩니다. 클러스터 풀은 클러스터 풀에 지정된 요구 사항을 유지하기 위해 클러스터 풀에 실행 중인 새 및 hibernated 클러스터를 자동으로 생성합니다.

참고: 클러스터 풀에서 클레임된 클러스터가 더 이상 필요하지 않고 삭제되면 리소스가 삭제됩니다. 클러스터가 클러스터 풀로 반환되지 않습니다.

필요한 액세스: 관리자

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

사용 가능한 클러스터가 있거나 없는 클러스터 풀이 있어야 합니다. 클러스터 풀에 사용 가능한 클러스터가 있는 경우 사용 가능한 클러스터가 클레임됩니다. 클러스터 풀에 사용 가능한 클러스터가 없으면 클레임을 충족하기 위해 클러스터가 생성됩니다. 클러스터 풀을 생성하는 방법에 대한 자세한 내용은 클러스터 풀 생성 을 참조하십시오.

1.7.16.2.2. 클러스터 풀에서 클러스터 클레임
링크 복사

클러스터 클레임을 생성할 때 클러스터 풀에서 새 클러스터를 요청합니다. 클러스터를 사용할 수 있을 때 풀에서 클러스터를 확인합니다. 자동 가져오기를 비활성화하지 않는 한 클레임된 클러스터는 관리 클러스터 중 하나로 자동으로 가져옵니다.

클러스터를 클레임하려면 다음 단계를 완료합니다.

  1. 탐색 메뉴에서 Infrastructure > Clusters 를 클릭하고 Cluster pools 탭을 선택합니다.
  2. 클러스터에서 요청할 클러스터 풀의 이름을 찾아 Claim 클러스터 를 선택합니다.

클러스터를 사용할 수 있는 경우 클레임되고 Managed 클러스터 탭에 즉시 표시됩니다. 사용 가능한 클러스터가 없는 경우 hibernated 클러스터를 다시 시작하거나 새 클러스터를 프로비저닝하는 데 몇 분이 걸릴 수 있습니다. 이 시간 동안 클레임 상태가 보류 중입니다. 클러스터 풀을 확장하여 보류 중인 클레임을 보거나 삭제합니다.

클레임된 클러스터는 클러스터 풀에 있는 시점과 연결된 클러스터 세트의 멤버로 유지됩니다. 클레임할 때 클레임된 클러스터의 클러스터 세트를 변경할 수 없습니다.

참고: 클라우드 공급자 인증 정보의 풀 시크릿, SSH 키 또는 기본 도메인에 대한 변경 사항은 원래 인증 정보를 사용하여 이미 프로비저닝되었으므로 클러스터 풀에서 클레임한 기존 클러스터에는 반영되지 않습니다. 콘솔을 사용하여 클러스터 풀 정보를 편집할 수 없지만 CLI 인터페이스를 사용하여 정보를 업데이트하여 업데이트할 수 있습니다. 업데이트된 정보가 포함된 인증 정보를 사용하여 새 클러스터 풀을 생성할 수도 있습니다. 새 풀에서 생성된 클러스터는 새 인증 정보에 제공된 설정을 사용합니다.

1.7.16.3. 클러스터 풀 릴리스 이미지 업데이트
링크 복사

클러스터 풀의 클러스터가 잠시 중단된 상태로 유지되는 경우 클러스터의 Red Hat OpenShift Container Platform 릴리스 이미지가 백 수준이 될 수 있습니다. 이 경우 클러스터 풀에 있는 클러스터의 릴리스 이미지 버전을 업그레이드할 수 있습니다.

필요한 액세스: 편집

클러스터 풀의 클러스터의 OpenShift Container Platform 릴리스 이미지를 업데이트하려면 다음 단계를 완료합니다.

참고: 이 절차에서는 클러스터 풀에 이미 클레임된 클러스터 풀에서 클러스터를 업데이트하지 않습니다. 이 절차를 완료한 후 릴리스 이미지에 대한 업데이트는 클러스터 풀과 관련된 다음 클러스터에만 적용됩니다.

  • 이 절차를 사용하여 릴리스 이미지를 업데이트한 후 클러스터 풀에서 생성한 클러스터입니다.
  • 클러스터 풀에서 하이버팅되는 클러스터입니다. 이전 릴리스 이미지가 있는 기존의 중단된 클러스터가 제거되고 새 릴리스 이미지가 있는 새 클러스터가 해당 클러스터를 대체합니다.
  1. 탐색 메뉴에서 인프라 > 클러스터를 클릭합니다.
  2. Cluster Pool 탭을 선택합니다.
  3. Cluster Pool 표에서 업데이트할 클러스터 풀의 이름을 찾습니다.
  4. 표에서 클러스터 풀 의 옵션 메뉴를 클릭하고 릴리스 이미지 업데이트를 선택합니다.
  5. 이 클러스터 풀에서 향후 클러스터 생성에 사용할 새 릴리스 이미지를 선택합니다.

클러스터 풀 릴리스 이미지가 업데이트되었습니다.

팁: 각 클러스터 풀의 상자를 선택하고 Actions 메뉴를 사용하여 선택한 클러스터 풀의 릴리스 이미지를 업데이트하여 여러 클러스터 풀의 릴리스 이미지를 업데이트할 수 있습니다.

1.7.16.4. 클러스터 풀 스케일링 (기술 프리뷰)
링크 복사

클러스터 풀 크기의 클러스터 수를 늘리거나 줄여 클러스터 풀의 클러스터 수를 변경할 수 있습니다.

필수 액세스: 클러스터 관리자

클러스터 풀의 클러스터 수를 변경하려면 다음 단계를 완료합니다.

  1. 탐색 메뉴에서 인프라 > 클러스터를 클릭합니다.
  2. Cluster Pool 탭을 선택합니다.
  3. 변경할 클러스터 풀의 옵션 메뉴에서 클러스터 풀 스케일링을 선택합니다.
  4. 풀 크기 값을 변경합니다.
  5. 선택적으로 실행 중인 클러스터 수를 업데이트하여 요청 시 즉시 사용 가능한 클러스터 수를 늘리거나 줄일 수 있습니다.

클러스터 풀은 새 값을 반영하도록 확장됩니다.

1.7.16.5. 클러스터 풀 삭제
링크 복사

클러스터 풀을 생성하고 더 이상 필요하지 않은 경우 클러스터 풀을 제거할 수 있습니다.

중요: 클러스터 클레임이 없는 클러스터 풀만 제거할 수 있습니다.

필수 액세스: 클러스터 관리자

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

  1. 탐색 메뉴에서 인프라 > 클러스터를 클릭합니다.
  2. Cluster Pool 탭을 선택합니다.

  3. 삭제할 클러스터 풀의 옵션 메뉴에서 확인 상자에 confirm 를 입력하고 Destroy 를 선택합니다.

    참고:

    • 클러스터 풀에 클러스터 클레임이 있는 경우 Destroy 버튼이 비활성화됩니다.
    • 클러스터 풀이 포함된 네임스페이스는 삭제되지 않습니다. 이러한 클러스터의 클러스터 클레임 리소스가 동일한 네임스페이스에 생성되므로 네임스페이스를 삭제하면 클러스터 풀에서 클레임된 클러스터가 제거됩니다.

팁: 각 클러스터 풀의 상자를 선택하고 Actions 메뉴를 사용하여 선택한 클러스터 풀을 제거하여 한 가지 작업으로 여러 클러스터 풀을 제거할 수 있습니다.

1.7.17. ManagedServiceAccount 애드온 활성화
링크 복사

지원되는 다중 클러스터 엔진 Operator 버전을 설치하면 ManagedServiceAccount 애드온이 기본적으로 활성화됩니다.

ManagedServiceAccount 를 사용하면 관리 클러스터에서 서비스 계정을 생성하거나 삭제할 수 있습니다.

필요한 액세스: 편집기

hub 클러스터의 < managed_cluster > 네임스페이스에 ManagedServiceAccount 사용자 정의 리소스가 생성되면 관리 클러스터에 ServiceAccount 가 생성됩니다.

TokenRequest 는 관리형 클러스터의 Kubernetes API 서버에 대한 ServiceAccount 를 사용하여 수행됩니다. 그런 다음 토큰은 hub 클러스터의 < target_managed_cluster> 네임스페이스의 Secret 에 저장됩니다.

참고: 토큰이 만료되고 순환될 수 있습니다. 토큰 요청에 대한 자세한 내용은 TokenRequest 를 참조하십시오.

1.7.17.1. 사전 요구 사항
링크 복사
  • 지원되는 Red Hat OpenShift Container Platform 환경이 필요합니다.
  • 다중 클러스터 엔진 Operator가 설치되어 있어야 합니다.
1.7.17.2. ManagedServiceAccount 활성화
링크 복사

허브 클러스터 및 관리 클러스터에 대한 ManagedServiceAccount 애드온을 활성화하려면 다음 단계를 완료하십시오.

  1. 허브 클러스터에서 ManagedServiceAccount 애드온을 활성화합니다. 자세한 내용은 고급 구성 을 참조하십시오.

  2. ManagedServiceAccount 애드온을 배포하고 대상 관리 클러스터에 적용합니다. 다음 YAML 파일을 생성하고 target_managed_cluster 를 Managed-ServiceAccount 애드온을 적용하는 관리 클러스터의 이름으로 바꿉니다. 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: ManagedClusterAddOn
metadata:
  name: managed-serviceaccount
  namespace: <target_managed_cluster>
spec:
  installNamespace: open-cluster-management-agent-addon
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 파일을 적용합니다. 

    oc apply -f -
    Copy to Clipboard Toggle word wrap

    이제 관리 클러스터에 대해 ManagedServiceAccount 플러그인을 활성화했습니다. ManagedServiceAccount 를 구성하려면 다음 단계를 참조하십시오.

  4. 다음 YAML 소스를 사용하여 ManagedServiceAccount 사용자 정의 리소스를 생성합니다. 

    apiVersion: authentication.open-cluster-management.io/v1alpha1
kind: ManagedServiceAccount
metadata:
  name: <managedserviceaccount_name>
  namespace: <target_managed_cluster>
spec:
  rotation: {}
    Copy to Clipboard Toggle word wrap
    • managed_serviceaccount_name 을 ManagedServiceAccount 의 이름으로 교체합니다.
    • target_managed_cluster 를 ManagedServiceAccount 를 적용하는 관리 클러스터의 이름으로 교체합니다.

  5. 확인하려면 ManagedServiceAccount 오브젝트 상태에서 tokenSecretRef 속성을 확인하여 시크릿 이름과 네임스페이스를 찾습니다. 계정 및 클러스터 이름을 사용하여 다음 명령을 실행합니다. 

    oc get managedserviceaccount <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml
    Copy to Clipboard Toggle word wrap

  6. 관리 클러스터에서 생성된 ServiceAccount 에 연결된 검색된 토큰이 포함된 보안을 확인합니다. 다음 명령을 실행합니다. 

    oc get secret <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml
    Copy to Clipboard Toggle word wrap

1.7.18. 클러스터 라이프사이클 고급 구성
링크 복사

설치 중 또는 설치 후 일부 클러스터 설정을 구성할 수 있습니다.

1.7.18.1. API 서버 인증서 사용자 정의
링크 복사

관리형 클러스터는 OpenShift Kube API 서버 외부 로드 밸런서와의 상호 연결을 통해 hub 클러스터와 통신합니다. OpenShift Container Platform을 설치할 때 기본 OpenShift Kube API 서버 인증서는 내부 Red Hat OpenShift Container Platform 클러스터 인증 기관(CA)에서 발급합니다. 필요한 경우 인증서를 추가하거나 변경할 수 있습니다.

API 서버 인증서를 변경하면 관리 클러스터와 허브 클러스터 간의 통신에 영향을 미칠 수 있습니다. 제품을 설치하기 전에 이름이 지정된 인증서를 추가하면 관리 클러스터를 오프라인 상태로 둘 수 있는 문제를 방지할 수 있습니다.

다음 목록에는 인증서를 업데이트해야 하는 몇 가지 예가 포함되어 있습니다.

  • 외부 로드 밸런서의 기본 API 서버 인증서를 자체 인증서로 교체하려고 합니다. OpenShift Container Platform 설명서에서 API 서버 인증서 추가 의 지침에 따라 호스트 이름 api.<cluster_name>.<base_domain >이 포함된 이름이 지정된 인증서를 추가하여 외부 로드 밸런서의 기본 API 서버 인증서를 교체할 수 있습니다. 인증서를 교체하면 관리 클러스터 중 일부가 오프라인 상태로 이동할 수 있습니다. 인증서를 업그레이드한 후 클러스터가 오프라인 상태인 경우 인증서 변경 후 가져온 클러스터 문제 해결 지침에 따라 문제를 해결합니다.

    참고: 제품을 설치하기 전에 이름이 지정된 인증서를 추가하면 클러스터가 오프라인 상태로 전환되지 않습니다.

  • 외부 로드 밸런서에 대해 이름이 지정된 인증서가 만료되어 이를 교체해야 합니다. 이전 인증서와 새 인증서가 중간 인증서 수에도 불구하고 동일한 루트 CA 인증서를 공유하는 경우 OpenShift Container Platform 설명서의 API 서버 인증서 추가 지침에 따라 새 인증서에 대한 새 시크릿을 생성할 수 있습니다. 그런 다음 호스트 이름 api.<cluster_name>.<base_domain >에 대한 제공 인증서 참조를 APIServer 사용자 정의 리소스의 새 시크릿으로 업데이트합니다. 그렇지 않으면 이전 및 새 인증서에 다른 루트 CA 인증서가 있는 경우 다음 단계를 완료하여 인증서를 교체합니다.

    1. 다음 예와 유사한 APIServer 사용자 정의 리소스를 찾습니다. 

      apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  audit:
    profile: Default
  servingCerts:
    namedCertificates:
    - names:
      - api.mycluster.example.com
      servingCertificate:
        name: old-cert-secret
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 기존 및 새 인증서의 콘텐츠가 포함된 openshift-config 네임스페이스에 새 보안을 생성합니다.

      1. 이전 인증서를 새 인증서로 복사합니다. 

        cp old.crt combined.crt
        Copy to Clipboard Toggle word wrap

      2. 새 인증서의 내용을 이전 인증서의 사본에 추가합니다. 

        cat new.crt >> combined.crt
        Copy to Clipboard Toggle word wrap

      3. 결합된 인증서를 적용하여 보안을 생성합니다. 

        oc create secret tls combined-certs-secret --cert=combined.crt --key=old.key -n openshift-config
        Copy to Clipboard Toggle word wrap

    3. APIServer 리소스를 업데이트하여 servingCertificate 로 결합된 인증서를 참조합니다. 

      apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  audit:
    profile: Default
  servingCerts:
    namedCertificates:
    - names:
      - api.mycluster.example.com
      servingCertificate:
        name: combined-cert-secret
      Copy to Clipboard Toggle word wrap
    4. 약 15분 후에 새 인증서와 이전 인증서가 모두 포함된 CA 번들이 관리형 클러스터로 전파됩니다.

    5. 다음 명령을 입력하여 새 인증서 정보만 포함된 openshift-config 네임스페이스에 new-cert-secret 이라는 다른 보안을 생성합니다. 

      oc create secret tls new-cert-secret --cert=new.crt --key=new.key -n openshift-config {code}
      Copy to Clipboard Toggle word wrap

    6. new-cert-secret 을 참조하도록 servingCertificate 의 이름을 변경하여 APIServer 리소스를 업데이트합니다. 리소스는 다음 예와 유사할 수 있습니다. 

      apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  audit:
    profile: Default
  servingCerts:
    namedCertificates:
    - names:
      - api.mycluster.example.com
      servingCertificate:
        name: new-cert-secret
      Copy to Clipboard Toggle word wrap

      약 15분 후에 이전 인증서가 CA 번들에서 제거되고 변경 사항이 관리 클러스터에 자동으로 전파됩니다.

참고: 관리 클러스터는 호스트 이름 api.<cluster_name>.<base_domain >을 사용하여 hub 클러스터에 액세스해야 합니다. 다른 호스트 이름으로 구성된 이름이 지정된 인증서를 사용할 수 없습니다.

1.7.18.2. 허브 클러스터와 관리 클러스터 간의 프록시 구성
링크 복사

Kubernetes Operator 허브 클러스터의 다중 클러스터 엔진에 관리 클러스터를 등록하려면 관리 클러스터를 다중 클러스터 엔진 Operator 허브 클러스터로 전송해야 합니다. 관리되는 클러스터가 다중 클러스터 엔진 Operator 허브 클러스터에 직접 연결할 수 없는 경우가 있습니다. 이 경우 관리 클러스터의 통신이 HTTP 또는 HTTPS 프록시 서버를 통해 다중 클러스터 엔진 Operator 허브 클러스터에 액세스할 수 있도록 프록시 설정을 구성합니다.

예를 들어 다중 클러스터 엔진 Operator 허브 클러스터는 퍼블릭 클라우드에 있으며 관리 클러스터는 방화벽 뒤의 프라이빗 클라우드 환경에 있습니다. 프라이빗 클라우드에서의 통신은 HTTP 또는 HTTPS 프록시 서버를 통해서만 진행할 수 있습니다.

1.7.18.2.1. 사전 요구 사항
링크 복사
  • HTTP 터널을 지원하는 HTTP 또는 HTTPS 프록시 서버가 실행되고 있습니다. 예를 들어 HTTP 연결 방법입니다.
  • HTTP 또는 HTTPS 프록시 서버에 연결할 수 있는 조작된 클러스터가 있으며 프록시 서버는 다중 클러스터 엔진 operator hub 클러스터에 액세스할 수 있습니다.

hub 클러스터와 관리 클러스터 간의 프록시 설정을 구성하려면 다음 단계를 완료합니다.

  1. 프록시 설정을 사용하여 KlusterConfig 리소스를 생성합니다.

    1. HTTP 프록시를 사용하여 다음 구성을 참조하십시오. 

      apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: http-proxy
spec:
  hubKubeAPIServerConfig:
    proxyURL: "http://<username>:<password>@<ip>:<port>"
      Copy to Clipboard Toggle word wrap

    2. HTTPS 프록시를 사용하여 다음 구성을 참조하십시오. 

      apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: https-proxy
spec:
  hubKubeAPIServerConfig:
    proxyURL: "https://<username>:<password>@<ip>:<port>"
    trustedCABundles:
    - name: "proxy-ca-bundle"
      caBundle:
        name: <configmap-name>
        namespace: <configmap-namespace>
      Copy to Clipboard Toggle word wrap

      참고: HTTPS 프록시에는 CA 번들이 필요합니다. 하나 이상의 CA 인증서가 포함된 ConfigMap을 나타냅니다. 다음 명령을 실행하여 ConfigMap을 생성할 수 있습니다. 

      oc create -n <configmap-namespace> configmap <configmap-name> --from-file=ca.crt=/path/to/ca/file
      Copy to Clipboard Toggle word wrap

  2. 관리 클러스터를 생성할 때 KlusterletConfig 리소스를 참조하는 주석을 추가하여 KlusterletConfig 리소스를 선택합니다. 다음 예제를 참조하십시오. 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    agent.open-cluster-management.io/klusterlet-config: <klusterlet-config-name>
  name:<managed-cluster-name>
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60
    Copy to Clipboard Toggle word wrap

    참고:

    • 다중 클러스터 엔진 Operator 콘솔에서 작업할 때 ManagedCluster 리소스에 주석을 추가하도록 YAML 보기를 전환해야 할 수 있습니다.
    • 글로벌 KlusterletConfig 를 사용하여 바인딩에 주석을 사용하지 않고도 모든 관리 클러스터에서 구성을 활성화할 수 있습니다.
1.7.18.2.2. 허브 클러스터와 관리 클러스터 간의 프록시 비활성화
링크 복사

개발이 변경되면 HTTP 또는 HTTPS 프록시를 비활성화해야 할 수 있습니다.

  1. ManagedCluster 리소스로 이동합니다.
  2. agent.open-cluster-management.io/klusterlet-config 주석을 제거합니다.
1.7.18.2.3. 선택 사항: 특정 노드에서 실행되도록 klusterlet 구성
링크 복사

Red Hat Advanced Cluster Management for Kubernetes를 사용하여 클러스터를 생성할 때 관리 클러스터에 대한 nodeSelector 및 허용 오차 주석을 구성하여 관리 대상 클러스터 klusterlet을 실행할 노드를 지정할 수 있습니다. 다음 설정을 구성하려면 다음 단계를 완료합니다.

  1. 콘솔의 클러스터 페이지에서 업데이트할 관리 클러스터를 선택합니다.

  2. YAML 스위치를 On 으로 설정하여 YAML 콘텐츠를 확인합니다.

    참고: YAML 편집기는 클러스터를 가져오거나 생성하는 경우에만 사용할 수 있습니다. 가져오기 또는 생성 후 관리형 클러스터 YAML 정의를 편집하려면 OpenShift Container Platform 명령줄 인터페이스 또는 Red Hat Advanced Cluster Management 검색 기능을 사용해야 합니다.

  3. 관리 클러스터 YAML 정의에 nodeSelector 주석을 추가합니다. 이 주석의 키는 open-cluster-management/nodeSelector 입니다. 이 주석의 값은 JSON 형식의 문자열 맵입니다.

  4. 관리 클러스터 YAML 정의에 허용 오차 항목을 추가합니다. 이 주석의 키는 open-cluster-management/tolerations 입니다. 이 주석의 값은 JSON 형식의 허용 오차 목록을 나타냅니다. 결과 YAML은 다음 예와 유사할 수 있습니다. 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    open-cluster-management/nodeSelector: '{"dedicated":"acm"}'
    open-cluster-management/tolerations: '[{"key":"dedicated","operator":"Equal","value":"acm","effect":"NoSchedule"}]'
    Copy to Clipboard Toggle word wrap
  5. 올바른 노드에 콘텐츠를 배포할 수 있도록 하려면 klusterlet 애드온 구성을 참조하십시오.

관리 클러스터와 허브 클러스터 사이에 중간 구성 요소가 있는 경우 다중 클러스터 엔진 Operator 허브 클러스터에 관리 클러스터를 등록하지 못할 수 있습니다. 중간 구성 요소의 예로는 가상 IP, 로드 밸런서, 역방향 프록시 또는 API 게이트웨이가 포함됩니다. 중간 구성 요소가 있는 경우 관리 클러스터를 가져올 때 hub 클러스터 API 서버에 사용자 정의 서버 URL 및 CA 번들을 사용해야 합니다.

1.7.18.3.1. 사전 요구 사항
링크 복사
  • hub 클러스터 API 서버가 관리 클러스터에 액세스할 수 있도록 중간 구성 요소를 구성해야 합니다.

  • 중간 구성 요소가 관리 클러스터와 허브 클러스터 API 서버 간의 SSL 연결을 종료하는 경우 SSL 연결을 브리지하고 원래 요청의 인증 정보를 hub 클러스터 API 서버의 백엔드로 전달해야 합니다. Kubernetes API 서버의 사용자 유휴 기능을 사용하여 SSL 연결을 브리지할 수 있습니다.

    중간 구성 요소는 원래 요청에서 클라이언트 인증서를 추출하고 인증서 제목의 CN(Common Name) 및 조직(O)을 가장 헤더로 추가한 다음 수정된 가장 요청을 허브 클러스터 API 서버의 백엔드로 전달합니다.

    참고: SSL 연결을 브리지하는 경우 클러스터 프록시 애드온이 작동하지 않습니다.

1.7.18.3.2. 서버 URL 및 허브 클러스터 CA 번들 사용자 정의
링크 복사

관리 클러스터를 가져올 때 사용자 정의 허브 API 서버 URL 및 CA 번들을 사용하려면 다음 단계를 완료하십시오.

  1. 사용자 정의 허브 클러스터 API 서버 URL 및 CA 번들을 사용하여 KlusterConfig 리소스를 생성합니다. 다음 예제를 참조하십시오. 

    apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: <name>
    1 
    
spec:
  hubKubeAPIServerConfig:
    url: "https://api.example.com:6443"
    2 
    
    serverVerificationStrategy: UseCustomCABundles
    trustedCABundles:
    - name: <custom-ca-bundle>
    3 
    
      caBundle:
        name: <custom-ca-bundle-configmap>
    4 
    
        namespace: <multicluster-engine>
    5
    Copy to Clipboard Toggle word wrap
    1
    klusterlet 구성 이름을 추가합니다.
    2
    사용자 지정 서버 URL을 추가합니다.
    3
    사용자 정의 CA 번들 이름을 추가합니다. 내부 사용을 위해 예약된 자동 감지를 제외한 모든 값을 사용할 수 있습니다.
    4
    CA 번들 ConfigMap의 이름을 추가합니다. 다음 명령을 실행하여 ConfigMap을 생성할 수 있습니다. oc create -n <configmap-namespace> configmap-name> --from-file=ca.crt=/path/to/ca/file
    5
    CA 번들 ConfigMap의 네임스페이스를 추가합니다.

  2. 리소스를 참조하는 주석을 추가하여 관리 클러스터를 생성할 때 KlusterletConfig 리소스를 선택합니다. 다음 예제를 참조하십시오. 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    agent.open-cluster-management.io/klusterlet-config:
    1 
    
  name:
    2 
    
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60
    Copy to Clipboard Toggle word wrap
    1
    klusterlet 구성 이름을 추가합니다.
    2
    클러스터 이름을 추가합니다.

    참고:

    • 콘솔을 사용하는 경우 YAML 보기를 활성화하여 ManagedCluster 리소스에 주석을 추가해야 할 수 있습니다.
    • 글로벌 KlusterletConfig 를 사용하여 바인딩에 주석을 사용하지 않고도 모든 관리 클러스터에서 구성을 활성화할 수 있습니다.
1.7.18.3.3. 글로벌 KlusterletConfig구성
링크 복사

KlusterletConfig 리소스를 생성하고 이름을 global 로 설정하면 글로벌 KlusterletConfig 의 구성이 모든 관리 클러스터에 자동으로 적용됩니다.

글로벌 KlusterletConfig 가 있는 환경에서는 cluster-specific KlusterletConfig 를 생성하고 agent.open-cluster-management.io/klusterlet-config: <klusterletconfig-name> 주석을 ManagedCluster 리소스에 추가하여 관리 클러스터에 바인딩할 수도 있습니다. 동일한 필드에 다른 값을 설정하면 클러스터별 KlusterletConfig 의 값이 글로벌 KlusterletConfig 값을 덮어씁니다.

hubKubeAPIServerURL 필드에 KlusterletConfig 및 글로벌 KlusterletConfig 에 다른 값이 설정되어 있는 다음 예제를 참조하십시오. "https://api.example.test.com:6443" 값은 "https://api.example.global.com:6443" 값을 덮어씁니다.

사용 중단: hubKubeAPIServerURL 필드는 더 이상 사용되지 않습니다. 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: test
spec:
  hubKubeAPIServerConfig:
    url: "https://api.example.test.com:6443"
---
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerConfig:
    url: "https://api.example.global.com:6443"
Copy to Clipboard Toggle word wrap

글로벌 KlusterletConfig 의 값은 관리 클러스터에 바인딩된 클러스터별 KlusterletConfig 가 없거나 동일한 필드가 없거나 클러스터별 KlusterletConfig 에 값이 없는 경우 사용됩니다.

글로벌 KlusterletConfig 의 hubKubeAPIServerURL 필드에 있는 "example.global.com" 값이 KlusterletConfig 를 덮어씁니다. 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: test
spec:
  hubKubeAPIServerURL: ""
—
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerURL: "example.global.com"
Copy to Clipboard Toggle word wrap

글로벌 KlusterletConfig 의 hubKubeAPIServerURL 필드에 있는 "example.global.com" 값도 KlusterletConfig 를 덮어씁니다. 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: test
—
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerURL: "example.global.com"
Copy to Clipboard Toggle word wrap
1.7.18.4. 허브 클러스터 KubeAPIServer 확인 전략 구성
링크 복사

관리형 클러스터는 OpenShift Container Platform KubeAPIServer 외부 로드 밸런서와의 상호 연결을 통해 허브 클러스터와 통신합니다. OpenShift Container Platform을 설치할 때 내부 OpenShift Container Platform 클러스터 인증 기관(CA)에서 기본 OpenShift Container Platform KubeAPIServer 인증서를 발행합니다. Kubernetes Operator용 다중 클러스터 엔진은 부트스트랩-kubeconfig-secret 네임스페이스의 관리 클러스터에 인증서를 자동으로 탐지하고 추가합니다.

자동으로 감지된 인증서가 작동하지 않으면 KlusterletConfig 리소스에서 전략 구성을 수동으로 구성할 수 있습니다. 전략을 수동으로 구성하면 허브 클러스터 KubeAPIServer 인증서를 확인하는 방법을 제어할 수 있습니다.

전략을 수동으로 구성하는 방법을 알아보려면 다음 세 가지 전략 중 하나의 예제를 참조하십시오.

1.7.18.4.1. UseAutoDetectedCABundle을 사용하여 전략 구성
링크 복사

기본 구성 전략은 UseAutoDetectedCABundle 입니다. 다중 클러스터 엔진 Operator는 hub 클러스터에서 인증서를 자동으로 감지하고 구성 맵의 trustedCABundles 목록에 구성된 인증서를 실제 CA 번들에 대한 참조에 병합합니다.

다음 예제에서는 hub 클러스터에서 자동으로 감지된 인증서와 new-ocp-ca 구성 맵에서 구성한 인증서를 병합하고 관리 클러스터에 둘 다 추가합니다. 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
 name: ca-strategy
spec:
 hubKubeAPIServerConfig:
   serverVerificationStrategy: UseAutoDetectedCABundle
   trustedCABundles:
   - name: new-ca
     caBundle:
       name: new-ocp-ca
       namespace: default
Copy to Clipboard Toggle word wrap
1.7.18.4.2. UseSystemTruststore를 사용하여 전략 구성
링크 복사

UseSystemTruststore 에서는 다중 클러스터 엔진 Operator가 인증서를 탐지하지 않고 trustedCABundles 매개변수 섹션에 구성된 인증서를 무시합니다. 이 구성은 관리 클러스터에 인증서를 전달하지 않습니다. 대신 관리 클러스터는 관리 클러스터의 시스템 신뢰할 수 있는 저장소의 인증서를 사용하여 허브 클러스터 API 서버를 확인합니다. 이는 Let's Encrypt 와 같은 공용 CA가 허브 클러스터 인증서를 발급하는 상황에 적용됩니다. UseSystemTruststore 를 사용하는 다음 예제를 참조하십시오. 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
 name: ca-strategy
spec:
 hubKubeAPIServerConfig:
   serverVerificationStrategy: UseSystemTruststore
Copy to Clipboard Toggle word wrap
1.7.18.4.3. UseCustomCABundles를 사용하여 전략 구성
링크 복사

hub 클러스터 API 서버의 CA를 알고 다중 클러스터 엔진 운영자가 자동으로 감지하지 않도록 하려면 UseCustomCABundles 를 사용할 수 있습니다. 이 전략의 경우 다중 클러스터 엔진 Operator는 구성된 인증서를 trustedCABundles 매개변수에서 관리 클러스터에 추가합니다. UseCustomCABundles 사용 방법을 알아보려면 다음 예제를 참조하십시오. 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
 name: ca-strategy
spec:
 hubKubeAPIServerConfig:
   serverVerificationStrategy: UseCustomCABundles
   trustedCABundles:
   - name: ca
     caBundle:
       name: ocp-ca
       namespace: default
Copy to Clipboard Toggle word wrap

일반적으로 이 정책은 각 관리 클러스터에 대해 동일합니다. 허브 클러스터 관리자는 다중 클러스터 엔진 Operator 또는 허브 클러스터 인증서 변경 시 각 관리 클러스터에 대한 정책을 활성화하도록 global 이라는 KlusterletConfig 를 구성할 수 있습니다. 다음 예제를 참조하십시오. 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
 name: global
spec:
 hubKubeAPIServerConfig:
   serverVerificationStrategy: UseSystemTruststore
Copy to Clipboard Toggle word wrap

관리 클러스터에서 다른 전략을 사용해야 하는 경우 다른 KlusterletConfig 를 생성하고 관리 클러스터의 agent.open-cluster-management.io/klusterlet-config 주석을 사용하여 특정 전략을 가리킬 수도 있습니다. 다음 예제를 참조하십시오. 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
 name: test-ca
spec:
 hubKubeAPIServerConfig:
   serverVerificationStrategy: UseCustomCABundles
   trustedCABundles:
   - name: ca
     caBundle:
       name: ocp-ca
       namespace: default
--
apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    agent.open-cluster-management.io/klusterlet-config: test-ca
  name: cluster1
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60
Copy to Clipboard Toggle word wrap
1.7.18.5. 추가 리소스
링크 복사

1.7.19. 관리에서 클러스터 제거
링크 복사

다중 클러스터 엔진 Operator를 사용하여 생성된 관리에서 OpenShift Container Platform 클러스터를 제거하면 이를 분리 하거나 제거할 수 있습니다. 클러스터를 분리하면 관리에서 제거되지만 완전히 삭제되지는 않습니다. 관리하려는 경우 다시 가져올 수 있습니다. 이는 클러스터가 Ready 상태에 있는 경우에만 옵션입니다.

다음 절차에서는 다음 상황 중 하나로 관리에서 클러스터를 제거합니다.

  • 클러스터를 이미 삭제하고 Red Hat Advanced Cluster Management에서 삭제된 클러스터를 제거하려고 합니다.
  • 관리에서 클러스터를 제거하려고 하지만 클러스터를 삭제하지 않았습니다.

중요:

1.7.19.1. 콘솔을 사용하여 클러스터 제거
링크 복사

탐색 메뉴에서 Infrastructure > Clusters 로 이동하여 관리에서 제거하려는 클러스터 옆에 있는 옵션 메뉴에서 Destroy cluster 또는 Detach 클러스터를 선택합니다.

팁: 분리 또는 삭제하려는 클러스터의 확인란을 선택하고 Detach 또는 Destroy 를 선택하여 여러 클러스터를 분리하거나 제거할 수 있습니다.

중요: < your-local-cluster-name>이라는 허브 클러스터를 분리하려고 하면 disableHubSelfManagement 의 기본 설정이 false 이고 hub 클러스터는 자체적으로 관리하는 local-cluster 임을 유의하십시오. 이 설정으로 인해 허브 클러스터가 분리될 때 다시 가져와서 자체적으로 관리하며 MultiClusterHub 컨트롤러를 조정합니다. hub 클러스터에서 분리 프로세스를 완료하고 다시 가져오는 데 몇 시간이 걸릴 수 있습니다.

프로세스가 완료될 때까지 기다리지 않고 허브 클러스터를 다시 가져오려면 다음 명령을 입력하여 multiclusterhub-operator Pod를 재시작하고 더 빠르게 다시 가져올 수 있습니다. 

oc -n open-cluster-management delete -l name=multiclusterhub-operator pods
Copy to Clipboard Toggle word wrap

온라인 연결 중 설치에 설명된 대로 disableHubSelfManagement 값을 true 로 변경하여 Hub 클러스터의 값을 자동으로 가져오지 않도록 할 수 있습니다.

1.7.19.2. 명령줄을 사용하여 클러스터 제거
링크 복사

hub 클러스터의 명령줄을 사용하여 관리 클러스터를 분리하려면 다음 명령을 실행합니다. 

oc delete managedcluster $CLUSTER_NAME
Copy to Clipboard Toggle word wrap

분리 후 관리되는 클러스터를 삭제하려면 다음 명령을 실행합니다. 

oc delete clusterdeployment <CLUSTER_NAME> -n $CLUSTER_NAME
Copy to Clipboard Toggle word wrap

참고:

  • 관리 클러스터를 제거하지 않으려면 ClusterDeployment 사용자 정의 리소스에서 spec.preserveOnDelete 매개변수를 true 로 설정합니다.

  • disableHubSelfManagement 의 기본 설정은 false 입니다. false 설정을 사용하면 local-cluster 인 hub 클러스터가 분리되고 MultiClusterHub 컨트롤러를 조정할 때 자신을 다시 가져오고 관리합니다.

    연결 해제 및 다시 가져오기 프로세스는 허브 클러스터를 완료하는 데 몇 시간이 걸릴 수 있습니다. 프로세스가 완료될 때까지 기다리지 않고 허브 클러스터를 다시 가져오려면 다음 명령을 입력하여 multiclusterhub-operator Pod를 재시작하고 더 빨리 다시 가져올 수 있습니다. 

    oc -n open-cluster-management delete -l name=multiclusterhub-operator pods
    Copy to Clipboard Toggle word wrap

    disableHubSelfManagement 값을 true 로 변경하여 hub 클러스터의 값을 자동으로 가져오지 않도록 할 수 있습니다. 온라인으로 연결하는 동안 설치를 참조하십시오.

1.7.19.3. 클러스터를 제거한 후 나머지 리소스 제거
링크 복사

관리 클러스터에 제거된 리소스가 남아 있는 경우 나머지 구성 요소를 모두 제거하는 데 필요한 추가 단계가 있습니다. 이러한 추가 단계가 필요한 경우 다음 예제가 포함됩니다.

  • 관리되는 클러스터는 완전히 생성되기 전에 분리되었으며 klusterlet 과 같은 구성 요소는 관리 클러스터에 남아 있습니다.
  • 클러스터를 관리하고 있는 허브는 관리 클러스터를 분리하기 전에 손실되거나 삭제되었으며 허브에서 관리 클러스터를 분리할 방법이 없습니다.
  • 관리형 클러스터는 분리될 때 온라인 상태가 아닙니다.

이러한 상황 중 하나가 관리형 클러스터의 분리에 적용되는 경우 관리 클러스터에서 제거할 수 없는 몇 가지 리소스가 있습니다. 관리 클러스터를 분리하려면 다음 단계를 완료합니다.

  1. oc 명령줄 인터페이스가 구성되어 있는지 확인합니다.

  2. 관리 클러스터에 KUBECONFIG 가 구성되어 있는지 확인합니다.

    oc get ns | grep open-cluster-management-agent 를 실행하면 두 개의 네임스페이스가 표시됩니다. 

    open-cluster-management-agent         Active   10m
open-cluster-management-agent-addon   Active   10m
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 사용하여 klusterlet 사용자 정의 리소스를 제거합니다. 

    oc get klusterlet | grep klusterlet | awk '{print $1}' | xargs oc patch klusterlet --type=merge -p '{"metadata":{"finalizers": []}}'
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 나머지 리소스를 제거합니다. 

    oc delete namespaces open-cluster-management-agent open-cluster-management-agent-addon --wait=false
oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc delete crds --wait=false
oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc patch crds --type=merge -p '{"metadata":{"finalizers": []}}'
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 네임스페이스와 열려 있는 모든 클러스터 관리 crds 가 모두 제거되었는지 확인합니다. 

    oc get crds | grep open-cluster-management.io | awk '{print $1}'
oc get ns | grep open-cluster-management-agent
    Copy to Clipboard Toggle word wrap
1.7.19.4. 클러스터를 제거한 후 etcd 데이터베이스 조각 모음
링크 복사

많은 관리 클러스터가 있으면 hub 클러스터의 etcd 데이터베이스 크기에 영향을 미칠 수 있습니다. OpenShift Container Platform 4.8에서는 관리 클러스터를 삭제하면 허브 클러스터의 etcd 데이터베이스가 크기가 자동으로 줄어들지 않습니다. 일부 시나리오에서는 etcd 데이터베이스를 공간이 부족할 수 있습니다. etcdserver: mvcc: 데이터베이스 공간 초과 오류가 표시됩니다. 이 오류를 수정하려면 데이터베이스 기록을 압축하고 etcd 데이터베이스를 조각 모음하여 etcd 데이터베이스 크기를 줄입니다.

참고: OpenShift Container Platform 버전 4.9 이상의 경우 etcd Operator는 자동으로 디스크를 조각 모음하고 etcd 기록을 압축합니다. 수동 조작이 필요하지 않습니다. 다음 절차는 OpenShift Container Platform 버전 4.8 및 이전 버전의 절차입니다.

다음 절차를 완료하여 etcd 기록을 압축하고 hub 클러스터에서 etcd 데이터베이스를 조각 모음합니다.

1.7.19.4.1. 사전 요구 사항
링크 복사
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
1.7.19.4.2. 프로세스
링크 복사

  1. etcd 기록을 압축합니다.

    1. etcd 멤버에 대한 원격 쉘 세션을 엽니다. 예를 들면 다음과 같습니다. 

      $ oc rsh -n openshift-etcd etcd-control-plane-0.example.com etcdctl endpoint status --cluster -w table
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 etcd 기록을 압축합니다. 

      sh-4.4#etcdctl compact $(etcdctl endpoint status --write-out="json" |  egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*' -m1)
      Copy to Clipboard Toggle word wrap

      출력 예

      $ compacted revision 158774421
      Copy to Clipboard Toggle word wrap

  2. etcd 데이터베이스를 조각 모음하고 etcd 데이터 분리에 설명된 대로 NOSPACE 경고를 지웁니다.

1.8. 검색 서비스
링크 복사

OpenShift Cluster Manager 에서 사용할 수 있는 OpenShift Container Platform 클러스터를 검색할 수 있습니다. 검색 후 관리할 클러스터를 가져올 수 있습니다. Discovery 서비스는 백엔드 및 콘솔 사용에 Discover Operator를 사용합니다.

OpenShift Cluster Manager 인증 정보가 있어야 합니다. 인증 정보를 생성해야 하는 경우 OpenShift Cluster Manager의 인증 정보 생성 을 참조하십시오.

필요한 액세스: 관리자

1.8.1. 서비스 계정 인증
링크 복사

OpenShift Cluster Manager 에서 사용할 수 있는 OpenShift Container Platform 클러스터를 검색하려면 서비스 계정으로 인증해야 합니다. OpenShift Cluster Manager 오프라인 토큰은 더 이상 사용되지 않습니다.

사전 요구 사항

1.8.1.1. 인증
링크 복사

서비스 계정으로 인증하려면 다음 절차를 참조하십시오.

  1. 다중 클러스터 엔진 운영자 콘솔에서 service-account client-id 및 client-secret 쌍으로 새 인증 정보 시크릿을 생성합니다.
  2. 다중 클러스터 엔진 operator Discovery 서비스에서 올바르게 인증하고 클러스터를 검색할 수 있도록 서비스 계정 client-id 및 client-secret 쌍을 지정합니다.
  3. 가져오기를 위해 AWS DiscoveredCluster 리소스에서 Red Hat OpenShift Service를 관리형 클러스터로 설정합니다. service-account 자격 증명을 사용하여 시작된 AWS 가져오기 흐름의 Red Hat OpenShift Service는 클러스터를 인증하고 가져옵니다.
Expand
표 1.10. 배포된 구성 요소 목록
Role액세스 권한

OpenShift Cluster Manager cluster autoscaler editor

클러스터 자동 스케일러에서 업데이트 작업 수행

OpenShift Cluster Manager cluster editor

클러스터에서 업데이트 작업 수행

OpenShift Cluster Manager 클러스터 프로비저너

클러스터에서 프로비저닝 작업 수행

OpenShift Cluster Manager cluster viewer

클러스터에서 읽기 작업 수행

OpenShift Cluster Manager IdP editor

IdP에서 업데이트 작업 수행

OpenShift Cluster Manager 시스템 풀 편집기

머신 풀에서 업데이트 작업 수행

OpenShift Cluster Manager 조직 관리자

연결된 조직의 클러스터에서 사용 가능한 모든 작업을 수행합니다.

서브스크립션 뷰어

모든 서브스크립션 리소스에서 읽기 작업을 수행합니다.

1.8.2. 콘솔을 사용하여 Discovery 구성
링크 복사

콘솔을 통해 클러스터를 찾도록 Discovery를 구성합니다. 클러스터에서 Discovery 기능을 구성할 때 DiscoveryConfig 리소스가 OpenShift Cluster Manager에 연결하여 조직의 일부인 클러스터 검색을 시작해야 합니다. 별도의 인증 정보를 사용하여 여러 DiscoveryConfig 리소스를 생성할 수 있습니다.

클러스터를 검색한 후 콘솔의 Discovered clusters 탭에 표시되는 클러스터를 가져올 수 있습니다. 제품 콘솔을 사용하여 Discovery를 활성화합니다.

필수 액세스: 인증 정보가 생성된 네임스페이스에 대한 액세스입니다.

사전 요구 사항

1.8.2.1. 콘솔에서 검색된 클러스터 가져오기
링크 복사

다른 인프라 공급자에서 검색된 클러스터를 수동으로 가져오려면 다음 단계를 완료합니다.

  1. 기존 클러스터 페이지로 이동하여 Discovered clusters 탭을 클릭합니다.
  2. Discovered clusters 테이블에서 가져올 클러스터를 찾습니다.
  3. 옵션 메뉴에서 클러스터 가져오기 를 선택합니다.
  4. 검색된 클러스터의 경우 문서를 사용하여 수동으로 가져오거나 클러스터 가져오기를 자동으로 선택할 수 있습니다.
  5. 인증 정보 또는 Kubeconfig 파일을 사용하여 자동으로 가져오려면 콘텐츠를 복사하여 붙여넣습니다.
  6. 가져오기 를 클릭합니다.
1.8.2.2. 검색된 클러스터 보기
링크 복사

인증 정보를 설정하고 가져올 클러스터를 검색한 후 콘솔에서 해당 정보를 볼 수 있습니다.

  1. Clusters > Discovered clusters 를 클릭합니다.

  2. 다음 정보로 채워진 테이블을 확인합니다.

    • name 은 OpenShift Cluster Manager에 지정된 표시 이름입니다. 클러스터에 표시 이름이 없으면 클러스터 콘솔 URL을 기반으로 생성된 이름이 표시됩니다. OpenShift Cluster Manager에서 콘솔 URL이 없거나 수동으로 수정된 경우 클러스터 외부 ID가 표시됩니다.
    • 네임스페이스 는 인증 정보 및 검색된 클러스터를 생성한 네임스페이스입니다.
    • type 은 검색된 클러스터 Red Hat OpenShift 유형입니다.
    • 배포 버전은 검색된 클러스터 Red Hat OpenShift 버전입니다.
    • 인프라 공급자는 검색된 클러스터의 클라우드 공급자입니다.
    • 마지막 활성 은 검색된 클러스터가 마지막으로 활성화된 시간입니다.
    • 검색된 클러스터가 생성 될 때 생성됩니다.
    • 검색된 클러스터가 검색된 시기를 검색합니다.
    • 클러스터 유형은 클러스터 의 플랫폼 유형(예: OpenShift Container Platform 또는 AWS의 Red Hat OpenShift Service)입니다.
    • 인프라 공급자는 AWS(Amazon Web Services) 또는 Microsoft Azure와 같이 클러스터가 실행되는 위치에 따라 필터링합니다.
  3. 또한 표에서 모든 정보를 검색할 수 있습니다. 예를 들어 특정 네임스페이스에 있는 Discovered 클러스터 만 표시하려면 해당 네임스페이스를 검색합니다.
  4. 이제 클러스터 가져오기를 클릭하여 관리 클러스터를 생성할 수 있습니다.

1.8.3. CLI를 사용하여 Discovery 활성화
링크 복사

CLI를 사용하여 검색을 활성화하여 OpenShift Cluster Manager에서 사용할 수 있는 클러스터를 찾습니다.

필요한 액세스: 관리자

사전 요구 사항

  • OpenShift Cluster Manager에 연결할 자격 증명을 생성합니다.
1.8.3.1. 검색 설정 및 프로세스
링크 복사

참고: DiscoveryConfig 라는 이름은 discovery 이고 선택한 인증 정보와 동일한 네임스페이스에서 생성해야 합니다. 다음 DiscoveryConfig 샘플을 참조하십시오. 

apiVersion: discovery.open-cluster-management.io/v1
kind: DiscoveryConfig
metadata:
  name: discovery
  namespace: <NAMESPACE_NAME>
spec:
  credential: <SECRET_NAME>
  filters:
    lastActive: 7
    openshiftVersions:
    - "4.x"
Copy to Clipboard Toggle word wrap
  1. SECRET_NAME 을 이전에 설정한 인증 정보로 교체합니다.
  2. NAMESPACE_NAME 을 SECRET_NAME 의 네임스페이스로 바꿉니다.
  3. 검색할 클러스터의 마지막 활동 이후 최대 시간을 입력합니다. 예를 들어 lastActive: 7 에서는 지난 7일 동안 활성 상태인 클러스터가 검색됩니다.
  4. 검색할 OpenShift Container Platform 클러스터 버전을 입력하여 문자열 목록으로 검색합니다. 참고: openshiftVersions 목록의 모든 항목은 메이저 및 마이너 버전을 지정합니다. 예를 들어 4.x를 지정하면 4.x.1,4.x.2 와 같은 모든 에라타 릴리스가 포함됩니다.
1.8.3.2. 검색된 클러스터 보기
링크 복사

oc get discoveredclusters -n <namespace >를 실행하여 검색된 클러스터를 확인합니다. 여기서 namespace 는 검색 인증 정보가 존재하는 네임스페이스입니다.

오브젝트는 검색 컨트롤러에서 생성합니다. 이러한 DiscoveredClusters 는 DiscoveryConfig 검색된clusters.discovery.open-cluster-management.io API에 지정된 필터 및 자격 증명을 사용하여 OpenShift Cluster Manager에 있는 클러스터를 나타냅니다. name 값은 클러스터 외부 ID입니다. 

apiVersion: discovery.open-cluster-management.io/v1
kind: DiscoveredCluster
metadata:
  name: <cluster-external-id>
  namespace: <NAMESPACE_NAME>
spec:
  activity_timestamp: "2022-04-19T21:06:14Z"
  cloudProvider: vsphere
  console: https://console-openshift-console.apps.qe1-vmware-pkt.dev02.red-chesterfield.com
  creation_timestamp: "2022-04-19T16:29:53Z"
  credential:
    apiVersion: v1
    kind: Secret
    name: <SECRET_NAME>
    namespace: <NAMESPACE_NAME>
  display_name: qe1-vmware-pkt.dev02.red-chesterfield.com
  name: <cluster-external-id>
  openshiftVersion: 4.x
  status: Stale
Copy to Clipboard Toggle word wrap

1.8.4. 관리를 위해 검색된 클러스터 활성화
링크 복사

개별 클러스터를 수동으로 가져오지 않고 Discovery-Operator 를 사용하여 지원되는 클러스터를 허브 클러스터로 자동으로 가져옵니다.

필수 액세스: 클러스터 관리자

사전 요구 사항

  • Discovery는 기본적으로 활성화되어 있습니다. 기본 설정을 변경한 경우 Discovery를 활성화해야 합니다.
  • AWS 명령줄 인터페이스에서 Red Hat OpenShift Service를 설정해야 합니다. AWS CLI에서 Red Hat OpenShift Service 시작하기 설명서를 참조하십시오.

다음 절차는 Discovery-Operator 를 사용하여 AWS에서 검색된 Red Hat OpenShift Service 및 호스팅된 컨트롤 플레인 클러스터를 자동으로 가져오는 방법의 예입니다. 콘솔 또는 명령줄 인터페이스에서 가져올 수 있습니다.

  • 콘솔에서 가져옵니다. 콘솔에서 리소스를 수정하고 importAsManagedCluster 필드를 true 로 설정해야 합니다.

    1. 콘솔에서 hub 클러스터에 로그인합니다.
    2. 탐색 메뉴에서 Search 를 선택합니다.
    3. 검색 모음에서 "DiscoveredCluster" 쿼리를 입력합니다.
    4. DiscoveredCluster 리소스 결과가 표시됩니다.

    5. DiscoveredCluster 리소스로 이동하여 importAsManagedCluster 를 true 로 설정합니다. importAsManagedCluster 가 true 로 설정되고 < 4.x.z >가 지원되는 OpenShift Container Platform 버전인 다음 예제를 참조하십시오. 

      apiVersion: discovery.open-cluster-management.io/v1
kind: DiscoveredCluster
metadata:
  name: 28c17977-fc73-4050-b5cc-a5aa2d1d6892
  namespace: discovery
spec:
  openshiftVersion: <4.x.z>
  isManagedCluster: false
  cloudProvider: aws
  name: 28c17977-fc73-4050-b5cc-a5aa2d1d6892
  displayName: rosa-dc
  status: Active
  importAsManagedCluster: true
      1 
      
  type: <supported-type>
      2
      Copy to Clipboard Toggle word wrap
      1
      필드를 true 로 설정하면 Discovery-Operator 에서 DiscoveredCluster 리소스를 가져오고 ManagedCluster 리소스를 생성하고 Red Hat Advanced Cluster Management가 설치된 경우 KlusterletAddOnConfig 리소스를 생성합니다. 자동 가져오기를 위해 Secret 리소스도 생성합니다.
      2
      ROSA 또는 MultiClusterEngineHCP 를 매개변수 값으로 사용해야 합니다.
    6. DiscoveredCluster 리소스를 가져오려면 클러스터 페이지로 이동합니다. 클러스터 목록 탭에서 클러스터 가져오기 상태를 확인합니다.

    7. 자동 다시 가져오기를 방지하기 위해 Discovery의 관리 클러스터를 분리하려면 Detach 클러스터 옵션을 선택합니다. Discovery-Operator 는 다음 주석 discovery.open-cluster-management.io/previously-auto-imported: 'true' 를 추가합니다.

      DiscoveredCluster 리소스는 다음 YAML과 유사할 수 있습니다. 

      apiVersion: discovery.open-cluster-management.io/v1
kind: DiscoveredCluster
metadata:
  annotations:
    discovery.open-cluster-management.io/previously-auto-imported: 'true'
      Copy to Clipboard Toggle word wrap

    8. DiscoveredCluster 리소스가 자동으로 다시 가져오기되지 않았는지 확인하려면 Discovery-Operator 로그에서 다음 메시지를 확인합니다. 여기서 "rosa-dc" 가 검색된 클러스터입니다. 

      2024-06-12T14:11:43.366Z INFO reconcile	Skipped automatic import for DiscoveredCluster due to
existing 'discovery.open-cluster-management.io/previously-auto-imported' annotation {"Name": "rosa-dc"}
      Copy to Clipboard Toggle word wrap

    참고: DiscoveredCluster 리소스를 자동으로 다시 가져오려면 이전에 언급한 주석을 제거해야 합니다.

  • 명령줄 인터페이스에서 가져옵니다.

    1. 명령줄 인터페이스에서 DiscoveredCluster 리소스를 자동으로 가져오려면 다음을 수행합니다. 로그인 후 다음 명령을 사용하여 importAsManagedCluster paramater를 true 로 설정합니다. &lt ;name&gt; 및 < namespace >를 사용자 이름과 네임스페이스로 바꿉니다. 

      oc patch discoveredcluster <name> -n <namespace> --type='json' -p='[{"op": "replace", "path": "/spec/importAsManagedCluster", "value": true}]'
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 클러스터를 관리 클러스터로 가져왔는지 확인합니다. 

      oc get managedcluster <name>
      Copy to Clipboard Toggle word wrap
    3. AWS 클러스터 ID의 Red Hat OpenShift Service에 대한 설명을 보려면 AWS 명령줄 인터페이스의 Red Hat OpenShift Service에서 다음 명령을 실행합니다. 
    rosa describe cluster --cluster=<cluster-name> | grep -o ^ID:.*
    Copy to Clipboard Toggle word wrap

중요: 다른 Kubernetes 공급자의 경우 이러한 인프라 공급자 DiscoveredCluster 리소스를 수동으로 가져와야 합니다. Kubernetes 구성을 다른 유형의 DiscoveredCluster 리소스에 직접 적용합니다. DiscoveredCluster 리소스에서 importAsManagedCluster 필드를 활성화하면 Discovery webhook로 인해 가져오지 않습니다.

1.9. 호스트 인벤토리 소개
링크 복사

호스트 인벤토리 관리 및 온-프레미스 클러스터 설치는 다중 클러스터 엔진 Operator 중앙 인프라 관리 기능을 사용하여 사용할 수 있습니다.

호스트 인벤토리 및 중앙 인프라 관리에 대해 자세히 알아보려면 계속 읽으십시오.

1.9.1. 호스트 인벤토리 개요
링크 복사

주요 인프라 관리 기능은 라이프사이클 동안 베어 메탈 호스트를 관리하는 데 중점을 둔 멀티 클러스터 엔진 Operator의 Red Hat OpenShift Container Platform 설치 경험입니다.

지원 설치 프로그램은 에이전트를 사용하여 대상 호스트에서 사전 설치 검증을 실행하는 OpenShift Container Platform 설치 방법과 설치 진행 상황을 평가하고 추적하는 중앙 서비스입니다.

Red Hat OpenShift용 인프라 Operator는 지원 설치 관리자 서비스를 실행하는 워크로드를 관리하고 설치하는 다중 클러스터 엔진 운영자 구성 요소입니다.

콘솔을 사용하여 온프레미스 OpenShift Container Platform 클러스터를 생성하는 데 사용할 수 있는 베어 메탈 또는 가상 머신 풀인 호스트 인벤토리를 생성할 수 있습니다. 이러한 클러스터는 컨트롤 플레인 전용 머신 또는 컨트롤 플레인의 전용 머신이 있는 독립 실행형 클러스터일 수 있습니다. 여기서 컨트롤 플레인은 허브 클러스터에서 Pod로 실행됩니다. ../../html-single/clusters#hosted-control-planes-intro

ZTP(ZTP)를 사용하여 콘솔, API 또는 GitOps를 사용하여 독립 실행형 클러스터를 설치할 수 있습니다. ZTP에 대한 자세한 내용은 Red Hat OpenShift Container Platform 설명서의 연결이 끊긴 환경에 GitOps ZTP 설치를 참조하십시오.

시스템은 Discovery Image로 부팅한 후 호스트 인벤토리를 결합합니다. Discovery Image는 다음이 포함된 Red Hat CoreOS 라이브 이미지입니다.

  • 검색, 검증 및 설치 작업을 수행하는 에이전트입니다.
  • 해당하는 경우 엔드포인트, 토큰, 정적 네트워크 구성을 포함하여 허브 클러스터에서 서비스에 연결하는 데 필요한 구성입니다.

공통 속성 세트를 공유하는 호스트 세트인 각 인프라 환경에 대해 하나의 Discovery Image가 있습니다. InfraEnv 사용자 정의 리소스 정의는 이 인프라 환경 및 관련 Discovery Image를 나타냅니다. InfraEnv 사용자 정의 리소스에서 osImageVersion 필드를 설정하여 검색 이미지에 사용되는 Red Hat Core OS 버전을 지정할 수 있습니다. 값을 지정하지 않으면 최신 Red Hat Core OS 버전이 사용됩니다.

호스트가 부팅되고 에이전트가 서비스에 연결되면 서비스는 해당 호스트를 나타내는 허브 클러스터에 새 Agent 사용자 정의 리소스를 생성합니다. 에이전트 리소스는 호스트 인벤토리를 구성합니다.

나중에 OpenShift 노드로 인벤토리에 호스트를 설치할 수 있습니다. 에이전트는 필요한 구성과 함께 운영 체제를 디스크에 쓰고 호스트를 재부팅합니다.

참고: Red Hat Advanced Cluster Management 및 중앙 인프라 관리는 Nutanix 가상 머신을 생성하여 추가 구성이 필요한 AgentClusterInstall 리소스를 사용하여 Nutanix 플랫폼을 지원합니다. 자세한 내용은 지원 설치 관리자 설명서의 선택적: Nutanix에 설치를 참조하십시오.

1.9.2. 중앙 인프라 관리 서비스 활성화
링크 복사

중앙 인프라 관리 서비스는 다중 클러스터 엔진 Operator와 함께 제공되며 OpenShift Container Platform 클러스터를 배포합니다. Red Hat Advanced Cluster Management를 설치하고 hub 클러스터에서 MultiClusterHub Operator를 활성화했지만 이 경우 서비스를 수동으로 활성화해야 하는 경우 중앙 인프라 관리 서비스가 자동으로 배포됩니다.

다음 섹션을 참조하십시오.

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

중앙 인프라 관리 서비스를 활성화하기 전에 다음 사전 요구 사항을 참조하십시오.

  • 지원되는 OpenShift Container Platform 버전과 지원되는 Red Hat Advanced Cluster Management for Kubernetes 버전에 배포된 허브 클러스터가 있어야 합니다.
  • 허브 클러스터에 대한 인터넷 액세스가 필요합니다.
  • 연결이 끊긴 환경에서 작업하는 경우 환경을 생성하는 데 필요한 이미지를 검색하기 위해 인터넷에 연결되어 있는 내부 또는 미러 레지스트리에 대한 연결이 필요합니다.
  • 베어 메탈 프로비저닝에 필요한 포트를 열어야 합니다. OpenShift Container Platform 설명서에서 필요한 포트 활성화를 참조하십시오.
  • 베어 메탈 호스트 사용자 정의 리소스 정의가 필요합니다.
  • OpenShift Container Platform 풀 시크릿 이 필요합니다. 자세한 내용은 이미지 풀 시크릿 사용을 참조하십시오.
  • 구성된 기본 스토리지 클래스가 필요합니다.
  • 연결이 끊긴 환경의 경우 OpenShift Container Platform 설명서에서 네트워크 맨 엣지에서 클러스터에 대한 절차를 완료합니다.
1.9.2.2. 베어 메탈 호스트 사용자 정의 리소스 정의 생성
링크 복사

중앙 인프라 관리 서비스를 활성화하기 전에 베어 메탈 호스트 사용자 정의 리소스 정의가 필요합니다.

  1. 다음 명령을 실행하여 베어 메탈 호스트 사용자 정의 리소스 정의가 있는지 확인합니다. 

    oc get crd baremetalhosts.metal3.io
    Copy to Clipboard Toggle word wrap
    • 베어 메탈 호스트 사용자 정의 리소스 정의가 있는 경우 출력에 리소스가 생성된 날짜가 표시됩니다.
    • 리소스가 없는 경우 다음과 유사한 오류가 표시됩니다. 
    Error from server (NotFound): customresourcedefinitions.apiextensions.k8s.io "baremetalhosts.metal3.io" not found
    Copy to Clipboard Toggle word wrap

  2. 베어 메탈 호스트 사용자 정의 리소스 정의가 없는 경우 metal3.io_baremetalhosts.yaml 파일을 다운로드하고 다음 명령을 실행하여 리소스를 생성하여 콘텐츠를 적용합니다. 

    oc apply -f
    Copy to Clipboard Toggle word wrap
1.9.2.3. 프로비저닝 리소스 생성 또는 수정
링크 복사

중앙 인프라 관리 서비스를 활성화하려면 프로비저닝 리소스가 필요합니다.

  1. 다음 명령을 실행하여 프로비저닝 리소스가 있는지 확인합니다. 

    oc get provisioning
    Copy to Clipboard Toggle word wrap
    • 프로비저닝 리소스가 이미 있는 경우 프로비저닝 리소스를 수정합니다.
    • 프로비저닝 리소스가 없는 경우 리소스를 찾을 수 없음 오류가 표시됩니다. 계속해서 프로비저닝 리소스를 생성합니다.

  2. 프로비저닝 리소스를 수정합니다.

    프로비저닝 리소스가 이미 있는 경우 hub 클러스터가 다음 플랫폼 중 하나에 설치된 경우 리소스를 수정해야 합니다.

    • 베어 메탈
    • Red Hat OpenStack Platform
    • VMware vSphere

    • 사용자 프로비저닝 인프라(UPI) 방법 및 플랫폼은 None입니다.

      허브 클러스터가 다른 플랫폼에 설치된 경우 연결이 끊긴 환경에서 중앙 인프라 관리 활성화 또는 연결된 환경에서 중앙 인프라 관리 활성화에서 계속 진행하십시오.

      다음 명령을 실행하여 Bare Metal Operator가 모든 네임스페이스를 조사할 수 있도록 프로비저닝 리소스를 수정합니다. 

    oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'
    Copy to Clipboard Toggle word wrap

  3. 프로비저닝 리소스가 없는 경우 프로비저닝 리소스를 생성합니다.

    1. 다음 프로비저닝 리소스 YAML 파일을 생성합니다. 

      apiVersion: metal3.io/v1alpha1
kind: Provisioning
metadata:
  name: provisioning-configuration
spec:
  provisioningNetwork: "Disabled"
  watchAllNamespaces: true
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 콘텐츠를 적용합니다. 
    oc apply -f
    Copy to Clipboard Toggle word wrap
1.9.2.4. 연결이 끊긴 환경에서 중앙 인프라 관리 활성화
링크 복사

연결이 끊긴 환경에서 중앙 인프라 관리를 활성화하려면 다음 단계를 완료합니다.

  1. 인프라 Operator와 동일한 네임스페이스에 ConfigMap 을 생성하여 미러 레지스트리의 ca-bundle.crt 및 registries.conf 값을 지정합니다. 파일 ConfigMap 은 다음 예와 유사할 수 있습니다. 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: <mirror-config>
  namespace: multicluster-engine
  labels:
    app: assisted-service
data:
  ca-bundle.crt: |
    <certificate-content>
  registries.conf: |
    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
    [[registry]]
       prefix = ""
       location = "registry.redhat.io/multicluster-engine"
       mirror-by-digest-only = true
       [[registry.mirror]]
       location = "mirror.registry.com:5000/multicluster-engine"
    Copy to Clipboard Toggle word wrap

    참고: 다이제스트를 사용하여 릴리스 이미지가 지정되므로 mirror-by-digest-only 를 true 로 설정해야 합니다.

    unqualified-search-registries 목록의 레지스트리는 PUBLIC_CONTAINER_REGISTRIES 환경 변수의 인증 무시 목록에 자동으로 추가됩니다. 관리 클러스터의 풀 시크릿을 검증할 때 지정된 레지스트리는 인증이 필요하지 않습니다.

  2. 모든 osImage 요청과 함께 보낼 헤더 및 쿼리 매개변수를 나타내는 키 쌍을 작성합니다. 두 매개변수가 모두 필요하지 않은 경우 헤더 또는 쿼리 매개변수에만 대한 키 쌍을 작성합니다.

중요: 헤더 및 쿼리 매개변수는 HTTPS를 사용하는 경우에만 암호화됩니다. 보안 문제를 방지하려면 HTTPS를 사용해야 합니다.

  1. headers 라는 파일을 생성하고 다음 예제와 유사한 콘텐츠를 추가합니다. 

    {
  "Authorization": "Basic xyz"
}
    Copy to Clipboard Toggle word wrap

  2. query_params 라는 파일을 생성하고 다음 예와 유사한 콘텐츠를 추가합니다. 

    {
  "api_key": "myexampleapikey",
}
    Copy to Clipboard Toggle word wrap

    1. 다음 명령을 실행하여 생성한 매개변수 파일에서 시크릿을 생성합니다. 하나의 매개변수 파일만 생성한 경우 생성하지 않은 파일의 인수를 제거합니다. 

      oc create secret generic -n multicluster-engine os-images-http-auth --from-file=./query_params --from-file=./headers
      Copy to Clipboard Toggle word wrap

    2. 자체 서명 또는 타사 CA 인증서와 함께 HTTPS osImages 를 사용하려면 image-service-additional-ca ConfigMap 에 인증서를 추가합니다. 인증서를 생성하려면 다음 명령을 실행합니다. 

      oc -n multicluster-engine create configmap image-service-additional-ca --from-file=<file-name>
      Copy to Clipboard Toggle word wrap

    3. agent_service_config.yaml 파일에 다음 YAML 콘텐츠를 저장하여 AgentServiceConfig 사용자 지정 리소스를 생성합니다. 

      apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
 name: agent
spec:
  databaseStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <db_volume_size>
  filesystemStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <fs_volume_size>
  mirrorRegistryRef:
    name: <mirror_config>
      1 
      
  unauthenticatedRegistries:
    - <unauthenticated_registry>
      2 
      
  imageStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <img_volume_size>
      3 
      
  OSImageAdditionalParamsRef:
	    name: os-images-http-auth
  OSImageCACertRef:
    name: image-service-additional-ca
  osImages:
    - openshiftVersion: "<ocp_version>"
      4 
      
      version: "<ocp_release_version>"
      5 
      
      url: "<iso_url>"
      6 
      
      cpuArchitecture: "x86_64"
      Copy to Clipboard Toggle word wrap
    1
    mirror_config 를 미러 레지스트리 구성 세부 정보가 포함된 ConfigMap 의 이름으로 교체합니다.
    2
    인증이 필요하지 않은 미러 레지스트리를 사용하는 경우 선택적 unauthenticated_registry 매개변수를 포함합니다. 이 목록의 항목은 검증되지 않았거나 풀 시크릿에 항목이 있어야 합니다.
    3
    img_volume_size 를 imageStorage 필드의 볼륨 크기로 바꿉니다. 이 값은 기본 Red Hat Enterprise Linux CoreOS 이미지를 저장하기 위해 할당된 스토리지 양을 지정합니다. 최소 값은 10Gi 이지만 모범 사례에 대한 값은 특히 osImages 를 사용하여 제한된 세트를 정의하는 대신 기본 이미지 세트를 선택하는 경우 최소 50Gi 입니다. osImages 에 구성된 Red Hat Enterprise Linux CoreOS의 각 인스턴스에 대해 최소 2Gi 의 이미지 스토리지를 허용해야 합니다.
    4
    ocp_version 을 설치할 지원되는 OpenShift Container Platform 버전으로 교체합니다.
    5
    ocp_release_version 을 특정 설치 버전 (예: 49.83.202103251640-0 )으로 바꿉니다.
    6
    iso_url 을 ISO URL로 바꿉니다. rhoc 에서 ISO url 값을 찾을 수 있습니다.

자체 서명 또는 타사 CA 인증서가 있는 HTTPS osImages 를 사용하는 경우 OSImageCACertRef 사양의 인증서를 참조하십시오.

중요: 늦은 바인딩 기능을 사용하는 경우 클러스터를 생성할 때 사용하는 OpenShift Container Platform 릴리스 이미지가 동일해야 합니다.

assisted-service 및 assisted-image-service 배포를 확인하고 Pod가 준비되어 실행 중인지 확인하여 중앙 인프라 관리 서비스가 정상인지 확인할 수 있습니다.

1.9.2.5. 연결된 환경에서 중앙 인프라 관리 활성화
링크 복사

연결된 환경에서 중앙 인프라 관리를 활성화하려면 agent_service_config.yaml 파일에 다음 YAML 콘텐츠를 저장하여 AgentServiceConfig 사용자 지정 리소스를 생성합니다. 

apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
 name: agent
spec:
  databaseStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <db_volume_size>
1 

  filesystemStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <fs_volume_size>
2 

  imageStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <img_volume_size>
3
Copy to Clipboard Toggle word wrap
1
db_volume_size 를 databaseStorage 필드의 볼륨 크기(예: 10Gi )로 바꿉니다. 이 값은 클러스터의 데이터베이스 테이블 및 데이터베이스 뷰와 같은 파일을 저장하기 위해 할당된 스토리지 양을 지정합니다. 필요한 최소 값은 1Gi 입니다. 클러스터가 여러 개인 경우 더 높은 값을 사용해야 할 수 있습니다.
2
fs_volume_size 를 filesystemStorage 필드의 볼륨 크기로 바꿉니다(예: 지원되는 각 클러스터의 경우 200M, 지원되는 각 OpenShift Container Platform 버전에 대해 2-3Gi ). 필요한 최소 값은 1Gi 이지만 권장 값은 100Gi 이상이어야 합니다. 이 값은 클러스터의 로그, 매니페스트 및 kubeconfig 파일을 저장하기 위해 할당된 스토리지 양을 지정합니다. 클러스터가 여러 개인 경우 더 높은 값을 사용해야 할 수 있습니다.
3
img_volume_size 를 imageStorage 필드의 볼륨 크기로 바꿉니다. 이 값은 기본 Red Hat Enterprise Linux CoreOS 이미지를 저장하기 위해 할당된 스토리지 양을 지정합니다. 최소 값은 10Gi 이지만 모범 사례에 대한 값은 특히 osImages 를 사용하여 제한된 세트를 정의하는 대신 기본 이미지 세트를 선택하는 경우 최소 50Gi 입니다. osImages 에 구성된 Red Hat Enterprise Linux CoreOS의 각 인스턴스에 대해 최소 2Gi 의 이미지 스토리지를 허용해야 합니다.

osImages 에서 사용자 지정 이미지 세트를 정의하는 방법에 대한 자세한 내용은 연결이 끊긴 환경에서 중앙 인프라 관리 활성화를 참조하십시오.

중앙 인프라 관리 서비스가 구성되어 있습니다. assisted-service 및 assisted-image-service 배포를 확인하고 Pod가 준비되고 실행 중인지 확인하여 정상 상태인지 확인할 수 있습니다.

1.9.2.6. 지원 설치 관리자를 사용하여 FIPS 지원 클러스터 설치
링크 복사

FIPS 모드에 있는 지원되는 OpenShift Container Platform 클러스터를 설치할 때 설치 프로그램에 대해 Red Hat Enterprise Linux 버전을 지정하지 마십시오.

필수 액세스: AgentServiceConfig 및 AgentClusterInstall 리소스를 편집할 수 있는 권한이 있어야 합니다.

1.9.2.6.1. OpenShift Container Platform 클러스터 버전 4.15 및 이전 버전 설치
링크 복사
If you install a {ocp-short} cluster version 4.15 and earlier, complete the following steps to update the `AgentServiceConfig` resource:
Copy to Clipboard Toggle word wrap

  1. 다음 명령을 사용하여 관리 클러스터에 로그인합니다. 

    oc login
    Copy to Clipboard Toggle word wrap

  2. AgentServiceConfig 리소스에 agent-install.openshift.io/service-image-base: el8 주석을 추가합니다.

    AgentServiceConfig 리소스는 다음 YAML과 유사할 수 있습니다. 

    apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
  annotations:
    agent-install.openshift.io/service-image-base: el8
...
    Copy to Clipboard Toggle word wrap
1.9.2.6.2. OpenShift Container Platform 클러스터 버전 4.16 이상 설치
링크 복사

OpenShift Container Platform 클러스터 버전 4.16 이상을 설치하는 경우 다음 단계를 완료하여 AgentServiceConfig 리소스를 업데이트합니다.

  1. 다음 명령을 사용하여 관리 클러스터에 로그인합니다. 

    oc login
    Copy to Clipboard Toggle word wrap
  2. agent-install.openshift.io/service-image-base: el8 주석이 AgentServiceConfig 리소스에 있는 경우 주석을 제거합니다.
1.9.2.7. 추가 리소스
링크 복사

1.9.3. Amazon Web Services에서 중앙 인프라 관리 활성화
링크 복사

Amazon Web Services에서 Hub 클러스터를 실행하고 중앙 인프라 관리 서비스를 활성화하려면 중앙 인프라 관리 서비스를 활성화한 후 다음 단계를 완료합니다.

  1. hub 클러스터에 로그인했는지 확인하고 다음 명령을 실행하여 assisted-image-service 에 구성된 고유한 도메인을 찾습니다. 

    oc get routes --all-namespaces | grep assisted-image-service
    Copy to Clipboard Toggle word wrap

    도메인은 다음 예와 유사할 수 있습니다. assisted-image-service-multicluster-engine.apps.<yourdomain>.com

  2. hub 클러스터에 로그인했는지 확인하고 NLB type 매개변수를 사용하여 고유한 도메인으로 새 IngressController 를 생성합니다. 다음 예제를 참조하십시오. 

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: ingress-controller-with-nlb
  namespace: openshift-ingress-operator
spec:
  domain: nlb-apps.<domain>.com
  routeSelector:
      matchLabels:
        router-type: nlb
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External
      providerParameters:
        type: AWS
        aws:
          type: NLB
    Copy to Clipboard Toggle word wrap
  3. nlb-apps.< domain >.com에서 <your domain >을 <yourdomain>으로 교체하여 IngressController 의 domain 매개변수에 < yourdomain >을 추가합니다.

  4. 다음 명령을 실행하여 새 IngressController 를 적용합니다. 

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

  5. 다음 단계를 완료하여 새 IngressController 의 spec.domain 매개변수 값이 기존 IngressController 와 충돌하지 않는지 확인합니다.

    1. 다음 명령을 실행하여 모든 IngressController 를 나열합니다. 

      oc get ingresscontroller -n openshift-ingress-operator
      Copy to Clipboard Toggle word wrap

    2. 방금 생성한 ingress-controller-with-nlb 를 제외하고 각 IngressController 에서 다음 명령을 실행합니다. 

      oc edit ingresscontroller <name> -n openshift-ingress-operator
      Copy to Clipboard Toggle word wrap

      spec.domain 보고서가 없는 경우 nlb-apps.<domain>.com을 제외한 클러스터에 노출된 모든 경로와 일치하는 기본 도메인 을 추가합니다.

      spec.domain 보고서가 제공된 경우 nlb-apps.<domain>.com 경로가 지정된 범위에서 제외되었는지 확인합니다.

  6. 다음 명령을 실행하여 nlb-apps 위치를 사용하도록 assisted-image-service 경로를 편집합니다. 

    oc edit route assisted-image-service -n <namespace>
    Copy to Clipboard Toggle word wrap

    기본 네임스페이스는 다중 클러스터 엔진 Operator를 설치한 위치입니다.

  7. assisted-image-service 경로에 다음 행을 추가합니다. 

    metadata:
  labels:
    router-type: nlb
  name: assisted-image-service
    Copy to Clipboard Toggle word wrap

  8. assisted-image-service 경로에서 spec.host 의 URL 값을 찾습니다. URL은 다음 예와 유사할 수 있습니다. 

    assisted-image-service-multicluster-engine.apps.<yourdomain>.com
    Copy to Clipboard Toggle word wrap
  9. 새 IngressController 에 구성된 도메인과 일치하도록 URL의 앱을 nlb- apps 로 교체합니다.

  10. Amazon Web Services에서 중앙 인프라 관리 서비스가 활성화되어 있는지 확인하려면 다음 명령을 실행하여 Pod가 정상 상태인지 확인합니다. 

    oc get pods -n multicluster-engine | grep assist
    Copy to Clipboard Toggle word wrap
  11. 새 호스트 인벤토리를 생성하고 다운로드 URL이 새 nlb-apps URL을 사용하는지 확인합니다.

1.9.4. 콘솔을 사용하여 호스트 인벤토리 생성
링크 복사

호스트 인벤토리(인프라 환경)를 생성하여 OpenShift Container Platform 클러스터를 설치할 수 있는 물리적 또는 가상 머신을 검색할 수 있습니다.

1.9.4.1. 사전 요구 사항
링크 복사
  • 중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
1.9.4.2. 호스트 인벤토리 생성
링크 복사

콘솔을 사용하여 호스트 인벤토리를 생성하려면 다음 단계를 완료합니다.

  1. 콘솔에서 인프라 > 호스트 인벤토리 로 이동하여 인프라 환경 생성 을 클릭합니다.

  2. 호스트 인벤토리 설정에 다음 정보를 추가합니다.

    이름
    인프라 환경의 고유 이름입니다. 콘솔을 사용하여 인프라 환경을 생성하면 선택한 이름으로 InfraEnv 리소스의 새 네임스페이스도 생성됩니다. 명령줄 인터페이스를 사용하여 InfraEnv 리소스를 생성하고 콘솔에서 리소스를 모니터링하려면 네임스페이스와 InfraEnv 에 동일한 이름을 사용합니다.
    네트워크 유형
    인프라 환경에 추가하는 호스트가 DHCP 또는 정적 네트워킹을 사용하는지 여부를 지정합니다. 정적 네트워킹 구성에는 추가 단계가 필요합니다.
    위치
    호스트의 지리적 위치를 지정합니다. 지리적 위치는 호스트가 있는 데이터 센터를 정의하는 데 사용할 수 있습니다.
    라벨
    이 인프라 환경에서 검색된 호스트에 레이블을 추가할 수 있는 선택적 필드입니다. 지정된 위치가 레이블 목록에 자동으로 추가됩니다.
    인프라 공급자 인증 정보
    인프라 공급자 인증 정보를 선택하면 풀 시크릿 및 SSH 공개 키 필드에 인증 정보 정보가 자동으로 채워집니다. 자세한 내용은 온-프레미스 환경에 대한 인증 정보 만들기 를 참조하십시오.
    풀 시크릿
    OpenShift Container Platform 풀 시크릿을 사용하여 OpenShift Container Platform 리소스에 액세스할 수 있습니다. 인프라 공급자 인증 정보를 선택한 경우 이 필드가 자동으로 채워집니다.
    SSH 공개 키

    호스트와의 보안 통신을 활성화하는 SSH 키입니다. 문제 해결을 위해 호스트에 연결하는 데 사용할 수 있습니다. 클러스터를 설치한 후에는 더 이상 SSH 키를 사용하여 호스트에 연결할 수 없습니다. 키는 일반적으로 id_rsa.pub 파일에 있습니다. 기본 파일 경로는 ~/.ssh/id_rsa.pub 입니다. SSH 공개 키 값이 포함된 인프라 공급자 인증 정보를 선택한 경우 이 필드가 자동으로 채워집니다.

    호스트에 프록시 설정을 활성화하려면 활성화할 설정을 선택하고 다음 정보를 입력합니다.

    HTTP 프록시 URL
    HTTP 요청에 대한 프록시의 URL입니다.
    HTTPS 프록시 URL
    HTTP 요청에 대한 프록시의 URL입니다. URL은 HTTP로 시작해야 합니다. HTTPS는 지원되지 않습니다. 값을 지정하지 않으면 HTTP 프록시 URL이 기본적으로 HTTP 및 HTTPS 연결에 사용됩니다.
    프록시 도메인 없음
    프록시를 사용하지 않으려는 쉼표로 구분된 도메인 목록입니다. 마침표(.)로 도메인 이름을 시작하여 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표(*)를 추가합니다. 선택적으로 NTP 풀 또는 서버의 쉼표로 구분된 IP 또는 도메인 이름 목록을 제공하여 고유한 NTP(Network Time Protocol) 소스를 추가합니다.

콘솔에서 사용할 수 없는 고급 구성 옵션이 필요한 경우 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성을 계속합니다.

고급 구성 옵션이 필요하지 않은 경우 정적 네트워킹을 구성하여 계속해서 인프라 환경에 호스트를 추가할 수 있습니다.

1.9.4.3. 호스트 인벤토리에 액세스
링크 복사

호스트 인벤토리에 액세스하려면 콘솔에서 인프라 > 호스트 인벤토리 를 선택합니다. 목록에서 인프라 환경을 선택하여 세부 정보 및 호스트를 확인합니다.

1.9.4.4. 추가 리소스
링크 복사

베어 메탈에서 호스팅된 컨트롤 플레인을 구성하는 프로세스의 일부로 호스트 인벤토리를 생성한 경우 다음 절차를 완료합니다.

1.9.5. 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성
링크 복사

호스트 인벤토리(인프라 환경)를 생성하여 OpenShift Container Platform 클러스터를 설치할 수 있는 물리적 또는 가상 머신을 검색할 수 있습니다. 자동화된 배포를 위해 콘솔 대신 명령행 인터페이스를 사용하거나 다음 고급 구성 옵션에 사용합니다.

  • 검색된 호스트를 기존 클러스터 정의에 자동으로 바인딩
  • Discovery Image의 ignition 구성 덮어쓰기
  • iPXE 동작 제어
  • Discovery Image의 커널 인수 수정
  • 검색 단계에서 호스트가 신뢰할 수 있는 추가 인증서 전달
  • 최신 버전의 기본 옵션이 아닌 테스트를 위해 부팅할 Red Hat CoreOS 버전을 선택합니다.
1.9.5.1. 사전 요구 사항
링크 복사

중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.

1.9.5.2. 호스트 인벤토리 생성
링크 복사

명령줄 인터페이스를 사용하여 호스트 인벤토리(인프라 환경)를 생성하려면 다음 단계를 완료합니다.

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

    oc login
    Copy to Clipboard Toggle word wrap

  2. 리소스의 네임스페이스를 생성합니다.

    1. namespace.yaml 이라는 파일을 생성하고 다음 콘텐츠를 추가합니다. 

      apiVersion: v1
kind: Namespace
metadata:
  name: <your_namespace>
      1
      Copy to Clipboard Toggle word wrap
      1
      네임스페이스에서 동일한 이름을 사용하여 콘솔에서 인벤토리를 모니터링합니다.

    2. 다음 명령을 실행하여 YAML 콘텐츠를 적용합니다. 

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

  3. OpenShift Container Platform 풀 보안이 포함된 Secret 사용자 정의 리소스를 생성합니다.

    1. pull-secret.yaml 파일을 생성하고 다음 콘텐츠를 추가합니다. 

      apiVersion: v1
kind: Secret
type: kubernetes.io/dockerconfigjson
metadata:
  name: pull-secret
      1 
      
  namespace: <your_namespace>
stringData:
  .dockerconfigjson: <your_pull_secret>
      2
      Copy to Clipboard Toggle word wrap
      1
      이름을 추가하십시오.
      2
      풀 시크릿을 추가합니다.

    2. 다음 명령을 실행하여 YAML 콘텐츠를 적용합니다. 

      oc apply -f pull-secret.yaml
      Copy to Clipboard Toggle word wrap

  4. 인프라 환경을 생성합니다.

    1. infra-env.yaml 파일을 생성하고 다음 콘텐츠를 추가합니다. 필요한 경우 값을 바꿉니다. 

      apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: myinfraenv
  namespace: <your_namespace>
spec:
  proxy:
    httpProxy: <http://user:password@ipaddr:port>
    httpsProxy: <http://user:password@ipaddr:port>
    noProxy:
  additionalNTPSources:
  sshAuthorizedKey:
  pullSecretRef:
    name: <name>
  agentLabels:
    <key>: <value>
  nmStateConfigLabelSelector:
    matchLabels:
      <key>: <value>
  clusterRef:
    name: <cluster_name>
    namespace: <project_name>
  ignitionConfigOverride: '{"ignition": {"version": "3.1.0"}, …}'
  cpuArchitecture: x86_64
  ipxeScriptType: DiscoveryImageAlways
  kernelArguments:
    - operation: append
      value: audit=0
  additionalTrustBundle: <bundle>
  osImageVersion: <version>
  ImageType: <type>
      Copy to Clipboard Toggle word wrap

InfraEnv 표에서 다음 필드 설명을 참조하십시오.

Expand
표 1.11. InfraEnv 필드 테이블
필드선택 사항 또는 필수설명

proxy

선택 사항

InfraEnv 리소스를 사용하는 에이전트 및 클러스터의 프록시 설정을 정의합니다. 프록시 값을 설정하지 않으면 에이전트가 프록시 를 사용하도록 구성되지 않습니다.

httpProxy

선택 사항

HTTP 요청에 대한 프록시의 URL입니다. URL은 http 로 시작해야 합니다. HTTPS는 지원되지 않습니다.

httpsProxy

선택 사항

HTTP 요청에 대한 프록시의 URL입니다. URL은 http 로 시작해야 합니다. HTTPS는 지원되지 않습니다.

noProxy

선택 사항

프록시를 사용하지 않으려는 쉼표로 구분된 도메인 및 CIDR 목록입니다.

추가 NTPSources

선택 사항

모든 호스트에 추가할 NTP(Network Time Protocol) 소스(hostname 또는 IP) 목록입니다. DHCP와 같은 다른 옵션을 사용하여 구성된 NTP 소스에 추가됩니다.

sshAuthorizedKey

선택 사항

검색 단계에서 디버깅에 사용할 수 있도록 모든 호스트에 추가된 SSH 공개 키입니다. 검색 단계는 호스트가 검색 이미지를 부팅하는 단계입니다.

name

필수 항목

풀 보안이 포함된 Kubernetes 시크릿의 이름입니다.

agentLabels

선택 사항

InfraEnv 로 검색되는 호스트를 나타내는 에이전트 리소스에 자동으로 추가되는 라벨입니다. 키와 값을 추가해야 합니다.

nmStateConfigLabelSelector

선택 사항

호스트의 고정 IP, 브리지 및 본딩과 같은 고급 네트워크 구성을 통합합니다. 호스트 네트워크 구성은 선택한 라벨을 사용하여 하나 이상의 NMStateConfig 리소스에 지정됩니다. nmStateConfigLabelSelector 속성은 선택한 라벨과 일치하는 Kubernetes 라벨 선택기입니다. 이 라벨 선택기와 일치하는 모든 NMStateConfig 라벨의 네트워크 구성은 Discovery Image에 포함됩니다. 부팅 시 각 호스트를 네트워크 인터페이스와 비교하고 적절한 구성을 적용합니다. 고급 네트워크 구성에 대한 자세한 내용은 인프라 환경에 대한 고급 네트워킹 구성을 참조하십시오.

clusterRef

선택 사항

독립 실행형 온-프레미스 클러스터를 설명하는 기존 ClusterDeployment 리소스를 참조합니다. 기본적으로 설정되지 않습니다. clusterRef 가 설정되지 않은 경우 호스트는 나중에 하나 이상의 클러스터에 바인딩될 수 있습니다. 한 클러스터에서 호스트를 제거하고 다른 클러스터에 추가할 수 있습니다. clusterRef 가 설정되면 InfraEnv 로 검색된 모든 호스트가 지정된 클러스터에 자동으로 바인딩됩니다. 클러스터가 아직 설치되지 않은 경우 검색된 모든 호스트가 설치에 포함됩니다. 클러스터가 이미 설치되어 있으면 검색된 모든 호스트가 추가됩니다.

ignitionConfigOverride

선택 사항

Red Hat CoreOS 라이브 이미지의 ignition 구성(예: 파일 추가)을 수정합니다. 필요한 경우에만 ignitionConfigOverride 를 사용하십시오. 클러스터 버전에 관계없이 ignition 버전 3.1.0을 사용해야 합니다.

cpuArchitecture

선택 사항

지원되는 CPU 아키텍처(x86_64, aarch64, ppc64le 또는 s390x) 중 하나를 선택합니다. 기본값은 x86_64입니다.

ipxeScriptType

선택 사항

DiscoveryImageAlways 의 기본값으로 설정되고 iPXE를 사용하여 부팅할 때 이미지 서비스가 항상 iPXE 스크립트를 제공하도록 합니다. 결과적으로 호스트는 네트워크 검색 이미지에서 부팅됩니다. 값을 BootOrderControl 으로 설정하면 이미지 서비스에서 호스트 상태에 따라 iPXE 스크립트를 반환할 시기를 결정하므로 호스트가 프로비저닝되고 클러스터의 일부인 경우 호스트에서 부팅됩니다.

kernelArguments

선택 사항

Discovery Image가 부팅될 때 에 대한 커널 인수를 수정할 수 있습니다. 작업에 사용 가능한 값은 추가,교체 또는 삭제 입니다.

additionalTrustBundle

선택 사항

PEM 인코딩 X.509 인증서 번들, 일반적으로 호스트가 다시 암호화하는 MITTM(man-in-the-middle) 프록시가 있는 네트워크에 있거나 호스트가 컨테이너 이미지 레지스트리와 같은 다른 목적으로 인증서를 신뢰해야 하는 경우 필요합니다. InfraEnv 에서 검색된 호스트는 이 번들에서 인증서를 신뢰합니다. InfraEnv 에서 검색된 호스트에서 생성된 클러스터도 이 번들의 인증서를 신뢰합니다.

osImageVersion

선택 사항

InfraEnv 에 사용할 Red Hat CoreOS 이미지 버전입니다. 버전이 AgentServiceConfig.spec.osImages 또는 기본 OS 이미지 목록에 지정된 OS 이미지를 참조하는지 확인합니다. 각 릴리스에는 특정 Red Hat CoreOS 이미지 버전 세트가 있습니다. OSImageVersion 은 OS 이미지 목록의 OpenShift Container Platform 버전과 일치해야 합니다. OSImageVersion 및 ClusterRef 를 동시에 지정할 수 없습니다. 기본적으로 존재하지 않는 다른 버전의 Red Hat CoreOS 이미지를 사용하려면 AgentServiceConfig.spec.osImages 에서 지정하여 버전을 수동으로 추가해야 합니다. 버전 추가에 대한 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.

ImageType

선택 사항

다운로드할 ISO 파일 유형을 선택합니다. 가능한 옵션은 최소-iso 또는 full-iso 입니다. ISO 유형을 지정하지 않으면 기본적으로 최소 ISO가 사용됩니다. 최소 ISO에는 루트 파일 시스템인 RootFS 가 포함되어 있지 않습니다. 최소 ISO를 선택하면 나중에 RootFS 가 다운로드됩니다.

  1. 다음 명령을 실행하여 YAML 콘텐츠를 적용합니다. 

    oc apply -f infra-env.yaml
    Copy to Clipboard Toggle word wrap

  2. 호스트 인벤토리가 생성되었는지 확인하려면 다음 명령을 사용하여 상태를 확인합니다. 

    oc describe infraenv myinfraenv -n <your_namespace>
    Copy to Clipboard Toggle word wrap

다음 주요 속성 목록을 참조하십시오.

  • conditions: 이미지가 성공적으로 생성되었는지를 나타내는 표준 Kubernetes 상태입니다.
  • isoDownloadURL: Discovery Image를 다운로드할 URL입니다.
  • createdTime: 이미지가 마지막으로 생성된 시간입니다. InfraEnv 를 수정하는 경우 새 이미지를 다운로드하기 전에 타임스탬프가 업데이트되었는지 확인합니다.

참고: InfraEnv 리소스를 수정하는 경우, createdTime 속성을 확인하여 InfraEnv 에서 새 Discovery Image를 생성했는지 확인합니다. 이미 호스트를 부팅한 경우 최신 Discovery Image를 사용하여 다시 부팅합니다.

필요한 경우 정적 네트워킹을 구성하고 인프라 환경에 호스트를 추가할 수 있습니다.

1.9.5.3. 추가 리소스
링크 복사

1.9.6. 인프라 환경에 대한 고급 네트워킹 구성
링크 복사

단일 인터페이스에서 DHCP 이외의 네트워킹이 필요한 호스트의 경우 고급 네트워킹을 구성해야 합니다. 필수 구성에는 하나 이상의 호스트에 대한 네트워킹을 설명하는 NMStateConfig 리소스의 인스턴스 생성이 포함됩니다.

각 NMStateConfig 리소스에는 InfraEnv 리소스의 nmStateConfigLabelSelector 와 일치하는 레이블이 포함되어야 합니다. nmStateConfigLabelSelector 에 대한 자세한 내용은 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성 을 참조하십시오.

Discovery Image에는 참조된 모든 NMStateConfig 리소스에 정의된 네트워크 구성이 포함되어 있습니다. 부팅 후 각 호스트는 각 구성을 네트워크 인터페이스와 비교하고 적절한 구성을 적용합니다.

1.9.6.1. 사전 요구 사항
링크 복사
1.9.6.2. 명령줄 인터페이스를 사용하여 고급 네트워킹 구성
링크 복사

명령줄 인터페이스를 사용하여 인프라 환경에 대한 고급 네트워킹을 구성하려면 다음 단계를 완료합니다.

  1. nmstateconfig.yaml 이라는 파일을 생성하고 다음 템플릿과 유사한 콘텐츠를 추가합니다. 필요한 경우 값을 바꿉니다. 

    apiVersion: agent-install.openshift.io/v1beta1
kind: NMStateConfig
metadata:
  name: mynmstateconfig
  namespace: <your-infraenv-namespace>
  labels:
    some-key: <some-value>
spec:
  config:
    interfaces:
      - name: eth0
        type: ethernet
        state: up
        mac-address: 02:00:00:80:12:14
        ipv4:
          enabled: true
          address:
            - ip: 192.168.111.30
              prefix-length: 24
          dhcp: false
      - name: eth1
        type: ethernet
        state: up
        mac-address: 02:00:00:80:12:15
        ipv4:
          enabled: true
          address:
            - ip: 192.168.140.30
              prefix-length: 24
          dhcp: false
    dns-resolver:
      config:
        server:
          - 192.168.126.1
    routes:
      config:
        - destination: 0.0.0.0/0
          next-hop-address: 192.168.111.1
          next-hop-interface: eth1
          table-id: 254
        - destination: 0.0.0.0/0
          next-hop-address: 192.168.140.1
          next-hop-interface: eth1
          table-id: 254
  interfaces:
    - name: "eth0"
      macAddress: "02:00:00:80:12:14"
    - name: "eth1"
      macAddress: "02:00:00:80:12:15"
    Copy to Clipboard Toggle word wrap
Expand
표 1.12. NMStateConfig 필드 테이블
필드선택 사항 또는 필수설명

name

필수 항목

구성 중인 호스트 또는 호스트와 관련된 이름을 사용합니다.

네임스페이스

필수 항목

네임스페이스는 InfraEnv 리소스의 네임스페이스와 일치해야 합니다.

some-key

필수 항목

InfraEnv 리소스에서 nmStateConfigLabelSelector 와 일치하는 하나 이상의 레이블을 추가합니다.

config

선택 사항

NMstate 형식의 네트워크 설정을 설명합니다. 형식 사양 및 추가 예제는 선언 네트워크 API 를 참조하십시오. 구성은 호스트당 하나의 NMStateConfig 리소스가 있거나 단일 NMStateConfig 리소스에서 여러 호스트의 인터페이스를 설명할 수 있는 단일 호스트에도 적용할 수 있습니다.

인터페이스

선택 사항

지정된 NMstate 구성 및 호스트에 있는 MAC 주소에 있는 인터페이스 이름 간 매핑에 대해 설명합니다. 매핑에서 호스트에 있는 물리적 인터페이스를 사용하는지 확인합니다. 예를 들어 NMState 구성이 본딩 또는 VLAN을 정의하는 경우 매핑에는 상위 인터페이스에 대한 항목만 포함됩니다. 매핑의 용도는 다음과 같습니다. * 호스트의 인터페이스 이름과 일치하지 않는 구성에서 인터페이스 이름을 사용할 수 있습니다. 운영 체제가 인터페이스 이름을 선택하고 예측할 수 없는 인터페이스 이름을 선택하기 때문에 이 유용할 수 있습니다. * 부팅 후 어떤 MAC 주소를 찾고 올바른 NMstate 설정을 적용합니다.

참고: 이미지 서비스는 InfraEnv 속성을 업데이트하거나 레이블 선택기와 일치하는 NMStateConfig 리소스를 변경할 때 새 이미지를 자동으로 생성합니다. InfraEnv 리소스를 생성한 후 NMStateConfig 리소스를 추가하는 경우 InfraEnv에서 InfraEnv 에서 createdTime 속성을 확인하여 새 Discovery Image를 생성해야 합니다. 이미 호스트를 부팅한 경우 최신 Discovery Image를 사용하여 다시 부팅합니다.

  1. 다음 명령을 실행하여 YAML 콘텐츠를 적용합니다. 

    oc apply -f nmstateconfig.yaml
    Copy to Clipboard Toggle word wrap
1.9.6.3. 추가 리소스
링크 복사

1.9.7. Discovery Image를 사용하여 호스트 인벤토리에 호스트 추가
링크 복사

호스트 인벤토리(인프라 환경)를 생성한 후 호스트를 검색하여 인벤토리에 추가할 수 있습니다.

인벤토리에 호스트를 추가하려면 ISO 파일을 다운로드하여 각 서버에 연결할 방법을 선택합니다. 예를 들어 가상 미디어를 사용하거나 ISO 파일을 USB 드라이브에 작성하여 ISO 파일을 다운로드할 수 있습니다.

중요: 설치가 실패하지 않도록 하려면 설치 프로세스 중에 장치에 Discovery ISO 미디어를 계속 연결하고 각 호스트를 한 번에 부팅하도록 설정합니다.

1.9.7.1. 사전 요구 사항
링크 복사
1.9.7.2. 콘솔을 사용하여 호스트 추가
링크 복사

다음 단계를 완료하여 ISO 파일을 다운로드합니다.

  1. 콘솔에서 Infrastructure > Host inventory 를 선택합니다.
  2. 목록에서 인프라 환경을 선택합니다.
  3. 호스트 추가를 클릭하고 Discovery ISO 사용을 선택합니다.
  4. 최소 이미지 파일 또는 전체 이미지 파일을 선택합니다.

  5. Discovery ISO 생성을 클릭합니다.

    참고: 부팅된 호스트가 호스트 인벤토리 테이블에 나타납니다. 호스트가 표시되는 데 몇 분이 걸릴 수 있습니다.

  6. 사용할 수 있도록 각 호스트를 승인합니다. 작업을 클릭하고 승인을 선택하여 인벤토리 테이블에서 호스트를 선택할 수 있습니다.
1.9.7.3. 명령줄 인터페이스를 사용하여 호스트 추가
링크 복사

isoDownloadURL 속성에서 ISO 파일을 다운로드할 URL은 InfraEnv 리소스의 상태에 있습니다. InfraEnv 리소스에 대한 자세한 내용은 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성 을 참조하십시오.

부팅된 각 호스트는 동일한 네임스페이스에 에이전트 리소스를 생성합니다.

  1. 다음 명령을 실행하여 InfraEnv 사용자 정의 리소스에서 다운로드 URL을 확인합니다. 

    oc get infraenv -n <infra env namespace> <infra env name> -o jsonpath='{.status.isoDownloadURL}'
    Copy to Clipboard Toggle word wrap

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

    https://assisted-image-service-assisted-installer.apps.example-acm-hub.com/byapikey/eyJhbGciOiJFUzI1NiIsInC93XVCJ9.eyJpbmZyYV9lbnZfaWQcTA0Y38sWVjYi02MTA0LTQ4NDMtODasdkOGIxYTZkZGM5ZTUifQ.3ydTpHaXJmTasd7uDp2NvGUFRKin3Z9Qct3lvDky1N-5zj3KsRePhAM48aUccBqmucGt3g/4.17/x86_64/minimal.iso
    Copy to Clipboard Toggle word wrap

    참고: 기본적으로 최소 ISO가 제공됩니다. InfraEnv 리소스에서 ImageType 을 full-iso 로 설정하여 전체 ISO를 지정할 수 있습니다. 자세한 내용은 추가 리소스 섹션에서 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성 을 참조하십시오.

  2. URL을 사용하여 ISO 파일을 다운로드하고 ISO 파일로 호스트를 부팅합니다.

    다음으로 각 호스트를 승인해야 합니다. 다음 절차를 참조하십시오.

  3. 다음 명령을 실행하여 모든 에이전트 를 나열합니다. 

    oc get agent -n <infra env namespace>
    Copy to Clipboard Toggle word wrap

    다음 출력과 유사한 출력이 표시됩니다. 

    NAME                                   CLUSTER   APPROVED   ROLE          STAGE
24a92a6f-ea35-4d6f-9579-8f04c0d3591e             false      auto-assign
    Copy to Clipboard Toggle word wrap

  4. 목록에서 모든 에이전트 를 승인하고 잘못된 승인 상태로 승인합니다. 다음 명령을 실행합니다. 

    oc patch agent -n <infra env namespace> <agent name> -p '{"spec":{"approved":true}}' --type merge
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 승인 상태를 확인합니다. 

    oc get agent -n <infra env namespace>
    Copy to Clipboard Toggle word wrap

    true 값을 사용하여 다음 출력과 유사한 출력이 표시됩니다. 

    NAME                                   CLUSTER   APPROVED   ROLE          STAGE
173e3a84-88e2-4fe1-967f-1a9242503bec             true       auto-assign
    Copy to Clipboard Toggle word wrap
1.9.7.4. HTTP 또는 HTTPS로 iPXE 아티팩트 호스팅
링크 복사

AgentServiceConfig 사용자 정의 리소스에서 spec.iPXEHTTPRoute 필드를 편집하여 iPXE 아티팩트를 호스팅하는 방법을 변경할 수 있습니다.

iPXE 아티팩트에 HTTP를 사용하도록 활성화된 필드를 설정합니다.

iPXE 아티팩트에 HTTPS를 사용하도록 필드를 disabled 로 설정합니다.

기본값은 disabled 입니다. spec.iPXEHTTPRoute 필드가 enabled 로 설정된 다음 예제를 참조하십시오. 

apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
  name: agent
spec:
  iPXEHTTPRoute: enabled
Copy to Clipboard Toggle word wrap

값을 enabled 로 설정하면 다음 끝점이 HTTP를 통해 노출됩니다.

  • assisted-service 의 API/assisted-installer/v2/infra-envs/<id>/downloads/files?file_name=ipxe-script
  • assisted-image-service의 boot -artifacts/ 및 이미지/<infra-env-id>/pxe-initrd
1.9.7.5. 추가 리소스
링크 복사

1.9.8. 호스트 인벤토리에 베어 메탈 호스트 자동 추가
링크 복사

인프라 환경을 생성한 후 호스트를 검색하여 호스트 인벤토리에 추가할 수 있습니다. 베어 메탈 Operator가 각 베어 메탈 호스트의 BMC(Baseboard Management Controller)와 통신하도록 하여 인프라 환경의 검색 이미지 부팅을 자동화할 수 있습니다. 각 호스트에 대한 BareMetalHost 리소스 및 관련 BMC 시크릿을 생성합니다. 자동화는 인프라 환경을 참조하는 BareMetalHost 의 레이블로 설정됩니다.

자동화는 다음 작업을 수행합니다.

  • 인프라 환경에서 표시하는 Discovery Image를 사용하여 각 베어 메탈 호스트 부팅
  • 인프라 환경 또는 관련 네트워크 구성이 업데이트되는 경우 각 호스트를 최신 검색 이미지로 재부팅
  • 검색 시 각 에이전트 리소스를 해당 BareMetalHost 리소스와 연결합니다.
  • 호스트 이름, 역할 및 설치 디스크와 같은 BareMetalHost 의 정보를 기반으로 에이전트 리소스 속성 업데이트
  • 클러스터 노드로 사용할 에이전트 승인
1.9.8.1. 사전 요구 사항
링크 복사
1.9.8.2. 콘솔을 사용하여 베어 메탈 호스트 추가
링크 복사

콘솔을 사용하여 호스트 인벤토리에 베어 메탈 호스트를 자동으로 추가하려면 다음 단계를 완료합니다.

  1. 콘솔에서 Infrastructure > Host inventory 를 선택합니다.
  2. 목록에서 인프라 환경을 선택합니다.
  3. 호스트 추가를 클릭하고 BMC 양식으로 를 선택합니다.
  4. 필요한 정보를 추가하고 생성 을 클릭합니다.

BMC 주소 지정에 대한 자세한 내용은 추가 리소스 섹션의 BMC 주소 지정을 참조하십시오.

1.9.8.3. 명령줄 인터페이스를 사용하여 베어 메탈 호스트 추가
링크 복사

명령줄 인터페이스를 사용하여 호스트 인벤토리에 베어 메탈 호스트를 자동으로 추가하려면 다음 단계를 완료합니다.

  1. 다음 YAML 콘텐츠를 적용하고 필요한 경우 값을 교체하여 BMC 시크릿을 생성합니다. 

    apiVersion: v1
kind: Secret
metadata:
  name: <bmc-secret-name>
  namespace: <your_infraenv_namespace>
    1 
    
type: Opaque
data:
  username: <username>
  password: <password>
    Copy to Clipboard Toggle word wrap
    1
    네임스페이스는 InfraEnv 의 네임스페이스와 동일해야 합니다.

  2. 다음 YAML 콘텐츠를 적용하고 필요한 경우 값을 교체하여 베어 메탈 호스트를 생성합니다. 

    apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: <bmh-name>
  namespace: <your-infraenv-namespace>
    1 
    
  annotations:
    inspect.metal3.io: disabled
    bmac.agent-install.openshift.io/hostname: <hostname>
    2 
    
    bmac.agent-install.openshift.io/role: <role>
    3 
    
  labels:
    infraenvs.agent-install.openshift.io: <your-infraenv>
    4 
    
spec:
  online: true
  automatedCleaningMode: disabled
    5 
    
  bootMACAddress: <your-mac-address>
    6 
    
  bmc:
    address: <machine-address>
    7 
    
    credentialsName: <bmc-secret-name>
    8 
    
  rootDeviceHints:
    deviceName: /dev/sda
    9
    Copy to Clipboard Toggle word wrap
    1
    네임스페이스는 InfraEnv 의 네임스페이스와 동일해야 합니다.
    2
    선택 사항: 호스트 이름으로 바꿉니다.
    3
    선택 사항: 가능한 값은 master 또는 worker 입니다.
    4
    이름은 InfrEnv 의 이름과 일치해야 하며 동일한 네임스페이스에 있어야 합니다.
    5
    값을 설정하지 않으면 메타데이터 값이 자동으로 사용됩니다.
    6
    MAC 주소가 호스트 인터페이스 중 하나의 MAC 주소와 일치하는지 확인합니다.
    7
    BMC 주소를 사용합니다. 자세한 내용은 추가 리소스 섹션의 대역 외 관리 IP 주소에 대한 포트 액세스 및 BMC 주소 지정을 참조하십시오.
    8
    credentialsName 값이 생성한 BMC 시크릿의 이름과 일치하는지 확인합니다.
    9
    선택 사항: 설치 디스크를 선택합니다. 사용 가능한 루트 장치 팁은 BareMetalHost 사양 을 참조하십시오. 호스트를 검색 이미지로 부팅하고 해당 에이전트 리소스가 생성되면 이 팁에 따라 설치 디스크가 설정됩니다.

호스트를 켜면 이미지가 다운로드되기 시작합니다. 이 작업은 몇 분 정도 걸릴 수 있습니다. 호스트가 검색되면 에이전트 사용자 지정 리소스가 자동으로 생성됩니다.

1.9.8.4. 명령줄 인터페이스를 사용하여 관리형 클러스터 노드 제거
링크 복사

관리형 클러스터에서 관리형 클러스터 노드를 제거하려면 지원되는 OpenShift Container Platform 버전에서 실행 중인 허브 클러스터가 필요합니다. 노드를 부팅하는 데 필요한 정적 네트워킹 구성을 사용할 수 있어야 합니다. 에이전트 및 베어 메탈 호스트를 삭제할 때 NMStateConfig 리소스를 삭제하지 마십시오.

1.9.8.4.1. 베어 메탈 호스트를 사용하여 관리형 클러스터 노드 제거
링크 복사

허브 클러스터에 베어 메탈 호스트가 있고 관리 클러스터에서 관리 클러스터 노드를 제거하려면 다음 단계를 완료합니다.

  1. 삭제하려는 노드의 BareMetalHost 리소스에 다음 주석을 추가합니다. 

    bmac.agent-install.openshift.io/remove-agent-and-node-on-delete: true
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 BareMetalHost 리소스를 삭제합니다. & lt;bmh-name& gt;을 BareMetalHost 의 이름으로 바꿉니다. 

    oc delete bmh <bmh-name>
    Copy to Clipboard Toggle word wrap
1.9.8.4.2. 베어 메탈 호스트 없이 관리형 클러스터 노드 제거
링크 복사

허브 클러스터에 베어 메탈 호스트가 없고 관리 클러스터에서 관리 클러스터 노드를 제거하려면 에이전트 사양에서 clusterDeploymentName 필드를 제거하여 에이전트를 바인딩 해제하거나 제거 중인 노드에 해당하는 에이전트 사용자 정의 리소스를 삭제할 수 있습니다.

hub 클러스터에서 에이전트 리소스를 삭제하지만 관리 클러스터에서 노드를 제거하지 않으려면 에이전트 리소스에서 주석 agent.agent-install.openshift.io/skip-spoke-cleanup 을 true 로 설정할 수 있습니다.

OpenShift Container Platform 설명서의 노드 삭제 지침을 참조하십시오.

1.9.8.5. 호스트 바인딩 및 바인딩 해제
링크 복사

Agent 사용자 정의 리소스에서 spec.clusterDeploymentName 필드를 설정하거나 {}bmac.agent-install.openshift.io/cluster-reference 베어 메탈 호스트 주석을 설정하여 Red Hat OpenShift Container Platform 클러스터에 호스트를 바인딩할 수 있습니다.

{}bmac.agent-install.openshift.io/cluster-reference 베어 메탈 호스트 주석은 OpenShift Container Platform 클러스터에 대한 연결을 제어하고 호스트를 특정 클러스터에 바인딩하거나 바인딩 해제합니다.

{}bmac.agent-install.openshift.io/cluster-reference 주석을 다음 세 가지 방법 중 하나로 사용할 수 있습니다.

  • 베어 메탈 호스트에 주석을 설정하지 않으면 호스트에 변경 사항이 적용되지 않습니다.
  • 빈 문자열 값으로 주석을 설정하면 호스트가 바인딩 해제됩니다.
  • 주석을 설정하고 < cluster-namespace>/<cluster-name > 형식을 따르는 문자열 값을 사용하는 경우 호스트는 ClusterDeployment 사용자 정의 리소스가 나타내는 클러스터에 바인딩합니다.

참고: 호스트에 이미 cluster-reference 주석이 포함된 InfraEnv 가 있는 경우 {}bmac.agent-install.openshift.io/cluster-reference 주석이 무시됩니다.

1.9.8.6. 추가 리소스
링크 복사

1.9.9. 호스트 인벤토리 관리
링크 복사

콘솔을 사용하거나 명령줄 인터페이스를 사용하여 호스트 인벤토리를 관리하고 기존 호스트를 편집하고 Agent 리소스를 편집할 수 있습니다.

1.9.9.1. 콘솔을 사용하여 호스트 인벤토리 관리
링크 복사

Discovery ISO로 성공적으로 부팅한 각 호스트는 호스트 인벤토리에 행으로 표시됩니다. 콘솔을 사용하여 호스트를 편집하고 관리할 수 있습니다. 호스트를 수동으로 부팅하고 베어 메탈 Operator 자동화를 사용하지 않는 경우 콘솔에서 호스트를 승인해야 사용할 수 있습니다. OpenShift 노드로 설치할 준비가 된 호스트의 상태는 Available 입니다.

1.9.9.2. 명령줄 인터페이스를 사용하여 호스트 인벤토리 관리
링크 복사

에이전트 리소스는 각 호스트를 나타냅니다. 에이전트 리소스에서 다음 속성을 설정할 수 있습니다.

  • clusterDeploymentName

    이 속성을 클러스터에 노드로 설치하려는 경우 사용할 ClusterDeployment 의 네임스페이스 및 이름으로 설정합니다.

  • 선택 사항: role

    클러스터에서 호스트의 역할을 설정합니다. 가능한 값은 master,worker, auto-assign 입니다. 기본값은 auto-assign 입니다.

  • hostname

    호스트의 호스트 이름을 설정합니다. 호스트에 유효한 호스트 이름이 자동으로 할당되는 경우(예: DHCP 사용) 선택 사항입니다.

  • 승인됨

    호스트를 OpenShift 노드로 설치할 수 있는지 여부를 나타냅니다. 이 속성은 기본값이 False 인 부울입니다. 호스트를 수동으로 부팅하고 베어 메탈 Operator 자동화를 사용하지 않는 경우 호스트를 설치하기 전에 이 속성을 True 로 설정해야 합니다.

  • installation_disk_id

    선택한 설치 디스크의 ID가 호스트의 인벤토리에 표시됩니다.

  • installerArgs

    호스트의 coreos-installer 인수에 대한 덮어쓰기가 포함된 JSON 형식의 문자열입니다. 이 속성을 사용하여 커널 인수를 수정할 수 있습니다. 다음 예제 구문을 참조하십시오. 

    ["--append-karg", "ip=192.0.2.2::192.0.2.254:255.255.255.0:core0.example.com:enp1s0:none", "--save-partindex", "4"]
    Copy to Clipboard Toggle word wrap

  • ignitionConfigOverrides

    호스트의 ignition 구성에 대한 덮어쓰기가 포함된 JSON 형식의 문자열입니다. 이 속성을 사용하여 ignition을 사용하여 호스트에 파일을 추가할 수 있습니다. 다음 예제 구문을 참조하십시오. 

    {"ignition": "version": "3.1.0"}, "storage": {"files": [{"path": "/tmp/example", "contents": {"source": "data:text/plain;base64,aGVscGltdHJhcHBlZGluYXN3YWdnZXJzcGVj"}}]}}
    Copy to Clipboard Toggle word wrap

  • nodeLabels

    호스트를 설치한 후 노드에 적용되는 라벨 목록입니다.

에이전트 리소스의 상태에 는 다음과 같은 속성이 있습니다.

  • role

    클러스터에서 호스트의 역할을 설정합니다. 이전에 Agent 리소스에서 역할을 설정하면 값이 상태에 표시됩니다.

  • 인벤토리

    호스트에서 실행 중인 에이전트가 검색하는 호스트 속성을 포함합니다.

  • 진행 상황

    호스트 설치 진행 중입니다.

  • ntpSources

    호스트의 구성된 NTP(Network Time Protocol) 소스입니다.

  • conditions

    True 또는 False 값과 함께 다음 표준 Kubernetes 조건을 포함합니다.

    • SpecSynced: 지정된 모든 속성이 성공적으로 적용되면 True 입니다. false 오류가 발생하면 false입니다.
    • connected: 설치 서비스에 대한 에이전트 연결이 중단되지 않으면 True 입니다. 에이전트가 잠시 후에 설치 서비스에 도달하지 않은 경우 false 입니다.
    • RequirementsMet: 호스트가 설치를 시작할 준비가 되면 True 입니다.
    • validated: 모든 호스트 검증이 통과하면 True 입니다.
    • installed: 호스트가 OpenShift 노드로 설치된 경우 True 입니다.
    • Bound: 호스트가 클러스터에 바인딩된 경우 True 입니다.
    • cleanup: Agent resouce를 삭제하라는 요청이 실패하면 False 입니다.

  • debugInfo

    설치 로그 및 이벤트를 다운로드하기 위한 URL이 포함되어 있습니다.

  • validationsInfo

    설치에 성공했는지 확인하기 위해 호스트가 검색된 후 에이전트가 실행되는 검증에 대한 정보가 포함되어 있습니다. 값이 False 인 경우 문제를 해결합니다.

  • installation_disk_id

    선택한 설치 디스크의 ID가 호스트의 인벤토리에 표시됩니다.

1.9.9.3. 추가 리소스
링크 복사

1.9.10. 각 클러스터에 대한 미러 레지스트리 구성
링크 복사

미러 레지스트리 기능을 사용하여 각 AgentClusterInstall 및 InfraEnv 리소스의 전용 미러 레지스트리 구성 오브젝트를 참조하여 각 클러스터에 대한 사용자 정의 레지스트리를 구성하고 관리합니다.

격리된 레지스트리 구성이 필요한 다중 클러스터 환경에서 각 클러스터에 대한 미러 레지스트리를 구성할 수 있습니다.

1.9.10.1. 사전 요구 사항
링크 복사
  • 중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
  • 미러 레지스트리를 설정해야 합니다.
  • assisted-service 는 KubeAPI 모드에서 실행되어야 합니다.
1.9.10.2. 필요한 이미지 미러링
링크 복사

필요한 이미지가 레지스트리에 미러링되었는지 확인합니다. 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 Red Hat OpenShift Container Platform 릴리스 이미지를 미러링합니다. 

    oc adm release mirror \
  -a pull_secret.json \
  --from=quay.io/openshift-release-dev/ocp-release:$OCP_TAG \
  --to=$REGISTRY_IP:$REGISTRY_PORT/openshift-release-dev/ocp-release \
  --to-release-image=$REGISTRY_IP:$REGISTRY_PORT/openshift-release-dev/ocp-release:$OCP_TAG \
    Copy to Clipboard Toggle word wrap

    참고: 미러 레지스트리의 OpenShift Container Platform 버전이 이미지 세트 구성의 버전과 일치하는지 확인합니다.

  2. 다음 명령을 실행하여 지원 설치 프로그램 이미지를 미러링합니다. 

    oc image mirror \
  -a pull_secret.json \
  quay.io/edge-infrastructure/assisted-installer:latest \
  $REGISTRY_IP:$REGISTRY_PORT/edge-infrastructure/assisted-installer:latest

oc image mirror \
  -a pull_secret.json \
  quay.io/edge-infrastructure/assisted-installer-controller:latest \
  $REGISTRY_IP:$REGISTRY_PORT/edge-infrastructure/assisted-installer-controller:latest

oc image mirror \
  -a pull_secret.json \
  quay.io/edge-infrastructure/assisted-installer-agent:latest \
  $REGISTRY_IP:$REGISTRY_PORT/edge-infrastructure/assisted-installer-agent:latest
    Copy to Clipboard Toggle word wrap
1.9.10.3. 업데이트된 구성으로 사용자 정의 리소스 정의 적용
링크 복사

미러 레지스트리를 설정한 후 필요한 사용자 정의 리소스 정의를 적용하여 미러링된 이미지를 사용하도록 클러스터를 구성합니다. 다음 단계를 완료합니다.

  1. 다음 콘텐츠를 사용하여 mirror_registry.yaml 이라는 ConfigMap 파일을 생성합니다. 필요한 경우 값을 바꿉니다. 
apiVersion: v1
kind: ConfigMap
metadata:
  name: mirror-registry-config
  namespace: <your-namespace>
data:
  registries.conf: |
    [[registry]]
      prefix = ""
      location = "quay.io/openshift-release-dev/ocp-release"
      [[registry.mirror]]
        location = "$REGISTRY_IP:$REGISTRY_PORT/openshift-release-dev/ocp-release"
        pull-from-mirror = "digest-only"

    [[registry]]
      prefix = ""
      location = "quay.io/edge-infrastructure"
      [[registry.mirror]]
        location = "$REGISTRY_IP:$REGISTRY_PORT/edge-infrastructure"
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
Copy to Clipboard Toggle word wrap
  1. 다음 명령을 실행하여 ConfigMap 을 적용합니다. 
oc apply -f mirror_registry.yaml
Copy to Clipboard Toggle word wrap

  1. AgentClusterInstall 및 InfraEnv 사용자 정의 리소스 정의가 미러 레지스트리 구성을 참조하는지 확인합니다. aci.yaml 및 infraenv.yaml 모두에 대한 다음 예제를 참조하십시오. 

    ...
spec:
  mirrorRegistryRef:
    name: mirror-registry-config
    namespace: <your-namespace>
    ...
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 사용자 정의 리소스 정의를 업데이트하고 적용합니다. 

    oc apply -f aci.yaml
oc apply -f infraenv.yaml
    Copy to Clipboard Toggle word wrap
1.9.10.4. 추가 리소스
링크 복사

1.10. 클러스터 API
링크 복사

클러스터 API는 Kubernetes 클러스터의 프로비저닝, 업그레이드 및 관리를 단순화하는 선언적 API를 제공합니다. 다중 클러스터 엔진 Operator는 여러 인프라 및 부트스트랩 공급자와 함께 코어 클러스터 API 구성 요소를 설치하여 다양한 사용 사례 및 플랫폼을 지원합니다. 독립 실행형 다중 클러스터 엔진 Operator 또는 Red Hat Advanced Cluster Management를 사용하여 Cluster API를 사용하는 방법을 알아봅니다. 다음 프로세스를 참조하십시오.

1.10.1. 클러스터 API를 사용하여 관리형 클러스터 설치
링크 복사

metal3 인프라 공급자와 OpenShift Container Platform 지원 부트스트랩 및 컨트롤 플레인 공급자를 사용하여 클러스터 API로 OpenShift Container Platform 관리 클러스터를 설치할 수 있습니다.

  • 'ControlPlane'은 컨트롤 플레인 속성을 정의합니다.
  • ClusterInfrastructure 는 클러스터 수준 인프라 세부 정보를 정의합니다.

사전 요구 사항

  • Red Hat Advanced Cluster Management 설치 또는 다중 클러스터 엔진 Operator 독립 실행형 설치의 MultiClusterEngine 리소스가 필요합니다.
  • 다음 API 기본 도메인은 정적 API VIP를 가리켜야 합니다 . api.<cluster_name>.<base_domain > .
  • 다음 애플리케이션 기본 도메인은 Ingress VIP의 고정 IP 주소를 가리켜야 합니다 . *.apps.<cluster_name>.<base_domain > .
  • 클러스터의 내부 API 끝점( api-int.<baseDomain>)이 필요합니다.
1.10.1.1. 클러스터 API를 사용하여 워크로드 프로비저닝
링크 복사

  1. 워크로드를 프로비저닝하는 데 필요한 서비스를 활성화합니다. 기본적으로 assisted-service 가 활성화됩니다. 기본적으로 cluster-api-provider-metal3-preview 및 cluster-api-provider-openshift-assisted-preview 는 비활성화되어 있습니다. 세 가지 서비스 모두 true 임을 확인합니다. 다음 명령을 실행하여 리소스를 편집합니다. 

    oc edit multiclusterengines.multicluster.openshift.io -n multicluster-engine
    Copy to Clipboard Toggle word wrap

  2. assisted-service 구성 요소, cluster-api-provider-metal3-preview 구성 요소, cluster-api-provider-openshift-assisted-preview 구성 요소의 .spec.overrides 에서 enabled: true 를 설정합니다. 다음 configOverrides 값을 참조하십시오. 

        - configOverrides: {}
      enabled: true
      name: assisted-service
    - configOverrides: {}
      enabled: true
      name: cluster-api
...
    - configOverrides: {}
      enabled: true
      name: cluster-api-provider-metal3-preview
    - configOverrides: {}
      enabled: true
      name: cluster-api-provider-openshift-assisted-preview
    Copy to Clipboard Toggle word wrap
  3. 중앙 인프라 관리 서비스를 활성화합니다. 절차 를 보려면 중앙 인프라 관리 서비스 활성화를 참조하십시오.

  4. clusterNetwork 사양, controlPlaneRef 사양 및 infrastructureRef 사양을 사용하여 클러스터 리소스를 구성합니다. 다음 Cluster 리소스를 참조하십시오. 

    apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: <cluster-name>
  namespace: <cluster-namespace>
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
        - 172.18.0.0/20
    services:
      cidrBlocks:
        - 10.96.0.0/12
  controlPlaneRef:
    1 
    
    apiVersion: controlplane.cluster.x-k8s.io/v1alpha2
    kind: OpenshiftAssistedControlPlane
    name:  <cluster-name>
    namespace:  <cluster-namespace>
  infrastructureRef:
    2 
    
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3Cluster
    name: <cluster-name>
    namespace: <cluster-namespace>
    Copy to Clipboard Toggle word wrap
    1
    OpenshiftAssistedControlPlane 는 컨트롤 플레인입니다.
    2
    Metal3Cluster 는 인프라입니다.

  5. 다음 명령을 실행하여 YAML 콘텐츠를 적용합니다. 

    oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

  6. distributionVersion,apiVIPs 및 SSH 키를 포함하는 OpenshiftAssistedControlPlane 리소스를 구성합니다. distributionVersion 필드에 OpenShift Container Platform 버전을 지정합니다.

    참고: distributionVersion 의 값은 OpenShift Container Platform 릴리스 의 이미지와 일치합니다. 다음 YAML 리소스를 참조하십시오. 

    apiVersion: controlplane.cluster.x-k8s.io/v1alpha2
kind: OpenshiftAssistedControlPlane
metadata:
  name: <cluster-name>
  namespace: <cluster-namespace>
  annotations: {}
spec:
  openshiftAssistedConfigSpec:
    sshAuthorizedKey: "{{ ssh_authorized_key }}"
    1 
    
    nodeRegistration:
      kubeletExtraLabels:
      - 'metal3.io/uuid="${METADATA_UUID}"'
  distributionVersion: <4.x.0>
  config:
    apiVIPs:
    - 192.168.222.40
    ingressVIPs:
    - 192.168.222.41
    baseDomain: lab.home
    pullSecretRef:
      name: "pull-secret"
    sshAuthorizedKey: "{{ ssh_authorized_key }}"
    2 
    
  machineTemplate:
    infrastructureRef:
      apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
      kind: Metal3MachineTemplate
      name: <cluster-name-control-plane>
      namespace: <cluster-namespace>
  replicas: 3
    Copy to Clipboard Toggle word wrap

    <1>'.spec.openshiftAssistedConfigSpec.sshAuthorizedKey'는 부팅 (검색) 단계의 노드에 액세스하는 데 사용됩니다. <2>'.spec.config.sshAuthorizedKey'는 프로비저닝된 OpenShift Container Platform 노드에 액세스하는 데 사용됩니다.

  7. YAML 파일을 적용합니다. 다음 명령을 실행합니다. 

    oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap
  8. 풀 시크릿이 없는 경우 클러스터에서 컨테이너 레지스트리에서 이미지를 가져올 수 있도록 풀 시크릿을 생성해야 합니다. 풀 시크릿을 생성하려면 다음 단계를 완료합니다.

  9. YAML 파일을 생성하여 이미지를 가져옵니다. pull-secret.yaml 이라는 파일의 다음 예제를 참조하십시오. 

    apiVersion: v1
kind: Secret
metadata:
  name: pull-secret
  namespace: <cluster-namespace>
    1 
    
data:
  .dockerconfigjson: <encoded_docker_configuration>
    2 
    
type: kubernetes.io/dockerconfigjson
    Copy to Clipboard Toggle word wrap
    1 1
    네임스페이스 값이 대상 네임스페이스 와 일치하는지 확인합니다.
    2 2
    base64로 인코딩된 구성 파일을 값으로 지정합니다.

  10. 다음 명령을 실행하여 파일을 적용합니다. 

    oc apply -f pull-secret.yaml
    Copy to Clipboard Toggle word wrap

  11. baremetal에 클러스터 배포와 관련된 정보가 포함된 Metal3Cluster 인프라 리소스를 구성합니다. 

    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3Cluster
metadata:
  name: <cluster-name>
  namespace: <cluster-namespace>
spec:
  controlPlaneEndpoint:
    host: <cluster-name>.lab.home
    1 
    
    port: 6443
  noCloudProvider: true
    Copy to Clipboard Toggle word wrap
    1
    호스트 는 클러스터 리소스의 clusterName과 함께 < clusterName >.<baseDomain>* 값이고 baseDomain 은 OpenshiftAssistedControlPlane 리소스에 정의됩니다.

  12. 파일을 적용합니다. 다음 명령을 실행합니다. 

    oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

  13. OpenshiftAssistedControlPlane 리소스에서 참조하는 컨트롤 플레인 노드에 대해 Metal3MachineTemplate 리소스를 구성합니다. 다음 YAML 샘플을 참조하십시오. 

    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: <cluster-name>
  namespace: <cluster-namespace>
spec:
  nodeReuse: false
  template:
    spec:
      automatedCleaningMode: disabled
      dataTemplate:
        name: <cluster-name-template>
      image:
    1 
    
        checksum: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.19/4.19.0/sha256sum.txt
        checksumType: sha256
        url: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.19/4.19.0/rhcos-4.19.0-x86_64-nutanix.x86_64.qcow2
        format: qcow2
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3DataTemplate
metadata:
   name: <cluster-name-template>
   namespace: <cluster-namespace>
spec:
   clusterName: <cluster-name>
    2
    Copy to Clipboard Toggle word wrap
    1
    이미지는 OpenShift Container Platform 릴리스 의 distributionVersion 값과 버전과 일치합니다.
    2
    clusterName 을 Cluster 리소스에 있는 값과 동일한 값으로 설정합니다.

  14. 파일을 적용합니다. 다음 명령을 실행합니다. 

    oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

  15. Metal3MachineTemplate 을 참조하는 MachineDeployment 리소스를 사용하여 작업자 노드를 구성합니다. 다음 YAML 예제를 참조하십시오. 

    apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: <cluster-name-worker>
  namespace: <cluster-namespace>
  labels:
    cluster.x-k8s.io/cluster-name: <cluster-name>
spec:
  clusterName: <cluster-name>
  replicas: 2
  selector:
    matchLabels:
      cluster.x-k8s.io/cluster-name: <cluster-name>
  template:
    metadata:
      labels:
        cluster.x-k8s.io/cluster-name: <cluster-name>
    spec:
      clusterName: <cluster-name>
      bootstrap:
    1 
    
        configRef:
          name: <cluster-name-worker>
          apiVersion: bootstrap.cluster.x-k8s.io/v1alpha1
          kind: OpenshiftAssistedConfigTemplate
      infrastructureRef:
    2 
    
        name: <cluster-name-workers-2>
        apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
        kind: Metal3MachineTemplate
    Copy to Clipboard Toggle word wrap
    1
    부트스트랩 구성은 설치를 위해 다음 리소스에서도 참조됩니다.
    2
    인프라 참조는 프로비저닝할 리소스를 가리킵니다.

  16. 파일을 적용합니다. 다음 명령을 실행합니다. 

    oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

  17. MachineDeployment 에서 참조되는 OpenshiftAssistedConfigTemplate 리소스를 생성합니다. 다음 YAML은 작업자 노드의 부트스트랩 구성을 정의하고 지원 설치 프로그램에 노드를 등록하는 데 사용됩니다. 

    apiVersion: bootstrap.cluster.x-k8s.io/v1alpha1
kind: OpenshiftAssistedConfigTemplate
metadata:
  name: <cluster-name-worker>
  namespace: <cluster-namespace>
  labels:
    cluster.x-k8s.io/cluster-name: cluster-name
spec:
  template:
    spec:
      nodeRegistration:
        kubeletExtraLabels:
          - 'metal3.io/uuid="${METADATA_UUID}"'
    1 
    
      sshAuthorizedKey: "{{ ssh_authorized_key }}"
    2
    Copy to Clipboard Toggle word wrap
    1
    kubeletExtraLabels 는 이 값에서 변경할 수 없습니다.
    2
    sshAuthorizedKey 를 입력합니다.

  18. MachineDeployment 리소스에서 참조되는 Metal3MachineTemplate 을 생성합니다. 다음 예제를 참조하십시오. 

    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
   name: <cluster-name-workers-2>
   namespace: <cluster-namespace>
spec:
   nodeReuse: false
   template:
      spec:
         automatedCleaningMode: metadata
         dataTemplate:
            name: <cluster-name-workers-template>
      image:
        checksum: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.19/4.19.0/sha256sum.txt
        checksumType: sha256
        url: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.19/4.19.0/rhcos-4.19.0-x86_64-nutanix.x86_64.qcow2
        format: qcow2
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3DataTemplate
metadata:
   name: <cluster-name-workers-template>
   namespace: <cluster-namespace>
spec:
   clusterName: <cluster-name>
    Copy to Clipboard Toggle word wrap

  19. 다음 명령을 실행하여 YAML 파일을 저장하고 클러스터를 프로비저닝합니다. 

    oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

  20. 클러스터 프로비저닝 상태를 확인합니다.

    1. oc get cluster --namespace <cluster-namespace> <cluster-name> -o yaml 을 실행하여 클러스터 리소스 상태를 확인합니다.

      다음 출력 및 상태를 참조하십시오. 

      status:
  conditions:
  - lastTransitionTime: "2025-06-25T11:23:38Z"
    status: "True"
    type: Ready
  - lastTransitionTime: "2025-06-25T11:23:38Z"
    status: "True"
    type: ControlPlaneReady
  - lastTransitionTime: "2025-06-25T10:37:03Z"
    status: "True"
    type: InfrastructureReady
      Copy to Clipboard Toggle word wrap

    2. oc get metal3cluster --namespace <cluster-namespace> <cluster-name> -o yaml 명령을 실행하여 클러스터 인프라 상태를 확인합니다.

      다음 출력 및 상태를 참조하십시오. 

      status:
  conditions:
  - lastTransitionTime: "2025-06-25T10:37:03Z"
    status: "True"
    type: Ready
  - lastTransitionTime: "2025-06-25T10:37:03Z"
    status: "True"
    type: BaremetalInfrastructureReady
      Copy to Clipboard Toggle word wrap

    3. oc get openshiftassistedcontrolplane --namespace <cluster-namespace> <cluster-name> -o yaml 명령을 실행하여 컨트롤 플레인 상태를 확인합니다.

      다음 출력 및 상태를 참조하십시오. 

      status:
  conditions:
  - lastTransitionTime: "2025-06-25T11:23:38Z"
    status: "True"
    type: Ready
  - lastTransitionTime: "2025-06-25T11:23:38Z"
    status: "True"
    type: ControlPlaneReady
  - lastTransitionTime: "2025-06-25T10:45:48Z"
    status: "True"
    type: KubeconfigAvailable
  - lastTransitionTime: "2025-06-25T10:38:25Z"
    status: "True"
    type: MachinesCreated
  - lastTransitionTime: "2025-06-25T11:10:54Z"
    status: "True"
    type: MachinesReady
  - lastTransitionTime: "2025-06-25T11:23:38Z"
    status: "True"
    type: UpgradeCompleted
      Copy to Clipboard Toggle word wrap

    4. oc get machinedeployment --namespace <cluster-namespace> <cluster-name> -o yaml 명령을 실행하여 머신 배포 상태를 확인합니다.

      다음 출력 및 상태를 참조하십시오. 

      status:
  conditions:
  - lastTransitionTime: "2025-06-25T11:10:29Z"
    status: "True"
    type: Ready
  - lastTransitionTime: "2025-06-25T11:10:29Z"
    status: "True"
    type: Available
  - lastTransitionTime: "2025-06-25T11:10:29Z"
    status: "True"
    type: MachineSetReady
      Copy to Clipboard Toggle word wrap

    5. kubectl get machine -l cluster.x-k8s.io/cluster-name=cluster-name -n test-capi -o yaml 명령을 실행하여 머신을 확인합니다.

      다음 출력 및 상태를 참조하십시오. 

     status:
    conditions:
    - lastTransitionTime: "2025-06-25T11:09:57Z"
  	status: "True"
  	type: Ready
    - lastTransitionTime: "2025-06-25T10:38:20Z"
  	status: "True"
  	type: BootstrapReady
    - lastTransitionTime: "2025-06-25T11:09:57Z"
  	status: "True"
  	type: InfrastructureReady
    - lastTransitionTime: "2025-06-25T11:10:29Z"
  	status: "True"
  	type: NodeHealthy
    Copy to Clipboard Toggle word wrap

  21. 클러스터에 액세스합니다.

    1. 다음 명령을 실행하여 kubeconfig 파일을 가져옵니다. 

      oc get secret -n test-capi  cluster-name-admin-kubeconfig -o json | jq -r .data.kubeconfig | base64 --decode > kubeconfig
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 kubeconfig 파일을 사용하여 클러스터에 액세스합니다. 
    export KUBECONFIG=$(realpath kubeconfig)
oc get nodes
    Copy to Clipboard Toggle word wrap

1.11. API
링크 복사

deprecated: API에 대한 문서는 더 이상 사용되지 않습니다. 콘솔 또는 oc 명령에서 API Explorer 를 사용하여 현재 및 지원되는 API를 확인합니다.

다중 클러스터 엔진 Operator를 사용하여 클러스터 라이프사이클 관리를 위해 다음 API에 액세스할 수 있습니다. 사용자 필수 액세스: 역할이 할당된 작업만 수행할 수 있습니다.

참고: 통합 콘솔에서 모든 API에 액세스할 수도 있습니다. local-cluster 보기에서 Home > API Explorer 로 이동하여 API 그룹을 살펴봅니다.

자세한 내용은 다음 리소스 각각에 대한 API 설명서를 참조하십시오.

1.11.1. 클러스터 API
링크 복사

deprecated: API에 대한 문서는 더 이상 사용되지 않습니다. 콘솔 또는 oc 명령에서 API Explorer 를 사용하여 현재 및 지원되는 API를 확인합니다.

1.11.1.1. 개요
링크 복사

이 문서는 Kubernetes Operator용 다중 클러스터 엔진용 클러스터 리소스에 대한 것입니다. 클러스터 리소스에는 생성, 쿼리, 삭제 및 업데이트의 네 가지 요청이 있습니다.

1.11.1.1.1. URI 스키마
링크 복사

BasePath : /kubernetes/apis
Schemes : HTTPS

1.11.1.1.2. 태그
링크 복사
  • cluster.open-cluster-management.io : 클러스터 생성 및 관리
1.11.1.2. 경로
링크 복사
1.11.1.2.1. 모든 클러스터 쿼리
링크 복사
GET /cluster.open-cluster-management.io/v1/managedclusters
Copy to Clipboard Toggle word wrap
1.11.1.2.1.1. 설명
링크 복사

자세한 내용은 클러스터를 쿼리합니다.

1.11.1.2.1.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

1.11.1.2.1.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.1.2.1.4. 사용
링크 복사
  • cluster/yaml
1.11.1.2.1.5. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.1.2.2. 클러스터 생성
링크 복사
POST /cluster.open-cluster-management.io/v1/managedclusters
Copy to Clipboard Toggle word wrap
1.11.1.2.2.1. 설명
링크 복사

클러스터 생성

1.11.1.2.2.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

본문

본문
필요

생성할 클러스터를 설명하는 매개변수입니다.

Cluster

1.11.1.2.2.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.1.2.2.4. 사용
링크 복사
  • cluster/yaml
1.11.1.2.2.5. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.1.2.2.6. HTTP 요청의 예
링크 복사
1.11.1.2.2.6.1. 요청 본문
링크 복사
{
  "apiVersion" : "cluster.open-cluster-management.io/v1",
  "kind" : "ManagedCluster",
  "metadata" : {
    "labels" : {
      "vendor" : "OpenShift"
    },
    "name" : "cluster1"
  },
  "spec": {
    "hubAcceptsClient": true,
    "managedClusterClientConfigs": [
      {
        "caBundle": "test",
        "url": "https://test.com"
      }
    ]
  },
  "status" : { }
}
Copy to Clipboard Toggle word wrap
1.11.1.2.3. 단일 클러스터 쿼리
링크 복사
GET /cluster.open-cluster-management.io/v1/managedclusters/{cluster_name}
Copy to Clipboard Toggle word wrap
1.11.1.2.3.1. 설명
링크 복사

자세한 내용은 단일 클러스터를 쿼리합니다.

1.11.1.2.3.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

cluster_name
required

쿼리할 클러스터의 이름입니다.

string

1.11.1.2.3.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.1.2.3.4. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.1.2.4. 클러스터 삭제
링크 복사
DELETE /cluster.open-cluster-management.io/v1/managedclusters/{cluster_name}
Copy to Clipboard Toggle word wrap
1.11.1.2.4.1. 설명
링크 복사

단일 클러스터 삭제

1.11.1.2.4.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

cluster_name
required

삭제할 클러스터의 이름입니다.

string

1.11.1.2.4.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.1.2.4.4. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.1.3. 정의
링크 복사
1.11.1.3.1. Cluster
링크 복사
Expand
이름스키마

apiVersion
required

string

종류
필요

string

메타데이터
필요

object

사양
필요

spec

spec

Expand
이름스키마

hubAcceptsClient
필요

bool

managedClusterClientConfigs
optional

< managedClusterClientConfigs > array

leaseDurationSeconds
optional

integer (int32)

managedClusterClientConfigs

Expand
이름설명스키마

URL
필요

 

string

cabundle
선택 사항

패턴 : 

"^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$"
Copy to Clipboard Toggle word wrap

문자열(바이트)

1.11.2. Clustersets API (v1beta2)
링크 복사

deprecated: API에 대한 문서는 더 이상 사용되지 않습니다. 콘솔 또는 oc 명령에서 API Explorer 를 사용하여 현재 및 지원되는 API를 확인합니다.

1.11.2.1. 개요
링크 복사

이 문서는 Kubernetes Operator용 다중 클러스터 엔진용 Clusterset 리소스에 대한 것입니다. Clusterset 리소스에는 생성, 쿼리, 삭제 및 업데이트의 네 가지 요청이 있습니다.

1.11.2.1.1. URI 스키마
링크 복사

BasePath : /kubernetes/apis
Schemes : HTTPS

1.11.2.1.2. 태그
링크 복사
  • cluster.open-cluster-management.io : Clustersets 생성 및 관리
1.11.2.2. 경로
링크 복사
1.11.2.2.1. 모든 clustersets 쿼리
링크 복사
GET /cluster.open-cluster-management.io/v1beta2/managedclustersets
Copy to Clipboard Toggle word wrap
1.11.2.2.1.1. 설명
링크 복사

자세한 내용은 Clustersets를 쿼리합니다.

1.11.2.2.1.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

1.11.2.2.1.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.2.2.1.4. 사용
링크 복사
  • clusterset/yaml
1.11.2.2.1.5. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.2.2.2. clusterset 생성
링크 복사
POST /cluster.open-cluster-management.io/v1beta2/managedclustersets
Copy to Clipboard Toggle word wrap
1.11.2.2.2.1. 설명
링크 복사

클러스터 세트를 생성합니다.

1.11.2.2.2.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

본문

본문
필요

생성할 clusterset을 설명하는 매개변수입니다.

clusterset

1.11.2.2.2.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.2.2.2.4. 사용
링크 복사
  • clusterset/yaml
1.11.2.2.2.5. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.2.2.2.6. HTTP 요청의 예
링크 복사
1.11.2.2.2.6.1. 요청 본문
링크 복사
{
  "apiVersion" : "cluster.open-cluster-management.io/v1beta2",
  "kind" : "ManagedClusterSet",
  "metadata" : {
    "name" : "clusterset1"
  },
  "spec": { },
  "status" : { }
}
Copy to Clipboard Toggle word wrap
1.11.2.2.3. 단일 클러스터 세트 쿼리
링크 복사
GET /cluster.open-cluster-management.io/v1beta2/managedclustersets/{clusterset_name}
Copy to Clipboard Toggle word wrap
1.11.2.2.3.1. 설명
링크 복사

자세한 내용은 단일 클러스터 세트를 쿼리합니다.

1.11.2.2.3.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

clusterset_name
required

쿼리할 클러스터 세트의 이름입니다.

string

1.11.2.2.3.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.2.2.3.4. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.2.2.4. clusterset 삭제
링크 복사
DELETE /cluster.open-cluster-management.io/v1beta2/managedclustersets/{clusterset_name}
Copy to Clipboard Toggle word wrap
1.11.2.2.4.1. 설명
링크 복사

단일 클러스터 세트를 삭제합니다.

1.11.2.2.4.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

clusterset_name
required

삭제할 클러스터 세트의 이름입니다.

string

1.11.2.2.4.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.2.2.4.4. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.2.3. 정의
링크 복사
1.11.2.3.1. clusterset
링크 복사
Expand
이름스키마

apiVersion
required

string

종류
필요

string

메타데이터
필요

object

1.11.3. Clustersetbindings API (v1beta2)
링크 복사

deprecated: API에 대한 문서는 더 이상 사용되지 않습니다. 콘솔 또는 oc 명령에서 API Explorer 를 사용하여 현재 및 지원되는 API를 확인합니다.

1.11.3.1. 개요
링크 복사

이 문서는 Kubernetes용 다중 클러스터 엔진의 clustersetbinding 리소스를 위한 것입니다. Clustersetbinding 리소스에는 생성, 쿼리, 삭제 및 업데이트의 네 가지 요청이 있습니다.

1.11.3.1.1. URI 스키마
링크 복사

BasePath : /kubernetes/apis
Schemes : HTTPS

1.11.3.1.2. 태그
링크 복사
  • cluster.open-cluster-management.io : clustersetbindings 생성 및 관리
1.11.3.2. 경로
링크 복사
1.11.3.2.1. 모든 clustersetbindings 쿼리
링크 복사
GET /cluster.open-cluster-management.io/v1beta2/namespaces/{namespace}/managedclustersetbindings
Copy to Clipboard Toggle word wrap
1.11.3.2.1.1. 설명
링크 복사

자세한 내용은 clustersetbindings를 쿼리합니다.

1.11.3.2.1.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

네임스페이스
필요

사용할 네임스페이스(예: default)입니다.

string

1.11.3.2.1.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.3.2.1.4. 사용
링크 복사
  • clustersetbinding/yaml
1.11.3.2.1.5. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.3.2.2. clustersetbinding 생성
링크 복사
POST /cluster.open-cluster-management.io/v1beta2/namespaces/{namespace}/managedclustersetbindings
Copy to Clipboard Toggle word wrap
1.11.3.2.2.1. 설명
링크 복사

clustersetbinding을 생성합니다.

1.11.3.2.2.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

네임스페이스
필요

사용할 네임스페이스(예: default)입니다.

string

본문

본문
필요

생성할 clustersetbinding을 설명하는 매개변수입니다.

Clustersetbinding

1.11.3.2.2.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.3.2.2.4. 사용
링크 복사
  • clustersetbinding/yaml
1.11.3.2.2.5. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.3.2.2.6. HTTP 요청의 예
링크 복사
1.11.3.2.2.6.1. 요청 본문
링크 복사
{
  "apiVersion" : "cluster.open-cluster-management.io/v1",
  "kind" : "ManagedClusterSetBinding",
  "metadata" : {
    "name" : "clusterset1",
    "namespace" : "ns1"
  },
 "spec": {
    "clusterSet": "clusterset1"
  },
  "status" : { }
}
Copy to Clipboard Toggle word wrap
1.11.3.2.3. 단일 clustersetbinding 쿼리
링크 복사
GET /cluster.open-cluster-management.io/v1beta2/namespaces/{namespace}/managedclustersetbindings/{clustersetbinding_name}
Copy to Clipboard Toggle word wrap
1.11.3.2.3.1. 설명
링크 복사

자세한 내용은 단일 clustersetbinding을 쿼리합니다.

1.11.3.2.3.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

네임스페이스
필요

사용할 네임스페이스(예: default)입니다.

string

경로

clustersetbinding_name
required

쿼리할 clustersetbinding의 이름입니다.

string

1.11.3.2.3.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.3.2.3.4. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.3.2.4. clustersetbinding 삭제
링크 복사
DELETE /cluster.open-cluster-management.io/v1beta2/managedclustersetbindings/{clustersetbinding_name}
Copy to Clipboard Toggle word wrap
1.11.3.2.4.1. 설명
링크 복사

단일 clustersetbinding을 삭제합니다.

1.11.3.2.4.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

네임스페이스
필요

사용할 네임스페이스(예: default)입니다.

string

경로

clustersetbinding_name
required

삭제할 clustersetbinding의 이름입니다.

string

1.11.3.2.4.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.3.2.4.4. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.3.3. 정의
링크 복사
1.11.3.3.1. Clustersetbinding
링크 복사
Expand
이름스키마

apiVersion
required

string

종류
필요

string

메타데이터
필요

object

사양
필요

spec

spec

Expand
이름스키마

clusterSet
required

string

1.11.4. Clusterview API(v1alpha1)
링크 복사

deprecated: API에 대한 문서는 더 이상 사용되지 않습니다. 콘솔 또는 oc 명령에서 API Explorer 를 사용하여 현재 및 지원되는 API를 확인합니다.

1.11.4.1. 개요
링크 복사

이 문서는 Kubernetes용 다중 클러스터 엔진의 clusterview 리소스에 대한 것입니다. clusterview 리소스는 액세스할 수 있는 관리 클러스터 및 관리 클러스터 세트 목록을 볼 수 있는 CLI 명령을 제공합니다. 가능한 세 가지 요청은 list, get, watch입니다.

1.11.4.1.1. URI 스키마
링크 복사

BasePath : /kubernetes/apis
Schemes : HTTPS

1.11.4.1.2. 태그
링크 복사
  • clusterview.open-cluster-management.io : ID가 액세스할 수 있는 관리 클러스터 목록을 확인합니다.
1.11.4.2. 경로
링크 복사
1.11.4.2.1. 관리 클러스터 가져오기
링크 복사
GET /managedclusters.clusterview.open-cluster-management.io
Copy to Clipboard Toggle word wrap
1.11.4.2.1.1. 설명
링크 복사

액세스할 수 있는 관리 클러스터 목록을 확인합니다.

1.11.4.2.1.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

1.11.4.2.1.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.4.2.1.4. 사용
링크 복사
  • managedcluster/yaml
1.11.4.2.1.5. 태그
링크 복사
  • clusterview.open-cluster-management.io
1.11.4.2.2. 관리 클러스터 나열
링크 복사
LIST /managedclusters.clusterview.open-cluster-management.io
Copy to Clipboard Toggle word wrap
1.11.4.2.2.1. 설명
링크 복사

액세스할 수 있는 관리 클러스터 목록을 확인합니다.

1.11.4.2.2.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

본문

본문
선택 사항

관리 클러스터를 나열할 사용자 ID의 이름입니다.

string

1.11.4.2.2.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.4.2.2.4. 사용
링크 복사
  • managedcluster/yaml
1.11.4.2.2.5. 태그
링크 복사
  • clusterview.open-cluster-management.io
1.11.4.2.2.6. HTTP 요청의 예
링크 복사
1.11.4.2.2.6.1. 요청 본문
링크 복사
{
  "apiVersion" : "clusterview.open-cluster-management.io/v1alpha1",
  "kind" : "ClusterView",
  "metadata" : {
    "name" : "<user_ID>"
  },
  "spec": { },
  "status" : { }
}
Copy to Clipboard Toggle word wrap
1.11.4.2.3. 관리 클러스터 세트 모니터링
링크 복사
WATCH /managedclusters.clusterview.open-cluster-management.io
Copy to Clipboard Toggle word wrap
1.11.4.2.3.1. 설명
링크 복사

액세스할 수 있는 관리형 클러스터를 확인합니다.

1.11.4.2.3.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

clusterview_name
optional

조사할 사용자 ID의 이름입니다.

string

1.11.4.2.3.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.4.2.4. 관리되는 클러스터 세트를 나열합니다.
링크 복사
GET /managedclustersets.clusterview.open-cluster-management.io
Copy to Clipboard Toggle word wrap
1.11.4.2.4.1. 설명
링크 복사

액세스할 수 있는 관리 클러스터를 나열합니다.

1.11.4.2.4.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

clusterview_name
optional

조사할 사용자 ID의 이름입니다.

string

1.11.4.2.4.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.4.2.5. 관리되는 클러스터 세트를 나열합니다.
링크 복사
LIST /managedclustersets.clusterview.open-cluster-management.io
Copy to Clipboard Toggle word wrap
1.11.4.2.5.1. 설명
링크 복사

액세스할 수 있는 관리 클러스터를 나열합니다.

1.11.4.2.5.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

clusterview_name
optional

조사할 사용자 ID의 이름입니다.

string

1.11.4.2.5.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.4.2.6. 관리되는 클러스터 세트를 확인합니다.
링크 복사
WATCH /managedclustersets.clusterview.open-cluster-management.io
Copy to Clipboard Toggle word wrap
1.11.4.2.6.1. 설명
링크 복사

액세스할 수 있는 관리형 클러스터를 확인합니다.

1.11.4.2.6.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

clusterview_name
optional

조사할 사용자 ID의 이름입니다.

string

1.11.4.2.6.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.5. ManagedServiceAccount API (v1alpha1) (더 이상 사용되지 않음)
링크 복사

deprecated: API에 대한 문서는 더 이상 사용되지 않습니다. 콘솔 또는 oc 명령에서 API Explorer 를 사용하여 현재 및 지원되는 API를 확인합니다.

1.11.5.1. 개요
링크 복사

이 문서는 다중 클러스터 엔진 Operator의 ManagedServiceAccount 리소스에 대한 것입니다. ManagedServiceAccount 리소스에는 생성, 쿼리, 삭제 및 업데이트의 네 가지 요청이 있습니다.

deprecated: v1alpha1 API는 더 이상 사용되지 않습니다. 최상의 결과를 얻으려면 대신 v1beta1 을 사용하십시오.

1.11.5.1.1. URI 스키마
링크 복사

BasePath : /kubernetes/apis
Schemes : HTTPS

1.11.5.1.2. 태그
링크 복사
  • managedserviceaccounts.authentication.open-cluster-management.io: ManagedServiceAccounts생성 및 관리
1.11.5.2. 경로
링크 복사
1.11.5.2.1. ManagedServiceAccount 생성
링크 복사
POST /authentication.open-cluster-management.io/v1beta1/managedserviceaccounts
Copy to Clipboard Toggle word wrap
1.11.5.2.1.1. 설명
링크 복사

ManagedServiceAccount 를 생성합니다.

1.11.5.2.1.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

본문

본문
필요

생성할 ManagedServiceAccount를 설명하는 매개변수입니다.

ManagedServiceAccount

1.11.5.2.1.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.5.2.1.4. 사용
링크 복사
  • managedserviceaccount/yaml
1.11.5.2.1.5. 태그
링크 복사
  • managedserviceaccounts.authentication.open-cluster-management.io
1.11.5.2.1.5.1. 요청 본문
링크 복사
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  annotations:
    controller-gen.kubebuilder.io/version: v0.14.0
  name: managedserviceaccounts.authentication.open-cluster-management.io
spec:
  group: authentication.open-cluster-management.io
  names:
    kind: ManagedServiceAccount
    listKind: ManagedServiceAccountList
    plural: managedserviceaccounts
    singular: managedserviceaccount
  scope: Namespaced
  versions:
  - deprecated: true
    deprecationWarning: authentication.open-cluster-management.io/v1alpha1 ManagedServiceAccount
      is deprecated; use authentication.open-cluster-management.io/v1beta1 ManagedServiceAccount;
      version v1alpha1 will be removed in the next release
    name: v1alpha1
    schema:
      openAPIV3Schema:
        description: ManagedServiceAccount is the Schema for the managedserviceaccounts
          API
        properties:
          apiVersion:
            description: |-
              APIVersion defines the versioned schema of this representation of an object.
              Servers should convert recognized schemas to the latest internal value, and
              may reject unrecognized values.
              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
            type: string
          kind:
            description: |-
              Kind is a string value representing the REST resource this object represents.
              Servers may infer this from the endpoint the client submits requests to.
              Cannot be updated.
              In CamelCase.
              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
            type: string
          metadata:
            type: object
          spec:
            description: ManagedServiceAccountSpec defines the desired state of ManagedServiceAccount
            properties:
              rotation:
                description: Rotation is the policy for rotation the credentials.
                properties:
                  enabled:
                    default: true
                    description: |-
                      Enabled prescribes whether the ServiceAccount token will
                      be rotated from the upstream
                    type: boolean
                  validity:
                    default: 8640h0m0s
                    description: Validity is the duration for which the signed ServiceAccount
                      token is valid.
                    type: string
                type: object
              ttlSecondsAfterCreation:
                description: |-
                  ttlSecondsAfterCreation limits the lifetime of a ManagedServiceAccount.
                  If the ttlSecondsAfterCreation field is set, the ManagedServiceAccount will be
                  automatically deleted regardless of the ManagedServiceAccount's status.
                  When the ManagedServiceAccount is deleted, its lifecycle guarantees
                  (e.g. finalizers) will be honored. If this field is unset, the ManagedServiceAccount
                  won't be automatically deleted. If this field is set to zero, the
                  ManagedServiceAccount becomes eligible for deletion immediately after its creation.
                  In order to use ttlSecondsAfterCreation, the EphemeralIdentity feature gate must be enabled.
                exclusiveMinimum: true
                format: int32
                minimum: 0
                type: integer
            required:
            - rotation
            type: object
          status:
            description: ManagedServiceAccountStatus defines the observed state of
              ManagedServiceAccount
            properties:
              conditions:
                description: Conditions is the condition list.
                items:
                  description: "Condition contains details for one aspect of the current
                    state of this API Resource.\n---\nThis struct is intended for
                    direct use as an array at the field path .status.conditions.  For
                    example,\n\n\n\ttype FooStatus struct{\n\t    // Represents the
                    observations of a foo's current state.\n\t    // Known .status.conditions.type
                    are: \"Available\", \"Progressing\", and \"Degraded\"\n\t    //
                    +patchMergeKey=type\n\t    // +patchStrategy=merge\n\t    // +listType=map\n\t
                    \   // +listMapKey=type\n\t    Conditions []metav1.Condition `json:\"conditions,omitempty\"
                    patchStrategy:\"merge\" patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n\n\t
                    \   // other fields\n\t}"
                  properties:
                    lastTransitionTime:
                      description: |-
                        lastTransitionTime is the last time the condition transitioned from one status to another.
                        This should be when the underlying condition changed.  If that is not known, then using the time when the API field changed is acceptable.
                      format: date-time
                      type: string
                    message:
                      description: |-
                        message is a human readable message indicating details about the transition.
                        This may be an empty string.
                      maxLength: 32768
                      type: string
                    observedGeneration:
                      description: |-
                        observedGeneration represents the .metadata.generation that the condition was set based upon.
                        For instance, if .metadata.generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date
                        with respect to the current state of the instance.
                      format: int64
                      minimum: 0
                      type: integer
                    reason:
                      description: |-
                        reason contains a programmatic identifier indicating the reason for the condition's last transition.
                        Producers of specific condition types may define expected values and meanings for this field,
                        and whether the values are considered a guaranteed API.
                        The value should be a CamelCase string.
                        This field may not be empty.
                      maxLength: 1024
                      minLength: 1
                      pattern: ^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$
                      type: string
                    status:
                      description: status of the condition, one of True, False, Unknown.
                      enum:
                      - "True"
                      - "False"
                      - Unknown
                      type: string
                    type:
                      description: |-
                        type of condition in CamelCase or in foo.example.com/CamelCase.
                        ---
                        Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be
                        useful (see .node.status.conditions), the ability to deconflict is important.
                        The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt)
                      maxLength: 316
                      pattern: ^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])$
                      type: string
                  required:
                  - lastTransitionTime
                  - message
                  - reason
                  - status
                  - type
                  type: object
                type: array
              expirationTimestamp:
                description: ExpirationTimestamp is the time when the token will expire.
                format: date-time
                type: string
              tokenSecretRef:
                description: |-
                  TokenSecretRef is a reference to the corresponding ServiceAccount's Secret, which stores
                  the CA certficate and token from the managed cluster.
                properties:
                  lastRefreshTimestamp:
                    description: |-
                      LastRefreshTimestamp is the timestamp indicating when the token in the Secret
                      is refreshed.
                    format: date-time
                    type: string
                  name:
                    description: Name is the name of the referenced secret.
                    type: string
                required:
                - lastRefreshTimestamp
                - name
                type: object
            type: object
        type: object
    served: true
    storage: false
    subresources:
      status: {}
  - name: v1beta1
    schema:
      openAPIV3Schema:
        description: ManagedServiceAccount is the Schema for the managedserviceaccounts
          API
        properties:
          apiVersion:
            description: |-
              APIVersion defines the versioned schema of this representation of an object.
              Servers should convert recognized schemas to the latest internal value, and
              may reject unrecognized values.
              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
            type: string
          kind:
            description: |-
              Kind is a string value representing the REST resource this object represents.
              Servers may infer this from the endpoint the client submits requests to.
              Cannot be updated.
              In CamelCase.
              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
            type: string
          metadata:
            type: object
          spec:
            description: ManagedServiceAccountSpec defines the desired state of ManagedServiceAccount
            properties:
              rotation:
                description: Rotation is the policy for rotation the credentials.
                properties:
                  enabled:
                    default: true
                    description: |-
                      Enabled prescribes whether the ServiceAccount token will be rotated before it expires.
                      Deprecated: All ServiceAccount tokens will be rotated before they expire regardless of this field.
                    type: boolean
                  validity:
                    default: 8640h0m0s
                    description: Validity is the duration of validity for requesting
                      the signed ServiceAccount token.
                    type: string
                type: object
              ttlSecondsAfterCreation:
                description: |-
                  ttlSecondsAfterCreation limits the lifetime of a ManagedServiceAccount.
                  If the ttlSecondsAfterCreation field is set, the ManagedServiceAccount will be
                  automatically deleted regardless of the ManagedServiceAccount's status.
                  When the ManagedServiceAccount is deleted, its lifecycle guarantees
                  (e.g. finalizers) will be honored. If this field is unset, the ManagedServiceAccount
                  won't be automatically deleted. If this field is set to zero, the
                  ManagedServiceAccount becomes eligible for deletion immediately after its creation.
                  In order to use ttlSecondsAfterCreation, the EphemeralIdentity feature gate must be enabled.
                exclusiveMinimum: true
                format: int32
                minimum: 0
                type: integer
            required:
            - rotation
            type: object
          status:
            description: ManagedServiceAccountStatus defines the observed state of
              ManagedServiceAccount
            properties:
              conditions:
                description: Conditions is the condition list.
                items:
                  description: "Condition contains details for one aspect of the current
                    state of this API Resource.\n---\nThis struct is intended for
                    direct use as an array at the field path .status.conditions.  For
                    example,\n\n\n\ttype FooStatus struct{\n\t    // Represents the
                    observations of a foo's current state.\n\t    // Known .status.conditions.type
                    are: \"Available\", \"Progressing\", and \"Degraded\"\n\t    //
                    +patchMergeKey=type\n\t    // +patchStrategy=merge\n\t    // +listType=map\n\t
                    \   // +listMapKey=type\n\t    Conditions []metav1.Condition `json:\"conditions,omitempty\"
                    patchStrategy:\"merge\" patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n\n\t
                    \   // other fields\n\t}"
                  properties:
                    lastTransitionTime:
                      description: |-
                        lastTransitionTime is the last time the condition transitioned from one status to another.
                        This should be when the underlying condition changed.  If that is not known, then using the time when the API field changed is acceptable.
                      format: date-time
                      type: string
                    message:
                      description: |-
                        message is a human readable message indicating details about the transition.
                        This may be an empty string.
                      maxLength: 32768
                      type: string
                    observedGeneration:
                      description: |-
                        observedGeneration represents the .metadata.generation that the condition was set based upon.
                        For instance, if .metadata.generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date
                        with respect to the current state of the instance.
                      format: int64
                      minimum: 0
                      type: integer
                    reason:
                      description: |-
                        reason contains a programmatic identifier indicating the reason for the condition's last transition.
                        Producers of specific condition types may define expected values and meanings for this field,
                        and whether the values are considered a guaranteed API.
                        The value should be a CamelCase string.
                        This field may not be empty.
                      maxLength: 1024
                      minLength: 1
                      pattern: ^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$
                      type: string
                    status:
                      description: status of the condition, one of True, False, Unknown.
                      enum:
                      - "True"
                      - "False"
                      - Unknown
                      type: string
                    type:
                      description: |-
                        type of condition in CamelCase or in foo.example.com/CamelCase.
                        ---
                        Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be
                        useful (see .node.status.conditions), the ability to deconflict is important.
                        The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt)
                      maxLength: 316
                      pattern: ^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])$
                      type: string
                  required:
                  - lastTransitionTime
                  - message
                  - reason
                  - status
                  - type
                  type: object
                type: array
              expirationTimestamp:
                description: ExpirationTimestamp is the time when the token will expire.
                format: date-time
                type: string
              tokenSecretRef:
                description: |-
                  TokenSecretRef is a reference to the corresponding ServiceAccount's Secret, which stores
                  the CA certficate and token from the managed cluster.
                properties:
                  lastRefreshTimestamp:
                    description: |-
                      LastRefreshTimestamp is the timestamp indicating when the token in the Secret
                      is refreshed.
                    format: date-time
                    type: string
                  name:
                    description: Name is the name of the referenced secret.
                    type: string
                required:
                - lastRefreshTimestamp
                - name
                type: object
            type: object
        type: object
    served: true
    storage: true
    subresources:
      status: {}
Copy to Clipboard Toggle word wrap
1.11.5.2.2. 단일 ManagedServiceAccount 쿼리
링크 복사
GET /authentication.open-cluster-management.io/v1beta1/namespaces/{namespace}/managedserviceaccounts/{managedserviceaccount_name}
Copy to Clipboard Toggle word wrap
1.11.5.2.2.1. 설명
링크 복사

자세한 내용은 단일 ManagedServiceAccount 를 쿼리합니다.

1.11.5.2.2.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

managedserviceaccount_name
required

쿼리할 ManagedServiceAccount 의 이름입니다.

string

1.11.5.2.2.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.5.2.2.4. 태그
링크 복사
  • managedserviceaccounts.authentication.open-cluster-management.io
1.11.5.2.3. Delete a ManagedServiceAccount
링크 복사
DELETE /authentication.open-cluster-management.io/v1beta1/namespaces/{namespace}/managedserviceaccounts/{managedserviceaccount_name}
Copy to Clipboard Toggle word wrap
1.11.5.2.3.1. 설명
링크 복사

단일 ManagedServiceAccount 를 삭제합니다.

1.11.5.2.3.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

managedserviceaccount_name
required

삭제할 ManagedServiceAccount 의 이름입니다.

string

1.11.5.2.3.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.5.2.3.4. 태그
링크 복사
  • managedserviceaccounts.authentication.open-cluster-management.io
1.11.5.3. 정의
링크 복사
1.11.5.3.1. ManagedServiceAccount
링크 복사
Expand
이름설명스키마

apiVersion
required

ManagedServiceAccount 의 버전이 지정된 스키마입니다.

string

종류
필요

REST 리소스를 나타내는 문자열 값입니다.

string

메타데이터
필요

ManagedServiceAccount 의 메타 데이터입니다.

object

사양
필요

ManagedServiceAccount 의 사양입니다.

 

1.11.6. MultiClusterEngine API (v1alpha1)
링크 복사

deprecated: API에 대한 문서는 더 이상 사용되지 않습니다. 콘솔 또는 oc 명령에서 API Explorer 를 사용하여 현재 및 지원되는 API를 확인합니다.

1.11.6.1. 개요
링크 복사

이 문서는 Kubernetes용 다중 클러스터 엔진의 MultiClusterEngine 리소스에 대한 것입니다. MultiClusterEngine 리소스에는 생성, 쿼리, 삭제 및 업데이트의 네 가지 가능한 요청이 있습니다.

1.11.6.1.1. URI 스키마
링크 복사

BasePath : /kubernetes/apis
Schemes : HTTPS

1.11.6.1.2. 태그
링크 복사
  • multiclusterengines.multicluster.openshift.io : MultiClusterEngines 생성 및 관리
1.11.6.2. 경로
링크 복사
1.11.6.2.1. MultiClusterEngine 생성
링크 복사
POST /apis/multicluster.openshift.io/v1alpha1/multiclusterengines
Copy to Clipboard Toggle word wrap
1.11.6.2.1.1. 설명
링크 복사

MultiClusterEngine을 생성합니다.

1.11.6.2.1.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

본문

본문
필요

생성할 MultiClusterEngine을 설명하는 매개변수입니다.

MultiClusterEngine

1.11.6.2.1.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.6.2.1.4. 사용
링크 복사
  • MultiClusterEngines/yaml
1.11.6.2.1.5. 태그
링크 복사
  • multiclusterengines.multicluster.openshift.io
1.11.6.2.1.5.1. 요청 본문
링크 복사
{
  "apiVersion": "apiextensions.k8s.io/v1",
  "kind": "CustomResourceDefinition",
  "metadata": {
    "annotations": {
      "controller-gen.kubebuilder.io/version": "v0.4.1"
    },
    "creationTimestamp": null,
    "name": "multiclusterengines.multicluster.openshift.io"
  },
  "spec": {
    "group": "multicluster.openshift.io",
    "names": {
      "kind": "MultiClusterEngine",
      "listKind": "MultiClusterEngineList",
      "plural": "multiclusterengines",
      "shortNames": [
        "mce"
      ],
      "singular": "multiclusterengine"
    },
    "scope": "Cluster",
    "versions": [
      {
        "additionalPrinterColumns": [
          {
            "description": "The overall state of the MultiClusterEngine",
            "jsonPath": ".status.phase",
            "name": "Status",
            "type": "string"
          },
          {
            "jsonPath": ".metadata.creationTimestamp",
            "name": "Age",
            "type": "date"
          }
        ],
        "name": "v1alpha1",
        "schema": {
          "openAPIV3Schema": {
            "description": "MultiClusterEngine is the Schema for the multiclusterengines\nAPI",
            "properties": {
              "apiVersion": {
                "description": "APIVersion defines the versioned schema of this representation\nof an object. Servers should convert recognized schemas to the latest\ninternal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources",
                "type": "string"
              },
              "kind": {
                "description": "Kind is a string value representing the REST resource this\nobject represents. Servers may infer this from the endpoint the client\nsubmits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds",
                "type": "string"
              },
              "metadata": {
                "type": "object"
              },
              "spec": {
                "description": "MultiClusterEngineSpec defines the desired state of MultiClusterEngine",
                "properties": {
                  "imagePullSecret": {
                    "description": "Override pull secret for accessing MultiClusterEngine\noperand and endpoint images",
                    "type": "string"
                  },
                  "nodeSelector": {
                    "additionalProperties": {
                      "type": "string"
                    },
                    "description": "Set the nodeselectors",
                    "type": "object"
                  },
                  "targetNamespace": {
                    "description": "Location where MCE resources will be placed",
                    "type": "string"
                  },
                  "tolerations": {
                    "description": "Tolerations causes all components to tolerate any taints.",
                    "items": {
                      "description": "The pod this Toleration is attached to tolerates any\ntaint that matches the triple <key,value,effect> using the matching\noperator <operator>.",
                      "properties": {
                        "effect": {
                          "description": "Effect indicates the taint effect to match. Empty\nmeans match all taint effects. When specified, allowed values\nare NoSchedule, PreferNoSchedule and NoExecute.",
                          "type": "string"
                        },
                        "key": {
                          "description": "Key is the taint key that the toleration applies\nto. Empty means match all taint keys. If the key is empty,\noperator must be Exists; this combination means to match all\nvalues and all keys.",
                          "type": "string"
                        },
                        "operator": {
                          "description": "Operator represents a key's relationship to the\nvalue. Valid operators are Exists and Equal. Defaults to Equal.\nExists is equivalent to wildcard for value, so that a pod\ncan tolerate all taints of a particular category.",
                          "type": "string"
                        },
                        "tolerationSeconds": {
                          "description": "TolerationSeconds represents the period of time\nthe toleration (which must be of effect NoExecute, otherwise\nthis field is ignored) tolerates the taint. By default, it\nis not set, which means tolerate the taint forever (do not\nevict). Zero and negative values will be treated as 0 (evict\nimmediately) by the system.",
                          "format": "int64",
                          "type": "integer"
                        },
                        "value": {
                          "description": "Value is the taint value the toleration matches\nto. If the operator is Exists, the value should be empty,\notherwise just a regular string.",
                          "type": "string"
                        }
                      },
                      "type": "object"
                    },
                    "type": "array"
                  }
                },
                "type": "object"
              },
              "status": {
                "description": "MultiClusterEngineStatus defines the observed state of MultiClusterEngine",
                "properties": {
                  "components": {
                    "items": {
                      "description": "ComponentCondition contains condition information for\ntracked components",
                      "properties": {
                        "kind": {
                          "description": "The resource kind this condition represents",
                          "type": "string"
                        },
                        "lastTransitionTime": {
                          "description": "LastTransitionTime is the last time the condition\nchanged from one status to another.",
                          "format": "date-time",
                          "type": "string"
                        },
                        "message": {
                          "description": "Message is a human-readable message indicating\ndetails about the last status change.",
                          "type": "string"
                        },
                        "name": {
                          "description": "The component name",
                          "type": "string"
                        },
                        "reason": {
                          "description": "Reason is a (brief) reason for the condition's\nlast status change.",
                          "type": "string"
                        },
                        "status": {
                          "description": "Status is the status of the condition. One of True,\nFalse, Unknown.",
                          "type": "string"
                        },
                        "type": {
                          "description": "Type is the type of the cluster condition.",
                          "type": "string"
                        }
                      },
                      "type": "object"
                    },
                    "type": "array"
                  },
                  "conditions": {
                    "items": {
                      "properties": {
                        "lastTransitionTime": {
                          "description": "LastTransitionTime is the last time the condition\nchanged from one status to another.",
                          "format": "date-time",
                          "type": "string"
                        },
                        "lastUpdateTime": {
                          "description": "The last time this condition was updated.",
                          "format": "date-time",
                          "type": "string"
                        },
                        "message": {
                          "description": "Message is a human-readable message indicating\ndetails about the last status change.",
                          "type": "string"
                        },
                        "reason": {
                          "description": "Reason is a (brief) reason for the condition's\nlast status change.",
                          "type": "string"
                        },
                        "status": {
                          "description": "Status is the status of the condition. One of True,\nFalse, Unknown.",
                          "type": "string"
                        },
                        "type": {
                          "description": "Type is the type of the cluster condition.",
                          "type": "string"
                        }
                      },
                      "type": "object"
                    },
                    "type": "array"
                  },
                  "phase": {
                    "description": "Latest observed overall state",
                    "type": "string"
                  }
                },
                "type": "object"
              }
            },
            "type": "object"
          }
        },
        "served": true,
        "storage": true,
        "subresources": {
          "status": {}
        }
      }
    ]
  },
  "status": {
    "acceptedNames": {
      "kind": "",
      "plural": ""
    },
    "conditions": [],
    "storedVersions": []
  }
}
Copy to Clipboard Toggle word wrap
1.11.6.2.2. 모든 MultiClusterEngines 쿼리
링크 복사
GET /apis/multicluster.openshift.io/v1alpha1/multiclusterengines
Copy to Clipboard Toggle word wrap
1.11.6.2.2.1. 설명
링크 복사

자세한 내용은 다중 클러스터 엔진을 쿼리합니다.

1.11.6.2.2.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

1.11.6.2.2.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.6.2.2.4. 사용
링크 복사
  • operator/yaml
1.11.6.2.2.5. 태그
링크 복사
  • multiclusterengines.multicluster.openshift.io
1.11.6.2.3. MultiClusterEngine Operator 삭제
링크 복사
DELETE /apis/multicluster.openshift.io/v1alpha1/multiclusterengines/{name}
Copy to Clipboard Toggle word wrap
1.11.6.2.3.1. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

이름
필요

삭제할 다중 클러스터 엔진의 이름입니다.

string

1.11.6.2.3.2. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.6.2.3.3. 태그
링크 복사
  • multiclusterengines.multicluster.openshift.io
1.11.6.3. 정의
링크 복사
1.11.6.3.1. MultiClusterEngine
링크 복사
Expand
이름설명스키마

apiVersion
required

MultiClusterEngines의 버전이 지정된 스키마입니다.

string

종류
필요

REST 리소스를 나타내는 문자열 값입니다.

string

메타데이터
필요

리소스를 정의하는 규칙을 설명합니다.

object

사양
필요

MultiClusterEngineSpec은 원하는 MultiClusterEngine 상태를 정의합니다.

사양 목록을참조하십시오.

1.11.6.3.2. 사양 목록
링크 복사
Expand
이름설명스키마

nodeSelector
optional

노드 선택기를 설정합니다.

map[string]string

imagePullSecret
optional

MultiClusterEngine 피연산자 및 끝점 이미지에 액세스하기 위해 풀 시크릿을 재정의합니다.

string

허용 오차
선택 사항

허용 오차를 사용하면 모든 구성 요소가 모든 테인트를 허용합니다.

[]corev1.Toleration

targetNamespace
optional

MCE 리소스가 배치되는 위치입니다.

string

1.11.7. 배치 API(v1beta1)
링크 복사

deprecated: API에 대한 문서는 더 이상 사용되지 않습니다. 콘솔 또는 oc 명령에서 API Explorer 를 사용하여 현재 및 지원되는 API를 확인합니다.

1.11.7.1. 개요
링크 복사

이 문서는 Kubernetes용 다중 클러스터 엔진의 배치 리소스에 대한 것입니다. 배치 리소스에는 생성, 쿼리, 삭제 및 업데이트의 네 가지 요청이 있습니다.

1.11.7.1.1. URI 스키마
링크 복사

BasePath : /kubernetes/apis
Schemes : HTTPS

1.11.7.1.2. 태그
링크 복사
  • cluster.open-cluster-management.io : 배치 생성 및 관리
1.11.7.2. 경로
링크 복사
1.11.7.2.1. 모든 배치 쿼리
링크 복사
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements
Copy to Clipboard Toggle word wrap
1.11.7.2.1.1. 설명
링크 복사

자세한 내용은 배치를 쿼리합니다.

1.11.7.2.1.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

1.11.7.2.1.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.7.2.1.4. 사용
링크 복사
  • placement/yaml
1.11.7.2.1.5. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.7.2.2. 배치 생성
링크 복사
POST /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements
Copy to Clipboard Toggle word wrap
1.11.7.2.2.1. 설명
링크 복사

배치를 생성합니다.

1.11.7.2.2.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

본문

본문
필요

생성할 배치를 설명하는 매개변수입니다.

배치

1.11.7.2.2.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.7.2.2.4. 사용
링크 복사
  • placement/yaml
1.11.7.2.2.5. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.7.2.2.6. HTTP 요청의 예
링크 복사
1.11.7.2.2.6.1. 요청 본문
링크 복사
{
  "apiVersion" : "cluster.open-cluster-management.io/v1beta1",
  "kind" : "Placement",
  "metadata" : {
    "name" : "placement1",
    "namespace": "ns1"
  },
  "spec": {
    "predicates": [
      {
        "requiredClusterSelector": {
          "labelSelector": {
            "matchLabels": {
              "vendor": "OpenShift"
            }
          }
        }
      }
    ]
  },
  "status" : { }
}
Copy to Clipboard Toggle word wrap
1.11.7.2.3. 단일 배치 쿼리
링크 복사
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements/{placement_name}
Copy to Clipboard Toggle word wrap
1.11.7.2.3.1. 설명
링크 복사

자세한 내용은 단일 배치를 쿼리합니다.

1.11.7.2.3.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

placement_name
required

쿼리할 배치의 이름입니다.

string

1.11.7.2.3.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.7.2.3.4. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.7.2.4. 배치 삭제
링크 복사
DELETE /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements/{placement_name}
Copy to Clipboard Toggle word wrap
1.11.7.2.4.1. 설명
링크 복사

단일 배치를 삭제합니다.

1.11.7.2.4.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

placement_name
required

삭제할 배치의 이름입니다.

string

1.11.7.2.4.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.7.2.4.4. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.7.3. 정의
링크 복사
1.11.7.3.1. 배치
링크 복사
Expand
이름설명스키마

apiVersion
required

배치의 버전이 지정된 스키마입니다.

string

종류
필요

REST 리소스를 나타내는 문자열 값입니다.

string

메타데이터
필요

배치의 메타 데이터입니다.

object

사양
필요

배치 사양입니다.

spec

spec

Expand
이름설명스키마

ClusterSets
선택 사항

ManagedClusters가 선택된 ManagedClusterSet의 서브 세트입니다. 비어 있는 경우 Placement 네임스페이스에 바인딩된 ManagedClusterSets에서 ManagedClusters가 선택됩니다. 그렇지 않으면 ManagedClusters가 이 하위 집합의 교차점에서 선택되며 ManagedClusterSets는 배치 네임스페이스에 바인딩됩니다.

문자열 배열

numberOfClusters
optional

선택할 ManagedCluster 수입니다.

integer (int32)

서술자
선택 사항

ManagedClusters를 선택하는 클러스터 서술자의 하위 집합입니다. 조건부 논리는 또는 입니다.

clusterPredicate 배열

clusterPredicate

Expand
이름설명스키마

requiredClusterSelector
optional

레이블 및 클러스터 클레임이 있는 ManagedClusters를 선택하는 클러스터 선택기입니다.

clusterSelector

clusterSelector

Expand
이름설명스키마

labelSelector
optional

라벨별 ManagedClusters 선택기입니다.

object

claimSelector
optional

클레임에 의한 ManagedCluster의 선택기입니다.

clusterClaimSelector

clusterClaimSelector

Expand
이름설명스키마

matchExpressions
optional

클러스터 클레임 선택기 요구 사항의 하위 집합입니다. 조건부 논리는 AND 입니다.

< object > array

1.11.8. PlacementDecisions API (v1beta1)
링크 복사

deprecated: API에 대한 문서는 더 이상 사용되지 않습니다. 콘솔 또는 oc 명령에서 API Explorer 를 사용하여 현재 및 지원되는 API를 확인합니다.

1.11.8.1. 개요
링크 복사

이 문서는 Kubernetes용 다중 클러스터 엔진의 PlacementDecision 리소스에 대한 것입니다. PlacementDecision 리소스에는 생성, 쿼리, 삭제 및 업데이트의 네 가지 가능한 요청이 있습니다.

1.11.8.1.1. URI 스키마
링크 복사

BasePath : /kubernetes/apis
Schemes : HTTPS

1.11.8.1.2. 태그
링크 복사
  • cluster.open-cluster-management.io : PlacementDecisions를 생성 및 관리합니다.
1.11.8.2. 경로
링크 복사
1.11.8.2.1. 모든 PlacementDecisions 쿼리
링크 복사
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions
Copy to Clipboard Toggle word wrap
1.11.8.2.1.1. 설명
링크 복사

자세한 내용은 PlacementDecisions를 쿼리합니다.

1.11.8.2.1.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

1.11.8.2.1.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.8.2.1.4. 사용
링크 복사
  • placementdecision/yaml
1.11.8.2.1.5. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.8.2.2. PlacementDecision 생성
링크 복사
POST /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions
Copy to Clipboard Toggle word wrap
1.11.8.2.2.1. 설명
링크 복사

PlacementDecision을 생성합니다.

1.11.8.2.2.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

본문

본문
필요

생성할 PlacementDecision을 설명하는 매개변수입니다.

PlacementDecision

1.11.8.2.2.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.8.2.2.4. 사용
링크 복사
  • placementdecision/yaml
1.11.8.2.2.5. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.8.2.2.6. HTTP 요청의 예
링크 복사
1.11.8.2.2.6.1. 요청 본문
링크 복사
{
  "apiVersion" : "cluster.open-cluster-management.io/v1beta1",
  "kind" : "PlacementDecision",
  "metadata" : {
    "labels" : {
      "cluster.open-cluster-management.io/placement" : "placement1"
    },
    "name" : "placement1-decision1",
    "namespace": "ns1"
  },
  "status" : { }
}
Copy to Clipboard Toggle word wrap
1.11.8.2.3. 단일 PlacementDecision 쿼리
링크 복사
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions/{placementdecision_name}
Copy to Clipboard Toggle word wrap
1.11.8.2.3.1. 설명
링크 복사

자세한 내용은 단일 PlacementDecision을 쿼리합니다.

1.11.8.2.3.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

placementdecision_name
required

쿼리할 PlacementDecision의 이름입니다.

string

1.11.8.2.3.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.8.2.3.4. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.8.2.4. PlacementDecision 삭제
링크 복사
DELETE /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions/{placementdecision_name}
Copy to Clipboard Toggle word wrap
1.11.8.2.4.1. 설명
링크 복사

단일 PlacementDecision을 삭제합니다.

1.11.8.2.4.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

placementdecision_name
required

삭제할 PlacementDecision의 이름입니다.

string

1.11.8.2.4.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.8.2.4.4. 태그
링크 복사
  • cluster.open-cluster-management.io
1.11.8.3. 정의
링크 복사
1.11.8.3.1. PlacementDecision
링크 복사
Expand
이름설명스키마

apiVersion
required

PlacementDecision의 버전이 지정된 스키마입니다.

string

종류
필요

REST 리소스를 나타내는 문자열 값입니다.

string

메타데이터
필요

PlacementDecision의 메타 데이터입니다.

object

1.11.9. KlusterletConfig API (v1alpha1)
링크 복사

deprecated: API에 대한 문서는 더 이상 사용되지 않습니다. 콘솔 또는 oc 명령에서 API Explorer 를 사용하여 현재 및 지원되는 API를 확인합니다.

1.11.9.1. 개요
링크 복사

이 문서는 Kubernetes 운영자용 다중 클러스터 엔진용 KlusterletConfig 리소스에 대한 것입니다. KlusterletConfig 리소스는 Klusterlet 설치를 구성하는 데 사용됩니다. 네 가지 가능한 요청은 create, query, delete, update 입니다.

1.11.9.1.1. URI 스키마
링크 복사

BasePath : /kubernetes/apis
Schemes : HTTPS

1.11.9.1.2. 태그
링크 복사
  • klusterletconfigs.config.open-cluster-management.io : klusterletconfigs 생성 및 관리
1.11.9.2. 경로
링크 복사
1.11.9.2.1. 모든 KlusterletConfig 쿼리
링크 복사
GET /config.open-cluster-management.io/v1alpha1/klusterletconfigs
Copy to Clipboard Toggle word wrap
1.11.9.2.1.1. 설명
링크 복사

자세한 내용은 모든 KlusterletConfig 를 쿼리합니다.

1.11.9.2.1.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

1.11.9.2.1.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

KlusterletConfig yaml

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.9.2.1.4. 사용
링크 복사
  • klusterletconfig/yaml
1.11.9.2.1.5. 태그
링크 복사
  • klusterletconfigs.config.open-cluster-management.io
1.11.9.2.2. Create a KlusterletConfig
링크 복사
POST /config.open-cluster-management.io/v1alpha1/klusterletconfigs
Copy to Clipboard Toggle word wrap
1.11.9.2.2.1. 설명
링크 복사

KlusterletConfig 를 만듭니다.

1.11.9.2.2.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

본문

본문
필요

생성할 KlusterletConfig를 설명하는 매개변수입니다.

klusterletconfig

1.11.9.2.2.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.9.2.2.4. 사용
링크 복사
  • klusterletconfig/yaml
1.11.9.2.2.5. 태그
링크 복사
  • klusterletconfigs.config.open-cluster-management.io
1.11.9.2.2.6. HTTP 요청의 예
링크 복사
1.11.9.2.2.6.1. 요청 본문
링크 복사
{
  "apiVersion": "apiextensions.k8s.io/v1",
  "kind": "CustomResourceDefinition",
  "metadata": {
    "annotations": {
      "controller-gen.kubebuilder.io/version": "v0.7.0"
    },
    "creationTimestamp": null,
    "name": "klusterletconfigs.config.open-cluster-management.io"
  },
  "spec": {
    "group": "config.open-cluster-management.io",
    "names": {
      "kind": "KlusterletConfig",
      "listKind": "KlusterletConfigList",
      "plural": "klusterletconfigs",
      "singular": "klusterletconfig"
    },
    "preserveUnknownFields": false,
    "scope": "Cluster",
    "versions": [
      {
        "name": "v1alpha1",
        "schema": {
          "openAPIV3Schema": {
            "description": "KlusterletConfig contains the configuration of a klusterlet including the upgrade strategy, config overrides, proxy configurations etc.",
            "properties": {
              "apiVersion": {
                "description": "APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources",
                "type": "string"
              },
              "kind": {
                "description": "Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds",
                "type": "string"
              },
              "metadata": {
                "type": "object"
              },
              "spec": {
                "description": "Spec defines the desired state of KlusterletConfig",
                "properties": {
                  "appliedManifestWorkEvictionGracePeriod": {
                    "description": "AppliedManifestWorkEvictionGracePeriod is the eviction grace period the work agent will wait before evicting the AppliedManifestWorks, whose corresponding ManifestWorks are missing on the hub cluster, from the managed cluster. If not present, the default value of the work agent will be used. If its value is set to \"INFINITE\", it means the AppliedManifestWorks will never been evicted from the managed cluster.",
                    "pattern": "^([0-9]+(s|m|h))+$|^INFINITE$",
                    "type": "string"
                  },
                  "bootstrapKubeConfigs": {
                    "description": "BootstrapKubeConfigSecrets is the list of secrets that reflects the Klusterlet.Spec.RegistrationConfiguration.BootstrapKubeConfigs.",
                    "properties": {
                      "localSecretsConfig": {
                        "description": "LocalSecretsConfig include a list of secrets that contains the kubeconfigs for ordered bootstrap kubeconifigs. The secrets must be in the same namespace where the agent controller runs.",
                        "properties": {
                          "hubConnectionTimeoutSeconds": {
                            "default": 600,
                            "description": "HubConnectionTimeoutSeconds is used to set the timeout of connecting to the hub cluster. When agent loses the connection to the hub over the timeout seconds, the agent do a rebootstrap. By default is 10 mins.",
                            "format": "int32",
                            "minimum": 180,
                            "type": "integer"
                          },
                          "kubeConfigSecrets": {
                            "description": "KubeConfigSecrets is a list of secret names. The secrets are in the same namespace where the agent controller runs.",
                            "items": {
                              "properties": {
                                "name": {
                                  "description": "Name is the name of the secret.",
                                  "type": "string"
                                }
                              },
                              "type": "object"
                            },
                            "type": "array"
                          }
                        },
                        "type": "object"
                      },
                      "type": {
                        "default": "None",
                        "description": "Type specifies the type of priority bootstrap kubeconfigs. By default, it is set to None, representing no priority bootstrap kubeconfigs are set.",
                        "enum": [
                          "None",
                          "LocalSecrets"
                        ],
                        "type": "string"
                      }
                    },
                    "type": "object"
                  },
                  "hubKubeAPIServerCABundle": {
                    "description": "HubKubeAPIServerCABundle is the CA bundle to verify the server certificate of the hub kube API against. If not present, CA bundle will be determined with the logic below: 1). Use the certificate of the named certificate configured in APIServer/cluster if FQDN matches; 2). Otherwise use the CA certificates from kube-root-ca.crt ConfigMap in the cluster namespace; \n Deprecated and maintained for backward compatibility, use HubKubeAPIServerConfig.ServerVarificationStrategy and HubKubeAPIServerConfig.TrustedCABundles instead",
                    "format": "byte",
                    "type": "string"
                  },
                  "hubKubeAPIServerConfig": {
                    "description": "HubKubeAPIServerConfig specifies the settings required for connecting to the hub Kube API server. If this field is present, the below deprecated fields will be ignored: - HubKubeAPIServerProxyConfig - HubKubeAPIServerURL - HubKubeAPIServerCABundle",
                    "properties": {
                      "proxyURL": {
                        "description": "ProxyURL is the URL to the proxy to be used for all requests made by client If an HTTPS proxy server is configured, you may also need to add the necessary CA certificates to TrustedCABundles.",
                        "type": "string"
                      },
                      "serverVerificationStrategy": {
                        "description": "ServerVerificationStrategy is the strategy used for verifying the server certification; The value could be \"UseSystemTruststore\", \"UseAutoDetectedCABundle\", \"UseCustomCABundles\", empty. \n When this strategy is not set or value is empty; if there is only one klusterletConfig configured for a cluster, the strategy is eaual to \"UseAutoDetectedCABundle\", if there are more than one klusterletConfigs, the empty strategy will be overrided by other non-empty strategies.",
                        "enum": [
                          "UseSystemTruststore",
                          "UseAutoDetectedCABundle",
                          "UseCustomCABundles"
                        ],
                        "type": "string"
                      },
                      "trustedCABundles": {
                        "description": "TrustedCABundles refers to a collection of user-provided CA bundles used for verifying the server certificate of the hub Kubernetes API If the ServerVerificationStrategy is set to \"UseSystemTruststore\", this field will be ignored. Otherwise, the CA certificates from the configured bundles will be appended to the klusterlet CA bundle.",
                        "items": {
                          "description": "CABundle is a user-provided CA bundle",
                          "properties": {
                            "caBundle": {
                              "description": "CABundle refers to a ConfigMap with label \"import.open-cluster-management.io/ca-bundle\" containing the user-provided CA bundle The key of the CA data could be \"ca-bundle.crt\", \"ca.crt\", or \"tls.crt\".",
                              "properties": {
                                "name": {
                                  "description": "name is the metadata.name of the referenced config map",
                                  "type": "string"
                                },
                                "namespace": {
                                  "description": "name is the metadata.namespace of the referenced config map",
                                  "type": "string"
                                }
                              },
                              "required": [
                                "name",
                                "namespace"
                              ],
                              "type": "object"
                            },
                            "name": {
                              "description": "Name is the identifier used to reference the CA bundle; Do not use \"auto-detected\" as the name since it is the reserved name for the auto-detected CA bundle.",
                              "type": "string"
                            }
                          },
                          "required": [
                            "caBundle",
                            "name"
                          ],
                          "type": "object"
                        },
                        "type": "array",
                        "x-kubernetes-list-map-keys": [
                          "name"
                        ],
                        "x-kubernetes-list-type": "map"
                      },
                      "url": {
                        "description": "URL is the endpoint of the hub Kube API server. If not present, the .status.apiServerURL of Infrastructure/cluster will be used as the default value. e.g. `oc get infrastructure cluster -o jsonpath='{.status.apiServerURL}'`",
                        "type": "string"
                      }
                    },
                    "type": "object"
                  },
                  "hubKubeAPIServerProxyConfig": {
                    "description": "HubKubeAPIServerProxyConfig holds proxy settings for connections between klusterlet/add-on agents on the managed cluster and the kube-apiserver on the hub cluster. Empty means no proxy settings is available. \n Deprecated and maintained for backward compatibility, use HubKubeAPIServerConfig.ProxyURL instead",
                    "properties": {
                      "caBundle": {
                        "description": "CABundle is a CA certificate bundle to verify the proxy server. It will be ignored if only HTTPProxy is set; And it is required when HTTPSProxy is set and self signed CA certificate is used by the proxy server.",
                        "format": "byte",
                        "type": "string"
                      },
                      "httpProxy": {
                        "description": "HTTPProxy is the URL of the proxy for HTTP requests",
                        "type": "string"
                      },
                      "httpsProxy": {
                        "description": "HTTPSProxy is the URL of the proxy for HTTPS requests HTTPSProxy will be chosen if both HTTPProxy and HTTPSProxy are set.",
                        "type": "string"
                      }
                    },
                    "type": "object"
                  },
                  "hubKubeAPIServerURL": {
                    "description": "HubKubeAPIServerURL is the URL of the hub Kube API server. If not present, the .status.apiServerURL of Infrastructure/cluster will be used as the default value. e.g. `oc get infrastructure cluster -o jsonpath='{.status.apiServerURL}'` \n Deprecated and maintained for backward compatibility, use HubKubeAPIServerConfig.URL instead",
                    "type": "string"
                  },
                  "installMode": {
                    "description": "InstallMode is the mode to install the klusterlet",
                    "properties": {
                      "noOperator": {
                        "description": "NoOperator is the setting of klusterlet installation when install type is noOperator.",
                        "properties": {
                          "postfix": {
                            "description": "Postfix is the postfix of the klusterlet name. The name of the klusterlet is \"klusterlet\" if it is not set, and \"klusterlet-{Postfix}\". The install namespace is \"open-cluster-management-agent\" if it is not set, and \"open-cluster-management-{Postfix}\".",
                            "maxLength": 33,
                            "pattern": "^[-a-z0-9]*[a-z0-9]$",
                            "type": "string"
                          }
                        },
                        "type": "object"
                      },
                      "type": {
                        "default": "default",
                        "description": "InstallModeType is the type of install mode.",
                        "enum": [
                          "default",
                          "noOperator"
                        ],
                        "type": "string"
                      }
                    },
                    "type": "object"
                  },
                  "nodePlacement": {
                    "description": "NodePlacement enables explicit control over the scheduling of the agent components. If the placement is nil, the placement is not specified, it will be omitted. If the placement is an empty object, the placement will match all nodes and tolerate nothing.",
                    "properties": {
                      "nodeSelector": {
                        "additionalProperties": {
                          "type": "string"
                        },
                        "description": "NodeSelector defines which Nodes the Pods are scheduled on. The default is an empty list.",
                        "type": "object"
                      },
                      "tolerations": {
                        "description": "Tolerations are attached by pods to tolerate any taint that matches the triple <key,value,effect> using the matching operator <operator>. The default is an empty list.",
                        "items": {
                          "description": "The pod this Toleration is attached to tolerates any taint that matches the triple <key,value,effect> using the matching operator <operator>.",
                          "properties": {
                            "effect": {
                              "description": "Effect indicates the taint effect to match. Empty means match all taint effects. When specified, allowed values are NoSchedule, PreferNoSchedule and NoExecute.",
                              "type": "string"
                            },
                            "key": {
                              "description": "Key is the taint key that the toleration applies to. Empty means match all taint keys. If the key is empty, operator must be Exists; this combination means to match all values and all keys.",
                              "type": "string"
                            },
                            "operator": {
                              "description": "Operator represents a key's relationship to the value. Valid operators are Exists and Equal. Defaults to Equal. Exists is equivalent to wildcard for value, so that a pod can tolerate all taints of a particular category.",
                              "type": "string"
                            },
                            "tolerationSeconds": {
                              "description": "TolerationSeconds represents the period of time the toleration (which must be of effect NoExecute, otherwise this field is ignored) tolerates the taint. By default, it is not set, which means tolerate the taint forever (do not evict). Zero and negative values will be treated as 0 (evict immediately) by the system.",
                              "format": "int64",
                              "type": "integer"
                            },
                            "value": {
                              "description": "Value is the taint value the toleration matches to. If the operator is Exists, the value should be empty, otherwise just a regular string.",
                              "type": "string"
                            }
                          },
                          "type": "object"
                        },
                        "type": "array"
                      }
                    },
                    "type": "object"
                  },
                  "pullSecret": {
                    "description": "PullSecret is the name of image pull secret.",
                    "properties": {
                      "apiVersion": {
                        "description": "API version of the referent.",
                        "type": "string"
                      },
                      "fieldPath": {
                        "description": "If referring to a piece of an object instead of an entire object, this string should contain a valid JSON/Go field access statement, such as desiredState.manifest.containers[2]. For example, if the object reference is to a container within a pod, this would take on a value like: \"spec.containers{name}\" (where \"name\" refers to the name of the container that triggered the event) or if no container name is specified \"spec.containers[2]\" (container with index 2 in this pod). This syntax is chosen only to have some well-defined way of referencing a part of an object. TODO: this design is not final and this field is subject to change in the future.",
                        "type": "string"
                      },
                      "kind": {
                        "description": "Kind of the referent. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds",
                        "type": "string"
                      },
                      "name": {
                        "description": "Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names",
                        "type": "string"
                      },
                      "namespace": {
                        "description": "Namespace of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/",
                        "type": "string"
                      },
                      "resourceVersion": {
                        "description": "Specific resourceVersion to which this reference is made, if any. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency",
                        "type": "string"
                      },
                      "uid": {
                        "description": "UID of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids",
                        "type": "string"
                      }
                    },
                    "type": "object",
                    "x-kubernetes-map-type": "atomic"
                  },
                  "registries": {
                    "description": "Registries includes the mirror and source registries. The source registry will be replaced by the Mirror.",
                    "items": {
                      "properties": {
                        "mirror": {
                          "description": "Mirror is the mirrored registry of the Source. Will be ignored if Mirror is empty.",
                          "type": "string"
                        },
                        "source": {
                          "description": "Source is the source registry. All image registries will be replaced by Mirror if Source is empty.",
                          "type": "string"
                        }
                      },
                      "required": [
                        "mirror"
                      ],
                      "type": "object"
                    },
                    "type": "array"
                  }
                },
                "type": "object"
              },
              "status": {
                "description": "Status defines the observed state of KlusterletConfig",
                "type": "object"
              }
            },
            "type": "object"
          }
        },
        "served": true,
        "storage": true,
        "subresources": {
          "status": {}
        }
      }
    ]
  },
  "status": {
    "acceptedNames": {
      "kind": "",
      "plural": ""
    },
    "conditions": [],
    "storedVersions": []
  }
}
Copy to Clipboard Toggle word wrap
1.11.9.2.3. 단일 klusterletconfig 쿼리
링크 복사
GET /config.open-cluster-management.io/v1alpha1/klusterletconfigs/{klusterletconfig_name}
Copy to Clipboard Toggle word wrap
1.11.9.2.3.1. 설명
링크 복사

자세한 내용은 단일 KlusterletConfig 를 쿼리합니다.

1.11.9.2.3.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

klusterletconfig_name
required

쿼리할 klusterletconfig의 이름입니다.

string

1.11.9.2.3.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

KlusterletConfig yaml

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.9.2.3.4. 태그
링크 복사
  • klusterletconfigs.config.open-cluster-management.io
1.11.9.2.4. klusterletconfig 삭제
링크 복사
DELETE /config.open-cluster-management.io/v1alpha1/klusterletconfigs/{klusterletconfig_name}
Copy to Clipboard Toggle word wrap
1.11.9.2.4.1. 설명
링크 복사

단일 KlusterletConfig 를 삭제합니다.

1.11.9.2.4.2. 매개 변수
링크 복사
Expand
유형이름설명스키마

Header

COOKIE
필요

권한 부여: Bearer {ACCESS_TOKEN}; ACCESS_TOKEN은 사용자 액세스 토큰입니다.

string

경로

klusterletconfig_name
required

삭제할 klusterletconfig의 이름입니다.

string

1.11.9.2.4.3. 응답
링크 복사
Expand
HTTP 코드설명스키마

200

성공

콘텐츠 없음

403

액세스 금지

콘텐츠 없음

404

리소스를 찾을 수 없음

콘텐츠 없음

500

내부 서비스 오류

콘텐츠 없음

503

서비스를 사용할 수 없음

콘텐츠 없음

1.11.9.2.4.4. 태그
링크 복사
  • klusterletconfig.authentication.open-cluster-management.io
1.11.9.3. 정의
링크 복사
1.11.9.3.1. klusterletconfig
링크 복사
Expand
이름설명스키마

apiVersion
required

klusterletconfig의 버전이 지정된 스키마입니다.

string

종류
필요

REST 리소스를 나타내는 문자열 값입니다.

string

메타데이터
필요

KlusterletConfig 의 메타 데이터입니다.

object

사양
필요

KlusterletConfig 사양입니다.

 

1.12. 문제 해결
링크 복사

문제 해결 가이드를 사용하기 전에 oc adm must-gather 명령을 실행하여 세부 정보, 로그 및 디버깅 문제 단계를 수행할 수 있습니다. 자세한 내용은 must-gather 명령 실행을 참조하십시오.

또한 역할 기반 액세스를 확인합니다. 자세한 내용은 다중 클러스터 엔진 운영자 역할 기반 액세스 제어를 참조하십시오.

1.12.1. 문서화된 문제 해결
링크 복사

다중 클러스터 엔진 Operator의 문제 해결 주제 목록을 확인합니다.

설치:

설치 작업의 기본 문서를 보려면 다중 클러스터 엔진 Operator 설치 및 업그레이드를 참조하십시오.

클러스터 관리:

클러스터 관리에 대한 주요 문서를 보려면 클러스터 라이프사이클 소개를 참조하십시오.

1.12.2. must-gather 명령을 실행하여 문제 해결
링크 복사

문제 해결을 시작하려면 사용자가 must-gather 명령을 실행하여 문제를 디버깅하는 데 필요한 문제 해결 시나리오에 대해 확인한 다음 명령 사용을 시작하는 절차를 참조하십시오.

필수 액세스: 클러스터 관리자

1.12.2.1. must-gather 시나리오
링크 복사

  • 시나리오 1: 문서화된 문제 해결 섹션을 사용하여 문제에 대한 해결 방법이 문서화되어 있는지 확인합니다. 이 가이드는 제품의 주요 기능에 의해 구성됩니다.

    이 시나리오에서는 가이드가 설명서에 있는지 확인합니다.

  • 시나리오 2: 해결 단계에 문제가 문서화되지 않은 경우 must-gather 명령을 실행하고 출력을 사용하여 문제를 디버깅합니다.
  • 시나리오 3: must-gather 명령의 출력을 사용하여 문제를 디버깅할 수 없는 경우 Red Hat 지원과 출력을 공유하십시오.
1.12.2.2. must-gather 절차
링크 복사

must-gather 명령을 사용하려면 다음 절차를 참조하십시오.

  1. must-gather 명령에 대해 알아보고 OpenShift Container Platform 설명서에서 클러스터에 대한 데이터 수집에 필요한 사전 요구 사항을 설치합니다.

  2. 클러스터에 로그인합니다. 일반적인 사용 사례의 경우 엔진 클러스터에 로그인하는 동안 must-gather 를 실행해야 합니다.

    참고: 관리 클러스터를 확인하려면 cluster-scoped-resources 디렉터리에 있는 gather-managed.log 파일을 찾습니다. 

    <your-directory>/cluster-scoped-resources/gather-managed.log>
    Copy to Clipboard Toggle word wrap

    JOINED 및 AVAILABLE 열에 True 가 설정되지 않은 관리형 클러스터를 확인합니다. True 상태와 연결되지 않은 클러스터에서 must-gather 명령을 실행할 수 있습니다.

  3. 데이터 및 디렉터리 수집에 사용되는 Kubernetes 이미지에 대한 다중 클러스터 엔진을 추가합니다. 다음 명령을 실행합니다. 
oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel9:v2.8 --dest-dir=<directory>
Copy to Clipboard Toggle word wrap

  1. 지정된 디렉터리로 이동하여 다음 수준에서 구성된 출력을 확인합니다.

    • 두 개의 피어 수준: cluster-scoped-resources 및 namespace resources.
    • 각 하위 수준: 클러스터 범위 및 네임스페이스 범위 리소스 모두에 대한 사용자 정의 리소스 정의에 대한 API 그룹입니다.
    • 유형별로 정렬된 YAML 파일 각의 다음 수준 .
1.12.2.3. 연결이 끊긴 환경의 must-gather
링크 복사

연결이 끊긴 환경에서 must-gather 명령을 실행하려면 다음 단계를 완료합니다.

  1. 연결이 끊긴 환경에서 Red Hat Operator 카탈로그 이미지를 미러 레지스트리에 미러링합니다. 자세한 내용은 연결이 끊긴 네트워크에 설치를 참조하십시오.
  2. 다음 명령을 실행하여 미러 레지스트리에서 이미지를 참조하는 로그를 추출합니다. sha256 을 현재 이미지로 교체합니다. 
REGISTRY=registry.example.com:5000
IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel9@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8>

oc adm must-gather --image=$IMAGE --dest-dir=./data
Copy to Clipboard Toggle word wrap

여기에서 제품 팀의 Jira 버그를 열 수 있습니다.

설치 중에 Zero Touch 프로비저닝 또는 호스트 인벤토리를 사용하여 Kubernetes Operator에 대해 다중 클러스터 엔진에 의해 생성된 기존 클러스터에 노드를 추가하거나 축소할 수 없습니다. 설치 프로세스는 검색 단계에서 올바르게 작동하지만 설치 단계에서는 실패합니다.

네트워크 구성이 실패합니다. 통합 콘솔의 hub 클러스터에서 Pending 사용자 작업이 표시됩니다. 설명에서 재부팅 단계에서 실패하는 것을 확인할 수 있습니다.

설치 호스트에서 실행 중인 에이전트에서 정보를 보고할 수 없기 때문에 실패에 대한 오류 메시지는 매우 정확하지 않습니다.

1.12.3.1. 증상: 2 일 작업자를 위한 설치 실패
링크 복사

Discover 단계 후에는 호스트가 재부팅되어 설치를 계속하지만 네트워크를 구성할 수 없습니다. 다음 증상 및 메시지를 확인합니다.

  • 통합 콘솔의 hub 클러스터에서 추가 노드에서 Pending 사용자 작업을 확인하고 재부팅 표시기를 사용합니다. 

    This host is pending user action. Host timed out when pulling ignition. Check the host console... Rebooting
    Copy to Clipboard Toggle word wrap

  • Red Hat OpenShift Container Platform 구성 관리 클러스터에서 기존 클러스터 의 MachineConfig 를 확인합니다. MachineConfigs 중 하나가 다음 디렉토리에 파일을 생성하는지 확인합니다.

    • /sysroot/etc/NetworkManager/system-connections/
    • /sysroot/etc/sysconfig/network-scripts/
  • 설치 호스트의 터미널에서 다음 메시지가 실패하는 호스트를 확인합니다. journalctl 을 사용하여 로그 메시지를 볼 수 있습니다. 
info: networking config is defined in the real root

info: will not attempt to propagate initramfs networking
Copy to Clipboard Toggle word wrap

로그에 마지막 메시지가 표시되면 이전에 Symptom 에 나열된 폴더에 기존 네트워크 구성이 이미 발견되었기 때문에 네트워킹 구성이 전파되지 않습니다.

1.12.3.2. 문제 해결: 노드 병합 네트워크 구성 다시 생성
링크 복사

설치 중에 적절한 네트워크 구성을 사용하려면 다음 작업을 수행합니다.

  1. 허브 클러스터에서 노드를 삭제합니다.
  2. 이전 프로세스를 반복하여 동일한 방식으로 노드를 설치합니다.

  3. 다음 주석을 사용하여 노드의 BareMetalHost 오브젝트를 생성합니다. 

    "bmac.agent-install.openshift.io/installer-args": "[\"--append-karg\", \"coreos.force_persist_ip\"]"
    Copy to Clipboard Toggle word wrap

노드가 설치를 시작합니다. 검색 단계 후 노드는 기존 클러스터의 변경 사항과 초기 구성 간의 네트워크 구성을 병합합니다.

에이전트 플랫폼에서 호스팅된 컨트롤 플레인 클러스터를 삭제하면 일반적으로 모든 백엔드 리소스가 삭제됩니다. 머신 리소스가 올바르게 삭제되지 않으면 클러스터 삭제에 실패합니다. 이 경우 나머지 시스템 리소스를 수동으로 제거해야 합니다.

에이전트 플랫폼에서 호스트된 컨트롤 플레인 클러스터를 제거하려고 하면 다음과 같은 오류와 함께 hcp destroy 명령이 실패합니다.

+ 

2024-02-22T09:56:19-05:00    ERROR    HostedCluster deletion failed    {"namespace": "clusters", "name": "hosted-0", "error": "context deadline exceeded"}
2024-02-22T09:56:19-05:00    ERROR    Failed to destroy cluster    {"error": "context deadline exceeded"}
Copy to Clipboard Toggle word wrap
1.12.4.2. 문제 해결: 나머지 머신 리소스를 수동으로 제거
링크 복사

에이전트 플랫폼에서 호스트된 컨트롤 플레인 클러스터를 성공적으로 제거하려면 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 < hosted_cluster_namespace>를 호스팅된 클러스터 네임스페이스 이름으로 교체하여 나머지 머신 리소스 목록을 확인합니다. 

    oc get machine -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap

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

    NAMESPACE           NAME             CLUSTER          NODENAME   PROVIDERID   PHASE      AGE   VERSION
clusters-hosted-0   hosted-0-9gg8b   hosted-0-nhdbp                           Deleting   10h   <4.x.0>-rc.8
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 머신 리소스에 연결된 machine.cluster.x-k8s.io 종료자를 제거합니다. 

    oc edit machines -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 터미널에 No resources found 메시지가 표시되는지 확인합니다. 

    oc get agentmachine -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 에이전트 플랫폼에서 호스팅된 컨트롤 플레인 클러스터를 제거합니다. 

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

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

1.12.5. 설치 또는 보류 중인 설치 상태 문제 해결
링크 복사

다중 클러스터 엔진 Operator를 설치할 때 MultiClusterEngine 은 Installing 단계에 남아 있거나 여러 Pod가 Pending 상태를 유지합니다.

1.12.5.1. 증상: 보류 중 상태 발생
링크 복사

MultiClusterEngine을 설치한 후 10분 이상 전달되었으며 MultiClusterEngine 리소스의 status.components 필드에서 하나 이상의 구성 요소가 ProgressDeadlineExceeded. 클러스터의 리소스 제약 조건이 문제가 될 수 있습니다.

MultiClusterEngine 이 설치된 네임스페이스에서 Pod를 확인합니다. 다음과 유사한 상태로 보류 중이 표시될 수 있습니다. 

reason: Unschedulable
message: '0/6 nodes are available: 3 Insufficient cpu, 3 node(s) had taint {node-role.kubernetes.io/master:
        }, that the pod didn't tolerate.'
Copy to Clipboard Toggle word wrap

이 경우 제품을 실행하기 위해 작업자 노드 리소스가 클러스터에 충분하지 않습니다.

1.12.5.2. 문제 해결: 작업자 노드 크기 조정
링크 복사

이 문제가 있는 경우 더 큰 작업자 노드로 클러스터를 업데이트해야 합니다. 클러스터 크기 지정에 대한 지침은 클러스터 크기 조정을 참조하십시오.

1.12.6. 설치 실패 문제 해결
링크 복사

다중 클러스터 엔진 Operator를 다시 설치할 때 Pod가 시작되지 않습니다.

1.12.6.1. 증상: 재설치 실패
링크 복사

다중 클러스터 엔진 Operator를 설치한 후 Pod가 시작되지 않는 경우 이전 멀티 클러스터 엔진 Operator의 항목이 제거될 때 올바르게 제거되지 않았기 때문에 종종 Pod가 시작되지 않습니다.

이 경우 설치 프로세스를 완료한 후 Pod가 시작되지 않습니다.

1.12.6.2. 문제 해결: 설치 실패
링크 복사

이 문제가 있는 경우 다음 단계를 완료합니다.

  1. 설치 제거 프로세스를 실행하여 설치 제거의 단계에 따라 현재 구성 요소를 제거합니다. ???
  2. Red Hat OpenShift Container Platform CLI가 oc 명령을 실행하도록 구성되어 있는지 확인합니다. oc 명령 구성에 대한 자세한 내용은 OpenShift Container Platform 설명서에서 OpenShift CLI 시작하기 를 참조하십시오.

  3. 다음 스크립트를 파일에 복사하여 스크립트의 < namespace > 값을 이전에 다중 클러스터 엔진 Operator를 설치한 네임스페이스 이름으로 교체합니다.

    중요: 스크립트를 실행할 때 네임스페이스도 정리 및 삭제되므로 올바른 네임스페이스를 지정했는지 확인합니다. 

    MCE_NAMESPACE=<namespace>
oc delete multiclusterengine --all
oc delete apiservice v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io
oc delete crd discoveredclusters.discovery.open-cluster-management.io discoveryconfigs.discovery.open-cluster-management.io
oc delete mutatingwebhookconfiguration ocm-mutating-webhook managedclustermutators.admission.cluster.open-cluster-management.io
oc delete validatingwebhookconfiguration ocm-validating-webhook
oc delete ns $MCE_NAMESPACE
    Copy to Clipboard Toggle word wrap
  4. 스크립트를 실행합니다. 리소스가 없는 메시지가 표시되면 설치를 진행할 수 있습니다.
  5. 설치를 실행합니다. 온라인으로 연결하는 동안 설치를 참조하십시오.

1.12.7. 오프라인 클러스터 문제 해결
링크 복사

오프라인 상태를 표시하는 클러스터에는 몇 가지 일반적인 원인이 있습니다.

1.12.7.1. 증상: 클러스터 상태가 오프라인 상태
링크 복사

클러스터 생성 절차를 완료한 후에는 Red Hat Advanced Cluster Management 콘솔에서 액세스할 수 없으며 오프라인 상태가 표시됩니다.

1.12.7.2. 문제 해결: 클러스터 상태가 오프라인 상태입니다.
링크 복사

  1. 관리 클러스터를 사용할 수 있는지 확인합니다. Red Hat Advanced Cluster Management 콘솔의 Clusters 영역에서 확인할 수 있습니다.

    사용할 수 없는 경우 관리 클러스터를 다시 시작하십시오.

  2. 관리 클러스터 상태가 여전히 오프라인 상태인 경우 다음 단계를 완료합니다.

    1. hub 클러스터에서 oc get managedcluster <cluster_name> -o yaml 명령을 실행합니다. & lt;cluster_name >을 클러스터 이름으로 바꿉니다.
    2. status.conditions 섹션을 찾습니다.
    3. ManagedClusterConditionAvailable 유형의 메시지를 확인하고 모든 문제를 해결합니다.

1.12.8. 관리형 클러스터 가져오기 실패 문제 해결
링크 복사

클러스터 가져오기에 실패하면 클러스터 가져오기에 실패한 이유를 확인하기 위해 수행할 수 있는 몇 가지 단계가 있습니다.

1.12.8.1. 증상: 가져온 클러스터를 사용할 수 없음
링크 복사

클러스터 가져오기 절차를 완료한 후에는 콘솔에서 액세스할 수 없습니다.

1.12.8.2. 문제 해결: 가져온 클러스터를 사용할 수 없음
링크 복사

가져오기를 시도한 후에는 가져온 클러스터를 사용할 수 없는 몇 가지 이유가 있을 수 있습니다. 클러스터 가져오기에 실패하면 가져오기에 실패한 이유를 찾을 때까지 다음 단계를 완료합니다.

  1. hub 클러스터에서 다음 명령을 실행하여 가져오기 컨트롤러가 실행 중인지 확인합니다. 

    kubectl -n multicluster-engine get pods -l app=managedcluster-import-controller-v2
    Copy to Clipboard Toggle word wrap

    실행 중인 Pod 두 개가 표시되어야 합니다. Pod 중 하나가 실행 중이 아닌 경우 다음 명령을 실행하여 로그를 확인하여 이유를 확인합니다. 

    kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1
    Copy to Clipboard Toggle word wrap

  2. hub 클러스터에서 다음 명령을 실행하여 가져오기 컨트롤러에서 관리 클러스터 가져오기 보안이 성공적으로 생성되었는지 확인합니다. 

    kubectl -n <managed_cluster_name> get secrets <managed_cluster_name>-import
    Copy to Clipboard Toggle word wrap

    가져오기 보안이 없는 경우 다음 명령을 실행하여 가져오기 컨트롤러의 로그 항목을 보고 생성되지 않은 이유를 확인합니다. 

    kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1 | grep importconfig-controller
    Copy to Clipboard Toggle word wrap

  3. 허브 클러스터에서 관리 클러스터가 로컬 클러스터이거나 Hive에서 프로비저닝하거나 자동 가져오기 시크릿이 있는 경우 다음 명령을 실행하여 관리 클러스터의 가져오기 상태를 확인합니다. 

    kubectl get managedcluster <managed_cluster_name> -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}' | grep ManagedClusterImportSucceeded
    Copy to Clipboard Toggle word wrap

    ManagedClusterImportSucceeded 조건이 true 가 아닌 경우 명령의 결과는 실패 이유를 나타냅니다.

  4. 성능이 저하된 상태에 대해 관리 클러스터의 Klusterlet 상태를 확인합니다. Klusterlet의 성능이 저하된 이유를 찾으려면 성능이 저하된 Klusterlet 문제 해결을 참조하십시오.

1.12.9. 알 수 없는 권한 오류로 클러스터 다시 가져오기 실패
링크 복사

관리 클러스터를 다중 클러스터 엔진 Operator 허브 클러스터로 다시 가져올 때 문제가 발생하는 경우 절차를 수행하여 문제를 해결합니다.

1.12.9.1. 증상: 알 수 없는 권한 오류로 클러스터 가져오기 실패
링크 복사

다중 클러스터 엔진 Operator를 사용하여 OpenShift Container Platform 클러스터를 프로비저닝한 후 OpenShift Container Platform 클러스터에 API 서버 인증서를 변경하거나 API 서버 인증서를 추가할 때 알 수 없는 기관에서 서명한 x509: 인증서로 클러스터를 다시 가져올 수 있습니다.

관리 클러스터를 다시 가져오지 못한 후 다음 명령을 실행하여 다중 클러스터 엔진 Operator 허브 클러스터에서 가져오기 컨트롤러 로그를 가져옵니다. 

kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 -f
Copy to Clipboard Toggle word wrap

다음 오류 로그가 표시되면 관리 클러스터 API 서버 인증서가 변경될 수 있습니다.

ERROR Reconciler error {"controller": "clusterdeployment-controller", "object": {"name":"awscluster1","namespace": "awscluster1", "name": "awscluster1", "reconcileID": "reconcileID": "a2cccf24-2547-4e26-f258a6710", "a2cccf24-2547-4e26-f258a6710", "error": "awscluster1"}

관리형 클러스터 API 서버 인증서가 변경되었는지 확인하려면 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 your-managed-cluster-name 을 관리 클러스터 이름으로 교체하여 관리 클러스터 이름을 지정합니다. 

    cluster_name=<your-managed-cluster-name>
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 관리형 클러스터 kubeconfig 시크릿 이름을 가져옵니다. 

    kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 kubeconfig 를 새 파일로 내보냅니다. 

    oc -n ${cluster_name} get secret ${kubeconfig_secret_name} -ojsonpath={.data.kubeconfig} | base64 -d > kubeconfig.old
    Copy to Clipboard Toggle word wrap 
    export KUBECONFIG=kubeconfig.old
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 kubeconfig 를 사용하여 관리 클러스터에서 네임스페이스를 가져옵니다. 

    oc get ns
    Copy to Clipboard Toggle word wrap

다음 메시지와 유사한 오류가 발생하면 클러스터 API 서버 ceritificates가 변경되었으며 kubeconfig 파일이 유효하지 않습니다.

서버에 연결할 수 없음: x509: 알 수 없는 기관에서 서명한 인증서

관리 클러스터 관리자는 관리 클러스터에 유효한 새 kubeconfig 파일을 생성해야 합니다.

새 kubeconfig 를 생성한 후 다음 단계를 완료하여 관리 클러스터의 새 kubeconfig 를 업데이트합니다.

  1. 다음 명령을 실행하여 kubeconfig 파일 경로와 클러스터 이름을 설정합니다. & lt;path_to_kubeconfig& gt;를 새 kubeconfig 파일의 경로로 바꿉니다. & lt;managed_cluster_name >을 관리 클러스터 이름으로 바꿉니다. 

    cluster_name=<managed_cluster_name>
kubeconfig_file=<path_to_kubeconfig>
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 새 kubeconfig 를 인코딩합니다. 

    kubeconfig=$(cat ${kubeconfig_file} | base64 -w0)
    Copy to Clipboard Toggle word wrap

    참고: macOS에서 다음 명령을 실행합니다. 

    kubeconfig=$(cat ${kubeconfig_file} | base64)
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 kubeconfig json 패치를 정의합니다. 

    kubeconfig_patch="[\{\"op\":\"replace\", \"path\":\"/data/kubeconfig\", \"value\":\"${kubeconfig}\"}, \{\"op\":\"replace\", \"path\":\"/data/raw-kubeconfig\", \"value\":\"${kubeconfig}\"}]"
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 관리 클러스터에서 관리자 kubeconfig 시크릿 이름을 검색합니다. 

    kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 관리자 kubeconfig 시크릿을 새 kubeconfig 로 패치합니다. 

    oc -n ${cluster_name} patch secrets ${kubeconfig_secret_name} --type='json' -p="${kubeconfig_patch}"
    Copy to Clipboard Toggle word wrap

1.12.10. 가져오기 보류 중 상태의 클러스터 문제 해결
링크 복사

클러스터 콘솔에서 보류 중 가져오기 가 계속되는 경우 절차에 따라 문제를 해결합니다.

1.12.10.1. 증상: 가져오기 상태가 보류 중인 클러스터
링크 복사

Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 가져온 후 클러스터에 Pending import 상태로 콘솔에 표시됩니다.

1.12.10.2. 문제 확인: 가져오기 보류 중인 클러스터
링크 복사

  1. 관리 클러스터에서 다음 명령을 실행하여 문제가 있는 Kubernetes Pod 이름을 확인합니다. 

    kubectl get pod -n open-cluster-management-agent | grep klusterlet-agent
    Copy to Clipboard Toggle word wrap

  2. 관리 클러스터에서 다음 명령을 실행하여 오류의 로그 항목을 찾습니다. 

    kubectl logs <klusterlet_agent_pod> -n open-cluster-management-agent
    Copy to Clipboard Toggle word wrap

    registration_agent_pod 를 1단계에서 확인한 포드 이름으로 교체합니다.

  3. 반환된 결과에 네트워킹 연결 문제가 있음을 나타내는 텍스트를 검색합니다. 예제에는 이러한 호스트가 없습니다.
1.12.10.3. 문제 해결: 가져오기 보류 중인 클러스터
링크 복사

  1. hub 클러스터에 다음 명령을 입력하여 문제가 있는 포트 번호를 검색합니다. 

    oc get infrastructure cluster -o yaml | grep apiServerURL
    Copy to Clipboard Toggle word wrap

  2. 관리 클러스터의 호스트 이름을 확인할 수 있고 호스트와 포트에 대한 아웃바운드 연결이 발생하는지 확인합니다.

    관리 클러스터에서 통신을 설정할 수 없는 경우 클러스터 가져오기가 완료되지 않습니다. 관리 클러스터의 클러스터 상태는 가져오기 보류 중입니다.

1.12.11. 인증서 변경 후 가져온 클러스터 오프라인 문제 해결
링크 복사

사용자 정의 apiserver 인증서 설치가 지원되지만 인증서 정보를 변경하기 전에 가져온 하나 이상의 클러스터의 상태가 오프라인 상태가 될 수 있습니다.

1.12.11.1. 증상: 인증서 변경 후 오프라인 클러스터
링크 복사

인증서 보안 업데이트 절차를 완료한 후 온라인 상태의 클러스터 중 하나 이상이 이제 콘솔에 오프라인 상태를 표시합니다.

1.12.11.2. 문제 식별: 인증서 변경 후 오프라인 클러스터
링크 복사

사용자 정의 API 서버 인증서에 대한 정보를 업데이트한 후 새 인증서가 이제 오프라인 상태가 되기 전에 가져온 클러스터입니다.

인증서가 문제가 있음을 나타내는 오류는 오프라인 관리 클러스터의 open-cluster-management-agent 네임스페이스에 있는 Pod 로그에서 확인할 수 있습니다. 다음 예제는 로그에 표시되는 오류와 유사합니다.

다음 work-agent 로그를 참조하십시오. 

E0917 03:04:05.874759       1 manifestwork_controller.go:179] Reconcile work test-1-klusterlet-addon-workmgr fails with err: Failed to update work status with err Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:05.874887       1 base_controller.go:231] "ManifestWorkAgent" controller failed to sync "test-1-klusterlet-addon-workmgr", err: Failed to update work status with err Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:37.245859       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManifestWork: failed to list *v1.ManifestWork: Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks?resourceVersion=607424": x509: certificate signed by unknown authority
Copy to Clipboard Toggle word wrap

다음 registration-agent 로그를 참조하십시오. 

I0917 02:27:41.525026       1 event.go:282] Event(v1.ObjectReference{Kind:"Namespace", Namespace:"open-cluster-management-agent", Name:"open-cluster-management-agent", UID:"", APIVersion:"v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'ManagedClusterAvailableConditionUpdated' update managed cluster "test-1" available condition to "True", due to "Managed cluster is available"
E0917 02:58:26.315984       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1beta1.CertificateSigningRequest: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority
E0917 02:58:26.598343       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true": x509: certificate signed by unknown authority
E0917 02:58:27.613963       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: failed to list *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority
Copy to Clipboard Toggle word wrap
1.12.11.3. 문제 해결: 인증서 변경 후 오프라인 클러스터
링크 복사

관리 클러스터가 로컬 클러스터이거나 관리되는 클러스터 가 다중 클러스터 엔진 Operator에 의해 생성된 경우 관리 클러스터를 복구하기 위해 10분 이상 기다려야 합니다.

관리 클러스터를 즉시 복구하려면 hub 클러스터에서 관리 클러스터 가져오기 보안을 삭제하고 다중 클러스터 엔진 Operator를 사용하여 복구할 수 있습니다. 다음 명령을 실행합니다. 

oc delete secret -n <cluster_name> <cluster_name>-import
Copy to Clipboard Toggle word wrap

& lt;cluster_name >을 복구하려는 관리 클러스터의 이름으로 바꿉니다.

다중 클러스터 엔진 Operator를 사용하여 가져온 관리 클러스터를 복구하려면 다음 단계를 완료하십시오. 관리 클러스터를 다시 가져옵니다.

  1. hub 클러스터에서 다음 명령을 실행하여 관리 클러스터 가져오기 보안을 다시 생성합니다. 

    oc delete secret -n <cluster_name> <cluster_name>-import
    Copy to Clipboard Toggle word wrap

    & lt;cluster_name >을 가져올 관리 클러스터의 이름으로 바꿉니다.

  2. 허브 클러스터에서 다음 명령을 실행하여 관리 클러스터 가져오기 보안을 YAML 파일에 노출합니다. 

    oc get secret -n <cluster_name> <cluster_name>-import -ojsonpath='{.data.import\.yaml}' | base64 --decode  > import.yaml
    Copy to Clipboard Toggle word wrap

    & lt;cluster_name >을 가져올 관리 클러스터의 이름으로 바꿉니다.

  3. 관리 클러스터에서 다음 명령을 실행하여 import.yaml 파일을 적용합니다. 

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

참고: 이전 단계에서는 hub 클러스터에서 관리 클러스터를 분리하지 않습니다. 이 단계에서는 새 인증서 정보를 포함하여 관리 클러스터의 현재 설정으로 필요한 매니페스트를 업데이트합니다.

1.12.12. 클러스터 상태가 오프라인에서 사용 가능으로 변경 문제 해결
링크 복사

관리 클러스터의 상태는 환경 또는 클러스터를 수동으로 변경하지 않고 오프라인에서 사용 가능한 상태로 변경됩니다.

1.12.12.1. 증상: 클러스터 상태가 오프라인에서 사용 가능으로 변경
링크 복사

관리 클러스터를 허브 클러스터에 연결하는 네트워크가 불안정한 경우 허브 클러스터 사이클에 의해 오프라인 과 사용 가능 으로 보고되는 관리 클러스터의 상태가 불안정합니다.

이 문제를 해결하려면 다음 단계를 완료하십시오.

  1. 다음 명령을 입력하여 hub 클러스터에서 ManagedCluster 사양을 편집합니다. 

    oc edit managedcluster <cluster-name>
    Copy to Clipboard Toggle word wrap

    cluster-name 을 관리 클러스터의 이름으로 바꿉니다.

  2. ManagedCluster 사양에서 leaseDurationSeconds 값을 늘립니다. 기본값은 60초이며 관리 클러스터의 오프라인 유예 기간은 5분이며 리스DurationSeconds 의 5배입니다. 네트워크 문제와의 연결을 유지하기에 충분한 시간이 아닐 수 있습니다. 리스에 더 많은 시간을 지정합니다. 예를 들어 leaseDurationSeconds 를 240초로 설정하면 20분 오프라인 유예 기간이 제공됩니다.

1.12.13. VMware vSphere에서 클러스터 생성 문제 해결
링크 복사

VMware vSphere에서 Red Hat OpenShift Container Platform 클러스터를 생성할 때 문제가 발생하는 경우 다음 문제 해결 정보를 참조하여 문제가 해결되었는지 확인하십시오.

참고: VMware vSphere에서 클러스터 생성 프로세스가 실패하면 로그를 볼 수 있는 링크가 활성화되어 있지 않을 수 있습니다. 이 경우 hive-controllers Pod의 로그를 확인하여 문제를 식별할 수 있습니다. hive-controllers 로그는 hive 네임스페이스에 있습니다.

1.12.13.1. 인증서 IP SAN 오류와 함께 관리되는 클러스터 생성 실패
링크 복사

VMware vSphere에서 새 Red Hat OpenShift Container Platform 클러스터를 생성한 후 클러스터에 인증서 IP SAN 오류를 나타내는 오류 메시지와 함께 실패합니다.

관리 클러스터의 배포가 실패하고 배포 로그에 다음 오류를 반환합니다. 

time="2020-08-07T15:27:55Z" level=error msg="Error: error setting up new vSphere SOAP client: Post https://147.1.1.1/sdk: x509: cannot validate certificate for xx.xx.xx.xx because it doesn't contain any IP SANs"
time="2020-08-07T15:27:55Z" level=error
Copy to Clipboard Toggle word wrap

자격 증명의 IP 주소 대신 VMware vCenter 서버 정규화된 호스트 이름을 사용합니다. VMware vCenter CA 인증서를 업데이트하여 IP SAN을 포함할 수도 있습니다.

1.12.13.2. 알 수 없는 인증 기관으로 관리 클러스터 생성 실패
링크 복사

VMware vSphere에서 새 Red Hat OpenShift Container Platform 클러스터를 생성하면 인증서가 알 수 없는 기관에서 서명했기 때문에 클러스터가 실패합니다.

관리 클러스터의 배포가 실패하고 배포 로그에 다음 오류를 반환합니다. 

Error: error setting up new vSphere SOAP client: Post https://vspherehost.com/sdk: x509: certificate signed by unknown authority"
Copy to Clipboard Toggle word wrap

인증 정보를 생성할 때 인증 기관에서 올바른 인증서를 입력했는지 확인합니다.

1.12.13.3. 만료된 인증서로 관리되는 클러스터 생성 실패
링크 복사
1.12.13.3.1. 증상: 만료된 인증서로 관리 클러스터 생성에 실패합니다.
링크 복사

VMware vSphere에서 새 Red Hat OpenShift Container Platform 클러스터를 생성한 후 인증서가 만료되거나 유효하지 않기 때문에 클러스터가 실패합니다.

관리 클러스터의 배포가 실패하고 배포 로그에 다음 오류를 반환합니다. 

x509: certificate has expired or is not yet valid
Copy to Clipboard Toggle word wrap

ESXi 호스트의 시간이 동기화되었는지 확인합니다.

VMware vSphere에서 새 Red Hat OpenShift Container Platform 클러스터를 생성한 후 태그 지정을 사용할 수 있는 권한이 부족하기 때문에 클러스터가 실패합니다.

관리 클러스터의 배포가 실패하고 배포 로그에 다음 오류를 반환합니다. 

time="2020-08-07T19:41:58Z" level=debug msg="vsphere_tag_category.category: Creating..."
time="2020-08-07T19:41:58Z" level=error
time="2020-08-07T19:41:58Z" level=error msg="Error: could not create category: POST https://vspherehost.com/rest/com/vmware/cis/tagging/category: 403 Forbidden"
time="2020-08-07T19:41:58Z" level=error
time="2020-08-07T19:41:58Z" level=error msg="  on ../tmp/openshift-install-436877649/main.tf line 54, in resource \"vsphere_tag_category\" \"category\":"
time="2020-08-07T19:41:58Z" level=error msg="  54: resource \"vsphere_tag_category\" \"category\" {"
Copy to Clipboard Toggle word wrap

VMware vCenter 필수 계정 권한이 올바른지 확인합니다. 자세한 내용은 설치 중에 제거된 이미지 레지스트리 를 참조하십시오.

VMware vSphere에서 새 Red Hat OpenShift Container Platform 클러스터를 생성한 후 잘못된 dnsVIP가 있으므로 클러스터가 실패합니다.

VMware vSphere를 사용하여 새 관리 클러스터를 배포하려고 할 때 다음 메시지가 표시되면 VMware 설치 관리자 프로비저닝 인프라(IPI)를 지원하지 않는 이전 OpenShift Container Platform 릴리스 이미지가 있기 때문입니다. 

failed to fetch Master Machines: failed to load asset \\\"Install Config\\\": invalid \\\"install-config.yaml\\\" file: platform.vsphere.dnsVIP: Invalid value: \\\"\\\": \\\"\\\" is not a valid IP
Copy to Clipboard Toggle word wrap

VMware 설치 관리자 프로비저닝 인프라를 지원하는 이후 버전의 OpenShift Container Platform에서 릴리스 이미지를 선택합니다.

VMware vSphere에서 새 Red Hat OpenShift Container Platform 클러스터를 생성한 후 잘못된 네트워크 유형이 지정되어 있으므로 클러스터가 실패합니다.

1.12.13.6.2. 문제 식별: Managed cluster creation fails with incorrect network type
링크 복사

VMware vSphere를 사용하여 새 관리 클러스터를 배포하려고 할 때 다음 메시지가 표시되면 VMware Installer Provisioned Infrastructure (IPI)를 지원하지 않는 이전 OpenShift Container Platform 이미지가 있기 때문입니다. 

time="2020-08-11T14:31:38-04:00" level=debug msg="vsphereprivate_import_ova.import: Creating..."
time="2020-08-11T14:31:39-04:00" level=error
time="2020-08-11T14:31:39-04:00" level=error msg="Error: rpc error: code = Unavailable desc = transport is closing"
time="2020-08-11T14:31:39-04:00" level=error
time="2020-08-11T14:31:39-04:00" level=error
time="2020-08-11T14:31:39-04:00" level=fatal msg="failed to fetch Cluster: failed to generate asset \"Cluster\": failed to create cluster: failed to apply Terraform: failed to complete the change"
Copy to Clipboard Toggle word wrap

지정된 VMware 클러스터에 유효한 VMware vSphere 네트워크 유형을 선택합니다.

VMware vSphere에서 새 Red Hat OpenShift Container Platform 클러스터를 생성한 후 디스크 변경 사항을 처리할 때 오류가 있기 때문에 클러스터가 실패합니다.

다음과 유사한 메시지가 로그에 표시됩니다. 

ERROR
ERROR Error: error reconfiguring virtual machine: error processing disk changes post-clone: disk.0: ServerFaultCode: NoPermission: RESOURCE (vm-71:2000), ACTION (queryAssociatedProfile): RESOURCE (vm-71), ACTION (PolicyIDByVirtualDisk)
Copy to Clipboard Toggle word wrap

VMware vSphere 클라이언트를 사용하여 프로파일 중심 스토리지 권한에 대한 모든 권한을 사용자에게 부여합니다.

1.12.14. 보류 중 또는 실패 상태의 콘솔에서 클러스터 문제 해결
링크 복사

생성한 클러스터의 콘솔에서 Pending 상태 또는 실패 상태를 모니터링하는 경우 절차를 수행하여 문제를 해결합니다.

1.12.14.1. 증상: 보류 중이거나 실패한 콘솔의 클러스터
링크 복사

콘솔을 사용하여 새 클러스터를 생성하면 Pending 상태 이상으로 클러스터가 진행되지 않거나 Failed 상태가 표시됩니다.

1.12.14.2. 문제 식별: 보류 중이거나 실패한 콘솔의 클러스터
링크 복사

클러스터에 Failed 상태가 표시되면 클러스터의 세부 정보 페이지로 이동하여 제공된 로그 링크를 따릅니다. 로그를 찾을 수 없거나 클러스터에 Pending 상태가 표시되면 다음 절차를 계속 실행하여 로그를 확인합니다.

  • 절차 1

    1. 허브 클러스터에서 다음 명령을 실행하여 새 클러스터의 네임스페이스에 생성된 Kubernetes Pod의 이름을 확인합니다. 

      oc get pod -n <new_cluster_name>
      Copy to Clipboard Toggle word wrap

      new_cluster_name 을 생성한 클러스터 이름으로 교체합니다.

    2. 이름에 provision 문자열이 포함된 Pod가 나열되지 않은 경우 Procedure 2를 계속합니다. 제목에 프로비저닝 이 있는 Pod가 있는 경우 허브 클러스터에서 다음 명령을 실행하여 해당 Pod의 로그를 확인합니다. 

      oc logs <new_cluster_name_provision_pod_name> -n <new_cluster_name> -c hive
      Copy to Clipboard Toggle word wrap

      new_cluster_name_provision_pod_name 을 생성한 클러스터 이름 및 프로비저닝이 포함된 포드 이름으로 교체 합니다.

    3. 문제의 원인을 설명할 수 있는 로그에서 오류를 검색합니다.

  • 절차 2

    이름이 provision 인 Pod가 없는 경우 프로세스 초기에 문제가 발생했습니다. 로그를 보려면 다음 절차를 완료합니다.

    1. hub 클러스터에서 다음 명령을 실행합니다. 

      oc describe clusterdeployments -n <new_cluster_name>
      Copy to Clipboard Toggle word wrap

      new_cluster_name 을 생성한 클러스터 이름으로 교체합니다. 클러스터 설치 로그에 대한 자세한 내용은 Red Hat OpenShift 설명서의 설치 로그 수집을 참조하십시오.

    2. 리소스의 Status.Conditions.Message 및 Status.Conditions.Reason 항목에서 문제에 대한 추가 정보가 있는지 확인하십시오.
1.12.14.3. 문제 해결: 보류 중이거나 실패한 콘솔의 클러스터
링크 복사

로그에서 오류를 확인한 후 클러스터를 제거하고 다시 생성하기 전에 오류를 해결하는 방법을 확인합니다.

다음 예제에서는 지원되지 않는 영역을 선택할 때 발생할 수 있는 로그 오류와 이를 해결하는 데 필요한 작업을 제공합니다. 

No subnets provided for zones
Copy to Clipboard Toggle word wrap

클러스터를 생성할 때 지원되지 않는 리전 내에서 하나 이상의 영역을 선택했습니다. 클러스터를 재생성하여 문제를 해결할 때 다음 작업 중 하나를 완료합니다.

  • 지역 내에서 다른 영역을 선택합니다.
  • 다른 영역이 나열된 경우 지원을 제공하지 않는 영역을 생략합니다.
  • 클러스터의 다른 리전을 선택합니다.

로그에서 문제를 확인한 후 클러스터를 제거하고 다시 생성합니다.

클러스터 생성에 대한 자세한 내용은 클러스터 생성 을 참조하십시오.

1.12.15. 성능이 저하된 조건으로 Klusterlet 문제 해결
링크 복사

Klusterlet 성능이 저하된 조건은 관리 클러스터에서 Klusterlet 에이전트의 상태를 진단하는 데 도움이 될 수 있습니다. Klusterlet이 성능 저하된 상태에 있는 경우 관리 클러스터의 Klusterlet 에이전트에 문제를 해결해야 하는 오류가 있을 수 있습니다. Klusterlet degraded conditions that are set to True 를 참조하십시오.

1.12.15.1. 증상: Klusterlet은 성능 저하 상태에 있습니다.
링크 복사

관리 클러스터에 Klusterlet을 배포한 후 RegistrationDesiredDegraded 또는 WorkDesiredDegraded 상태에 True 상태가 표시됩니다.

1.12.15.2. 문제 식별: Klusterlet은 성능 저하된 상태에 있습니다.
링크 복사

  1. 관리 클러스터에서 다음 명령을 실행하여 Klusterlet 상태를 확인합니다. 

    kubectl get klusterlets klusterlet -oyaml
    Copy to Clipboard Toggle word wrap
  2. RegistrationDesiredDegraded 또는 WorkDesiredDegraded 를 확인하여 조건이 True 로 설정되어 있는지 확인합니다. 나열된 모든 성능이 저하된 조건에 대한 문제를 복구합니다.
1.12.15.3. 문제 해결: Klusterlet은 성능 저하 상태에 있습니다.
링크 복사

다음 성능 저하 상태의 목록과 이러한 문제를 해결하는 방법을 참조하십시오.

  • 상태가 True 이고 조건 이유가 있는 RegistrationDesiredDegraded 조건이 BootStrapSecretMissing 인 경우 open-cluster-management-agent 네임스페이스에 부트스트랩 시크릿을 생성해야 합니다.
  • RegistrationDesiredDegraded 조건이 True 를 표시하고 조건 이유가 BootstrapSecretError 또는 BootstrapSecretUnauthorized 이면 현재 부트스트랩 보안이 유효하지 않습니다. 현재 부트스트랩 시크릿을 삭제하고 open-cluster-management-agent 네임스페이스에 유효한 부트스트랩 시크릿을 다시 생성합니다.
  • RegistrationDesiredDegraded 및 WorkDesiredDegraded 에 True 가 표시되고 조건 이유가 HubKubeConfigSecretMissing 인 경우 Klusterlet을 삭제하고 다시 생성합니다.
  • RegistrationDesiredDegraded 및 WorkDesiredDegraded 에 True 가 표시되고 조건 이유가 ClusterNameMissing,KubeConfig Mising ,HubConfigSecretError 또는 HubConfigSecretUnauthorized, open-cluster-management-agent 네임스페이스에서 hub cluster kubeconfig 시크릿을 삭제합니다. 등록 에이전트는 다시 부팅되어 새 hub 클러스터 kubeconfig 시크릿을 가져옵니다.
  • RegistrationDesiredDegraded 에 True 가 표시되고 조건 이유가 GetRegistrationDeploymentFailed 또는 UnavailableRegistrationPod 인 경우 조건 메시지를 확인하여 문제 세부 정보를 가져오고 해결하려고 할 수 있습니다.
  • WorkDesiredDegraded 에 True 가 표시되고 조건 이유가 GetWorkDeploymentFailed 또는 UnavailableWorkPod 인 경우 상태 메시지를 확인하여 문제 세부 정보를 가져오고 해결하려고 할 수 있습니다.

1.12.16. 클러스터를 삭제한 후에도 네임스페이스가 남아 있음
링크 복사

관리 클러스터를 제거하면 일반적으로 네임스페이스가 클러스터 제거 프로세스의 일부로 제거됩니다. 드문 경우지만 네임스페이스에 일부 아티팩트가 남아 있습니다. 이 경우 네임스페이스를 수동으로 제거해야 합니다.

관리 클러스터를 제거한 후 네임스페이스는 제거되지 않습니다.

네임스페이스를 수동으로 제거하려면 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 <cluster_name> 네임스페이스에 남아 있는 리소스 목록을 생성합니다. 

    oc api-resources --verbs=list --namespaced -o name | grep -E '^secrets|^serviceaccounts|^managedclusteraddons|^roles|^rolebindings|^manifestworks|^leases|^managedclusterinfo|^appliedmanifestworks'|^clusteroauths' | xargs -n 1 oc get --show-kind --ignore-not-found -n <cluster_name>
    Copy to Clipboard Toggle word wrap

    cluster_name 을 제거하려는 클러스터의 네임스페이스 이름으로 교체합니다.

  2. 다음 명령을 입력하여 목록을 편집하여 Delete 상태가 없는 목록에서 식별된 각 리소스를 삭제합니다. 

    oc edit <resource_kind> <resource_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    resource_kind 를 리소스 종류로 바꿉니다. resource_name 을 리소스 이름으로 교체합니다. namespace 를 리소스의 네임스페이스 이름으로 교체합니다.

  3. 메타데이터에서 종료자 속성을 찾습니다.
  4. vi 편집기 dd 명령을 사용하여 Kubernetes가 아닌 종료자를 삭제합니다.
  5. 목록을 저장하고 :wq 명령을 입력하여 vi 편집기를 종료합니다.

  6. 다음 명령을 입력하여 네임스페이스를 삭제합니다. 

    oc delete ns <cluster-name>
    Copy to Clipboard Toggle word wrap

    cluster-name 을 삭제하려는 네임스페이스 이름으로 교체합니다.

1.12.17. 클러스터를 가져올 때 auto-import-secret-exists 오류
링크 복사

자동 가져오기 보안이라는 오류 메시지와 함께 클러스터 가져오기가 실패합니다.

관리를 위해 하이브 클러스터를 가져올 때 자동 가져오기 보안 오류가 이미 표시됩니다.

1.12.17.2. 문제 해결: 클러스터를 가져올 때 Auto-import-secret-exists 오류
링크 복사

이 문제는 이전에 관리한 클러스터를 가져오려고 할 때 발생합니다. 이 경우 클러스터를 다시 가져오려고 할 때 보안이 충돌합니다.

이 문제를 해결하려면 다음 단계를 완료하십시오.

  1. 기존 auto-import-secret 을 수동으로 삭제하려면 hub 클러스터에서 다음 명령을 실행합니다. 

    oc delete secret auto-import-secret -n <cluster-namespace>
    Copy to Clipboard Toggle word wrap

    cluster-namespace 를 클러스터의 네임스페이스로 바꿉니다.

  2. 클러스터 가져오기 소개의 절차를 사용하여 클러스터를 다시 가져옵니다.

1.12.18. 배치 생성 후 누락된 PlacementDecision 문제 해결
링크 복사

배치를 생성한 후 Placement Descision 이 생성되지 않는 경우 절차에 따라 문제를 해결합니다.

1.12.18.1. 증상: 배치 생성 후 Placement 중단
링크 복사

배치를 생성하면 Placement Descision 이 자동으로 생성되지 않습니다.

1.12.18.2. 문제 해결: 배치 생성 후 placementDecision 해제
링크 복사

이 문제를 해결하려면 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 배치 조건을 확인합니다. 

    kubectl describe placement <placement-name>
    Copy to Clipboard Toggle word wrap

    placement-name 을 배치 이름으로 교체합니다.

    출력은 다음 예와 유사할 수 있습니다. 

    Name:         demo-placement
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  cluster.open-cluster-management.io/v1beta1
Kind:         Placement
Status:
  Conditions:
    Last Transition Time:       2022-09-30T07:39:45Z
    Message:                    Placement configurations check pass
    Reason:                     Succeedconfigured
    Status:                     False
    Type:                       PlacementMisconfigured
    Last Transition Time:       2022-09-30T07:39:45Z
    Message:                    No valid ManagedClusterSetBindings found in placement namespace
    Reason:                     NoManagedClusterSetBindings
    Status:                     False
    Type:                       PlacementSatisfied
  Number Of Selected Clusters:  0
    Copy to Clipboard Toggle word wrap

  2. PlacementMisconfigured 및 PlacementSatisfied:의 상태에 대한 출력을 확인합니다.

    • Placement Misconfigured Status 가 true이면 배치에 구성 오류가 발생합니다. 구성 오류 및 해결 방법에 대한 자세한 내용은 포함된 메시지를 확인하십시오.
    • Placement Satisfied Status 가 false인 경우 관리 클러스터가 배치를 충족하지 않습니다. 자세한 내용과 오류 해결 방법에 대해서는 포함된 메시지를 확인하십시오. 이전 예에서는 placement 네임스페이스에 ManagedClusterSetBindings 가 없습니다.

  3. 이벤트에서 각 클러스터의 점수를 확인하여 점수가 낮은 일부 클러스터가 선택되지 않은 이유를 확인할 수 있습니다. 출력은 다음 예와 유사할 수 있습니다. 

    Name:         demo-placement
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  cluster.open-cluster-management.io/v1beta1
Kind:         Placement
Events:
  Type    Reason          Age   From                 Message
  ----    ------          ----  ----                 -------
  Normal  DecisionCreate  2m10s   placementController  Decision demo-placement-decision-1 is created with placement demo-placement in namespace default
  Normal  DecisionUpdate  2m10s   placementController  Decision demo-placement-decision-1 is updated with placement demo-placement in namespace default
  Normal  ScoreUpdate     2m10s   placementController  cluster1:0 cluster2:100 cluster3:200
  Normal  DecisionUpdate  3s      placementController  Decision demo-placement-decision-1 is updated with placement demo-placement in namespace default
  Normal  ScoreUpdate     3s      placementController  cluster1:200 cluster2:145 cluster3:189 cluster4:200
    Copy to Clipboard Toggle word wrap

    참고: 배치 컨트롤러는 점수를 할당하고 각 필터링된 ManagedCluster 에 대한 이벤트를 생성합니다. 배치 컨트롤러는 클러스터 점수가 변경될 때 새 이벤트를 생성합니다.

1.12.19. Dell 하드웨어에서 베어 메탈 호스트의 검색 실패 문제 해결
링크 복사

Dell 하드웨어에서 베어 메탈 호스트를 검색하지 못하면 IDRAC(Integrated Dell Remote Access Controller)가 알려지지 않은 인증 기관의 인증서를 허용하지 않도록 구성됩니다.

1.12.19.1. 증상: Dell 하드웨어에서 베어 메탈 호스트의 검색 실패
링크 복사

베이스 보드 관리 컨트롤러를 사용하여 베어 메탈 호스트를 검색하는 절차를 완료하면 다음과 유사한 오류 메시지가 표시됩니다. 

ProvisioningError 51s metal3-baremetal-controller Image provisioning failed: Deploy step deploy.deploy failed with BadRequestError: HTTP POST https://<bmc_address>/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia returned code 400. Base.1.8.GeneralError: A general error has occurred. See ExtendedInfo for more information Extended information: [
{"Message": "Unable to mount remote share https://<ironic_address>/redfish/boot-<uuid>.iso.", 'MessageArgs': ["https://<ironic_address>/redfish/boot-<uuid>.iso"], "MessageArgs@odata.count": 1, "MessageId": "IDRAC.2.5.RAC0720", "RelatedProperties": ["#/Image"], "RelatedProperties@odata.count": 1, "Resolution": "Retry the operation.", "Severity": "Informational"}
]
Copy to Clipboard Toggle word wrap
1.12.19.2. 문제 해결: Dell 하드웨어에서 베어 메탈 호스트의 검색 실패
링크 복사

iDRAC는 알 수 없는 인증 기관의 인증서를 수락하지 않도록 구성되어 있습니다.

이 문제를 바이패스하려면 다음 단계를 완료하여 호스트 iDRAC의 베이스 보드 관리 컨트롤러에서 인증서 확인을 비활성화합니다.

  1. iDRAC 콘솔에서 구성 > 가상 미디어 > 원격 파일 공유로 이동합니다.
  2. Expired 또는 잘못된 인증서 작업 의 값을 Yes 로 변경합니다.

1.12.20. 최소 ISO 부팅 실패 문제 해결
링크 복사

최소한의 ISO를 부팅하려고 할 때 문제가 발생할 수 있습니다.

1.12.20.1. 증상: 최소 ISO 부팅 실패
링크 복사

부팅 화면에서 호스트가 루트 파일 시스템 이미지를 다운로드하지 못했음을 보여줍니다.

1.12.20.2. 문제 해결: 최소 ISO 부팅 실패
링크 복사

문제 해결 방법을 알아보려면 OpenShift Container Platform} 지원 설치 관리자의 최소 검색 ISO 문제 해결을 참조하십시오.

1.12.21. RHCOS 이미지 미러링 문제 해결
링크 복사

연결이 끊긴 환경의 Red Hat OpenShift Virtualization의 호스팅된 컨트롤 플레인의 경우 oc-mirror 가 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 내부 레지스트리에 자동으로 미러링하지 못합니다. 첫 번째 호스트 클러스터를 생성할 때 내부 레지스트리에서 부팅 이미지를 사용할 수 없으므로 Kubevirt 가상 머신이 부팅되지 않습니다.

1.12.21.1. 증상: oc-mirror 가 RHCOS 이미지 미러링을 시도하지 못했습니다
링크 복사

oc-mirror 플러그인은 릴리스 페이로드에서 내부 레지스트리로 {op-system-first} 이미지를 미러링하지 않습니다.

이 문제를 해결하려면 RHCOS 이미지를 내부 레지스트리에 수동으로 미러링합니다. 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 내부 레지스트리 이름을 가져옵니다. 

    oc get imagecontentsourcepolicy -o json | jq -r '.items[].spec.repositoryDigestMirrors[0].mirrors[0]'
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 페이로드 이미지를 가져옵니다. 

    oc get clusterversion version -ojsonpath='{.status.desired.image}'
    Copy to Clipboard Toggle word wrap

  3. 호스팅된 클러스터의 페이로드 이미지에서 부팅 이미지가 포함된 0000_50_installer_coreos-bootimages.yaml 파일을 추출합니다. & lt;payload_image >를 페이로드 이미지 이름으로 바꿉니다. 다음 명령을 실행합니다. 

    oc image extract --file /release-manifests/0000_50_installer_coreos-bootimages.yaml <payload_image> --confirm
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 RHCOS 이미지를 가져옵니다. 

    cat 0000_50_installer_coreos-bootimages.yaml | yq -r .data.stream | jq -r '.architectures.x86_64.images.kubevirt."digest-ref"'
    Copy to Clipboard Toggle word wrap

  5. RHCOS 이미지를 내부 레지스트리에 미러링합니다. < rhcos_image >를 RHCOS 이미지로 바꿉니다(예: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:d9643ead36b1c026be664c9c65c11433c6cdffd93ba229141d134a4a 694 . < internal_registry >를 내부 레지스트리의 이름으로 바꿉니다(예: virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev ). 다음 명령을 실행합니다. 

    oc image mirror <rhcos_image> <internal_registry>
    Copy to Clipboard Toggle word wrap

  6. ImageDigestMirrorSet 오브젝트를 정의하는 rhcos-boot-kubevirt.yaml 이라는 YAML 파일을 생성합니다. 다음 예제 구성을 참조하십시오. 

    apiVersion: config.openshift.io/v1
kind: ImageDigestMirrorSet
metadata:
  name: rhcos-boot-kubevirt
spec:
  repositoryDigestMirrors:
    - mirrors:
        - <rhcos_image_no_digest>
    1 
    
      source: virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev
    2
    Copy to Clipboard Toggle word wrap
    1
    다이제스트 없이 RHCOS 이미지를 지정합니다(예: quay.io/openshift-release-dev/ocp-v4.0-art-dev ).
    2
    내부 레지스트리의 이름을 지정합니다(예: virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev ).

  7. 다음 명령을 실행하여 rhcos-boot-kubevirt.yaml 파일을 적용하여 ImageDigestMirrorSet 오브젝트를 생성합니다. 

    oc apply -f rhcos-boot-kubevirt.yaml
    Copy to Clipboard Toggle word wrap

BareMetalHosts 없이 늦은 바인딩 관리 클러스터를 사용하는 경우 늦은 바인딩 클러스터를 제거하고 노드를 Discovery ISO로 반환하려면 추가 수동 단계를 완료해야 합니다.

1.12.22.1. 증상: 베어 메탈이 아닌 클러스터를 늦은 바인딩 풀로 반환
링크 복사

BareMetalHosts 가 없는 최신 바인딩 관리 클러스터의 경우 클러스터 정보를 제거해도 모든 노드를 Discovery ISO로 자동으로 반환하지는 않습니다.

늦은 바인딩으로 베어 메탈이 아닌 노드를 바인딩 해제하려면 다음 단계를 완료하십시오.

  1. 클러스터 정보를 제거합니다. 자세한 내용은 관리에서 클러스터 제거를 참조하십시오.
  2. 루트 디스크를 정리합니다.
  3. Discovery ISO를 사용하여 수동으로 재부팅합니다.

AWS 호스팅 클러스터의 Red Hat OpenShift Service의 모든 관리 클러스터의 상태는 갑자기 Unknown 이 됩니다.

klusterlet-agent Pod가 관리 클러스터의 open-cluster-management-agent 네임스페이스에 로그인하면 다음과 유사한 오류가 표시됩니다. 

E0809 18:45:29.450874       1 reflector.go:147] k8s.io/client-go@v0.29.4/tools/cache/reflector.go:229: Failed to watch *v1.CertificateSigningRequest: failed to list *v1.CertificateSigningRequest: Get "https://api.xxx.openshiftapps.com:443/apis/certificates.k8s.io/v1/certificatesigningrequests?limit=500&resourceVersion=0": tls: failed to verify certificate: x509: certificate signed by unknown authority
Copy to Clipboard Toggle word wrap
  1. 이름이 global 인 KlusterletConfig 리소스가 없는 경우 해당 리소스를 생성합니다.

  2. spec.hubKubeAPIServerConfig.serverVerificationStrategy 를 UseSystemTruststore 로 설정합니다. 다음 예제를 참조하십시오. 

    apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerConfig:
    serverVerificationStrategy: UseSystemTruststore
    Copy to Clipboard Toggle word wrap

  3. hub 클러스터에서 다음 명령을 실행하여 리소스를 적용합니다. & lt;filename >을 파일 이름으로 바꿉니다. 

    oc apply -f <filename>
    Copy to Clipboard Toggle word wrap

    일부 관리 클러스터의 상태가 복구될 수 있습니다. Unknown 상태로 유지되는 관리 클러스터의 프로세스를 계속합니다.

  4. hub 클러스터에서 다음 명령을 실행하여 import.yaml 'file from the hub cluster를 내보내고 디코딩합니다. '<cluster_name> 를 클러스터 이름으로 교체합니다. 

    oc get secret <cluster_name>-import -n <cluster_name> -o jsonpath={.data.import\.yaml} | base64 --decode > <cluster_name>-import.yaml
    Copy to Clipboard Toggle word wrap

  5. 관리 클러스터에서 다음 명령을 실행하여 파일을 적용합니다. 

    oc apply -f <cluster_name>-import.yaml
    Copy to Clipboard Toggle word wrap

콘솔에서 관리 클러스터를 업그레이드하려고 할 때 콘솔에 원하는 OpenShift Container Platform 버전이 표시되지 않습니다.

콘솔에서 관리 클러스터를 업그레이드하고 클러스터 세부 정보 뷰에서 사용 가능한 업그레이드 를 클릭하여 드롭다운 목록에서 OpenShift Container Platform 버전을 선택하면 버전이 누락됩니다.

다음 절차를 참조하십시오.

  1. 원하는 버전이 관리 클러스터의 ClusterVersion 리소스에 포함되어 있는지 확인합니다. 다음 명령을 실행합니다. 

    oc get clusterversion version -o jsonpath='{.status.availableUpdates[*].version}'
    Copy to Clipboard Toggle word wrap

    예상 버전이 표시되지 않으면 이 관리 클러스터에 해당 버전이 적용되지 않습니다.

  2. ManagedClusterInfo 리소스에 hub 클러스터의 버전이 포함되어 있는지 확인합니다. 다음 명령을 실행합니다. 

    oc -n <cluster_name> get managedclusterinfo <cluster_name> -o jsonpath='{.status.distributionInfo.ocp.availableUpdates[*]}'
    Copy to Clipboard Toggle word wrap

  3. 버전이 포함된 경우 hub 클러스터에 오류가 있는 ClusterCurator 리소스가 있는지 확인합니다. 다음 명령을 실행합니다. 

    oc -n <cluster_name> get ClusterCurator <cluster_name> -o yaml
    Copy to Clipboard Toggle word wrap

  4. ClusterCurator 리소스가 존재하고 clustercurator-job 조건의 상태가 False 인 경우 hub 클러스터에서 ClusterCurator 리소스를 삭제합니다. 다음 명령을 실행합니다. 

    oc -n <cluster_name> delete ClusterCurator <cluster_name>
    Copy to Clipboard Toggle word wrap

  5. ManagedClusterInfo 리소스에 버전이 포함되지 않은 경우 관리 클러스터에서 work-manager 애드온 로그를 확인하고 보고된 오류를 수정합니다. 다음 명령을 실행하고 해당 환경의 실제 이름으로 Pod 이름을 바꿉니다. 

    oc -n open-cluster-management-agent-addon logs klusterlet-addon-workmgr-<your_pod_name>
    Copy to Clipboard Toggle word wrap

Hive 프로비저닝 또는 지원 설치 관리자 클러스터에서 클러스터 CA(인증 기관)를 업데이트한 후 표시되는 연결 오류 메시지의 문제를 해결합니다.

Hive 프로비저닝 또는 지원 설치 프로그램 클러스터에서 엔터프라이즈 CA를 사용하여 클러스터 CA를 업데이트하면 허브 클러스터의 해당 클러스터 배포에 다음과 같은 연결 오류 메시지가 표시됩니다. 

x509: certificate signed by unknown authority
Copy to Clipboard Toggle word wrap

이 상태로 클러스터를 백업하고 복원하는 경우 관리 클러스터를 복원된 허브 클러스터로 자동으로 가져올 수 없습니다.

다음 절차를 사용하여 오류를 해결합니다.

  1. 시스템의 전역 변수를 사용하여 사용자 정의 CA를 정의합니다. 다음 명령을 실행합니다. 

    export CA=<your_customized_CA>
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 사용자 정의 CA로 새 보안을 생성합니다. 

    oc create secret generic additional-ca \
  --from-literal=ca.crt="$CA" \
  --namespace hive
    Copy to Clipboard Toggle word wrap

  3. 클러스터를 새 시크릿으로 업데이트합니다. 추가 CA 패치를 사용하여 다음 명령을 실행합니다. 

    oc patch hiveconfig hive --type=merge -p '
{
  "spec": {
    "additionalCertificateAuthoritiesSecretRef": [
      {
        "name": "additional-ca"
      }
    ]
  }
}'
    Copy to Clipboard Toggle word wrap

법적 공지
링크 복사

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

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat