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

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

콘솔에는 세 가지 최신 버전의 OpenShift Container Platform의 최신 릴리스 이미지만 표시됩니다. 예를 들어 콘솔 옵션에 다음 릴리스 이미지가 표시될 수 있습니다.

quay.io/openshift-release-dev/ocp-release:4.15.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

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

oc get clusterimageset

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

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

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

예를 들어 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

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

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

클러스터를 생성하기 전에 clusterImageSets 리포지토리를 복제하여 hub 클러스터에 적용해야 합니다. 다음 단계를 참조하십시오.

클러스터를 생성할 때 Red Hat OpenShift Container Platform 릴리스 이미지를 선택합니다.

참고: 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

ClusterDeployment 은 클러스터의 라이프사이클을 제어하는 데 사용되는 Hive 사용자 정의 리소스입니다.

Hive 사용 설명서에 따라 ClusterDeployment 사용자 정의 리소스를 생성하고 개별 클러스터를 생성합니다.

ClusterPool 은 여러 클러스터를 생성하는 데 사용되는 Hive 사용자 정의 리소스이기도 합니다.

Cluster Pools 문서에 따라 Hive ClusterPool API로 클러스터를 생성합니다.

추가 리소스 매니페스트가 포함된 구성 맵 리소스를 지정하는 ClusterDeployment 리소스에 참조를 추가합니다.

참고: ClusterDeployment 리소스 및 구성 맵은 동일한 네임스페이스에 있어야 합니다.

리소스 매니페스트가 있는 구성 맵을 사용하여 추가 매니페스트를 구성하려면 다음 단계를 완료합니다.

AWS에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.

AWS 클러스터 생성에 대한 다음 중요한 정보를 참조하십시오.

새 클러스터를 생성하려면 다음 절차를 참조하십시오. 대신 가져올 기존 클러스터가 있는 경우 클러스터 가져오기 를 참조하십시오.

참고: 클러스터를 가져오기 위해 클러스터 세부 정보가 제공된 oc 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator 관리 아래에 자동으로 구성됩니다.

인증 정보를 생성해야 하는 경우 자세한 내용은 Amazon Web Services에 대한 인증 정보 생성 을 참조하십시오.

클러스터 이름은 클러스터의 호스트 이름에 사용됩니다.

Kubernetes용 Red Hat Advanced Cluster Management를 사용하고 관리 클러스터 klusterlet을 특정 노드에서 실행하도록 구성하려면 선택 사항: 필요한 단계를 위해 특정 노드에서 실행되도록 klusterlet 구성 을 참조하십시오.

AWS GovCloud 클러스터를 생성하기 전에 다음 사전 요구 사항이 있어야합니다.

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

AWS GovCloud에서 클러스터를 생성하는 것은 표준 AWS에서 클러스터를 생성하는 것과 거의 동일하지만 AWS GovCloud에서 클러스터에 대한 AWS PrivateLink를 준비하기 위해 몇 가지 추가 단계를 완료해야 합니다.

spec:
  awsPrivateLink:
    ## The list of inventory of VPCs that can be used to create VPC
    ## endpoints by the controller.
    endpointVPCInventory:
    - region: us-east-1
      vpcID: vpc-1
      subnets:
      - availabilityZone: us-east-1a
        subnetID: subnet-11
      - availabilityZone: us-east-1b
        subnetID: subnet-12
      - availabilityZone: us-east-1c
        subnetID: subnet-13
      - availabilityZone: us-east-1d
        subnetID: subnet-14
      - availabilityZone: us-east-1e
        subnetID: subnet-15
      - availabilityZone: us-east-1f
        subnetID: subnet-16
    - region: us-east-1
      vpcID: vpc-2
      subnets:
      - availabilityZone: us-east-1a
        subnetID: subnet-21
      - availabilityZone: us-east-1b
        subnetID: subnet-22
      - availabilityZone: us-east-1c
        subnetID: subnet-23
      - availabilityZone: us-east-1d
        subnetID: subnet-24
      - availabilityZone: us-east-1e
        subnetID: subnet-25
      - availabilityZone: us-east-1f
        subnetID: subnet-26
    ## The credentialsSecretRef points to a secret with permissions to create.
    ## The resources in the account where the inventory of VPCs exist.
    credentialsSecretRef:
      name: <hub-account-credentials-secret-name>

    ## A list of VPC where various mce clusters exists.
    associatedVPCs:
    - region: region-mce1
      vpcID: vpc-mce1
      credentialsSecretRef:
        name: <credentials-that-have-access-to-account-where-MCE1-VPC-exists>
    - region: region-mce2
      vpcID: vpc-mce2
      credentialsSecretRef:
        name: <credentials-that-have-access-to-account-where-MCE2-VPC-exists>

콘솔에서 클러스터를 생성하려면 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을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지 릴리스를 참조하십시오.

노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동 관리를 공유합니다. 정보에는 다음 필드가 포함됩니다.

작업자 풀에 0개 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 단일 작업자 풀에 있거나 여러 작업자 풀에 배포할 수 있습니다. 제로 작업자 노드가 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 선택적 정보에는 다음 필드가 포함됩니다.

클러스터에 네트워킹 세부 정보가 필요하며 IPv6를 사용하려면 여러 네트워크가 필요합니다. AWS GovCloud 클러스터의 경우 Machine CIDR 필드에 Hive VPC의 주소 블록 값을 입력합니다. 네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다.

인증 정보에 제공된 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나, 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시를 생성하는 데 필요한 정보가 포함되어 있습니다.

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 구성 을 참조하십시오.

