백업 및 복원

Red Hat Advanced Cluster Management for Kubernetes 2.8

자세한 내용은 백업 및 복원에 대해 알아보십시오.

초록

자세한 내용은 백업 및 복원에 대해 알아보십시오.

1장. 백업 및 복원

클러스터 백업 및 복원 Operator는 hub 클러스터에서 실행되며 Kubernetes 허브 클러스터 장애에 대한 Red Hat Advanced Cluster Management에 대한 재해 복구 솔루션을 제공합니다. hub 클러스터가 실패하면 모든 관리 클러스터가 계속 작동하는 경우에도 정책 구성 기반 경고 또는 클러스터 업데이트와 같은 일부 기능이 작동하지 않습니다. hub 클러스터를 사용할 수 없는 경우 복구 계획이 필요한지 또는 새로 배포된 허브 클러스터에서 데이터를 복구해야 하는지 여부를 결정해야 합니다.

백업 및 복원 구성 요소는 정책을 사용하여 기본 허브 클러스터를 사용할 수 없는 시기를 관리자에게 알리고 복원 작업이 필요할 수 있습니다. 백업 솔루션이 예상대로 작동하지 않는 경우 관리자에게 경고하고 기본 허브 클러스터가 활성 상태이고 클러스터를 관리하는 경우에도 백업 데이터 문제를 보고합니다.

클러스터 백업 및 복원 Operator는 OADP Operator 에 따라 Velero를 설치하고 허브 클러스터에서 데이터가 저장된 백업 스토리지 위치로의 연결을 생성합니다. Velero는 백업 및 복원 작업을 실행하는 구성 요소입니다. 클러스터 백업 및 복원 Operator 솔루션은 관리 클러스터, 애플리케이션 및 정책을 포함한 모든 Red Hat Advanced Cluster Management 허브 클러스터 리소스에 대한 백업 및 복원 지원을 제공합니다.

클러스터 백업 및 복원 Operator는 허브 클러스터 설치를 확장하는 타사 리소스의 백업을 지원합니다. 이 백업 솔루션을 사용하면 지정된 시간 간격으로 실행되는 cron 기반 백업 일정을 정의할 수 있습니다. hub 클러스터가 실패하면 새 hub 클러스터를 배포하고 백업된 데이터가 새 허브 클러스터로 이동합니다.

다음 항목을 계속 읽고 백업 및 복원 연산자에 대해 자세히 알아봅니다.Continue reading the following topics to learn more about the backup and restore operator:

1.1. 백업 및 복원 Operator 아키텍처

Operator는 Red Hat Advanced Cluster Management 백업 일정과 이러한 백업을 처리하고 복원하는 데 사용되는 restore.cluster.open-cluster-management.io 리소스를 정의하는 BackupSchedule.cluster.open-cluster-management.io 리소스를 정의합니다. Operator는 해당 Velero 리소스를 생성하고, 복원해야 하는 원격 클러스터 및 기타 허브 클러스터 리소스를 백업하는 데 필요한 옵션을 정의합니다. 다음 다이어그램을 확인합니다.

Backup and restore architecture diagram

1.1.1. 백업되는 리소스

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

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

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

  • MultiClusterHub 네임스페이스의 모든 리소스를 제외합니다. 이는 현재 허브 클러스터 ID에 연결된 설치 리소스를 백업하지 않기 위한 것이며 백업하면 안 됩니다.
  • .open-cluster-management.io .open-cluster-management.io 접미사로 API 버전을 사용하여 모든 사용자 정의 리소스 정의를 백업합니다. 이 접미사는 모든 Red Hat Advanced Cluster Management 리소스가 백업되었음을 나타냅니다.
  • 다음 API 그룹에서 모든 사용자 지정 리소스 정의 백업: argoproj.io,app.k8s.io,core.observatorium.io,hive.openshift.io.
  • 다음 API 그룹에서 모든 사용자 정의 리소스 정의를 제외합니다. admission.cluster.open-cluster-management.io,admission.work.open-cluster-management.io,internal.open-cluster-management.io,operator.open-cluster-management.io,work.open-cluster-management.io,search.open-cluster-management.io,admission.hive.openshift.io,velero.io.io .
  • 포함된 API 그룹의 일부인 다음 사용자 정의 리소스 정의를 제외합니다. 이 정의는 필요하지 않거나 백업되는 소유자 리소스에 의해 다시 생성됩니다. clustermanagementaddon,observabilityaddon,applicationmanager,certpolicycontroller ,iampolicycontroller,searchcollector,workmanager,backupschedule,restore,clusterclaim.cluster.open-cluster-management.io.
  • cluster.open-cluster-management.io/type,hive.openshift.io/secret-type,cluster.open-cluster-management.io/backup 라벨이 있는 시크릿 및 ConfigMap을 백업합니다.
  • 백업하려는 기타 리소스에 대해 cluster.open-cluster-management.io/backup 레이블을 사용하며 이전에 언급한 기준에 포함되지 않습니다. 다음 예제를 참조하십시오.

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

    참고: hive.openshift.io.ClusterDeployment 리소스에서 사용하는 보안을 백업해야 하며 콘솔을 사용하여 클러스터를 생성할 때만 cluster.open-cluster-management.io/backup 레이블로 자동으로 주석이 추가됩니다. 대신 GitOps를 사용하여 Hive 클러스터를 배포하는 경우 cluster.open-cluster-management.io/backup 레이블을 ClusterDeployment 에서 사용하는 보안에 수동으로 추가해야 합니다.

  • 백업하지 않으려는 특정 리소스를 제외합니다. 예를 들어 백업 프로세스에서 Velero 리소스를 제외하려면 다음 예제를 참조하십시오.

    apiVersion: my.group/v1alpha1
    kind: MyResource
     metadata:
      labels:
        velero.io/exclude-from-backup: "true"

1.1.2. 관리형 클러스터 활성화 시 복원된 리소스

리소스에 cluster.open-cluster-management.io/backup 레이블을 추가하면 acm-resources-generic-schedule 백업에서 리소스가 자동으로 백업됩니다. 관리 클러스터를 새 허브 클러스터로 이동한 후 복원된 리소스에서 veleroManagedClustersBackupName:latest 가 사용되는 경우에만 리소스 중 하나를 cluster-activation 으로 설정해야 합니다. 이렇게 하면 관리 대상 클러스터 활성화를 호출하지 않는 한 리소스가 복원되지 않습니다. 다음 예제를 확인합니다.

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

