Backup for GKE의 권한 오류 문제 해결

이 문서에서는 Backup for GKE를 사용하여 복원 작업을 실행할 때 발생할 수 있는 오류와 해당 코드를 설명합니다. 각 섹션에는 복원 오류를 해결하기 위한 작업을 실행할 때 고려해야 할 사항과 복원 작업 오류를 해결하는 방법에 관한 안내가 포함되어 있습니다.

오류 200010301: 사용할 수 없는 허용 웹훅 서비스로 인해 복원 작업을 완료할 수 없음

승인 웹훅 서비스(HTTP 콜백이라고도 함)를 사용할 수 없어 복원 작업을 완료하려는 시도가 실패하면 200010301 오류가 발생하며, 그 결과 다음과 같은 오류 메시지가 표시됩니다. 오류 메시지는 GKE API 서버가 리소스를 복원하려고 시도하는 중에 승인 웹훅에 연결하려고 했지만 웹훅을 지원하는 서비스를 사용할 수 없거나 찾을 수 없음을 나타냅니다.

  resource [/example-group/ClusterSecretStore/example-store] restore failed:

  Internal error occurred: failed calling webhook "example-webhook.io":
  failed to call webhook: Post "https://example-webhook.example-namespace.svc:443/validate-example": service "example-webhook" not found.

이 오류는 ValidatingAdmissionWebhook 또는 MutatingAdmissionWebhook GKE 리소스가 타겟 클러스터에서 활성 상태이지만 GKE API 서버가 웹훅에 구성된 엔드포인트에 도달할 수 없는 경우에 발생합니다. 허용 웹훅은 GKE API 서버에 대한 요청을 가로채며, 구성은 GKE API 서버가 요청을 쿼리하는 방법을 지정합니다.

웹훅의 clientConfig는 승인 요청을 처리하는 백엔드를 지정하며, 이는 내부 클러스터 서비스 또는 외부 URL일 수 있습니다. 이 두 옵션 중에서 선택하는 것은 웹훅의 구체적인 운영 및 아키텍처 요구사항에 따라 달라집니다. 옵션 유형에 따라 다음과 같은 이유로 복원 작업이 실패했을 수 있습니다.

  • 클러스터 내 서비스: GKE API 서버가 웹훅을 호출하려고 할 때 GKE 서비스와 지원 포드가 복원되지 않았거나 준비되지 않았습니다. 이는 클러스터 범위 웹훅 구성이 네임스페이스 서비스가 완전히 ready 상태가 되기 전에 적용되는 복원 작업 중에 발생합니다.

  • 외부 URL: GKE 클러스터와 외부 엔드포인트 간의 네트워크 연결 문제, DNS 변환 문제 또는 방화벽 규칙으로 인해 외부 엔드포인트를 일시적으로 사용할 수 없습니다.

