第24章インストール設定

24.1. ノードのカスタマイズ

OpenShift Container Platform は、Ignition を介してクラスター全体の設定とマシンごとの設定の両方をサポートしています。そのため、オペレーティングシステムに対する任意のパーティショニングとファイルコンテンツの変更が可能です。一般に、設定ファイルが Red Hat Enterprise Linux (RHEL) で文書化されている場合、Ignition を介した変更がサポートされます。

マシン設定の変更をデプロイするには 2 つの方法があります。

openshift-install の実行時にクラスターを起動するためにマニフェストファイルに組み込まれるマシン設定を作成します。
Machine Config Operator を使用して実行中の OpenShift Container Platform ノードに渡されるマシン設定を作成します。

さらに、ベアメタルノードのインストール時に coreos-installer に渡される Ignition 設定などの参照設定を変更すると、マシンごとの設定が可能になります。現在、これらの変更はマシン設定オペレーターに表示されません。

以下のセクションでは、この方法でノード上で設定する必要が生じる可能性のある機能について説明します。

24.1.1. Butane でのマシン設定の作成

マシン設定は、ユーザーおよびファイルシステムの作成、ネットワークの設定、systemd ユニットのインストールなどを行う方法をマシンに指示することで、コントロールプレーンマシンおよびワーカーマシンを設定するために使用されます。

マシン設定の変更は困難である可能性があるため、Butane 設定を使用してマシン設定を作成することができます。これにより、ノードの設定がより容易になります。

24.1.1.1. Butane について

Butane は、OpenShift Container Platform が使用するコマンドラインユーティリティーで、マシン設定を作成するための便利で簡略化した構文を提供したり、マシン設定の追加検証を実行したりします。Butane が受け入れる Butane 設定ファイルの形式は、OpenShift Butane config spec で定義されています。

24.1.1.2. Butane のインストール

Butane ツール (butane) をインストールして、コマンドラインインターフェイスから OpenShift Container Platform マシン設定を作成できます。対応するバイナリーファイルをダウンロードし、Linux、Windows、または macOS に butane をインストールできます。

ヒント

Butane リリースは、古いリリースと、Fedora CoreOS Config Transpiler (FCCT) との後方互換性があります。

手順