cluster.open-cluster-management.io/backup: cluster-activation 레이블로 식별되고 acm-resources-generic-schedule 백업으로 저장된 활성화 데이터 리소스 외에도 클러스터 백업 및 복원 Operator에는 기본적으로 몇 가지 리소스가 포함되어 있습니다. acm-managed-clusters-schedule 백업으로 지원되는 리소스는 다음과 같습니다.

  • managedcluster.cluster.open-cluster-management.io
  • managedcluster.clusterview.open-cluster-management.io
  • klusterletaddonconfig.agent.open-cluster-management.io
  • managedclusteraddon.addon.open-cluster-management.io
  • managedclusterset.cluster.open-cluster-management.io
  • managedclusterset.clusterview.open-cluster-management.io
  • managedclustersetbinding.cluster.open-cluster-management.io
  • clusterpool.hive.openshift.io
  • clusterclaim.hive.openshift.io
  • clustercurator.cluster.open-cluster-management.io

1.2. 활성 수동 허브 클러스터 구성

초기 허브 클러스터에서 데이터를 백업하고 활성 클러스터를 사용할 수 없게 될 때 관리 클러스터를 제어하기 위해 하나 이상의 수동 허브 클러스터 구성이 있는 활성 수동 허브 클러스터 구성을 구성하는 방법을 알아봅니다.

1.2.1. 활성 수동 구성

활성 수동 구성에는 하나의 활성 허브 클러스터 및 수동 허브 클러스터가 있습니다. 활성 허브 클러스터는 BackupSchedule.cluster.open-cluster-management.io 리소스를 사용하여 정의된 시간 간격으로 클러스터를 관리하고 리소스를 백업하는 기본 허브 클러스터라고도 합니다.

수동 허브 클러스터는 지속적으로 최신 백업을 검색하고 수동 데이터를 복원합니다. 수동 허브는 Restore.cluster.open-cluster-management.io 리소스를 사용하여 새 백업 데이터를 사용할 수 있는 경우 기본 허브 클러스터에서 수동 데이터를 복원합니다. 이러한 허브 클러스터는 기본 허브 클러스터가 실패할 때 기본 허브 클러스터가 기본 허브가 되도록 보류 상태에 있습니다.

활성 및 수동 허브 클러스터는 동일한 스토리지 위치에 연결됩니다. 여기서 기본 허브 클러스터는 기본 허브 클러스터 백업에 액세스할 수동 허브 클러스터의 데이터를 백업합니다. 이 자동 복원 구성을 설정하는 방법에 대한 자세한 내용은 백업을 확인하는 동안 수동 리소스 복구를 참조하십시오.

다음 다이어그램에서 활성 허브 클러스터는 로컬 클러스터를 관리하고 주기적으로 hub 클러스터 데이터를 백업합니다.

Active passive configration diagram

패시브 허브 클러스터는 관리형 클러스터 활성화 데이터를 제외하고 이 데이터를 복원하여 관리 클러스터를 수동 허브 클러스터로 이동합니다. 패시브 허브 클러스터는 수동 데이터를 지속적으로 복원할 수 있습니다. 패시브 허브 클러스터는 수동 데이터를 일회성 작업으로 복원할 수 있습니다. 자세한 내용은 수동 리소스 복구를 참조하십시오.

1.2.2. 재해 복구

기본 허브 클러스터가 실패하면 관리자가 관리형 클러스터를 인수할 수동 허브 클러스터를 선택합니다. 다음 이미지에서 관리자는 Hub 클러스터 N 을 새 기본 허브 클러스터로 사용하기로 결정합니다.

Disaster recovery diagram

hub cluster N 은 관리형 클러스터 활성화 데이터를 복원합니다. 이 시점에서 관리 클러스터는 Hub 클러스터 N과 연결됩니다. 관리자는 BackupSchedule.cluster.open-cluster-management.io 리소스를 생성하고 초기 기본 허브 클러스터와 동일한 스토리지 위치에 백업을 저장하여 새 기본 허브 클러스터, Hub 클러스터 N 에서 백업을 활성화합니다.

다른 모든 수동 허브 클러스터에서는 이제 새 기본 허브 클러스터에서 생성한 백업 데이터를 사용하여 수동 데이터를 복원합니다. Hub N 은 이제 기본 허브 클러스터로서 클러스터를 관리하고 데이터를 백업합니다.

참고:

  • 이전 다이어그램의 프로세스 1은 기본 허브 클러스터가 실패하여 교체해야 하는지 또는 hub 클러스터와 관리 클러스터 간에 네트워크 통신 오류가 있는지 확인해야 하므로 자동화되지 않습니다. 관리자는 또한 어떤 패시브 허브 클러스터가 기본 허브 클러스터가 될지 결정합니다. :aap: 작업과의 정책 통합은 백업 정책에서 백업 오류를 보고할 때 작업을 실행하여 이 단계를 자동화하는 데 도움이 될 수 있습니다.
  • 이전 다이어그램의 프로세스 2는 수동입니다. 관리자가 새 기본 허브 클러스터에서 백업을 생성하지 않으면 cron 작업으로 적극적으로 실행되는 백업을 사용하여 관리자에게 알립니다.

1.2.3. 추가 리소스

1.3. 백업 및 복원 Operator 설치

클러스터 백업 및 복원 Operator가 자동으로 설치되지 않습니다. 계속 읽고 Operator를 설치하고 활성화하는 방법을 알아봅니다.

참고: 이전에 백업 구성 요소 네임스페이스와 다른 네임스페이스의 hub 클러스터에 OADP Operator를 설치하고 사용한 경우 이 버전을 제거합니다. 이제 백업 구성 요소가 구성 요소 네임스페이스에 설치된 OADP에서 작동합니다. 백업 구성 요소와 함께 설치된 OADP Operator가 소유한 DataProtectionApplication 리소스에 대해 동일한 스토리지 위치를 사용합니다. 이전 Operator와 동일한 백업 데이터에 액세스합니다. 이제 Velero 백업 리소스가 이 허브 클러스터의 새 OADP Operator 네임스페이스 내에 로드됩니다.

Velero는 Red Hat Advanced Cluster Management for Kubernetes hub 클러스터에 OADP Operator와 함께 설치됩니다. Red Hat Advanced Cluster Management Hub 클러스터 리소스를 백업하고 복원하는 데 사용됩니다.

Velero에 지원되는 스토리지 공급자 목록은 S3 호환 오브젝트 저장소 공급자를 참조하십시오.

1.3.1. 사전 요구 사항

