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}

이 오류는 리소스 생성 및 수정에 관한 특정 규칙을 적용하여 리소스 생성 요청을 차단하는 ValidatingAdmissionWebhook 또는 MutatingAdmissionWebhook가 있는 타겟 GKE 클러스터에 설정된 구성으로 인해 발생합니다. 예를 들어 관련되지만 충돌하는 리소스가 클러스터에 이미 있으므로 웹훅이 리소스 생성을 방지합니다. 예를 들어 웹훅은 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 리소스가 누락되어 복원 작업을 완료할 수 없음

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 컨트롤러: 다른 리소스 또는 정책과 충돌하거나 OwnerReference 체인이 가비지 컬렉션으로 이어지거나 owner 리소스가 삭제될 때 종속 리소스를 삭제하는 GKE의 자동 정리 프로세스로 인해 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 --sort-by='.lastTimestamp'

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

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

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

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

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

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

다음 단계