백업 계획에서 허용 모드 사용 설정

이 페이지에서는 백업 계획에서 허용 모드를 사용 설정하는 방법을 설명합니다.

백업 실행 중에 Backup for GKE에서 복원 실패 가능성이 높은 조건이 감지되면 백업 자체가 실패합니다. 실패 원인은 백업의 state_reason 필드에 제공됩니다. Google Cloud 콘솔에서는 이 필드를 상태 이유라고 합니다.

허용 모드를 사용 설정하면 문제 설명은 상태 이유 필드에 계속 제공되지만 백업이 실패하지 않습니다. 문제점을 알고 있으며 복원 시 해결 방법을 사용할 준비가 되었으면 이 동작을 사용 설정할 수 있습니다.

다음은 백업의 상태 이유 필드에 표시될 수 있으며 허용 모드 사용 설정을 제안하는 오류 메시지의 예시입니다. If you cannot implement the recommended fix, you may create a new backup with Permissive Mode enabled.

gcloud

허용 모드를 사용 설정합니다.

gcloud beta container backup-restore backup-plans update BACKUP_PLAN \
    --project=PROJECT_ID \
    --location=LOCATION
    --permissive-mode

다음을 바꿉니다.

콘솔

다음 안내에 따라 Google Cloud 콘솔에서 허용 모드를 사용 설정합니다.

  1. Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.

    Google Kubernetes Engine으로 이동

  2. 탐색 메뉴에서 Backup for GKE를 클릭합니다.

  3. 백업 계획 탭을 클릭합니다.

  4. 클러스터를 확장하고 계획 이름을 클릭합니다.

  5. 세부정보 탭을 클릭하여 계획 세부정보를 수정합니다.

  6. 수정을 클릭하여 백업 모드가 있는 섹션을 수정합니다.

  7. 허용 모드 체크박스를 클릭하고 변경사항 저장을 클릭합니다.

Terraform

기존 google_gke_backup_backup_plan 리소스를 업데이트합니다.

resource "google_gke_backup_backup_plan" "NAME" {
   ...
   backup_config {
     permissive_mode = true
     ...
   }
}

다음을 바꿉니다.

  • NAME: 업데이트하려는 google_gke_backup_backup_plan의 이름

자세한 내용은 gke_backup_backup_plan을 참조하세요.

백업 실패 문제 해결

다음 표에서는 백업의 상태 이유 필드에 표시되는 다양한 백업 실패 메시지에 대한 설명과 권장 조치를 보여줍니다.

백업 실패 메시지 메시지 설명 및 실패 이유 권장 작업

CustomResourceDefinitions "..." have invalid schemas

설명: 클러스터의 커스텀 리소스 정의(CRD)가 원래 apiextensions.k8s.io/v1beta1로 적용되었으며 apiextensions.k8s.io/v1에 필요한 구조 스키마가 없습니다.

이유: Backup for GKE는 구조 스키마를 자동으로 정의할 수 없습니다. apiextensions.k8s.io/v1beta1을 사용할 수 없는 Kubernetes v1.22+ 클러스터에서 CRD를 복원하면 복원이 실패합니다. 이 오류는 CRD에서 정의한 커스텀 리소스를 복원할 때 발생합니다. 		다음 옵션을 사용하는 것이 좋습니다.
  • CRD를 관리하는 경우 Kubernetes 문서의 단계를 따라 CRD의 구조 스키마를 지정하세요.
  • GKE 관리 CRD인 경우 CRD에서 제공하는 기존 리소스가 없으면 kubectl delete crd를 호출할 수 있습니다. CRD에서 제공하는 기존 리소스가 있으면 복원 동작을 이해한 후 허용 모드를 사용 설정할 수 있습니다. 일반적인 CRD에 대한 권장사항은 문서를 참조하세요.
  • 타사 CRD인 경우 관련 문서를 참조하여 apiextensions.k8s.io/v1로 마이그레이션하세요.

허용 모드가 사용 설정되면 구조 스키마가 없는 CRD는 Kubernetes v1.22+ 클러스터에서 백업되지 않습니다. 이러한 백업을 성공적으로 복원하려면 CRD에서 제공하는 리소스를 복원에서 제외하거나 복원을 시작하기 전에 대상 클러스터에서 CRD를 만들어야 합니다.

PersistentVolumeClaims "..." are bound to PersistentVolumes of unsupported types "..." and cannot be backed up

설명: 소스 클러스터에서 PVC는 Persistent Disk 볼륨이 아닌 PV에 바인딩됩니다.