이 오류를 해결하려면 다음 안내를 따르세요.

  1. 오류 메시지에 언급된 실패한 웹훅을 식별합니다. 예를 들면 failed calling webhook "..."입니다.

  2. kubectl get validatingwebhookconfigurations 명령어를 실행하여 웹훅을 검사합니다.

    kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml

    WEBHOOK_NAME을 오류 메시지에 표시된 웹훅 이름으로 바꿉니다.

    kubectl get mutatingwebhookconfigurations 명령어를 실행하여 웹훅을 검사할 수도 있습니다.

    kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml

    WEBHOOK_NAME을 오류 메시지에 표시된 웹훅의 이름으로 바꿉니다.

  3. 구성 유형에 따라 다음 문제 해결 단계를 수행하세요.

    서비스 기반 clientConfig

    GroupKindDependency 항목이 있는 RestoreOrder을 포함하도록 RestorePlan 리소스를 수정하여 맞춤 복원 순서를 정의합니다. 이를 통해 ValidatingWebhookConfiguration 또는 MutatingWebhookConfiguration 전에 Deployment, StatefulSet, Service와 같은 웹훅을 지원하는 구성요소를 복원하고 준비할 수 있습니다.

    맞춤 복원 순서를 정의하는 방법은 복원 중에 리소스 복원 순서 지정을 참고하세요.

    이 접근 방식은 서비스의 포드가 Service 객체가 생성된 후에도 완전히 ready 상태로 전환되지 않기 때문에 실패할 수 있습니다. 실패의 또 다른 이유는 다른 애플리케이션에서 예기치 않게 웹훅 구성을 만들었기 때문일 수 있습니다. 또는 다음 단계에 따라 2단계 복원 작업을 실행할 수 있습니다.

    1. 웹훅이 작동하는 데 필요한 특정 리소스(예: Namespaces, Deployments, StatefulSets, Services)를 포함하는 세부적인 복원 필터로 복원 작업을 구성하여 백업을 사용하여 Restore 리소스를 만듭니다.

      세분화된 복원 필터로 복원을 구성하는 방법에 대한 자세한 내용은 세분화된 복원 사용 설정을 참고하세요.

    2. 백업 작업을 위한 다른 Restore 리소스를 만들고 선택한 나머지 리소스를 구성합니다.

    URL 기반 clientConfig

    1. 외부 HTTPS 엔드포인트를 확인하고 활성 상태이며 연결 가능하고 올바르게 작동하는지 확인합니다.

    2. GKE 클러스터의 노드와 컨트롤 플레인에서 외부 URL로의 네트워크 연결이 있는지 확인합니다. 가상 프라이빗 클라우드, 온프레미스 또는 웹훅, 네트워크 정책, DNS 변환을 호스팅하는 클라우드 제공업체를 사용하는 경우 방화벽 규칙도 확인해야 할 수 있습니다.

  4. 복원 작업을 다시 시도합니다. 작업이 계속 실패하면 Cloud Customer Care에 문의하여 추가 지원을 받으세요.

오류 200010302: 리소스 생성 요청이 거부되어 복원 작업을 완료할 수 없음

허용 웹훅이 리소스 생성 요청을 거부하여 복원 작업을 완료하려는 시도가 실패하면 오류 200010302가 발생합니다. 이로 인해 활성 허용 웹훅이 요청을 가로채 맞춤 정책에 따라 거부했기 때문에 백업의 리소스를 타겟 클러스터에서 만들 수 없다는 오류 메시지가 표시됩니다.

  [KubeError]; e.g. resource

  [/example-namespace/example-api/ExampleResource/example-name]

  restore failed: admission webhook "example-webhook.example.com" denied the request: {reason for denial}

이 오류는 타겟 GKE 클러스터에 설정된 구성으로 인해 발생합니다. 이 구성에는 리소스 생성 및 수정에 관한 특정 규칙을 적용하여 리소스 생성 요청을 차단하는 ValidatingAdmissionWebhook 또는 MutatingAdmissionWebhook가 있습니다. 예를 들어 관련 리소스가 이미 클러스터에 있지만 충돌하기 때문에 웹훅이 리소스 생성을 방지합니다. 예를 들어 웹훅은 HorizontalPodAutoscaler GKE API 리소스에서 이미 관리하는 경우 배포 생성을 거부할 수 있습니다.

이 오류를 해결하려면 다음 안내를 따르세요.

  1. 복원 작업이 실패할 때 발생하는 오류 메시지를 사용하여 요청을 거부하는 웹훅을 식별합니다. 예를 들어 webhook WEBHOOK_NAME denied the request 오류 메시지에는 다음 정보가 포함됩니다.

    • 웹훅 이름: 요청을 거부하는 웹훅의 이름입니다.

    • 거부 이유: 요청이 거부된 구체적인 이유입니다.

  2. kubectl get validatingwebhookconfigurations 명령어를 실행하여 웹훅을 검사합니다.

    kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml

    WEBHOOK_NAME을 오류 메시지에서 확인한 웹훅의 이름으로 바꿉니다.

    kubectl get mutatingwebhookconfigurations 명령어를 실행하여 웹훅을 검사할 수도 있습니다.

    kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml

    WEBHOOK_NAME을 오류 메시지에서 확인한 웹훅의 이름으로 바꿉니다.

  3. 타겟 클러스터의 근본적인 문제를 해결합니다. 올바른 조치는 구체적인 오류에 따라 다릅니다. 예를 들어 HorizontalPodAutoscaler 충돌이 있는 경우 백업된 워크로드와 연결된 리소스가 생성되도록 복원을 실행하기 전에 대상 클러스터에서 기존 HorizontalPodAutoscaler을 삭제해야 합니다.

  4. 복원 작업을 다시 시도합니다. 복원 작업이 계속 실패하면 추가 지원을 위해 Cloud Customer Care에 문의하세요.