백업 및 복원 연산자를 활성화하고 사용하려면 다음 사전 요구 사항을 충족해야 합니다.

  • 백업이 저장된 클라우드 스토리지에 대한 인증 정보 시크릿 생성 단계를 완료해야 합니다. 시크릿 리소스는 백업 구성 요소 네임스페이스에 있는 OADP Operator 네임스페이스에 생성해야 합니다.
  • 활성 및 수동 허브 클러스터 모두의 경우:

    • Red Hat OpenShift Container Platform 클러스터에서 Kubernetes Operator 버전 2.8.x용 Red Hat Advanced Cluster Management를 설치합니다. Red Hat Advanced Cluster Management를 설치할 때 MultiClusterHub 리소스가 자동으로 생성되고 실행 중 상태가 표시됩니다.
    • 클러스터 백업 및 복원 Operator를 수동으로 설치해야 합니다. 클러스터 백업 및 복원 Operator (cluster-backup)를 활성화합니다. cluster-backup 매개변수를 true 로 설정하여 MultiClusterHub 리소스를 편집합니다. 그러면 백업 구성 요소와 동일한 네임스페이스에 OADP Operator가 설치됩니다.
  • 패시브 허브 클러스터의 경우:

    • 수동 허브 클러스터에서 복원 작업을 실행하기 전에 hub 클러스터를 수동으로 구성하고 활성 허브 클러스터에 모든 운영자를 설치하고 활성 허브 클러스터와 동일한 네임스페이스에 설치해야 합니다.
    • Red Hat Advanced Cluster Management Operator가 초기 허브 클러스터와 동일한 네임스페이스에 설치되어 있는지 확인합니다. 그런 다음 DataProtectionApplication 리소스를 만들고 초기 허브 클러스터가 데이터를 백업한 것과 동일한 스토리지 위치에 연결합니다.
  • DataProtectionApplication 리소스를 생성할 때 생성된 시크릿을 사용합니다.

    DataProtectionApplication 리소스의 인스턴스를 생성하려면 다음 단계를 완료합니다.

    1. Red Hat OpenShift Container Platform 콘솔에서 Operator > 설치된 Operator 를 선택합니다.
    2. DataProtectionApplication에서 Create instance 를 클릭합니다.
    3. {ocp-short) 콘솔을 사용하거나 DataProtectionApplication 예제에서 언급한 YAML 파일을 사용하여 구성을 선택하여 Velero 인스턴스를 생성합니다.
    4. DataProtectionApplication 네임스페이스를 open-cluster-management-backup 으로 설정합니다.
    5. DataProtectionApplication 리소스에 대해 사양(spec:) 값을 적절하게 설정합니다. 그런 다음 만들기 를 클릭합니다.

      기본 백업 스토리지 위치를 사용하려는 경우 backupStorageLocations 섹션에서 다음 값, default: true 를 설정합니다. 다음 DataProtectionApplication 리소스 샘플을 확인합니다.

      apiVersion: oadp.openshift.io/v1alpha1
      kind: DataProtectionApplication
      metadata:
        name: dpa-sample
      spec:
        configuration:
          velero:
            defaultPlugins:
            - openshift
            - aws
          restic:
            enable: true
        backupLocations:
          - name: default
            velero:
              provider: aws
              default: true
              objectStorage:
                bucket: my-bucket
                prefix: my-prefix
              config:
                region: us-east-1
                profile: "default"
              credential:
                name: cloud-credentials
                key: cloud
        snapshotLocations:
          - name: default
            velero:
              provider: aws
              config:
                region: us-west-2
                profile: "default"

      DataProtectionApplication 리소스를 만드는 예제를 참조하십시오.

      • 복원 작업을 실행하기 전에 Ansible Automation Platform, Red Hat OpenShift Container Platform GitOps 또는 인증서 관리자와 같은 다른 Operator가 설치되어 있는지 확인합니다. 이렇게 하면 새 허브 클러스터가 초기 허브 클러스터와 동일한 방식으로 구성됩니다.
      • 패시브 허브 클러스터는 백업 및 복원 Operator를 설치할 때 초기 허브 클러스터와 동일한 네임스페이스 이름을 사용하고 이전 허브 클러스터에 구성된 다른 Operator를 사용해야 합니다.
  • 연결이 끊긴 환경의 경우:

    연결이 끊긴 환경에서 Red Hat OpenShift Container Platform을 사용하여 백업 및 복원 구성 요소를 활성화하면 다음 추가 단계를 완료합니다.

    1. OADP Operator가 설치된 소스를 덮어쓰도록 follwing 주석으로 MultiClusterHub 리소스를 업데이트합니다. MultiClusterHub 리소스에서 cluster-backup 구성 요소가 활성화되기 전에 주석을 생성합니다.

      apiVersion: operator.open-cluster-management.io/v1
      kind: MultiClusterHub
      metadata:
        annotations:
          installer.open-cluster-management.io/oadp-subscription-spec: '{"source": "redhat-operator-index"}'
    2. redhat-operator-index 는 사용자 지정 이름으로, 사용자가 정의하고 연결이 끊긴 환경에서 Red Hat OpenShift Operator에 액세스하는 데 사용하는 CatalogSource 리소스의 이름을 나타냅니다. 다음 명령을 실행하여 catalogsource 를 검색합니다.

      oc get catalogsource -A

      출력은 다음과 유사합니다.

      NAMESPACE               NAME                         DISPLAY                       TYPE   PUBLISHER   AGE
      openshift-marketplace   acm-custom-registry          Advanced Cluster Management   grpc   Red Hat     42h
      openshift-marketplace   multiclusterengine-catalog   MultiCluster Engine           grpc   Red Hat     42h
      openshift-marketplace   redhat-operator-index                                      grpc               42h

1.3.2. 백업 및 복원 연산자 활성화

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

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

백업 및 복원 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: true
          name: cluster-backup
    separateCertificateManagement: false

1.3.3. 추가 리소스

1.4. 관리형 클러스터 활성화 데이터 복원

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

Operator를 사용하는 방법에 대한 자세한 내용은 스케줄링 및 백업 복원 을 참조하십시오.

1.4.1. 활성화 데이터를 복원하기 전에 클러스터 준비

새 허브 클러스터에서 활성화 데이터를 복원하기 전에 다음 단계를 완료하여 데이터 손상 또는 클러스터 손실을 방지합니다.

  1. 기본 클러스터를 종료합니다.

    자세한 내용은 기본 클러스터 축소를 참조하십시오.

  2. 기존 관리 클러스터를 복원 허브로 사용하려면 MultiClusterHub 에서 disableHubSelfManagementtrue 로 설정합니다.

    자세한 내용은 disableHubSelfManagement 주제를 참조하십시오.

    spec.disableHubSelfManagementtrue 로 설정된 다음 예제를 참조하십시오.

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