클러스터에 액세스하는 방법에 대한 지침은 클러스터 액세스를 계속합니다.

Azure에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.

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

다중 클러스터 엔진 Operator 콘솔에서 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 생성 을 클릭하고 콘솔의 단계를 완료합니다.

참고: 이 절차는 클러스터를 생성하기 위한 것입니다. 가져올 기존 클러스터가 있는 경우 해당 단계에 대한 클러스터 가져오기 를 참조하십시오.

인증 정보를 생성해야 하는 경우 자세한 내용은 Microsoft Azure에 대한 인증 정보 생성 을 참조하십시오.

클러스터 이름은 클러스터의 호스트 이름에 사용됩니다.

중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 모든 리소스가 삭제됩니다.

팁: 콘솔에서 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML 을 선택합니다.

기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin 권한이 없는 경우 clusterset-admin 권한이 있는 클러스터 세트를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없는 경우 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 클러스터 세트에 clusterset-admin 권한을 제공하려면 클러스터 관리자에게 문의하십시오.

모든 관리 클러스터는 관리 클러스터 세트와 연결되어 있어야 합니다. ManagedClusterSet 에 관리 클러스터를 할당하지 않으면 기본 관리 클러스터 세트에 자동으로 추가됩니다.

Azure 계정에 대해 구성한 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 값이 해당 필드에 채워집니다. 값을 덮어 쓰기하여 변경할 수 있습니다. 자세한 내용은 Azure 클라우드 서비스의 사용자 정의 도메인 이름 구성 을 참조하십시오. 이 이름은 클러스터의 호스트 이름에 사용됩니다.

릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전을 사용할 수 있는 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지의 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지 릴리스를 참조하십시오.

노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동 관리를 공유합니다. 정보에는 다음과 같은 선택적 필드가 포함됩니다.

클러스터를 생성한 후 컨트롤 플레인 풀의 인스턴스 유형 및 크기 및 루트 스토리지 할당(필수)을 변경할 수 있습니다.

작업자 풀에서 하나 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 단일 작업자 풀에 있거나 여러 작업자 풀에 배포할 수 있습니다. 제로 작업자 노드가 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 정보에는 다음 필드가 포함됩니다.

네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다. IPv6 주소를 사용하는 경우 두 개 이상의 네트워크가 있어야 합니다.

인증 정보에 제공된 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나, 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시를 생성하는 데 필요한 정보가 포함되어 있습니다.

정보를 검토하고 선택적으로 클러스터를 생성하기 전에 사용자 지정할 때 YAML 스위치를 클릭하여 패널의 install-config.yaml 파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.

Kubernetes용 Red Hat Advanced Cluster Management를 사용하고 관리 클러스터 klusterlet을 특정 노드에서 실행하도록 구성하려면 선택 사항: 필요한 단계를 위해 특정 노드에서 실행되도록 klusterlet 구성 을 참조하십시오.

참고: 클러스터를 가져오기 위해 클러스터 세부 정보가 제공된 oc 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator 관리 아래에 자동으로 구성됩니다.

클러스터에 액세스하는 방법에 대한 지침은 클러스터 액세스를 계속합니다.

GCP에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.

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

다중 클러스터 엔진 Operator 콘솔에서 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 생성 을 클릭하고 콘솔의 단계를 완료합니다.

참고: 이 절차는 클러스터를 생성하기 위한 것입니다. 가져올 기존 클러스터가 있는 경우 해당 단계에 대한 클러스터 가져오기 를 참조하십시오.

인증 정보를 생성해야 하는 경우 자세한 내용은 Google Cloud Platform의 인증 정보 생성 을 참조하십시오.

클러스터 이름은 클러스터의 호스트 이름에 사용됩니다. GCP 클러스터 이름 지정에 적용되는 몇 가지 제한 사항이 있습니다. 이러한 제한에는 goog 로 이름을 시작하거나 이름에 Google 과 유사한 문자 및 숫자 그룹이 포함되어 있지 않습니다. 전체 제한 목록은 버킷 이름 지정 지침을 참조하십시오.

중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 모든 리소스가 삭제됩니다.

팁: 콘솔에서 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML 을 선택합니다.

기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin 권한이 없는 경우 clusterset-admin 권한이 있는 클러스터 세트를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없는 경우 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 클러스터 세트에 clusterset-admin 권한을 제공하려면 클러스터 관리자에게 문의하십시오.

모든 관리 클러스터는 관리 클러스터 세트와 연결되어 있어야 합니다. ManagedClusterSet 에 관리 클러스터를 할당하지 않으면 기본 관리 클러스터 세트에 자동으로 추가됩니다.

GCP 계정에 대해 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 값이 필드에 채워집니다. 값을 덮어 쓰기하여 변경할 수 있습니다. 자세한 내용은 사용자 정의 도메인 설정을 참조하십시오. 이 이름은 클러스터의 호스트 이름에 사용됩니다.

릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전을 사용할 수 있는 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지의 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지 릴리스를 참조하십시오.

노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동 관리를 공유합니다. 정보에는 다음 필드가 포함됩니다.

컨트롤 플레인 풀의 인스턴스 유형을 지정할 수 있습니다. 인스턴스 유형 및 크기를 생성한 후 변경할 수 있습니다.

작업자 풀에서 하나 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 단일 작업자 풀에 있거나 여러 작업자 풀에 배포할 수 있습니다. 제로 작업자 노드가 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 정보에는 다음 필드가 포함됩니다.