이유: Backup for GKE는 Persistent Disk 볼륨 데이터만 백업하도록 지원합니다. 새 볼륨 프로비저닝 및 백업에서 볼륨 데이터 복원 정책을 사용하여 복원된 비영구 디스크 PVC는 볼륨 데이터를 복원하지 않습니다. 하지만 데이터가 포함된 기존 볼륨 재사용 정책을 사용하면 PVC를 원래 볼륨 핸들에 다시 연결할 수 있습니다. 이는 NFS와 같은 외부 서버에서 지원하는 볼륨 유형에 유용합니다. 		소스 클러스터에서 비Persistent Disk 볼륨에 사용 가능한 복원 옵션을 이해하고 허용 모드를 사용 설정합니다. Filestore 볼륨 백업은 Backup for GKE로 Filestore 볼륨 처리를 참조하세요.

허용 모드가 사용 설정되면 PVC 구성이 백업되지만 볼륨 데이터는 백업되지 않습니다.

PersistentVolumeClaims "..." are not bound to PersistentVolumes and cannot be backed up

설명: 클러스터의 PVC가 PV에 바인딩되지 않습니다.

이유: Backup for GKE는 PVC를 백업할 수 있지만 백업할 볼륨 데이터가 없습니다. 이러한 상황은 잘못된 구성 또는 요청된 스토리지와 사용 가능한 스토리지 사이의 불일치를 나타낼 수 있습니다. 		결합되지 않은 PVC가 허용 가능한 상태인지 확인합니다. 그렇다면 허용 모드를 사용 설정합니다. 백업 동작에 미치는 영향에 유의하세요.

허용 모드가 사용 설정되면 PVC 구성이 백업되지만 백업할 볼륨 데이터가 없습니다.

Failed to query API resources ...

설명: 클러스터의 API 서비스가 잘못 구성되었습니다. 그러면 API 경로 요청에서 'API 리소스 쿼리 실패'가 반환됩니다. 기본 서비스가 없거나 아직 준비되지 않았을 수 있습니다.

이유: Backup for GKE는 사용할 수 없는 API로 제공되는 리소스를 백업할 수 없습니다. 		API 서비스의 spec.service에서 기본 서비스를 확인하여 준비되었는지 확인합니다.

허용 모드가 사용 설정되면 로드에 실패한 API 그룹의 리소스가 백업되지 않습니다.

Secret ... is an auto-generated token from ServiceAccount ... referenced in Pod specs

설명: Kubernetes v1.23 이하에서는 서비스 계정이 보안 비밀로 지원되는 토큰을 자동으로 생성합니다. 그러나 이후 버전에서는 Kubernetes가 이 자동 생성 토큰 기능을 삭제했습니다. 클러스터의 포드가 컨테이너의 파일 시스템에 보안 비밀 볼륨을 마운트했을 수 있습니다.

이유: Backup for GKE에서 자동 생성된 보안 비밀 및 이러한 보안 비밀 볼륨을 마운트하는 포드와 함께 서비스 계정을 복원하면 복원이 성공한 것으로 보입니다. 하지만 Kubernetes가 보안 비밀을 삭제하므로 포드가 컨테이너 생성에서 멈춰서 시작할 수 없습니다. 		포드에서 spec.serviceAccountName 필드를 정의합니다. 이 작업을 통해 토큰이 컨테이너의 /var/run/secrets/kubernetes.io/serviceaccount에 자동으로 마운트됩니다. 자세한 내용은 포드의 서비스 계정 구성 문서를 참조하세요.

허용 모드가 사용 설정되면 보안 비밀이 백업되지만 Kubernetes v1.24+ 클러스터의 포드에 마운트할 수 없습니다.

문제가 있는 일반적인 CRD 및 권장 조치

다음은 백업 문제가 있는 몇 가지 일반적인 CRD와 문제를 해결하기 위한 조치입니다.

  • capacityrequests.internal.autoscaling.k8s.io: 이 CRD는 v1.21 클러스터에서 일시적으로 사용되었습니다. kubectl delete crd capacityrequests.internal.autoscaling.k8s.io를 실행하여 CRD를 삭제합니다.
  • scalingpolicies.scalingpolicy.kope.io: 이 CRD는 fluentd 리소스를 제어하는 데 사용되었지만 GKE는 fluentbit를 사용하도록 마이그레이션되었습니다. kubectl delete crd scalingpolicies.scalingpolicy.kope.io를 실행하여 CRD를 삭제합니다.
  • memberships.hub.gke.io: 멤버십 리소스가 없는 경우 kubectl delete crd memberships.hub.gke.io를 실행하여 CRD를 삭제합니다. 구성원 리소스가 있으면 허용 모드를 사용 설정합니다.
  • applications.app.k8s.io: 복원 동작을 이해하고 허용 모드를 사용 설정합니다.