サポートコンソール開発者トライアルの開始お問い合わせ

第25章 永続ストレージの例

25.1. 概要

以下のセクションでは、一般的なストレージのユースケースを定義するための総合的なな手順について詳しく説明します。以下の例では、永続ボリュームとそのセキュリティーの管理だけでなく、システムのユーザーがボリュームに対する要求を行う方法についても取り上げます。

25.2. 2 つの Persistent Volume Claim (永続ボリューム要求) 間での NFS マウントの共有

25.2.1. 概要

以下のユースケースでは、クラスター管理者が 2 つの別々のコンテナーで共有ストレージを利用しようとしている場合に、その解決策を設定する方法について説明します。ここでは NFS の使用例を取り上げていますが、GlusterFS など他の共有ストレージタイプにも簡単に応用できます。また、この例では共有ストレージに関連した Pod のセキュリティーの設定についても説明します。

NFS を使用した永続ストレージでは、永続ボリューム (PV)、Persistent Volume Claim (永続ボリューム要求、PVC)、永続ストレージとしての NFS の使用について説明しています。このトピックでは既存の NFS クラスターと OpenShift Container Platform 永続ストアの使用について詳しく説明しますが、既存の NFS サーバーおよびエクスポートが OpenShift Container Platform インフラストラクチャーに存在することを前提とします。

注記

oc コマンドはすべて OpenShift Container Platform のマスターホストで実行されます。

25.2.2. 永続ボリュームの作成

PV オブジェクトを OpenShift Container Platform で作成する前に、永続ボリューム (PV) ファイルを以下のように定義します。

例25.1 NFS を使用した永続ボリュームオブジェクトの定義

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv 1
spec:
  capacity:
    storage: 1Gi 2
  accessModes:
    - ReadWriteMany 3
  persistentVolumeReclaimPolicy: Retain 4
  nfs: 5
    path: /opt/nfs 6
    server: nfs.f22 7
    readOnly: false
1
PV の名前。Pod 定義で参照されたり、各種の oc ボリュームコマンドで表示されたりします。
2
このボリュームに割り当てられるストレージの量。
3
accessModes は、PV と PVC を一致させるためのラベルとして使用されます。現時点で、これらはいずれの形態のアクセス制御も定義しません。
4
ボリューム回収ポリシー Retain は、ボリュームにアクセスする Pod が終了した後にもボリュームが維持されることを示します。
5
使用するボリュームタイプを定義します。この例では NFS プラグインを定義しています。
6
NFS マウントパスです。
7
NFS サーバーです。IP アドレスで指定することもできます。

PV の定義を nfs-pv.yaml などのファイルに保存し、以下のように永続ボリュームを作成します。 

# oc create -f nfs-pv.yaml
persistentvolume "nfs-pv" created

永続ボリュームが作成されたことを確認します。 

# oc get pv
NAME         LABELS    CAPACITY   ACCESSMODES   STATUS      CLAIM     REASON    AGE
nfs-pv       <none>    1Gi        RWX           Available                       37s

25.2.3. Persistent Volume Claim (永続ボリューム要求) の作成

Persistent Volume Claim (永続ボリューム要求、PVC) では、必要なアクセスモードとストレージ容量を指定します。現時点では、これら 2 つの属性のみに基づいて PVC が 1 つの PV にバインドされます。PV が PVC にバインドされると、その PV は基本的に当該 PVC のプロジェクトに結び付けられ、別の PVC にバインドすることはできません。PV と PVC には 1 対 1 のマッピングが存在します。ただし、同じプロジェクト内の複数の Pod が同じ PVC を使用することは可能です。以下の例ではそのユースケースを取り上げています。

例25.2 PVC オブジェクト定義

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc  1
spec:
  accessModes:
  - ReadWriteMany      2
  resources:
     requests:
       storage: 1Gi    3
1
この要求名は、volumes セクションで Pod によって参照されます。
2
PV についての先の説明にあるように、accessModes はアクセスを実施するものではなく、PV と PVC を一致させるためのラベルとして機能します。
3
この要求は、1Gi 以上の容量がある PV を検索します。

PVC の定義を nfs-pvc.yaml などのファイルに保存し、以下のように PVC を作成します。 

# oc create -f nfs-pvc.yaml
persistentvolumeclaim "nfs-pvc" created

PVC が作成されていて、予想される PV にバインドされていることを確認します。 

# oc get pvc
NAME            LABELS    STATUS    VOLUME       CAPACITY   ACCESSMODES   AGE
nfs-pvc         <none>    Bound     nfs-pv       1Gi        RWX           24s
                                    1
1
要求の nfs-pvc が nfs-pv PV にバインドされています。

25.2.4. NFS ボリュームアクセスの確保

NFS サーバー内のノードへのアクセスが必要です。このノードで、以下のように NFS エクスポートのマウントを確認します。 

[root@nfs nfs]# ls -lZ /opt/nfs/
total 8
-rw-r--r--. 1 root 100003  system_u:object_r:usr_t:s0     10 Oct 12 23:27 test2b
              1
                     2
1
所有者の ID は 0 です。
2
グループの ID は 100003 です。

NFS マウントにアクセスするためには、コンテナーが SELinux ラベルを一致する必要があり、UID を 0 にして実行するか、または補助グループ範囲内の 100003 に指定して実行します。NFS マウントのグループ (後の Pod 定義で定義される) に一致させることでボリュームにアクセスできるようにします。

デフォルトでは、SELinux では Pod からリモートの NFS サーバーへの書き込みは許可されません。SELinux を各ノードで有効にした状態で NFS ボリュームへの書き込みを有効にするには、以下のコマンドを実行します。 

# setsebool -P virt_use_nfs on

25.2.5. Pod の作成

Pod 定義ファイルまたはテンプレートファイルを使用して Pod を定義することができます。以下は、1 つのコンテナーを作成して NFS ボリュームを読み書きアクセス用にマウントする Pod 仕様です。

例25.3 Pod オブジェクトの定義

apiVersion: v1
kind: Pod
metadata:
  name: hello-openshift-nfs-pod 1
  labels:
    name: hello-openshift-nfs-pod
spec:
  containers:
    - name: hello-openshift-nfs-pod
      image: openshift/hello-openshift 2
      ports:
        - name: web
          containerPort: 80
      volumeMounts:
        - name: nfsvol 3
          mountPath: /usr/share/nginx/html 4
  securityContext:
      supplementalGroups: [100003] 5
      privileged: false
  volumes:
    - name: nfsvol
      persistentVolumeClaim:
        claimName: nfs-pvc 6
1
oc get pod によって表示されるこの Pod の名前。
2
この Pod が実行するイメージ。
3
ボリュームの名前。この名前は containers セクションと volumes セクションの両方で同じにする必要があります。
4
コンテナーで表示されるマウントパス。
5
コンテナーに割り当てるグループ ID。
6
先の手順で作成した PVC。

Pod 定義を nfs.yaml などのファイルに保存し、以下のように Pod を作成します。 

# oc create -f nfs.yaml
pod "hello-openshift-nfs-pod" created

Pod が作成されていることを確認します。 

# oc get pods
NAME                          READY     STATUS    RESTARTS   AGE
hello-openshift-nfs-pod       1/1       Running   0          4s

詳細は oc describe pod コマンドで以下のように表示されます。 

[root@ose70 nfs]# oc describe pod hello-openshift-nfs-pod
Name:				hello-openshift-nfs-pod
Namespace:			default 1
Image(s):			fedora/S3
Node:				ose70.rh7/192.168.234.148 2
Start Time:			Mon, 21 Mar 2016 09:59:47 -0400
Labels:				name=hello-openshift-nfs-pod
Status:				Running
Reason:
Message:
IP:				10.1.0.4
Replication Controllers:	<none>
Containers:
  hello-openshift-nfs-pod:
    Container ID:	docker://a3292104d6c28d9cf49f440b2967a0fc5583540fc3b062db598557b93893bc6f
    Image:		fedora/S3
    Image ID:		docker://403d268c640894cbd76d84a1de3995d2549a93af51c8e16e89842e4c3ed6a00a
    QoS Tier:
      cpu:		BestEffort
      memory:		BestEffort
    State:		Running
      Started:		Mon, 21 Mar 2016 09:59:49 -0400
    Ready:		True
    Restart Count:	0
    Environment Variables:
Conditions:
  Type		Status
  Ready 	True
Volumes:
  nfsvol:
    Type:	PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:	nfs-pvc 3
    ReadOnly:	false
  default-token-a06zb:
    Type:	Secret (a secret that should populate this volume)
    SecretName:	default-token-a06zb
Events: 4
  FirstSeen	LastSeen	Count	From			SubobjectPath				                      Reason		Message
  ─────────	────────	─────	────			─────────────				                      ──────		───────
  4m		4m		1	{scheduler }							                                      Scheduled	Successfully assigned hello-openshift-nfs-pod to ose70.rh7
  4m		4m		1	{kubelet ose70.rh7}	implicitly required container POD	          Pulled		Container image "openshift3/ose-pod:v3.1.0.4" already present on machine
  4m		4m		1	{kubelet ose70.rh7}	implicitly required container POD	          Created		Created with docker id 866a37108041
  4m		4m		1	{kubelet ose70.rh7}	implicitly required container POD	          Started		Started with docker id 866a37108041
  4m		4m		1	{kubelet ose70.rh7}	spec.containers{hello-openshift-nfs-pod}		Pulled		Container image "fedora/S3" already present on machine
  4m		4m		1	{kubelet ose70.rh7}	spec.containers{hello-openshift-nfs-pod}		Created		Created with docker id a3292104d6c2
  4m		4m		1	{kubelet ose70.rh7}	spec.containers{hello-openshift-nfs-pod}		Started		Started with docker id a3292104d6c2
1
プロジェクト (namespace) 名。
2
Pod を実行している OpenShift Container Platform ノードの IP アドレス。
3
Pod で使用される PVC 名。
4
Pod の起動と NFS ボリュームのマウントをもたらすイベントの一覧。ボリュームをマウントできない場合、コンテナーは正常に起動しません。

oc get pod <name> -o yaml コマンドでは、Pod の承認に使用される SCC や Pod のユーザー ID とグループ ID、SELinux ラベルなどの内部情報がさらに表示されます。 

[root@ose70 nfs]# oc get pod hello-openshift-nfs-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    openshift.io/scc: restricted 1
  creationTimestamp: 2016-03-21T13:59:47Z
  labels:
    name: hello-openshift-nfs-pod
  name: hello-openshift-nfs-pod
  namespace: default 2
  resourceVersion: "2814411"
  selflink: /api/v1/namespaces/default/pods/hello-openshift-nfs-pod
  uid: 2c22d2ea-ef6d-11e5-adc7-000c2900f1e3
