PV·PVC가 Terminating에 남을 때 확인할 항목
PV가 삭제되지 않을 때 Finalizer를 확인하고 수정했던 명령 메모입니다. Terminating으로 남는 이유를 보지 않고 Finalizer부터 비우면 필요한 정리 작업을 건너뛸 수 있어, 상태 확인과 수동 변경을 나눠 정리했습니다.
삭제 요청과 Finalizer
Finalizer는 삭제 전에 처리해야 할 작업을 나타내는 메타데이터입니다. 일반적인 잠금이나 무조건 잘못 걸린 상태를 뜻하지 않습니다.
삭제를 요청하면 오브젝트에 deletionTimestamp가 설정됩니다. 남아 있는 Finalizer에 해당하는 처리가 끝나야 오브젝트 제거가 진행될 수 있습니다.
PV의 kubernetes.io/pv-protection은 PVC에 바인딩된 PV의 삭제를 지연하고, PVC의 kubernetes.io/pvc-protection은 Pod가 사용하는 PVC의 삭제를 지연합니다. 이 둘을 스토리지 파일의 물리적 잠금과 같은 것으로 해석하면 안 됩니다.
PV와 PVC 연결 확인
먼저 전체 상태와 이벤트를 확인합니다. 아래 이름과 네임스페이스는 예시입니다.
kubectl get pv example-pv -o yaml
kubectl describe pv example-pv
kubectl get pvc example-claim -n example -o yaml
kubectl describe pvc example-claim -n example
kubectl get pods -n example -o yamlPV의 claimRef와 PVC의 volumeName, Pod의 볼륨 참조를 이어서 봅니다. 실제 사용 중이면 해당 워크로드의 종료·정리 절차부터 진행해야 합니다.
Pod가 없다는 확인만으로 모든 정리가 끝났다고 판단할 수도 없습니다. PV의 reclaim policy와 스토리지의 연결·해제 상태, provisioner나 관련 컨트롤러의 오류도 확인해야 합니다. Finalizer 키가 다르면 담당하는 작업도 다를 수 있습니다.
수동 제거 전에 확인할 조건
담당 컨트롤러가 복구돼 정상 절차를 마칠 수 있다면 그 경로를 먼저 사용합니다. 수동 변경이 필요한 경우에도 필요한 정리를 마쳤는지와 남길 데이터, 실제 스토리지 상태를 확인해야 합니다.
원래 메모는 metadata.finalizers 전체를 비우는 방식이었습니다. 여러 Finalizer가 있으면 다른 정리 작업까지 함께 건너뛰므로 일반적인 복구 명령으로 쓰기 어렵습니다.
특정 Finalizer의 수동 변경 예시
다음은 필요한 정리를 끝내고 첫 번째 항목이 kubernetes.io/pv-protection임을 확인한 경우의 예시입니다. 실행할 때도 해당 값이 일치하는지 JSON Patch의 test로 확인합니다.
kubectl patch pv example-pv --type=json -p='[
{"op":"test","path":"/metadata/finalizers/0","value":"kubernetes.io/pv-protection"},
{"op":"remove","path":"/metadata/finalizers/0"}
]'순서나 값이 다르면 이 예시는 실패합니다. 현재 상태를 다시 확인해야 하며, 실패를 피하려고 전체 배열을 비우는 방식으로 바꾸면 안 됩니다.
변경 이후에도 다른 Finalizer가 남아 있으면 삭제는 계속 기다릴 수 있습니다. Kubernetes 오브젝트가 사라진 뒤에도 실제 디스크·볼륨 정리와 데이터 보관 결과는 별도로 확인해야 합니다.