클러스터

머신 풀에 자동 스케일링이 활성화됩니다.

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

자동 스케일링이 비활성화되어 있습니다.

베어 메탈 자산 세트를 가져오려면 다음 단계를 완료합니다.

REST API를 사용하여 베어 메탈 자산을 생성하려면 다음을 수행하십시오.

팁: oc 명령에 --v=9 를 추가하여 결과 작업의 원시 출력을 확인할 수 있습니다. 이 기능은 oc 명령의 REST API 경로를 확인하는 데 유용할 수 있습니다.

다음 단계를 완료하여 AgentServiceConfig 사용자 지정 리소스를 생성합니다.

assisted-service 및 assisted-image-service 배포를 확인하고 해당 Pod가 준비되고 실행 중인지 확인할 수 있습니다. 콘솔을 사용하여 인프라 환경 생성을 계속합니다.

다음 명령을 사용하여 자동화된 프로비저닝 용 서비스를 활성화하는 프로비저닝 CR을 수동으로 생성합니다.

oc create -f provisioning-configuration.yaml

CR은 다음 샘플과 유사할 수 있습니다.

apiVersion: metal3.io/v1alpha1
kind: Provisioning
metadata:
  name: provisioning-configuration
spec:
  provisioningNetwork: Disabled
  watchAllNamespaces: true

Amazon Web Services에서 hub 클러스터를 실행하고 CIM 서비스를 활성화하려면 CIM 활성화 후 다음 추가 단계를 완료합니다.

Amazon Web Services에서 CIM 서비스가 활성화되어 있는지 확인하려면 다음 단계를 완료합니다.

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

참고: 클라우드 공급자 액세스 키를 변경하는 경우 프로비저닝된 클러스터 액세스 키를 수동으로 업데이트해야 합니다. 자세한 내용은 알려진 문제에서 프로비저닝된 클러스터에 대한 자동 시크릿 업데이트가 지원되지 않음을 참조하십시오.

Red Hat Advanced Cluster Management 콘솔에서 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 생성을 클릭하고 콘솔의 단계를 완료합니다.

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

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

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

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

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

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

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

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

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

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

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

클러스터에 네트워킹 세부 정보가 필요하며 IPv6를 사용하는 데 여러 네트워크가 필요합니다. 네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다.

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

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

참고: 클러스터를 가져오기 위해 클러스터 세부 정보와 함께 제공된 kubectl 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 Red Hat Advanced Cluster Management의 관리 하에 자동으로 구성됩니다.

클러스터에 액세스하는 방법에 대한 지침을 보려면 클러스터에 계속 액세스합니다.

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

참고: 클라우드 공급자 액세스 키를 변경하는 경우 프로비저닝된 클러스터 액세스 키를 수동으로 업데이트해야 합니다. 자세한 내용은 알려진 문제에서 프로비저닝된 클러스터에 대한 자동 시크릿 업데이트가 지원되지 않음을 참조하십시오.

Kubernetes 콘솔용 Red Hat Advanced Cluster Management에서 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 생성을 클릭하고 콘솔의 단계를 완료합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

참고: 클러스터를 가져오기 위해 클러스터 세부 정보와 함께 제공된 kubectl 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 Red Hat Advanced Cluster Management의 관리 하에 자동으로 구성됩니다.

클러스터에 액세스하는 방법에 대한 지침을 보려면 클러스터에 계속 액세스합니다.

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

참고: 클라우드 공급자 액세스 키를 변경하는 경우 프로비저닝된 클러스터 액세스 키를 수동으로 업데이트해야 합니다. 자세한 내용은 알려진 문제에서 프로비저닝된 클러스터에 대한 자동 시크릿 업데이트가 지원되지 않음을 참조하십시오.

Kubernetes 콘솔용 Red Hat Advanced Cluster Management에서 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 생성을 클릭하고 콘솔의 단계를 완료합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

참고: 클러스터를 가져오기 위해 클러스터 세부 정보와 함께 제공된 kubectl 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 Red Hat Advanced Cluster Management의 관리 하에 자동으로 구성됩니다.

클러스터에 액세스하는 방법에 대한 지침을 보려면 클러스터에 계속 액세스합니다.

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

참고: VMware vSphere 또는 Red Hat OpenStack Platform 공급자 및 연결이 끊긴 설치 공급자를 사용하여 클러스터를 생성할 때 미러 레지스트리에 액세스하는 데 인증서가 필요한 경우 연결이 끊긴 설치의 구성 섹션에 인증 정보의 추가 신뢰 번들 필드에 입력해야 합니다. 클러스터 생성 콘솔 편집기에 입력할 수 없습니다.

Kubernetes 콘솔용 Red Hat Advanced Cluster Management에서 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 생성을 클릭하고 콘솔의 단계를 완료합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

설치 분리를 클릭하여 연결 해제된 설치 이미지를 정의할 수 있습니다. 클러스터 생성에 대한 연결되지 않은 설치 설정을 입력할 수 없거나 제한 사항에 대한 자세한 내용은 입력한 경우 무시됩니다.

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

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

참고: 클러스터를 가져오기 위해 클러스터 세부 정보와 함께 제공된 kubectl 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 Red Hat Advanced Cluster Management의 관리 하에 자동으로 구성됩니다.

클러스터에 액세스하는 방법에 대한 지침을 보려면 클러스터에 계속 액세스합니다.

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

Kubernetes 콘솔용 Red Hat Advanced Cluster Management에서 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 생성을 클릭하고 콘솔의 단계를 완료합니다.

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

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