spec:
  containers:
  - image: fedora/S3
    imagePullPolicy: IfNotPresent
    name: hello-openshift-nfs-pod
    ports:
    - containerPort: 80
      name: web
      protocol: TCP
    resources: {}
    securityContext:
      privileged: false
    terminationMessagePath: /dev/termination-log
    volumeMounts:
    - mountPath: /usr/share/S3/html
      name: nfsvol
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-a06zb
      readOnly: true
  dnsPolicy: ClusterFirst
  host: ose70.rh7
  imagePullSecrets:
  - name: default-dockercfg-xvdew
  nodeName: ose70.rh7
  restartPolicy: Always
  securityContext:
    supplementalGroups:
    - 100003 3
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  volumes:
  - name: nfsvol
    persistentVolumeClaim:
      claimName: nfs-pvc 4
  - name: default-token-a06zb
    secret:
      secretName: default-token-a06zb
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: 2016-03-21T13:59:49Z
    status: "True"
    type: Ready
  containerStatuses:
  - containerID: docker://a3292104d6c28d9cf49f440b2967a0fc5583540fc3b062db598557b93893bc6f
    image: fedora/S3
    imageID: docker://403d268c640894cbd76d84a1de3995d2549a93af51c8e16e89842e4c3ed6a00a
    lastState: {}
    name: hello-openshift-nfs-pod
    ready: true
    restartCount: 0
    state:
      running:
        startedAt: 2016-03-21T13:59:49Z
  hostIP: 192.168.234.148
  phase: Running
  podIP: 10.1.0.4
  startTime: 2016-03-21T13:59:47Z
1
Pod が使用する SCC。
2
プロジェクト (namespace) 名。
3
Pod の補助グループ ID (すべてのコンテナー)。
4
Pod で使用される PVC 名。

25.2.6. 同じ PVC を参照する追加 Pod の作成

以下の Pod 定義 (同じ namespace で作成されている) では別のコンテナーを使用しています。ただし、以下の volumes セクションで要求名を指定することで、同じバッキングストレージを使用できます。

例25.4 Pod オブジェクトの定義

apiVersion: v1
kind: Pod
metadata:
  name: busybox-nfs-pod 1
  labels:
    name: busybox-nfs-pod
spec:
  containers:
  - name: busybox-nfs-pod
    image: busybox 2
    command: ["sleep", "60000"]
    volumeMounts:
    - name: nfsvol-2 3
      mountPath: /usr/share/busybox  4
      readOnly: false
  securityContext:
    supplementalGroups: [100003] 5
    privileged: false
  volumes:
  - name: nfsvol-2
    persistentVolumeClaim:
      claimName: nfs-pvc 6
1
oc get pod によって表示されるこの Pod の名前。
2
この Pod が実行するイメージ。
3
ボリュームの名前。この名前は containers セクションと volumes セクションの両方で同じにする必要があります。
4
コンテナーで表示されるマウントパス。
5
コンテナーに割り当てるグループ ID。
6
先に作成されており、別のコンテナーでも使用されている PVC。

Pod 定義を nfs-2.yaml などのファイルに保存し、以下のように Pod を作成します。 

# oc create -f nfs-2.yaml
pod "busybox-nfs-pod" created

Pod が作成されていることを確認します。 

# oc get pods
NAME                READY     STATUS    RESTARTS   AGE
busybox-nfs-pod     1/1       Running   0          3s

詳細は oc describe pod コマンドで以下のように表示されます。 

[root@ose70 nfs]# oc describe pod busybox-nfs-pod
Name:				busybox-nfs-pod
Namespace:			default
Image(s):			busybox
Node:				ose70.rh7/192.168.234.148
Start Time:			Mon, 21 Mar 2016 10:19:46 -0400
Labels:				name=busybox-nfs-pod
Status:				Running
Reason:
Message:
IP:				10.1.0.5
Replication Controllers:	<none>
Containers:
  busybox-nfs-pod:
    Container ID:	docker://346d432e5a4824ebf5a47fceb4247e0568ecc64eadcc160e9bab481aecfb0594
    Image:		busybox
    Image ID:		docker://17583c7dd0dae6244203b8029733bdb7d17fccbb2b5d93e2b24cf48b8bfd06e2
    QoS Tier:
      cpu:		BestEffort
      memory:		BestEffort
    State:		Running
      Started:		Mon, 21 Mar 2016 10:19:48 -0400
    Ready:		True
    Restart Count:	0
    Environment Variables:
Conditions:
  Type		Status
  Ready 	True
Volumes:
  nfsvol-2:
    Type:	PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:	nfs-pvc
    ReadOnly:	false
  default-token-32d2z:
    Type:	Secret (a secret that should populate this volume)
    SecretName:	default-token-32d2z
Events:
  FirstSeen	LastSeen	Count	From			SubobjectPath				Reason		Message
  ─────────	────────	─────	────			─────────────				──────		───────
  4m		4m		1	{scheduler }							Scheduled	Successfully assigned busybox-nfs-pod to ose70.rh7
  4m		4m		1	{kubelet ose70.rh7}	implicitly required container POD	Pulled		Container image "openshift3/ose-pod:v3.1.0.4" already present on machine
  4m		4m		1	{kubelet ose70.rh7}	implicitly required container POD	Created		Created with docker id 249b7d7519b1
  4m		4m		1	{kubelet ose70.rh7}	implicitly required container POD	Started		Started with docker id 249b7d7519b1
  4m		4m		1	{kubelet ose70.rh7}	spec.containers{busybox-nfs-pod}	Pulled		Container image "busybox" already present on machine
  4m		4m		1	{kubelet ose70.rh7}	spec.containers{busybox-nfs-pod}	Created		Created with docker id 346d432e5a48
  4m		4m		1	{kubelet ose70.rh7}	spec.containers{busybox-nfs-pod}	Started		Started with docker id 346d432e5a48

ここから分かるように、いずれのコンテナーでも、バックエンドの同じ NFS マウントに割り当てられた同じストレージ要求を使用しています。

25.3. Ceph RBD を使用した詳細例

25.3.1. 概要

このトピックでは、既存の Ceph クラスターを OpenShift Container Platform の永続ストアとして使用する詳細な例を紹介します。ここでは、作業用の Ceph クラスターがすでに設定されていることを前提とします。まだ設定されていない場合は、Red Hat Ceph Storage の概要について参照してください。

Ceph RADOS ブロックデバイスを使用した永続ストレージでは、永続ボリューム (PV)、Persistent Volume Claim (永続ボリューム要求、PVC)、永続ストレージとしての Ceph RBD の使用について説明しています。

注記

oc …​ コマンドはすべて OpenShift Container Platform のマスターホストで実行されます。

25.3.2. ceph-common パッケージのインストール

ceph-common ライブラリーは、すべてのスケジュール可能な OpenShift Container Platform ノードにインストールする必要があります。

注記

OpenShift Container Platform のオールインワンホストは、Pod のワークロードを実行するために使用されることは多くありません。したがって、これはスケジュール可能なノードに含まれません。 

# yum install -y ceph-common

25.3.3. Ceph シークレットの作成

ceph auth get-key コマンドを Ceph の MON ノードで実行すると、client.admin ユーザーのキー値が以下のように表示されます。

例25.5 Ceph のシークレットの定義

apiVersion: v1
kind: Secret
metadata:
  name: ceph-secret
data:
  key: QVFBOFF2SlZheUJQRVJBQWgvS2cwT1laQUhPQno3akZwekxxdGc9PQ== 1
1
この base64 キーは、Ceph の MON ノードの 1 つで ceph auth get-key client.admin | base64 コマンドを使用して生成されたものであり、出力をコピーし、これをシークレットキーの値として貼り付けています。

シークレット定義を ceph-secret.yaml などのファイルに保存し、シークレットを作成します。 

$ oc create -f ceph-secret.yaml
secret "ceph-secret" created

シークレットが作成されたことを確認します。 

# oc get secret ceph-secret
NAME          TYPE      DATA      AGE
ceph-secret   Opaque    1         23d

25.3.4. 永続ボリュームの作成

次に、OpenShift Container Platform で PV オブジェクトを作成する前に、永続ボリュームファイルを定義します。

例25.6 Ceph RBD を使用した永続ボリュームオブジェクトの定義

apiVersion: v1
kind: PersistentVolume
metadata:
  name: ceph-pv     1
spec:
  capacity:
    storage: 2Gi    2
  accessModes:
    - ReadWriteOnce 3
  rbd:              4
    monitors:       5
      - 192.168.122.133:6789
    pool: rbd
    image: ceph-image
    user: admin
    secretRef:
      name: ceph-secret 6
    fsType: ext4        7
    readOnly: false
  persistentVolumeReclaimPolicy: Recycle
1
PV の名前。Pod 定義で参照されたり、各種の oc ボリュームコマンドで表示されたりします。
2
このボリュームに割り当てられるストレージの量。
3
accessModes は、PV と PVC を一致させるためのラベルとして使用します。現時点で、これらはいずれの形態のアクセス制御も定義しません。ブロックストレージはすべて、単一ユーザーに対して定義されます (非共有ストレージ)。
4
使用するボリュームタイプを定義します。この例では rbd プラグインを定義しています。
5
Ceph モニターの IP アドレスとポートの配列です。
6
先に定義した Ceph のシークレットです。OpenShift Container Platform から Ceph サーバーへのセキュアな接続を作成するのに使用します。
7
Ceph RBD ブロックデバイスにマウントされるファイルシステムタイプです。

PV の定義を ceph-pv.yaml などのファイルに保存し、永続ボリュームを作成します。 

# oc create -f ceph-pv.yaml
persistentvolume "ceph-pv" created

永続ボリュームが作成されたことを確認します。 

# oc get pv
NAME                     LABELS    CAPACITY     ACCESSMODES   STATUS      CLAIM     REASON    AGE
ceph-pv                  <none>    2147483648   RWO           Available                       2s

25.3.5. Persistent Volume Claim (永続ボリューム要求) の作成

Persistent Volume Claim (永続ボリューム要求、PVC) では、必要なアクセスモードとストレージ容量を指定します。現時点では、これら 2 つの属性のみに基づいて PVC が 1 つの PV にバインドされます。PV が PVC にバインドされると、その PV は基本的に当該 PVC のプロジェクトに結び付けられ、別の PVC にバインドすることはできません。PV と PVC には 1 対 1 のマッピングが存在します。ただし、同じプロジェクト内の複数の Pod が同じ PVC を使用することは可能です。

例25.7 PVC オブジェクト定義

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: ceph-claim
spec:
  accessModes:     1
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi 2
1
PV についての先の説明にあるように、accessModes はアクセスを実施するものではなく、PV と PVC を一致させるためのラベルとして機能します。
2
この要求は 2Gi 以上の容量を提供する PV を探します。

PVC の定義を ceph-claim.yaml などのファイルに保存し、以下のように PVC を作成します。 

# oc create -f ceph-claim.yaml
persistentvolumeclaim "ceph-claim" created

#and verify the PVC was created and bound to the expected PV:
# oc get pvc
NAME         LABELS    STATUS    VOLUME    CAPACITY   ACCESSMODES   AGE
ceph-claim   <none>    Bound     ceph-pv   1Gi        RWX           21s
                                 1
1
要求が ceph-pv PV にバインドされています。

25.3.6. Pod の作成

Pod 定義ファイルまたはテンプレートファイルを使用して Pod を定義できます。以下は、1 つのコンテナーを作成し、Ceph RBD ボリュームを読み書きアクセス用にマウントする Pod 仕様です。