오류 200060202: 워크로드 유효성 검사 중에 GKE 리소스가 누락되어 복원 작업을 완료할 수 없음

이 오류는 복원 작업의 워크로드 검증 단계에서 발생합니다. Backup for GKE에서 검증할 것으로 예상하는 GKE 리소스를 대상 클러스터에서 찾을 수 없어 다음 오류 메시지가 표시됩니다.200060202

  Workload Validation Error: [KIND] "[NAME]" not found

예를 들면 Example: Workload Validation Error: pods "jenkins-0" not found입니다.

이 오류는 복원 작업 프로세스의 일부로 Backup for GKE가 GKE 리소스를 성공적으로 생성하거나 업데이트했지만 검증 단계가 시작될 때 GKE 리소스의 워크로드 검증이 완료되기 전에 리소스가 복원 프로세스에 의해 처음 생성되거나 업데이트된 후 삭제되었기 때문에 하나 이상의 GKE 리소스가 더 이상 대상 클러스터에 없는 경우에 발생합니다. 이와 같은 오류는 다음과 같은 이유로 발생할 수 있습니다.

  • 수동 삭제: 사용자 또는 관리자가 kubectl 또는 기타 도구를 사용하여 리소스를 수동으로 삭제했습니다. Google Cloud

  • 외부 자동화: 구성 동기화, ArgoCD, Flux, 맞춤 스크립트 또는 기타 클러스터 관리 도구와 같은 GitOps 컨트롤러가 저장소의 원하는 상태와 일치하도록 리소스를 되돌리거나 삭제했습니다.

  • GKE 컨트롤러: GKE 컨트롤러가 다른 리소스 또는 정책과 충돌하여 리소스를 삭제했거나 OwnerReference 체인으로 인해 가비지 컬렉션이 발생했거나 owner 리소스가 삭제될 때 종속 리소스를 삭제하는 GKE의 자동 정리 프로세스가 발생했습니다.

이 오류를 해결하려면 다음 안내를 따르세요.

  1. 복원 작업이 완료되지 않을 때 표시되는 오류 메시지를 사용하여 누락된 리소스를 확인합니다.

  2. 다음 방법 중 하나를 사용하여 리소스가 속한 네임스페이스를 찾습니다.

    • GKE 감사 로그: 복원 작업을 시도할 때 생성된 GKE 감사 로그를 검사합니다. 리소스 Kind 및 Name에 대한 삭제 작업의 로그를 필터링할 수 있습니다. 감사 로그 항목에는 원래 네임스페이스가 포함됩니다.

    • 백업 세부정보: 복원 작업의 범위와 백업 콘텐츠를 검토합니다. 백업 색인에는 리소스의 원래 네임스페이스가 표시됩니다. RestorePlan에 선택한 네임스페이스에서 리소스를 복원하는 규칙을 지정하는 TransformationRule이 포함되어 있는지 확인할 수도 있습니다.

    • 네임스페이스 전체 검색: kubectl get 명령어를 실행하여 모든 네임스페이스에서 리소스를 검색합니다.

      kubectl get KIND --all-namespaces | grep NAME

      KIND 및 NAME을 오류 메시지의 값으로 바꿉니다. 리소스가 아직 있는 경우 이 명령어는 네임스페이스를 표시합니다.

  3. kubectl get 명령어를 실행하여 삭제를 확인합니다.

    kubectl get KIND NAME -n [NAMESPACE]

    KIND 및 NAME을 오류 메시지의 값으로 바꿉니다. not found 오류 메시지가 표시됩니다.

  4. 다음 방법 중 하나를 사용하여 삭제 원인을 조사합니다.

    • GKE 감사 로그: 삭제 요청을 발행한 항목을 식별합니다. 예를 들어 사용자, 서비스 계정 또는 컨트롤러입니다.

    • 구성된 자동화 검토: GitOps 또는 기타 자동화 도구를 사용하는 경우 로그와 상태를 확인하여 복원된 리소스에 간섭이 있었는지 확인합니다.

    • 관련 이벤트 검사: kubectl get events 명령어를 실행하여 확인된 네임스페이스에서 GKE 이벤트를 확인합니다.

      kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'

      NAMESPACE_NAME를 네임스페이스 이름으로 바꿉니다.

  5. 이전 단계의 결과를 기반으로 리소스 삭제의 원인을 해결합니다. 예를 들어 충돌하는 자동화를 일시중지하거나, 잘못된 구성을 수정하거나, 사용자 권한을 조정할 수 있습니다.

  6. 다음 방법 중 하나를 사용하여 누락된 리소스를 복구합니다.

    • 매니페스트 파일 다시 적용: 누락된 리소스의 매니페스트가 있는 경우 올바른 네임스페이스에 다시 적용할 수 있습니다.

    • 세분화된 복원 실행: 세분화된 복원 작업을 실행하여 동일한 백업에서 누락된 리소스만 선택적으로 복원합니다. 이렇게 하면 올바른 네임스페이스를 지정할 수 있습니다. 세분화된 복원 작업을 실행하는 방법에 관한 자세한 내용은 세분화된 복원 사용 설정을 참고하세요.

  7. 복원 작업을 다시 시도합니다. 복원 작업이 계속 실패하면 추가 지원을 위해 Cloud Customer Care에 문의하세요.

