스토리지 진단 — Pending과 마운트 실패

결론부터

PVC의 바인딩 실패와 Pod의 마운트 실패를 나눈 뒤, 해당 리소스의 Events에서 원인을 찾는다.

지금까지는 저장소가 연결되는 정상 흐름을 봤다. 이 장은 PVC가 아직 저장소를 못 구했는지, 구한 저장소를 Pod에 붙이지 못했는지부터 가르는 진단 순서다.

진단 절차

증상은 둘 중 하나다. 어느 쪽인지부터 가른다.

# PVC가 Pending
kubectl describe pvc data                 # ★ Events
kubectl get pv                            # 조건에 맞는 PV가 있는가
kubectl get sc                            # StorageClass 이름이 맞는가

# Pod이 ContainerCreating에서 멈춤
kubectl describe pod web                  # ★ Events에 마운트 에러
kubectl get events --field-selector involvedObject.name=web

# 노드에서 확인
kubectl get volumeattachments
sudo journalctl -u kubelet | grep -i mount

VolumeAttachment는 “이 볼륨이 지금 어느 노드에 붙어 있는가”를 기록하는 클러스터 스코프 오브젝트다. Multi-Attach error가 났을 때 여기서 옛 노드가 아직 볼륨을 잡고 있는지를 눈으로 확인할 수 있다. 직접 만들거나 고치는 물건은 아니다 — 조회용으로만 알아 두면 된다.

Events 메시지	원인
no persistent volumes available for this claim	PV 없음 / 조건 불일치
waiting for first consumer	정상. Pod을 만들면 된다
Multi-Attach error for volume	RWO 볼륨을 두 노드에서 쓰려 한다
FailedMount: timeout expired waiting	스토리지 백엔드 연결 문제
MountVolume.SetUp failed ... not found	ConfigMap/Secret이 없다

요약

• PVC가 Pending이면 describe pvc에서 클래스와 바인딩 조건을 확인한다.
• waiting for first consumer는 소비할 Pod의 배치를 기다리는 상태다.
• Pod이 ContainerCreating이면 describe pod에서 attach·mount 오류를 확인한다.

다음: API 요청 처리 흐름