클러스터의 이름은 클러스터의 호스트 이름에 사용됩니다. 이름에는 15자 미만이 포함되어야 합니다. 이 값은 자격 증명 사전 요구 사항 섹션에 나열된 DNS 레코드를 생성하는 데 사용한 이름과 일치해야 합니다.

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

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

기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 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 이상의 릴리스 이미지만 지원됩니다.

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

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

클러스터에 대한 네트워킹 세부 정보가 필요합니다. IPv4 네트워크의 하나 이상의 네트워크에 대한 값을 제공해야 합니다. IPv6 네트워크의 경우 둘 이상의 네트워크를 정의해야 합니다.

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

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

설치 분리를 클릭하여 연결 해제된 설치 이미지를 정의할 수 있습니다. 클러스터 생성에 대한 연결되지 않은 설치 설정을 입력할 수 없거나 제한 사항에 대한 자세한 내용은 입력한 경우 무시됩니다.

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

참고: 클러스터를 가져오기 위해 클러스터 세부 정보와 함께 제공된 kubectl 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 Red Hat Advanced Cluster Management의 관리 하에 자동으로 구성됩니다.

클러스터에 액세스하는 방법에 대한 지침을 보려면 클러스터에 계속 액세스합니다.

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

참고: 클라우드 공급자 액세스 키를 변경하는 경우 프로비저닝된 클러스터 액세스 키를 수동으로 업데이트해야 합니다. 자세한 내용은 알려진 문제에서 프로비저닝된 클러스터에 대한 자동 시크릿 업데이트가 지원되지 않음을 참조하십시오.

Kubernetes 콘솔용 Red Hat Advanced Cluster Management에서 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 생성을 클릭하고 콘솔의 단계를 완료합니다.

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

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

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

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

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

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

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

Red Hat Virtualization 계정에 대해 구성한 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 필드에 채워집니다. 값을 덮어쓰고 변경할 수 있습니다.

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

노드 풀 정보에는 컨트롤 플레인 풀의 코어, 소켓, 메모리 및 디스크 크기가 포함됩니다. 세 개의 컨트롤 플레인 노드는 클러스터 활동 관리를 공유합니다. 정보에는 아키텍처 필드가 포함됩니다. 다음 필드 설명을 확인합니다.

작업자 풀 정보에는 작업자 풀의 풀 이름, 코어 수, 메모리 할당, 디스크 크기 할당 및 노드 수가 필요합니다. 작업자 풀 내의 작업자 노드는 단일 작업자 풀에 있거나 여러 작업자 풀에 분산될 수 있습니다.

사전 구성된 oVirt 환경에서 다음 네트워킹 세부 정보가 필요합니다.

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

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

참고: 클러스터를 가져오기 위해 클러스터 세부 정보와 함께 제공된 kubectl 명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 Red Hat Advanced Cluster Management의 관리 하에 자동으로 구성됩니다.

클러스터에 액세스하는 방법에 대한 지침을 보려면 클러스터에 계속 액세스합니다.

베어 메탈 환경에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.

Kubernetes 콘솔용 Red Hat Advanced Cluster Management에서 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 생성을 클릭하고 콘솔의 단계를 완료합니다.

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

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

베어 메탈 클러스터의 경우 클러스터 이름은 임의의 이름일 수 없습니다. 클러스터 URL과 연결되어 있습니다. 사용하는 클러스터 이름이 DNS 및 네트워크 설정과 일치하는지 확인합니다.

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

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

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

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

공급자의 기본 도메인은 Red Hat OpenShift Container Platform 클러스터 구성 요소에 대한 경로를 생성하는 데 사용됩니다. 클러스터 공급자의 DNS에서 SOA(Start of Authority) 레코드로 구성됩니다. 이 이름은 클러스터의 호스트 이름에 사용됩니다.

베어 메탈 공급자 계정에 대해 구성한 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 필드에 채워집니다. 값을 작성하여 변경할 수 있지만 클러스터를 생성한 후에는 이름을 변경할 수 없습니다. 자세한 내용은 OpenShift Container Platform 설명서의 베어 메탈에 설치를 참조하십시오.

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

호스트 목록은 기존 베어 메탈 자산에서 컴파일되며 인증 정보와 연결됩니다. 베어 메탈 호스트에서 최신 펌웨어를 실행 중이거나 프로비저닝에 실패할 수 있는지 확인합니다. 하이퍼바이저와 동일한 브릿지 네트워크에 있는 최소 3개의 베어 메탈 자산을 선택해야 합니다. 생성된 베어 메탈 자산이 없는 경우 생성 프로세스를 계속하기 전에 자산 가져오기 를 선택하여 만들거나 가져올 수 있습니다. 베어 메탈 자산 생성에 대한 자세한 내용은 베어 메탈 자산 생성 및 수정을 참조하십시오. 또는 Disable certificate verification 을 선택하여 요구 사항을 바이패스할 수 있습니다.

다음 표에서는 네트워킹 옵션 및 해당 설명을 보여줍니다.

IPv6 주소를 사용하는 경우 네트워크가 두 개 이상 있어야 합니다.

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

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

참고: 클러스터를 가져오기 위해 클러스터 세부 정보와 함께 제공된 kubectl 명령을 실행할 필요가 없습니다. 클러스터를 생성하면 Red Hat Advanced Cluster Management 관리로 자동 구성됩니다.

클러스터에 액세스하는 방법에 대한 지침을 보려면 클러스터에 계속 액세스합니다.

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

Kubernetes 콘솔용 Red Hat Advanced Cluster Management에서 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 생성을 클릭하고 콘솔의 단계를 완료합니다.

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