네트워킹 세부 정보가 필요하며 IPv6 주소를 사용하려면 여러 네트워크가 필요합니다. 네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다.

인증 정보에 제공된 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나, 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시를 생성하는 데 필요한 정보가 포함되어 있습니다.

정보를 검토하고 선택적으로 클러스터를 생성하기 전에 사용자 지정할 때 YAML: On 을 선택하여 패널의 install-config.yaml 파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.

Kubernetes용 Red Hat Advanced Cluster Management를 사용하고 관리 클러스터 klusterlet을 특정 노드에서 실행하도록 구성하려면 선택 사항: 필요한 단계를 위해 특정 노드에서 실행되도록 klusterlet 구성 을 참조하십시오.

참고: 클러스터를 가져오기 위해 클러스터 세부 정보가 제공된 oc 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator 관리 아래에 자동으로 구성됩니다.

클러스터에 액세스하는 방법에 대한 지침은 클러스터 액세스를 계속합니다.

vSphere에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.

다중 클러스터 엔진 Operator 콘솔에서 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 생성 을 클릭하고 콘솔의 단계를 완료합니다.

참고: 이 절차는 클러스터를 생성하기 위한 것입니다. 가져올 기존 클러스터가 있는 경우 해당 단계에 대한 클러스터 가져오기 를 참조하십시오.

인증 정보를 생성해야 하는 경우 인증 정보 생성에 대한 자세한 내용은 VMware vSphere의 인증 정보 생성 을 참조하십시오.

클러스터 이름은 클러스터의 호스트 이름에 사용됩니다.

중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 모든 리소스가 삭제됩니다.

팁: 콘솔에서 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML 을 선택합니다.

기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin 권한이 없는 경우 clusterset-admin 권한이 있는 클러스터 세트를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없는 경우 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 클러스터 세트에 clusterset-admin 권한을 제공하려면 클러스터 관리자에게 문의하십시오.

모든 관리 클러스터는 관리 클러스터 세트와 연결되어 있어야 합니다. ManagedClusterSet 에 관리 클러스터를 할당하지 않으면 기본 관리 클러스터 세트에 자동으로 추가됩니다.

vSphere 계정에 대해 구성한 선택한 인증 정보와 연결된 기본 도메인이 이미 있는 경우 해당 값이 필드에 채워집니다. 값을 덮어 쓰기하여 변경할 수 있습니다. 자세한 내용은 사용자 지정으로 vSphere에 클러스터 설치를 참조하십시오. 이 값은 사전 요구 사항 섹션에 나열된 DNS 레코드를 생성하는 데 사용한 이름과 일치해야 합니다. 이 이름은 클러스터의 호스트 이름에 사용됩니다.

릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전을 사용할 수 있는 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지의 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지 릴리스를 참조하십시오.

참고: OpenShift Container Platform 버전 4.15 이상 버전의 릴리스 이미지가 지원됩니다.

노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동 관리를 공유합니다. 정보에는 CPU 아키텍처 필드가 포함됩니다. 다음 필드 설명을 표시합니다.

작업자 풀에서 하나 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 단일 작업자 풀에 있거나 여러 작업자 풀에 배포할 수 있습니다. 제로 작업자 노드가 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 정보에는 소켓당 코어,CPU,Memory_min MiB, _Disk 크기 (GiB) 및 노드 수가 포함됩니다.

네트워킹 정보가 필요합니다. IPv6를 사용하려면 여러 네트워크가 필요합니다. 필수 네트워킹 정보 중 일부는 다음 필드를 포함합니다.

네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다. IPv6 주소를 사용하는 경우 두 개 이상의 네트워크가 있어야 합니다.

인증 정보에 제공된 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나, 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시를 생성하는 데 필요한 정보가 포함되어 있습니다.

연결 해제된 설치를 클릭하여 연결 해제된 설치 이미지를 정의할 수 있습니다. Red Hat OpenStack Platform 공급자 및 연결이 끊긴 설치를 사용하여 클러스터를 생성할 때 인증서가 미러 레지스트리에 액세스해야 하는 경우, 클러스터를 생성할 때 연결 해제된 설치 구성 섹션의 추가 신뢰 번들 필드에 입력해야 합니다.

자동화 템플릿 추가를 클릭하여 템플릿을 생성할 수 있습니다.

정보를 검토하고 선택적으로 클러스터를 생성하기 전에 사용자 지정할 때 YAML 스위치를 클릭하여 패널의 install-config.yaml 파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.

Kubernetes용 Red Hat Advanced Cluster Management를 사용하고 관리 클러스터 klusterlet을 특정 노드에서 실행하도록 구성하려면 선택 사항: 필요한 단계를 위해 특정 노드에서 실행되도록 klusterlet 구성 을 참조하십시오.

참고: 클러스터를 가져오기 위해 클러스터 세부 정보가 제공된 oc 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator 관리 아래에 자동으로 구성됩니다.

클러스터에 액세스하는 방법에 대한 지침은 클러스터 액세스를 계속합니다.

Red Hat OpenStack Platform에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.

다중 클러스터 엔진 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 주소를 사용하는 경우 두 개 이상의 네트워크가 있어야 합니다.

인증 정보에 제공된 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나, 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시를 생성하는 데 필요한 정보가 포함되어 있습니다.

연결 해제된 설치를 클릭하여 연결 해제된 설치 이미지를 정의할 수 있습니다. Red Hat OpenStack Platform 공급자 및 연결이 끊긴 설치를 사용하여 클러스터를 생성할 때 인증서가 미러 레지스트리에 액세스해야 하는 경우, 클러스터를 생성할 때 연결 해제된 설치 구성 섹션의 추가 신뢰 번들 필드에 입력해야 합니다.