例25.8 Pod オブジェクトの定義

apiVersion: v1
kind: Pod
metadata:
  name: ceph-pod1           1
spec:
  containers:
  - name: ceph-busybox
    image: busybox          2
    command: ["sleep", "60000"]
    volumeMounts:
    - name: ceph-vol1       3
      mountPath: /usr/share/busybox 4
      readOnly: false
  volumes:
  - name: ceph-vol1         5
    persistentVolumeClaim:
      claimName: ceph-claim 6
1
oc get pod によって表示されるこの Pod の名前。
2
この Pod が実行するイメージ。この例では、busybox に sleep の実行を指示しています。
3 5
ボリュームの名前。この名前は containers セクションと volumes セクションの両方で同じにする必要があります。
4
コンテナーで表示されるマウントパス。
6
Ceph RBD クラスターにバインドされる PVC。

Pod 定義を ceph-pod1.yaml などのファイルに保存し、以下のように Pod を作成します。 

# oc create -f ceph-pod1.yaml
pod "ceph-pod1" created

#verify pod was created
# oc get pod
NAME        READY     STATUS    RESTARTS   AGE
ceph-pod1   1/1       Running   0          2m
                      1
1
しばらくすると、Pod が Running 状態になります。

25.3.7. グループ ID と所有者 ID の定義 (オプション)

Ceph RBD などのブロックストレージを使用する場合、物理ブロックストレージは Pod の管理対象になります。Pod で定義されたグループ ID は、コンテナー内の Ceph RBD マウントと実際のストレージ自体の両方のグループ ID になります。そのため、通常はグループ ID を Pod 仕様に定義する必要はありません。ただし、グループ ID が必要な場合は、以下の Pod 定義の例に示すように fsGroup を使用して定義することができます。

例25.9 グループ ID の Pod 定義

...
spec:
  containers:
    - name:
    ...
  securityContext: 1
    fsGroup: 7777  2
...
1
securityContext は特定のコンテナーの下位ではなく、この Pod レベルで定義します。
2
Pod 内のコンテナーはすべて同じ fsGroup ID になります。

25.3.8. ceph-user-secret をプロジェクトのデフォルトとして設定する方法

すべてのプロジェクトで永続ストレージを使用できるようにする場合は、デフォルトのプロジェクトテンプレートを修正する必要があります。デフォルトプロジェクトテンプレートの修正についての詳細は、「デフォルトプロジェクトテンプレートの修正」を参照してください。これをデフォルトプロジェクトテンプレートに追加することで、プロジェクトの作成アクセス権を持つすべてのユーザーが Ceph クラスターにアクセスできるようになります。

例25.10 デフォルトプロジェクトの例

...
apiVersion: v1
kind: Template
metadata:
  creationTimestamp: null
  name: project-request
objects:
- apiVersion: v1
  kind: Project
  metadata:
    annotations:
      openshift.io/description: ${PROJECT_DESCRIPTION}
      openshift.io/display-name: ${PROJECT_DISPLAYNAME}
      openshift.io/requester: ${PROJECT_REQUESTING_USER}
    creationTimestamp: null
    name: ${PROJECT_NAME}
  spec: {}
  status: {}
- apiVersion: v1
  kind: Secret
  metadata:
    name: ceph-user-secret
  data:
    key: yoursupersecretbase64keygoeshere 1
  type:
    kubernetes.io/rbd
...
1
各自のスーパーシークレット Ceph ユーザーキーをここに base64 形式で記述します。「Ceph のシークレットの作成」を参照してください。

25.4. 動的プロビジョニングでの Ceph RBD の使用

25.4.1. 概要

このトピックでは、既存の Ceph クラスターを OpenShift Container Platform の永続ストレージとして使用する詳細な例を紹介します。ここでは、作業用の Ceph クラスターがすでに設定されていることを前提とします。まだ設定されていない場合は、Red Hat Ceph Storage の概要について参照してください。

「Ceph RADOS ブロックデバイスを使用した永続ストレージ」では、永続ボリューム (PV)、Persistent Volume Claim (永続ボリューム要求、PVC)、永続ストレージとしての Ceph RADOS ブロックデバイス (RBD) の使用方法について説明しています。

注記
  • OpenShift Container Platform のマスターホストで、全 oc コマンドを実行します。
  • OpenShift Container Platform のオールインワンホストは、Pod のワークロードを実行するために使用されることは多くありません。したがって、これはスケジュール可能なノードに含まれません。

25.4.2. 動的ボリューム用プールの作成

  1. 最新の ceph-common パッケージをインストールします。 

    yum install -y ceph-common
    注記

    ceph-common ライブラリーは、all schedulable OpenShift Container Platform ノードにインストールする必要があります。

  2. 管理者または MON ノードによって、以下のように動的ボリューム用の新規プールが作成されます。 

    $ ceph osd pool create kube 1024
$ ceph auth get-or-create client.kube mon 'allow r, allow command "osd blacklist"' osd 'allow class-read object_prefix rbd_children, allow rwx pool=kube' -o ceph.client.kube.keyring
    注記

    RBD のデフォルトプールを使用することも可能ですが、このオプションは推奨されません。

25.4.3. 動的な永続ストレージでの既存の Ceph クラスターの使用

動的な永続ストレージに既存の Ceph クラスターを使用するには、以下を実行します。

  1. client.admin 向けに base64 でエンコードされたキーを作成します。 

    $ ceph auth get client.admin

    Ceph シークレット定義例

    apiVersion: v1
kind: Secret
metadata:
  name: ceph-secret
  namespace: kube-system
data:
  key: QVFBOFF2SlZheUJQRVJBQWgvS2cwT1laQUhPQno3akZwekxxdGc9PQ== 1
type: kubernetes.io/rbd 2

    1
    この base64 キーは、Ceph の MON ノードの 1 つで ceph auth get-key client.admin | base64 コマンドを使用して生成されたものであり、出力をコピーし、これをシークレットキーの値として貼り付けています。
    2
    この値は、Ceph RBD を動的プロビジョニングで機能させるために必要です。

  2. client.admin 用に Ceph シークレットを作成します。 

    $ oc create -f ceph-secret.yaml
secret "ceph-secret" created

  3. シークレットが作成されたことを確認します。 

    $ oc get secret ceph-secret
NAME          TYPE                DATA      AGE
ceph-secret   kubernetes.io/rbd   1         5d

  4. ストレージクラスを作成します。 

    $ oc create -f ceph-storageclass.yaml
storageclass "dynamic" created

    Ceph ストレージクラスの例

    apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
  name: dynamic
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/rbd
parameters:
  monitors: 192.168.1.11:6789,192.168.1.12:6789,192.168.1.13:6789 1
  adminId: admin 2
  adminSecretName: ceph-secret 3
  adminSecretNamespace: kube-system 4
  pool: kube  5
  userId: kube  6
  userSecretName: ceph-user-secret 7

    1
    Ceph が監視する IP アドレスのコンマ区切りの一覧。この値は必須です。
    2
    Ceph クライアント ID。プール内にイメージを作成する権限があります。デフォルトは admin です。
    3
    adminId のシークレット名。この値は必須です。設定するシークレットには kubernetes.io/rbd が含まれる必要があります。
    4
    adminSecret の namespace。デフォルトは default です。
    5
    Ceph RBD プール。デフォルトは rbd ですが、この値は推奨されません。
    6
    Ceph RBD イメージのマッピングに使用される Ceph クライアント ID。デフォルトは adminId のシークレット名と同じです。
    7
    Ceph RBD イメージをマッピングするための userId の Ceph シークレット名。PVC と同じ namespace に存在する必要があります。Ceph シークレットが新規プロジェクトのデフォルトとして設定されていない限り、このパラメーターの値を指定する必要があります。

  5. ストレージクラスが作成されたことを確認します。 

    $ oc get storageclasses
NAME                TYPE
dynamic (default)   kubernetes.io/rbd

  6. PVC オブジェクト定義を作成します。

    PVC オブジェクト定義例

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: ceph-claim-dynamic
spec:
  accessModes:  1
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi 2

    1
    accessModes はアクセス権としての効果はなく、代わりに PV と PVC を照合するラベルとして機能します。
    2
    この要求は 2Gi 以上の容量を提供する PV を探します。

  7. PVC を作成します。 

    $ oc create -f ceph-pvc.yaml
persistentvolumeclaim "ceph-claim-dynamic" created

  8. PVC が作成されていて、予想される PV にバインドされていることを確認します。 

    $ oc get pvc
NAME        STATUS  VOLUME                                   CAPACITY ACCESSMODES  AGE
ceph-claim  Bound   pvc-f548d663-3cac-11e7-9937-0024e8650c7a 2Gi      RWO          1m

  9. Pod オブジェクト定義を以下のように作成します。

    Pod オブジェクトの定義例

    apiVersion: v1
kind: Pod
metadata:
  name: ceph-pod1 1
spec:
  containers:
  - name: ceph-busybox
    image: busybox 2
    command: ["sleep", "60000"]
    volumeMounts:
    - name: ceph-vol1 3
      mountPath: /usr/share/busybox 4
      readOnly: false
  volumes:
  - name: ceph-vol1
    persistentVolumeClaim:
      claimName: ceph-claim-dynamic 5

    1
    oc get pod によって表示されるこの Pod の名前。
    2
    この Pod が実行するイメージ。この例では、busybox は sleep に設定されています。
    3
    ボリュームの名前。この名前は containers セクションと volumes セクションの両方で同じにする必要があります。
    4
    コンテナーでのマウントパス。
    5
    Ceph RBD クラスターにバインドされる PVC。

  10. Pod を作成します。 

    $ oc create -f ceph-pod1.yaml
pod "ceph-pod1" created

  11. Pod が作成されていることを確認します。 

    $ oc get pod
NAME        READY     STATUS   RESTARTS   AGE
ceph-pod1   1/1       Running  0          2m

しばらくすると、Pod のステータスが Running に変わります。

25.4.4. ceph-user-secret をプロジェクトのデフォルトとして設定する方法

全プロジェクトで永続ストレージを使用できるようにするには、デフォルトのプロジェクトテンプレートを変更する必要があります。これをデフォルトのプロジェクトテンプレートに追加すると、プロジェクト作成の権限があるユーザーはすべて Ceph クラスターにアクセスできるようになります。詳細情報は、「デフォルトのプロジェクトテンプレート変更」を参照してください。

デフォルトプロジェクトの例

...
apiVersion: v1
kind: Template
metadata:
  creationTimestamp: null
  name: project-request
objects:
- apiVersion: v1
  kind: Project
  metadata:
    annotations:
      openshift.io/description: ${PROJECT_DESCRIPTION}
      openshift.io/display-name: ${PROJECT_DISPLAYNAME}
      openshift.io/requester: ${PROJECT_REQUESTING_USER}
    creationTimestamp: null
    name: ${PROJECT_NAME}
  spec: {}
  status: {}
- apiVersion: v1
  kind: Secret
  metadata:
    name: ceph-user-secret
  data:
    key: QVFCbEV4OVpmaGJtQ0JBQW55d2Z0NHZtcS96cE42SW1JVUQvekE9PQ== 1
  type:
    kubernetes.io/rbd