자세한 내용은 온-프레미스 환경에 대한 자격 증명 만들기를 참조하십시오.If you need to create a credential, see Creating a credential for an on-premises environment for more information.

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

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

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

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

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

공급자 계정에 대해 구성한 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 필드에 채워집니다. 값을 수정하여 변경할 수 있지만 이 설정은 클러스터를 생성한 후에는 변경할 수 없습니다. 공급자의 기본 도메인은 Red Hat OpenShift Container Platform 클러스터 구성 요소에 대한 경로를 생성하는 데 사용됩니다. 클러스터 공급자의 DNS에서 SOA(Start of Authority) 레코드로 구성됩니다.

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

4.9 이상 OpenShift 버전을 선택하면 Install single node OpenShift (SNO) 를 선택하는 옵션이 표시됩니다. 단일 노드 OpenShift 클러스터에는 컨트롤 플레인 서비스와 사용자 워크로드를 호스팅하는 단일 노드가 포함되어 있습니다. 생성된 후에는 단일 노드 OpenShift 클러스터에 노드를 추가할 수 없습니다.

클러스터가 단일 노드 OpenShift 클러스터가 되도록 하려면 단일 노드 OpenShift 옵션을 선택합니다.

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

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

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

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

기존 인프라 환경 없이 새 호스트를 검색하는 경우 4단계로 시작하여 호스트를 정의하는 인프라 환경에 호스트 추가 단계를 완료합니다.

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

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

클러스터에 액세스하는 방법에 대한 지침을 보려면 클러스터에 계속 액세스합니다.

Red Hat Advanced Cluster Management 콘솔을 사용하여 Red Hat Advanced Cluster Management에서 생성한 클러스터를 사용하려면 다음 단계를 완료하십시오.

클러스터 페이지의 클러스터 상태는 프로세스가 완료되면 Hibernating 입니다.

팁: 클러스터 페이지에서 클러스터를 선택하고 Actions > iPXE 클러스터를 선택하여 여러 클러스터를 할 수 있습니다.

선택한 클러스터가 hibernating입니다.

CLI를 사용하여 Red Hat Advanced Cluster Management에서 생성한 클러스터를 사용하려면 다음 단계를 완료하십시오.

선택한 클러스터가 hibernating입니다.

Red Hat Advanced Cluster Management 콘솔을 사용하여 상위 클러스터의 정상적인 작동을 다시 시작하려면 다음 단계를 완료하십시오.

프로세스가 완료되면 클러스터 페이지의 클러스터 상태가 Ready 입니다.

팁: 클러스터 페이지에서 재개할 클러스터를 선택하고 작업 > 클러스터 재시작을 선택하여 여러 클러스터를 다시 시작할 수 있습니다.

선택한 클러스터가 정상적인 작업을 다시 시작합니다.

CLI를 사용하여 상위 클러스터의 정상적인 작동을 다시 시작하려면 다음 단계를 완료합니다.

선택한 클러스터가 정상적인 작업을 다시 시작합니다.

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

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

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

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

클러스터를 가져옵니다. 다른 가져오기를 선택하여 다른 가져오기 를 가져올 수 있습니다.

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

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

참고: local-cluster 라는 hub 클러스터를 분리하려고 하면 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 주제를 참조하십시오.

자동 가져오기 보안을 사용하여 클러스터 가져오기를 계속하거나 수동 명령으로 클러스터를 가져옵니다.

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

klusterlet 추가 기능 가져오기를 계속합니다.

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

klusterlet 추가 기능 가져오기를 계속합니다.

다음 절차를 완료하여 klusterlet 추가 기능 구성 파일을 생성하고 적용할 수 있습니다.

이제 클러스터를 가져옵니다.

클러스터를 제거하려면 다음 명령을 실행합니다.

oc delete managedcluster ${CLUSTER_NAME}

cluster_name 을 클러스터 이름으로 교체합니다.

이제 클러스터가 제거되었습니다.

ManagedClusterImageRegistry CRD로 클러스터를 가져오려면 다음 단계를 완료합니다.

klusterletaddonconfigs.agent.open-cluster-management.io Kubernetes 리소스에서 다음 설정을 업데이트할 수 있습니다.

hub 클러스터를 사용하여 klusterletaddonconfigs.agent.open-cluster-management.io 리소스의 설정을 수정할 수 있습니다. 설정을 변경하려면 다음 단계를 완료합니다.

hub 클러스터를 사용하여 설정을 수정하려면 cluster-name 네임스페이스에 액세스할 수 있어야 합니다. 다음 단계를 완료합니다.

Red Hat Advanced Cluster Management 콘솔을 사용하여 설정된 관리형 클러스터를 생성하려면 다음 단계를 완료합니다.

관리형 클러스터 세트의 다음 정의를 yaml 파일에 추가하여 명령줄을 사용하여 관리되는 클러스터 세트를 생성합니다.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ManagedClusterSet
metadata:
  name: <clusterset1>

clusterset1 을 관리 클러스터 세트의 이름으로 교체합니다.

ManagedClusterSetBinding 리소스를 생성하여 ManagedClusterSet 리소스를 네임스페이스에 바인딩합니다. 동일한 네임스페이스에서 생성되는 애플리케이션 및 정책은 바인딩된 관리형 클러스터 세트 리소스에 포함된 관리형 클러스터에만 액세스할 수 있습니다.