정보를 검토하고 선택적으로 클러스터를 생성하기 전에 사용자 지정할 때 YAML 스위치를 클릭하여 패널의 install-config.yaml 파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.

내부 CA(인증 기관)를 사용하는 클러스터를 생성할 때 다음 단계를 완료하여 클러스터의 YAML 파일을 사용자 지정해야 합니다.

Kubernetes용 Red Hat Advanced Cluster Management를 사용하고 관리 클러스터 klusterlet을 특정 노드에서 실행하도록 구성하려면 선택 사항: 필요한 단계를 위해 특정 노드에서 실행되도록 klusterlet 구성 을 참조하십시오.

참고: 클러스터를 가져오기 위해 클러스터 세부 정보가 제공된 oc 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator 관리 아래에 자동으로 구성됩니다.

클러스터에 액세스하는 방법에 대한 지침은 클러스터 액세스를 계속합니다.

온-프레미스 환경에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.

콘솔에서 클러스터를 생성하려면 다음 단계를 완료합니다.

지원되는 설치에 다음 옵션을 사용할 수 있습니다.

인증 정보를 생성해야 하는 경우 자세한 내용은 온-프레미스 환경에 대한 인증 정보 만들기 를 참조하십시오.

클러스터 이름은 클러스터의 호스트 이름에 사용됩니다.

중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 모든 리소스가 삭제됩니다.

참고: 콘솔에서 정보를 입력할 때 콘텐츠 업데이트를 보려면 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 클러스터에 작업자를 추가할 수 있습니다.

참고: 단일 노드 OpenShift 컨트롤 플레인에는 8개의 CPU 코어가 필요하지만 다중 노드 컨트롤 플레인 클러스터의 컨트롤 플레인 노드는 4개의 CPU 코어만 필요합니다.

클러스터를 검토하고 저장하면 클러스터가 초안 클러스터로 저장됩니다. 클러스터 페이지에서 클러스터 이름을 선택하여 생성 프로세스를 종료하고 나중에 프로세스를 완료할 수 있습니다.

기존 호스트를 사용하는 경우 호스트를 직접 선택할지 아니면 자동으로 선택하려는 경우 선택합니다. 호스트 수는 선택한 노드 수를 기반으로 합니다. 예를 들어 단일 노드 OpenShift 클러스터에는 하나의 호스트만 필요하지만 표준 3-노드 클러스터에는 3개의 호스트가 필요합니다.

이 클러스터의 요구 사항을 충족하는 사용 가능한 호스트의 위치는 호스트 위치 목록에 표시됩니다. 호스트 배포 및 고가용성 구성을 위해 여러 위치를 선택합니다.

기존 인프라 환경이 없는 새 호스트를 검색하는 경우 Discovery Image를 사용하여 호스트 인벤토리에 호스트 추가 단계를 완료합니다.

호스트가 바인딩되고 검증이 통과되면 다음 IP 주소를 추가하여 클러스터의 네트워킹 정보를 완료합니다.

Kubernetes용 Red Hat Advanced Cluster Management를 사용하고 관리 클러스터 klusterlet을 특정 노드에서 실행하도록 구성하려면 선택 사항: 필요한 단계를 위해 특정 노드에서 실행되도록 klusterlet 구성 을 참조하십시오.

클러스터 탐색 페이지에서 설치 상태를 볼 수 있습니다.

클러스터에 액세스하는 방법에 대한 지침은 클러스터 액세스를 계속합니다.

중앙 인프라 관리 구성 요소 내에서 지원 설치 관리자 기능을 사용하여 콘솔 없이 클러스터를 생성할 수도 있습니다. 이 절차를 완료하면 생성된 검색 이미지에서 호스트를 부팅할 수 있습니다. 절차 순서는 일반적으로 중요하지 않지만 필요한 순서가 있을 때 표시됩니다.

apiVersion: v1
kind: Namespace
metadata:
  name: sample-namespace

apiVersion: v1
kind: Secret
type: kubernetes.io/dockerconfigjson
metadata:
  name: <pull-secret>
  namespace: sample-namespace
stringData:
  .dockerconfigjson: 'your-pull-secret-json' 1

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  name: openshift-v4.15.0
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.15.0-rc.0-x86_64

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

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.15.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
  sshPublicKey: ssh-rsa <your-public-key-here> 4

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"

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

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

필수 사용자 유형 또는 액세스 수준: 클러스터 관리자

새 풀 시크릿을 생성해야 하는 경우 다음 단계를 완료합니다.

사용 가능한 각 클라우드 공급자에 대해 콘솔에서 기존 클러스터를 가져올 수 있습니다.

참고: 허브 클러스터는 다른 허브 클러스터를 관리할 수 없습니다. 허브 클러스터는 자동으로 자체적으로 가져오기 및 관리하도록 설정되어 있으므로 자체적으로 관리하기 위해 허브 클러스터를 수동으로 가져올 필요가 없습니다.

기본적으로 네임스페이스는 클러스터 이름과 네임스페이스에 사용되지만 변경할 수 있습니다.

중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 모든 리소스가 삭제됩니다.

모든 관리 클러스터는 관리 클러스터 세트와 연결되어 있어야 합니다. 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 클러스터를 그룹으로 검색할 수 있습니다.

다음 표에서는 클러스터를 가져오는 방법을 지정하는 가져오기 모드에 사용할 수 있는 옵션을 제공합니다.