...

1
base64 形式で Ceph のユーザーキーをここに配置します。

25.5. GlusterFS を使用する詳細例

25.5.1. 概要

このトピックでは、既存のコンバージドモード、インデペンデントモードまたはスタンドアロンの Red Hat Gluster Storage クラスターを OpenShift Container Platform の永続ストレージとして使用する詳細例を紹介します。ここでは作業用の Red Hat Gluster Storage クラスターがすでに設定されていることを前提とします。コンバージドモードまたはインデペンデントモードのインストールについてのヘルプは、「Red Hat Gluster Storage を使用する永続ストレージ」を参照してください。スタンドアロンの Red Hat Gluster Storage の場合については、『Red Hat Gluster Storage Administration Guide』を参照してください。

GlusterFS ボリュームを動的にプロビジョニングする方法の詳細例については、「GlusterFS を動的プロビジョニングに使用する詳細例」を参照してください。

注記

oc コマンドはすべて OpenShift Container Platform のマスターホストで実行されます。

25.5.2. 前提条件

GlusterFS ボリュームにアクセスするには、すべてのスケジュール可能なノードで mount.glusterfs コマンドを利用できる必要があります。RPM ベースのシステムの場合は、glusterfs-fuse パッケージがインストールされている必要があります。 

# yum install glusterfs-fuse

このパッケージはすべての RHEL システムにインストールされています。ただし、サーバーが x86_64 アーキテクチャーを使用する場合は Red Hat Gluster Storage の最新バージョンに更新することを推奨します。そのためには、以下の RPM リポジトリーを有効にする必要があります。 

# subscription-manager repos --enable=rh-gluster-3-client-for-rhel-7-server-rpms

glusterfs-fuse がノードにすでにインストールされている場合、最新バージョンがインストールされていることを確認します。 

# yum update glusterfs-fuse

デフォルトでは、SELinux は Pod からリモート Red Hat Gluster Storage サーバーへの書き込みを許可しません。SELinux が有効な状態で Red Hat Gluster Storage ボリュームへの書き込みを有効にするには、GlusterFS を実行する各ノードで以下のコマンドを実行します。 

$ sudo setsebool -P virt_sandbox_use_fusefs on 1
$ sudo setsebool -P virt_use_fusefs on
1
-P オプションを使用すると、再起動した後もブール値が永続化されます。
注記

virt_sandbox_use_fusefs ブール値は、docker-selinux パッケージによって定義されます。このブール値が定義されていないというエラーが表示される場合は、このパッケージがインストールされていることを確認してください。

注記

Atomic Host を使用している場合に、Atomic Host をアップグレードすると、SELinux のブール値が消去されるので、Atomic Host をアップグレードする場合には、これらのブール値を設定し直す必要があります。

25.5.3. 静的プロビジョニング

  1. 静的プロビジョニングを有効にするには、最初に GlusterFS ボリュームを作成します。gluster コマンドラインインターフェースを使用してこれを行う方法については、『Red Hat Gluster Storage Administration Guide』を参照してください。また、heketi-cli を使用してこれを行う方法については、heketi プロジェクトサイトを参照してください。この例では、ボリュームに myVol1 という名前を付けます。

  2. gluster-endpoints.yaml で以下のサービスとエンドポイントを定義します。 

    ---
apiVersion: v1
kind: Service
metadata:
  name: glusterfs-cluster 1
spec:
  ports:
  - port: 1
---
apiVersion: v1
kind: Endpoints
metadata:
  name: glusterfs-cluster 2
subsets:
  - addresses:
      - ip: 192.168.122.221 3
    ports:
      - port: 1 4
  - addresses:
      - ip: 192.168.122.222 5
    ports:
      - port: 1 6
  - addresses:
      - ip: 192.168.122.223 7
    ports:
      - port: 1 8
    1 2
    これらの名前は一致している必要があります。
    3 5 7
    ip の値には、Red Hat Gluster Storage サーバーのホスト名ではなく、実際の IP アドレスを指定する必要があります。
    4 6 8
    ポート番号は無視されます。

  3. OpenShift Container Platform マスターホストからサービスとエンドポイントを作成します。 

    $ oc create -f gluster-endpoints.yaml
service "glusterfs-cluster" created
endpoints "glusterfs-cluster" created

  4. サービスとエンドポイントが作成されたことを確認します。 

    $ oc get services
NAME                       CLUSTER_IP       EXTERNAL_IP   PORT(S)    SELECTOR        AGE
glusterfs-cluster          172.30.205.34    <none>        1/TCP      <none>          44s

$ oc get endpoints
NAME                ENDPOINTS                                               AGE
docker-registry     10.1.0.3:5000                                           4h
glusterfs-cluster   192.168.122.221:1,192.168.122.222:1,192.168.122.223:1   11s
kubernetes          172.16.35.3:8443                                        4d
    注記

    エンドポイントはプロジェクトごとに一意です。GlusterFS にアクセスする各プロジェクトには独自のエンドポイントが必要です。

  5. ボリュームにアクセスするには、ボリューム上のファイルシステムにアクセスできるユーザー ID (UID) またはグループ ID (GID) でコンテナーを実行する必要があります。この情報は以下の方法で取得できます。 

    $ mkdir -p /mnt/glusterfs/myVol1

$ mount -t glusterfs 192.168.122.221:/myVol1 /mnt/glusterfs/myVol1

$ ls -lnZ /mnt/glusterfs/
drwxrwx---. 592 590 system_u:object_r:fusefs_t:s0    myVol1 1 2
    1
    UID は 592 です。
    2
    GID は 590 です。

  6. gluster-pv.yaml で以下の PersistentVolume (PV) を定義します。 

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: gluster-default-volume 1
  annotations:
    pv.beta.kubernetes.io/gid: "590" 2
spec:
  capacity:
    storage: 2Gi 3
  accessModes: 4
    - ReadWriteMany
  glusterfs:
    endpoints: glusterfs-cluster 5
    path: myVol1 6
    readOnly: false
  persistentVolumeReclaimPolicy: Retain
    1
    ボリュームの名前です。
    2
    GlusterFS ボリュームのルートの GID です。
    3
    このボリュームに割り当てられるストレージの量。
    4
    accessModes は、PV と PVC を一致させるためのラベルとして使用します。現時点で、それらは現時点ではいずれの形式のアクセス制御も定義しません。
    5
    以前に作成されたエンドポイントリソースです。
    6
    アクセス対象の GlusterFS ボリュームです。

  7. OpenShift Container Platform マスターホストから PV を作成します。 

    $ oc create -f gluster-pv.yaml

  8. PV が作成されたことを確認します。 

    $ oc get pv
NAME                     LABELS    CAPACITY     ACCESSMODES   STATUS      CLAIM     REASON    AGE
gluster-default-volume   <none>    2147483648   RWX           Available                       2s

  9. gluster-claim.yaml で、新規 PV にバインドする PersistentVolumeClaim (PVC) を作成します。 

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gluster-claim  1
spec:
  accessModes:
  - ReadWriteMany      2
  resources:
     requests:
       storage: 1Gi    3
    1
    この要求名は、volumes セクションで Pod によって参照されます。
    2
    PV の accessModes に一致する必要があります。
    3
    この要求は、1Gi 以上の容量がある PV を検索します。

  10. OpenShift Container Platform マスターホストから PVC を作成します。 

    $ oc create -f gluster-claim.yaml

  11. PV と PVC がバインドされていることを確認します。 

    $ oc get pv
NAME         LABELS    CAPACITY   ACCESSMODES   STATUS      CLAIM          REASON    AGE
gluster-pv   <none>    1Gi        RWX           Available   gluster-claim            37s

$ oc get pvc
NAME            LABELS    STATUS    VOLUME       CAPACITY   ACCESSMODES   AGE
gluster-claim   <none>    Bound     gluster-pv   1Gi        RWX           24s
注記

PVC はプロジェクトごとに一意です。GlusterFS ボリュームにアクセスする各プロジェクトには独自の PVC が必要です。PV は単一のプロジェクトにバインドされないため、複数のプロジェクトにまたがる PVC が同じ PV を参照する場合があります。

25.5.4. ストレージの使用

ここまでの時点で、PVC にバインドされる GlusterFS ボリュームを動的に作成しましたので、この PVC を Pod で利用できるようになりました。

  1. Pod オブジェクト定義を以下のように作成します。 

    apiVersion: v1
kind: Pod
metadata:
  name: hello-openshift-pod
  labels:
    name: hello-openshift-pod
spec:
  containers:
  - name: hello-openshift-pod
    image: openshift/hello-openshift
    ports:
    - name: web
      containerPort: 80
    volumeMounts:
    - name: gluster-vol1
      mountPath: /usr/share/nginx/html
      readOnly: false
  volumes:
  - name: gluster-vol1
    persistentVolumeClaim:
      claimName: gluster1 1
    1
    先の手順で作成した PVC の名前。

  2. OpenShift Container Platform マスターホストから、以下のように Pod を作成します。 

    # oc create -f hello-openshift-pod.yaml
pod "hello-openshift-pod" created

  3. Pod を表示します。イメージがまだ存在していない場合はダウンロードする必要があるので、数分かかります。 

    # oc get pods -o wide
NAME                               READY     STATUS    RESTARTS   AGE       IP               NODE
hello-openshift-pod                          1/1       Running   0          9m        10.38.0.0        node1

  4. コンテナーへの oc exec を実行し、index.html ファイルを Pod の mountPath 定義内に作成します。 

    $ oc exec -ti hello-openshift-pod /bin/sh
$ cd /usr/share/nginx/html
$ echo 'Hello OpenShift!!!' > index.html
$ ls
index.html
$ exit

  5. ここで、Pod の URL に対して curl を実行します。 

    # curl http://10.38.0.0
Hello OpenShift!!!

  6. Pod を削除してから再作成し、これが出現するまで待機します。 

    # oc delete pod hello-openshift-pod
pod "hello-openshift-pod" deleted
# oc create -f hello-openshift-pod.yaml
pod "hello-openshift-pod" created
# oc get pods -o wide
NAME                               READY     STATUS    RESTARTS   AGE       IP               NODE
hello-openshift-pod                          1/1       Running   0          9m        10.37.0.0        node1

  7. もう一度 Pod に対して curl を実行します。データは前と同じになりますが、Pod の IP アドレスは変更されている可能性があることに注意してください。 

    # curl http://10.37.0.0
Hello OpenShift!!!

  8. 以下の操作をいずれかのノードで実行して、index.html ファイルが GlusterFS ストレージに書き込まれていることを確認します。 

    $ mount | grep heketi
