백업 및 복원

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

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

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

리소스에 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 백업으로 지원되는 리소스는 다음과 같습니다.

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

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

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

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

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

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

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

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

참고:

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

처음으로 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: true
          name: cluster-backup
    separateCertificateManagement: false

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

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

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

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

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

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

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

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

새 허브 클러스터에서 복원 작업을 실행하기 전에 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 클러스터와 동일한 방식으로 구성됩니다.

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

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

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

참고:

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
  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

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

허브 클러스터가 클러스터를 관리하려면 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 샘플을 사용합니다. 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 클러스터에서 백업 파일에 포함된 백업 리소스가 생성되었는지 확인합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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,ManagedServiceAccount 및 ManifestWork 를 포함하여 생성된 모든 리소스를 제거합니다. 리소스를 제거하면 hub 클러스터 및 관리 클러스터에서 자동 가져오기 토큰이 삭제됩니다.

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

모범 사례: 사용 가능한 백업 스토리지 서버 측 암호화를 사용하여 대상의 데이터를 암호화합니다. 백업에는 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 지원 스토리지 공급자를 참조하여 다른 스토리지 공급자의 구성 가능한 모든 매개변수에 대해 알아보십시오.

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