참고: Ansible Automation Platform 작업을 생성하고 실행하려면 OperatorHub에서 Red Hat Ansible Automation Platform Resource Operator가 설치되어 있어야 합니다.

클러스터 API 주소를 구성하려면 선택 사항: 클러스터 API 주소 구성을 참조하십시오.

관리 클러스터 klusterlet을 특정 노드에서 실행하도록 구성하려면 선택 사항: 특정 노드에서 실행되도록 klusterlet 구성을 참조하십시오.

가져온 클러스터와 관리 클러스터에서 생성된 open-cluster-management-agent-addon 을 제거하려면 다음 절차를 완료합니다.

클러스터 페이지에서 Actions > Detach cluster 를 클릭하여 관리에서 클러스터를 제거합니다.

참고: local-cluster 라는 허브 클러스터를 분리하려고 하면 disableHubSelfManagement 의 기본 설정은 false 입니다. 이 설정으로 인해 허브 클러스터가 분리될 때 자체적으로 다시 가져와서 자체적으로 관리되고 MultiClusterHub 컨트롤러를 조정합니다. hub 클러스터에서 분리 프로세스를 완료하고 다시 가져오는 데 몇 시간이 걸릴 수 있습니다. 프로세스가 완료될 때까지 기다리지 않고 허브 클러스터를 다시 가져오려면 다음 명령을 실행하여 multiclusterhub-operator Pod를 재시작하고 더 빨리 다시 가져올 수 있습니다.

oc delete po -n open-cluster-management `oc get pod -n open-cluster-management | grep multiclusterhub-operator| cut -d' ' -f1`

disableHubSelfManagement 값을 true 로 변경하여 hub 클러스터의 값을 자동으로 가져오지 않도록 할 수 있습니다. 자세한 내용은 disableHubSelfManagement 주제를 참조하십시오.

CLI를 사용하여 관리 클러스터를 가져오기 전에 다음 단계를 완료해야 합니다.

자동 가져오기 보안을 사용하거나 클러스터를 수동으로 가져와서 클러스터를 가져올 수 있습니다.

자동 가져오기 보안을 사용하여 관리 클러스터를 가져오려면 클러스터의 kubeconfig 파일 또는 클러스터의 kube API 서버 및 토큰 쌍에 대한 참조가 포함된 시크릿을 생성해야 합니다. 자동 가져오기 보안을 사용하여 클러스터를 가져오려면 다음 단계를 완료합니다.

이제 klusterlet 애드온 가져오기를 계속할 수 있습니다.

중요: 가져오기 명령에는 가져온 각 관리 클러스터에 복사되는 풀 시크릿 정보가 포함되어 있습니다. 가져온 클러스터에 액세스할 수 있는 사용자는 풀 시크릿 정보도 볼 수 있습니다.

관리 클러스터를 수동으로 가져오려면 다음 단계를 완료합니다.

이제 klusterlet 애드온 가져오기를 계속할 수 있습니다.

KlusterletAddonConfig klusterlet 애드온 구성을 구현하여 관리 클러스터에서 다른 애드온을 활성화합니다. 다음 단계를 완료하여 구성 파일을 생성하고 적용합니다.

명령줄 인터페이스를 사용하여 관리 클러스터를 제거하려면 다음 명령을 실행합니다.

oc delete managedcluster <cluster_name>

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

에이전트 등록 끝점을 사용하여 관리 클러스터를 가져오려면 다음 단계를 완료합니다.

정적 네트워크 또는 베어 메탈 호스트 없이 수동으로 OpenShift Container Platform 클러스터를 가져오려면 다음 단계를 완료하고 노드 추가를 준비합니다.

지원 설치 관리자에서 OpenShift Container Platform 관리 클러스터를 설치한 경우 관리 클러스터 및 해당 리소스를 Hub 클러스터에서 다른 허브 클러스터로 이동할 수 있습니다.

다음 리소스를 가져오고 클러스터를 계속 관리할 수 있습니다.

원래 리소스의 복사본을 생성하고 새 허브 클러스터에 적용하여 새 허브 클러스터에서 클러스터를 관리할 수 있습니다. 그런 다음 새 허브 클러스터에서 관리 클러스터를 축소하거나 확장할 수 있습니다.

중요: 지원 설치 관리자가 설치한 경우에만 가져온 OpenShift Container Platform 관리 클러스터를 축소할 수 있습니다.

대상 허브 클러스터에서 리소스의 복사본을 생성하여 클러스터 리소스를 가져옵니다. 에이전트 리소스의 복사본을 생성하고 다른 리소스에 유사한 단계를 적용하는 방법을 알아보려면 다음 예제를 참조하십시오.

클러스터 리소스를 가져온 후 소스 허브 클러스터에서 원래 클러스터 리소스를 삭제합니다.

ManagedClusterImageRegistry 사용자 정의 리소스 정의로 사용자 지정된 클러스터를 가져오려면 다음 단계를 완료합니다.

자동 스케일링을 구성하면 트래픽이 낮을 때 축소하여 리소스 비용을 낮추고 리소스 수요가 많을 때 리소스가 충분한지 확인하기 위해 확장 가능한 클러스터의 유연성을 제공합니다.

콘솔 또는 명령줄을 사용하여 자동 스케일링을 비활성화할 수 있습니다.

콘솔과 명령줄에서 수동으로 확장할 수 있습니다.

관리 클러스터 API를 신뢰하는 데 필요한 새 CA 인증서가 있어야 합니다.