/dev/mapper/VolGroup00-LogVol00 on /var/lib/heketi type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
/dev/mapper/vg_f92e09091f6b20ab12b02a2513e4ed90-brick_1e730a5462c352835055018e1874e578 on /var/lib/heketi/mounts/vg_f92e09091f6b20ab12b02a2513e4ed90/brick_1e730a5462c352835055018e1874e578 type xfs (rw,noatime,seclabel,nouuid,attr2,inode64,logbsize=256k,sunit=512,swidth=512,noquota)
/dev/mapper/vg_f92e09091f6b20ab12b02a2513e4ed90-brick_d8c06e606ff4cc29ccb9d018c73ee292 on /var/lib/heketi/mounts/vg_f92e09091f6b20ab12b02a2513e4ed90/brick_d8c06e606ff4cc29ccb9d018c73ee292 type xfs (rw,noatime,seclabel,nouuid,attr2,inode64,logbsize=256k,sunit=512,swidth=512,noquota)

$ cd /var/lib/heketi/mounts/vg_f92e09091f6b20ab12b02a2513e4ed90/brick_d8c06e606ff4cc29ccb9d018c73ee292/brick
$ ls
index.html
$ cat index.html
Hello OpenShift!!!

25.6. GlusterFS を動的プロビジョニングに使用する詳細例

25.6.1. 概要

このトピックでは、既存のコンバージドモード、インデペンデントモードまたはスタンドアロンの Red Hat Gluster Storage クラスターを OpenShift Container Platform の動的永続ストレージとして使用する詳細例を紹介します。ここでは作業用の Red Hat Gluster Storage クラスターがすでに設定されていることを前提とします。コンバージドモードまたはインデペンデントモードのインストールについてのヘルプは、「Red Hat Gluster Storage を使用する永続ストレージ」を参照してください。スタンドアロンの Red Hat Gluster Storage の場合については、『Red Hat Gluster Storage Administration Guide』を参照してください。

注記

oc コマンドはすべて OpenShift Container Platform のマスターホストで実行されます。

25.6.2. 前提条件

GlusterFS ボリュームにアクセスするには、すべてのスケジュール可能なノードで mount.glusterfs コマンドを利用できる必要があります。RPM ベースのシステムの場合は、glusterfs-fuse パッケージがインストールされている必要があります。 

# yum install glusterfs-fuse

このパッケージはすべての RHEL システムにインストールされています。ただし、サーバーが x86_64 アーキテクチャーを使用する場合は Red Hat Gluster Storage の最新バージョンに更新することを推奨します。そのためには、以下の RPM リポジトリーを有効にする必要があります。 

# subscription-manager repos --enable=rh-gluster-3-client-for-rhel-7-server-rpms

glusterfs-fuse がノードにすでにインストールされている場合、最新バージョンがインストールされていることを確認します。 

# yum update glusterfs-fuse

デフォルトでは、SELinux は Pod からリモート Red Hat Gluster Storage サーバーへの書き込みを許可しません。SELinux が有効な状態で Red Hat Gluster Storage ボリュームへの書き込みを有効にするには、GlusterFS を実行する各ノードで以下のコマンドを実行します。 

$ sudo setsebool -P virt_sandbox_use_fusefs on 1
$ sudo setsebool -P virt_use_fusefs on
1
-P オプションを使用すると、再起動した後もブール値が永続化されます。
注記

virt_sandbox_use_fusefs ブール値は、docker-selinux パッケージによって定義されます。このブール値が定義されていないというエラーが表示される場合は、このパッケージがインストールされていることを確認してください。

注記

Atomic Host を使用している場合に、Atomic Host をアップグレードすると、SELinux のブール値が消去されるので、Atomic Host をアップグレードする場合には、これらのブール値を設定し直す必要があります。

25.6.3. 動的プロビジョニング

  1. 動的プロビジョニングを有効にするには、最初に StorageClass オブジェクト定義を作成します。以下の定義は、OpenShift Container Platform でこの例を使用するために必要な最小要件に基づいています。その他のパラメーターと仕様定義については、「動的プロビジョニングとストレージクラスの作成」を参照してください。 

    kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: glusterfs
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://10.42.0.0:8080" 1
  restauthenabled: "false" 2
    1
    heketi サーバーの URL です。
    2
    この例では認証が有効ではないため、false に設定します。

  2. OpenShift Container Platform マスターホストから StorageClass を作成します。 

    # oc create -f gluster-storage-class.yaml
storageclass "glusterfs" created

  3. 新たに作成される StorageClass を使用して PVC を作成します。以下は例になります。 

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: gluster1
spec:
 accessModes:
  - ReadWriteMany
 resources:
   requests:
        storage: 30Gi
 storageClassName: glusterfs

  4. OpenShift Container Platform マスターホストから PVC を作成します。 

    # oc create -f glusterfs-dyn-pvc.yaml
persistentvolumeclaim "gluster1" created

  5. PVC を表示し、ボリュームが動的に作成され、PVC にバインドされていることを確認します。 

    # oc get pvc
NAME          	STATUS	VOLUME                                 		CAPACITY   	ACCESSMODES   	STORAGECLASS   	AGE
gluster1        Bound	pvc-78852230-d8e2-11e6-a3fa-0800279cf26f   	30Gi   		RWX       	gluster-dyn	42s

25.6.4. ストレージの使用

ここまでの時点で、PVC にバインドされる GlusterFS ボリュームを動的に作成しましたので、この PVC を Pod で利用できるようになりました。

  1. Pod オブジェクト定義を以下のように作成します。 

    apiVersion: v1
kind: Pod
metadata:
  name: hello-openshift-pod
  labels:
    name: hello-openshift-pod
spec:
  containers:
  - name: hello-openshift-pod
    image: openshift/hello-openshift
    ports:
    - name: web
      containerPort: 80
    volumeMounts:
    - name: gluster-vol1
      mountPath: /usr/share/nginx/html
      readOnly: false
  volumes:
  - name: gluster-vol1
    persistentVolumeClaim:
      claimName: gluster1 1
    1
    先の手順で作成した PVC の名前。

  2. OpenShift Container Platform マスターホストから、以下のように Pod を作成します。 

    # oc create -f hello-openshift-pod.yaml
pod "hello-openshift-pod" created

  3. Pod を表示します。イメージがまだ存在していない場合はダウンロードする必要があるので、数分かかります。 

    # oc get pods -o wide
NAME                               READY     STATUS    RESTARTS   AGE       IP               NODE
hello-openshift-pod                          1/1       Running   0          9m        10.38.0.0        node1

  4. コンテナーへの oc exec を実行し、index.html ファイルを Pod の mountPath 定義内に作成します。 

    $ oc exec -ti hello-openshift-pod /bin/sh
$ cd /usr/share/nginx/html
$ echo 'Hello OpenShift!!!' > index.html
$ ls
index.html
$ exit

  5. ここで、Pod の URL に対して curl を実行します。 

    # curl http://10.38.0.0
Hello OpenShift!!!

  6. Pod を削除してから再作成し、これが出現するまで待機します。 

    # oc delete pod hello-openshift-pod
pod "hello-openshift-pod" deleted
# oc create -f hello-openshift-pod.yaml
pod "hello-openshift-pod" created
# oc get pods -o wide
NAME                               READY     STATUS    RESTARTS   AGE       IP               NODE
hello-openshift-pod                          1/1       Running   0          9m        10.37.0.0        node1

  7. もう一度 Pod に対して curl を実行します。データは前と同じになりますが、Pod の IP アドレスは変更されている可能性があることに注意してください。 

    # curl http://10.37.0.0
Hello OpenShift!!!

  8. 以下の操作をいずれかのノードで実行して、index.html ファイルが GlusterFS ストレージに書き込まれていることを確認します。 

    $ mount | grep heketi
/dev/mapper/VolGroup00-LogVol00 on /var/lib/heketi type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
/dev/mapper/vg_f92e09091f6b20ab12b02a2513e4ed90-brick_1e730a5462c352835055018e1874e578 on /var/lib/heketi/mounts/vg_f92e09091f6b20ab12b02a2513e4ed90/brick_1e730a5462c352835055018e1874e578 type xfs (rw,noatime,seclabel,nouuid,attr2,inode64,logbsize=256k,sunit=512,swidth=512,noquota)
/dev/mapper/vg_f92e09091f6b20ab12b02a2513e4ed90-brick_d8c06e606ff4cc29ccb9d018c73ee292 on /var/lib/heketi/mounts/vg_f92e09091f6b20ab12b02a2513e4ed90/brick_d8c06e606ff4cc29ccb9d018c73ee292 type xfs (rw,noatime,seclabel,nouuid,attr2,inode64,logbsize=256k,sunit=512,swidth=512,noquota)

$ cd /var/lib/heketi/mounts/vg_f92e09091f6b20ab12b02a2513e4ed90/brick_d8c06e606ff4cc29ccb9d018c73ee292/brick
$ ls
index.html
$ cat index.html
Hello OpenShift!!!

25.7. 特権付き Pod へのボリュームのマウント

25.7.1. 概要

永続ボリュームは、特権付き SCC (Security Context Constraint) が割り当てられた Pod にマウントすることができます。

注記

このトピックでは、特権付き Pod へのボリュームのマウントのユースケースの例として GlusterFS を使用していますが、これはいずれの サポート対象ストレージプラグインを使用するケースにも適用できます。

25.7.2. 前提条件

25.7.3. 永続ボリュームの作成

PersistentVolume を作成すると、プロジェクトに関係なく、ユーザーがストレージにアクセスできるようになります。

  1. admin として、サービス、エンドポイントオブジェクトおよび永続ボリュームを作成します。 

    $ oc create -f gluster-endpoints-service.yaml
$ oc create -f gluster-endpoints.yaml
$ oc create -f gluster-pv.yaml

  2. オブジェクトが作成されたことを以下のように確認します。 

    $ oc get svc
NAME              CLUSTER_IP      EXTERNAL_IP   PORT(S)   SELECTOR   AGE
gluster-cluster   172.30.151.58   <none>        1/TCP     <none>     24s
    $ oc get ep
NAME              ENDPOINTS                           AGE
gluster-cluster   192.168.59.102:1,192.168.59.103:1   2m
    $ oc get pv
NAME                     LABELS    CAPACITY   ACCESSMODES   STATUS      CLAIM     REASON    AGE
gluster-default-volume   <none>    2Gi        RWX           Available                       2d

25.7.4. 通常ユーザーの作成

通常ユーザーを以下のように 特権付き SCC (または SCC へのアクセスのあるグループ) に追加すると、当該ユーザーは特権付き Pod を実行できるようになります。

  1. admin として、ユーザーを SCC に追加します。 

    $ oc adm policy add-scc-to-user privileged <ユーザー名>

  2. 通常ユーザーとしてログインします。 

    $ oc login -u <username> -p <password>

  3. 次に、新規プロジェクトを作成します。 

    $ oc new-project <project_name>

25.7.5. Persistent Volume Claim (永続ボリューム要求) の作成

  1. 通常ユーザーとして、ボリュームにアクセスするための PersistentVolumeClaim を作成します。 

    $ oc create -f gluster-pvc.yaml -n <project_name>

  2. 要求にアクセスするための Pod を定義します。

    例25.11 Pod 定義

    apiVersion: v1
id: gluster-S3-pvc
kind: Pod
metadata:
  name: gluster-nginx-priv
