[CKA Ch-05] 스토리지: PVC가 Pending에 머무는 이유를 바인딩 규칙으로 읽기

결론부터

1. PVC는 저장 공간 요청이고 PV는 그 요청을 채우는 실제 볼륨입니다. 컨트롤 플레인의 제어 루프가 PVC에 맞는 PV를 찾아 일대일로 묶고 맞는 PV가 없으면 PVC는 무기한 Pending으로 남습니다.
2. 바인딩에서 먼저 맞춰 볼 조건은 StorageClass 이름, 접근 모드, 크기입니다. storageClassName을 생략한 PVC에는 기본 StorageClass가 붙고 ""로 적은 PVC는 클래스 없는 PV에만 묶입니다.
3. 동적 프로비저닝은 StorageClass가 있어야 일어납니다. 클래스의 volumeBindingMode가 WaitForFirstConsumer이면 그 PVC를 쓰는 Pod가 생길 때까지 Pending인 것이 정상입니다.
4. 회수 정책은 Retain, Delete, Recycle(사용 중단)입니다. 동적으로 만든 PV는 StorageClass의 reclaimPolicy를 물려받고 기본값은 Delete입니다. 데이터가 중요하면 kubectl patch pv로 Retain으로 바꿉니다.
5. 접근 모드는 노드 기준입니다. ReadWriteOnce는 한 노드의 여러 Pod가 함께 쓸 수 있고 클러스터 전체에서 Pod 하나로 제한하려면 ReadWriteOncePod를 씁니다.

커리큘럼(CNCF, CKA Curriculum v1.37)의 Storage 항목은 세 개입니다.

예시는 가상의 쇼핑몰과 게시판입니다. 네임스페이스 shop의 주문 DB(order-db)와 게시판 첨부파일 저장소(board-files)가 영구 저장소를 씁니다.

0. 먼저 잡을 그림

Persistent Volumes 문서의 정의를 표로 옮겼습니다.

수명 주기는 프로비저닝, 바인딩, 사용, 회수 네 단계입니다.

1
[프로비저닝]          [바인딩]              [사용]                 [회수]
2
정적: 관리자가 PV 생성   제어 루프가 PVC에 맞는    Pod가 volumes에서       PVC 삭제 후
3
동적: StorageClass가    PV를 찾아 일대일로 묶음   persistentVolumeClaim   reclaimPolicy대로
4
      PV 생성                                   으로 참조              Retain/Delete

PV는 Pod와 무관한 수명을 가지고 emptyDir 같은 임시 볼륨은 Pod와 함께 사라집니다. 컨테이너 자체의 쓰기 레이어는 컨테이너가 다시 시작되면 비워지므로 남겨야 할 데이터는 볼륨에 둡니다. 쓰기 레이어의 커널 쪽 구조(OverlayFS)는 시험 범위 밖이라 쿠버네티스 아래의 리눅스 4편에 따로 두었습니다.

1. StorageClass와 동적 프로비저닝

1-1. StorageClass가 하는 일

StorageClass는 관리자가 제공하는 저장소의 “클래스”를 기술합니다. 클래스가 무엇을 뜻하는지(성능 등급, 백업 정책 등)는 쿠버네티스가 정하지 않습니다.

문서의 예시 클래스를 주문 DB용으로 옮겼습니다. 프로비저너 이름은 클러스터에 설치된 드라이버 이름(kubectl get csidriver, 2-4절)으로 바꿉니다.

1
apiVersion: storage.k8s.io/v1
2
kind: StorageClass
3
metadata:
4
  name: order-fast
5
  annotations:
6
    storageclass.kubernetes.io/is-default-class: "false"
7
provisioner: csi-driver.example-vendor.example
8
reclaimPolicy: Retain             # 기본값은 Delete
9
allowVolumeExpansion: true
10
volumeBindingMode: WaitForFirstConsumer
11
parameters:
12
  guaranteedReadWriteLatency: "true"   # 프로비저너 전용 값

kubectl create에는 StorageClass, PV, PVC를 만드는 하위 명령이 없으므로 문서 예제를 복사해 고치거나 kubectl get sc <이름> -o yaml을 받아 고칩니다.

1-2. 동적 프로비저닝의 흐름

Dynamic Volume Provisioning 문서를 따라가면 순서는 다음과 같습니다.

