第24章 永続ストレージの設定

OpenShift Container Platform クラスターは、NFS を使用している永続ストレージを使ってプロビジョニングすることが可能です。永続ボリューム (PV) および Persistent Volume Claim (永続ボリューム要求、PVC) は、プロジェクト全体でボリュームを共有するための便利な方法を提供します。PV 定義に含まれる NFS に固有の情報は、Pod 定義で直接定義することも可能ですが、この方法の場合にはボリュームが一意のクラスターリソースとして作成されされないため、ボリュームが競合の影響を受けやすくなります。

このトピックでは、NFS 永続ストレージタイプの具体的な使用方法について説明します。OpenShift Container Platform と NFS についてある程度理解していることを前提とします。OpenShift Container Platform 永続ボリューム (PV) の一般的なフレームワークの詳細は永続ストレージの概念に関するトピックを参照してください。

OpenShift Container Platform でストレージをボリュームとしてマウントするには、ストレージがあらかじめ基礎となるインフラストラクチャーに存在している必要があります。NFS ボリュームをプロビジョニングするには、NFS サーバーの一覧とエクスポートパスのみが必要です。

最初に、PV のオブジェクト定義を作成します。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 1
spec:
  capacity:
    storage: 5Gi 2
  accessModes:
  - ReadWriteOnce 3
  nfs: 4
    path: /tmp 5
    server: 172.17.0.2 6
  persistentVolumeReclaimPolicy: Recycle 7

定義をファイル (nfs-pv.yaml など) に保存し、PV を作成します。

$ oc create -f nfs-pv.yaml
persistentvolume "pv0001" created

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

# oc get pv
NAME                     LABELS    CAPACITY     ACCESSMODES   STATUS      CLAIM     REASON    AGE
pv0001                   <none>    5368709120   RWO           Available                       31s

以下の手順で PVC が作成されます。これは新規 PV にバインドされます。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-claim1
spec:
  accessModes:
    - ReadWriteOnce 1
  resources:
    requests:
      storage: 1Gi 2

定義をファイル (nfs-claim.yaml など) に保存し、PVC を作成します。

# oc create -f nfs-claim.yaml

ディスクパーティションを使用して、ディスククォータとサイズ制限を実施することができます。それぞれのパーティションを独自のエクスポートとすることができ、それぞれのエクスポートは 1 つの PV になります。OpenShift Container Platform は PV に固有の名前を適用しますが、NFS ボリュームのサーバーとパスの一意性については管理者に委ねられています。

この方法でクォータを有効にすると、開発者は永続ストレージを具体的な量 (10Gi など) を指定して要求し、この容量以上が設定されている対応のボリュームに適合できます。

このセクションでは、一致するパーミッションや SELinux の考慮点を含む、NFS ボリュームのセキュリティーについて説明します。ユーザーは、POSIX パーミッションやプロセス UID、補助グループおよび SELinux の基礎的な点を理解している必要があります。

開発者は、Pod 定義の volumes セクションで、PVC を名前で参照するか、または NFS ボリュームのプラグインを直接参照して NFS ストレージを要求します。

NFS サーバーの /etc/exports ファイルにはアクセス可能な NFS ディレクトリーが含まれています。ターゲットの NFS ディレクトリーには、POSIX の所有者とグループ ID があります。OpenShift Container Platform NFS プラグインは、同じ POSIX の所有者とエクスポートされる NFS ディレクトリーにあるパーミッションを使って、コンテナーの NFS ディレクトリーをマウントします。ただし、コンテナーは NFS マウントの所有者と同等の実効 UID では実行されません。これは期待される動作です。

ターゲットの NFS ディレクトリーが NFS サーバーに表示される場合を例に取って見てみましょう。

# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 5555 unconfined_u:object_r:usr_t:s0   /opt/nfs

# id nfsnobody
uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)

コンテナーは SELinux ラベルと一致している必要があり、ディレクトリーにアクセスするために UID 65534 (nfsnobody 所有者) か、または補助グループの 5555 のいずれかを使って実行する必要があります。

spec:
  containers:
    - name:
    ...
  securityContext: 1
    supplementalGroups: [5555] 2

spec:
  containers: 1
  - name:
  ...
    securityContext:
      runAsUser: 65534 2

# setsebool -P virt_use_nfs 1

NFS は OpenShift Container Platform の 再利用可能な プラグインインターフェースを実装します。回収タスクは、それぞれの永続ボリュームに設定されるポリシーに基づいて自動プロセスによって処理されます。

デフォルトでは、PV は Retain に設定されます。Recycle に設定される NFS ボリュームは、要求からの解放後 (このボリュームにバインドされるユーザーの PersistentVolumeClaim の削除後) に除去されます ( rm -rf がこのボリュームで実行されます)。リサイクルされた NFS ボリュームは新規の要求にバインドさせることができます。

PV への要求が解除される (PVC が削除される) と、PV オブジェクトは再利用できません。代わりに、新規の PV が元のボリュームと同じ基本ボリューム情報を使って作成されます。

たとえば、管理者は nfs1 という名前の PV を作成するとします。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs1
spec:
  capacity:
    storage: 1Mi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.1
    path: "/"

ユーザーは、nfs1 にバインドされる PVC1 を作成します。次にユーザーは PVC1 を削除し、nfs1 への要求を解除します。これにより、nfs1 は Released になります。管理者が同じ NFS 共有を利用可能にする必要がある場合には、同じ NFS サーバー情報を使って新規 PV を作成する必要があります。この場合、PV の名前は元の名前とは異なる名前にします。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs2
spec:
  capacity:
    storage: 1Mi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.1
    path: "/"

元の PV を削除して、PV を同じ名前で再作成することは推奨されません。PV のステータスを Released から Available に手動で変更しようとすると、エラーが発生してデータが失われる可能性があります。

クラスターは、NFS を使用している永続ストレージを使って以下の方法でプロビジョニングすることができます。

スクリプトを使って上記タスクを自動化する方法は多数あります。まずは Ansible Playbook のサンプルを使用して開始することができます。

適切なエクスポートとセキュリティーマッピングを行うため、使用している NFS のバージョンおよびその設定方法に応じて追加の設定が必要になることがあります。以下は例になります。

Red Hat Gluster Storage は、OpenShift Container Platform の永続ストレージと動的プロビジョニングを提供するように設定でき、OpenShift Container Platform 内のコンテナー化ストレージ (コンバージドモード) としても、独自のノード上の非コンテナー化ストレージ (インデペンデントモード) としても使用できます。

24.3.1.1. コンバージドモード

コンバージドモードの場合には、Red Hat Gluster Storage は、コンテナー化されたディレクトリーを OpenShift Container Platform ノードで直接実行します。それにより、コンピュートおよびストレージインスタンスをスケジュールでき、同じハードウェアのセットから実行することができます。

図24.1 アーキテクチャー - コンバージドモード

コンバージドモードは Red Hat Gluster Storage 3.1 update 3 より利用できます。詳細については、「converged mode for OpenShift Container Platform」を参照してください。

24.3.1.3. スタンドアロンの Red Hat Gluster Storage

スタンドアロンの Red Hat Gluster Storage クラスターが環境で使用できる場合、OpenShift Container Platform の GlusterFS ボリュームプラグインを使用してそのクラスター上でボリュームを使用することができます。この方法は、アプリケーションが専用のコンピュートノード、OpenShift Container Platform クラスターで実行され、ストレージはその専用ノードから提供される従来のデプロイメントです。

図24.2 アーキテクチャー - OpenShift Container Platform の GlusterFS ボリュームプラグインを使用したスタンドアロンの Red Hat Gluster Storage クラスター

Red Hat Gluster Storage の詳細については、『Red Hat Gluster Storage Installation Guide』および『Red Hat Gluster Storage Administration Guide』を参照してください。

重要

インフラストラクチャーにおけるストレージの高可用性は、基礎となるストレージのプロバイダーに委ねられています。