네임스페이스에 대한 액세스 권한은 해당 네임스페이스에 바인딩된 관리형 클러스터 세트에 자동으로 적용됩니다. 관리 클러스터 세트가 바인딩된 네임스페이스에 액세스할 수 있는 액세스 권한이 있는 경우 해당 네임스페이스에 바인딩된 모든 관리 클러스터 세트에 액세스할 수 있는 권한이 자동으로 부여됩니다. 그러나 관리형 클러스터 세트에 액세스할 수 있는 권한만 있는 경우 해당 네임스페이스의 다른 관리 클러스터 세트에 액세스할 수 있는 권한이 자동으로 없습니다. 관리형 클러스터 세트가 표시되지 않으면 이를 확인하는 데 필요한 권한이 없을 수 있습니다.

콘솔 또는 명령줄을 사용하여 관리형 클러스터 세트 바인딩을 생성할 수 있습니다.

Red Hat Advanced Cluster Management 콘솔을 사용하여 설정된 관리형 클러스터에 클러스터를 추가하려면 다음 단계를 완료합니다.

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

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

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

명령줄을 사용하여 설정된 관리형 클러스터에서 관리형 클러스터를 제거하려면 다음 단계를 완료하십시오.

참고: 관리 대상 클러스터에서 다른 클러스터로 설정된 관리 클러스터를 이동하는 경우 두 관리 클러스터 세트 모두에서 필요한 RBAC 권한을 사용할 수 있어야 합니다.

관리형 클러스터의 배치 작동 방식에 대한 다음 정보를 참조하십시오.

배치 사양에는 다음 필드가 포함됩니다.

참고: configurations.name 파일은 v1beta1에서 제거되고 scoreCoordinate.builtIn 파일로 대체됩니다. name 및 scoreCoordinate.builtIn 이 모두 정의된 경우 scoreCoordinate.builtIn 의 값을 사용하여 선택을 결정합니다.

해당 네임스페이스에서 ManagedClusterSet Binding 을 생성하여 하나 이상의 ManagedClusterSet을 네임스페이스에 바인딩해야 합니다. 참고: managedclustersets/bind 의 가상 하위 리소스에서 CREATE 에 대한 역할 기반 액세스가 필요합니다. 다음 예제를 참조하십시오.

cluster.open-cluster-management.io/placement name} 레이블이 있는 하나 이상의 Placement Decision s 가 생성되어 배치에서 선택한 ManagedCluster 를 나타냅니다.

ManagedCluster 를 선택하고 Placement Decision 에 추가하면 이 배치를 사용하는 구성 요소가 이 ManagedCluster 에 워크로드를 적용할 수 있습니다. ManagedCluster 가 더 이상 선택되지 않고 PlacementDecisions 에서 제거된 후 이 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: ''

배포된 애드온의 상태에 따라 배치에 사용할 관리 클러스터를 선택할 수 있습니다. 예를 들어 클러스터에 활성화된 특정 추가 기능이 있는 경우에만 배치용으로 관리 클러스터를 선택하려고 합니다.

배치를 생성할 때 애드온의 라벨과 필요한 경우 상태를 지정하여 이 작업을 수행할 수 있습니다. 클러스터에서 애드온이 활성화된 경우 ManagedCluster 리소스에 레이블이 자동으로 생성됩니다. 애드온이 비활성화된 경우 라벨이 자동으로 제거됩니다.

각 애드온은 feature.open-cluster-management.io/addon-<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

애드온 및 해당 상태를 기반으로 배치를 생성하는 다음 예제를 참조하십시오.

배치 리소스 기반 예약에서 우선순위에는 관리 클러스터의 점수를 계산하기 위해 MananagedCluster 리소스에서 제공하는 기본값보다 더 많은 데이터가 필요한 경우가 있습니다. 예를 들어 모니터링 시스템을 통해 가져온 클러스터의 CPU 또는 메모리 사용량 데이터를 기반으로 클러스터를 예약합니다.

API AddOnPlacementScore 는 사용자 정의 점수를 기반으로 보다 확장 가능한 일정을 설정하는 방법을 지원합니다.

자세한 내용은 오픈 클러스터 관리 리포지토리에서 확장 가능한 스케줄링 기능 배치를 참조하십시오.

테인트는 관리형 클러스터의 속성에 지정되며, 배치가 관리 클러스터 또는 관리되는 클러스터 집합을 거절할 수 있습니다. 다음 예와 유사한 명령을 입력하여 관리형 클러스터에 테인트를 추가할 수 있습니다.

kubectl taint ManagedCluster <managed_cluster_name> key=value: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/v1alpha1
kind: Placement
metadata:
  name: demo4
  namespace: demo1
spec:
  tolerations:
    - key: cluster.open-cluster-management.io/unreachable
      operator: Exists
      tolerationSeconds: 300
----

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

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

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

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

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

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

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

호스팅 서비스 클러스터로 작동하도록 기존 클러스터를 구성하여 호스팅 컨트롤 플레인을 배포할 수 있습니다. 호스팅 서비스 클러스터는 컨트롤 플레인이 호스팅되는 OpenShift Container Platform 클러스터이며 허브 클러스터 또는 OpenShift Container Platform 관리형 클러스터 중 하나일 수 있습니다.

HyperShift Operator를 설치하고 호스팅 서비스 클러스터로 기존 클러스터를 활성화한 후 HypershiftDeployment 사용자 지정 리소스를 생성하여 HyperShift 호스팅 클러스터를 프로비저닝할 수 있습니다.

이제 클러스터에 액세스할 수 있습니다. 액세스 보안은 hypershift-hosting-service-cluster 네임스페이스에 저장됩니다. 이 네임스페이스는 호스팅 서비스 클러스터의 이름과 동일합니다. 다음 형식의 시크릿 이름 형식을 확인합니다.

HyperShift 호스팅 클러스터를 삭제하려면 다음 명령 중 하나를 실행하여 HypershiftDeployment 리소스를 삭제합니다.

