第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 
spec:
  capacity:
    storage: 5Gi 
  accessModes:
  - ReadWriteOnce 
  nfs: 
    path: /tmp 
    server: 172.17.0.2 
  persistentVolumeReclaimPolicy: Recycle 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 

spec:
  capacity:
    storage: 5Gi 

  accessModes:
  - ReadWriteOnce 

  nfs: 

    path: /tmp 

    server: 172.17.0.2 

  persistentVolumeReclaimPolicy: Recycle 

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

oc create -f nfs-pv.yaml

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

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

oc get 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 
  resources:
    requests:
      storage: 1Gi 

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-claim1
spec:
  accessModes:
    - ReadWriteOnce 

  resources:
    requests:
      storage: 1Gi 

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

oc create -f nfs-claim.yaml

# 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
id nfsnobody

# 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: 
    supplementalGroups: [5555] 

spec:
  containers:
    - name:
    ...
  securityContext: 

    supplementalGroups: [5555] 

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

spec:
  containers: 

  - name:
  ...
    securityContext:
      runAsUser: 65534 

setsebool -P virt_use_nfs 1

# 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: "/"

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: "/"

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 内のコンテナー化ストレージ (Container-Native Storage) としても、独自のノード上の非コンテナー化ストレージ (Container-Ready Storage) としても使用できます。

24.3.1.1. Container-Native Storage

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

図24.1 アーキテクチャー: Container-Native Storage

Container-Native Storage は Red Hat Gluster Storage 3.1 update 3 より利用能になっています。詳細については、「Container-Native Storage 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

# yum install glusterfs-fuse

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

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

yum update glusterfs-fuse

# yum update glusterfs-fuse

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

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

sudo setsebool -P virt_sandbox_use_fusefs on
sudo setsebool -P virt_use_fusefs on

$ sudo setsebool -P virt_sandbox_use_fusefs on 

$ sudo setsebool -P virt_use_fusefs on

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

Container-Ready Storage または スタンドアロンの Red Hat Gluster Storage の場合:

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

Container-Native Storage および Container-Ready Storage の場合は、通常インストーラー (Advanced Installer) を使用して必要なコンポーネントをインストールすることを推奨します。

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

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

# 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

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

GlusterFS ボリュームは、静的または動的にプロビジョニングできます。静的プロビジョニングは、すべての設定で使用できます。動的プロビジョニングは、Container-Native Storage と Container-Ready Storage のみでサポートされます。

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: 
    fsGroup: 7777 

spec:
  containers:
    - name:
    ...
  securityContext: 

    fsGroup: 7777 

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" 
spec:
  capacity:
    storage: "5Gi" 
  accessModes:
    - "ReadWriteOnce"
  awsElasticBlockStore: 
    fsType: "ext4" 
    volumeID: "vol-f37a03aa" 

apiVersion: "v1"
kind: "PersistentVolume"
metadata:
  name: "pv0001" 

spec:
  capacity:
    storage: "5Gi" 

  accessModes:
    - "ReadWriteOnce"
  awsElasticBlockStore: 

    fsType: "ext4" 

    volumeID: "vol-f37a03aa" 

oc create -f aws-pv.yaml

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

oc get pv

# 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" 
spec:
  capacity:
    storage: "5Gi" 
  accessModes:
    - "ReadWriteOnce"
  gcePersistentDisk: 
    fsType: "ext4" 
    pdName: "pd-disk-1" 

apiVersion: "v1"
kind: "PersistentVolume"
metadata:
  name: "pv0001" 

spec:
  capacity:
    storage: "5Gi" 

  accessModes:
    - "ReadWriteOnce"
  gcePersistentDisk: 

    fsType: "ext4" 

    pdName: "pd-disk-1" 

oc create -f gce-pv.yaml

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

oc get pv

# 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.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'] 
    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
    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 
    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 

    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'] 
    lun: 2
    fsType: ext4

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

    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>

cloud: <region>

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

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

apiVersion: "v1"
kind: "PersistentVolume"
metadata:
  name: "pv0001" 

spec:
  capacity:
    storage: "5Gi" 

  accessModes:
    - "ReadWriteOnce"
  azureDisk: 

    diskName: test2.vhd 

    diskURI: https://someacount.blob.core.windows.net/vhds/test2.vhd 

    cachingMode: ReadWrite  

    fsType: ext4  

    readOnly: false  

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

# 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-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 に変換されます。

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

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", 
        "fooVolumeName": "bar",
	"kubernetes.io/fsType": "ext4", 
	"kubernetes.io/readwrite": "ro", 
	"kubernetes.io/secret/<key name>": "<key value>", 
	"kubernetes.io/secret/<another key name>": "<another key value>",
}

{
	"fooServer": "192.168.0.1:1234", 

        "fooVolumeName": "bar",
	"kubernetes.io/fsType": "ext4", 

	"kubernetes.io/readwrite": "ro", 

	"kubernetes.io/secret/<key name>": "<key value>", 

	"kubernetes.io/secret/<another key name>": "<another key value>",
}

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

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