このセクションでは、Red Hat Gluster Storage を OpenShift Container Platform で使用する際に考慮すべきトピックについて取り上げます。

# yum install glusterfs-fuse

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

# yum update glusterfs-fuse

$ heketi-cli volume create --size=100 --gid=10001000

$ sudo setsebool -P virt_sandbox_use_fusefs on 1
$ sudo setsebool -P virt_use_fusefs on

Red Hat Gluster Storage と OpenShift Container Platform のサポートされる統合を作成するには、以下の要件が満たされている必要があります。

インデペンデントモードまたは スタンドアロンの Red Hat Gluster Storage の場合:

スタンドアロンの Red Hat Gluster Storage の場合、OpenShift Container Platform で使用するためにインストールする必要があるコンポーネントはありません。OpenShift Container Platform には組み込み GlusterFS ボリュームドライバーが付属しており、これを使用して既存のボリュームを既存のクラスターで活用できます。既存のボリュームの使用方法については、「プロビジョニング」を参照してください。

コンバージドモードおよびインデペンデントモードでは、「クラスターインストールプロセスを使用して、必要なコンポーネントをインストールすることを推奨します。

コンバージドモードの場合、OpenShift Container Platform のインストールには、クラスターから全リソースおよびアーティファクトをアンイストールするための Playbook が同梱されています。この Playbook を使用するには、コンバージドモードのターゲットインスタンスをインストールするのに使用した元のインベントリーファイルを指定して、以下の Playbook を実行します。

# ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/uninstall.yml

さらに、Playbook は、openshift_storage_glusterfs_wipe と呼ばれる変数の使用をサポートします。これは、有効化されている場合には、Red Hat Gluster Storage バックエンドストレージに使用されていたブロックデバイス上のデータを破棄します。openshift_storage_glusterfs_wipe 変数を使用するには、以下を実行します。

# ansible-playbook -i <path_to_inventory_file> -e
"openshift_storage_glusterfs_wipe=true"
/usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/uninstall.yml

GlusterFS ボリュームは、静的または動的にプロビジョニングできます。静的プロビジョニングは、すべての設定で使用できます。動的プロビジョニングは、コンバージドモードおよびインデペンデントモードでサポートされます。

OpenStack Cinder を使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これには、Kubernetes と OpenStack についてある程度の理解があることが前提となります。

Kubernetes の 永続ボリュームフレームワークは、管理者がクラスターに永続ストレージをプロビジョニングできるようにします。ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようにします。OpenStack Cinder ボリュームを動的にプロビジョニングできます。

永続ボリュームは、単一のプロジェクトまたは namespace にバインドされず、OpenShift Container Platform クラスター全体で共有できます。ただし、Persistent Volume Claim (永続ボリューム要求) は、プロジェクトまたは namespace に固有で、ユーザーが要求できます。

OpenShift Container Platform でストレージをボリュームとしてマウントするには、ストレージが基礎となるインフラストラクチャーに存在している必要があります。OpenShift Container Platform が OpenStack 用に設定されていることを確認した後、Cinder に必要なのは、Cinder ボリューム ID と PersistentVolume API のみになります。

OpenShift Container Platform クラスターでは、Ceph RBD を使用して永続ストレージをプロビジョニングできます。

永続ボリューム (PV) と Persistent Volume Claim (永続ボリューム要求、PVC)は、単一プロジェクトでボリュームを共有できます。PV 定義に含まれている Ceph RBD 固有の情報は Pod 定義で直接定義することも可能ですが、この方法だとボリュームが一意のクラスターリソースとして作成されず、競合の影響を受けやすくなります。

このトピックでは、OpenShift Container Platform と Ceph RBD についてある程度理解していることを前提とします。OpenShift Container Platform 永続ボリューム (PV) の一般的なフレームワークについての詳細は、永続ストレージの概念に関するトピックを参照してください。

Ceph ボリュームをプロビジョニングするには、以下が必要になります。

共有ボリューム (NFS および GlusterFS) とブロックボリューム (Ceph RBD、iSCSI、およびほとんどのクラウドストレージ) の大きな違いは、Pod 定義またはコンテナーイメージで定義されたユーザー ID とグループ ID がターゲットの物理ストレージに適用されることです。これはブロックデバイスの所有権の管理と呼ばれます。たとえば、Ceph RBD マウントで所有者が 123 に、グループ ID が 567 に設定されていて、Pod で runAsUser が 222 に、fsGroup が 7777 に定義されている場合、Ceph RBD 物理マウントの所有権は 222:7777 に変更されます。

Pod の securityContext 定義で fsGroup スタンザを使用して、Pod で Ceph RBD ボリュームのグループ所有権を定義します。

spec:
  containers:
    - name:
    ...
  securityContext: 1
    fsGroup: 7777 2

OpenShift Container Platform では、AWS Elastic Block Store ボリューム (EBS) がサポートされます。AWS EC2 を使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これには、Kubernetes と AWS についてある程度の理解があることが前提となります。

Kubernetes 永続ボリュームフレームワークは、管理者がクラスターに永続ストレージをプロビジョニングできるようにします。ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようになります。AWS Elastic Block Store ボリュームは、動的にプロビジョニングできます。永続ボリュームは、単一のプロジェクトまたは namespace にバインドされず、OpenShift Container Platform クラスター全体で共有できます。ただし、Persistent Volume Claim (永続ボリューム要求)は、プロジェクトまたは namespace に固有で、ユーザーが要求できます。

OpenShift Container Platform でストレージをボリュームとしてマウントするには、基礎となるインフラストラクチャーにストレージが存在している必要があります。OpenShift Container Platform が AWS Elastic Block Store 用に設定されていることを確認した後、OpenShift と AWS に必要になるのは、AWS EBS ボリューム ID と PersistentVolume API のみです。

apiVersion: "v1"
kind: "PersistentVolume"
metadata:
  name: "pv0001" 1
spec:
  capacity:
    storage: "5Gi" 2
  accessModes:
    - "ReadWriteOnce"
  awsElasticBlockStore: 3
    fsType: "ext4" 4
    volumeID: "vol-f37a03aa" 5

# oc create -f aws-pv.yaml
persistentvolume "pv0001" created

# oc get pv
NAME      LABELS    CAPACITY   ACCESSMODES   STATUS      CLAIM     REASON    AGE
pv0001    <none>    5Gi        RWO           Available                       2s

OpenShift Container Platform では、GCE Persistent Disk ボリューム (gcePD) がサポートされます。GCE を使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これには、Kubernetes と GCE についてある程度の理解があることが前提となります。

Kubernetes の 永続ボリュームフレームワークは、管理者がクラスターに永続ストレージをプロビジョニングできるようにします。また、ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようにします。GCE Persistent Disk ボリュームは、動的にプロビジョニングできます。永続ボリュームは、単一のプロジェクトまたは namespace にバインドされず、OpenShift Container Platform クラスター全体で共有できます。ただし、Persistent Volume Claim (永続ボリューム要求) は、プロジェクトまたは namespace に固有で、ユーザーが要求できます。

OpenShift Container Platform でストレージをボリュームとしてマウントするには、基礎となるインフラストラクチャーにストレージが存在している必要があります。OpenShift Container Platform が GCE Persistent Disk 用に設定されていることを確認した後、OpenShift Container Platform と GCE に必要となるのは、GCE Persistent Disk ボリューム ID と PersistentVolume API のみです。

apiVersion: "v1"
kind: "PersistentVolume"
metadata:
  name: "pv0001" 1
spec:
  capacity:
    storage: "5Gi" 2
  accessModes:
    - "ReadWriteOnce"
  gcePersistentDisk: 3
    fsType: "ext4" 4
    pdName: "pd-disk-1" 5

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

# oc get pv
NAME      LABELS    CAPACITY   ACCESSMODES   STATUS      CLAIM     REASON    AGE
pv0001    <none>    5Gi        RWO           Available                       2s