오류 200060201: 워크로드 유효성 검사 시간 초과로 인해 복원 작업을 완료할 수 없음

클러스터에서 리소스가 생성된 후 예상 시간 제한 내에 복원된 하나 이상의 워크로드가 복원 작업 중에 완전히 ready되지 않아 200060201 오류가 발생하며, 그 결과 다음 오류 메시지가 표시됩니다.

Workload Validation Error: Timedout waiting for workloads to be ready - [namespace/workload_name, ...]

이 오류는 Backup for GKE가 GKE 리소스 구성을 복원한 후 중요한 워크로드가 올바르게 작동하는지 확인하기 위해 유효성 검사 단계를 실행하기 때문에 발생합니다. Backup for GKE는 특정 워크로드가 ready 상태에 도달할 때까지 기다리지만 할당된 제한 시간 내에 하나 이상의 워크로드가 다음 준비 기준을 충족하지 않았습니다.

  • Pods의 경우: status.Phase이(가) Running입니다.

  • Deployments의 경우: status.ReadyReplicas이 spec.Replicas과 같음

  • StatefulSets의 경우: status.ReadyReplicas이 spec.Replicas과 같음

  • DaemonSets의 경우: status.NumberReady이 status.DesiredNumberScheduled과 같음

이 오류를 해결하려면 다음 안내를 따르세요.

  1. 워크로드 및 ready 상태로 전환되지 않은 네임스페이스를 나열하는 오류 메시지에서 ready 상태가 아닌 워크로드를 확인합니다.

  2. kubectl describe 명령어를 실행하여 워크로드 상태를 검사하고 실패한 워크로드의 세부정보와 이벤트를 가져옵니다.

    kubectl describe WORKLOAD_TYPE WORKLOAD_NAME -n NAMESPACE_NAME