참고: 활성화 데이터가 복원 허브 클러스터로 이동하기 전에 복원 허브 클러스터에서 자체 관리 옵션이 비활성화되지 않으면 관리형 클러스터 네임스페이스 충돌의 로컬 클러스터 klusterlet 및 klusterlet이 있습니다. 결과적으로 복원 허브 클러스터는 관리 클러스터를 사용하고 복원된 관리 클러스터를 사용하여 자체적으로 관리됩니다. 관리형 클러스터를 분리 작업의 일부로 분리하면 관리 클러스터는 프로비저닝 해제 요청을 수신하여 복원 허브 클러스터가 제거됩니다.

1.4.2. 추가 리소스

1.5. 백업 예약 및 복원

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

  1. 백업 및 복원 Operator인 backupschedule.cluster.open-cluster-management.io 를 사용하여 백업 일정을 생성하고 restore.cluster.open-cluster-management.io 리소스를 사용하여 백업을 복원합니다.
  2. 다음 명령을 실행하여 backupschedule.cluster.open-cluster-management.io 리소스를 생성합니다.

    oc create -f cluster_v1beta1_backupschedule.yaml

    cluster_v1beta1_backupschedule.yaml 리소스는 다음 파일과 유사합니다.

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: BackupSchedule
    metadata:
      name: schedule-acm
      namespace: open-cluster-management-backup
    spec:
      veleroSchedule: 0 */2 * * * 1
      veleroTtl: 120h 2
    1
    2시간마다 백업 생성
    2
    선택 사항: 120h 후에 예약된 백업을 삭제합니다. 지정하지 않으면 최대 Velero 기본값인 10.0.0.1h가 사용됩니다.

    backupschedule.cluster.open-cluster-management.io 사양 속성에 대한 다음 설명을 확인합니다.

    • veleroSchedule 은 필수 속성이며 백업을 예약하는 cron 작업을 정의합니다.
    • veleroTtl 은 선택적 속성이며 예약된 백업 리소스에 대한 만료 시간을 정의합니다. 지정하지 않으면 Velero에 의해 설정된 최대 기본값이 사용되며, 이는 10.0.0.1 h 입니다.
  3. 3 schedule.velero.io 리소스의 정의를 표시하는 backupschedule.cluster.open-cluster-management.io 리소스의 상태를 확인합니다. 다음 명령을 실행합니다.

    oc get BackupSchedule -n open-cluster-management-backup
  4. 복원 시나리오에서는 복원 시나리오를 위해 다른 허브 클러스터에서 복원 작업이 실행됩니다. 복원 작업을 시작하려면 백업을 복원하려는 hub 클러스터에서 restore.cluster.open-cluster-management.io 리소스를 생성합니다.

    참고: 새 허브 클러스터에서 백업을 복원할 때 백업이 생성된 이전 허브 클러스터를 종료해야 합니다. 관리 클러스터 조정이 실행 중인 경우 관리형 클러스터를 더 이상 사용할 수 없음을 발견하면 이전 hub 클러스터에서 관리 클러스터를 다시 가져오려고 합니다.

    클러스터 백업 및 복원 Operator, backupschedule.cluster.open-cluster-management.iorestore.cluster.open-cluster-management.io 리소스를 사용하여 백업 또는 복원 리소스를 생성할 수 있습니다. cluster-backup-operator 샘플을 참조하십시오.

  5. 다음 명령을 실행하여 restore.cluster.open-cluster-management.io 리소스를 생성합니다.

    oc create -f cluster_v1beta1_backupschedule.yaml

    리소스는 다음 파일과 유사합니다.

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Restore
    metadata:
      name: restore-acm
      namespace: open-cluster-management-backup
    spec:
      veleroManagedClustersBackupName: latest
      veleroCredentialsBackupName: latest
      veleroResourcesBackupName: latest
  6. 다음 명령을 실행하여 Velero 복원 리소스를 확인합니다.

    oc get restore.velero.io -n open-cluster-management-backup
  7. 다음 명령을 실행하여 Red Hat Advanced Cluster Management Restore 이벤트를 확인합니다.

    oc describe restore.cluster.open-cluster-management.io -n open-cluster-management-backup

Restore YAML 리소스의 매개변수 및 샘플에 대한 설명은 백업 복원 섹션을 참조하십시오.

1.5.1. 백업 데이터 확장

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

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

1.5.2. 클러스터 백업 예약

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
  namespace: open-cluster-management-backup
spec:
  veleroSchedule: 0 */2 * * *
  veleroTtl: 120h

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

oc get BackupSchedule -n open-cluster-management-backup

backupschedule.cluster.open-cluster-management.io 리소스는 백업을 생성하는 데 사용되는 6개의 schedule.velero.io 리소스를 생성합니다. 다음 명령을 실행하여 예약된 백업 목록을 확인합니다.

oc get schedules -A | grep acm

리소스는 다음 표에 표시된 것처럼 그룹에서 별도로 백업됩니다.

표 1.1. 리소스 그룹 테이블

리소스설명

자격 증명 백업

Hive 자격 증명, Red Hat Advanced Cluster Management, 사용자가 생성한 인증 정보 및 ConfigMap을 저장하는 백업 파일

리소스 백업

Red Hat Advanced Cluster Management 리소스에 대한 백업 1개와 일반 리소스용 백업이 포함되어 있습니다. 이러한 리소스는 cluster.open-cluster-management.io/backup 라벨을 사용합니다.

관리형 클러스터 백업

백업이 복원되는 hub 클러스터에 대한 관리형 클러스터 연결을 활성화하는 리소스만 포함합니다.

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

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

1.5.3. 추가 리소스

1.6. 백업 복원

일반적인 복원 시나리오에서는 백업이 실행되는 hub 클러스터를 사용할 수 없으며 백업된 데이터를 새 허브 클러스터로 이동해야 합니다. 이 작업은 새 허브 클러스터에서 클러스터 복원 작업을 실행하여 수행됩니다. 이 경우 복원 작업은 백업이 생성된 위치와 다른 허브 클러스터에서 실행됩니다.

이전 스냅샷에서 데이터를 복구할 수 있도록 백업이 수집된 동일한 허브 클러스터에서 데이터를 복원하려는 경우도 있습니다. 이 경우 복원 및 백업 작업이 동일한 허브 클러스터에서 실행됩니다.