iSCSI を使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これには、Kubernetes と iSCSI についてある程度の理解があることが前提となります。

Kubernetes の 永続ボリュームフレームワークは、管理者がクラスターに永続ストレージをプロビジョニングできるようにします。ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようにします。

OpenShift Container Platform でストレージをボリュームとしてマウントする前に、基礎となるインフラストラクチャーにストレージが存在することを確認します。iSCSI に必要になるのは、iSCSI ターゲットポータル、有効な iSCSI 修飾名 (IQN)、有効な LUN 番号、ファイルシステムタイプ、および PersistentVolume API のみです。

オプションで、マルチパススポータルと CHAP (チャレンジハンドシェイク認証プロトコル) 設定を指定できます。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
     targetPortal: 10.16.154.81:3260
     portals: ['10.16.154.82:3260', '10.16.154.83:3260']
     iqn: iqn.2014-12.example.server:storage.target00
     lun: 0
     fsType: 'ext4'
     readOnly: false
     chapAuthDiscovery: true
     chapAuthSession: true
     secretRef:
       name: chap-secret

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi_pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
    targetPortal: 10.0.0.1:3260
    portals: ['10.0.2.16:3260', '10.0.2.17:3260', '10.0.2.18:3260'] 1
    iqn: iqn.2016-04.test.com:storage.target00
    lun: 0
    fsType: ext4
    readOnly: false

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi_pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
    targetPortal: 10.0.0.1:3260
    portals: ['10.0.2.16:3260', '10.0.2.17:3260', '10.0.2.18:3260']
    iqn: iqn.2016-04.test.com:storage.target00
    lun: 0
    initiatorName: iqn.2016-04.test.com:custom.iqn 1
    fsType: ext4
    readOnly: false

ファイバーチャネルを使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これには、Kubernetes と Fibre Channel についてある程度の理解があることが前提となります。

Kubernetes の 永続ボリュームフレームワークは、管理者がクラスターに永続ストレージをプロビジョニングできるようにします。ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようにします。

OpenShift Container Platform でストレージをボリュームとしてマウントするには、基礎となるインフラストラクチャーにストレージが存在している必要があります。ファイバーチャネルの永続ストレージに必要になるのは、targetWWNs (ファイバーチャネルターゲットのワールドワイド名の配列)、有効な LUN 番号、ファイルシステムタイプ、および PersistentVolume API のみです。 永続ボリュームと LUN は 1 対 1 でマッピングされます。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  fc:
    targetWWNs: ['500a0981891b8dc5', '500a0981991b8dc5'] 1
    lun: 2
    fsType: ext4

OpenShift Container Platform では、Microsoft Azure Disk ボリュームがサポートされます。Azure を使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これには、Kubernetes と Azure についてある程度の理解があることが前提となります。

Kubernetes の 永続ボリュームフレームワークは、管理者がクラスターに永続ストレージをプロビジョニングできるようにします。ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようにします。

Azure Disk ボリュームは、動的にプロビジョニングできます。永続ボリュームは、単一のプロジェクトまたは namespace にバインドされず、OpenShift Container Platform クラスター全体で共有できます。ただし、Persistent Volume Claim (永続ボリューム要求) は、プロジェクトまたは namespace に固有で、ユーザーが要求できます。

Azure を使用して永続ボリュームを作成する前に、OpenShift Container Platform クラスターが以下の要件を満たしていることを確認してください。

OpenShift Container Platform でストレージをボリュームとしてマウントするには、基礎となるインフラストラクチャーにストレージが存在している必要があります。OpenShift Container Platform が Azure Disk 用に設定されていることを確認した後、OpenShift Container Platform と Azure に必要になるのは、Azure Disk Name および Disk URI と PersistentVolume API のみです。

Azure には、インスタンスをデプロイする複数のリージョンがあります。必要なリージョンを指定するには、以下を azure.conf ファイルに追加します。

cloud: <region>

リージョンは以下のいずれかになります。

apiVersion: "v1"
kind: "PersistentVolume"
metadata:
  name: "pv0001" 1
spec:
  capacity:
    storage: "5Gi" 2
  accessModes:
    - "ReadWriteOnce"
  azureDisk: 3
    diskName: test2.vhd 4
    diskURI: https://someacount.blob.core.windows.net/vhds/test2.vhd 5
    cachingMode: ReadWrite  6
    fsType: ext4  7
    readOnly: false  8

OpenShift Container Platform では、Microsoft Azure File ボリュームがサポートされます。Azure を使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これには、Kubernetes と Azure についてのある程度の理解があることが前提となります。

dir_mode および file_mode のパーミッションが 0755 に設定されている場合には、デフォルト値 0755 を 0777 または 0775 に変更します。OpenShift Container Platform 3.9 では、デフォルトの dir_mode および file_mode パーミッションが 0777 から 0755 に変更されるので、この手動の手順が必要です。以下の例では、変更された値が含まれる設定ファイルを紹介しています。

# azf-pv.yml
apiVersion: "v1"
kind: "PersistentVolume"
metadata:
  name: "azpv"
spec:
  capacity:
    storage: "1Gi"
  accessModes:
    - "ReadWriteMany"
  azureFile:
    secretName: azure-secret
    shareName: azftest
    readOnly: false
  mountOptions:
    - dir_mode=0777
    - file_mode=0777

$ azure-file-sc.yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azurefile
provisioner: kubernetes.io/azure-file
mountOptions:
  - dir_mode=0777
  - file_mode=0777
parameters:
  storageAccount: ocp39str
  location: centralus

Azure Disk は複数のリージョンクラウドに対応していますが、Azure File は、エンドポイントがハードコードされているために Azure パブリッククラウドのみをサポートしています。

Azure Storage Account の名前とキーをシークレット設定に定義します。これは後に OpenShift Container Platform で使用できるように base64 に変換されます。

これで、PVC (永続ボリューム要求) を使用してストレージを要求し、新規の永続ボリュームを活用できるようになります。

OpenShift Container Platform には、各種のストレージテクノロジーを使用するためにボリュームプラグインが組み込まれています。組み込みプラグインがないバックエンドのストレージを使用する場合は、FlexVolume ドライバーを使用して OpenShift Container Platform を拡張し、アプリケーションに永続ストレージを提供できます。

FlexVolume ドライバーは、クラスター内のすべてのマシン (マスターとノードの両方) の明確に定義されたディレクトリーに格納されている実行可能ファイルです。OpenShift Container Platform は、flexVolume をソースとする PersistentVolume によって表されるボリュームの割り当て、割り当て解除、マウント、またはアンマウントが必要になるたびに FlexVolume ドライバーを呼び出します。

ドライバーの最初のコマンドライン引数は常に操作名です。その他のパラメーターは操作ごとに異なります。ほとんどの操作は、JSON (JavaScript Object Notation) 文字列をパラメーターとして取ります。このパラメーターは完全な JSON 文字列であり、JSON データを含むファイルの名前ではありません。

FlexVolume ドライバーには以下が含まれます。

{
	"fooServer": "192.168.0.1:1234", 1
        "fooVolumeName": "bar",
	"kubernetes.io/fsType": "ext4", 2
	"kubernetes.io/readwrite": "ro", 3
	"kubernetes.io/secret/<key name>": "<key value>", 4
	"kubernetes.io/secret/<another key name>": "<another key value>",
}

OpenShift Container Platform は、ドライバーの標準出力に JSON データが含まれていると想定します。指定されていない場合、出力には操作の結果が示されます。

{
	"status": "<Success/Failure/Not supported>",
	"message": "<Reason for success/failure>"
}

ドライバーの終了コードは、成功の場合は 0、エラーの場合は 1 です。

操作はべき等です。つまり、すでに割り当てられているボリュームの割り当て操作や、すでにマウントされているボリュームのマウント操作は成功します。

FlexVolume ドライバーは以下の 2 つのモードで動作します。