프로덕션 환경 작업자 노드를 OpenShift Container Platform 클러스터에 추가하기 전에 유효한 kubeconfig 가 있는지 확인해야 합니다.

관리 클러스터의 API 인증서가 변경되면 다음 단계를 완료하여 kubeconfig 를 새 CA 인증서로 업데이트합니다.

유효한 kubeconfig 가 있는 경우 다음 단계를 완료하여 OpenShift Container Platform 클러스터에 프로덕션 환경 작업자 노드를 추가합니다.

작업자 노드의 설치를 기다립니다. 작업자 노드 설치가 완료되면 작업자 노드는 가입 프로세스를 시작하기 위해 작업자 노드에 CSR(인증서 서명 요청)과 함께 관리 클러스터에 연결합니다. CSR이 자동으로 서명됩니다.

정상 관리 클러스터에 컨트롤 플레인 노드를 추가하려면 다음 단계를 완료합니다.

비정상적인 관리 클러스터에 컨트롤 플레인 노드를 추가하려면 다음 단계를 완료합니다.

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

업그레이드할 이미지와 로컬 미러 레지스트리로 업그레이드할 현재 이미지를 모두 미러링해야 합니다. 이미지를 미러링하려면 다음 단계를 완료합니다.

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

OpenShift Update Service는 그래프 데이터 정보를 사용하여 사용 가능한 업그레이드를 결정합니다. 연결된 환경에서 OpenShift Update Service는 Cincinnati 그래프 데이터 GitHub 리포지토리에서 직접 업그레이드할 수 있는 그래프 데이터 정보를 가져옵니다. 연결이 끊긴 환경을 구성하기 때문에 init 컨테이너 를 사용하여 로컬 리포지토리에서 그래프 데이터를 사용할 수 있도록 설정해야 합니다. 그래프 데이터 init 컨테이너 를 생성하려면 다음 단계를 완료합니다.

미러링된 OpenShift Container Platform 릴리스 이미지를 저장하기 위해 보안 외부 컨테이너 레지스트리를 사용하는 경우 OpenShift Update Service는 업그레이드 그래프를 빌드하기 위해 이 레지스트리에 액세스해야 합니다. OpenShift Update Service Pod에서 작동하도록 CA 인증서를 구성하려면 다음 단계를 완료합니다.

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

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

참고: 이 섹션의 단계는 릴리스를 미러링된 레지스트리로 미러링한 경우에만 적용됩니다.

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

기본 레지스트리를 덮어쓰려면 다음 단계를 완료합니다.

관리 클러스터에서 모든 기본 카탈로그 소스를 비활성화하고 새 카탈로그 소스를 생성합니다. 기본 위치를 연결된 위치에서 연결이 끊긴 로컬 레지스트리로 변경하려면 다음 단계를 완료합니다.

관리 클러스터에서 ClusterVersion 리소스 정보를 업데이트하여 업그레이드를 검색하는 위치에서 기본 위치를 변경합니다.

클러스터 페이지에서 클러스터 의 배포 버전은 연결이 끊긴 레지스트리에 업그레이드가 있는 경우 사용 가능한 업그레이드가 있음을 나타냅니다. 클러스터를 선택하고 Actions 메뉴에서 Upgrade Cluster를 선택하여 사용 가능한 업그레이드를 볼 수 있습니다. 선택적 업그레이드 경로를 사용할 수 있는 경우 사용 가능한 업그레이드가 나열됩니다.

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

콘솔을 사용하여 OpenShift Container Platform 버전 4.6 이상에서 클러스터 업그레이드 채널을 선택할 수 있습니다. 이러한 버전은 미러 레지스트리에서 사용할 수 있어야 합니다. 채널 선택 단계를 완료하여 업그레이드 채널을 지정합니다.

연결이 끊긴 레지스트리를 구성한 후 다중 클러스터 엔진 Operator 및 OpenShift Update Service는 연결이 끊긴 레지스트리를 사용하여 업그레이드를 사용할 수 있는지 확인합니다. 사용 가능한 업그레이드가 표시되지 않는 경우 클러스터의 현재 수준의 릴리스 이미지와 로컬 저장소에 미러링된 하나 이상의 이후 수준이 있는지 확인합니다. 현재 클러스터 버전의 릴리스 이미지를 사용할 수 없는 경우 업그레이드를 사용할 수 없습니다.

클러스터 페이지에서 클러스터 의 배포 버전은 연결이 끊긴 레지스트리에 업그레이드가 있는 경우 사용 가능한 업그레이드가 있음을 나타냅니다. 사용 가능한 업그레이드를 클릭하고 업그레이드 버전을 선택하여 이미지를 업그레이드할 수 있습니다.

관리 클러스터가 선택한 버전으로 업데이트되었습니다.

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

CLI를 사용하여 설정된 관리 클러스터의 다음 정의를 YAML 파일에 추가하여 관리 클러스터 세트를 생성합니다.

apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSet
metadata:
  name: <cluster_set>

& lt;cluster_set >을 관리되는 클러스터 세트의 이름으로 바꿉니다.

ManagedClusterSet 을 생성한 후 콘솔의 지침에 따라 또는 CLI를 사용하여 설정된 관리 클러스터에 클러스터를 추가할 수 있습니다.

CLI를 사용하여 설정된 관리 클러스터에 클러스터를 추가하려면 다음 단계를 완료합니다.

콘솔을 사용하여 ManagedClusterSetBinding 을 생성하려면 다음 단계를 완료합니다.