hub 클러스터에서 restore.cluster.open-cluster-management.io 리소스를 생성한 후 다음 명령을 실행하여 복원 작업의 상태를 가져올 수 있습니다.

oc get restore -n open-cluster-management-backup

백업 파일에 포함된 백업 리소스가 생성되었는지 확인할 수도 있습니다.

참고: restore.cluster.open-cluster-management.io 리소스는 syncRestoreWithNewBackups 옵션을 사용하여 복원 수동 리소스 섹션에 언급된 대로 true 로 설정하지 않는 한 한 번 실행됩니다. 복원 작업이 완료된 후 동일한 복원 작업을 다시 실행하려면 동일한 사양 옵션을 사용하여 새 restore.cluster.open-cluster-management.io 리소스를 생성해야 합니다.

복원 작업은 백업 작업에서 생성한 3가지 백업 유형을 모두 복원하는 데 사용됩니다. Yu는 특정 유형의 백업만 설치하도록 선택할 수 있습니다(관리된 클러스터만, 사용자 인증 정보만 또는 허브 클러스터 리소스만).

복원은 다음과 같은 3가지 필수 사양 속성을 정의합니다. 여기서 복원 논리는 백업 파일 유형에 대해 정의됩니다.

  • veleroManagedClustersBackupName 은 관리 클러스터 활성화 리소스에 대한 복원 옵션을 정의하는 데 사용됩니다.
  • veleroCredentialsBackupName 은 사용자 자격 증명의 복원 옵션을 정의하는 데 사용됩니다.
  • veleroResourcesBackupName 은 허브 클러스터 리소스(애플리케이션,정책 및 관리형 클러스터 수동 데이터와 같은 기타 허브 클러스터 리소스)에 대한 복원 옵션을 정의하는 데 사용됩니다.

    이전에 언급한 속성의 유효한 옵션은 다음과 같습니다.

    • latest - 이 속성은 이 유형의 백업에 사용 가능한 마지막 백업 파일을 복원합니다.
    • 건너뛰기 - 이 속성은 현재 복원 작업을 사용하여 이 유형의 백업을 복원하지 않습니다.
    • <backup_name > - 이 속성은 지정된 백업을 이름으로 복원합니다.

restore.cluster.open-cluster-management.io 에서 생성한 restore.velero.io 리소스의 이름은 다음 템플릿 규칙인 < restore.cluster.open-cluster-management.io name>-<velero-backup-resource-name > . 다음 설명을 확인합니다.

  • restore.cluster.open-cluster-management.io 이름은 복원을 시작하는 현재 restore.cluster.open-cluster-management.io 리소스의 이름입니다.
  • Velero-backup-resource-name 은 데이터를 복원하는 데 사용되는 Velero 백업 파일의 이름입니다. 예를 들어 restore-acm 이라는 restore.cluster.open-cluster-management.io 리소스는 restore.velero.io 복원 리소스를 생성합니다. 형식에 대한 다음 예제를 확인합니다.

    • restore-acm-acm-managed-clusters-schedule-20210102205438 은 관리형 클러스터 활성화 데이터 백업을 복원하는 데 사용됩니다. 이 샘플에서 리소스를 복원하는 데 사용되는 backup.velero.io 백업 이름은 acm-managed-clusters-schedule-20210902205438 입니다.
    • restore-acm-acm-credentials-schedule-20210902206789 는 인증 정보 백업을 복원하는 데 사용됩니다. 이 샘플에서 리소스를 복원하는 데 사용되는 backup.velero.io 백업 이름은 acm-managed-clusters-schedule-20210902206789 입니다.
    • restore-acm-acm-resources-schedule-20210902201234 는 관리 클러스터 수동 데이터 백업과 같은 애플리케이션, 정책 및 기타 허브 클러스터 리소스를 복원하는 데 사용됩니다. 이 샘플에서 리소스를 복원하는 데 사용되는 backup.velero.io 백업 이름은 acm-managed-clusters-schedule-20210902201234 입니다.

참고: 백업 유형에 skip 이 사용되는 경우 restore.velero.io 가 생성되지 않습니다.

클러스터 복원 리소스의 다음 YAML 샘플을 확인합니다. 이 샘플에서는 사용 가능한 최신 백업 파일을 사용하여 세 가지 유형의 백업 파일이 복원됩니다.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm
  namespace: open-cluster-management-backup
spec:
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

참고: 관리형 클러스터 백업의 acm-managed-clusters 백업이 다른 hub 클러스터에 복원되면 Hive API에서 생성한 관리형 클러스터만 새 hub 클러스터에 자동으로 연결됩니다. 다른 모든 관리형 클러스터는 Pending Import 상태로 유지되며 새 hub 클러스터로 다시 가져와야 합니다. 자세한 내용은 가져온 관리 클러스터 복구(기술 프리뷰)를 참조하십시오.

1.6.1. 새 허브 클러스터 준비

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

MultiClusterEngine 리소스에 대한 변경 사항을 포함하여 Red Hat Advanced Cluster Management Operator에서 생성한 MultiClusterHub 리소스에 대한 초기 허브 클러스터에서와 동일한 구성을 사용합니다.

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

1.6.2. 복원 후 hub 클러스터 정리

Velero는 현재 복원된 백업으로 변경된 경우 기존 리소스를 업데이트합니다. Velero는 이전 복원에 의해 생성된 리소스이며 현재 복원된 백업의 일부가 아닌 CloudEvent 리소스를 정리하지 않습니다. 이렇게 하면 새 허브 클러스터에서 허브 클러스터 데이터를 복원할 때 사용할 수 있는 시나리오가 제한됩니다. 복원이 한 번만 적용되지 않으면 새 허브 클러스터를 수동 구성으로 안정적으로 사용할 수 없습니다. hub 클러스터의 데이터는 복원된 리소스와 함께 사용할 수 있는 데이터를 반영하지 않습니다.

이 제한을 해결하기 위해 Restore.cluster.open-cluster-management.io 리소스가 생성되면 backup Operator는 hub 클러스터를 정리하는 복원 후 작업을 실행합니다. 이 작업에서는 현재 복원된 백업에 포함되지 않은 이전 Red Hat Advanced Cluster Management 복원에서 생성한 리소스를 모두 제거합니다.

