第17章 インストール設定
17.1. ノードのカスタマイズ
OpenShift Container Platform ノードへの直接の変更は推奨されませんが、必要とされる低レベルのセキュリティー、冗長性、ネットワーク、またはパフォーマンス機能を実装することが必要になる場合があります。OpenShift Container Platform ノードへの直接の変更は、以下によって実行できます。
-
openshift-install
の実行時にクラスターを起動するためにマニフェストファイルに組み込まれるマシン設定を作成します。 - Machine Config Operator を使用して実行中の OpenShift Container Platform ノードに渡されるマシン設定を作成します。
-
ベアメタルノードのインストール時に
coreos-installer
に渡される Ignition 設定を作成します。
以下のセクションでは、この方法でノード上で設定する必要が生じる可能性のある機能について説明します。
17.1.1. day-1 カーネル引数の追加
多くの場合、カーネル引数を day-2 アクティビティーとして変更することが推奨されますが、初期クラスターのインストール時にすべてのマスターまたはワーカーノードにカーネル引数を追加することができます。以下は、クラスターのインストール時にカーネル引数を追加して、システムの初回起動前に有効にする必要が生じる可能性のある理由です。
- SELinux などの機能を無効にし、初回起動時にシステムに影響を与えないようにする必要がある場合。
RHCOS での 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 ファイルを作成します。
クラスターの作成を継続できます。
17.1.2. カーネルモジュールのノードへの追加
大半の一般的なハードウェアの場合、Linux カーネルには、コンピューターの起動時にそのハードウェアを使用するために必要となるデバイスドライバーモジュールが含まれます。ただし、一部のハードウェアの場合、Linux でモジュールを利用できません。したがって、各ホストコンピューターにこれらのモジュールを提供する方法を確保する必要があります。この手順では、OpenShift Container Platform クラスターのノードについてこれを実行する方法を説明します。
この手順に従ってカーネルモジュールを最初にデプロイする際、モジュールは現行のカーネルに対して利用可能になります。新規カーネルがインストールされると、kmods-via-containers ソフトウェアはモジュールを再ビルドし、デプロイしてそのモジュールの新規カーネルと互換性のあるバージョンが利用可能になるようにします。
この機能によって各ノードでモジュールが最新の状態に保てるようにするために、以下が実行されます。
- 新規カーネルがインストールされているかどうかを検出するために、システムの起動時に起動する各ノードに systemd サービスを追加します。
- 新規カーネルが検出されると、サービスはモジュールを再ビルドし、これをカーネルにインストールします。
この手順に必要なソフトウェアの詳細については、kmods-via-containers github サイトを参照してください。
以下の重要な点に留意してください。
- この手順はテクノロジープレビューです。
-
ソフトウェアのツールおよびサンプルは公式の RPM 形式で利用できず、現時点ではこの手順に記載されている非公式の
github.com
サイトからしか取得できません。 - この手順で追加する必要がある可能性のあるサードパーティーのカーネルモジュールについては Red Hat はサポートしません。
-
この手順では、カーネルモジュールのビルドに必要なソフトウェアは RHEL 8 コンテナーにデプロイされます。モジュールは、ノードが新規カーネルを取得する際に各ノードで自動的に再ビルドされることに注意してください。このため、各ノードには、モジュールの再ビルドに必要なカーネルと関連パッケージを含む
yum
リポジトリーへのアクセスが必要です。このコンテンツは、有効な RHEL サブスクリプションを使用して効果的に利用できます。
17.1.2.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
リポジトリーのクローンを作成します。リポジトリーのフォルダーを作成します。
$ mkdir kmods; cd kmods
リポジトリーのクローンを作成します。
$ git clone https://github.com/kmods-via-containers/kmods-via-containers
RHEL 8 ビルドホストに KVC フレームワークインスタンスをインストールし、モジュールをテストします。これにより、
kmods-via-container
systemd サービスが追加され、読み込まれます。kmod-via-containers
ディレクトリーに移動します。$ cd kmods-via-containers/
KVC フレームワークインスタンスをインストールします。
$ sudo make install
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
その後は、システムの起動時に、このサービスは新規カーネルが実行中であるかどうかをチェックします。新規カーネルがある場合は、サービスは新規バージョンのカーネルモジュールをビルドし、これをロードします。モジュールがすでにビルドされている場合は、これをロードします。
17.1.2.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
リポジトリーへのポインターを追加します。これには、新たにインストールされたカーネルと一致させる必要があるため、新規のカーネルパッケージが含まれている必要があります。
17.1.2.2.1. MachineConfig
オブジェクトでのカーネルモジュールのプロビジョニング
MachineConfig
オブジェクト でカーネルモジュールソフトウェアをパッケージ化することで、そのソフトウェアをインストール時に、または Machine Config Operator を使用してワーカーまたはマスターノードに配信できます。
まず、使用するベース Ignition 設定を作成します。インストール時に、Ignition 設定にはクラスターの core
ユーザーの authorized_keys
ファイルに追加する ssh パブリックキーが含まれます。後で MCO を使用して MachineConfig
を追加する場合、ssh パブリックキーは不要になります。どちらのタイプでも、サンプルの simple-kmod サービスは kmods-via-containers@simple-kmod.service
を必要とする systemd ユニットファイルを作成します。
systemd ユニットは アップストリームのバグ に対する回避策であり、kmods-via-containers@simple-kmod.service
が起動時に開始するようにします。
RHEL 8 システムを登録します。
# subscription-manager register
RHEL 8 システムにサブスクリプションを割り当てます。
# subscription-manager attach --auto
ソフトウェアのビルドに必要なソフトウェアをインストールします。
# yum install podman make git -y
systemd ユニットファイルを作成する Ignition 設定ファイルを作成します。
Ignition 設定ファイルをホストするディレクトリーを作成します。
$ mkdir kmods; cd kmods
systemd ユニットファイルを作成する Ignition 設定ファイルを作成します。
$ cat <<EOF > ./baseconfig.ign { "ignition": { "version": "3.2.0" }, "passwd": { "users": [ { "name": "core", "groups": ["sudo"], "sshAuthorizedKeys": [ "ssh-rsa AAAA" ] } ] }, "systemd": { "units": [{ "name": "require-kvc-simple-kmod.service", "enabled": true, "contents": "[Unit]\nRequires=kmods-via-containers@simple-kmod.service\n[Service]\nType=oneshot\nExecStart=/usr/bin/true\n\n[Install]\nWantedBy=multi-user.target" }] } } EOF
注記openshift-install
の実行時に、パブリック SSH キーを使用するbaseconfig.ign
ファイルに追加する必要があります。MCO を使用してMachineConfig
オブジェクトを作成する場合、パブリック SSH キーは必要ありません。
以下の設定を使用するベース MCO YAML スニペットを作成します。
$ cat <<EOF > mc-base.yaml apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 10-kvc-simple-kmod spec: config: EOF
注記mc-base.yaml
は、worker
ノードにカーネルモジュールをデプロイするように設定されます。マスターノードでデプロイするには、ロールをworker
からmaster
に変更します。どちらの方法でも、デプロイメントの種類ごとに異なるファイル名を使用して手順全体を繰り返すことができます。kmods-via-containers
ソフトウェアを取得します。kmods-via-containers
リポジトリーのクローンを作成します。$ git clone https://github.com/kmods-via-containers/kmods-via-containers
kvc-simple-kmod
リポジトリーのクローンを作成します。$ git clone https://github.com/kmods-via-containers/kvc-simple-kmod
-
モジュールソフトウェアを取得します。この例では、
kvc-simple-kmod
が使用されます。 fakeroot ディレクトリーを作成し、先にクローン作成したリポジトリーを使用して Ignition で配信するファイルを使用してこれを設定します。
ディレクトリーを作成します。
$ FAKEROOT=$(mktemp -d)
kmod-via-containers
ディレクトリーに移動します。$ cd kmods-via-containers
KVC フレームワークインスタンスをインストールします。
$ make install DESTDIR=${FAKEROOT}/usr/local CONFDIR=${FAKEROOT}/etc/
kvc-simple-kmod
ディレクトリーに移動します。$ cd ../kvc-simple-kmod
インスタンスを作成します。
$ make install DESTDIR=${FAKEROOT}/usr/local CONFDIR=${FAKEROOT}/etc/
filetranspiler
というツールおよび依存するソフトウェアを取得します。$ cd .. ; sudo yum install -y python3 git clone https://github.com/ashcrow/filetranspiler.git
最終的なマシン設定 YAML(
mc.yaml
) を生成し、これに配信するファイルと共にベース Ignition 設定、ベースマシン設定、および fakeroot ディレクトリーを含めます。$ ./filetranspiler/filetranspile -i ./baseconfig.ign \ -f ${FAKEROOT} --format=yaml --dereference-symlinks \ | sed 's/^/ /' | (cat mc-base.yaml -) > 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
17.1.3. インストール時のディスクの暗号化
インストール時に、コントロールプレーンおよびコンピュートノードのブートディスクの暗号化を有効できます。OpenShift Container Platform は Trusted Platform Module (TPM) v2 および Tang 暗号化モードをサポートします。
- TPM v2: これは優先されるモードです。TPM v2 は、サーバー内に含まれる安全な暗号プロセッサーにパスフレーズを保存します。このモードを使用すると、ディスクがサーバーから削除された場合にクラスターノードのブートディスクデータが復号化されないようにできます。
- tang: Tang および Clevis は、ネットワークバインドディスク暗号化 (NBDE) を有効にするサーバーおよびクライアントコンポーネントです。クラスターノードのブートディスクデータを Tang サーバーにバインドできます。これにより、ノードが Tang サーバーにアクセスできるセキュアなネットワーク上にある場合を除き、データの復号化ができなくなります。Clevis は、クライアント側の復号化の実装に使用される自動復号化フレームワークです。
Tang 暗号化モードを使用したディスクの暗号化は、ユーザーによってプロビジョニングされるインフラストラクチャーでのベアメタルおよび vSphere インストールでのみサポートされます。
TPM v2 または Tang 暗号化モードを有効にすると、RHCOS ブートディスクは LUKS2 形式を使用して暗号化されます。
この機能には以下の特徴があります。
- インストーラーでプロビジョニングされるインフラストラクチャーおよびユーザーによってプロビジョニングされるインフラストラクチャーのデプロイメントで利用可能である。
- Red Hat Enterprise Linux CoreOS (RHCOS) システムのみでサポートされる。
- マニフェストのインストールフェーズでディスク暗号化が設定される。これにより、初回起動時からディスクに書き込まれたすべてのデータが暗号化されます。
- パスフレーズを提供するのにユーザーの介入を必要としない。
- AES-256-CBC 暗号化を使用する。
クラスター内のノードのディスク暗号化を有効にするには、以下の 2 つの手順の内のいずれかに従います。
17.1.3.1. TPM v2 ディスク暗号化の有効化
以下の手順を使用して、OpenShift Container Platform のインストール時に TPM v2 モードディスクの暗号化を有効にします。
以前のバージョンの RHCOS では、ディスク暗号化は Ignition 設定で /etc/clevis.json
を指定して設定されました。このファイルは、OpenShift Container Platform 4.7 以降で作成されたクラスターではサポートされません。LUKS デバイスは Ignition luks
セクションで直接設定する必要があります。
前提条件
- インストールノードで OpenShift Container Platform インストールプログラムをダウンロードしている。
手順
- TPM v2 暗号化を各ノードの BIOS で有効にする必要があるかどうかを確認します。これは、ほとんどの Dell システムで必要になります。コンピューターのマニュアルを確認してください。
インストールノードで、インストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
$ ./openshift-install create manifests --dir <installation_directory> 1
- 1
<installation_directory>
は、インストールファイルを保存するディレクトリーへのパスに置き換えます。
マシン設定ファイルを作成し、TPM v2 暗号化モードを使用してコントロールプレーンまたはコンピュートノードのブートディスクを暗号化します。
重要影響を受けるノードでブートディスクのミラーリングも設定する場合も、この手順を省略します。ブートディスクのミラーリングを設定する際にディスクの暗号化を設定します。
コントロールプレーンノードで暗号化を設定するには、以下のマシン設定サンプルを
<installation_directory>/openshift
ディレクトリーのファイルに保存します。たとえば、ファイルに99-openshift-master-tpmv2-encryption.yaml
などの名前を付けます。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: master-tpm labels: machineconfiguration.openshift.io/role: master spec: config: ignition: version: 3.2.0 storage: luks: - name: root device: /dev/disk/by-partlabel/root clevis: tpm2: true 1 options: [--cipher, aes-cbc-essiv:sha256] wipeVolume: true filesystems: - device: /dev/mapper/root format: xfs wipeFilesystem: true label: root
- 1
- Trusted Platform Module (TPM) セキュア暗号化プロセッサーを使用して root ファイルシステムを暗号化する場合は、この属性を
true
に設定します。
コンピュートノードで暗号化を設定するには、以下のマシン設定サンプルを
<installation_directory>/openshift
ディレクトリーのファイルに保存します。たとえば、ファイルに99-openshift-worker-tpmv2-encryption.yaml
などの名前を付けます。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: worker-tpm labels: machineconfiguration.openshift.io/role: worker spec: config: ignition: version: 3.2.0 storage: luks: - name: root device: /dev/disk/by-partlabel/root clevis: tpm2: true 1 options: [--cipher, aes-cbc-essiv:sha256] wipeVolume: true filesystems: - device: /dev/mapper/root format: xfs wipeFilesystem: true label: root
- 1
- Trusted Platform Module (TPM) セキュア暗号化プロセッサーを使用して root ファイルシステムを暗号化する場合は、この属性を
true
に設定します。
- YAML ファイルのバックアップコピーを作成します。元の YAML ファイルは Ignition 設定ファイルの作成時に使用されます。
- 残りの OpenShift Container Platform のデプロイメントを継続します。
追加のデータパーティションを設定する場合、暗号化が明示的に要求されない限り、それらは暗号化されません。
17.1.3.2. Tang ディスク暗号化の有効化
以下の手順を使用して、OpenShift Container Platform のインストール時に Tang モードディスクの暗号化を有効にします。
以前のバージョンの RHCOS では、ディスク暗号化は Ignition 設定で /etc/clevis.json
を指定して設定されました。このファイルは、OpenShift Container Platform 4.7 以降で作成されたクラスターではサポートされません。LUKS デバイスは Ignition luks
セクションで直接設定する必要があります。
前提条件
- インストールノードで OpenShift Container Platform インストールプログラムをダウンロードしている。
- Tang 交換キーのサムプリントの生成に使用できる Red Hat Enterprise Linux (RHEL) 8 マシンにアクセスできる。
手順
- Tang サーバーを設定するか、または既存のサーバーにアクセスします。手順については、NBDE (Network-Bound Disk Encryption) を参照してください。
クラスターについて Red Hat Enterprise Linux CoreOS (RHCOS) インストールを実行する際にネットワークを設定するためにカーネル引数を追加します。たとえば、DHCP ネットワークを設定するには、
ip=dhcp
を特定するか、またはカーネルコマンドラインにパラメーターを追加する際に静的ネットワークを設定します。DHCP と静的ネットワークの両方の場合、rd.neednet=1
カーネル引数も指定する必要があります。重要このステップを省略すると、2 番目の起動に失敗します。
RHEL 8 マシンに
clevis
パッケージがインストールされていない場合はインストールします。$ sudo yum install clevis
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 バインディングの問題を防ぐ必要があります。
Kubernetes マニフェストを生成していない場合は、インストールノードでインストールプログラムが含まれるディレクトリーに移動してマニフェストを作成します。
$ ./openshift-install create manifests --dir <installation_directory> 1
- 1
<installation_directory>
は、インストールファイルを保存するディレクトリーへのパスに置き換えます。
マシン設定ファイルを作成して Tang 暗号化モードを使用し、コントロールプレーンまたはコンピュートノードのブートディスクを暗号化します。
重要影響を受けるノードでブートディスクのミラーリングを設定する場合も、後で使用するためにエクスチェンジキーのサムプリントを記録し、この手順を省略します。ブートディスクのミラーリングを設定する際にディスクの暗号化を設定します。
コントロールプレーンノードで暗号化を設定するには、以下のマシン設定サンプルを
<installation_directory>/openshift
ディレクトリーのファイルに保存します。たとえば、ファイルに99-openshift-master-tang-encryption.yaml
などの名前を付けます。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: master-tang labels: machineconfiguration.openshift.io/role: master spec: config: ignition: version: 3.2.0 storage: luks: - name: root device: /dev/disk/by-partlabel/root clevis: tang: - url: http://tang.example.com:7500 1 thumbprint: PLjNyRdGw03zlRoGjQYMahSZGu9 2 options: [--cipher, aes-cbc-essiv:sha256] wipeVolume: true filesystems: - device: /dev/mapper/root format: xfs wipeFilesystem: true label: root kernelArguments: - rd.neednet=1 3
コンピュートノードで暗号化を設定するには、以下のマシン設定サンプルを
<installation_directory>/openshift
ディレクトリーのファイルに保存します。たとえば、ファイルに99-openshift-worker-tang-encryption.yaml
などの名前を付けます。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: worker-tang labels: machineconfiguration.openshift.io/role: worker spec: config: ignition: version: 3.2.0 storage: luks: - name: root device: /dev/disk/by-partlabel/root clevis: tang: - url: http://tang.example.com:7500 1 thumbprint: PLjNyRdGw03zlRoGjQYMahSZGu9 2 options: [--cipher, aes-cbc-essiv:sha256] wipeVolume: true filesystems: - device: /dev/mapper/root format: xfs wipeFilesystem: true label: root kernelArguments: - rd.neednet=1 3
- YAML ファイルのバックアップコピーを作成します。元の YAML ファイルは Ignition 設定ファイルの作成時に使用されます。
- 残りの OpenShift Container Platform インストールを継続します。
追加のデータパーティションを設定する場合、暗号化が明示的に要求されない限り、それらは暗号化されません。
17.1.4. インストール時のディスクのミラーリング
コントロールプレーンおよびコンピュートノードでの OpenShift Container Platform のインストール時に、ブートディスクの 2 つ以上の冗長ストレージデバイスへのミラーリングを有効にできます。ノードは、1 つのデバイスが利用可能な状態である限り、ストレージデバイスに障害が発生した後も引き続き機能します。
ミラーリングは、障害の発生したディスクの置き換えをサポートしません。ミラーを元の低下していない状態に復元するには、ノードを再プロビジョニングします。
ミラーリングは、Red Hat Enterprise Linux CoreOS (RHCOS) システムのユーザーによってプロビジョニングされるインフラストラクチャーのデプロイメントでのみ利用できます。ミラーリングのサポートは、BIOS または UEFI で起動した x86_64 ノード、および ppc64le ノードで利用できます。
手順
OpenShift Container Platform のデプロイメント時のブートディスクのミラーリングを有効にするには、以下を実行します。
インストール用に Ignition 設定を作成するところまで、ベアメタルのインストール手順に従います。
たとえば、以下のコマンドを入力しているはずです。
$ openshift-install create ignition-configs --dir $HOME/clusterconfig
Ignition 設定ファイルが作成されていることを確認します。
$ ls $HOME/clusterconfig/
出力例
auth bootstrap.ign master.ign metadata.json worker.ign
設定しているノードのタイプに応じて、
master.ign
またはworker.ign
設定への参照のある RHCOS 設定 (RCC) を作成します。RCC は、ブートディスクのミラーリングに使用されるデバイスを指定する必要があります。ミラーリングされたルートファイルシステムで LUKS 暗号化が必要な場合は、この RCC でこれを設定する必要があります。以下の RCC の例では、
$HOME/clusterconfig/worker-raid.rcc
を作成する方法を示します。RCC の例
variant: rhcos version: 0.1.0 ignition: config: merge: - local: worker.ign 1 boot_device: mirror: devices: 2 - /dev/sda - /dev/sdb luks: 3 tpm2: true 4 tang: 5 - url: http://tang.example.com:7500 thumbprint: <tang_thumbprint> storage: 6 luks: - name: root options: [--cipher, aes-cbc-essiv:sha256]
- 1
- ノードタイプの Ignition 設定の名前を使用します。
- 2
- RHCOS がインストールされるディスクを含む、ブートディスクミラーに含まれる必要があるすべてのディスクデバイスを一覧表示します。
- 3
- ルートファイルシステムを暗号化する必要がある場合は、このセクションを追加してください。詳細は、インストール時のディスクの暗号化を参照してください。
- 4
- Trusted Platform Module (TPM) を使用してルートファイルシステムを暗号化する場合は、このフィールドを追加してください。詳細は、TPM v2 ディスク暗号化の有効化を参照してください。
- 5
- Tang サーバーを使用する必要がある場合は、このセクションを追加してください。サーバー URL およびサムプリントを取得するには、Tang ディスク暗号化の有効化の手順に従います。
- 6
- ルートファイルシステムを暗号化する必要がある場合は、このセクションを追加してください。
Fedora CoreOS Config Transpiler (FCCT) ツールを実行し、
worker-raid.rcc
などの RCC を、先の手順で作成した RCC で設定した Ignition 設定にマージします。$ podman run --pull=always --rm --volume $HOME/clusterconfig:/pwd --workdir /pwd \ quay.io/coreos/fcct:release --files-dir . worker-raid.rcc --output worker-raid.ign
このコマンドは、
$HOME/clusterconfig/worker-raid.ign
に統合された Ignition 設定を生成します。- ノードをプロビジョニングするために組み合わされた Ignition 設定を使用し、残りの OpenShift Container Platform デプロイメントを引き続き実行します。
17.1.4.1. RAID 対応のデータボリュームの設定
ソフトウェア RAID のパーティション設定を有効にして、外部データボリュームを提供できます。
手順
ソフトウェア RAID を使用してデータボリュームを設定する
<installation_directory>/openshift
ディレクトリーにマシン設定を作成します。この例では、raid1-alt-storage.yaml
という名前です。セカンダリーディスク設定ファイルの RAID 1 の例
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: raid1-alt-storage spec: config: ignition: version: 3.2.0 storage: disks: - device: /dev/sdc partitions: - label: data-1 wipeTable: true - device: /dev/sdd partitions: - label: data-2 wipeTable: true filesystems: - device: /dev/md/md-data format: xfs path: /var/lib/containers wipeFilesystem: true raid: - devices: - /dev/disk/by-partlabel/data-1 - /dev/disk/by-partlabel/data-2 level: raid1 name: md-data systemd: units: - contents: |- [Unit] Before=local-fs.target Requires=systemd-fsck@dev-md-md\x2ddata.service After=systemd-fsck@dev-md-md\x2ddata.service [Mount] Where=/var/lib/containers What=/dev/md/md-data Type=xfs [Install] RequiredBy=local-fs.target enabled: true name: var-lib-containers.mount 1
- 1
- 別のマウントポイントを選択する場合は、マウントポイントに対応するユニット名を更新する必要があります。そうでないと、ユニットはアクティブになりません。
echo $(systemd-escape -p $mountpoint).mount
がある一致するユニット名を生成できます。$mountpoint
は選択したマウントポイントです。
17.1.5. chrony タイムサービスの設定
chrony タイムサービス (chronyd
) で使用されるタイムサーバーおよび関連する設定は、chrony.conf
ファイルのコンテンツを変更し、それらのコンテンツをマシン設定としてノードに渡して設定できます。
手順
chrony.conf
ファイルのコンテンツを作成し、これを base64 でエンコードします。以下に例を示します。$ cat << EOF | base64 pool 0.rhel.pool.ntp.org iburst 1 driftfile /var/lib/chrony/drift makestep 1.0 3 rtcsync logdir /var/log/chrony EOF
- 1
- DHCP サーバーが提供するものなど、有効な到達可能なタイムソースを指定します。または、NTP サーバーの
1.rhel.pool.ntp.org
、2.rhel.pool.ntp.org
、または3.rhel.pool.ntp.org
のいずれかを指定できます。
出力例
ICAgIHNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdAogICAgZHJpZnRmaWxlIC92YXIvbGli L2Nocm9ueS9kcmlmdAogICAgbWFrZXN0ZXAgMS4wIDMKICAgIHJ0Y3N5bmMKICAgIGxvZ2RpciAv dmFyL2xvZy9jaHJvbnkK
MachineConfig
ファイルを作成します。base64 文字列を独自に作成した文字列に置き換えます。この例では、ファイルをmaster
ノードに追加します。これをworker
に切り替えたり、worker
ロールの追加の MachineConfig を作成したりできます。クラスターが使用するそれぞれのタイプのマシンについて MachineConfig ファイルを作成します。$ cat << EOF > ./99-masters-chrony-configuration.yaml apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: master name: 99-masters-chrony-configuration spec: config: ignition: config: {} security: tls: {} timeouts: {} version: 3.2.0 networkd: {} passwd: {} storage: files: - contents: source: data:text/plain;charset=utf-8;base64,ICAgIHNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdAogICAgZHJpZnRmaWxlIC92YXIvbGliL2Nocm9ueS9kcmlmdAogICAgbWFrZXN0ZXAgMS4wIDMKICAgIHJ0Y3N5bmMKICAgIGxvZ2RpciAvdmFyL2xvZy9jaHJvbnkK mode: 420 1 overwrite: true path: /etc/chrony.conf osImageURL: "" EOF
- 1
- マシン設定ファイルの
mode
フィールドに 8 進数の値でモードを指定します。ファイルを作成し、変更を適用すると、mode
は 10 進数の値に変換されます。コマンドoc get mc <mc-name> -o yaml
で YAML ファイルを確認できます。
- 設定ファイルのバックアップコピーを作成します。
以下の 2 つの方法のいずれかで設定を適用します。
-
クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、そのファイルを
<installation_directory>/openshift
ディレクトリーに追加してから、クラスターの作成を継続します。 クラスターがすでに実行中の場合は、ファイルを適用します。
$ oc apply -f ./99-masters-chrony-configuration.yaml
-
クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、そのファイルを
17.1.6. 関連情報
- FIPS サポートについての詳細は、FIPS 暗号のサポート を参照してください。