Butane イメージのダウンロードページ (https://mirror.openshift.com/pub/openshift-v4/clients/butane/) に移動してください。
butane バイナリーを取得します。
1. 最新バージョンの Butane の場合は、最新の butane イメージを現在のディレクトリーに保存します。
```
$ curl https://mirror.openshift.com/pub/openshift-v4/clients/butane/latest/butane --output butane
```
2. オプション: aarch64 や ppc64le など、Butane をインストールする特定のタイプのアーキテクチャーの場合は、適切な URL を指定してください。以下に例を示します。
```
$ curl https://mirror.openshift.com/pub/openshift-v4/clients/butane/latest/butane-aarch64 --output butane
```
ダウンロード済みのバイナリーファイルを実行可能にします。
```
$ chmod +x butane
```
butane バイナリーファイルを PATH にあるディレクトリーに移動します。
PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。
```
$ echo $PATH
```

検証手順

butane コマンドを実行して、Butane ツールを使用できるようになりました。
```
$ butane <butane_file>
```

24.1.1.3. Butane を使用した MachineConfig オブジェクトの作成

Butane を使用して MachineConfig オブジェクトを作成できるため、インストール時に、または Machine Config Operator を使用して、ワーカーノードまたはコントロールプレーンノードを設定できます。

前提条件

butane ユーティリティーをインストールしている。

手順

Butane 設定ファイルを作成します。以下の例では、99-worker-custom.bu という名前のファイルを作成します。このファイルは、カーネルデバッグメッセージを表示するようにシステムコンソールを設定し、chrony タイムサービスのカスタム設定を指定します。
```
variant: openshift
version: 4.11.0
metadata:
  name: 99-worker-custom
  labels:
    machineconfiguration.openshift.io/role: worker
openshift:
  kernel_arguments:
    - loglevel=7
storage:
  files:
    - path: /etc/chrony.conf
      mode: 0644
      overwrite: true
      contents:
        inline: |
          pool 0.rhel.pool.ntp.org iburst
          driftfile /var/lib/chrony/drift
          makestep 1.0 3
          rtcsync
          logdir /var/log/chrony
```
注記
99-worker-custom.bu ファイルは、ワーカーノードのマシン設定を作成するように設定されます。コントロールプレーンノードにデプロイするには、ロールを worker から master に変更します。どちらの方法でも、デプロイメントの種類ごとに異なるファイル名を使用して手順全体を繰り返すことができます。
直前の手順で作成したファイルを Butane に指定して MachineConfig オブジェクトを作成します。
```
$ butane 99-worker-custom.bu -o ./99-worker-custom.yaml
```
MachineConfig オブジェクト YAML ファイルは、マシンの設定を終了するために作成されます。
将来的に MachineConfig オブジェクトを更新する必要がある場合に備えて、Butane 設定を保存します。
クラスターがまだ起動していない場合は、マニフェストファイルを生成し、MachineConfig オブジェクト YAML ファイルを openshift ディレクトリーに追加します。クラスターがすでに実行中の場合は、ファイルを以下のように適用します。
```
$ oc create -f 99-worker-custom.yaml
```

関連情報

24.1.2. day-1 カーネル引数の追加

多くの場合、カーネル引数を day-2 アクティビティーとして変更することが推奨されますが、初期クラスターのインストール時にすべてのマスターまたはワーカーノードにカーネル引数を追加することができます。以下は、クラスターのインストール時にカーネル引数を追加して、システムの初回起動前に有効にする必要が生じる可能性のある理由です。

システムの起動前に、低レベルのネットワーク設定を実行する必要がある場合。
SELinux などの機能を無効にし、初回起動時にシステムに影響を与えないようにする必要がある場合。
警告
実稼働環境での RHCOS での SELinux の無効化はサポートされていません。ノードで SELinux が無効になったら、実稼働クラスターで再プロビジョニングする前に再プロビジョニングする必要があります。

カーネル引数をマスターまたはワーカーノードに追加するには、MachineConfig オブジェクトを作成し、そのオブジェクトをクラスターのセットアップ時に Ignition が使用するマニフェストファイルのセットに挿入することができます。

起動時に RHEL 8 カーネルに渡すことのできる引数のリストについては、Kernel.org カーネルパラメーターを参照してください。カーネル引数が OpenShift Container Platform の初回インストールを完了するために必要な場合は、この手順でカーネル引数のみを追加することが推奨されます。

手順

インストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
```
$ ./openshift-install create manifests --dir <installation_directory>
```
カーネル引数をワーカーまたコントロールプレーンノードに追加するかどうかを決定します。
openshift ディレクトリーでファイル (例: 99-openshift-machineconfig-master-kargs.yaml) を作成し、カーネル設定を追加するために MachineConfig オブジェクトを定義します。この例では、loglevel=7 カーネル引数をコントロールプレーンノードに追加します。
```
$ cat << EOF > 99-openshift-machineconfig-master-kargs.yaml
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-openshift-machineconfig-master-kargs
spec:
  kernelArguments:
    - loglevel=7
EOF
```
カーネル引数をワーカーノードに追加する場合は、master を worker に切り替えます。マスターおよびワーカーノードの両方に追加するために別々の YAML ファイルを作成します。

クラスターの作成を継続できます。

24.1.3. カーネルモジュールのノードへの追加

大半の一般的なハードウェアの場合、Linux カーネルには、コンピューターの起動時にそのハードウェアを使用するために必要となるデバイスドライバーモジュールが含まれます。ただし、一部のハードウェアの場合、Linux でモジュールを利用できません。したがって、各ホストコンピューターにこれらのモジュールを提供する方法を確保する必要があります。この手順では、OpenShift Container Platform クラスターのノードについてこれを実行する方法を説明します。

この手順に従ってカーネルモジュールを最初にデプロイする際、モジュールは現行のカーネルに対して利用可能になります。新規カーネルがインストールされると、kmods-via-containers ソフトウェアはモジュールを再ビルドし、デプロイしてそのモジュールの新規カーネルと互換性のあるバージョンが利用可能になるようにします。

この機能によって各ノードでモジュールが最新の状態に保てるようにするために、以下が実行されます。

新規カーネルがインストールされているかどうかを検出するために、システムの起動時に起動する各ノードに systemd サービスを追加します。
新規カーネルが検出されると、サービスはモジュールを再ビルドし、これをカーネルにインストールします。

この手順に必要なソフトウェアの詳細については、kmods-via-containers github サイトを参照してください。

以下の重要な点に留意してください。

この手順はテクノロジープレビューです。
ソフトウェアのツールおよびサンプルは公式の RPM 形式で利用できず、現時点ではこの手順に記載されている非公式の github.com サイトからしか取得できません。
この手順で追加する必要がある可能性のあるサードパーティーのカーネルモジュールについては Red Hat はサポートしません。
この手順では、カーネルモジュールのビルドに必要なソフトウェアは RHEL 8 コンテナーにデプロイされます。モジュールは、ノードが新規カーネルを取得する際に各ノードで自動的に再ビルドされることに注意してください。このため、各ノードには、モジュールの再ビルドに必要なカーネルと関連パッケージを含む yum リポジトリーへのアクセスが必要です。このコンテンツは、有効な RHEL サブスクリプションを使用して効果的に利用できます。

24.1.3.1. カーネルモジュールコンテナーのビルドおよびテスト

カーネルモジュールを OpenShift Container Platform クラスターにデプロイする前に、プロセスを別の RHEL システムでテストできます。カーネルモジュールのソースコード、KVC フレームワーク、および kmod-via-containers ソフトウェアを収集します。次にモジュールをビルドし、テストします。RHEL 8 システムでこれを行うには、以下を実行します。

手順

RHEL 8 システムを登録します。
```
# subscription-manager register
```
RHEL 8 システムにサブスクリプションを割り当てます。
```
# subscription-manager attach --auto
```
ソフトウェアとコンテナーのビルドに必要なソフトウェアをインストールします。
```
# yum install podman make git -y
```
kmod-via-containers リポジトリーのクローンを作成します。
1. リポジトリーのフォルダーを作成します。
```
$ mkdir kmods; cd kmods
```
2. リポジトリーのクローンを作成します。
```
$ git clone https://github.com/kmods-via-containers/kmods-via-containers
```
RHEL 8 ビルドホストに KVC フレームワークインスタンスをインストールし、モジュールをテストします。これにより、kmods-via-container systemd サービスが追加され、読み込まれます。
1. kmod-via-containers ディレクトリーに移動します。
```
$ cd kmods-via-containers/
```
2. KVC フレームワークインスタンスをインストールします。
```
$ sudo make install
```
3. systemd マネージャー設定を再読み込みします。
```
$ sudo systemctl daemon-reload
```
カーネルモジュールのソースコードを取得します。ソースコードは、制御下になく、他から提供されるサードパーティーモジュールをビルドするために使用される可能性があります。システムに対してクローン作成できる以下の kvc-simple-kmod サンプルのコンテンツと同様のコンテンツが必要になります。
```
$ cd .. ; git clone https://github.com/kmods-via-containers/kvc-simple-kmod
```

この例では、設定ファイル simple-kmod.conf を編集し、Dockerfile の名前を Dockerfile.rhel に変更します。

kvc-simple-kmod ディレクトリーに移動します。
```
$ cd kvc-simple-kmod
```

Dockerfile の名前を変更します。

$ cat simple-kmod.conf

Dockerfile の例

KMOD_CONTAINER_BUILD_CONTEXT="https://github.com/kmods-via-containers/kvc-simple-kmod.git"
KMOD_CONTAINER_BUILD_FILE=Dockerfile.rhel
KMOD_SOFTWARE_VERSION=dd1a7d4
KMOD_NAMES="simple-kmod simple-procfs-kmod"

この例ではカーネルモジュール simple-kmod の kmods-via-containers@.service のインスタンスを作成します。
```
$ sudo make install
```
kmods-via-containers@.service インスタンスを有効にします。
```
$ sudo kmods-via-containers build simple-kmod $(uname -r)
```

systemd サービスを有効にし、起動します。

$ sudo systemctl enable kmods-via-containers@simple-kmod.service --now

サービスのステータスを確認します。

$ sudo systemctl status kmods-via-containers@simple-kmod.service

出力例

● kmods-via-containers@simple-kmod.service - Kmods Via Containers - simple-kmod
   Loaded: loaded (/etc/systemd/system/kmods-via-containers@.service;
          enabled; vendor preset: disabled)
   Active: active (exited) since Sun 2020-01-12 23:49:49 EST; 5s ago...

カーネルモジュールがロードされていることを確認するには、lsmod コマンドを使用してモジュールをリスト表示します。
```
$ lsmod | grep simple_
```
出力例
```
simple_procfs_kmod     16384  0
simple_kmod            16384  0
```

オプション。他の方法を使用して simple-kmod のサンプルが機能していることを確認します。

dmesg を使用してカーネルリングバッファーで Hello world メッセージを探します。
```
$ dmesg | grep 'Hello world'
```
出力例
```
[ 6420.761332] Hello world from simple_kmod.
```

/proc で simple-procfs-kmod の値を確認します。

$ sudo cat /proc/simple-procfs-kmod

出力例

simple-procfs-kmod number = 0

spkut コマンドを実行して、モジュールの詳細情報を取得します。

$ sudo spkut 44

出力例

KVC: wrapper simple-kmod for 4.18.0-147.3.1.el8_1.x86_64
Running userspace wrapper using the kernel module container...
+ podman run -i --rm --privileged
   simple-kmod-dd1a7d4:4.18.0-147.3.1.el8_1.x86_64 spkut 44
simple-procfs-kmod number = 0
simple-procfs-kmod number = 44

その後は、システムの起動時に、このサービスは新規カーネルが実行中であるかどうかをチェックします。新規カーネルがある場合は、サービスは新規バージョンのカーネルモジュールをビルドし、これをロードします。モジュールがすでにビルドされている場合は、これをロードします。

24.1.3.2. カーネルモジュールの OpenShift Container Platform へのプロビジョニング

OpenShift Container Platform クラスターの初回起動時にカーネルモジュールを有効にする必要があるかどうかに応じて、以下のいずれかの方法でデプロイするようにカーネルモジュールを設定できます。

クラスターインストール時のカーネルモジュールのプロビジョニング (day-1): コンテンツを MachineConfig として作成し、これをマニフェストファイルのセットと共に組み込み、これを openshift-install に提供できます。
Machine Config Operator によるカーネルモジュールのプロビジョニング (day-2): カーネルモジュールを追加する際にクラスターが稼働するまで待機できる場合、Machine Config Operator (MCO) を使用してカーネルモジュールソフトウェアをデプロイできます。

いずれの場合も、各ノードは、新規カーネルの検出時にカーネルパッケージと関連ソフトウェアパッケージを取得できる必要があります。該当するコンテンツを取得できるように各ノードをセットアップする方法はいくつかあります。

各ノードに RHEL エンタイトルメントを提供します。
/etc/pki/entitlement ディレクトリーから、既存 RHEL ホストの RHEL エンタイトルメントを取得し、それらを Ignition 設定の作成時に提供する他のファイルと同じ場所にコピーします。
Dockerfile 内で、カーネルおよびその他のパッケージを含む yum リポジトリーへのポインターを追加します。これには、新たにインストールされたカーネルと一致させる必要があるため、新規のカーネルパッケージが含まれている必要があります。

24.1.3.2.1. MachineConfig オブジェクトを介したカーネルモジュールのプロビジョニング

MachineConfig オブジェクトでカーネルモジュールソフトウェアをパッケージ化することで、そのソフトウェアをインストール時に、または Machine Config Operator を使用して、ワーカーノードまたはコントロールプレーンノードに配信できます。

手順

RHEL 8 システムを登録します。
```
# subscription-manager register
```
RHEL 8 システムにサブスクリプションを割り当てます。
```
# subscription-manager attach --auto
```
ソフトウェアのビルドに必要なソフトウェアをインストールします。
```
# yum install podman make git -y
```
カーネルモジュールおよびツールをホストするディレクトリーを作成します。
```
$ mkdir kmods; cd kmods
```
kmods-via-containers ソフトウェアを取得します。
1. kmods-via-containers リポジトリーのクローンを作成します。
```
$ git clone https://github.com/kmods-via-containers/kmods-via-containers
```
2. kvc-simple-kmod リポジトリーのクローンを作成します。
```
$ git clone https://github.com/kmods-via-containers/kvc-simple-kmod
```
モジュールソフトウェアを取得します。この例では、kvc-simple-kmod が使用されます。
fakeroot ディレクトリーを作成し、先にクローン作成したリポジトリーを使用して Ignition で配信するファイルを使用してこれを設定します。
1. ディレクトリーを作成します。
```
$ FAKEROOT=$(mktemp -d)
```
2. kmod-via-containers ディレクトリーに移動します。
```
$ cd kmods-via-containers
```
3. KVC フレームワークインスタンスをインストールします。
```
$ make install DESTDIR=${FAKEROOT}/usr/local CONFDIR=${FAKEROOT}/etc/
```
4. kvc-simple-kmod ディレクトリーに移動します。
```
$ cd ../kvc-simple-kmod
```
5. インスタンスを作成します。
```
$ make install DESTDIR=${FAKEROOT}/usr/local CONFDIR=${FAKEROOT}/etc/
```
fakeroot ディレクトリーのクローンを作成し、以下のコマンドを実行してシンボリックリンクをターゲットのコピーに置き換えます。
```
$ cd .. && rm -rf kmod-tree && cp -Lpr ${FAKEROOT} kmod-tree
```
カーネルモジュールツリーを埋め込む Butane 設定ファイル (99-simple-kmod.bu) を作成し、systemd サービスを有効にします。
注記
Butane の詳細は、Butane を使用したマシン設定の作成を参照してください。
```
variant: openshift
version: 4.11.0
metadata:
  name: 99-simple-kmod
  labels:
    machineconfiguration.openshift.io/role: worker 1
storage:
  trees:
    - local: kmod-tree
systemd:
  units:
    - name: kmods-via-containers@simple-kmod.service
      enabled: true
```
1
コントロールプレーンノードでデプロイするには、worker を master に変更します。コントロールプレーンおよびワーカーノードの両方にデプロイするには、それぞれのノードのタイプに対してこれらの残りの手順を 1 回ずつ実行します。
Butane を使用して、配信されるファイルおよび設定を含むマシン設定 YAML ファイルの 99-simple-kmod.yaml を生成します。
```
$ butane 99-simple-kmod.bu --files-dir . -o 99-simple-kmod.yaml
```
クラスターがまだ起動していない場合は、マニフェストファイルを生成し、そのファイルを openshift ディレクトリーに追加します。クラスターがすでに実行中の場合は、ファイルを以下のように適用します。
```
$ oc create -f 99-simple-kmod.yaml
```
ノードは kmods-via-containers@simple-kmod.service サービスを起動し、カーネルモジュールがロードされます。
カーネルモジュールがロードされていることを確認するには、ノードにログインすることができます (oc debug node/<openshift-node> を使用してから chroot /host を使用します)。モジュールをリスト表示するには、lsmod コマンドを使用します。
```
$ lsmod | grep simple_
```
出力例
```
simple_procfs_kmod     16384  0
simple_kmod            16384  0
```

24.1.4. インストール時のディスクの暗号化およびミラーリング

OpenShift Container Platform のインストール時に、クラスターノードでブートディスクの暗号化およびミラーリングを有効にできます。

24.1.4.1. ディスクの暗号化について

インストール時に、コントロールプレーンおよびコンピュートノードのブートディスクの暗号化を有効できます。OpenShift Container Platform は Trusted Platform Module (TPM) v2 および Tang 暗号化モードをサポートします。

TPM v2: これは優先されるモードです。TPM v2 は、サーバー内に含まれる安全な暗号プロセッサーにパスフレーズを保存します。このモードを使用すると、ディスクがサーバーから削除された場合にクラスターノードのブートディスクデータが復号化されないようにできます。
tang: Tang および Clevis は、ネットワークバインドディスク暗号化 (NBDE) を有効にするサーバーおよびクライアントコンポーネントです。クラスターノードのブートディスクデータを 1 つまたは複数の Tang サーバーにバインドできます。これにより、ノードが Tang サーバーにアクセスできるセキュアなネットワーク上にある場合を除き、データの復号化ができなくなります。Clevis は、クライアント側の復号化の実装に使用される自動復号化フレームワークです。

重要

Tang 暗号化モードを使用したディスクの暗号化は、ユーザーによってプロビジョニングされるインフラストラクチャーでのベアメタルおよび vSphere インストールでのみサポートされます。

注記

以前のバージョンの Red Hat Enterprise Linux CoreOS (RHCOS) では、ディスク暗号化は Ignition 設定で /etc/clevis.json を指定して設定されました。このファイルは、OpenShift Container Platform 4.7 以降で作成されたクラスターではサポートされず、ディスクの暗号化は以下の手順で設定される必要があります。

TPM v2 または Tang 暗号化モードを有効にすると、RHCOS ブートディスクは LUKS2 形式を使用して暗号化されます。

この機能には以下の特徴があります。

インストーラーでプロビジョニングされるインフラストラクチャーおよびユーザーによってプロビジョニングされるインフラストラクチャーのデプロイメントで利用可能である。
Red Hat Enterprise Linux CoreOS (RHCOS) システムのみでサポートされる。
マニフェストのインストールフェーズでディスク暗号化が設定される。これにより、初回起動時からディスクに書き込まれたすべてのデータが暗号化されます。
パスフレーズを提供するのにユーザーの介入を必要としない。
FIPS モードが有効な場合は、AES-256-XTS 暗号化、または AES-256-CBC を使用します。

24.1.4.1.1. 暗号化しきい値の設定

OpenShift Container Platform では、複数の Tang サーバーの要件を指定できます。TPM v2 および Tang 暗号化モードを同時に設定して、TPM のセキュアな暗号プロセッサーが存在し、安全なネットワーク上で Tang サーバーにアクセスできる場合にのみ、ブートディスクデータを復号化できます。

Butane 設定の threshold 属性を使用して、復号化できるようにするために必要な TPM v2 および Tang 暗号化条件の最小数を定義できます。宣言条件の組み合わせで指定値に到達した場合に、しきい値が満たされます。たとえば、2 台の Tang サーバーにアクセスするか、TPM のセキュアな暗号プロセッサーおよび Tang サーバーの 1 つにアクセスすることで、以下の設定の 2 しきい値 に到達できます。

ディスク暗号化の Butane 設定例

variant: openshift
version: 4.11.0
metadata:
  name: worker-storage
  labels:
    machineconfiguration.openshift.io/role: worker
boot_device:
  layout: x86_64 1
  luks:
    tpm2: true 2
    tang: 3
      - url: http://tang1.example.com:7500
        thumbprint: jwGN5tRFK-kF6pIX89ssF3khxxX
      - url: http://tang2.example.com:7500
        thumbprint: VCJsvZFjBSIHSldw78rOrq7h2ZF
    threshold: 2 4
openshift:
  fips: true

1: このフィールドをクラスターノードの命令セットアーキテクチャーに設定します。いくつかの例には、x86_64、aarch64、または ppc64le が含まれます。
2: Trusted Platform Module (TPM) を使用してルートファイルシステムを暗号化する場合は、このフィールドを追加してください。
3: 1 台以上の Tang サーバーを使用する必要がある場合は、このセクションを追加してください。
4: 復号化に実行に必要な TPM v2 および Tang 暗号化条件の最小数を指定します。

重要

デフォルトの しきい値 は 1 です。設定に複数の暗号化条件を追加するにも拘らず、しきい値を指定しない場合は、条件のいずれかが満たされている場合に復号化を実行できます。

注記

復号化に TPM v2 と Tang の両方が必要な場合には、しきい値 属性の値は、指定された Tang サーバーの合計数と 1 つの値である必要があります。しきい値 が低い場合には、暗号化モードのいずれかのみを使用してしきい値に到達できます。たとえば、tpm2 を true に設定して、2 台の Tang サーバーを指定すると、TPM の安全な暗号プロセッサーが利用できない場合でも 2 台の Tang サーバーにアクセスして、しきい値を 2 つ満たすことができます。

24.1.4.2. ディスクのミラーリングについて

コントロールプレーンおよびワーカーノードでの OpenShift Container Platform のインストール時に、ブートおよびその他のディスクの 2 つ以上の冗長ストレージデバイスへのミラーリングを有効にできます。ノードは、1 つのデバイスが利用可能な状態である限り、ストレージデバイスに障害が発生した後も引き続き機能します。

ミラーリングは、障害の発生したディスクの置き換えをサポートしません。ミラーを元の低下していない状態に復元するには、ノードを再プロビジョニングします。

注記

ユーザーがプロビジョニングしたインフラストラクチャーのデプロイメントの場合、ミラーリングは RHCOS システムのみで使用できます。ミラーリングのサポートは、BIOS または UEFI で起動された x86_64 ノードおよび ppc64le ノードで利用できます。

24.1.4.3. ディスク暗号化およびミラーリングの設定

OpenShift Container Platform のインストール時に暗号化およびミラーリングを有効にし、設定することができます。

前提条件

インストールノードで OpenShift Container Platform インストールプログラムをダウンロードしている。
インストールノードに Butane がインストールされている。
注記
Butane は、OpenShift Container Platform が使用するコマンドラインユーティリティーで、マシン設定を作成するための便利で簡略化した構文を提供したり、マシン設定の追加検証を実行したりします。詳細は、Butane を使用したマシン設定の作成 セクションを参照してください。
Tang 交換キーのサムプリントの生成に使用できる Red Hat Enterprise Linux (RHEL) 8 マシンにアクセスできる。

手順

TPM v2 を使用してクラスターを暗号化する必要がある場合、TPM v2 暗号化を各ノードの BIOS で有効にする必要があるかどうかを確認します。これは、ほとんどの Dell システムで必要になります。コンピューターのマニュアルを確認してください。
Tang を使用してクラスターを暗号化する必要がある場合は、以下の準備段階の手順に従います。
1. Tang サーバーを設定するか、既存のサーバーにアクセスします。手順については、NBDE (Network-Bound Disk Encryption) を参照してください。
2. RHEL 8 マシンに clevis パッケージがインストールされていない場合はインストールします。
```
$ sudo yum install clevis
```
3. RHEL 8 マシンで以下のコマンドを実行し、交換キーのサムプリントを生成します。http://tang.example.com:7500 を Tang サーバーの URL に置き換えます。
```
$ clevis-encrypt-tang '{"url":"http://tang.example.com:7500"}' < /dev/null > /dev/null 1
```
  1
  この例では、tangd.socket は Tang サーバーのポート 7500 でリッスンしています。
  注記
  このステップでは、clevis-encrypt-tang コマンドを使用して、交換キーのサムプリントを生成します。この時点で暗号化用のデータがコマンドに渡されないため、/dev/null はプレーンテキストではなく、インプットとして提供されます。この手順には必要ないため、暗号化された出力は /dev/null に送信されます。
  出力例
```
The advertisement contains the following signing keys:

PLjNyRdGw03zlRoGjQYMahSZGu9 1
```
  1
  エクスチェンジキーのサムプリント。
  Do you want to trust these keys? [ynYN] のプロンプトが表示されたら、Y と入力します。
  注記
  RHEL 8 には、Clevis バージョン 15 が同梱されており、SHA-1 ハッシュアルゴリズムを使用してサムプリントを生成します。その他のディストリビューションには、Clevis バージョン 17 以降があり、サムプリントに SHA-256 ハッシュアルゴリズムを使用します。サムプリントを作成するために SHA-1 を使用する Clevis バージョンを使用し、OpenShift Container Platform クラスターノードに Red Hat Enterprise Linux CoreOS (RHCOS) のインストール時に Clevis バインディングの問題を防ぐ必要があります。
4. ノードが静的 IP アドレス指定で設定されている場合は、RHCOS ノードをインストールするときに coreos-installer iso customize --dest-karg-append を実行するか、coreos-installer --append-karg オプションを使用して、インストール済みシステムの IP アドレスを設定します。ネットワークに必要な ip= およびその他の引数を追加します。
  重要
  一部の静的 IP の設定方法は、初回のブート後に initramfs に影響を与えず、Tang 暗号化では機能しない場合があります。これらには、coreos-installer --copy-network オプション、coreos-installer iso customize --network-keyfile オプション、および coreos-installer pxe customize --network-keyfile オプションが含まれるほか、インストール中のライブ ISO または PXE イメージのカーネルコマンドラインに ip= 引数が追加されます。静的 IP 設定が間違っていると、ノードの 2 回目のブートが失敗します。
インストールノードで、インストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
```
$ ./openshift-install create manifests --dir <installation_directory> 1
```
1
<installation_directory> は、インストールファイルを保存するディレクトリーへのパスに置き換えます。
ディスクの暗号化、ミラーリング、またはそれら両方を設定する Butane 設定を作成します。たとえば、コンピュートノードのストレージを設定するには、$HOME/clusterconfig/worker-storage.bu ファイルを作成します。
起動デバイスの Butane 設定例
```
variant: openshift
version: 4.11.0
metadata:
  name: worker-storage 1
  labels:
    machineconfiguration.openshift.io/role: worker 2
boot_device:
  layout: x86_64 3
  luks: 4
    tpm2: true 5
    tang: 6
      - url: http://tang.example.com:7500 7
        thumbprint: PLjNyRdGw03zlRoGjQYMahSZGu9 8
    threshold: 1 9
  mirror: 10
    devices: 11
      - /dev/sda
      - /dev/sdb
openshift:
  fips: true 12
```
1 2
コントロールプレーンの設定については、これらの両方の場所で worker を master に置き換えます。
3
このフィールドをクラスターノードの命令セットアーキテクチャーに設定します。いくつかの例には、x86_64、aarch64、または ppc64le が含まれます。
4
ルートファイルシステムを暗号化する必要がある場合は、このセクションを追加してください。詳細は、ディスク暗号化について のセクションを参照してください。
5
Trusted Platform Module (TPM) を使用してルートファイルシステムを暗号化する場合は、このフィールドを追加してください。
6
1 台以上の Tang サーバーを使用する必要がある場合は、このセクションを追加してください。
7
Tang サーバーの URL を指定します。この例では、tangd.socket は Tang サーバーのポート 7500 でリッスンしています。
8
前述のステップで生成された Exchange キーサムプリントを指定します。
9
復号化に実行に必要な TPM v2 および Tang 暗号化条件の最小数を指定します。デフォルト値は 1 です。このトピックに関する詳細情報は、暗号化しきい値の設定 セクションを参照してください。
10
ブートディスクをミラーリングする必要がある場合は、このセクションを追加してください。詳細は、ディスクのミラーリングについて を参照してください。
11
RHCOS がインストールされるディスクを含む、ブートディスクミラーに含まれる必要があるすべてのディスクデバイスをリスト表示します。
12
クラスターで FIPS モードを有効にするためにこのディレクティブを追加します。
重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストールを参照してください。ノードをディスク暗号化とミラーリングの両方を使用するように設定する場合、両方の機能を同じ Butane 設定ファイルに設定する必要があります。さらに、FIPS モードが有効にされたノードでディスク暗号化を設定する場合、FIPS モードが別のマニフェストで有効化されている場合でも、同じ Butane 設定ファイルに fips ディレクティブを追加する必要があります。
対応する Butane 設定ファイルからコントロールプレーンまたはコンピュートノードのマニフェストを作成し、<installation_directory>/openshift ディレクトリーに保存します。たとえば、コンピュートノードのマニフェストを作成するには、以下のコマンドを実行します。
```
$ butane $HOME/clusterconfig/worker-storage.bu -o <installation_directory>/openshift/99-worker-storage.yaml
```
ディスクの暗号化またはミラーリングを必要とするノード種別ごとに、この手順を繰り返します。
今後マニフェストを更新する必要がある場合には、Butane 設定ファイルを保存します。
残りの OpenShift Container Platform インストールを継続します。
ヒント
インストール時に、ディスク暗号化またはミラーリングに関連するエラーメッセージがないか、RHCOS ノードでコンソールログをモニタリングできます。
重要
追加のデータパーティションを設定する場合、暗号化が明示的に要求されない限り、それらは暗号化されません。

検証

OpenShift Container Platform のインストール後に、ブートディスクの暗号化またはミラーリングがクラスターノードで有効にされているかどうかを確認できます。

インストールホストから、デバッグ Pod を使用してクラスターノードにアクセスします。
1. ノードのデバッグ Pod を起動します。以下の例では、compute-1 ノードのデバッグ Pod を起動します。
```
$ oc debug node/compute-1
```
2. /host をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の /host にノードのルートファイルシステムをマウントします。root ディレクトリーを /host に変更すると、ノードの実行可能パスに含まれるバイナリーを実行できます。
```
# chroot /host
```
  注記
  Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されません。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。
ブートディスクの暗号化を設定している場合は、有効であるかどうかを確認します。
1. デバッグシェルで、ノードでのルートマッピングのステータスを確認します。
```
# cryptsetup status root
```
  出力例
```
/dev/mapper/root is active and is in use.
  type:    LUKS2 1
  cipher:  aes-xts-plain64 2
  keysize: 512 bits
  key location: keyring
  device:  /dev/sda4 3
  sector size:  512
  offset:  32768 sectors
  size:    15683456 sectors
  mode:    read/write
```
  1
  暗号化形式。TPM v2 または Tang 暗号化モードを有効にすると、RHCOS ブートディスクは LUKS2 形式を使用して暗号化されます。
  2
  LUKS2 ボリュームの暗号化に使用される暗号化アルゴリズム。FIPS モードが有効な場合には 、aes-cbc-essiv:sha256 暗号が使用されます。
  3
  暗号化した LUKS2 ボリュームを含むデバイス。ミラーリングを有効にすると、値は /dev/md126 などのソフトウェアミラーデバイスを表します。
2. 暗号化されたデバイスにバインドされる Clevis プラグインを一覧表示します。
```
# clevis luks list -d /dev/sda4 1
```
  1
  前述のステップの出力の device フィールドに一覧表示されるデバイスを指定します。
  出力例
```
1: sss '{"t":1,"pins":{"tang":[{"url":"http://tang.example.com:7500"}]}}' 1
```
  1
  この出力例では、Tang プラグインは、/dev/sda4 デバイスの Shamir の Secret Sharing (SSS) Clevis プラグインにより使用されます。

ミラーリングを設定している場合は、有効かどうかを確認します。

デバッグシェルから、ノードにあるソフトウェアの RAID デバイスのリストを表示します。
```
# cat /proc/mdstat
```
出力例
```
Personalities : [raid1]
md126 : active raid1 sdb3[1] sda3[0] 1
	  393152 blocks super 1.0 [2/2] [UU]

md127 : active raid1 sda4[0] sdb4[1] 2
	  51869632 blocks super 1.2 [2/2] [UU]

unused devices: <none>
```
1
この例では、/dev/md126 ソフトウェア RAID ミラーデバイスは、クラスターノードの /dev/sda3 および /dev/sdb3 ディスクデバイスを使用します。
2
この例では、/dev/md127 ソフトウェア RAID ミラーデバイスは、クラスターノードの /dev/sda4 および /dev/sdb4 ディスクデバイスを使用します。

上記のコマンドの出力に記載されている各ソフトウェア RAID デバイスの詳細を確認してください。以下の例は、/dev/md126 デバイスの詳細を示しています。

# mdadm --detail /dev/md126

出力例

/dev/md126:
           Version : 1.0
     Creation Time : Wed Jul  7 11:07:36 2021
        Raid Level : raid1 1
        Array Size : 393152 (383.94 MiB 402.59 MB)
     Used Dev Size : 393152 (383.94 MiB 402.59 MB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

       Update Time : Wed Jul  7 11:18:24 2021
             State : clean 2
    Active Devices : 2 3
   Working Devices : 2 4
    Failed Devices : 0 5
     Spare Devices : 0

Consistency Policy : resync

              Name : any:md-boot 6
              UUID : ccfa3801:c520e0b5:2bee2755:69043055
            Events : 19

    Number   Major   Minor   RaidDevice State
       0     252        3        0      active sync   /dev/sda3 7
       1     252       19        1      active sync   /dev/sdb3 8

1: デバイスの RAID レベルを指定します。raid1 は、RAID 1 ディスクミラーリングを示します。
2: RAID デバイスの状態を指定します。
3 4: アクティブかつ機能している基礎となるディスクデバイスの数を示します。
5: ステータスが failed のディスクデバイスの数を示します。
6: ソフトウェア RAID デバイスの名前。
7 8: ソフトウェア RAID デバイスが使用する基礎となるディスクデバイスに関する情報を提供します。

ソフトウェア RAID デバイスにマウントされているファイルシステムのリストを表示します。

# mount | grep /dev/md

出力例

/dev/md127 on / type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
/dev/md127 on /etc type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
/dev/md127 on /usr type xfs (ro,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
/dev/md127 on /sysroot type xfs (ro,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
/dev/md127 on /var type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
/dev/md127 on /var/lib/containers/storage/overlay type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
/dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/1 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
/dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/2 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
/dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/3 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
/dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/4 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
/dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/5 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
/dev/md126 on /boot type ext4 (rw,relatime,seclabel)

この出力例では、/boot ファイルシステムが /dev/md126 software RAID デバイスに、root ファイルシステムが /dev/md127 にマウントされ t ています。

OpenShift Container Platform ノードタイプごとに検証手順を繰り返します。

関連情報

TPM v2 および Tang 暗号化モードの詳細は、ポリシーベースの複号を使用して暗号化ボリュームの自動アンロックの設定を参照してください。

24.1.4.4. RAID 対応のデータボリュームの設定

ソフトウェア RAID のパーティション設定を有効にして、外部データボリュームを提供できます。OpenShift Container Platform は、データ保護およびフォールトトレランスに対応するために RAID 0、RAID 1、RAID 4、RAID 5、RAID 6、および RAID 10 をサポートします。詳細は、ディスクのミラーリングについてを参照してください。

前提条件

インストールノードで OpenShift Container Platform インストールプログラムをダウンロードしている。
インストールノードに Butane をインストールしている。
注記
Butane は、OpenShift Container Platform が使用するコマンドラインユーティリティーで、マシン設定を作成するための便利で簡略化した構文を提供したり、マシン設定の追加検証を実行したりします。詳細は、Butane を使用したマシン設定の作成 セクションを参照してください。

手順

ソフトウェア RAID を使用してデータボリュームを設定する Butane 設定を作成します。

ミラーリングされた起動ディスクに使用されるのと同じディスク上に RAID 1 を使用してデータボリュームを設定するには、$HOME/clusterconfig/raid1-storage.bu ファイルを作成します。以下に例を示します。
ミラーリングされた起動ディスク上の RAID 1
```
variant: openshift
version: 4.11.0
metadata:
  name: raid1-storage
  labels:
    machineconfiguration.openshift.io/role: worker
boot_device:
  mirror:
    devices:
      - /dev/sda
      - /dev/sdb
storage:
  disks:
    - device: /dev/sda
      partitions:
        - label: root-1
          size_mib: 25000 1
        - label: var-1
    - device: /dev/sdb
      partitions:
        - label: root-2
          size_mib: 25000 2
        - label: var-2
  raid:
    - name: md-var
      level: raid1
      devices:
        - /dev/disk/by-partlabel/var-1
        - /dev/disk/by-partlabel/var-2
  filesystems:
    - device: /dev/md/md-var
      path: /var
      format: xfs
      wipe_filesystem: true
      with_mount_unit: true
```
1 2
データパーティションをブートディスクに追加する場合は、25000 のメビバイトの最小値が推奨されます。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。

セカンダリーディスク上に RAID 1 を使用してデータボリュームを設定するには、$HOME/clusterconfig/raid1-alt-storage.bu ファイルを作成します。以下に例を示します。

セカンダリーディスク上の RAID 1

variant: openshift
version: 4.11.0
metadata:
  name: raid1-alt-storage
  labels:
    machineconfiguration.openshift.io/role: worker
storage:
  disks:
    - device: /dev/sdc
      wipe_table: true
      partitions:
        - label: data-1
    - device: /dev/sdd
      wipe_table: true
      partitions:
        - label: data-2
  raid:
    - name: md-var-lib-containers
      level: raid1
      devices:
        - /dev/disk/by-partlabel/data-1
        - /dev/disk/by-partlabel/data-2
  filesystems:
    - device: /dev/md/md-var-lib-containers
      path: /var/lib/containers
      format: xfs
      wipe_filesystem: true
      with_mount_unit: true

前のステップで作成した Butane 設定から RAID マニフェストを作成し、それを <installation_directory>/openshift ディレクトリーに保存します。たとえば、コンピュートノードのマニフェストを作成するには、以下のコマンドを実行します。
```
$ butane $HOME/clusterconfig/<butane_config>.bu -o <installation_directory>/openshift/<manifest_name>.yaml 1
```
1
<butane_config> および <manifest_name> を直前の手順のファイル名に置き換えます。たとえば、セカンダリーディスクの場合は、raid1-alt-storage.bu および raid1-alt-storage.yaml になります。
今後マニフェストを更新する必要がある場合には、Butane 設定を保存します。
残りの OpenShift Container Platform インストールを継続します。

24.1.5. chrony タイムサービスの設定

chrony タイムサービス (chronyd) で使用されるタイムサーバーおよび関連する設定は、chrony.conf ファイルのコンテンツを変更し、それらのコンテンツをマシン設定としてノードに渡して設定できます。

手順

chrony.conf ファイルのコンテンツを含む Butane 設定を作成します。たとえば、ワーカーノードで chrony を設定するには、99-worker-chrony.bu ファイルを作成します。
注記
Butane の詳細は、Butane を使用したマシン設定の作成を参照してください。
```
variant: openshift
version: 4.11.0
metadata:
  name: 99-worker-chrony 1
  labels:
    machineconfiguration.openshift.io/role: worker 2
storage:
  files:
  - path: /etc/chrony.conf
    mode: 0644 3
    overwrite: true
    contents:
      inline: |
        pool 0.rhel.pool.ntp.org iburst 4
        driftfile /var/lib/chrony/drift
        makestep 1.0 3
        rtcsync
        logdir /var/log/chrony
```
1 2
コントロールプレーンノードでは、これらの両方の場所で worker の代わりに master を使用します。
3
マシン設定ファイルの mode フィールドに 8 進数の値でモードを指定します。ファイルを作成し、変更を適用すると、mode は 10 進数の値に変換されます。コマンド oc get mc <mc-name> -o yaml で YAML ファイルを確認できます。
4
DHCP サーバーが提供するものなど、有効な到達可能なタイムソースを指定します。または、NTP サーバーの 1.rhel.pool.ntp.org、2.rhel.pool.ntp.org、または 3.rhel.pool.ntp.org のいずれかを指定できます。
Butane を使用して、ノードに配信される設定を含む MachineConfig オブジェクトファイル (99-worker-chrony.yaml) を生成します。
```
$ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml
```
以下の 2 つの方法のいずれかで設定を適用します。
- クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、MachineConfig オブジェクトファイルを <installation_directory>/openshift ディレクトリーに追加してから、クラスターの作成を続行します。
- クラスターがすでに実行中の場合は、ファイルを適用します。
```
$ oc apply -f ./99-worker-chrony.yaml
```

24.1.6. 関連情報

Butane の詳細は、Butane を使用したマシン設定の作成を参照してください。
FIPS サポートの詳細は、FIPS 暗号のサポートを参照してください。

第24章インストール設定

24.1. ノードのカスタマイズ

24.1.1. Butane でのマシン設定の作成

24.1.1.1. Butane について

24.1.1.2. Butane のインストール

24.1.1.3. Butane を使用した MachineConfig オブジェクトの作成

24.1.2. day-1 カーネル引数の追加

24.1.3. カーネルモジュールのノードへの追加

24.1.3.1. カーネルモジュールコンテナーのビルドおよびテスト

24.1.3.2. カーネルモジュールの OpenShift Container Platform へのプロビジョニング

24.1.3.2.1. MachineConfig オブジェクトを介したカーネルモジュールのプロビジョニング

24.1.4. インストール時のディスクの暗号化およびミラーリング

24.1.4.1. ディスクの暗号化について

24.1.4.1.1. 暗号化しきい値の設定

24.1.4.2. ディスクのミラーリングについて

24.1.4.3. ディスク暗号化およびミラーリングの設定

24.1.4.4. RAID 対応のデータボリュームの設定

24.1.5. chrony タイムサービスの設定

24.1.6. 関連情報

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

第24章 インストール設定

24.1. ノードのカスタマイズ

24.1.1. Butane でのマシン設定の作成

24.1.1.1. Butane について

24.1.1.2. Butane のインストール

24.1.1.3. Butane を使用した MachineConfig オブジェクトの作成

24.1.2. day-1 カーネル引数の追加

24.1.3. カーネルモジュールのノードへの追加

24.1.3.1. カーネルモジュールコンテナーのビルドおよびテスト

24.1.3.2. カーネルモジュールの OpenShift Container Platform へのプロビジョニング

24.1.3.2.1. MachineConfig オブジェクトを介したカーネルモジュールのプロビジョニング

24.1.4. インストール時のディスクの暗号化およびミラーリング

24.1.4.1. ディスクの暗号化について

24.1.4.1.1. 暗号化しきい値の設定

24.1.4.2. ディスクのミラーリングについて

24.1.4.3. ディスク暗号化およびミラーリングの設定

24.1.4.4. RAID 対応のデータボリュームの設定

24.1.5. chrony タイムサービスの設定

24.1.6. 関連情報

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

第24章インストール設定