spec:
  containers:
    - name: gluster-nginx-priv
      image: fedora/nginx
      volumeMounts:
        - mountPath: /mnt/gluster 1
          name: gluster-volume-claim
      securityContext:
        privileged: true
  volumes:
    - name: gluster-volume-claim
      persistentVolumeClaim:
        claimName: gluster-claim 2
    1
    Pod 内のボリュームマウント。
    2
    gluster-claim には PersistentVolume の名前を反映させる必要があります。

  3. Pod を作成するとマウントディレクトリーが作成され、ボリュームがそのマウントポイントに割り当てられます。

    通常ユーザーとして、以下のように定義から Pod を作成します。 

    $ oc create -f gluster-S3-pod.yaml

  4. Pod が正常に作成されたことを確認します。 

    $ oc get pods
NAME                 READY     STATUS    RESTARTS   AGE
gluster-S3-pod   1/1       Running   0          36m

    Pod が作成されるまでに数分の時間がかかることがあります。

25.7.6. 設定の検証

25.7.6.1. Pod の SCC の確認

  1. Pod 設定をエクスポートします。 

    $ oc get -o yaml --export pod <pod_name>

  2. 出力を確認します。openshift.io/scc の値が privileged であることを確認します。

    例25.12 スニペットのエクスポート

    metadata:
  annotations:
    openshift.io/scc: privileged

25.7.6.2. マウントの検証

  1. Pod にアクセスし、ボリュームがマウントされていることを確認します。 

    $ oc rsh <pod_name>
[root@gluster-S3-pvc /]# mount

  2. Gluster ボリュームの出力結果を確認します。

    例25.13 ボリュームマウント

    192.168.59.102:gv0 on /mnt/gluster type fuse.gluster (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)

25.8. 統合 OpenShift Container レジストリーから GlusterFS への切り替え

25.8.1. 概要

このトピックでは、GlusterFS ボリュームを統合 OpenShift Container レジストリーに割り当てる方法を説明します。この操作は、コンバージドモード、インデペンデントモード、またはスタンドアロンの Red Hat Gluster Storage のいずれかで実行できます。ここでは、レジストリーがすでに起動されていて、ボリュームが作成済みであることを前提とします。

25.8.2. 前提条件

  • ストレージを設定せずにデプロイされている既存の レジストリー。
  • 既存の GlusterFS ボリューム。
  • すべてのスケジュール可能なノードにインストールされている glusterfs-fuse。

  • cluster-admin ロールのバインディングを持つユーザー。

    • このガイドでは、このユーザーを admin と呼んでいます。
注記

oc コマンドはすべてマスターノードで admin ユーザーとして実行されます。

25.8.3. GlusterFS PersistentVolumeClaim の手動プロビジョニング

  1. 静的プロビジョニングを有効にするには、最初に GlusterFS ボリュームを作成します。gluster コマンドラインインターフェースを使用してこれを行う方法については、『Red Hat Gluster Storage Administration Guide』を参照してください。また、heketi-cli を使用してこれを行う方法については、heketi プロジェクトサイトを参照してください。この例では、ボリュームに myVol1 という名前を付けます。

  2. gluster-endpoints.yaml で以下のサービスとエンドポイントを定義します。 

    ---
apiVersion: v1
kind: Service
metadata:
  name: glusterfs-cluster 1
spec:
  ports:
  - port: 1
---
apiVersion: v1
kind: Endpoints
metadata:
  name: glusterfs-cluster 2
subsets:
  - addresses:
      - ip: 192.168.122.221 3
    ports:
      - port: 1 4
  - addresses:
      - ip: 192.168.122.222 5
    ports:
      - port: 1 6
  - addresses:
      - ip: 192.168.122.223 7
    ports:
      - port: 1 8
    1 2
    これらの名前は一致している必要があります。
    3 5 7
    ip の値には、Red Hat Gluster Storage サーバーのホスト名ではなく、実際の IP アドレスを指定する必要があります。
    4 6 8
    ポート番号は無視されます。

  3. OpenShift Container Platform マスターホストからサービスとエンドポイントを作成します。 

    $ oc create -f gluster-endpoints.yaml
service "glusterfs-cluster" created
endpoints "glusterfs-cluster" created

  4. サービスとエンドポイントが作成されたことを確認します。 

    $ oc get services
NAME                       CLUSTER_IP       EXTERNAL_IP   PORT(S)    SELECTOR        AGE
glusterfs-cluster          172.30.205.34    <none>        1/TCP      <none>          44s

$ oc get endpoints
NAME                ENDPOINTS                                               AGE
docker-registry     10.1.0.3:5000                                           4h
glusterfs-cluster   192.168.122.221:1,192.168.122.222:1,192.168.122.223:1   11s
kubernetes          172.16.35.3:8443                                        4d
    注記

    エンドポイントはプロジェクトごとに一意です。GlusterFS にアクセスする各プロジェクトには独自のエンドポイントが必要です。

  5. ボリュームにアクセスするには、ボリューム上のファイルシステムにアクセスできるユーザー ID (UID) またはグループ ID (GID) でコンテナーを実行する必要があります。この情報は以下の方法で取得できます。 

    $ mkdir -p /mnt/glusterfs/myVol1

$ mount -t glusterfs 192.168.122.221:/myVol1 /mnt/glusterfs/myVol1

$ ls -lnZ /mnt/glusterfs/
drwxrwx---. 592 590 system_u:object_r:fusefs_t:s0    myVol1 1 2
    1
    UID は 592 です。
    2
    GID は 590 です。

  6. gluster-pv.yaml で以下の PersistentVolume (PV) を定義します。 

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: gluster-default-volume 1
  annotations:
    pv.beta.kubernetes.io/gid: "590" 2
spec:
  capacity:
    storage: 2Gi 3
  accessModes: 4
    - ReadWriteMany
  glusterfs:
    endpoints: glusterfs-cluster 5
    path: myVol1 6
    readOnly: false
  persistentVolumeReclaimPolicy: Retain
    1
    ボリュームの名前です。
    2
    GlusterFS ボリュームのルートの GID です。
    3
    このボリュームに割り当てられるストレージの量。
    4
    accessModes は、PV と PVC を一致させるためのラベルとして使用します。現時点で、それらは現時点ではいずれの形式のアクセス制御も定義しません。
    5
    以前に作成されたエンドポイントリソースです。
    6
    アクセス対象の GlusterFS ボリュームです。

  7. OpenShift Container Platform マスターホストから PV を作成します。 

    $ oc create -f gluster-pv.yaml

  8. PV が作成されたことを確認します。 

    $ oc get pv
NAME                     LABELS    CAPACITY     ACCESSMODES   STATUS      CLAIM     REASON    AGE
gluster-default-volume   <none>    2147483648   RWX           Available                       2s

  9. gluster-claim.yaml で、新規 PV にバインドする PersistentVolumeClaim (PVC) を作成します。 

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gluster-claim  1
spec:
  accessModes:
  - ReadWriteMany      2
  resources:
     requests:
       storage: 1Gi    3
    1
    この要求名は、volumes セクションで Pod によって参照されます。
    2
    PV の accessModes に一致する必要があります。
    3
    この要求は、1Gi 以上の容量がある PV を検索します。

  10. OpenShift Container Platform マスターホストから PVC を作成します。 

    $ oc create -f gluster-claim.yaml

  11. PV と PVC がバインドされていることを確認します。 

    $ oc get pv
NAME         LABELS    CAPACITY   ACCESSMODES   STATUS      CLAIM          REASON    AGE
gluster-pv   <none>    1Gi        RWX           Available   gluster-claim            37s

$ oc get pvc
NAME            LABELS    STATUS    VOLUME       CAPACITY   ACCESSMODES   AGE
gluster-claim   <none>    Bound     gluster-pv   1Gi        RWX           24s
注記

PVC はプロジェクトごとに一意です。GlusterFS ボリュームにアクセスする各プロジェクトには独自の PVC が必要です。PV は単一のプロジェクトにバインドされないため、複数のプロジェクトにまたがる PVC が同じ PV を参照する場合があります。

25.8.4. PersistentVolumeClaim のレジストリーへの割り当て

次に進む前に、docker-registry サービスが実行中であることを確認します。 

$ oc get svc
NAME              CLUSTER_IP       EXTERNAL_IP   PORT(S)                 SELECTOR                  AGE
docker-registry   172.30.167.194   <none>        5000/TCP                docker-registry=default   18m
注記

docker-registry サービス、またはそれに関連付けられている Pod のいずれかが実行されていない場合は、レジストリーの設定手順を再度参照してトラブルシューティングを行ってから次に進んでください。

次に、PVC を割り当てます。 

$ oc volume deploymentconfigs/docker-registry --add --name=registry-storage -t pvc \
     --claim-name=gluster-claim --overwrite

OpenShift Container レジストリーの使用についての詳細は、「レジストリーのセットアップ」を参照してください。

25.9. ラベルによる永続ボリュームのバインド

25.9.1. 概要

このトピックでは、PV でラベルを定義して PVC 内でセレクターを一致させることで Persistent Volume Claim (永続ボリューム要求、PVC) を 永続ボリューム (PV) にバインドする詳細例を紹介します。この機能はすべてのストレージオプションで使用できます。ここでは、OpenShift Container Platform クラスターに永続ストレージリソースが含まれていて、それらのリソースを PVC によるバインディングに使用できることを前提としています。

ラベルとセレクターに関する注記

ラベルは OpenShift Container Platform の機能であり、ユーザー定義のタグ (キーと値のペア) をオブジェクトの仕様の一部としてサポートします。その主な目的は、オブジェクト間で同一ラベルを定義してオブジェクトを任意にグループ化できるようにすることです。定義したラベルをセレクターでターゲットとして指定すると、指定のラベル値を持つすべてのオブジェクトが一致します。この機能により、PVC を PV にバインドすることができます。ラベルについての詳細は、「Pods and Services」を参照してください。

注記

この例では、変更された GlusterFS の PV および PVC 仕様を使用しています。ただし、実装したセレクターとラベルはすべてのストレージオプションで汎用的に使用できます。使用しているボリュームプロバイダーの独自の設定については、「関連するストレージオプション」を参照してください。

25.9.1.1. 前提条件

以下があることを前提とします。

  • 少なくとも 1 つのマスターと 1 つのノードがある既存の OpenShift Container Platform クラスター
  • 少なくとも 1 つのサポート対象ストレージボリューム
  • cluster-admin 権限を持つユーザー

25.9.2. 仕様の定義

注記

ここでの仕様は GlusterFS に合わせてカスタマイズされています。使用しているボリュームプロバイダーの独自の設定については、「関連するストレージオプション」を参照してください。

25.9.2.1. ラベルのある永続ボリューム

例25.14 glusterfs-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: gluster-volume
  labels: 1
    storage-tier: gold
    aws-availability-zone: us-east-1
spec:
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteMany
  glusterfs:
    endpoints: glusterfs-cluster 2
    path: myVol1
    readOnly: false
  persistentVolumeReclaimPolicy: Retain
1
ラベルを使用して、ボリューム間で共有している共通の属性や特性を識別します。この例では、Gluster ボリュームを定義し、storage-tier という名前のカスタム属性 (キー) を持たせて、gold という値を割り当てています。要求で storage-tier=gold を使用して PV を選択すると、その PV に一致します。
2
エンドポイントは、Gluster で信頼されるプールを定義します。これについては以下で説明します。

