PersistentVolume은 다시 붙는데 롤아웃은 계속 멈출 때

대표 증상

PersistentVolume은 다시 붙는데 롤아웃은 계속 멈출 때 상황은 하나의 설정값만 틀린 문제가 아니라 배포 경계, 런타임 상태, cache, 권한, 네트워크 경로가 함께 어긋나며 나타나는 경우가 많습니다. 검색으로 들어온 사용자는 먼저 증상을 작게 나누고, 이 가이드의 검색 의도인 PersistentVolume reattached but rollout stuck, PVC attached but pod pending, volume mount ready but rollout blocked 같은 검색 의도를 겨냥합니다.를 기준으로 처음 확인할 신호를 정리해야 합니다.

초반에는 전체 rollback이나 무작정 재시작을 시도하기보다 영향 범위가 어느 node, Pod, job, 사용자, 경로에 묶여 있는지 확인합니다. 범위가 좁으면 최근 변경과 정상 상태를 비교하고, 범위가 넓으면 공통 의존성부터 확인하는 편이 안전합니다.

먼저 확인할 신호

가장 먼저 볼 것은 마지막 오류 줄이 아니라 같은 실패가 반복되는 경계입니다. attached but pod pending, mount succeeded rollout blocked, volume node affinity conflict, fsGroup delayed startup 같은 신호를 기준으로 문제를 묶으면 로그가 길어도 root cause 후보를 줄일 수 있습니다.

PVC/PV bound 상태와 Pod mount 성공 여부를 같은 것으로 보지 않습니다.
새 Pod가 붙는 노드의 volume affinity와 이전 Pod의 종료 상태를 같이 확인합니다.
fsGroup, ownership, init container mount 작업이 끝났는지 확인합니다.
readiness probe가 volume 초기화보다 먼저 실패하는지 시점을 맞춰 봅니다.
storage event와 rollout event를 같은 타임라인으로 비교합니다.

로그와 CLI 예시

아래 명령은 정답을 바로 알려주는 명령이 아니라 원인을 좁히기 위한 첫 관찰 지점입니다. 명령 결과를 정상 시점 또는 같은 역할의 정상 리소스와 비교하면 재시도만 반복하는 시간을 줄일 수 있습니다.

kubectl describe pod <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --previous

흔한 오진

운영 장애에서 가장 위험한 패턴은 증상 이름을 곧 원인으로 착각하는 것입니다. 같은 timeout, permission denied, rollout failure라도 실제 원인은 cache, 권한 상속, Secret 범위, 오래된 client 연결, proxy header처럼 다른 층에 있을 수 있습니다.

PVC가 Bound면 storage 문제는 끝났다고 판단하는 것
readiness와 mount 초기화 타이밍을 보지 않고 rollout만 반복 재시도하는 것

안전한 복구 순서

복구는 가장 작은 단위에서 시작합니다. 먼저 읽기 전용 확인으로 현재 상태를 고정하고, 그다음 영향이 제한된 리소스에서 변경을 검증합니다. 서비스 전체 재시작, cache 전체 삭제, 보안 정책 완화처럼 되돌리기 어려운 조치는 원인 후보가 좁혀진 뒤에 선택해야 합니다.

볼륨이 다시 붙었다는 사실만으로 애플리케이션 준비가 끝난 것은 아니라서 mount 이후 초기화 단계를 따로 봐야 합니다.
이 유형은 storage 팀과 플랫폼 팀이 서로 다른 성공 신호를 보고 있다고 착각할 때 오래 끌립니다.

재발 방지

장애가 끝난 뒤에는 원인 한 줄보다 “왜 그 상태가 오래 남았는지”를 기록해야 합니다. 배포 pipeline, 런타임 reload, 권한 상속, 인증서 갱신, 네트워크 정책처럼 자동화와 운영 절차 사이에 빈 곳이 있었는지 확인합니다.

관련 허브와 문제를 이어 보면 같은 증상을 다른 환경에서도 다시 진단해 볼 수 있습니다.