kubectl get pods -n NAMESPACE_NAME -l SELECTOR_FOR_WORKLOAD

    다음을 바꿉니다.

    • WORKLOAD_TYPE: 워크로드 유형(예: Deployment, StatefulSet, DaemonSet)

    • WORKLOAD_NAME: 특정 워크로드 인스턴스의 이름입니다.

    • NAMESPACE_NAME: 워크로드가 있는 네임스페이스

    • SELECTOR_FOR_WORKLOAD: 워크로드와 연결된 Pods를 찾는 라벨 선택기입니다. 예를 들면 app=my-app입니다.

    Deployments 또는 StatefulSets 워크로드 유형 내의 포드의 경우 kubectl describe pod 명령어를 실행하여 개별 포드의 상태를 확인합니다.

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    다음을 바꿉니다.

    • POD_NAME: 특정 포드의 이름입니다.

    • NAMESPACE_NAME: 포드가 있는 네임스페이스입니다.

  3. Events 섹션에서 describe 출력의 이벤트와 로그를 분석하고 다음 정보를 찾습니다.

    • ImagePullBackOff / ErrImagePull: 컨테이너 이미지를 가져오는 데 문제가 있음을 나타냅니다.

    • CrashLoopBackOff: 컨테이너가 시작되고 비정상 종료됨을 나타냅니다.

  4. Containers 섹션에서 describe 출력의 컨테이너 로그를 분석하여 kubectl logs 명령어를 실행하여 컨테이너 이름을 찾습니다.

    kubectl logs POD_NAME -n NAMESPACE_NAME -c CONTAINER_NAME

    다음을 바꿉니다.

    • POD_NAME: 특정 포드의 이름입니다.

    • NAMESPACE_NAME: 포드가 있는 네임스페이스입니다.

    • CONTAINER_NAME: 포드 내 컨테이너의 이름입니다.

    describe 출력에 따르면 다음과 같은 이유로 포드가 리소스 출력에 표시되지 않을 수 있습니다.

    • 준비 상태 프로브 실패: 컨테이너의 준비 상태 프로브가 성공하지 않습니다.

    • 리소스 문제: 클러스터에 CPU, 메모리 또는 기타 리소스가 부족하거나 할당량 한도에 도달했습니다.

    • init 컨테이너 문제: init 컨테이너의 실패로 인해 기본 컨테이너가 시작되지 않습니다.

    • 구성 오류: ConfigMaps, Secrets 또는 환경 변수의 오류입니다.

    • 네트워크 문제: Pods가 필수 서비스와 통신할 수 없습니다.

  5. GKE 클러스터 리소스를 확인하여 GKE 클러스터에 복원된 워크로드를 실행할 충분한 노드 용량, CPU, 메모리가 있는지 확인합니다. Autopilot 클러스터에서는 노드 자동 프로비저닝에 시간이 더 걸릴 수 있으므로 노드 확장 제한사항이나 오류가 있는지 확인하는 것이 좋습니다. 조사 결과를 바탕으로 근본적인 문제를 해결하고 워크로드가 ready 상태로 전환되지 못하도록 하는 문제를 해결합니다. 이 접근 방식에는 매니페스트 수정, 리소스 요청 또는 한도 조정, 네트워크 정책 수정, 종속 항목 충족 등이 포함될 수 있습니다.

  6. 기본 문제가 해결된 후 워크로드가 ready 상태가 될 때까지 기다립니다. 복원 작업을 다시 실행할 필요가 없습니다.

문제가 계속되면 Cloud Customer Care에 문의하여 추가 지원을 받으세요.

오류 200060102: 볼륨 유효성 검사 오류로 인해 복원 작업을 완료할 수 없음

200060102 오류는 VolumeBackup에서 PersistentVolume로 데이터를 복원하는 프로세스를 관리하는 하나 이상의 VolumeRestore 리소스가 복원 작업의 볼륨 검증 단계에서 failed 또는 deleting 상태로 전환되었기 때문에 발생합니다. 볼륨 복원에 실패하면 복원 리소스의 stateReason 필드에 다음 오류 메시지가 표시됩니다.

Volume Validation Error: Some of the volume restores failed - [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_ID/restores/RESTORE_ID/volumeRestores/VOLUME_RESTORE_ID (PVC: NAMESPACE/PVC_NAME), ...]

