こんにちは。今回は Kubernetes における 手動での PersistentVolume（PV）と PersistentVolumeClaim（PVC）のバインド と StorageClass の関係性 についてわかりやすく解説します。
🔍 PV と PVC のバインド時の storageClassName の扱い
- 手動で PV と PVC をバインドするときは、
storageClassNameを記載しなくても良い場合があります。 - ただし、
storageClassNameを書く場合は、PV と PVC の両方で同じ名前を指定する必要があります。
⚙️ デフォルト StorageClass が存在する場合の挙動
- クラスターにデフォルトの StorageClass がある場合、PVC が
storageClassNameを指定しなければ、
自動的にそのデフォルト StorageClass が提供する PV とバインドされます。 - 一方で、ストレージクラスが指定されていない「裸のPV」(storageClassなしのPV) は自動バインドされません。
- そのため、裸の PV を使う PVC は、
storageClassName: ""（空文字）を明示的に指定する必要があります。
📦 裸の PV とは？
-
裸の PV とは、
storageClassNameが設定されていない PV のことを指します。 - こうした PV は、動的プロビジョニングではなく、管理者が手動で作成・管理することが多いです。
🛠️ PV のホストパス設定例
- PV は例えば以下のように
hostPathを使ってホストのパスを指定できます。 - これは開発環境やテスト環境でよく使われます。
apiVersion: v1
kind: PersistentVolume
metadata:
name: example-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: /mnt/data
📝 まとめ
| 項目 | ポイント |
|---|---|
storageClassName の指定 |
PV と PVC で一致させるか、手動バインドなら省略可能 |
| デフォルト StorageClass | PVC が指定しなければ自動でデフォルト StorageClass の PV とバインドされる |
| 裸の PV |
storageClassName がない PV、PVC は storageClassName: "" を指定が必要 |
hostPath |
開発や検証で使うことが多い PV の一種 |
今回の内容が、Kubernetes の PV/PVC バインドと StorageClass の理解に役立てば幸いです。
質問や補足があれば、ぜひコメントしてくださいね 😊