CLI를 사용하여 ManagedClusterSetBinding 을 생성하려면 다음 단계를 완료합니다.

테인트는 관리 클러스터의 속성에 지정되며, 배치에서 관리 클러스터 또는 관리 클러스터 세트를 거절할 수 있습니다.

taint 섹션이 없는 경우 다음 예와 유사한 명령을 실행하여 관리 클러스터에 테인트를 추가할 수 있습니다.

oc patch managedcluster <managed_cluster_name> -p '{"spec":{"taints":[{"key": "key", "value": "value", "effect": "NoSelect"}]}}' --type=merge

또는 다음 예와 유사한 명령을 실행하여 기존 테인트에 테인트를 추가할 수 있습니다.

oc patch managedcluster <managed_cluster_name> --type='json' -p='[{"op": "add", "path": "/spec/taints/-", "value": {"key": "key", "value": "value", "effect": "NoSelect"}}]'

테인트의 사양에는 다음 필드가 포함됩니다.

관리 클러스터에 액세스할 수 없는 경우 클러스터를 배치에 추가하지 않아도 됩니다. 다음 테인트는 액세스할 수 없는 관리형 클러스터에 자동으로 추가됩니다.

허용 오차는 배치에 적용되며 배치의 허용 오차와 일치하는 테인트가 없는 관리 클러스터를 복구할 수 있습니다. 허용 오차 사양에는 다음 필드가 포함됩니다.

다음 예제에서는 테인트가 있는 클러스터를 허용하는 허용 오차를 구성하는 방법을 보여줍니다.

참고: 관리형 클러스터는 테인트에 대한 허용 오차가 포함된 배치에 배치되지 않습니다. 다른 배치에 동일한 허용 오차가 포함된 경우 관리 클러스터가 해당 배치 중 하나에 배치될 수 있습니다.

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'

다음 예제에서와 같이 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

관리형 클러스터에 5분 동안 연결할 수 없는 경우 애플리케이션이 다른 관리 클러스터로 이동됩니다.

콘솔을 사용하여 설정된 관리 클러스터에서 클러스터를 제거하려면 다음 단계를 완료합니다.

참고: 하나의 관리형 클러스터에서 다른 관리 클러스터로 관리되는 클러스터를 이동하는 경우 두 관리 클러스터 세트에 대해 필요한 RBAC 권한이 있어야 합니다.

명령줄을 사용하여 관리 클러스터 세트에서 클러스터를 제거하려면 다음 단계를 완료합니다.

참고: 한 클러스터에서 다른 클러스터로 관리되는 클러스터를 이동하는 경우 두 관리 클러스터 세트에 대해 필요한 RBAC 권한이 있어야 합니다.

일치하는 테인트를 사용하여 ManagedCluster를 필터링하는 방법을 알아보려면 다음 예제를 참조하십시오.

tolerationSeconds 매개변수를 사용하여 지정된 시간 동안 테인트가 일치하는 ManagedClusters 를 선택할 수도 있습니다. tolerationSeconds 는 허용 오차가 테인트에 바인딩된 기간을 정의합니다. tolerationSeconds 는 지정된 기간 후에 다른 관리 클러스터로 오프라인으로 이동하는 클러스터에 배포된 애플리케이션을 자동으로 전송할 수 있습니다.

다음 예제를 확인하여 tolerationSeconds 를 사용하는 방법을 알아봅니다.

배치와 함께 prioritizerPolicy 매개변수를 사용하여 ManagedCluster의 우선 순위를 지정하는 방법을 알아보려면 다음 예제를 확인합니다.

배포된 애드온의 상태에 따라 배치의 관리 클러스터를 선택할 수 있습니다. 예를 들어 관리 클러스터에서 활성화된 특정 애드온이 있는 경우에만 배치에 대해 관리형 클러스터를 선택할 수 있습니다.

배치를 생성할 때 애드온 레이블과 해당 상태를 지정할 수 있습니다. 관리형 클러스터에서 추가 기능이 활성화된 경우 ManagedCluster 리소스에서 레이블이 자동으로 생성됩니다. 추가 기능이 비활성화되면 레이블이 자동으로 제거됩니다.

각 애드온은 feature.open-cluster-management.io/addon-<addon_name>=<status_of_addon > 형식의 레이블로 표시됩니다.

addon_name 을 선택한 관리 클러스터에서 활성화할 애드온의 이름으로 교체합니다.

status_of_addon 을 관리 클러스터를 선택하는 경우 애드온에 포함할 상태로 바꿉니다.

status_of_addon:에 대해 가능한 값의 다음 표를 참조하십시오.

예를 들어 사용 가능한 application-manager 애드온은 다음을 읽는 관리 클러스터의 레이블로 표시됩니다.

feature.open-cluster-management.io/addon-application-manager: available

애드온 및 해당 상태를 기반으로 배치를 생성하는 방법을 알아보려면 다음 예제를 참조하십시오.

클러스터 풀을 생성하기 전에 다음 사전 요구 사항을 참조하십시오.

참고: 이 절차를 사용하여 클러스터 풀을 추가하면 풀에서 클러스터를 요청할 때 다중 클러스터 엔진 Operator 관리용 클러스터를 자동으로 가져옵니다. 클러스터 클레임과 관리를 위해 클레임된 클러스터를 자동으로 가져오지 않는 클러스터 풀을 생성하려면 clusterClaim 리소스에 다음 주석을 추가합니다.

kind: ClusterClaim
metadata:
  annotations:
    cluster.open-cluster-management.io/createmanagedcluster: "false" 1