후 복원 정리에서는 cleanupBeforeRestore 속성을 사용하여 정리할 오브젝트의 하위 집합을 식별합니다. 복원 후 정리에 다음 두 가지 옵션을 사용할 수 있습니다.

  • none: 필요하지 않음, Velero 복원만 시작합니다. 새로운 허브 클러스터에서 None 을 사용하십시오.
  • CleanupRestored: 현재 복원된 백업에 포함되지 않은 이전 Red Hat Advanced Cluster Management 복원에 의해 생성된 모든 리소스를 정리합니다.
  • cleanupupAll: 복원 작업으로 인해 생성되지 않은 경우에도 Red Hat Advanced Cluster Management 백업의 일부가 될 수 있는 hub 클러스터에서 모든 리소스를 정리합니다. 이는 복원 작업이 시작되기 전에 허브 클러스터에 추가 콘텐츠가 생성될 때 사용됩니다.

    모범 사례: cleanup All 옵션을 사용하지 않도록 합니다. 극단적인 주의가 있는 마지막 수단으로만 사용하십시오. 또한Cleanup All 은 이전에 복원된 백업에 의해 생성된 리소스 외에도 사용자가 생성한 hub 클러스터의 리소스를 정리합니다. 대신 hub 클러스터가 재해 시나리오의 수동 후보로 지정될 때 'CleanupRestored '옵션을 사용하여 hub 클러스터 콘텐츠를 업데이트하지 않도록 합니다. 정리 허브 클러스터를 수동 클러스터로 사용합니다.

참고:

  • 복원된 백업에 리소스가 없는 경우 Velero는 velero 복원 리소스에 대한 상태 PartiallyFailed 를 설정합니다. 즉, 해당 백업이 비어 있기 때문에 생성된 restore.velero.io 리소스에서 리소스를 복원하지 않는 경우 restore.cluster.open-cluster-management.io 리소스가 PartiallyFailed 상태에 있을 수 있습니다.
  • 새 백업을 사용할 수 있는 경우 syncRestoreWithNewBackups:true 를 사용하여 수동 데이터를 계속 복원하지 않는 한 restore.cluster.open-cluster-management.io 리소스가 한 번 실행됩니다. 이 경우 동기화 샘플이 있는 복원 패시브를 따릅니다. 백업을 확인하는 동안 수동 리소스 복구를 참조하십시오. 복원 작업이 완료되고 동일한 허브 클러스터에서 다른 복원 작업을 실행하려면 새 restore.cluster.open-cluster-management.io 리소스를 생성해야 합니다.
  • 여러 restore.cluster.open-cluster-management.io 리소스를 여러 개 생성할 수 있지만 언제든지 하나만 활성화할 수 있습니다.

1.6.3. 백업을 확인하는 동안 수동 리소스 복원

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

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

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

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

예를 들어 10분마다 백업을 확인하는 다음 리소스를 참조하십시오.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive-sync
  namespace: open-cluster-management-backup
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

1.6.4. 수동 리소스 복원

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

다음 샘플을 참조하십시오.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: skip
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

1.6.5. 활성화 리소스 복원

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

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive-activate
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: skip
  veleroResourcesBackupName: skip

수동 리소스를 복원하는 방법에 따라 활성화 리소스를 복원할 수 있는 몇 가지 옵션이 있습니다.

  • restore-acm-passive-sync cluster.open-cluster-management.io 리소스를 사용한 경우 수동 데이터 복원을 확인하는 동안 백업에 설명된 대로 veleroManagedClustersBackupName 값을 이 리소스에 최신 으로 업데이트합니다. 결과적으로 관리 클러스터 리소스 및 restore-acm-passive-sync 리소스가 복원됩니다.
  • 수동 리소스를 한 번 작업으로 복원하거나 아직 리소스를 복원하지 않은 경우 모든 리소스 복원 섹션에 지정된 대로 모든 리소스를 복원 하도록 선택합니다.

1.6.6. 모든 리소스 복원

한 번에 모든 데이터를 복원하고 허브 클러스터에서 관리 클러스터를 한 단계로 관리하도록 하려면 restore-acm 샘플을 사용합니다. hub 클러스터에서 restore.cluster.open-cluster-management.io 리소스를 생성한 후 다음 명령을 실행하여 복원 작업의 상태를 가져옵니다.

oc get restore -n open-cluster-management-backup

샘플은 다음 리소스와 유사합니다.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

hub 클러스터에서 백업 파일에 포함된 백업 리소스가 생성되었는지 확인합니다.

1.6.7. 가져온 관리 클러스터 복원

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

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

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

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

1.6.8. 기타 복원 샘플 사용

다음 복원 섹션을 보고 YAML 예제를 확인하여 다른 유형의 백업 파일을 복원합니다.

  • 세 가지 유형의 백업 리소스를 모두 복원합니다.

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Restore
    metadata:
      name: restore-acm
      namespace: open-cluster-management-backup
    spec:
      veleroManagedClustersBackupSchedule: latest
      veleroCredentialsBackupSchedule: latest
      veleroResourcesBackupSchedule: latest
  • 관리형 클러스터 리소스만 복원하십시오.

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Restore
    metadata:
      name: restore-acm
      namespace: open-cluster-management-backup
    spec:
      veleroManagedClustersBackupName: latest
      veleroCredentialsBackupName: skip
      veleroResourcesBackupName: skip
  • acm-managed-clusters-schedule-202902205438 백업을 사용하여 관리 클러스터의 리소스만 복원하십시오.

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Restore
    metadata:
      name: restore-acm
      namespace: open-cluster-management-backup
    spec:
      veleroManagedClustersBackupName: acm-managed-clusters-schedule-20210902205438
      veleroCredentialsBackupName: skip
      veleroResourcesBackupName: skip

    참고:

    • restore.cluster.open-cluster-management.io 리소스가 한 번 실행됩니다. 복원 작업이 완료되면 동일한 허브 클러스터에서 다른 복원 작업을 선택적으로 실행할 수 있습니다. 새 복원 작업을 실행하려면 새 restore.cluster.open-cluster-management.io 리소스를 생성해야 합니다.
    • 여러 restore.cluster.open-cluster-management.io 를 여러 개 생성할 수 있지만 언제든지 하나만 실행할 수 있습니다.

1.6.9. 복원 이벤트 보기

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

oc describe -n open-cluster-management-backup <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

1.6.10. 기본 클러스터 종료

새 허브 클러스터에서 백업을 복원할 때 백업이 생성된 이전 허브 클러스터가 종료되었는지 확인합니다. 해당 클러스터가 실행 중인 경우 관리형 클러스터 조정에서 관리 클러스터를 더 이상 사용할 수 없다는 이전 hub 클러스터는 관리 클러스터를 다시 가져오려고 합니다.

1.6.11. 추가 리소스

1.7. 관리형 서비스 계정을 사용하여 클러스터 자동 연결

