Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

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

27.1. 概要

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

注記

Installation and Configuration Guide』は、NFSGlusterFSCeph RBDOpenStack CinderAWS EBSGCE Persistent DiskiSCSI、および Fibre Channel を使用して、永続ストレージと共に OpenShift Container Platform クラスターをプロビジョニングする方法をクラスター管理者向けに説明しています。

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

27.2. ストレージの要求

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

Persistent Volume Claim (永続ボリューム要求、PVC) オブジェクト定義

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

27.3. ボリュームと要求のバインディング

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

27.4. Pod のボリュームとしての要求

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

要求を含む Pod の定義

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"

27.5. ボリュームと要求の事前バインディング

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

例27.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: Retain
  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 回収ポリシーに応じて回収されている場合、その claimRef は PVC または namespace 全体が存在しなくなっても同じ PVC 名および namespace に設定されたままになります。