1. 관리자가 StorageClass를 하나 이상 만듭니다.
2. 사용자가 PVC의 storageClassName에 그 클래스 이름을 적습니다(옛 volume.beta.kubernetes.io/storage-class 어노테이션은 사용 중단).
3. 정적으로 만든 PV 중 맞는 것이 없으면 클러스터가 그 PVC만을 위한 볼륨을 동적으로 만듭니다.
4. 동적으로 만든 PV는 항상 그 PVC에 묶입니다.

storageClassName: ""인 PVC는 동적 프로비저닝을 스스로 끈 것입니다. selector가 비어 있지 않은 PVC에도 PV를 동적으로 만들 수 없습니다.

1-3. 기본 StorageClass

PVC가 storageClassName을 적지 않으면 기본 StorageClass가 쓰입니다. StorageClass 하나에 어노테이션 storageclass.kubernetes.io/is-default-class: "true"가 있어야 하고 API 서버의 DefaultStorageClass 승인 컨트롤러(기본 켜짐)가 클래스를 생략한 PVC에 그 이름을 채워 넣습니다.

기본 클래스는 kubectl get sc에서 이름 옆에 (default)로 표시됩니다. Change the default StorageClass 문서의 방법은 기존 기본 클래스의 어노테이션을 "false"로 바꾸고 새 클래스를 "true"로 바꾸는 것입니다.

1
kubectl get storageclass
2
kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
3
kubectl patch storageclass order-fast -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

kubectl v1.37은 기본 어노테이션이 붙은 클래스가 둘이어도 실제로 쓰이는 하나(가장 최근 것)에만 (default)를 붙였습니다. 기본을 바꾼 뒤에는 이전 클래스의 어노테이션이 "false"인지도 확인합니다.

1-4. volumeBindingMode

Immediate로 특정 존에만 있는 저장소를 쓰면 Pod의 스케줄링 요구를 모른 채 PV가 정해져 Pod를 어디에도 둘 수 없게 될 수 있습니다.

WaitForFirstConsumer에는 함정이 하나 있습니다. Pod 스펙에 nodeName을 직접 쓰면 스케줄러를 건너뛰므로 PVC가 Pending으로 남고 Pod에는 FailedMount ... PVC is not bound가 반복됩니다. 노드를 고정하려면 kubernetes.io/hostname 노드 셀렉터를 씁니다.

1-5. local 볼륨과 StorageClass

local 볼륨은 동적 프로비저닝을 지원하지 않습니다. 그래도 문서는 WaitForFirstConsumer 모드의 StorageClass를 만들어 두라고 권합니다. 바인딩을 미뤄야 스케줄러가 Pod의 모든 제약을 보고 PV를 고를 수 있습니다. 아래는 Storage Classes 문서의 예제 그대로입니다.

1
apiVersion: storage.k8s.io/v1
2
kind: StorageClass
3
metadata:
4
  name: local-storage
5
provisioner: kubernetes.io/no-provisioner   # 자동 프로비저닝 없음
6
volumeBindingMode: WaitForFirstConsumer

1-6. 자주 틀리는 지점

• PVC의 storageClassName을 클래스 이름과 한 글자라도 다르게 쓰면 동적 프로비저닝이 일어나지 않고 Pending에 머뭅니다. kubectl describe pvc의 Events를 봅니다.
• 회수 정책은 PV를 만들 때 클래스에서 정해집니다. 클래스를 나중에 고쳐도 이미 만든 PV는 바뀌지 않으므로 PV를 직접 patch합니다.
• WaitForFirstConsumer 클래스의 PVC가 Pending인 것을 오류로 보고 손대는 실수가 있습니다. Pod를 만들면 풀립니다.

1-7. 직접 해 보기

1. 연습 클러스터의 kubectl get sc에서 (default) 표시를 확인합니다. kind의 기본 클래스는 standard(프로비저너 rancher.io/local-path, Delete, WaitForFirstConsumer)입니다.
2. 기본 표시를 다른 클래스로 옮기고 클래스를 생략한 PVC를 만들어 kubectl get pvc -o yaml의 storageClassName이 새 기본 클래스로 채워졌는지 봅니다. 기본 클래스가 없을 때 만든 PVC가 기본이 생기자 소급해서 채워지는지도 봅니다.
3. WaitForFirstConsumer 클래스로 PVC를 만들어 Events의 waiting for first consumer to be created before binding을 확인한 뒤 그 PVC를 쓰는 Pod를 만들어 kubectl get pvc -w로 Bound가 되는 것을 봅니다.