오류 메시지에는 대상 PersistentVolumeClaim 이름과 네임스페이스를 포함하여 실패한 VolumeRestore의 전체 리소스 이름이 나열됩니다. 오류 메시지는 GKE용 백업이 VolumeBackups에서 PersistentVolumes를 프로비저닝하기 위해 VolumeRestore 리소스를 시작했을 때 영향을 받는 PersistentVolumeClaim의 데이터 복원 프로세스가 완료되지 않았으며 스냅샷에서 기본 영구 디스크 생성이 실패했음을 나타냅니다. VolumeRestore 실패는 다음과 같은 이유로 발생할 수 있습니다.

  • 할당량 부족: 프로젝트 또는 리전(예: SSD_TOTAL_GB)에 할당된 영구 디스크 할당량이 충분하지 않습니다.

  • 권한 문제: Backup for GKE에서 사용하는 서비스 계정에 디스크를 만들거나 스냅샷에 액세스하는 데 필요한 권한이 없습니다.

  • 네트워크 문제: 디스크 생성 프로세스를 중단하는 일시적이거나 지속적인 네트워크 문제가 있습니다.

  • 잘못된 스냅샷: 소스 VolumeBackup 또는 기본 영구 디스크 스냅샷이 손상되었거나 액세스할 수 없습니다.

  • 리소스 제약 조건: 다른 클러스터 리소스 제약 조건으로 인해 볼륨 프로비저닝이 방해됩니다.

  • 내부 오류: Persistent Disk 서비스 내에 내부 문제가 있습니다.

이 오류를 해결하려면 다음 안내를 따르세요.

  1. 오류 메시지에 나열된 실패한 PersistentVolumeClaims를 확인합니다. 오류 메시지에는 실패한 VolumeRestore 객체의 전체 리소스 이름이 나열됩니다.

  2. gcloud beta container backup-restore volume-restores describe 명령어를 실행하여 실패한 각 VolumeRestore 리소스의 세부정보를 가져옵니다.

    gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_ID \
--restore=RESTORE_ID

    다음을 바꿉니다.

    • VOLUME_RESTORE_ID: 실패한 VolumeRestore 리소스의 ID입니다.

    • PROJECT_ID: Google Cloud 프로젝트의 ID입니다.

    • LOCATION: 복원의 Google Cloud 위치입니다.

    • RESTORE_PLAN_ID: 복원 계획의 ID입니다.

    • RESTORE_ID: 복원 작업의 ID입니다.

  3. 출력에서 state 및 stateMessage 필드를 검사하여 실패에 관한 세부정보를 확인합니다.

  4. kubectl get pvc 명령어를 실행하여 타겟 PersistentVolumeClaim의 상태를 검사합니다.

    kubectl get pvc PVC_NAME -n NAMESPACE_NAME -o yaml

    다음을 바꿉니다.

    • PVC_NAME: PersistentVolumeClaim 리소스의 이름입니다.

    • NAMESPACE_NAME: PersistentVolumeClaim이 있는 네임스페이스입니다.

  5. 출력의 status.phase 섹션에 Pending 단계가 표시되는지 확인합니다. 이 단계는 PersistentVolumeClaim이 아직 PersistentVolume에 바인딩되지 않았음을 의미하며, 이는 VolumeRestore가 실패한 경우 예상되는 동작입니다.

  6. YAML 출력의 Events 섹션에서 프로비저닝 실패와 관련된 메시지(예: ProvisioningFailed)를 검사합니다.

    Cloud KMS error when using key projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY:  Permission 'cloudkms.cryptoKeyVersions.useToEncrypt' denied  on resource 'projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY' (or it may not exist).

    출력은 디스크 생성 중에 암호화 키에 액세스하는 동안 권한 문제가 있음을 나타냅니다. 키에 액세스할 수 있는 compute service agent 관련 권한을 제공하려면 Backup for GKE 문서의 CMEK 암호화 사용 설정에 설명된 안내를 따르세요.

  7. kubectl get events 명령어를 실행하여 PersistentVolumeClaim 네임스페이스의 GKE 이벤트를 검토합니다. 여기에는 PersistentVolume 컨트롤러 또는 CSI 드라이버의 자세한 오류 메시지가 제공됩니다.

    kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'

    NAMESPACE_NAME을 PersistentVolumeClaim의 네임스페이스로 바꿉니다.

  8. FailedProvisioning 또는 ExternalProvisioning와 같은 키워드가 포함된 PersistentVolumeClaim 이름과 관련된 이벤트를 식별합니다. 이벤트에는 pd.csi.storage.gke.io와 같은 스토리지 프로비저너의 오류도 포함될 수 있습니다.

  9. 실패 시점의 디스크 생성 작업과 관련된 오류가 있는지 Cloud Logging에서 Cloud 감사 로그 및 영구 디스크 로그를 확인하여 영구 디스크 로그를 검사합니다.

  10. 생성된 오류 메시지를 기반으로 다음과 같은 기본 문제를 해결합니다.

    • (QUOTA_EXCEEDED}: Quota SSD_TOTAL_GB exceeded와 같이 표시된 경우 영구 디스크 할당량을 늘립니다.

    • IAM 권한을 확인하고 수정합니다.

    • 네트워크 문제를 조사하고 해결합니다.

    • 스냅샷 또는 영구 디스크 서비스 관련 문제를 해결하려면 Cloud Customer Care에 문의하세요.

    • PersistentVolumeClaim이 Pending 상태로 유지됩니다.

    • 복원 작업 프로세스는 VolumeRestore를 자동으로 재시도하지 않습니다. 이 문제를 해결하려면 영향을 받는 PersistentVolumeClaim를 사용하는 Deployment 또는 StatefulSet 워크로드의 복원 작업을 트리거해야 합니다.

    • 세부 복원을 사용하여 실패한 PersistentVolumeClaim와 연결된 Deployment 또는 StatefulSet 워크로드를 선택적으로 복원합니다. 이 방법을 사용하면 기본 문제가 해결된 경우 표준 GKE 메커니즘이 PersistentVolumeClaim 생성 및 바인딩 프로세스를 다시 처리할 수 있습니다. 세분화된 복원에 관한 자세한 내용은 세분화된 복원 사용 설정을 참고하세요.

