第28章 永続ボリュームの使用

PersistentVolume オブジェクトは OpenShift Container Platform クラスターのストレージリソースです。ストレージは、クラスター管理者が PersistentVolume オブジェクトを GCE Persistent Disk、AWS Elastic Block Store (EBS) および NFS マウントなどのソースから作成することによってプロビジョニングできます。

ストレージは、リソースの要求 (claim) を指定することにより利用可能になります。ストレージリソースの要求は PersistentVolumeClaim オブジェクトを使用して実行できます。この要求 (claim) は、通常は要求する内容に一致するボリュームとペアになります。

ストレージの要求は、プロジェクトで PersistentVolumeClaim オブジェクトを作成して実行できます。

apiVersion: "v1"
kind: "PersistentVolumeClaim"
metadata:
  name: "claim1"
spec:
  accessModes:
    - "ReadWriteOnce"
  resources:
    requests:
      storage: "1Gi"
  volumeName: "pv0001"

PersistentVolume は固有のリソースです。PersistentVolumeClaim はストレージサイズなどの特定の属性を持つリソースの要求です。これら 2 者の間には、要求を利用可能なボリュームに一致させ、要求とボリュームをバインドするプロセスがあります。これにより、要求は Pod のボリュームとして使用できます。OpenShift Container Platform は要求をサポートするボリュームを検索し、これを Pod にマウントします。

CLI を使用してクエリーを実行し、要求またはボリュームがバインドされているかどうかを判別できます。

$ oc get pvc
NAME        LABELS    STATUS    VOLUME
claim1      map[]     Bound     pv0001

$ oc get pv
NAME                LABELS              CAPACITY            ACCESSMODES         STATUS    CLAIM
pv0001              map[]               5368709120          RWO                 Bound     yournamespace / claim1

PersistentVolumeClaim は Pod によってボリュームとして使用されます。OpenShift Container Platform は Pod と同じ namespace の指定された名前で要求を検索し、この要求を使用してこれに対応するマウントするボリュームを検索します。

apiVersion: "v1"
kind: "Pod"
metadata:
  name: "mypod"
  labels:
    name: "frontendhttp"
spec:
  containers:
    -
      name: "myfrontend"
      image: openshift/hello-openshift
      ports:
        -
          containerPort: 80
          name: "http-server"
      volumeMounts:
        -
          mountPath: "/var/www/html"
          name: "pvol"
  volumes:
    -
      name: "pvol"
      persistentVolumeClaim:
        claimName: "claim1"

PersistentVolumeClaim をバインドする PersistentVolume を正確に把握している場合、volumeName フィールドを使用して PV を PVC に指定できます。この方法は、通常のマッチングおよびバインディングプロセスを省略します。PVC は volumeName に指定される同じ名前を持つ PV にのみバインドできます。この名前を持つ PV が存在し、Available の場合、PV と PVC は、PV が PVC のラベルセレクター、アクセスモードおよびリソース要求を満たすかどうかに関係なくバインドされます。

apiVersion: "v1"
kind: "PersistentVolumeClaim"
metadata:
  name: "claim1"
spec:
  accessModes:
    - "ReadWriteOnce"
  resources:
    requests:
      storage: "1Gi"
  volumeName: "pv0001"

クラスター管理者が独自の要求に対してのみにボリュームを「予約」し、それ以外の要求がその独自の要求がボリュームにバインドされる前にバインドされないようにすることもできます。この場合、管理者は claimRef フィールドを使用して PVC を PV に指定できます。PV は claimRef で指定される同じ名前および namesapce を持つ PVC にのみバインドできます。PVC のアクセスモードおよびリソース要求の条件は、ラベルセレクターが無視される場合でも PV および PVC がバインドされるために満たされる必要があります。

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 に設定されたままになります。