2. 볼륨 타입, 접근 모드, 회수 정책

2-1. 볼륨 타입

볼륨은 Pod의 컨테이너가 접근할 수 있는 디렉터리이고 그 디렉터리가 어디서 오는지는 볼륨 타입이 정합니다. Pod의 .spec.volumes에 볼륨을 정의하고 컨테이너마다 volumeMounts로 마운트 위치를 적습니다.

hostPath의 type 값은 시험에 자주 나옵니다.

문서는 hostPath PV를 단일 노드 테스트 전용이라고 적지만 공식 튜토리얼과 연습 과제는 PV 개념을 보여 주려고 hostPath PV를 자주 씁니다.

게시판 Pod가 업로드 임시 파일을 emptyDir에 두고 크기를 제한하는 예입니다.

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: board-upload
5
  namespace: shop
6
spec:
7
  containers:
8
  - name: app
9
    image: nginx
10
    volumeMounts:
11
    - name: tmp-upload
12
      mountPath: /var/tmp/upload
13
  volumes:
14
  - name: tmp-upload
15
    emptyDir:
16
      sizeLimit: 500Mi

임시 데이터라도 StorageClass의 기능(정해진 크기의 네트워크 디스크, 확장)이 필요하면 generic ephemeral volume을 씁니다. Ephemeral Volumes 문서의 규칙은 셋입니다.

• PVC 이름은 <Pod 이름>-<볼륨 이름>이고 Pod와 같은 네임스페이스에 생깁니다.
• Pod가 이 PVC의 소유자(ownerReference)라서 Pod를 지우면 PVC도 지워집니다. 볼륨이 함께 지워지는지는 클래스의 회수 정책을 따릅니다.
• 그 Pod를 위해 만든 PVC가 아니면 쓰지 않으므로 같은 이름의 PVC가 미리 있으면 Pod가 시작하지 못합니다.

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: report
5
  namespace: shop
6
spec:
7
  containers:
8
  - name: app
9
    image: busybox:1.36
10
    command: ["sleep", "1000000"]
11
    volumeMounts:
12
    - name: scratch
13
      mountPath: /scratch
14
  volumes:
15
  - name: scratch
16
    ephemeral:
17
      volumeClaimTemplate:
18
        spec:
19
          accessModes: ["ReadWriteOnce"]
20
          storageClassName: order-fast
21
          resources:
22
            requests:
23
              storage: 1Gi

이 Pod가 만들어지면 kubectl -n shop get pvc에 report-scratch가 보입니다.

2-2. 접근 모드

문서가 덧붙이는 사실이 시험 함정입니다.

• 접근 모드는 PVC와 PV를 맞추는 데 쓰이고 마운트 뒤의 쓰기 보호는 강제하지 않습니다. ReadOnlyMany로 만든 PV가 읽기 전용이라는 보장도 없습니다. 실제로 Pod 하나로 제한하는 것은 ReadWriteOncePod뿐입니다.
• 볼륨이 여러 모드를 지원해도 한 번에 한 모드로만 마운트됩니다.
• 지원하는 모드는 볼륨 플러그인마다 다릅니다. 문서 표 기준 HostPath는 RWO만, NFS는 RWO, ROX, RWX, CSI는 드라이버에 따라 다릅니다.
• 문서는 ReadWriteOncePod를 CSI 볼륨 전용이라고 적습니다. kind의 local-path(hostPath PV)에서도 RWOP PVC가 묶였고 같은 PVC를 쓰는 두 번째 Pod는 unavailable due to PersistentVolumeClaim with ReadWriteOncePod로 스케줄되지 않았습니다.

주문 DB처럼 Pod 하나만 써야 하는 볼륨이면 이렇게 요청합니다.

1
apiVersion: v1
2
kind: PersistentVolumeClaim
3
metadata:
4
  name: order-db-data
5
  namespace: shop
6
spec:
7
  accessModes:
8
  - ReadWriteOncePod
9
  storageClassName: order-fast
10
  resources:
11
    requests:
12
      storage: 20Gi

2-3. 회수 정책

PVC를 지운 뒤 PV를 어떻게 할지 정하는 것이 회수 정책(persistentVolumeReclaimPolicy)입니다.

