28.5. ボリュームと要求の事前バインディング
PersistentVolumeClaim
をバインドする PersistentVolume
を正確に把握している場合、volumeName
フィールドを使用して PV を PVC に指定できます。この方法は、通常のマッチングおよびバインディングプロセスを省略します。PVC は volumeName
に指定される同じ名前を持つ PV にのみバインドできます。この名前を持つ PV が存在し、Available
の場合、PV と PVC は、PV が PVC のラベルセレクター、アクセスモードおよびリソース要求を満たすかどうかに関係なくバインドされます。
例28.1 volumeName のある Persistent Volume Claim (永続ボリューム要求、PVC) オブジェクト定義
apiVersion: "v1" kind: "PersistentVolumeClaim" metadata: name: "claim1" spec: accessModes: - "ReadWriteOnce" resources: requests: storage: "1Gi" volumeName: "pv0001"
claimRefs
を設定する機能は、説明されているユースケースにおける一時的な回避策です。ボリュームを要求できるユーザーを制限する長期的なソリューションは開発中です。
クラスター管理者は、ユーザーの代わりに claimRefs
を設定する前に セレクターとラベルによるボリュームのバインディング を設定することをまず検討する必要があります。
クラスター管理者が独自の要求に対してのみにボリュームを「予約」し、それ以外の要求がその独自の要求がボリュームにバインドされる前にバインドされないようにすることもできます。この場合、管理者は claimRef
フィールドを使用して PVC を PV に指定できます。PV は claimRef
で指定される同じ名前および namesapce を持つ PVC にのみバインドできます。PVC のアクセスモードおよびリソース要求の条件は、ラベルセレクターが無視される場合でも PV および PVC がバインドされるために満たされる必要があります。
claimRef での永続ボリュームオブジェクト定義
apiVersion: v1 kind: PersistentVolume metadata: name: pv0001 spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce nfs: path: /tmp server: 172.17.0.2 persistentVolumeReclaimPolicy: Recycle claimRef: name: claim1 namespace: default
volumeName
を PVC に指定しても、その PVC がバインドされる前に異なる PVC が指定された PV にバインドされることを防ぐ訳ではありません。要求は PV が Available
になるまで Pending
のままになります。
claimRef
を PV に指定しても、指定された PVC が異なる PV にバインドされることを防ぐ訳ではありません。PVC は通常のバインディングプロセスに基づいてバインドする別の PV を自由に選択できます。そのため、これらのシナリオを避け、要求が必要なボリュームにバインドされるようにするには、volumeName
および claimRef
の両方が指定される必要があります。
pv.kubernetes.io/bound-by-controller
アノテーションについて Bound
PV および PVC ペアを検査することにより、volumeName
および/または claimRef
の設定のマッチングおよびバインディングプロセスへの影響を確認できます。volumeName
および/または claimRef
を独自に設定した PV および PVC にはこのアノテーションがありませんが、通常の PV および PVC ではこれは "yes"
に設定されています。
PV の claimRef
が一部の PVC 名および namespace に設定されていて、PV が Retain
または Recycle
回収ポリシーに応じて回収されている場合、その claimRef
は PVC または namespace 全体が存在しなくなっても同じ PVC 名および namespace に設定されたままになります。