문제가 지속되거나 VolumeRestore 실패의 원인이 명확하지 않은 경우 Cloud Customer Care에 문의하여 추가 지원을 받으세요.

오류 200060101: 볼륨 유효성 검사 시간 초과로 인해 복원 작업을 완료할 수 없음

이 오류는 VolumeBackup에서 데이터를 복원하는 작업을 관리하는 하나 이상의 VolumeRestore 리소스가 할당된 제한 시간 내에 succeeded 상태에 도달하지 않아 Backup for GKE가 대기를 중지할 때 복원 작업의 볼륨 검증 단계에서 발생합니다.200060101 다른 VolumeRestore 리소스도 불완전할 수 있습니다.

Restore 리소스의 stateReason 필드에 있는 오류 메시지는 제한 시간이 확인되었을 때 아직 succeeded 상태가 아니었던 첫 번째 VolumeRestore 리소스를 보여줍니다. 여기에는 특정 VolumeRestore의 타겟 PersistentVolumeClaim 이름과 네임스페이스가 포함됩니다. 예를 들면 다음과 같습니다.

Volume Validation Error: Timed out waiting for volume restore [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_NAME/restores/RESTORE_NAME/volumeRestores/VOLUME_RESTORE_ID (PVC: PVC_NAMESPACE/PVC_NAME)]

Backup for GKE는 VolumeBackups에서 PersistentVolumes을 프로비저닝하기 위해 VolumeRestore 리소스를 시작합니다. 이 오류는 스냅샷에서 기본 영구 디스크를 생성하고 이후 PersistentVolumeClaim을 PersistentVolume에 바인딩하는 데 인용된 VolumeRestore의 계산된 제한 시간보다 오래 걸렸음을 나타냅니다. 동일한 복원 작업의 다른 VolumeRestores도 완료되지 않은 상태일 수 있습니다.

Backup for GKE 관점에서 타임아웃에 도달했더라도 언급된 VolumeRestore 리소스와 잠재적으로 VolumeRestore 리소스의 기본 디스크 생성 프로세스가 아직 진행 중이거나 실패했을 수 있습니다.

이 문제를 해결하려면 다음 안내를 따르세요.

  1. 오류 메시지에서 시간 초과된 PersistentVolumeClaim 이름과 네임스페이스를 확인합니다(예: (PVC: PVC_NAMESPACE/PVC_NAME)).

  2. 복원 작업과 연결된 모든 VolumeRestores를 나열하여 gcloud beta container backup-restore volume-restores list 명령어를 실행하여 현재 상태를 확인합니다.

    gcloud beta container backup-restore volume-restores list \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_NAME \