이미 만든 PV의 정책은 Change the Reclaim Policy of a PersistentVolume 문서의 명령으로 바꿉니다.

1
kubectl get pv
2
kubectl patch pv <PV 이름> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
3
kubectl get pv            # RECLAIM POLICY 열 확인

문서의 확인 출력은 열 이름이 ACCESSMODES, RECLAIMPOLICY인 옛 모양입니다. kubectl v1.37에서는 이렇게 나옵니다.

1
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
2
pvc-8560aeed-4a36-48fd-8345-7970fefc501e   1Gi        RWO            Retain           Bound    shop/order-db-data   standard       <unset>                          2s

VOLUMEATTRIBUTESCLASS 열은 1.34에 GA가 된 VolumeAttributesClass(볼륨의 IOPS 같은 속성을 바꾸는 API)를 보여 줍니다. 커리큘럼 문구 밖이라 <unset>이면 넘어가도 됩니다.

Retain PV를 수동으로 회수하는 순서는 PV 삭제(외부 저장 자산은 남음), 자산의 데이터 정리, 자산 삭제입니다. 같은 자산을 다시 쓰려면 같은 정의로 PV를 새로 만듭니다.

Released PV를 지우지 않고 다시 묶는 방법도 문서(Recovering from Failure when Expanding Volumes 절의 관리자 절차)에 있습니다. PV의 claimRef를 지워 Available로 만든 뒤 volumeName으로 그 PV를 지정한 PVC를 새로 만듭니다(3-2절 YAML). 이전 데이터가 그대로 보이므로 새 PVC가 그 데이터를 봐도 되는 경우에만 씁니다.

1
kubectl patch pv <PV 이름> --type=json -p '[{"op":"remove","path":"/spec/claimRef"}]'
2
kubectl get pv <PV 이름>     # STATUS가 Available로 바뀌는지

2-4. CSI 드라이버와 프로비저너 이름

CSI(Container Storage Interface)는 저장 시스템을 워크로드에 노출하는 표준 인터페이스이고 저장소 벤더는 드라이버를 쿠버네티스 코드 밖에서 만들어 클러스터에 설치합니다. 시험에서 알아야 할 연결은 하나입니다. StorageClass의 provisioner 값이 설치된 CSI 드라이버 이름과 같아야 그 드라이버가 PVC를 보고 볼륨을 만듭니다. 이름이 다르면 아무도 볼륨을 만들지 않아 PVC가 Pending에 머뭅니다.

1
kubectl get csidriver                       # 설치된 드라이버 이름, ATTACHREQUIRED
2
kubectl get sc order-fast -o jsonpath='{.provisioner}{"\n"}'   # 위 이름과 같아야 함
3
kubectl get csinode <노드> -o yaml          # 그 노드의 kubelet에 등록된 드라이버
4
kubectl get volumeattachment                # 어떤 PV가 어느 노드에 붙었는지
5
kubectl get pod -A | grep -i csi            # 드라이버의 컨트롤러, 노드 Pod

attachRequired: true인 드라이버는 Pod가 노드에 배정되면 VolumeAttachment 객체가 생기고 Pod를 지우면 사라집니다. 드라이버의 내부 구조(사이드카 컨테이너, CSI RPC)는 시험 범위 밖입니다.

in-tree 볼륨 플러그인에서 CSI로 넘어가는 마이그레이션은 v1.25부터 stable이고 해당 CSI 드라이버는 관리자가 설치해야 합니다. 옛 자료의 provisioner: kubernetes.io/gce-pd 같은 예는 그 드라이버가 있는 클러스터에서만 동작하니 kubectl get sc로 실제 프로비저너 이름부터 확인합니다.

2-5. 자주 틀리는 지점

• RWO를 “Pod 하나”로 읽는 실수. RWO는 노드 하나 기준이라 같은 노드의 여러 Pod가 함께 마운트할 수 있습니다.
• 회수 정책을 PVC나 Pod에서 바꾸려는 실수. 정책은 PV(spec.persistentVolumeReclaimPolicy)나 StorageClass(reclaimPolicy)에 있고 필드 이름도 두 곳이 다릅니다.
• Retain PV가 Released가 되면 새 PVC가 자동으로 묶이지 않습니다. “데이터는 남기고 다시 쓰게 하라”는 과제에서는 이 상태를 먼저 확인합니다.
• hostPath FileOrCreate는 상위 디렉터리를 만들지 않아 Pod가 시작하지 못할 수 있습니다.
• StorageClass의 provisioner가 kubectl get csidriver 목록과 다른데 PVC만 고치는 실수.
• generic ephemeral volume의 PVC를 직접 지우거나 같은 이름의 PVC를 미리 만드는 실수.

