맞는 디스크가 있는데 PVC 가 묶이지 않는다

목표

no-provisioner StorageClass 와 손으로 만든 PV 로, PVC 가 언제 묶이는지(WaitForFirstConsumer),
어떤 요구면 끝내 안 묶이는지(accessMode 불일치), PVC 를 지운 뒤 PV 가 어떻게 남는지(Retain → Released)를
직접 관찰합니다.

왜 중요한가

파드는 사라져도 데이터는 남아야 합니다. 쿠버네티스는 이를 위해 "디스크 그 자체(PV)" 와 "디스크를 달라는 요청(PVC)" 을
나누고, 둘을 짝지우는 일을 컨트롤러에게 맡깁니다. 그래서 PVC 가 Pending 이라는 한 가지 증상 뒤에는
"아직 쓰는 파드가 없어 일부러 기다리는 중" 과 "조건에 맞는 볼륨이 아예 없음" 이라는 전혀 다른 원인이 숨어 있습니다.

reclaim 정책도 운영에서 자주 사고가 나는 자리입니다. Delete 정책이면 PVC 하나 지운 것으로 데이터가 사라지고,
Retain 이면 데이터는 지켜지지만 PV 가 Released 로 남아 자동으로 재사용되지 않습니다. 둘의 차이를 모르고 PVC 를
지우면 복구할 수 없는 일이 생깁니다.

단계

1. 네임스페이스 kcna-storage 를 만듭니다.
2. StorageClass local-fast(no-provisioner, WaitForFirstConsumer, Retain)를 만듭니다.
3. PV pv-fast-1(1Gi, ReadWriteOnce, Retain, hostPath)을 만듭니다.
4. PVC data 를 만들고 소비자가 없어 Pending 에 머무는 것을 확인합니다.
5. 파드 writer 가 data 를 마운트하자 PVC 가 pv-fast-1 에 묶이는 것을 확인합니다.
6. ReadWriteMany 를 요구하는 PVC wide 와 파드 wider 가 끝내 묶이지 못하는 것을 확인합니다.
7. writer 와 data 를 지우고 pv-fast-1 이 Released 로 남는 것을 확인합니다.
8. 관찰 결과를 /root/kcna-storage/report.txt 에 장부로 남깁니다.

참고

• kubectl describe pvc <이름> -n kcna-storage 의 Events 가 "왜 아직 안 묶였는지" 를 알려 줍니다.
• kubectl get pv 의 CLAIM 열은 Released 뒤에도 옛 PVC 이름을 기억합니다 — 그래서 다른 PVC 에 자동으로 묶이지 않습니다.
• 공식 문서: [퍼시스턴트 볼륨](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) ·

[스토리지 클래스](https://kubernetes.io/docs/concepts/storage/storage-classes/).

단계 8개

1. 디스크를 나눠 줄 작업장 열기
2. 쓰는 사람이 나타날 때까지 기다리는 저장소 등급
3. 관리자가 손으로 깔아 둔 1Gi 디스크
4. 맞는 디스크가 있는데도 PVC 가 Pending 이다
5. 파드가 나타나자 PVC 가 묶이다
6. 여럿이 같이 쓰겠다는 요구는 아무도 받아 주지 않는다
7. PVC 를 지웠는데 디스크는 남았다
8. 디스크가 어떻게 흘러갔는지 장부로 남기기