이 페이지에서는 Backup for GKE를 사용할 때 발생할 수 있는 스토리지 관련 오류, 작업을 실행할 때 고려해야 할 사항, 문제를 해결하는 단계를 설명합니다.
오류 100010105: Failed to backup PersistentVolumeClaim - Disk referenced by PersistentVolume does not exist
존재하지 않는 디스크를 참조하여 PersistentVolumeClaim 백업 시도가 실패하면 오류 100010105가 발생하며, 그 결과 Failed to backup PersistentVolumeClaim - Disk referenced by PersistentVolume does not exist라는 오류 메시지가 표시됩니다.
Google Kubernetes Engine에서 PersistentVolumes의 스토리지를 PersistentVolumeClaims 요청합니다. PersistentVolume은 스토리지 조각(일반적으로 기본 Compute Engine 영구 디스크)을 나타냅니다. PersistentVolumeClaim이 PersistentVolume에 바인딩되고, PersistentVolume의 구성이 Compute Engine 영구 디스크를 지정하는 경우 오류가 발생할 수 있습니다. 하지만 PersistentVolume 구성에 지정된 이름과 위치가 있는 실제 디스크를 Cloud de Confiance by S3NS 프로젝트에서 찾을 수 없습니다. 따라서 Backup for GKE는 존재하지 않는 디스크를 백업할 수 없으며 오류가 발생합니다.
이 오류를 해결하려면 다음 안내를 따르세요.
문제가 있는
PersistentVolumeClaim및PersistentVolume을 식별합니다. 문제가 있는PersistentVolumeClaim과 연결된PersistentVolume의 이름이 모두 실패한 Backup for GKE 작업의state reason필드에 나열됩니다.PersistentVolumeClaim이름, 네임스페이스,PersistentVolume의 이름을 모두 문서화하는 것이 좋습니다.PersistentVolume을 검사합니다.PersistentVolume을 설명하려면 다음 명령어의 상태 이유 필드에서 식별한PersistentVolume이름을 사용하세요.kubectl describe pv PERSISTENTVOLUME_NAMEPERSISTENTVOLUME_NAME을 PersistentVolume 이름으로 바꿉니다.출력에서
source섹션, 특히csi아래를 검토합니다. 이 섹션에서는PersistentVolume이 참조하려고 하는VolumeHandle을 설명합니다. 예를 들면 다음과 같습니다.Source: Type: GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine) PDName: my-non-existent-disk FSType: ext4 Partition: 0 ReadOnly: false In this example, the PD name is my-non-existent-disk. Source: Type: CSI (a Container Storage Interface (CSI) volume) Driver: pd.csi.storage.gke.io VolumeHandle: projects/PROJECT_ID/zones/ZONE/disks/DISK_NAME ...이 예에서
VolumeHandle에는 이름과 위치를 포함한 디스크의 전체 경로가 포함됩니다. 예를 들면projects/my-gcp-project/zones/us-central1-a/disks/my-disk-name입니다.PersistentVolume설명에서 가져온VolumeHandle을 사용하여 디스크 이름과 영역을 식별합니다.다음 방법 중 하나를 사용하여 디스크가 Cloud de Confiance by S3NS 프로젝트에 있는지 확인합니다.
영역 디스크
영역 디스크를 사용하는 경우 Google Cloud CLI를 사용하여
gcloud compute disks describe명령어를 실행합니다.gcloud compute disks describe DISK_NAME \ --zone=ZONE_NAME \ --project=PROJECT_ID다음을 바꿉니다.
DISK_NAME:PersistentVolume설명에서 가져온 디스크의 이름입니다.ZONE_NAME:PersistentVolume설명에서 가져온 디스크의 영역입니다.PROJECT_ID: Cloud de Confiance by S3NS 프로젝트 ID입니다.
리전 디스크
리전 디스크를 사용하는 경우 Google Cloud CLI를 사용하여
gcloud compute disks describe명령어를 실행합니다.gcloud compute disks describe DISK_NAME \ --region=REGION_NAME \ --project=PROJECT_ID다음을 바꿉니다.
DISK_NAME:PersistentVolume설명에서 가져온 디스크의 이름입니다.REGION_NAME:PersistentVolume설명에서 가져온 디스크의 리전입니다.PROJECT_ID: Cloud de Confiance by S3NS 프로젝트 ID입니다.
Resource not found또는The resource DISK_NAME was not found오류 메시지가 표시되면 디스크가 존재하지 않는 것입니다. 필요에 가장 적합한 시나리오에 따라 다음 방법 중 하나를 사용하여 문제를 해결하세요.디스크가 실수로 삭제되었거나 이름이 잘못 지정되었으며 데이터 또는
PersistentVolumeClaim을 유지하려는 경우, 또는PersistentVolume이 잘못된 디스크 이름으로 구성된 경우 다음 방법 중 하나를 사용하여 문제를 해결하세요.디스크 복원: 디스크 백업이 있는 경우
PersistentVolume에서 참조하는 이름 및 위치와 정확히 동일한 이름 및 위치로 복원합니다.새 디스크 만들기: 디스크 복원이 옵션이 아닌 경우
PersistentVolume구성에 있는 것과 동일한 이름과 위치로 새 디스크를 만듭니다.
PersistentVolumeClaim또는PersistentVolume, 해당 데이터 또는 애플리케이션이 더 이상 필요하지 않은 경우 불필요한 항목을 삭제하는 것이 좋습니다.PersistentVolumeClaim삭제:kubectl명령줄 도구를 통해kubectl delete pvc명령어를 실행하여PersistentVolumeClaim을 삭제합니다.
kubectl delete pvc PVC_NAME -n NAMESPACE다음을 바꿉니다.
PVC_NAME: 삭제할PersistentVolumeClaim의 이름입니다.NAMESPACE: 삭제할PersistentVolumeClaim의 네임스페이스입니다.
PersistentVolumeClaim을 삭제한 후에도PersistentVolume이 계속 표시됨:PersistentVolume의PersistentVolumeReclaimPolicy가Delete로 설정된 경우,PersistentVolumeClaim이 삭제되면PersistentVolume이 자동으로 삭제됩니다.persistentVolumeReclaimPolicy가Retain으로 설정된 경우,PersistentVolumeClaim이 삭제된 후PersistentVolume을 수동으로 삭제해야 합니다.PersistentVolume을 삭제하려면kubectl명령줄 도구를 사용하여kubectl delete pv명령어를 실행하세요.kubectl delete pv PV_NAMEPV_NAME을 삭제할PersistentVolume의 이름으로 바꿉니다.
작업이 계속 실패하면 Cloud Customer Care에 문의하여 추가 도움을 요청하세요.
오류 100010202: 볼륨 스냅샷 실패
Compute Engine 영구 디스크 스냅샷 생성에 실패하면 오류 100010202가 발생하고 Snapshotting volume failed 오류 메시지가 표시됩니다.
GKE용 백업 서비스에서 시작한 스냅샷 생성 프로세스 중에 가상 머신 (VM) 인스턴스에 대한 디스크의 연결 상태가 변경되면 Compute Engine 영구 디스크 스냅샷 작업이 실패합니다. 이 문제를 트리거하는 일반적인 시나리오는 다음과 같습니다.
- 노드 자동 복구: 비정상 노드가 다시 생성되어 포드가 다시 예약되고 디스크가 분리되었다가 다시 연결됩니다.
- 노드 업그레이드: 노드 풀 업그레이드 중에 노드는 일반적으로 드레인되고 교체됩니다. 포드가 정상적으로 종료되고 새 노드에서 다시 예약되어 디스크 분리 및 다시 연결 주기가 트리거됩니다.
- 클러스터 자동 확장: 축소 이벤트 중에 클러스터 자동 확장 처리가 노드를 삭제하면 영구 디스크가 있는 해당 노드의 포드가 강제 종료되어 디스크 분리가 발생합니다. 이러한 포드가 다른 곳으로 다시 예약되면 새 노드에서 연결이 발생합니다. 스케일 업 이벤트 중에 새 노드가 직접 재연결을 유발하지는 않지만, 새 노드에 예약된 포드는 초기 연결을 트리거합니다.
일시적인 오류입니다. 디스크 연결이 안정화되면 일반적으로 다음 자동 실행에서 백업이 성공합니다. 클러스터 이벤트가 백업에 영향을 미치지 않도록 하려면 다음 권장사항을 적용하세요.
스마트 예약 사용 설정: 스마트 예약(RPO 기반 일정)을 사용하여 백업 계획을 구성합니다. 이렇게 하면 백업 계획의 전체 RPO에 영향을 미치지 않고 지정된 기간 내에 일시적인 장애를 자동으로 재시도할 수 있습니다.
백업 제외 기간 설정: 노드 풀 업그레이드 또는 클러스터 크기 조절 작업을 실행하는 경우 해당 간격 동안 백업 설정에 백업 제외 기간을 추가합니다. 이렇게 하면 클러스터에서 디스크 연결을 적극적으로 수정하는 동안 Backup for GKE 서비스가 일시중지되고 스냅샷 예약이 방지됩니다.
수동 백업 재시도: 수동 또는 주문형 백업의 경우 클러스터 이벤트가 완료되면 백업 작업을 다시 시도합니다.
작업이 계속 실패하면 Cloud Customer Care에 문의하여 추가 도움을 요청하세요.