第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
バイナリーを取得します。最新バージョンの Butane の場合は、最新の
butane
イメージを現在のディレクトリーに保存します。$ curl https://mirror.openshift.com/pub/openshift-v4/clients/butane/latest/butane --output butane
オプション: 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
リポジトリーのクローンを作成します。リポジトリーのフォルダーを作成します。
$ 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
その後は、システムの起動時に、このサービスは新規カーネルが実行中であるかどうかをチェックします。新規カーネルがある場合は、サービスは新規バージョンのカーネルモジュールをビルドし、これをロードします。モジュールがすでにビルドされている場合は、これをロードします。
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
ソフトウェアを取得します。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/
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
です。設定に複数の暗号化条件を追加するにも拘らず、しきい値を指定しない場合は、条件のいずれかが満たされている場合に復号化を実行できます。
復号化に 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 を使用してクラスターを暗号化する必要がある場合は、以下の準備段階の手順に従います。
- Tang サーバーを設定するか、既存のサーバーにアクセスします。手順については、NBDE (Network-Bound Disk Encryption) を参照してください。
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 バインディングの問題を防ぐ必要があります。
ノードが静的 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 を使用してクラスターノードにアクセスします。
ノードのデバッグ Pod を起動します。以下の例では、
compute-1
ノードのデバッグ Pod を起動します。$ oc debug node/compute-1
/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>
を使用してノードにアクセスできます。
ブートディスクの暗号化を設定している場合は、有効であるかどうかを確認します。
デバッグシェルで、ノードでのルートマッピングのステータスを確認します。
# 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
暗号化されたデバイスにバインドされる 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>
上記のコマンドの出力に記載されている各ソフトウェア 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
ソフトウェア 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
セカンダリーディスク上に 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 暗号のサポート を参照してください。