클러스터 풀을 생성하려면 탐색 메뉴에서 Infrastructure > Clusters 를 선택합니다. 클러스터 풀 탭에는 액세스할 수 있는 클러스터 풀이 나열됩니다. 클러스터 풀 생성 을 선택하고 콘솔의 단계를 완료합니다.

클러스터 풀에 사용할 인프라 인증 정보가 없는 경우 인증 정보 추가 를 선택하여 생성할 수 있습니다.

목록에서 기존 네임스페이스를 선택하거나 새로 생성할 새 네임스페이스를 입력할 수 있습니다. 클러스터 풀이 클러스터와 동일한 네임스페이스에 있을 필요는 없습니다.

클러스터 풀의 RBAC 역할이 기존 클러스터 세트의 역할 할당을 공유하도록 하려면 클러스터 세트 이름을 선택할 수 있습니다. 클러스터 풀의 클러스터 세트는 클러스터 풀을 생성할 때만 설정할 수 있습니다. 클러스터 풀을 생성한 후에는 클러스터 풀 또는 클러스터 풀의 클러스터에 대한 클러스터 세트 연결을 변경할 수 없습니다. 클러스터 풀에서 요청하는 클러스터는 클러스터 풀과 동일한 클러스터 세트에 자동으로 추가됩니다.

참고: 클러스터 관리자 권한이 없는 경우 클러스터 세트를 선택해야 합니다. 이 경우 클러스터 세트 생성 요청은 클러스터 세트 이름을 포함하지 않는 경우 금지 오류와 함께 거부됩니다. 선택할 수 있는 클러스터 세트가 없는 경우 클러스터 관리자에게 문의하여 클러스터 세트를 생성하고 clusterset 관리자 권한을 부여합니다.

클러스터 풀 크기는 클러스터 풀에서 프로비저닝할 클러스터 수를 지정하는 반면, 클러스터 풀 실행 수는 풀이 계속 실행 중인 클러스터 수를 지정하고 즉시 사용할 준비가 된 클러스터 수를 지정합니다.

절차는 클러스터를 생성하는 절차와 매우 유사합니다.

공급자에 필요한 정보에 대한 자세한 내용은 다음 정보를 참조하십시오.

클러스터 풀에서 클러스터를 요청하기 전에 다음을 사용할 수 있어야 합니다.

사용 가능한 클러스터가 있거나 없는 클러스터 풀입니다. 클러스터 풀에 사용 가능한 클러스터가 있는 경우 사용 가능한 클러스터가 클레임됩니다. 클러스터 풀에 사용 가능한 클러스터가 없으면 클레임을 충족하기 위해 클러스터가 생성됩니다. 클러스터 풀을 생성하는 방법에 대한 자세한 내용은 클러스터 풀 생성 을 참조하십시오.

클러스터 클레임을 생성할 때 클러스터 풀에서 새 클러스터를 요청합니다. 클러스터를 사용할 수 있을 때 풀에서 클러스터를 확인합니다. 자동 가져오기를 비활성화하지 않는 한 클레임된 클러스터는 관리 클러스터 중 하나로 자동으로 가져옵니다.

클러스터를 클레임하려면 다음 단계를 완료합니다.

클러스터를 사용할 수 있는 경우 클레임되고 Managed 클러스터 탭에 즉시 표시됩니다. 사용 가능한 클러스터가 없는 경우 hibernated 클러스터를 다시 시작하거나 새 클러스터를 프로비저닝하는 데 몇 분이 걸릴 수 있습니다. 이 시간 동안 클레임 상태가 보류 중입니다. 클러스터 풀을 확장하여 보류 중인 클레임을 보거나 삭제합니다.

클레임된 클러스터는 클러스터 풀에 있는 시점과 연결된 클러스터 세트의 멤버로 유지됩니다. 클레임할 때 클레임된 클러스터의 클러스터 세트를 변경할 수 없습니다.

참고: 클라우드 공급자 인증 정보의 풀 시크릿, SSH 키 또는 기본 도메인에 대한 변경 사항은 원래 인증 정보를 사용하여 이미 프로비저닝되었으므로 클러스터 풀에서 클레임한 기존 클러스터에는 반영되지 않습니다. 콘솔을 사용하여 클러스터 풀 정보를 편집할 수 없지만 CLI 인터페이스를 사용하여 정보를 업데이트하여 업데이트할 수 있습니다. 업데이트된 정보가 포함된 인증 정보를 사용하여 새 클러스터 풀을 생성할 수도 있습니다. 새 풀에서 생성된 클러스터는 새 인증 정보에 제공된 설정을 사용합니다.

hub 클러스터와 관리 클러스터 간의 프록시 설정을 구성하려면 다음 단계를 완료합니다.

개발이 변경되면 HTTP 또는 HTTPS 프록시를 비활성화해야 할 수 있습니다.

Red Hat Advanced Cluster Management for Kubernetes를 사용하여 클러스터를 생성할 때 관리 클러스터에 대한 nodeSelector 및 허용 오차 주석을 구성하여 관리 대상 클러스터 klusterlet을 실행할 노드를 지정할 수 있습니다. 다음 설정을 구성하려면 다음 단계를 완료합니다.

관리 클러스터를 가져올 때 사용자 정의 허브 API 서버 URL 및 CA 번들을 사용하려면 다음 단계를 완료하십시오.

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 필드는 더 이상 사용되지 않습니다. 자세한 내용은 API 사용 중단을 참조하십시오.

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"

글로벌 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"

글로벌 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"