attach/detach 操作は、OpenShift Container Platform マスターにより、ノードにボリュームを割り当てるため、およびノードからボリュームの割り当てを解除するために使用されます。これは何らかの理由でノードが応答不能になった場合に役立ちます。その後、マスターはノード上のすべての Pod を強制終了し、ノードからすべてのボリュームの割り当てを解除して、ボリュームを他のノードに割り当てることで、元のノードがまだ到達不能な状態であってもアプリケーションを再開できます。

FlexVolume ドライバーをインストールします。

たとえば、ストレージ foo の FlexVolume ドライバーをインストールするには、実行可能ファイルを /usr/libexec/kubernetes/kubelet-plugins/volume/exec/openshift.com~foo/foo に配置します。

OpenShift Container Platform 3.10 では、controller-manager が静的 Pod として実行されるので、割り当ておよび割り当て解除の操作を行う FlexVolume バイナリーファイルは、外部の依存関係がなく、独立した実行可能ファイルでなければなりません。

Atomic ホストでは、FlexVolume プラグインディレクトリーのデフォルトの場所は /etc/origin/kubelet-plugins/ です。FlexVolume の実行可能ファイルを、クラスター内の全マスターとノードの /etc/origin/kubelet-plugins/volume/exec/<vendor>~<driver>/<driver> ディレクトリーに配置する必要があります。

インストールされているストレージを参照するには、PersistentVolume オブジェクトを使用します。OpenShift Container Platform の各 PersistentVolume オブジェクトは、ストレージバックエンドの 1 つのストレージアセット (通常はボリューム) を表します。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 1
spec:
  capacity:
    storage: 1Gi 2
  accessModes:
    - ReadWriteOnce
  flexVolume:
    driver: openshift.com/foo 3
    fsType: "ext4" 4
    secretRef: foo-secret 5
    readOnly: true 6
    options: 7
      fooServer: 192.168.0.1:1234
      fooVolumeName: bar

"fsType":"<FS type>",
"readwrite":"<rw>",
"secret/key1":"<secret1>"
...
"secret/keyN":"<secretN>"

OpenShift Container Platform では、VMWare vSphere の仮想マシンディスク (VMDK: Virtual Machine Disk) ボリュームがサポートされます。VMWare vSphere を使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これには、Kubernetes と VMWare vSphere についてのある程度の理解があることが前提となります。

OpenShift Container Platform の永続ボリューム (PV) フレームワークを使用すると、管理者がクラスターに永続ストレージをプロビジョニングできるようになるだけでなく、ユーザーが、基盤となるインフラストラクチャーに精通していなくてもこれらのリソースを要求できるようになります。VMWare vSphere VMDK ボリュームは、動的にプロビジョニングできます。

永続ボリュームは、単一のプロジェクトまたは namespace にバインドされず、OpenShift Container Platform クラスター全体で共有できます。ただし、PVC (永続ボリューム要求) は、プロジェクトまたは namespace に固有で、ユーザーによる要求が可能です。

前提条件

vSphere を使用して永続ボリュームを作成する前に、OpenShift Container Platform クラスターが以下の要件を満たしていることを確認してください。

OpenShift Container Platform でストレージをボリュームとしてマウントするには、ストレージが基礎となるインフラストラクチャーに存在している必要があります。OpenShift Container Platform が vSpehere 用に設定されていることを確認した後、OpenShift Container Platform と vSphere に必要になるのは、VM フォルダーパス、ファイルシステムタイプ、および PersistentVolume API のみです。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 1
spec:
  capacity:
    storage: 2Gi 2
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  vsphereVolume: 3
    volumePath: "[datastore1] volumes/myDisk" 4
    fsType: ext4 5

OpenShift Container Platform クラスターでは、ローカルボリュームを使用して永続ストレージをプロビジョニングできます。ローカル永続ボリュームを使用すると、標準の PVC インターフェースからディスク、パーティション、ディレクトリーなどのローカルストレージデバイスにアクセスできます。

ローカルボリュームは、Pod をノードに手動でスケジュールせずに使用できます。ボリュームのノード制約がシステムによって認識されるためです。ただし、ローカルボリュームは、依然として基礎となるノードの可用性に依存しており、すべてのアプリケーションに適しているわけではありません。

OpenShift Container Platform でストレージをボリュームとしてマウントするには、ストレージが基礎となるインフラストラクチャーに存在している必要があります。PersistentVolume API を使用する前に、OpenShift Container Platform がローカルボリューム用に設定されていることを確認してください。

Persistent Volume Claim (永続ボリューム要求) をオブジェクト定義に定義します。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: example-local-claim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi 1
  storageClassName: local-storage 2

機能すること:

機能しないこと:

Container Storage Interface (CSI) により、OpenShift Container Platform は CSI インターフェースを永続ストレージとして実装するストレージバックエンドからストレージを使用できます。

CSI ドライバーは通常、コンテナーイメージとして提供されます。これらのコンテナーは、実行先の OpenShift Container Platform を認識しません。OpenShift Container Platform でサポートされる CSI 互換のストレージを使用するには、クラスター管理者は、OpenShift Container Platform とストレージドライバーの橋渡しとして機能する、コンポーネントを複数デプロイする必要があります。

以下の図では、OpenShift Container Platform クラスターの Pod で実行されるコンポーネントの俯瞰図を示しています。

異なるストレージバックエンドに対して複数の CSI ドライバーを実行できます。各ドライバーには、独自の外部コントローラーのデプロイメントおよびドライバーと CSI レジストラーを含む DaemonSet が必要です。

OpenShift Container Platform は CSI ドライバーがインストールされた状態で提供されないので、この例では、OpenShift Container Platform に OpenStack Cinder 向けのコミュニティードライバーをデプロイする方法が示されています。

永続ストレージの動的プロビジョニングは、CSI ドライバーおよび基盤のストレージバックエンドの機能により異なります。CSI ドライバーのプロバイダーは、OpenShift Container Platform で StorageClass の作成方法および、設定で利用可能なパラメーターについて文書を作成する必要があります。

OpenStack Cinder の例にあるように、この StorageClass をデプロイして、動的プロビジョニングを有効化できます。以下の例では、新規のデフォルトストレージクラスを作成して、特別なストレージクラスを必要としない PVC がすべて、インストールした CSI ドライバーによりプロビジョニングされるようにします。

# oc create -f - << EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cinder
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: csi-cinderplugin
parameters:
EOF

CSI ドライバーがデプロイされ、動的プロビジョニング用に StorageClass が作成されたら、OpenShift Container Platform は CSI を使用する準備が整います。以下の例では、変更を加えずに、デフォルトの MySQL テンプレートをインストールします。

# oc new-app mysql-persistent
--> Deploying template "openshift/mysql-persistent" to project default
...

# oc get pvc
NAME              STATUS    VOLUME                                   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mysql             Bound     kubernetes-dynamic-pv-3271ffcb4e1811e8   1Gi        RWO            cinder         3s

OpenShift Container Platform は、OpenStack Manila 共有ファイルシステムサービスを使用して PV をプロビジョニングできます。

OpenStack Manila サービスが正しく設定され、OpenShift Container Platform クラスターからアクセスできることが前提です。プロビジョニングが可能なのは、NFS 共有タイプのみです。

PV、Persistent Volume Claim (永続ボリューム要求、PVC)、動的プロビジョニング および RBAC 認証 について理解しておくことを推奨します。

この機能は、外部プロビジョナーにより提供され、OpenShift Container Platform クラスターに外部プロビジョナーをインストールし、設定する必要があります。

OS_USERNAME
OS_PASSWORD
OS_AUTH_URL
OS_DOMAIN_NAME
OS_TENANT_NAME

OS_USERID
OS_PASSWORD
OS_AUTH_URL
OS_TENANT_ID

OS_USERNAME
OS_PASSWORD
OS_AUTH_URL
OS_DOMAIN_ID
OS_TENANT_NAME

