xDev Asia

PersistentVolume、PersistentVolumeClaim、StorageClassのハンズオン。動的プロビジョニング、回収ポリシー、ボリュームモードとアクセスモード。CKA対策。

Persistent Volumes、PVCsとStorageClass — 静的・動的プロビジョニング

1. PV & PVCライフサイクル

静的プロビジョニング:
  管理者がPVを作成 → 開発者がPVCを作成 → K8sがPVCをマッチするPVにバインド

動的プロビジョニング:
  開発者がPVC（storageClassName指定）を作成 → StorageClassが自動的にPVを作成

バインド条件:
  ✓ accessMode一致
  ✓ ストレージサイズ: PV >= PVC要求量
  ✓ storageClass一致（または""）
  ✓ volumeMode一致

2. PVとPVCの作成

# PersistentVolume（静的、ラボ用hostPath）
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-data
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  hostPath:
    path: /mnt/data    # ラボ専用; 本番ではNFS/EBSを使用

---
# PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
  storageClassName: manual

回収ポリシー	PVC削除時の動作
Retain	PVはデータを保持、フェーズ = Released（管理者が手動削除が必要）
Delete	PVとストレージバックエンドが自動的に削除
Recycle（非推奨）	ファイルを削除、PVは新しいPVCに再利用可能

試験のポイント：PVフェーズのライフサイクル：Available（PVCなし）→ Bound（PVCバインド済み）→ Released（PVC削除、Retainポリシー）→ Failed。ReleasedのPVは管理者が.spec.claimRefを手動削除するまで新しいPVCにバインドできません。

3. StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"  # デフォルトSC
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  iopsPerGB: "10"
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer  # Podスケジュール時まで遅延

volumeBindingMode	動作
Immediate	PVC作成時にPVが即座にプロビジョニング
WaitForFirstConsumer	Podがスケジュールされるまで遅延（同じゾーンを確保）

4. PVCを使用するPod

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: data-volume
      mountPath: /var/data
  volumes:
  - name: data-volume
    persistentVolumeClaim:
      claimName: pvc-data    # PVC名を参照

5. チートシート

タスク	コマンド
PV一覧	`kubectl get pv`
PVC一覧	`kubectl get pvc -n NAMESPACE`
PVC状態	`kubectl describe pvc NAME`
StorageClass一覧	`kubectl get storageclass`
PVC拡張	PVCのspec.resources.requests.storageを編集（SCが許可している場合）

6. 練習問題

Q1：PVCが「Pending」状態のままです。10GiのPVが存在します。PVCは5GiのReadWriteManyを要求していますが、PVはReadWriteOnceのみサポートしています。何が起きますか？

A) PVCはPVにバインドされ、RWOを使用する
B) PVCはPendingのまま — 要求されたアクセスモードに一致するPVがない ✓
C) KubernetesがPVのアクセスモードを自動変換する
D) PVCを使用するPodは起動するが書き込みできない

解説：PVCバインドには全条件の一致が必要: ストレージサイズ（PV >= PVC）、アクセスモード、storageClass、volumeMode。PVがRWOのみでPVCがRWXを要求している場合、バインドされません。

Q2：PVにバインドされているPVCが削除されました。PVのreclaimPolicy: Retainです。PVの状態はどうなりますか？

A) PVが削除される
B) PVはAvailableに遷移し、再利用可能になる
C) PVはReleasedに遷移 — データは保持されるが自動的に再バインドできない ✓
D) PVはすぐに別のPVCにプロビジョニングされる

解説：Retainポリシーはpvとデータを保持します。PVはReleased状態になります。再利用するには、管理者が古いclaimRefを手動で削除します（kubectl patch pv myPV -p '{"spec":{"claimRef":null}}'）。

Q3：クラウド環境では、WaitForFirstConsumerのvolumeBindingModeがImmediateより推奨される理由は？

A) ストレージコストを削減するため
B) ボリュームがスケジュールされたPodと同じアベイラビリティゾーンでプロビジョニングされることを保証するため ✓
C) 複数のPodがボリュームを共有できるようにするため
D) Pod起動時間を短縮するため