백업 컨트롤러는 Managed Service Account 구성 요소를 사용하여 가져온 클러스터를 새 허브 클러스터에 자동으로 연결합니다. Managed Service 계정은 각 관리 클러스터 네임 스페이스에서 가져온 각 클러스터에 대해 백업되는 토큰을 생성합니다. 토큰은 klusterlet-bootstrap-kubeconfig ClusterRole 바인딩을 사용하므로 자동 가져오기 작업에서 토큰을 사용할 수 있습니다. klusterlet-bootstrap-kubeconfig ClusterRolebootstrap-hub-kubeconfig 시크릿만 가져오거나 업데이트할 수 있습니다. Managed Service 계정 구성 요소에 대한 자세한 내용은 What is Managed Service Account? 를 참조하십시오.

새 hub 클러스터에서 활성화 데이터가 복원되면 복원 컨트롤러에서 복원 후 작업을 실행하고 Pending Import 상태에서 모든 관리 클러스터를 찾습니다. 관리 서비스 계정에서 생성한 유효한 토큰이 발견되면 컨트롤러는 토큰을 사용하여 자동 가져오기-비밀번호 를 생성합니다. 결과적으로 가져오기 구성 요소에서 관리형 클러스터를 다시 연결하려고 합니다. 클러스터에 액세스할 수 있으면 작업이 성공적으로 수행됩니다.

1.7.1. 자동 가져오기 활성화

Managed Service Account 구성 요소를 사용하는 자동 가져오기 기능은 기본적으로 비활성화되어 있습니다. 자동 가져오기 기능을 활성화하려면 다음 단계를 완료합니다.

  1. MultiClusterEngine 리소스에서 managedserviceaccount-preview enabled 매개변수를 true 로 설정하여 Managed Service 계정 구성 요소를 활성화합니다. 다음 예제를 참조하십시오.

    apiVersion: multicluster.openshift.io/v1
    kind: MultiClusterEngine
    metadata:
      name: multiclusterhub
    spec:
      overrides:
        components:
          - enabled: true
            name: managedserviceaccount-preview
  2. useManagedServiceAccount 매개변수를 true 로 설정하여 BackupSchedule.cluster.open-cluster-management.io 리소스의 자동 가져오기 기능을 활성화합니다. 다음 예제를 참조하십시오.

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: BackupSchedule
    metadata:
      name: schedule-acm-msa
      namespace: open-cluster-management-backup
    spec:
      veleroSchedule:
      veleroTtl: 120h
      useManagedServiceAccount: true

    선택 사항: 기본 토큰 유효 기간은 veleroTtl 의 값을 두 배로 설정하여 토큰이 전체 라이프사이클 동안 토큰을 저장하는 모든 백업에 대해 유효할 가능성을 높입니다. 이 값을 변경하여 managedServiceAccountTTL 의 값을 설정하여 토큰이 유효한 기간을 제어할 수 있습니다. 이 값을 변경하면 백업 수명 동안 만료되는 토큰을 사용하여 백업을 생성할 수 있습니다. 2시간 동안 사용하는 다음 예제를 참조하십시오.

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: BackupSchedule
    metadata:
      name: schedule-acm-msa
      namespace: open-cluster-management-backup
    spec:
      veleroSchedule:
      veleroTtl: 120h
      useManagedServiceAccount: true
      managedServiceAccountTTL: 2h

자동 가져오기 기능을 활성화하면 백업 구성 요소는 다음을 생성하여 가져온 관리 클러스터 처리를 시작합니다.

  • managed-serviceaccount 라는 ManagedServiceAddon.
  • A ManagedServiceAccount named auto-import-account.
  • 관리 클러스터에서 ManagedServiceAccount 토큰에 대한 klusterlet-bootstrap-kubeconfig RoleBinding 을 설정하는 각 ManagedServiceAccountManifestWork 입니다.

토큰은 Managed Service 계정을 생성할 때 관리 클러스터에 액세스할 수 있는 경우에만 생성되며, 그렇지 않으면 나중에 관리 클러스터를 사용할 수 있게 되면 생성됩니다.

1.7.2. 자동 가져오기 제한

다음 상황에서는 새 허브 클러스터로 이동할 때 관리 클러스터가 자동으로 가져오지 않도록 할 수 있습니다.

  • ManagedServiceAccount 토큰 없이 hub 백업을 실행할 때 예를 들어 관리 클러스터에 액세스할 수 없는 동안 ManagedServiceAccount 리소스를 생성할 때 백업에 관리 클러스터를 자동으로 가져오는 토큰이 포함되지 않습니다.
  • 자동 가져오기 보안 토큰이 유효하고 백업되는 경우 자동 가져오기 작업이 실패하지만 백업에서 사용할 수 있는 토큰이 이미 만료되면 복원 작업이 실행됩니다. restore.cluster.open-cluster-management.io 리소스는 각 관리 클러스터에 대해 유효하지 않은 토큰 문제를 보고합니다.
  • 복원 시 생성된 auto-import-secretManagedServiceAccount 토큰을 사용하여 관리 클러스터에 연결하므로 관리 클러스터는 kube apiserver 정보도 제공해야 합니다. apiserverManagedCluster 리소스에 설정해야 합니다. 다음 예제를 참조하십시오.

    apiVersion: cluster.open-cluster-management.io/v1
    kind: ManagedCluster
    metadata:
      name: managed-cluster-name
    spec:
      hubAcceptsClient: true
      leaseDurationSeconds: 60
      managedClusterClientConfigs:
          url: <apiserver>

    hub 클러스터에서 클러스터를 가져오면 apiserver 는 OpenShift Container Platform 클러스터에서만 자동으로 설정됩니다. EKS 클러스터와 같은 다른 유형의 관리형 클러스터에서 apiserver 를 수동으로 설정해야 합니다. 그렇지 않으면 자동 가져오기 기능이 클러스터를 무시합니다. 결과적으로 클러스터는 복원 허브 클러스터로 이동할 때 Pending Import 상태로 유지됩니다.

  • 백업 라벨이 ManagedServiceAccount 시크릿에 설정되기 전에 백업 일정이 실행되는 경우 ManagedServiceAccount 시크릿이 백업에 포함되지 않을 수 있습니다. ManagedServiceAccount 시크릿에는 생성 시 open-cluster-management.io/backup 라벨이 설정되어 있지 않습니다. 따라서 백업 컨트롤러는 관리되는 클러스터의 네임스페이스에서 ManagedServiceAccount 시크릿을 정기적으로 검색하고 찾을 수 없는 경우 백업 레이블을 추가합니다.

1.7.3. 자동 가져오기 비활성화