OS_USERNAME
OS_PASSWORD
OS_AUTH_URL
OS_DOMAIN_ID
OS_TENANT_ID

apiVersion: v1
kind: Secret
metadata:
  name: manila-provisioner-env
type: Opaque
data:
  os_username: <base64 encoded Manila username>
  os_password: <base64 encoded password>
  os_auth_url: <base64 encoded OpenStack Keystone URL>
  os_domain_name: <base64 encoded Manila service Domain>
  os_tenant_name: <base64 encoded Manila service Tenant/Project name>

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: manila-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: manila-provisioner
    spec:
      serviceAccountName: manila-provisioner-runner
      containers:
        - image: "registry.access.redhat.com:8888/openshift3/manila-provisioner:latest"
          imagePullPolicy: "IfNotPresent"
          name: manila-provisioner
          env:
            - name: "OS_USERNAME"
              valueFrom:
                secretKeyRef:
                  name: manila-provisioner-env
                  key: os_username
            - name: "OS_PASSWORD"
              valueFrom:
                secretKeyRef:
                  name: manila-provisioner-env
                  key: os_password
            - name: "OS_AUTH_URL"
              valueFrom:
                secretKeyRef:
                  name: manila-provisioner-env
                  key: os_auth_url
            - name: "OS_DOMAIN_NAME"
              valueFrom:
                secretKeyRef:
                  name: manila-provisioner-env
                  key: os_domain_name
            - name: "OS_TENANT_NAME"
              valueFrom:
                secretKeyRef:
                  name: manila-provisioner-env
                  key: os_tenant_name

プロビジョナーの実行後に、PVC と適切な StorageClass を使用して PV をプロビジョニングすることができます。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: manila-nfs-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2G
  storageClassName: manila-share

次に、PersistentVolumeClaim は、新たにプロビジョニングされた Manila 共有でサポートされる PersistentVolume にバインドされます。PersistentVolumeClaim の後に PersistentVolume を削除したら、プロビジョナーは Manila 共有を削除して、エクスポートを中止します。

StorageClass リソースオブジェクトは、要求可能なストレージを記述し、分類するほか、動的にプロビジョニングされるストレージのパラメーターを要求に応じて渡すための手段を提供します。StorageClass オブジェクトは、さまざまなレベルのストレージとストレージへのアクセスを制御するための管理メカニズムとしても機能します。クラスター管理者 (cluster-admin) またはストレージ管理者 (storage-admin) は、ユーザーが基礎となるストレージボリュームソースに関する詳しい知識がなくても要求できる StorageClass オブジェクトを定義し、作成します。

OpenShift Container Platform の永続ボリュームフレームワークは、この機能を有効にし、管理者がクラスターに永続ストレージをプロビジョニングできるようにします。このフレームワークにより、ユーザーは基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようになります。

OpenShift Container Platform では、数多くのストレージタイプを永続ボリュームとして使用できます。これらはすべて管理者によって静的にプロビジョニングされますが、一部のストレージタイプは組み込みプロバイダーとプラグイン API を使用して動的に作成できます。

[OSEv3:vars]

openshift_master_dynamic_provisioning_enabled=True

OpenShift Container Platform は、以下のプロビジョナープラグインを提供します。これらには、クラスターの設定済みプロバイダーの API を使用して新規ストレージリソースを作成する動的プロビジョニング用の一般的な実装が含まれます。

現時点で、StorageClass オブジェクトはグローバルなスコープ付きオブジェクトであり、cluster-admin または storage-admin ユーザーによって作成される必要があります。

現時点で 6 つのプラグインがサポートされています。以下のセクションでは、StorageClass の基本オブジェクトの定義とサポートされている各プラグインタイプの具体的な例について説明します。

kind: StorageClass 1
apiVersion: storage.k8s.io/v1 2
metadata:
  name: foo 3
  annotations: 4
     ...
provisioner: kubernetes.io/plug-in-type 5
parameters: 6
  param1: value
  ...
  paramN: value

   storageclass.kubernetes.io/is-default-class: "true"

   kubernetes.io/description: My StorageClass Description

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: gold
provisioner: kubernetes.io/cinder
parameters:
  type: fast  1
  availability: nova 2
  fsType: ext4 3

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1 1
  zone: us-east-1d 2
  iopsPerGB: "10" 3
  encrypted: "true" 4
  kmsKeyId: keyvalue 5
  fsType: ext4 6

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard  1
  zone: us-central1-a  2
  zones: us-central1-a, us-central1-b, us-east1-b  3
  fsType: ext4 4

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/glusterfs
parameters: 1
  resturl: http://127.0.0.1:8081 2
  restuser: admin 3
  secretName: heketi-secret 4
  secretNamespace: default 5
  gidMin: "40000" 6
  gidMax: "50000" 7
  volumeoptions: group metadata-cache, nl-cache on 8
  volumetype: replicate:3 9

apiVersion: v1
kind: Secret
metadata:
  name: heketi-secret
  namespace: default
data:
  key: bXlwYXNzd29yZA== 1
type: kubernetes.io/glusterfs

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/rbd
parameters:
  monitors: 10.16.153.105:6789  1
  adminId: admin  2
  adminSecretName: ceph-secret  3
  adminSecretNamespace: kube-system  4
  pool: kube  5
  userId: kube  6
  userSecretName: ceph-secret-user  7
  fsType: ext4 8

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gold
provisioner: netapp.io/trident 1
parameters: 2
  media: "ssd"
  provisioningType: "thin"
  snapshots: "true"

kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
  name: slow
provisioner: kubernetes.io/vsphere-volume 1
parameters:
  diskformat: thin 2

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/azure-disk
parameters:
  storageAccount: azure_storage_account_name  1
  storageaccounttype: Standard_LRS  2
  kind: Dedicated  3

GCE と AWS を使用している場合にデフォルトの StorageClass を変更するには、以下のプロセスを使用します。

このトピックでは、ボリュームのセキュリティーに関連する Pod のセキュリティーについての一般的なガイドを提供します。Pod レベルのセキュリティーに関する全般的な情報については、SCC (Security Context Constraints) の管理と SCC (Security Context Constraints) の概念に関するトピックを参照してください。OpenShift Container Platform の永続ボリューム (PV) フレームワークに関する全般的な情報については、永続ストレージの概念に関するトピックを参照してください。

永続ストレージにアクセスするには、クラスター管理者/ストレージ管理者とエンド開発者間の調整が必要です。クラスター管理者は、基礎となる物理ストレージを抽象化する PV を作成します。開発者は、容量などの一致条件に基づいて Pod と (必要に応じて) PV にバインドされる PVC を作成します。

同じプロジェクト内の複数の Persistent Volume Claim (永続ボリューム要求、PVC) を同じ PV にバインドできます。ただし、PVC を PV にバインドすると、最初の要求のプロジェクトの外部にある要求をその PV にバインドできなくなります。基礎となるストレージに複数のプロジェクトからアクセスする必要がある場合は、プロジェクトごとに独自の PV が必要です。これらの PV は同じ物理ストレージを参照できます。これに関連して、バインドされる PV はプロジェクトに結び付けられます。PV と PVC の詳細な例については、「WordPress and MySQL using NFS」を参照してください。

クラスター管理者が PV への Pod アクセスを許可するには、以下を行う必要があります。

グループ ID、ユーザー ID および SELinux の値は、Pod 定義の SecurityContext セクションで定義します。グループ ID は、Pod に対してグローバルであり、Pod で定義されるすべてのコンテナーに適用されます。ユーザー ID は同様にグローバルにすることも、コンテナーごとに固有にすることもできます。ボリュームへのアクセスは以下の 4 つのセクションで制御します。

SCC により、Pod にデフォルトのユーザー ID、fsGroup ID、補助グループ ID、および SELinux ラベルが割り当てられるかが左右されます。また、SCC で、許容可能な ID の範囲に対して、Pod 定義 (またはイメージ) で指定される ID を検証するかも決まります。検証が必要な場合で検証が失敗すると、Pod も失敗します。