2-6. 직접 해 보기

1. 같은 노드에 고정한 Pod 두 개(nodeSelector)가 RWO PVC 하나를 함께 마운트하는지 봅니다. 한 Pod를 다른 노드로 고정하면 kind의 local-path PV에서는 FailedScheduling ... didn't match PersistentVolume's node affinity로 Pending이 됩니다. 노드에 묶인 볼륨이라 생기는 결과입니다.
2. 동적 PVC를 만들고 생성된 PV의 회수 정책을 Retain으로 바꾼 뒤 PVC를 지워 PV가 Released로 남는 것을 봅니다. 이어서 claimRef를 지워 Available이 되는지 봅니다.
3. emptyDir에 파일을 쓰고 컨테이너만 죽였을 때(kubectl exec <Pod> -- sh -c 'kill 1')와 Pod를 지웠을 때 파일이 남는지 비교합니다. nginx 이미지에는 kill 실행 파일이 없어 셸 내장 명령으로 보냅니다.
4. 2-1의 report Pod를 만들고 report-scratch PVC가 생기는지, Pod를 지우면 PVC가 사라지는지 kubectl get pvc,pv -w로 봅니다.

3. PV와 PVC 관리

3-1. 정적 프로비저닝 전체 흐름

공식 튜토리얼(Configure a Pod to Use a PersistentVolume for Storage)과 같은 구성을 게시판 첨부파일 저장소로 옮겼습니다. 노드의 /mnt/data를 쓰는 hostPath PV, 그것을 요청하는 PVC, PVC를 마운트하는 Pod 순서입니다.

1
apiVersion: v1
2
kind: PersistentVolume
3
metadata:
4
  name: board-files-pv
5
  labels:
6
    type: local
7
spec:
8
  storageClassName: manual
9
  capacity:
10
    storage: 10Gi
11
  accessModes:
12
  - ReadWriteOnce
13
  persistentVolumeReclaimPolicy: Retain
14
  hostPath:
15
    path: /mnt/data
16
---
17
apiVersion: v1
18
kind: PersistentVolumeClaim
19
metadata:
20
  name: board-files
21
  namespace: shop
22
spec:
23
  storageClassName: manual
24
  accessModes:
25
  - ReadWriteOnce
26
  resources:
27
    requests:
28
      storage: 3Gi
29
---
30
apiVersion: v1
31
kind: Pod
32
metadata:
33
  name: board
34
  namespace: shop
35
spec:
36
  containers:
37
  - name: app
38
    image: nginx
39
    volumeMounts:
40
    - name: files
41
      mountPath: /usr/share/nginx/html
42
  volumes:
43
  - name: files
44
    persistentVolumeClaim:
45
      claimName: board-files

PVC가 3Gi를 요청했어도 10Gi PV에 묶일 수 있습니다. 요청한 만큼은 반드시 받지만 볼륨이 더 클 수 있어서 kubectl get pvc의 CAPACITY에는 묶인 PV의 크기 10Gi가 보입니다.

3-2. 바인딩 규칙

Persistent Volumes 문서의 바인딩 규칙을 한 표로 모았습니다.

특정 PV에 묶고 싶으면 PVC의 volumeName에 PV 이름을 적습니다(사전 바인딩). 이때도 클래스, 접근 모드, 크기는 검사합니다. 다른 PVC가 그 PV를 먼저 가져가지 못하게 하려면 PV의 claimRef에 PVC를 적어 예약합니다. 지정한 PV가 이미 다른 PVC에 묶여 있으면 바인딩이 Pending에 머뭅니다.

1
# PVC 쪽: 이 PV에만 묶이고 싶다
2
apiVersion: v1
3
kind: PersistentVolumeClaim
4
metadata:
5
  name: order-db-restore
6
  namespace: shop
7
spec:
8
  storageClassName: ""        # 빈 문자열을 명시해야 기본 클래스가 붙지 않는다
9
  volumeName: order-db-old-pv
10
  accessModes:
11
  - ReadWriteOnce
12
  resources:
13
    requests:
14
      storage: 20Gi