{
	"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 に配置します。

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

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

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 

spec:
  capacity:
    storage: 1Gi 

  accessModes:
    - ReadWriteOnce
  flexVolume:
    driver: openshift.com/foo 

    fsType: "ext4" 

    secretRef: foo-secret 

    readOnly: true 

    options: 

      fooServer: 192.168.0.1:1234
      fooVolumeName: bar

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

"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 クラスター全体で共有できます。ただし、Persistent Volume Claim (永続ボリューム要求) は、プロジェクトまたは 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 
spec:
  capacity:
    storage: 2Gi 
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  vsphereVolume: 
    volumePath: "[datastore1] volumes/myDisk" 
    fsType: ext4 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 

spec:
  capacity:
    storage: 2Gi 

  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  vsphereVolume: 

    volumePath: "[datastore1] volumes/myDisk" 

    fsType: ext4 

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 
  storageClassName: local-storage 

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

  storageClassName: local-storage 

機能すること:

機能しないこと:

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

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

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

[OSEv3:vars]

openshift_master_dynamic_provisioning_enabled=True

[OSEv3:vars]

openshift_master_dynamic_provisioning_enabled=True

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

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

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

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

kind: StorageClass 

apiVersion: storage.k8s.io/v1 

metadata:
  name: foo 

  annotations: 

     ...
provisioner: kubernetes.io/plug-in-type 

parameters: 

  param1: value
  ...
  paramN: value

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

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

   kubernetes.io/description: My StorageClass Description

   kubernetes.io/description: My StorageClass Description

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

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: gold
provisioner: kubernetes.io/cinder
parameters:
  type: fast  

  availability: nova 

  fsType: ext4 

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

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1 

  zone: us-east-1d 

  iopsPerGB: "10" 

  encrypted: "true" 

  kmsKeyId: keyvalue 

  fsType: ext4 

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

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard  

  zone: us-central1-a  

  zones: us-central1-a, us-central1-b, us-east1-b  

  fsType: ext4 

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://127.0.0.1:8081" 
  restuser: "admin" 
  secretName: "heketi-secret" 
  secretNamespace: "default" 
  gidMin: "40000" 
  gidMax: "50000" 

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://127.0.0.1:8081" 

  restuser: "admin" 

  secretName: "heketi-secret" 

  secretNamespace: "default" 

  gidMin: "40000" 

  gidMax: "50000" 

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

apiVersion: v1
kind: Secret
metadata:
  name: heketi-secret
  namespace: default
data:
  key: bXlwYXNzd29yZA== 

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  
  adminId: admin  
  adminSecretName: ceph-secret  
  adminSecretNamespace: kube-system  
  pool: kube  
  userId: kube  
  userSecretName: ceph-secret-user  
  fsType: ext4 

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/rbd
parameters:
  monitors: 10.16.153.105:6789  

  adminId: admin  

  adminSecretName: ceph-secret  

  adminSecretNamespace: kube-system  

  pool: kube  

  userId: kube  

  userSecretName: ceph-secret-user  

  fsType: ext4 

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

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gold
provisioner: netapp.io/trident 

parameters: 

  media: "ssd"
  provisioningType: "thin"
  snapshots: "true"

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

kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
  name: slow
provisioner: kubernetes.io/vsphere-volume 

parameters:
  diskformat: thin 

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

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/azure-disk
parameters:
  storageAccount: azure_storage_account_name  

  storageaccounttype: Standard_LRS  

  kind: Dedicated  

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 は、デフォルトのユーザー ID、fsGroup ID、補助グループ ID、および SELinux ラベルが Pod に割り当てられるかどうかに影響します。また、Pod 定義 (またはイメージ) で指定される ID が許容可能な 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

# oc get pod <pod_name> -o yaml
...
metadata:
  annotations:
    openshift.io/scc: nfs-scc 

  name: nfs-pod1 

  namespace: default 

...

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
oc get scc my-custom-scc -o yaml

$ oc get project default -o yaml 

...
metadata:
  annotations: 

    openshift.io/sa.scc.mcs: s0:c1,c0 

    openshift.io/sa.scc.supplemental-groups: 1000000000/10000 

    openshift.io/sa.scc.uid-range: 1000000000/10000 

$ oc get scc my-custom-scc -o yaml
...
fsGroup:
  type: MustRunAs 

  ranges:
  - min: 5000
    max: 6000
runAsUser:
  type: MustRunAsRange 

  uidRangeMin: 1000100000
  uidRangeMax: 1000100999
seLinuxContext: 

  type: MustRunAs
  SELinuxOptions: 

    user: <selinux-user-name>
    role: ...
    type: ...
    level: ...
supplementalGroups:
  type: MustRunAs 

  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>

# 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

# 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 
      mountPath: /usr/share/... 
  securityContext: 
    supplementalGroups: [5555] 
  volumes:
  - name: nfs 
    nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs 

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - name: ...
    volumeMounts:
    - name: nfs 

      mountPath: /usr/share/... 

  securityContext: 

    supplementalGroups: [5555] 

  volumes:
  - name: nfs 

    nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs 

前述の 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 ファイルをカスタマイズするのが最も簡単な方法です。たとえば、以下を実行します。