oc delete -f <HypershiftDeployment_yaml_file_name>

또는

oc delete hd -n <HypershiftDeployment_namespace> <HypershiftDeployment_resource_name>

관리 또는 호스팅 서비스 클러스터에서 HyperShift Operator를 제거하려면 다음 명령을 실행하여 관리 클러스터에서 hypershift-addon ManagedClusterAddon 을 삭제합니다.

oc delete managedclusteraddon -n <hypershift-management-cluster> hypershift-addon

클러스터를 찾도록 콘솔에서 Discovery를 구성합니다. 별도의 인증 정보를 사용하여 여러 DiscoveryConfig 리소스를 생성할 수 있습니다. 콘솔의 지침을 따르십시오.

인증 정보를 설정하고 가져올 클러스터를 검색한 후 콘솔에서 해당 인증서를 볼 수 있습니다.

클러스터를 검색한 후 콘솔의 Discovered 클러스터 탭에 표시되는 클러스터를 가져올 수 있습니다.

Discovery를 구성하는 데 사용된 네임스페이스에 액세스해야 합니다.

참고: 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.10"
    - "4.9"
    - "4.8"

oc get discoveredclusters -n <namespace >를 실행하여 검색된 클러스터를 확인합니다. 여기서 namespace 는 검색 인증 정보가 존재하는 네임스페이스입니다.

apiVersion: discovery.open-cluster-management.io/v1
kind: DiscoveredCluster
metadata:
  name: fd51aafa-95a8-41f7-a992-6fb95eed3c8e
  namespace: <NAMESPACE_NAME>
spec:
  activity_timestamp: "2021-04-19T21:06:14Z"
  cloudProvider: vsphere
  console: https://console-openshift-console.apps.qe1-vmware-pkt.dev02.red-chesterfield.com
  creation_timestamp: "2021-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: fd51aafa-95a8-41f7-a992-6fb95eed3c8e
  openshiftVersion: 4.10
  status: Stale

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

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

팁: ImageContentSourcePolicy 를 생성할 때 이 스크립트의 마지막 줄의 출력을 사용할 수 있습니다.

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 및 변경 사항을 확인한 다음 CA 인증서가 변경된 경우 배포를 다시 시작합니다.

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

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

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

이 단계에서 정책의 이름은 ImageContentSourcePolicy 입니다. 정책을 생성하려면 다음 단계를 완료합니다.

Catalogsource 정책을 관리형 클러스터로 푸시하여 연결된 위치에서 연결이 끊긴 로컬 레지스트리로 기본 위치를 변경합니다.

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

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

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

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

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

관리 클러스터는 선택한 버전으로 업데이트됩니다.

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

클러스터 백업 및 복원 Operator 솔루션은 관리 클러스터, 애플리케이션, 정책 및 베어 메탈 자산과 같은 모든 허브 클러스터 리소스에 대한 백업 및 복원 지원을 제공합니다. 솔루션을 사용하여 기본 허브 클러스터 설치를 확장하는 타사 리소스를 백업할 수 있습니다. 이 백업 솔루션을 사용하면 지정된 시간 간격으로 실행되고 허브 클러스터 콘텐츠의 최신 버전을 지속적으로 백업하는 cron 기반 백업 일정을 정의할 수 있습니다.

허브 클러스터가 중단된 경우 hub 클러스터를 교체해야 하거나 재해 시나리오에 있는 경우 새 허브 클러스터를 배포하고 백업할 수 있으며 데이터를 새 허브 클러스터로 이동할 수 있습니다.

백업 데이터를 식별하기 위해 다음과 같이 정렬된 클러스터 백업 및 복원 프로세스 목록을 확인합니다.

리소스에 cluster.open-cluster-management.io/backup 라벨을 추가하여 클러스터 백업 및 복원으로 타사 리소스를 백업할 수 있습니다. 레이블 값은 빈 문자열을 포함하여 모든 문자열이 될 수 있습니다. 백업 중인 구성 요소를 식별하는 데 도움이 될 수 있는 값을 사용합니다. 예를 들어, 구성 요소를 IDP 솔루션으로 제공하는 경우 cluster.open-cluster-management.io/backup: idp 레이블을 사용합니다.

참고: 관리 클러스터 활성화 리소스가 복원될 때 리소스를 복원하려면 cluster.open-cluster-management.io/backup 레이블에 cluster-activation 값을 사용합니다. 관리형 클러스터 활성화 리소스를 복원하면 관리 클러스터는 복원이 시작된 허브 클러스터에서 적극적으로 관리합니다.

apiVersion: my.group/v1alpha1
kind: MyResource
metadata:
  labels:
    cluster.open-cluster-management.io/backup: cluster-activation

Velero가 처음 설치되면 다음 샘플에 정의된 대로 Velero pod가 기본 CPU 및 메모리 제한으로 설정됩니다.

resources:
 limits:
   cpu: "1"
   memory: 256Mi
 requests:
   cpu: 500m
   memory: 128Mi

이전 샘플의 제한은 일부 시나리오에서 잘 작동하지만 클러스터가 많은 리소스를 백업하는 경우 업데이트해야 할 수 있습니다. 예를 들어, 백업이 2000 클러스터를 관리하는 hub 클러스터에서 실행되면 메모리 부족 오류(OOM)로 인해 Velero pod가 충돌합니다. 이 시나리오에 대해 다음 구성을 통해 백업이 완료될 수 있습니다.

  limits:
    cpu: "2"
    memory: 1Gi
  requests:
    cpu: 500m
    memory: 256Mi