15
---
16
# PV 쪽: 이 PVC만 받겠다
17
apiVersion: v1
18
kind: PersistentVolume
19
metadata:
20
  name: order-db-old-pv
21
spec:
22
  storageClassName: ""
23
  claimRef:
24
    name: order-db-restore
25
    namespace: shop
26
  capacity:
27
    storage: 20Gi
28
  accessModes:
29
  - ReadWriteOnce
30
  persistentVolumeReclaimPolicy: Retain
31
  hostPath:
32
    path: /mnt/order-db

문서는 이 방법이 Retain 정책의 PV를 다시 쓸 때 유용하다고 적습니다.

3-3. PV 상태

PV가 어떤 PVC에 묶였는지는 kubectl get pv의 CLAIM 열(<네임스페이스>/<PVC>)로 봅니다.

3-4. 사용 중인 객체 보호

Pod가 쓰고 있는 PVC를 지우면 바로 사라지지 않습니다(Storage Object in Use Protection). PVC를 쓰는 Pod가 모두 없어질 때까지 삭제가 미뤄지고 그동안 상태는 Terminating, Finalizers에는 kubernetes.io/pvc-protection이 보입니다. PVC에 묶인 PV를 지울 때는 kubernetes.io/pv-protection이 붙습니다.

1
kubectl -n shop delete pvc board-files      # 삭제 완료를 기다리느라 명령이 돌아오지 않을 수 있다
2
kubectl -n shop describe pvc board-files    # Status: Terminating, Finalizers, Used By 확인
3
kubectl -n shop delete pod board            # Pod를 지우면 PVC 삭제가 진행된다

delete pvc가 멈춘 것처럼 보이면 describe pvc의 Used By에서 그 PVC를 쓰는 Pod부터 찾습니다.

3-5. 볼륨 확장

1
kubectl -n shop patch pvc order-db-data -p '{"spec":{"resources":{"requests":{"storage":"30Gi"}}}}'
2
kubectl -n shop get pvc order-db-data -w

드라이버가 확장을 지원하지 않으면 allowVolumeExpansion을 켜도 진행되지 않습니다. kind 기본 local-path는 waiting for an external controller에서 멈췄습니다.

3-6. PVC가 Pending일 때 확인 순서

1절과 3-2절을 합친 점검 목록입니다.

Events 문구로 갈래를 바로 나눌 수 있습니다. 맞는 정적 PV가 없고 PVC의 클래스 이름에 해당하는 StorageClass도 없으면 크기 이야기 대신 ProvisioningFailed storageclass.storage.k8s.io "manual" not found가 찍힙니다. 맞는 PV가 없어서 그 이름으로 동적 프로비저닝을 시도했다는 뜻이라 “맞는 PV가 없다”와 “프로비저너가 없다”를 함께 봅니다.

3-7. 자주 틀리는 지점

• PVC를 Pod와 다른 네임스페이스에 만드는 실수. PV는 네임스페이스가 없지만 PVC는 있습니다.
• storageClassName을 PV에만 적고 PVC에는 생략하면 기본 클래스가 PVC에 붙어 PV와 클래스가 달라집니다. 정적 PV 과제에서는 PV와 PVC에 같은 클래스 이름을 쓰거나 둘 다 ""로 둡니다.
• Pod 스펙의 persistentVolumeClaim.claimName에 PV 이름을 적는 실수. Pod는 PV를 직접 참조하지 않습니다.
• 확장할 때 PV 크기를 직접 고치는 실수. 항상 PVC를 고칩니다.

3-8. 직접 해 보기

1. 3-1의 PV, PVC, Pod를 만들고 노드의 /mnt/data에 index.html을 써서 Pod 안에서 보이는지 확인합니다. kind라면 Pod가 뜬 노드 컨테이너 안의 경로입니다.
2. PVC 요청을 20Gi로 바꿔 다시 만들고 kubectl describe pvc Events에서 Pending의 이유를 읽습니다. 3-6 끝의 ProvisioningFailed 문구가 나오는지 봅니다.
3. Pod가 쓰는 PVC를 지워 Terminating, kubernetes.io/pvc-protection, Used By: <Pod 이름>을 확인한 뒤 Pod를 지워 PVC가 사라지는 것을 봅니다.

4. 확인 문제

직접 만든 연습 과제입니다. 시험 문항이나 덤프에서 옮긴 것이 아닙니다.