SCC は、runAsUser、supplementalGroups、fsGroup などのストラテジーを定義します。これらのストラテジーは Pod に権限があるかどうかを判断するのに役立ちます。RunAsAny に設定されるストラテジーの値は、Pod が対象のストラテジーの内容を何でも実行できると実質的に宣言します。このストラテジーに対する承認は省略され、このストラテジーをもとに生成される OpenShift Container Platform のデフォルト値はありません。したがって、生成されるコンテナーの ID と SELinux ラベルは、OpenShift Container Platform ポリシーではなく、コンテナーのデフォルトに基づいて割り当てられます。

以下に RunAsAny の簡単な概要を示します。

このような理由により、ID 関連のストラテジーについて RunAsAny が設定された SCC は、通常の開発者がアクセスできないように保護する必要があります。一方、MustRunAs または MustRunAsRange に設定された SCC ストラテジーは、(ID 関連のストラテジーについての) ID 検証をトリガーします。その結果、Pod 定義またはイメージに値が直接指定されていない場合は、OpenShift Container Platform によってデフォルト値がコンテナーに割り当てられます。

SCC では、許可される ID (ユーザーまたはグループ) の範囲を定義できます。範囲チェックが必要な場合 (MustRunAs を使用する場合など) で、許容可能な範囲が SCC で定義されていない場合は、プロジェクトによって ID 範囲が決定されます。したがって、プロジェクトでは、許容可能な ID の範囲がサポートされます。ただし、SCC とは異なり、プロジェクトは runAsUser などのストラテジーを定義しません。

許容可能な範囲を設定すると、コンテナー ID の境界を定義するだけでなく、範囲の最小値を対象の ID のデフォルト値にできるので役に立ちます。たとえば、SCC ID ストラテジーの値が MustRunAs で、ID 範囲の最小値が 100で、ID が Pod 定義に存在しない場合、100 がこの ID のデフォルト値になります。

Pod の受付プロセスの一環として、Pod で使用可能な SCC が (ほとんどの場合は優先順位の高い SCC から最も制限の厳しい SCC の順序で) 検査され、Pod の要求に最も一致する SCC が選択されます。SCC のストラテジータイプを RunAsAny に設定すると、制限が緩和されます。一方、MustRunAs タイプに設定すると、制限がより厳しくなります。これらすべてのストラテジーが評価されます。Pod に割り当てられた SCC を確認するには、oc get pod コマンドを使用します。

# oc get pod <pod_name> -o yaml
...
metadata:
  annotations:
    openshift.io/scc: nfs-scc 1
  name: nfs-pod1 2
  namespace: default 3
...

Pod で一致した SCC をすぐに確認できない場合があります。そのため、上記のコマンドは、ライブコンテナーの UID、補助グループ、および SELinux のラベル変更を理解するのに非常に役立ちます。

ストラテジーが RunAsAny に設定された SCC では、そのストラテジーの特定の値を Pod 定義 (またはイメージ) に定義できます。これがユーザー ID (runAsUser) に適用される場合、コンテナーが root として実行されないように SCC へのアクセスを制限することが推奨されます。

Pod が 制限付き SCC に一致することが多くあるため、これに伴うセキュリティーについて理解しておくことが重要です。制限付き SCC には以下の特性があります。

以下に、SCC とプロジェクトの相互関係をまとめた default プロジェクトとカスタム SCC (my-custom-scc) の例を示します。

$ oc get project default -o yaml 1
...
metadata:
  annotations: 2
    openshift.io/sa.scc.mcs: s0:c1,c0 3
    openshift.io/sa.scc.supplemental-groups: 1000000000/10000 4
    openshift.io/sa.scc.uid-range: 1000000000/10000 5

$ oc get scc my-custom-scc -o yaml
...
fsGroup:
  type: MustRunAs 6
  ranges:
  - min: 5000
    max: 6000
runAsUser:
  type: MustRunAsRange 7
  uidRangeMin: 1000100000
  uidRangeMax: 1000100999
seLinuxContext: 8
  type: MustRunAs
  SELinuxOptions: 9
    user: <selinux-user-name>
    role: ...
    type: ...
    level: ...
supplementalGroups:
  type: MustRunAs 10
  ranges:
  - min: 5000
    max: 6000

2 つの形式が許可される範囲にサポートされています。

補助グループは Linux の正規グループです。Linux で実行されるプロセスには、UID、GID、および 1 つ以上の補助グループがあります。これらの属性はコンテナーのメインプロセスで設定されます。supplementalGroups ID は、通常は NFS や GlusterFS などの共有ストレージへのアクセスを制御する場合に使用されます。一方、fsGroup は Ceph RBD や iSCSI などのブロックストレージへのアクセスを制御する場合に使用されます。

OpenShift Container Platform の共有ストレージプラグインは、マウントの POSIX パーミッションとターゲットストレージのパーミッションが一致するようにボリュームをマウントします。たとえば、ターゲットストレージの所有者 ID が 1234 で、そのグループ ID が 5678 の場合、ホストノードのマウントとコンテナーのマウントはそれらの同じ ID を持ちます。したがって、ボリュームにアクセスするためにはコンテナーのメインプロセスがこれらの ID の一方または両方と一致する必要があります。

たとえば、以下の NFS エクスポートについて見てみましょう。

OpenShift Container Platform ノード側:

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs  *

NFS サーバー側:

# cat /etc/exports
/opt/nfs *(rw,sync,root_squash)
...

# ls -lZ /opt/nfs -d
drwx------. 1000100001 5555 unconfined_u:object_r:usr_t:s0   /opt/nfs

/opt/nfs/ エクスポートには UID 1000100001 とグループ 5555 でアクセスすることができます。通常、コンテナーは root として実行しないようにする必要があります。そのため、この NFS の例では、UID 1000100001 として実行されないコンテナーやグループ 5555 のメンバーでないコンテナーは、NFS エクスポートにアクセスできません。

多くの場合、Pod と一致する SCC では特定のユーザー ID の指定は許可されません。そのため、Pod へのストレージアクセスを許可する場合には、補助グループを使用する方法はより柔軟な方法として使用できます。たとえば、前述のエクスポートへの NFS アクセスを許可する場合は、グループ 5555 を Pod 定義に定義できます。

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - name: ...
    volumeMounts:
    - name: nfs 1
      mountPath: /usr/share/... 2
  securityContext: 3
    supplementalGroups: [5555] 4
  volumes:
  - name: nfs 5
    nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs 6

前述の Pod にあるすべてのコンテナー (一致する SCC またはプロジェクトでグループ 5555 を許可することを前提とします) は、グループ 5555 のメンバーとなり、コンテナーのユーザー ID に関係なくボリュームにアクセスできます。ただし、ここでの前提条件に留意してください。場合によっては、SCC が許可されるグループ ID の範囲を定義されておらず、代わりにグループ ID の検証が必要になることがあります (supplementalGroups を MustRunAs に設定した結果など)。ただし、制限付き SCC の場合はこれと異なります。プロジェクトがこの NFS エクスポートにアクセスするようにカスタマイズされていない限り、通常プロジェクトが 5555 というグループ ID を許可することはありません。したがって、このシナリオでは、前述の Pod の 5555 というグループ ID は SCC またはプロジェクトの許可されたグループ ID の範囲内にないために Pod は失敗します。

補助グループとカスタム SCC

前述の例にあるような状況に対応するため、以下のようカスタム SCC を作成することができます。

多くの場合、定義済みの SCC を修正したり、定義済みプロジェクトで許可される ID の範囲を変更したりするよりも、新規の SCC を作成する方が適切です。

新規 SCC を作成するには、既存の SCC をエクスポートし、新規の SCC の要件を満たすように YAML ファイルをカスタマイズするのが最も簡単な方法です。たとえば、以下を実行します。