Velero pod 리소스에 대한 제한 및 요청을 업데이트하려면 DataProtectionApplication 리소스를 업데이트하고 Velero pod에 대한 resourceAllocation 템플릿을 삽입해야 합니다. 다음 샘플을 확인합니다.

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero
  namespace: open-cluster-management-backup
spec:
...
  configuration:
...
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "2"
            memory: 1Gi
          requests:
            cpu: 500m
            memory: 256Mi

DataProtectionApplication 매개변수에 대한 자세한 내용은 Velero 리소스 요청 및 제한 사용자 지정을 참조하십시오.

서버 측 암호화는 스토리지 위치에서 데이터를 수신하는 애플리케이션 또는 서비스의 데이터 암호화입니다. 백업 메커니즘 자체는 전송 중(백업 스토리지 위치로 이동) 또는 유휴 상태에서 데이터를 암호화하지 않으며(백업 스토리지 위치의 디스크에 저장됨)는 데이터를 암호화하지 않습니다. 대신 오브젝트 및 스냅샷 시스템의 기본 메커니즘에 의존합니다.

모범 사례: 사용 가능한 백업 스토리지 서버 측 암호화를 사용하여 대상의 데이터를 암호화합니다. 백업에는 hub 클러스터 외부에 저장할 때 암호화해야 하는 자격 증명 및 구성 파일과 같은 리소스가 포함되어 있습니다.

serverSideEncryption 및 kmsKeyId 매개변수를 사용하여 Amazon S3에 저장된 백업의 암호화를 활성화할 수 있습니다. 자세한 내용은 Backup Storage Location YAML 을 참조하십시오. 다음 샘플은 DataProtectionApplication 리소스를 설정할 때 AWS KMS 키 ID를 지정합니다.

spec:
  backupLocations:
    - velero:
        config:
          kmsKeyId: 502b409c-4da1-419f-a16e-eif453b3i49f
          profile: default
          region: us-east-1

Velero 지원 스토리지 공급자를 참조하여 다른 스토리지 공급자의 구성 가능한 모든 매개변수에 대해 알아보십시오.

backupschedule.cluster. open-cluster-management.io 리소스를 생성할 때 백업 일정이 활성화됩니다. 다음 backupschedule.cluster.open-cluster-management.io 샘플을 확인합니다.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
  name: schedule-acm
spec:
  veleroSchedule: 0 */2 * * *
  veleroTtl: 120h

backupschedule.cluster.open-cluster-management.io 리소스를 생성한 후 다음 명령을 실행하여 예약된 클러스터 백업 상태를 가져옵니다.

oc get bsch -n <oadp-operator-ns>

이전 명령의 < oadp-operator-ns > 매개변수는 BackupSchedule 이 생성되는 네임스페이스입니다. 이는 OADP Operator가 설치된 네임스페이스와 동일합니다. backupschedule.cluster.open-cluster-management.io 리소스는 백업을 생성하는 데 사용되는 6개의 schedule.velero.io 리소스를 생성합니다. 다음 명령을 실행하여 예약된 백업 목록을 확인합니다.

os get schedules -A | grep acm

리소스는 다음 그룹에서 별도로 백업됩니다.

참고: 리소스 백업 파일에는 관리되는 클러스터별 리소스가 포함되어 있지만 관리 클러스터를 허브 클러스터에 연결하는 리소스의 서브 세트는 포함되지 않습니다. 관리 클러스터를 연결하는 리소스를 활성화 리소스라고 하며 관리형 클러스터 백업에 포함됩니다. 새 허브 클러스터에서 인증 정보 및 리소스 백업에 대해서만 백업을 복원하면 새 허브 클러스터에서 Hive API를 사용하여 생성된 모든 관리 클러스터를 분리된 상태로 표시합니다. 그러나 가져오기 작업을 사용하여 기본 허브 클러스터에서 가져온 관리형 클러스터는 수동 허브 클러스터에서 활성화 데이터가 복원될 때만 나타납니다. 현재 관리 클러스터는 백업 파일을 생성한 원래 허브 클러스터에 계속 연결됩니다.

활성화 데이터가 복원되면 Hive API를 사용하여 생성된 관리 클러스터만 새 허브 클러스터와 자동으로 연결됩니다. 다른 모든 관리 클러스터는 Pending 상태로 표시되고 새 클러스터에 수동으로 다시 연결해야 합니다.

새 허브 클러스터에서 복원 작업을 실행하기 전에 hub 클러스터를 수동으로 구성하고 초기 허브 클러스터에 동일한 운영자를 설치해야 합니다. Red Hat Advanced Cluster Management Operator를 초기 허브 클러스터와 동일한 네임스페이스에 설치하고 DataProtectionApplication 리소스를 만든 다음 이전에 데이터를 백업한 초기 허브 클러스터와 동일한 스토리지 위치에 연결해야 합니다.

예를 들어 초기 허브 클러스터에 Ansible Automation Platform, Red Hat OpenShift GitOps, cert-manager 와 같은 다른 Operator가 설치된 경우 복원 작업을 실행하기 전에 설치해야 합니다. 이렇게 하면 새 hub 클러스터가 초기 hub 클러스터와 동일한 방식으로 구성됩니다.

Velero는 현재 hub 클러스터에서 기존 백업 리소스를 건너뜁니다. 이렇게 하면 새 허브 클러스터에서 허브 클러스터 데이터를 복원할 때 사용할 수 있는 시나리오가 제한됩니다. 새 hub 클러스터를 사용하고 복원이 두 번 이상 적용되는 경우 복원을 실행하기 전에 데이터를 정리하지 않는 한 허브 클러스터는 수동 구성으로 사용하지 않는 것이 좋습니다. 새 허브 클러스터의 데이터는 복원된 리소스와 함께 사용할 수 있는 데이터를 반영하지 않습니다.