--restore=RESTORE_NAME

    다음을 바꿉니다.

    • PROJECT_ID: Google Cloud 프로젝트의 ID입니다.

    • LOCATION: 복원의 Google Cloud 위치입니다.

    • RESTORE_PLAN_NAME: 복원 계획의 이름입니다.

    • RESTORE_NAME: 복원 작업의 이름입니다.

  3. succeeded 상태가 아닌 VolumeRestores를 찾습니다.

  4. gcloud beta container backup-restore volume-restores describe 명령어를 실행하여 오류에 언급된 VolumeRestore와 succeeded 상태가 아닌 다른 VolumeRestores에 관한 세부정보를 가져옵니다.

    gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_NAME \
--restore=RESTORE_NAME

    다음을 바꿉니다.

    • VOLUME_RESTORE_ID: VolumeRestore 리소스의 ID입니다.

    • PROJECT_ID: Google Cloud 프로젝트의 ID입니다.

    • LOCATION: 복원의 Google Cloud 위치입니다.

    • RESTORE_PLAN_NAME: 복원 계획의 이름입니다.

    • RESTORE_NAME: 복원 작업의 이름입니다.

  5. state 및 stateMessage 필드를 확인합니다. state 필드의 값은 creating 또는 restoring일 가능성이 높습니다. stateMessage 필드는 더 많은 컨텍스트를 제공하고 타겟 PersistentVolumeClaim 세부정보를 포함할 수 있습니다.

  6. kubectl get pvc 명령어를 실행하여 식별된 타겟 PersistentVolumeClaims의 상태를 검사합니다.

    kubectl get pvc PVC_NAME -n PVC_NAMESPACE -o yaml

    다음을 바꿉니다.

    • PVC_NAME: PersistentVolumeClaim 이름입니다.

    • PVC_NAMESPACE: PersistentVolumeClaim의 네임스페이스입니다.

    PersistentVolumeClaim's status.phase의 값은 Pending일 가능성이 높습니다. Events 섹션에서 다음 오류를 확인합니다.

    • Waiting for first consumer to be created before binding: StorageClass에 volumeBindingMode: WaitForFirstConsumer이 있음을 나타냅니다.

      PersistentVolumeClaim을 사용하는 Pod가 생성되고 예약될 때까지 PersistentVolume의 프로비저닝이 지연됩니다. 이 문제는 볼륨 프로비저닝 자체가 아니라 Pod 일정과 관련이 있을 수 있습니다. 따라서 PersistentVolumeClaim을 사용하는 Pods가 예약되지 않거나 시작되지 않는 이유를 확인하는 것이 좋습니다.

    • FailedProvisioning 또는 스토리지 프로비저너의 오류: 예: pd.csi.storage.gke.io

  7. kubectl get events 명령어를 실행하여 관련 네임스페이스의 GKE 이벤트를 검토합니다.

    kubectl get events -n PVC_NAMESPACE --sort-by='.lastTimestamp'

    PVC_NAMESPACE을 PersistentVolumeClaim의 네임스페이스로 바꿉니다.

    프로비저닝 메시지 또는 오류와 같은 PersistentVolumeClaim 이름과 관련된 이벤트를 찾습니다.

  8. Cloud Logging에서 Cloud 감사 로그 및 영구 디스크 로그를 확인합니다.

  9. creating 및 restoring 상태의 모든 VolumeRestores 상태를 모니터링합니다.

    문제가 해결되면 VolumeRestores 상태가 succeeded 또는 failed 상태로 전환될 수 있습니다. VolumeRestores가 succeeded 상태에 도달하면 PersistentVolumeClaims가 Bound이 되고 워크로드가 작동해야 합니다. VolumeRestore가 failed 상태로 전환되면 볼륨 유효성 검사 오류를 해결하기 위한 문제 해결 단계를 실행해야 합니다. 자세한 내용은 오류 200060102: 볼륨 유효성 검사 오류로 인해 복원 작업을 완료할 수 없음을 참고하세요.

VolumeRestores이 과도한 시간 동안 creating 또는 restoring 상태로 유지되면 Cloud Customer Care에 문의하여 추가 지원을 받으세요.

다음 단계