Red Hat Training
A Red Hat training course is available for OpenShift Container Platform
第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 オブジェクト定義
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
2NFS マウントにアクセスするためには、コンテナーが 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
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
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:47Z25.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
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 オブジェクト定義
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
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.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. 動的ボリューム用プールの作成
Install the latest ceph-common package:
yum install -y ceph-common
注記ceph-commonライブラリーは、all schedulableOpenShift Container Platform ノードにインストールする必要があります。管理者または MON ノードによって、以下のように動的ボリューム用の新規プールが作成されます。
$ ceph osd pool create kube 1024 $ ceph auth get-or-create client.kube mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=kube' -o ceph.client.kube.keyring
注記RBD のデフォルトプールを使用することも可能ですが、このオプションは推奨されません。
25.4.3. 動的な永続ストレージでの既存の Ceph クラスターの使用
動的な永続ストレージに既存の Ceph クラスターを使用するには、以下を実行します。
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
client.admin 用に Ceph シークレットを作成します。
$ oc create -f ceph-secret.yaml secret "ceph-secret" created
シークレットが作成されたことを確認します。
$ oc get secret ceph-secret NAME TYPE DATA AGE ceph-secret kubernetes.io/rbd 1 5d
ストレージクラスを作成します。
$ oc create -f ceph-storageclass.yaml storageclass "dynamic" created
Ceph ストレージクラスの例
apiVersion: storage.k8s.io/v1beta1 kind: StorageClass metadata: name: dynamic annotations: storageclass.beta.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 シークレットが新規プロジェクトのデフォルトとして設定されていない限り、このパラメーターの値を指定する必要があります。
ストレージクラスが作成されたことを確認します。
$ oc get storageclasses NAME TYPE dynamic (default) kubernetes.io/rbd
PVC オブジェクト定義を作成します。
PVC オブジェクト定義例
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: ceph-claim-dynamic spec: accessModes: 1 - ReadWriteOnce resources: requests: storage: 2Gi 2
PVC を作成します。
$ oc create -f ceph-pvc.yaml persistentvolumeclaim "ceph-claim-dynamic" created
PVC が作成されていて、予想される PV にバインドされていることを確認します。
$ oc get pvc NAME STATUS VOLUME CAPACITY ACCESSMODES AGE ceph-claim Bound pvc-f548d663-3cac-11e7-9937-0024e8650c7a 2Gi RWO 1m
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 5
Pod を作成します。
$ oc create -f ceph-pod1.yaml pod "ceph-pod1" created
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. 概要
このトピックでは、既存の Container-Native Storage、Container-Ready Storage、またはスタンドアロンの Red Hat Gluster Storage クラスターを OpenShift Container Platform の永続ストレージとして使用する詳細例を紹介します。ここでは作業用の Red Hat Gluster Storage クラスターがすでに設定されていることを前提とします。Container-Native Storage または Container-Ready 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 システムにインストールされています。ただし、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. 静的プロビジョニング
-
静的プロビジョニングを有効にするには、最初に GlusterFS ボリュームを作成します。
glusterコマンドラインインターフェースを使用してこれを行う方法については、『Red Hat Gluster Storage Administration Guide』を参照してください。また、heketi-cliを使用してこれを行う方法については、heketi プロジェクトサイトを参照してください。この例では、ボリュームにmyVol1という名前を付けます。 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
OpenShift Container Platform マスターホストからサービスとエンドポイントを作成します。
$ oc create -f gluster-endpoints.yaml service "glusterfs-cluster" created endpoints "glusterfs-cluster" created
サービスとエンドポイントが作成されたことを確認します。
$ 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 にアクセスする各プロジェクトには独自のエンドポイントが必要です。
ボリュームにアクセスするには、ボリューム上のファイルシステムにアクセスできるユーザー 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
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
OpenShift Container Platform マスターホストから PV を作成します。
$ oc create -f gluster-pv.yaml
PV が作成されたことを確認します。
$ oc get pv NAME LABELS CAPACITY ACCESSMODES STATUS CLAIM REASON AGE gluster-default-volume <none> 2147483648 RWX Available 2s
gluster-claim.yamlで、新規 PV にバインドする PersistentVolumeClaim (PVC) を作成します。apiVersion: v1 kind: PersistentVolumeClaim metadata: name: gluster-claim 1 spec: accessModes: - ReadWriteMany 2 resources: requests: storage: 1Gi 3
OpenShift Container Platform マスターホストから PVC を作成します。
$ oc create -f gluster-claim.yaml
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 で利用できるようになりました。
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 の名前。
OpenShift Container Platform マスターホストから、以下のように Pod を作成します。
# oc create -f hello-openshift-pod.yaml pod "hello-openshift-pod" created
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
コンテナーへの
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
ここで、Pod の URL に対して
curlを実行します。# curl http://10.38.0.0 Hello OpenShift!!!
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
もう一度 Pod に対して
curlを実行します。データは前と同じになりますが、Pod の IP アドレスは変更されている可能性があることに注意してください。# curl http://10.37.0.0 Hello OpenShift!!!
以下の操作をいずれかのノードで実行して、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. 概要
このトピックでは、既存の Container-Native Storage、Container-Ready Storage、またはスタンドアロンの Red Hat Gluster Storage クラスターを OpenShift Container Platform の動的永続ストレージとして使用する詳細例を紹介します。ここでは作業用の Red Hat Gluster Storage クラスターがすでに設定されていることを前提とします。Container-Native Storage または Container-Ready 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 システムにインストールされています。ただし、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. 動的プロビジョニング
動的プロビジョニングを有効にするには、最初に
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
OpenShift Container Platform マスターホストから StorageClass を作成します。
# oc create -f gluster-storage-class.yaml storageclass "glusterfs" created
新たに作成される StorageClass を使用して PVC を作成します。以下は例になります。
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: gluster1 spec: accessModes: - ReadWriteMany resources: requests: storage: 30Gi storageClassName: glusterfsOpenShift Container Platform マスターホストから PVC を作成します。
# oc create -f glusterfs-dyn-pvc.yaml persistentvolumeclaim "gluster1" created
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 で利用できるようになりました。
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 の名前。
OpenShift Container Platform マスターホストから、以下のように Pod を作成します。
# oc create -f hello-openshift-pod.yaml pod "hello-openshift-pod" created
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
コンテナーへの
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
ここで、Pod の URL に対して
curlを実行します。# curl http://10.38.0.0 Hello OpenShift!!!
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
もう一度 Pod に対して
curlを実行します。データは前と同じになりますが、Pod の IP アドレスは変更されている可能性があることに注意してください。# curl http://10.37.0.0 Hello OpenShift!!!
以下の操作をいずれかのノードで実行して、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. 前提条件
- 既存の Gluster ボリューム。
- すべてのホストにインストールされている glusterfs-fuse。
GlusterFS の定義:
- エンドポイントとサービス: gluster-endpoints-service.yaml および gluster-endpoints.yaml
- 永続ボリューム: gluster-pv.yaml
- Persistent Volume Claim (永続ボリューム要求): gluster-pvc.yaml
- 特権付き Pod: gluster-S3-pod.yaml
-
cluster-admin ロールのバインディングを持つユーザー。このガイドでは、このユーザーを
adminと呼んでいます。
25.7.3. 永続ボリュームの作成
PersistentVolume を作成すると、プロジェクトに関係なく、ユーザーがストレージにアクセスできるようになります。
admin として、サービス、エンドポイントオブジェクトおよび永続ボリュームを作成します。
$ oc create -f gluster-endpoints-service.yaml $ oc create -f gluster-endpoints.yaml $ oc create -f gluster-pv.yaml
オブジェクトが作成されたことを以下のように確認します。
$ 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 を実行できるようになります。
admin として、ユーザーを SCC に追加します。
$ oc adm policy add-scc-to-user privileged <username>
通常ユーザーとしてログインします。
$ oc login -u <username> -p <password>
次に、新規プロジェクトを作成します。
$ oc new-project <project_name>
25.7.5. Persistent Volume Claim (永続ボリューム要求) の作成
通常ユーザーとして、ボリュームにアクセスするための PersistentVolumeClaim を作成します。
$ oc create -f gluster-pvc.yaml -n <project_name>
要求にアクセスするための 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 2Pod を作成するとマウントディレクトリーが作成され、ボリュームがそのマウントポイントに割り当てられます。
通常ユーザーとして、以下のように定義から Pod を作成します。
$ oc create -f gluster-S3-pod.yaml
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 の確認
Pod 設定をエクスポートします。
$ oc export pod <pod_name>
出力を確認します。
openshift.io/sccの値がprivilegedであることを確認します。例25.12 スニペットのエクスポート
metadata: annotations: openshift.io/scc: privileged
25.7.6.2. マウントの検証
Pod にアクセスし、ボリュームがマウントされていることを確認します。
$ oc rsh <pod_name> [root@gluster-S3-pvc /]# mount
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 レジストリーに割り当てる方法を説明します。この操作は、Container-Native Storage、Container-Ready Storage、またはスタンドアロンの Red Hat Gluster Storage のいずれかで実行できます。ここでは、レジストリーがすでに起動されていて、ボリュームが作成済みであることを前提とします。
25.8.2. 前提条件
- ストレージを設定せずにデプロイされている既存の レジストリー。
- 既存の GlusterFS ボリューム。
- すべてのスケジュール可能なノードにインストールされている glusterfs-fuse。
cluster-admin ロールのバインディングを持つユーザー。
- このガイドでは、このユーザーを admin と呼んでいます。
oc コマンドはすべてマスターノードで admin ユーザーとして実行されます。
25.8.3. GlusterFS PersistentVolumeClaim の手動プロビジョニング
-
静的プロビジョニングを有効にするには、最初に GlusterFS ボリュームを作成します。
glusterコマンドラインインターフェースを使用してこれを行う方法については、『Red Hat Gluster Storage Administration Guide』を参照してください。また、heketi-cliを使用してこれを行う方法については、heketi プロジェクトサイトを参照してください。この例では、ボリュームにmyVol1という名前を付けます。 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
OpenShift Container Platform マスターホストからサービスとエンドポイントを作成します。
$ oc create -f gluster-endpoints.yaml service "glusterfs-cluster" created endpoints "glusterfs-cluster" created
サービスとエンドポイントが作成されたことを確認します。
$ 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 にアクセスする各プロジェクトには独自のエンドポイントが必要です。
ボリュームにアクセスするには、ボリューム上のファイルシステムにアクセスできるユーザー 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
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
OpenShift Container Platform マスターホストから PV を作成します。
$ oc create -f gluster-pv.yaml
PV が作成されたことを確認します。
$ oc get pv NAME LABELS CAPACITY ACCESSMODES STATUS CLAIM REASON AGE gluster-default-volume <none> 2147483648 RWX Available 2s
gluster-claim.yamlで、新規 PV にバインドする PersistentVolumeClaim (PVC) を作成します。apiVersion: v1 kind: PersistentVolumeClaim metadata: name: gluster-claim 1 spec: accessModes: - ReadWriteMany 2 resources: requests: storage: 1Gi 3
OpenShift Container Platform マスターホストから PVC を作成します。
$ oc create -f gluster-claim.yaml
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 --overwriteOpenShift 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
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: 125.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
例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
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
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
動的にプロビジョニングされたすべてのボリュームの RECLAIMPOLICY がデフォルトで Delete である点に注目してください。PV に動的にバインドされた PVC が削除されると、GCE ボリュームが削除され、すべてのデータが消失します。ただし、手動で作成された PV の RECLAIMPOLICY はデフォルトで Retain です。
25.11. 既存のレガシーストレージに対するストレージクラスの使用
25.11.1. 概要
この例では、レガシーデータボリュームが存在し、cluster-admin または storage-admin がそのボリュームを特定のプロジェクトで使用できるようにする必要があります。StorageClass を使用すると、他のユーザーおよびプロジェクトがこのボリュームへのアクセスを要求から取得する可能性が低くなります。これは、要求には完全一致する StorageClass 名の値が必要になるためです。また、ここでは動的なプロビジョニングも無効にしています。この例では以下の要件を満たしていることを前提としています。
- OpenShift Container Platform、GCE、および永続ディスクについてある程度理解している。
- OpenShift Container Platform が GCE を使用するように適切に設定されている。
25.11.1.1. シナリオ 1: レガシーデータを含む既存の永続ボリュームに StorageClass をリンクさせる
cluster-admin または storage-admin として、過去の財務データ用の StorageClass を定義し、作成します。
例25.24 StorageClass の finance-history オブジェクトの定義
この定義を 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
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 と自動的に置き換えるには、以下の手順を実行します。
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新規レジストリー設定を作成します。
$ oc create secret generic registry-config --from-file=config.yaml=registryconfig.yaml
シークレットを追加します。
$ oc volume dc/docker-registry --add --type=secret \ --secret-name=registry-config -m /etc/docker/registry/REGISTRY_CONFIGURATION_PATH環境変数を設定します。$ oc set env dc/docker-registry \ REGISTRY_CONFIGURATION_PATH=/etc/docker/registry/config.yamlレジストリー設定をすでに作成している場合は、以下の手順を実行します。
シークレットを削除します。
$ oc secretレジストリ設定を削除する
新規レジストリー設定を作成します。
$ oc create secret generic registry-config --from-file=config.yaml=registryconfig.yaml
新規ロールアウトを開始して設定を更新します。
$ oc rollout latest docker-registry