restore.cluster.open-cluster-management.io 리소스가 생성되면 클러스터 백업 및 복원 Operator는 Velero 복원이 시작되기 전에 hub 클러스터를 정리하여 복원을 준비하는 일련의 단계를 실행합니다.

cleanup 옵션은 cleanupBeforeRestore 속성을 사용하여 정리할 오브젝트의 하위 집합을 식별합니다. 이 정리에 대해 세 가지 옵션을 설정할 수 있습니다.

참고:

허브 클러스터에서 클러스터를 관리하려면 restore-passive-activate 샘플을 사용합니다. 이 경우 다른 데이터가 수동 리소스를 사용하는 허브 클러스터에서 이미 복원되었다고 가정합니다.

수동 데이터는 시크릿, ConfigMaps, 애플리케이션, 정책 및 모든 관리 클러스터 사용자 정의 리소스와 같은 백업 데이터로, 관리 클러스터와 허브 클러스터 간의 연결을 활성화하지 않습니다. 백업 리소스는 인증 정보 백업 및 복원 리소스에 의해 hub 클러스터에서 복원됩니다.

restore-passive-sync 샘플을 사용하여 수동 데이터를 복원하면서 새 백업을 사용할 수 있는지 확인하고 자동으로 복원합니다. 새 백업을 자동으로 복원하려면 syncRestoreWithNewBackups 매개변수를 true 로 설정해야 합니다. 또한 최신 수동 데이터만 복원해야 합니다.

VeleroResourcesBackupName 및 VeleroCredentialsBackupName 매개변수를 latest 로 설정하고 VeleroManagedClustersBackupName 매개변수를 건너뛰도록 설정합니다. VeleroManagedClustersBackupName 이 latest 로 설정된 직후 관리 클러스터는 새 허브 클러스터에서 활성화되고 이제 기본 허브 클러스터입니다.

활성화된 관리 클러스터가 기본 허브 클러스터가 되면 복원 리소스가 Finished 로 설정되고 true 로 설정된 경우에도 syncRestoreWithNewBackups 가 무시됩니다.

기본적으로 컨트롤러는 syncRestoreWithNewBackups 가 true 로 설정된 경우 30분마다 새 백업을 확인합니다. 새 백업이 있으면 백업된 리소스를 복원합니다. restoreSyncInterval 매개변수를 업데이트하여 점검 기간을 변경할 수 있습니다.

예를 들어 다음 리소스는 10분마다 백업을 확인합니다.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive-sync
spec:
  syncRestoreWithNewBackups: true # restore again when new backups are available
  restoreSyncInterval: 10m # check for new backups every 10 minutes
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: skip
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

Hive API를 사용하여 기본 허브 클러스터와 연결된 관리 클러스터만 활성화 데이터가 복원되는 새 hub 클러스터와 자동으로 연결됩니다. 이러한 클러스터는 클러스터 탭의 Create cluster 버튼을 사용하여 기본 허브 클러스터에 생성되었습니다. Import cluster 버튼을 사용하여 초기 hub 클러스터와 연결된 관리 클러스터는 활성화 데이터가 복원될 때 가져오기 보류 중으로 표시되고 새 허브 클러스터에서 다시 가져와야 합니다.

Hive는 허브 클러스터의 관리형 클러스터 네임스페이스에 관리형 클러스터 kubeconfig 를 저장하므로 Hive에서 새 허브 클러스터 클러스터와 연결할 수 있습니다. 새 hub 클러스터에서 백업 및 복원됩니다. 그런 다음 가져오기 컨트롤러는 Hive API를 사용하여 생성된 관리형 클러스터에서만 사용할 수 있는 복원된 구성을 사용하여 관리형 클러스터에서 부트스트랩 kubeconfig 를 업데이트합니다. 가져온 클러스터에서는 사용할 수 없습니다.

새 허브 클러스터에서 가져온 클러스터를 다시 연결하려면 복원 작업을 시작한 후 자동 가져오기-secret 리소스를 수동으로 생성합니다. 자세한 내용은 자동 가져오기 보안을 사용하여 클러스터 가져오기 를 참조하십시오.

Pending Import 상태의 각 클러스터의 관리 클러스터 네임스페이스에 auto-import-secret 리소스를 생성합니다. 가져오기 구성 요소에서 새 허브 클러스터에서 자동 가져오기를 시작할 수 있는 충분한 권한이 있는 kubeconfig 또는 토큰을 사용합니다. 관리형 클러스터와 연결하는 토큰을 사용하여 각 관리 클러스터에 대한 액세스 권한이 있어야 합니다. 토큰에는 klusterlet 역할 바인딩 또는 동일한 권한이 있는 역할이 있어야 합니다.

관리형 클러스터 활성화 데이터 또는 기타 활성화 데이터는 백업 리소스입니다. 새 hub 클러스터에서 활성화 데이터를 복원하면 관리 클러스터는 복원이 실행되는 허브 클러스터에서 적극적으로 관리됩니다. 활성화 데이터 리소스는 cluster.open-cluster-management.io/backup: cluster-activation 레이블을 사용할 때 관리 클러스터 백업 및 리소스 일반 백업에 의해 저장됩니다.