문제 1. 이름 pay-logs-pv, 용량 2Gi, 접근 모드 ReadWriteOnce, 회수 정책 Retain, StorageClass manual, 노드 경로 /srv/pay-logs인 PV를 만들고 네임스페이스 shop에 이 PV에 묶일 1Gi PVC pay-logs를 만드세요.

1
apiVersion: v1
2
kind: PersistentVolume
3
metadata:
4
  name: pay-logs-pv
5
spec:
6
  storageClassName: manual
7
  capacity:
8
    storage: 2Gi
9
  accessModes:
10
  - ReadWriteOnce
11
  persistentVolumeReclaimPolicy: Retain
12
  hostPath:
13
    path: /srv/pay-logs
14
---
15
apiVersion: v1
16
kind: PersistentVolumeClaim
17
metadata:
18
  name: pay-logs
19
  namespace: shop
20
spec:
21
  storageClassName: manual
22
  accessModes:
23
  - ReadWriteOnce
24
  resources:
25
    requests:
26
      storage: 1Gi

문제 2. PVC order-db-data가 Pending입니다. PVC가 요청한 클래스 order-fast의 VOLUMEBINDINGMODE가 WaitForFirstConsumer이고 이 PVC를 쓰는 Pod는 아직 없습니다. 무엇을 해야 하나요?

문제 3. 동적으로 만들어진 PV pvc-1a2b...가 있습니다. PVC를 지워도 데이터가 남도록 바꾸세요.

1
kubectl patch pv pvc-1a2b... -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
2
kubectl get pv pvc-1a2b...

문제 4. 클러스터에 StorageClass standard(기본)와 order-fast가 있습니다. 기본을 order-fast로 바꾸세요.

1
kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
2
kubectl patch storageclass order-fast -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
3
kubectl get sc

문제 5. 노드 하나에서 도는 Pod 두 개가 같은 RWO PVC를 마운트하고 있습니다. 이것이 가능한 이유와 Pod 하나만 쓰게 강제하려면 무엇을 바꿔야 하는지 답하세요.

문제 6. PVC order-db-data를 20Gi에서 30Gi로 늘리려 했는데 거부됩니다. 가장 먼저 확인할 것은 무엇인가요?

문제 7. 네임스페이스 shop의 PVC board-files가 Pending이고 Events에는 외부 프로비저너가 볼륨을 만들기를 기다린다는 메시지만 반복됩니다. 클래스는 Immediate 모드이고 provisioner는 csi-driver.example-vendor.example입니다. 어디를 확인하나요?

1
kubectl get csidriver
2
kubectl get sc <클래스> -o jsonpath='{.provisioner}{"\n"}'
3
kubectl get pod -A | grep -i csi

문제 8. 네임스페이스 shop의 Pod report에 이름이 scratch인 generic ephemeral volume이 있습니다. 만들어지는 PVC의 이름과 Pod를 지웠을 때 PVC가 어떻게 되는지 답하세요.

5. 범위와 한계

• 명령과 YAML은 kind v1.37(기본 StorageClass standard = local-path-provisioner)에서 2026년 10월에 직접 돌려 확인했습니다. 확장과 VolumeAttachment는 local-path가 지원하지 않아 예제 드라이버 csi-driver-host-path로 확인했습니다.
• 클라우드 디스크 CSI 드라이버, NFS 같은 RWX 볼륨, 여러 노드에 걸친 attach와 detach는 돌리지 못했습니다. 시험 환경에 어떤 프로비저너와 StorageClass가 준비되어 있는지는 공식 문서에 없으니 kubectl get sc부터 봅니다.
• 볼륨 스냅샷, 복제, 원시 블록 볼륨은 커리큘럼 문구에 없어 다루지 않았습니다. RecoverVolumeExpansionFailure(v1.34 stable)처럼 버전에 따라 바뀌는 항목은 시험 기준 버전의 문서로 다시 확인합니다.

참고 자료

시험 범위

• CNCF, CKA Curriculum v1.37

kubernetes.io

• Persistent Volumes
• Storage Classes
• Dynamic Volume Provisioning
• Volumes
• Ephemeral Volumes
• Configure a Pod to Use a PersistentVolume for Storage
• Change the Reclaim Policy of a PersistentVolume
• Change the default StorageClass

이 블로그의 관련 글

• 쿠버네티스 아래의 리눅스 4: OverlayFS (시험 범위 밖 심화)