以下の例は nfs-scc という名前の新規 SCC の一部です。

$ oc get -o yaml --export scc nfs-scc

allowHostDirVolumePlugin: false 1
...
kind: SecurityContextConstraints
metadata:
  ...
  name: nfs-scc 2
priority: 9 3
...
supplementalGroups:
  type: MustRunAs 4
  ranges:
  -  min: 5000 5
     max: 6000
...

前述の Pod をこの新規 SCC に対して実行すると (当然ですが Pod が新規 SCC に一致することを前提とします)、Pod が開始されます。これは、Pod 定義で指定したグループ 5555 がカスタム SCC によって許可されるようになったためです。

fsGroup は Pod の「ファイルシステムグループ」の ID を定義するもので、コンテナーの補助グループに追加されます。supplementalGroups の ID は共有ストレージに適用されますが、fsGroup の ID はブロックストレージに使用されます。

ブロックストレージ (Ceph RBD、iSCSI、各種クラウドストレージなど) は通常、ブロックストレージボリュームを直接に、または PVC を使用して要求した単一 Pod に専用のものとして設定されます。共有ストレージとは異なり、ブロックストレージは Pod によって引き継がれます。つまり、Pod 定義 (またはイメージ) で指定されたユーザー ID とグループ ID が実際の物理ブロックデバイスに適用されます。通常、ブロックストレージは共有されません。

以下の fsGroup の定義は Pod 定義の一部分です。

kind: Pod
...
spec:
  containers:
  - name: ...
  securityContext: 1
    fsGroup: 5555 2
  ...

supplementalGroups と同様に、前述の Pod にあるすべてのコンテナー (一致する SCC またはプロジェクトでグループ 5555 を許可することを前提とします) は、グループ 5555 のメンバーとなり、コンテナーのユーザー ID に関係なくブロックボリュームにアクセスできます。Pod が制限付き SCC に一致し、その fsGroup ストラテジーが MustRunAs である場合、Pod の実行は失敗します。しかし、SCC の fsGroup ストラテジーを RunAsAny に設定した場合は、任意の fsGroup ID (5555 を含む) が許可されます。SCC の fsGroup ストラテジーを RunAsAny に設定して、fsGroup ID を指定しない場合は、ブロックストレージの「引き継ぎ」は行われず、Pod へのパーミッションが拒否される可能性があります。

fsGroups とカスタム SCC

前述の例にあるような状況に対応するため、以下のようにカスタム SCC を作成することができます。

定義済みの SCC を修正したり、定義済みプロジェクトで許可される ID の範囲を変更したりするよりも、新規の SCC を作成する方が適切です。

以下の新規 SCC の定義の一部について見てみましょう。

# oc get -o yaml --export scc new-scc
...
kind: SecurityContextConstraints
...
fsGroup:
  type: MustRunAs 1
  ranges: 2
  - max: 6000
    min: 5000 3
...

前述の Pod をこの新規 SCC に対して実行すると (当然ですが Pod が新しい SCC に一致することを前提とします)、Pod が開始されます。これは、Pod 定義で指定したグループ 5555 がカスタム SCC によって許可されているためです。また、Pod でブロックデバイスの「引き継ぎ」が行われます。そのため、ブロックストレージを Pod の外部のプロセスから表示する場合、そのグループ ID は実際には 5555 になります。

以下は、ブロックの所有権をサポートしているボリュームの例です。

ユーザー ID はコンテナーイメージまたは Pod 定義で定義できます。Pod 定義では、1 つのユーザー ID をすべてのコンテナーに対してグローバルに定義するか、個々のコンテナーに固有のものとして定義するか、またはその両方として定義できます。以下の Pod 定義の一部ではユーザー ID を指定しています。

spec:
  containers:
  - name: ...
    securityContext:
      runAsUser: 1000100001

1000100001 はコンテナー固有の ID であり、エクスポートの所有者 ID と一致します。NFS エクスポートの所有者 ID が 54321 である場合は、その番号が Pod 定義で使用されます。コンテナー定義の外部で securityContext を指定すると、ID は Pod 内のすべてのコンテナーに対してグローバルになります。

グループ ID と同じように、SCC やプロジェクトで設定されているポリシーに従ってユーザー ID を検証することもできます。SCC の runAsUser ストラテジーを RunAsAny に設定した場合は、Pod 定義またはイメージで定義されているすべてのユーザー ID が許可されます。

代わりに runAsUser ストラテジーを MustRunAsRange に設定した場合は、指定したユーザー ID について、許可される ID の範囲にあるかどうかが検証されます。Pod でユーザー ID を指定しない場合は、デフォルト ID が許可されるユーザー ID の範囲の最小値に設定されます。

先の「NFS の例」に戻って、コンテナーでその UID を 1000100001 に設定する必要があります (上記の Pod の例を参照してください)。デフォルトプロジェクトと制限付き SCC を想定した場合、Pod で要求した 1000100001 というユーザー ID は許可されず、したがって Pod は失敗します。Pod が失敗するのは以下の理由によります。

この状況に対応するには、適切なユーザー ID 範囲を指定して新規 SCC を作成します。また、新規プロジェクトを適切なユーザー ID 範囲を定義して作成することもできます。さらに、以下のような推奨されない他のオプションがあります。

ユーザー ID とカスタム SCC

定義済みの SCC を変更することは可能な限り避ける必要があります。組織のセキュリティー上のニーズに合ったカスタム SCC を作成するか、または必要なユーザー ID をサポートする新規プロジェクトを作成することを推奨します。

前述の例にあるような状況に対応するため、以下のようにカスタム SCC を作成することができます。

以下は例を示しています。

$ oc get -o yaml --export scc nfs-scc

allowHostDirVolumePlugin: false 1
...
kind: SecurityContextConstraints
metadata:
  ...
  name: nfs-scc 2
priority: 9 3
requiredDropCapabilities: null
runAsUser:
  type: MustRunAsRange 4
  uidRangeMax: 1000100001 5
  uidRangeMin: 1000100001
...

これで、先の例の Pod 定義に runAsUser: 1000100001 が表示され、Pod が新規の nfs-scc と一致し、UID 1000100001 で実行できるようになります。

特権付き SCC を除くすべての定義済み SCC では、seLinuxContext を MustRunAs に設定します。そのため、Pod の要件と一致する可能性が高い SCC の場合、Pod での SELinux ポリシーの使用を強制的に実行します。Pod で使用される SELinux ポリシーは、その Pod 自体やイメージ、SCC、またはプロジェクト (デフォルトを指定する) で定義できます。

SELinux のラベルは Pod の securityContext.seLinuxOptions セクションで定義でき、user、role、type、および level を使用できます。

...
 securityContext: 1
    seLinuxOptions:
      level: "s0:c123,c456" 2
...

以下の例は SCC とデフォルトプロジェクトからの抜粋です。

$ oc get -o yaml --export scc scc-name
...
seLinuxContext:
  type: MustRunAs 1

# oc get -o yaml --export namespace default
...
metadata:
  annotations:
    openshift.io/sa.scc.mcs: s0:c1,c0 2
...

特権付き SCC を除くすべての定義済み SCC では、seLinuxContext を MustRunAs に設定します。これにより、Pod での MCS ラベルの使用が強制的に実行されます。MCS ラベルは、Pod 定義やイメージで定義するか、またはデフォルトとして指定されます。

SCC によって、SELinux ラベルを必要とするかどうかが決まります。また、SCC でデフォルトラベルを指定できます。seLinuxContext ストラテジーを MustRunAs に設定していて、Pod (またはイメージ) がラベルを定義していない場合は、OpenShift Container Platform は SCC 自体またはプロジェクトから選択されるラベルにデフォルト設定されます。