25.9.2.2. セレクターのある Persistent Volume Claim (永続ボリューム要求)

selector スタンザのある要求 (以下の例を参照してください) は、事前にバインドされていない既存の非要求の PV との一致を試みます。PVC セレクターがあるため、PV の容量は無視されます。ただし、accessModes は一致条件において考慮されます。

要求はその selector スタンザに含まれるすべてのキーと値のペアに一致する必要がある、ということに注意してください。要求に一致する PV がない場合、PVC はバインドされない (保留中の) ままになります。PV はその後に作成され、要求によってラベルの一致の有無が自動的にチェックされます。

例25.15 glusterfs-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gluster-claim
spec:
  accessModes:
  - ReadWriteMany
  resources:
     requests:
       storage: 1Gi
  selector: 1
    matchLabels:
      storage-tier: gold
      aws-availability-zone: us-east-1
1
selector スタンザでは、この要求と一致させるために PV で必要なすべてのラベルを定義します。

25.9.2.3. ボリュームエンドポイント

PV を Gluster ボリュームに割り当てるには、オブジェクトを作成する前にエンドポイントを設定する必要があります。

例25.16 glusterfs-ep.yaml

apiVersion: v1
kind: Endpoints
metadata:
  name: glusterfs-cluster
subsets:
  - addresses:
      - ip: 192.168.122.221
    ports:
      - port: 1
  - addresses:
      - ip: 192.168.122.222
    ports:
      - port: 1

25.9.2.4. PV、PVC、およびエンドポイントのデプロイ

この例では、oc コマンドを cluster-admin 権限のあるユーザーとして実行します。実稼働環境では、クラスタークライアントが PVC の定義と作成を行うことなどが予想されます。 

# oc create -f glusterfs-ep.yaml
endpoints "glusterfs-cluster" created
# oc create -f glusterfs-pv.yaml
persistentvolume "gluster-volume" created
# oc create -f glusterfs-pvc.yaml
persistentvolumeclaim "gluster-claim" created

最後に、PV と PVC が正常にバインドされていることを確認します。 

# oc get pv,pvc
NAME              CAPACITY   ACCESSMODES      STATUS     CLAIM                     REASON    AGE
gluster-volume    2Gi        RWX              Bound      gfs-trial/gluster-claim             7s
NAME              STATUS     VOLUME           CAPACITY   ACCESSMODES               AGE
gluster-claim     Bound      gluster-volume   2Gi        RWX                       7s
注記

PVC はプロジェクトに対してローカルですが、PV はクラスター全体にわたるグローバルリソースです。開発者および管理者以外のユーザーは、使用可能な PV のすべて (またはいずれか) にアクセスできない場合があります。

25.10. ストレージクラスを使用した動的プロビジョニング

25.10.1. 概要

この例では、StorageClass のさまざまな設定と Google Cloud Platform Compute Engine (GCE) を使用した動的プロビジョニングについて、いくつかのシナリオを紹介します。これらの例では、Kubernetes、GCE、および永続ディスクについて理解していること、また OpenShift Container Platform がインストールされていて GCE を使用できるよう適切に設定されていることを前提とします。

25.10.2. シナリオ 1: 2 種類の StorageClass を持つ基本的な動的プロビジョニング

StorageClass を使用すると、ストレージのレベルや使用状況を区別し、記述することができます。この例では、cluster-admin または storage-admin が GCE で 2 つの異なるストレージのクラスを設定します。

  • slow: 低コストで効率的なシーケンシャルデータの操作に最適化されている (低速読み取り/書き込み)
  • fast: 高速なランダム IOPS と持続的スループットに最適化されている (高速読み取り/書き込み)

これらの StorageClass を作成することで、cluster-admin または storage-admin はユーザーに対して、StorageClass の特定のレベルまたはサービスについての要求の作成を許可することができます。

例25.17 StorageClass 低速オブジェクトの定義

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow 1
provisioner: kubernetes.io/gce-pd 2
parameters:
  type: pd-standard 3
  zone: us-east1-d  4
1
StorageClass の名前。
2
使用するプロビジョナープラグイン。StorageClass の必須フィールドです。
3
PD のタイプ。この例では pd-standard を使用しています。このタイプは、持続的 IOPS とスループットが高い pd-ssd と比べていくらかコストを下げられる一方、持続的 IOPS の速度やスループットもわずかに低下します。
4
ゾーンは必須です。

例25.18 StorageClass 高速オブジェクトの定義

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd
  zone: us-east1-d

cluster-admin または storage-admin として、両方の定義を YAML ファイル (slow-gce.yaml と fast-gce.yaml など) に保存します。次に StorageClass を作成します。 

# oc create -f slow-gce.yaml
storageclass "slow" created

# oc create -f fast-gce.yaml
storageclass "fast" created

# oc get storageclass
NAME       TYPE
fast       kubernetes.io/gce-pd
slow       kubernetes.io/gce-pd
重要

cluster-admin ユーザーまたは storage-admin ユーザーは、適切な StorageClass 名を適切なユーザー、グループ、およびプロジェクトに送る必要があります。

通常ユーザーとして、以下のように新規プロジェクトを作成します。 

# oc new-project rh-eng

要求の YAML 定義を作成し、これをファイル (pvc-fast.yaml) に保存します。 

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pvc-engineering
spec:
 accessModes:
  - ReadWriteMany
 resources:
   requests:
     storage: 10Gi
 storageClassName: fast

oc create コマンドを使用して要求を追加します。 

# oc create -f pvc-fast.yaml
persistentvolumeclaim "pvc-engineering" created

要求がバインドされているかどうかをチェックします。 

# oc get pvc
NAME              STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
pvc-engineering   Bound     pvc-e9b4fef7-8bf7-11e6-9962-42010af00004   10Gi       RWX           2m
重要

この要求は rh-eng プロジェクトで作成され、バインドされているため、同じプロジェクトのいずれのユーザーにも共有できます。

cluster-admin ユーザーまたは storage-admin ユーザーとして、最近動的にプロビジョニングした永続ボリューム (PV) を表示します。 

# oc get pv
NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                     REASON    AGE
pvc-e9b4fef7-8bf7-11e6-9962-42010af00004   10Gi       RWX           Delete          Bound     rh-eng/pvc-engineering              5m
重要

動的にプロビジョニングされたすべてのボリュームについて、RECLAIMPOLICY がデフォルトで Delete になっていることに注意してください。これは、ボリュームが要求がシステムに存在している間存続することを意味します。要求を削除するとボリュームも削除され、ボリュームのすべてのデータが失われます。

最後に GCE コンソールをチェックします。新規のディスクが作成され、使用できる状態になります。 

kubernetes-dynamic-pvc-e9b4fef7-8bf7-11e6-9962-42010af00004 	SSD persistent disk 	10 GB 	us-east1-d

これで、Pod で Persistent Volume Claim (永続ボリューム要求) を参照し、ボリュームの使用を開始することができます。

25.10.3. シナリオ 2: クラスターにおけるデフォルトの StorageClass の動作を有効にする方法

この例では、cluster-admin または storage-admin により、StorageClass を要求に暗黙的に指定していない他のすべてのユーザーおよびプロジェクトについてデフォルトのストレージクラスが有効になります。この方法は、特化した StorageClass をクラスター全体に設定し、伝達することなしに cluster-admin または storage-admin がストレージボリュームを容易に管理できるようにする場合に役に立ちます。

以下の例は 「シナリオ 1: 2 種類の StorageClass を持つ基本的な動的プロビジョニング」 を基づいて作成されています。cluster-admin または storage-admin は、デフォルトの StorageClass として指定するための別の StorageClass を作成します。

例25.19 デフォルトの StorageClass オブジェクトの定義

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: generic 1
  annotations:
    storageclass.kubernetes.io/is-default-class: "true" 2
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
  zone: us-east1-d
1
StorageClass の名前。クラスター内で一意にする必要があります。
2
この StorageClass にデフォルトクラスのマークを付けるアノテーション。このバージョンの API では引用符付きの "true" を使用する必要があります。このアノテーションがない場合、OpenShift Container Platform はこれをデフォルトの StorageClass ではないと見なします。

cluster-admin または storage-admin として、この定義を YAML ファイル (generic-gce.yaml) に保存し、StorageClass を作成します。 

# oc create -f generic-gce.yaml
storageclass "generic" created

# oc get storageclass
NAME       TYPE
generic    kubernetes.io/gce-pd
fast       kubernetes.io/gce-pd
slow       kubernetes.io/gce-pd

通常ユーザーとして、StorageClass の要件なしに新規の要求定義を作成し、これをファイル (generic-pvc.yaml) に保存します。

例25.20 デフォルトのストレージ要求オブジェクトの定義

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pvc-engineering2
spec:
 accessModes:
  - ReadWriteMany
 resources:
   requests:
     storage: 5Gi

以下のように実行し、要求がバインドされていることをチェックします。 

# oc create -f generic-pvc.yaml
persistentvolumeclaim "pvc-engineering2" created
                                                                   3s
# oc get pvc
NAME               STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
pvc-engineering    Bound     pvc-e9b4fef7-8bf7-11e6-9962-42010af00004   10Gi       RWX           41m
pvc-engineering2   Bound     pvc-a9f70544-8bfd-11e6-9962-42010af00004   5Gi        RWX           7s  1
1
pvc-engineering2 は、デフォルトで、動的にプロビジョニングされたボリュームにバインドされます。

cluster-admin または storage-admin として、ここまでに定義した永続ボリュームを表示します。 

# oc get pv
NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                     REASON    AGE
pvc-a9f70544-8bfd-11e6-9962-42010af00004   5Gi        RWX           Delete          Bound     rh-eng/pvc-engineering2             5m 1
pvc-ba4612ce-8b4d-11e6-9962-42010af00004   5Gi        RWO           Delete          Bound     mytest/gce-dyn-claim1               21h
pvc-e9b4fef7-8bf7-11e6-9962-42010af00004   10Gi       RWX           Delete          Bound     rh-eng/pvc-engineering              46m 2
1
この PV は、デフォルトの StorageClass からデフォルトの動的ボリュームにバインドされています。
2
この PV は 高速 StorageClass を使用して「シナリオ 1: 2 種類の StorageClass を持つ基本的な動的プロビジョニング」の 1 番目の PVC にバインドされています。

GCE を使用して (動的にプロビジョニングされるのではなく) 手動でプロビジョニングされるディスクを作成します。次に、新規の GCE ディスク (pv-manual-gce.yaml) に接続する永続ボリュームを作成します。

例25.21 手動の PV オブジェクトの定義

apiVersion: v1
kind: PersistentVolume
metadata:
 name: pv-manual-gce
spec:
 capacity:
   storage: 35Gi
 accessModes:
   - ReadWriteMany
 gcePersistentDisk:
   readOnly: false
   pdName: the-newly-created-gce-PD
   fsType: ext4

オブジェクト定義ファイルを実行します。 

# oc create -f pv-manual-gce.yaml