cluster.open-cluster-management.io/backup: cluster-activation 레이블을 리소스에 추가하면 리소스가 acm-resources-generic-schedule 백업 리소스에서 자동으로 백업됩니다. 복원 리소스에서 veleroManagedClustersBackupName:latest 라벨 값을 설정하면 일반적으로 리소스를 복원해야 합니다. 관리 클러스터를 새 허브 클러스터로 이동할 때 이러한 리소스를 복원해야 하는 경우 veleroManagedClustersBackupName:latest 라벨 값을 cluster-activation 으로 설정합니다. 이렇게 하면 관리 대상 클러스터 활성화가 시작되지 않는 한 리소스가 복원되지 않습니다.

리소스는 다음 예와 유사합니다.

apiVersion: my.group/v1alpha1
kind: MyResource
metadata:
  labels:
    cluster.open-cluster-management.io/backup: cluster-activation

acm-managed-clusters-schedule 리소스에서 지원하는 활성화 세트에도 기본 리소스가 있습니다. acm-managed-clusters-schedule 리소스에서 복원한 다음 기본 리소스를 확인합니다.

활성 및 수동 허브 클러스터 모두의 경우:

패시브 허브 클러스터의 경우:

처음으로 MultiClusterHub 리소스를 생성할 때 클러스터 백업 및 복원 Operator를 활성화할 수 있습니다. cluster-backup 매개변수가 true 로 설정됩니다. Operator가 활성화되면 Operator 리소스가 설치됩니다.

MultiClusterHub 리소스가 이미 생성된 경우 MultiClusterHub 리소스를 편집하여 클러스터 백업 Operator를 설치하거나 제거할 수 있습니다. 클러스터 백업 Operator를 제거하려면 cluster-backup 을 false 로 설정합니다.

백업 및 복원 Operator가 활성화되면 MultiClusterHub 리소스가 다음 YAML 파일과 유사합니다.

apiVersion: operator.open-cluster-management.io/v1
  kind: MultiClusterHub
  metadata:
    name: multiclusterhub
    namespace: open-cluster-management
  spec:
    availabilityConfig: High
    enableClusterBackup: false
    imagePullSecret: multiclusterhub-operator-pull-secret
    ingress:
      sslCiphers:
        - ECDHE-ECDSA-AES256-GCM-SHA384
        - ECDHE-RSA-AES256-GCM-SHA384
        - ECDHE-ECDSA-AES128-GCM-SHA256
        - ECDHE-RSA-AES128-GCM-SHA256
    overrides:
      components:
        - enabled: true
          name: multiclusterhub-repo
        - enabled: true
          name: search
        - enabled: true
          name: management-ingress
        - enabled: true
          name: console
        - enabled: true
          name: insights
        - enabled: true
          name: grc
        - enabled: true
          name: cluster-lifecycle
        - enabled: true
          name: volsync
        - enabled: true
          name: multicluster-engine
        - enabled: false
          name: cluster-proxy-addon
        - enabled: true <<<<<<<<
          name: cluster-backup
    separateCertificateManagement: false

백업을 예약 및 복원하려면 다음 단계를 완료합니다.

다음 명령을 사용하여 복원 이벤트에 대한 정보를 가져옵니다.

oc describe -n <oadp-n> <restore-name>

이벤트 목록은 다음 샘플과 유사합니다.

Spec:
  Cleanup Before Restore:               CleanupRestored
  Restore Sync Interval:                4m
  Sync Restore With New Backups:        true
  Velero Credentials Backup Name:       latest
  Velero Managed Clusters Backup Name:  skip
  Velero Resources Backup Name:         latest
Status:
  Last Message:                     Velero restores have run to completion, restore will continue to sync with new backups
  Phase:                            Enabled
  Velero Credentials Restore Name:  example-acm-credentials-schedule-20220406171919
  Velero Resources Restore Name:    example-acm-resources-schedule-20220406171920
Events:
  Type    Reason                   Age   From                Message
  ----    ------                   ----  ----                -------
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-credentials-hive-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-credentials-cluster-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-credentials-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-resources-generic-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-resources-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-credentials-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-resources-generic-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-resources-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-credentials-cluster-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-credentials-hive-schedule-20220406155817
  Normal  Prepare to restore:      64m   Restore controller  Cleaning up resources for backup acm-resources-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-credentials-hive-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-credentials-cluster-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-credentials-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-resources-generic-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-credentials-cluster-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-credentials-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-resources-generic-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-resources-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-credentials-hive-schedule-20220406165328
  Normal  Prepare to restore:      38m   Restore controller  Cleaning up resources for backup acm-resources-generic-schedule-20220406171920
  Normal  Prepare to restore:      38m   Restore controller  Cleaning up resources for backup acm-resources-schedule-20220406171920
  Normal  Prepare to restore:      36m   Restore controller  Cleaning up resources for backup acm-credentials-hive-schedule-20220406171919
  Normal  Prepare to restore:      36m   Restore controller  Cleaning up resources for backup acm-credentials-cluster-schedule-20220406171919
  Normal  Prepare to restore:      36m   Restore controller  Cleaning up resources for backup acm-credentials-schedule-20220406171919
  Normal  Velero restore created:  36m   Restore controller  example-acm-credentials-cluster-schedule-20220406171919
  Normal  Velero restore created:  36m   Restore controller  example-acm-credentials-schedule-20220406171919
  Normal  Velero restore created:  36m   Restore controller  example-acm-resources-generic-schedule-20220406171920
  Normal  Velero restore created:  36m   Restore controller  example-acm-resources-schedule-20220406171920
  Normal  Velero restore created:  36m   Restore controller  example-acm-credentials-hive-schedule-20220406171919

필요한 사양 속성 및 유효한 옵션에 대한 설명은 백업 복원 을 참조하십시오.