seLinuxContext を RunAsAnyに設定した場合は、デフォルトラベルは提供されず、コンテナーによって最終的なラベルが決められます。Docker の場合、コンテナーでは一意の MCS ラベルが使用されますが、これが既存のストレージマウントのラベル付けに一致する可能性はほとんどありません。SELinux 管理をサポートしているボリュームについては、指定されるラベルからアクセスできるようにラベルの再設定がなされ、ラベルの排他性によってはそのラベルのみがアクセスできるようになります。

この場合、特権なしコンテナーについては以下の 2 つが関係します。

Pod からボリュームにアクセスできるようにするためには、Pod で両方のボリュームカテゴリーを持つ必要があります。たとえば、s0:c1,c2 を持つ Pod は、s0:c1,c2 のボリュームにアクセスでき、s0 のボリュームにはすべての Pod からアクセスできるようにします。

Pod で承認が失敗する場合、またはパーミッションエラーが原因でストレージのマウントが失敗している場合は、SELinux の実施による干渉が生じている可能性があります。これについては、たとえば以下を実行してチェックできます。

# ausearch -m avc --start recent

これは、ログファイルに AVC (Access Vector Cache) のエラーがないかどうかを検査します。

ここでは、selector 属性と label 属性を使用して Persistent Volume Claim (永続ボリューム要求、PVC) を永続ボリューム (PV) にバインドするための必要な手順について説明します。セレクターとラベルを実装することで、通常のユーザーは、クラスター管理者が定義する識別子を使用して、プロビジョニングされたストレージをターゲットに設定することができます。

静的にプロビジョニングされるストレージの場合、永続ストレージを必要とする開発者は、PVC をデプロイしてバインドするためにいくつかの PV の識別属性を把握しておく必要がありますが、その際、問題となる状況がいくつか生じます。通常のユーザーは、PVC のデプロイでも PV の値の指定においても、クラスター管理者に問い合わせをする必要が生じる場合があります。PV 属性だけでは、ストレージボリュームの用途も、ボリュームをグループ化する方法も確認できないためです。

selector 属性と label 属性を使用すると、ユーザーが意識せずに済むように PV の詳細を抽象化できると同時に、分かりやすくカスタマイズ可能なタグを使用してボリュームを識別する手段をクラスター管理者に提供できます。セレクターとラベルによるバインディングの方法を使用することで、ユーザーは管理者によって定義されているラベルのみを確認することが必要になります。

このセクションでは、PVC の定義方法とデプロイ方法を説明します。

# oc create -f gluster-pv.yaml
persistentVolume "gluster-volume" created

# oc get pv
NAME                     LABELS    CAPACITY     ACCESSMODES   STATUS      CLAIM     REASON    AGE
gluster-volume            map[]    2147483648   RWX           Available                       2s

# oc create -f gluster-pvc.yaml
persistentVolumeClaim "gluster-claim" created
# oc get pvc
NAME          LABELS    STATUS    VOLUME
gluster-claim           Bound     gluster-volume

OpenShift Container Platform 3.4 の時点では、ノードセット自体による各自のボリュームの割り当て/割り当て解除操作の管理のままにするのではなく、管理者がクラスターのマスターで実行されるコントローラーを有効にして、ノードセットに代わってボリュームの割り当て/割り当て解除操作を管理することができます。

コントローラー管理の割り当ておよび割り当て解除を有効にすることには、以下のメリットがあります。

OpenShift Container Platform 3.6 の時点では、コントローラーで管理される割り当て/割り当て解除はデフォルトの設定になっています。

ノード自体にアノテーション volumes.kubernetes.io/controller-managed-attach-detach が設定されている場合、そのノードの割り当て/割り当て解除操作はコントローラーによって管理されます。コントローラーは、すべてのノードでこのアノテーションの有無を自動的に検査し、その有無に応じて動作します。したがって、ユーザーがノードでこのアノテーションの有無を調べることで、コントローラーが管理する割り当て/割り当て解除がそのノードで有効にされているかどうかを判別することができます。

さらに、ノードでコントローラー管理の割り当て/割り当て解除が選択されていることを確認するには、ノードのログで以下の行を検索します。

Setting node annotation to enable volume controller attach/detach

この行が見つからない場合は、以下の行が代わりにログに含まれているはずです。

Controller attach/detach is disabled for this node; Kubelet will attach and detach volumes

コントローラーの端末から、コントローラーが特定ノードの割り当て/割り当て解除操作を管理しているかどうかを確認するには、まずロギングレベルを少なくとも 4 に設定する必要があります。次に、以下の行を見つけます。

processVolumesInUse for node <node_hostname>

ログの表示方法とロギングレベルの設定方法については、「ロギングレベルの設定」を参照してください。

コントローラー管理の割り当て/割り当て解除を有効にするには、個々のノードで独自の割り当て/割り当て解除をオプトインし、無効にするように設定します。編集対象のノード設定ファイルについての詳細は、「ノード設定ファイル」を参照してください。このファイルには、以下の行を追加します。

kubeletArguments:
  enable-controller-attach-detach:
  - "true"

ノードを設定したら、設定を有効にするためにノードを再起動する必要があります。

ストレージシステムの多くは、データを損失から保護するために永続ボリューム (PV) の「スナップショット」を作成する機能を備えています。外部のスナップショットコントローラーおよびプロビジョナーは、この機能を OpenShift Container Platform クラスターで使用して OpenShift Container Platform API を使用してボリュームスナップショットを扱う方法を提供しています。

本書では、OpenShift Container Platform におけるボリュームスナップショットのサポートの現状について説明しています。PV、Persistent Volume Claim (永続ボリューム要求、PVC)、および動的プロビジョニングについて理解しておくことを推奨されます。

外部のスナップショットコントローラーおよびプロビジョナーは、ボリュームスナップショットの機能を提供する外部コンポーネントです。これらの外部コンポーネントはクラスターで実行されます。コントローラーは、ボリュームスナップショットの作成、削除、および関連イベントのレポートを行います。プロビジョナーは、ボリュームスナップショットから新規の PersistentVolumes を作成します。詳細は、「スナップショットの作成」および「スナップショットの復元」を参照してください。

apiVersion: v1
kind: Secret
metadata:
  name: awskeys
type: Opaque
data:
  access-key-id: <base64 encoded AWS_ACCESS_KEY_ID>
  secret-access-key: <base64 encoded AWS_SECRET_ACCESS_KEY>

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: snapshot-controller
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: snapshot-controller
    spec:
      serviceAccountName: snapshot-controller-runner
      containers:
        - name: snapshot-controller
          image: "registry.access.redhat.com/openshift3/snapshot-controller:latest"
          imagePullPolicy: "IfNotPresent"
          args: ["-cloudprovider", "aws"]
          env:
            - name: AWS_ACCESS_KEY_ID
              valueFrom:
                secretKeyRef:
                  name: awskeys
                  key: access-key-id
            - name: AWS_SECRET_ACCESS_KEY
              valueFrom:
                secretKeyRef:
                  name: awskeys
                  key: secret-access-key
        - name: snapshot-provisioner
          image: "registry.access.redhat.com/openshift3/snapshot-provisioner:latest"
          imagePullPolicy: "IfNotPresent"
          args: ["-cloudprovider", "aws"]
          env:
            - name: AWS_ACCESS_KEY_ID
              valueFrom:
                secretKeyRef:
                  name: awskeys
                  key: access-key-id
            - name: AWS_SECRET_ACCESS_KEY
              valueFrom:
                secretKeyRef:
                  name: awskeys
                  key: secret-access-key

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: snapshot-controller
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: snapshot-controller
    spec:
      serviceAccountName: snapshot-controller-runner
      containers:
        - name: snapshot-controller
          image: "registry.access.redhat.com/openshift3/snapshot-controller:latest"
          imagePullPolicy: "IfNotPresent"
          args: ["-cloudprovider", "gce"]
        - name: snapshot-provisioner
          image: "registry.access.redhat.com/openshift3/snapshot-provisioner:latest"
          imagePullPolicy: "IfNotPresent"
          args: ["-cloudprovider", "gce"]