ここでもう一度 PV を表示します。pv-manual-gce ボリュームが Available になっていることに留意してください。 

# oc get pv
NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM                     REASON    AGE
pv-manual-gce                              35Gi       RWX           Retain          Available                                       4s
pvc-a9f70544-8bfd-11e6-9962-42010af00004   5Gi        RWX           Delete          Bound       rh-eng/pvc-engineering2             12m
pvc-ba4612ce-8b4d-11e6-9962-42010af00004   5Gi        RWO           Delete          Bound       mytest/gce-dyn-claim1               21h
pvc-e9b4fef7-8bf7-11e6-9962-42010af00004   10Gi       RWX           Delete          Bound       rh-eng/pvc-engineering              53m

今度は generic-pvc.yaml PVC 定義と同一の別の要求を作成しますが、名前を変更し、ストレージクラス名は設定しません。

例25.22 要求オブジェクトの定義

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pvc-engineering3
spec:
 accessModes:
  - ReadWriteMany
 resources:
   requests:
     storage: 15Gi

このインスタンスではデフォルトの StorageClass が有効になっているため、手動で作成された PV は要求のリクエストに対応せず、ユーザーは新たに動的にプロビジョニングされた永続ボリュームを受け取ることになります。 

# oc get pvc
NAME               STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
pvc-engineering    Bound     pvc-e9b4fef7-8bf7-11e6-9962-42010af00004   10Gi       RWX           1h
pvc-engineering2   Bound     pvc-a9f70544-8bfd-11e6-9962-42010af00004   5Gi        RWX           19m
pvc-engineering3   Bound     pvc-6fa8e73b-8c00-11e6-9962-42010af00004   15Gi       RWX           6s
重要

デフォルトの StorageClass がこのシステムで有効になっているため、手動で作成された永続ボリュームを前述の要求によってバインドし、動的にプロビジョニングされた新規ボリュームがバインドされないようにするには、PV をデフォルトの StorageClass で作成しておく必要があります。

デフォルトの StorageClass がこのシステムで有効になっているため、手動で作成された永続ボリュームを前述の要求によってバインドし、動的にプロビジョニングされた新規ボリュームをバインドしないようにするためには、PV をデフォルトの StorageClass で作成しておく必要があります。

これを解決するには、cluster-admin ユーザーまたは storage-admin ユーザーは、別の GCE ディスクを作成するか、または必要に応じて最初の手動の PV を削除し、StorageClass 名を割り当てる PV オブジェクト定義 (pv-manual-gce2.yaml) を使用することのみが必要になります。

例25.23 デフォルトの StorageClass 名を持つ手動 PV の仕様

apiVersion: v1
kind: PersistentVolume
metadata:
 name: pv-manual-gce2
spec:
 capacity:
   storage: 35Gi
 accessModes:
   - ReadWriteMany
 gcePersistentDisk:
   readOnly: false
   pdName: the-newly-created-gce-PD
   fsType: ext4
 storageClassName: generic 1
1
先に作成した汎用 の StorageClass の名前。

オブジェクト定義ファイルを実行します。 

# oc create -f pv-manual-gce2.yaml

PV を一覧表示します。 

# oc get pv
NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM                     REASON    AGE
pv-manual-gce                              35Gi       RWX           Retain          Available                                       4s 1
pv-manual-gce2                             35Gi       RWX           Retain          Bound       rh-eng/pvc-engineering3             4s 2
pvc-a9f70544-8bfd-11e6-9962-42010af00004   5Gi        RWX           Delete          Bound       rh-eng/pvc-engineering2             12m
pvc-ba4612ce-8b4d-11e6-9962-42010af00004   5Gi        RWO           Delete          Bound       mytest/gce-dyn-claim1               21h
pvc-e9b4fef7-8bf7-11e6-9962-42010af00004   10Gi       RWX           Delete          Bound       rh-eng/pvc-engineering              53m
1
元の手動 PV はまだバインドされておらず、Available です。これは、default StorageClass で作成されていないためです。
2
2 番目の PVC (名前以外) は手動で作成された Available の PV である pv-manual-gce2 にバインドされています。
重要

動的にプロビジョニングされたすべてのボリュームの RECLAIMPOLICY がデフォルトで Delete である点に注目してください。PV に動的にバインドされた PVC が削除されると、GCE ボリュームが削除され、すべてのデータが消失します。ただし、手動で作成された PV の RECLAIMPOLICY はデフォルトで Retain です。

25.11. 既存のレガシーストレージに対するストレージクラスの使用

25.11.1. 概要

この例では、レガシーデータボリュームが存在し、cluster-admin または storage-admin がそのボリュームを特定のプロジェクトで使用できるようにする必要があります。StorageClass を使用すると、他のユーザーおよびプロジェクトがこのボリュームへのアクセスを要求から取得する可能性が低くなります。これは、要求には完全一致する StorageClass 名の値が必要になるためです。また、ここでは動的なプロビジョニングも無効にしています。この例では以下の要件を満たしていることを前提としています。

25.11.1.1. シナリオ 1: レガシーデータを含む既存の永続ボリュームに StorageClass をリンクさせる

cluster-admin または storage-admin として、過去の財務データ用の StorageClass を定義し、作成します。

例25.24 StorageClass の finance-history オブジェクトの定義

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: finance-history 1
provisioner: no-provisioning 2
parameters: 3
1
StorageClass の名前。
2
これは必須フィールドです。しかし、動的なプロビジョニングは行われないため、実際のプロビジョナーのプラグインタイプでない限り、このフィールドに値を指定する必要があります。
3
パラメーターは動的プロビジョナーで使用されるだけなので、空白のままにしておくことができます。

この定義を YAML ファイル (finance-history-storageclass.yaml) に保存して、StorageClass を作成します。 

# oc create -f finance-history-storageclass.yaml
storageclass "finance-history" created


# oc get storageclass
NAME              TYPE
finance-history   no-provisioning
重要

cluster-admin ユーザーまたは storage-admin ユーザーは、適切な StorageClass 名を適切なユーザー、グループ、およびプロジェクトに送る必要があります。

StorageClass が存在します。cluster-admin または storage-admin は StorageClass で使用するための永続ボリューム (PV) を作成することができます。(動的にプロビジョニングされない) GCE および新しい GCE ディスク (gce-pv.yaml) に接続される永続ボリュームを使用して、手動でプロビジョニングされたディスクを作成します。

例25.25 財務履歴の PV オブジェクト

apiVersion: v1
kind: PersistentVolume
metadata:
 name: pv-finance-history
spec:
 capacity:
   storage: 35Gi
 accessModes:
   - ReadWriteMany
 gcePersistentDisk:
   readOnly: false
   pdName: the-existing-PD-volume-name-that-contains-the-valuable-data 1
   fsType: ext4
 storageClassName: finance-history 2
2
StorageClass 名。完全一致している必要があります。
1
すでに存在し、レガシーデータが含まれている GCE ディスクの名前。

cluster-admin または storage-admin として、PV を作成し、これを表示します。 

# oc create -f gce-pv.yaml
persistentvolume "pv-finance-history" created

# oc get pv
NAME                CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM                        REASON    AGE
pv-finance-history   35Gi       RWX           Retain          Available                                          2d

pv-finance-history が Available で、いつでも利用可能であることに留意してください。

ユーザーとして、Persistent Volume Claim (永続ボリューム要求、PVC) を YAML ファイルとして作成し、以下のように適切な StorageClass 名を指定します。

例25.26 finance-history オブジェクト定義の要求

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pvc-finance-history
spec:
 accessModes:
  - ReadWriteMany
 resources:
   requests:
     storage: 20Gi
 storageClassName: finance-history 1
1
StorageClass 名。完全一致している必要があります。そうでない場合には、削除されるか、または名前が一致する別の StorageClass が作成されるまで要求が非バインドの状態になります。

PVC と PV を作成および表示して、バインドされているか確認します。 

# oc create -f pvc-finance-history.yaml
persistentvolumeclaim "pvc-finance-history" created

# oc get pvc
NAME                  STATUS    VOLUME               CAPACITY   ACCESSMODES   AGE
pvc-finance-history   Bound     pv-finance-history   35Gi       RWX           9m


# oc get pv  (cluster/storage-admin)
NAME                 CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM                         REASON    AGE
pv-finance-history   35Gi       RWX           Retain          Bound       default/pvc-finance-history             5m
重要

同じクラスター内の StorageClass を、レガシーデータ (動的プロビジョニングなし) および動的プロビジョニングの両方に対して使用することができます。

25.12. Azure Blob Storage での統合 Docker レジストリーの設定

25.12.1. 概要

このトピックでは、Microsoft Azure Blob Storage で OpenShift 統合 Docker レジストリー を設定する方法を説明します。

25.12.2. 作業を開始する前に

  • Microsoft Azure Portal、Microsoft Azure CLI、または Microsoft Azure Storage Explorer を使用してストレージコンテナーを作成します。ストレージアカウント名、ストレージアカウントキー、および コンテナー名をメモしてください。
  • デプロイされていない場合は、統合 Docker レジストリーをデプロイします。

25.12.3. レジストリー設定の上書き

新規レジストリー Pod を作成し、古い Pod と自動的に置き換えるには、以下の手順を実行します。

  1. registryconfig.yaml という名前の新規レジストリー設定ファイルを作成して、以下の情報を追加します。 

    version: 0.1
log:
  level: debug
http:
  addr: :5000
storage:
  cache:
    blobdescriptor: inmemory
  delete:
    enabled: true
  azure: 1
    accountname: azureblobacc
    accountkey:  azureblobacckey
    container: azureblobname
    realm: core.windows.net 2
auth:
  openshift:
    realm: openshift
middleware:
  registry:
    - name: openshift
  repository:
    - name: openshift
      options:
        acceptschema2: false
        pullthrough: true
        enforcequota: false
        projectcachettl: 1m
        blobrepositorycachettl: 10m
  storage:
    - name: openshift
    1
    accountname、acountkey、および container の値をそれぞれストレージアカウント名、ストレージアカウントキー、およびストレージコンテナー名で置き換えます。
    2
    Azure のリージョンクラウドを使用している場合は、必要なレルムに設定します。たとえば、ドイツのリージョンクラウドの場合は core.cloudapi.de に設定します。

  2. 新規レジストリー設定を作成します。 

    $ oc create secret generic registry-config --from-file=config.yaml=registryconfig.yaml

  3. シークレットを追加します。 

    $ oc volume dc/docker-registry --add --type=secret \
    --secret-name=registry-config -m /etc/docker/registry/

  4. REGISTRY_CONFIGURATION_PATH 環境変数を設定します。 

    $ oc set env dc/docker-registry \
    REGISTRY_CONFIGURATION_PATH=/etc/docker/registry/config.yaml

  5. レジストリー設定をすでに作成している場合は、以下の手順を実行します。

    1. シークレットを削除します。 

      $ oc delete secret registry-config

    2. 新規レジストリー設定を作成します。 

      $ oc create secret generic registry-config --from-file=config.yaml=registryconfig.yaml

    3. 新規ロールアウトを開始して設定を更新します。 

      $ oc rollout latest docker-registry
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.