BackupSchedule 리소스에서 useManagedServiceAccount 매개변수를 false 로 설정하여 자동 가져오기 클러스터 기능을 비활성화할 수 있습니다. 다음 예제를 참조하십시오.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
  name: schedule-acm-msa
  namespace: open-cluster-management-backup
spec:
  veleroSchedule:
  veleroTtl: 120h
  useManagedServiceAccount: false

기본값은 false입니다. 값을 false 로 설정한 후 backup Operator는 ManagedServiceAddon,ManagedServiceAccountManifestWork 를 포함하여 생성된 모든 리소스를 제거합니다. 리소스를 제거하면 hub 클러스터 및 관리 클러스터에서 자동 가져오기 토큰이 삭제됩니다.

1.7.4. 추가 리소스

1.8. 백업 또는 복원 구성 검증

클러스터 백업 및 복원 Operator Helm 차트(cluster-backup-chart)는 hub 클러스터에 backup-restore-enabled 정책을 설치합니다. 이 정책은 백업 및 복원 구성 요소의 문제에 대해 알려주는 데 사용됩니다. backup-restore-enabled 정책에는 다음 제약 조건을 확인하는 템플릿 세트가 포함됩니다.

  • Pod 검증

    다음 템플릿은 백업 구성 요소 및 종속 항목에 대한 Pod 상태를 확인합니다.

    • ACM-backup-pod-running 템플릿은 백업 및 복원 Operator Pod가 실행 중인지 확인합니다.
    • OADP-pod-running 템플릿은 OADP Operator Pod가 실행 중인지 확인합니다.
    • Velero-pod-running 템플릿은 Velero pod가 실행 중인지 확인합니다.
  • Data Protection 애플리케이션 유효성 검사

    • data-protection-application-available 템플릿은 DataProtectioApplicatio.oadp.openshift.io 리소스가 생성되었는지 확인합니다. 이 OADP 리소스는 Velero 구성을 설정합니다.
  • 백업 스토리지 검증

    • backup-storage-location-available 템플릿은 BackupStorageLocation.velero.io 리소스가 생성되고 상태 값이 Available 인지 확인합니다. 즉, 백업 스토리지에 대한 연결이 유효합니다.
  • BackupSchedule 충돌 검증

    • ACM -backup-clusters-collision-report 템플릿은 상태가 BackupCollision 이 아닌지 확인합니다. BackupSchedule.cluster.open-cluster-management.io 가 현재 허브 클러스터에 있는 경우. 이렇게 하면 스토리지 위치에 백업 데이터를 작성할 때 현재 hub 클러스터가 다른 허브 클러스터와 충돌하지 않는지 확인합니다.

      BackupCollision 상태에 대한 정의의 경우 Backup Collisions 섹션을 참조하십시오.

  • BackupSchedule 및 복원 상태 검증

    • ACM -backup-phase-validation 템플릿은 현재 클러스터에 BackupSchedule.cluster.open-cluster-management.io 가 있는 경우 상태가 Failed, Empty 상태가 아닌지 확인합니다. 이렇게 하면 이 클러스터가 기본 hub 클러스터이고 백업을 생성하는 경우 BackupSchedule.cluster.open-cluster-management.io 상태가 정상입니다.
    • 동일한 템플릿에서 현재 클러스터에 Restore.cluster.open-cluster-management.io 가 있는 경우 상태가 Failed 또는 Empty 상태가 아닌지 확인합니다. 이렇게 하면 이 클러스터가 보조 허브 클러스터이고 백업을 복원 중인 경우 Restore.cluster.open-cluster-management.io 상태가 정상입니다.
  • 백업 보유 상태 검증

    • ACM -managed-clusters-schedule-backups-available 템플릿은 BackupStorageLocation.velero.io 에서 지정한 위치에서 Backup.velero.io 리소스를 사용할 수 있는지, 백업이 BackupSchedule.cluster.open-cluster-management.io 리소스에서 생성하는 경우 백업을 생성합니다. 이는 backup 및 restore 연산자를 사용하여 백업을 한 번 이상 실행했는지 확인합니다.
  • 완료를 위한 백업

    • acm-backup-in-progress-report 템플릿은 Backup.velero.io 리소스가 InProgress 상태에 고착되어 있는지 확인합니다. 이 검증은 리소스가 많은 경우 백업이 실행될 때 velero Pod가 재시작되고 백업이 완료되지 않고 계속 진행 중이므로 백업이 추가됩니다. 일반적인 백업 중에 백업 리소스는 실행 중 어느 시점에서 진행 중이지만 중단되지 않고 완료로 실행됩니다. acm-backup-in-progress-report 템플릿은 일정이 실행되는 동안 경고가 표시되고 백업이 진행 중인 것을 확인하는 것이 정상입니다.
  • cron 작업으로 적극적으로 실행되는 백업

    • BackupSchedule.cluster.open-cluster-management.io 는 스토리지 위치에 적극적으로 실행되고 새 백업을 저장합니다. 이 검증은 backup-schedule-cron-enabled 정책 템플릿에서 수행합니다. 템플릿은 스토리지 위치에 velero.io/schedule-name: acm-validation-policy-schedule 라벨이 있는 Backup.velero.io 가 있는지 확인합니다.

      acm-validation-policy-schedule 백업은 백업 cron 일정에 설정된 시간이 설정된 후 만료되도록 설정됩니다. 백업을 생성하기 위해 cron 작업이 실행되지 않으면 만료되고 새 작업이 생성되지 않기 때문에 이전 acm-validation-policy-schedule 백업이 삭제됩니다. 결과적으로 언제든지 acm-validation-policy-schedule 백업이 없는 경우 백업을 생성하는 활성 cron 작업이 없음을 의미합니다.

      이 정책은 hub 클러스터가 활성 상태이고 백업을 생성 또는 복원할 때 모든 백업 문제를 hub 클러스터 관리자에게 알리는 데 도움이 됩니다.

1.8.1. 서버 측 암호화를 사용하여 데이터 보호

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

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

serverSideEncryptionkmsKeyId 매개변수를 사용하여 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 지원 스토리지 공급자를 참조하여 다른 스토리지 공급자의 구성 가능한 모든 매개변수에 대해 알아보십시오.

1.8.2. 추가 리소스

1.9. 백업 및 복원 고급 구성

다음 주제를 확인하여 백업 및 복원을 추가로 구성할 수 있습니다.

1.9.1. 리소스 요청 및 제한 사용자 정의

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 리소스 요청 및 제한 사용자 지정을 참조하십시오.

법적 공지

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