3.2. MachineConfig オブジェクトを使用したノードの設定
このセクションのタスクを使用して、MachineConfig オブジェクトを作成し、OpenShift Container Platform ノードで実行されているファイル、systemd ユニットファイルその他のオペレーティングシステム機能を変更することができます。マシン設定の使用に関する詳細は、SSH 認証キーの 更新、イメージ署名の検証、SCTP の有効化、および OpenShift Container Platform の iSCSI イニシエーター名の設定 に関するコンテンツを参照してください。
OpenShift Container Platform は Ignition 仕様バージョン 3.2 をサポートします。今後作成する新規のマシン設定はすべて Ignition 仕様バージョン 3.2 をベースとする必要があります。OpenShift Container Platform クラスターをアップグレードする場合、既存の Ignition 仕様バージョン 2.x マシン設定は仕様バージョン 3.2 に自動的に変換されます。
他の設定ファイルを OpenShift Container Platform ノードに追加する方法については、以下の chrony タイムサービスの設定の手順をモデルとして使用します。
3.2.1. chrony タイムサービスの設定
chrony タイムサービス (chronyd) で使用されるタイムサーバーおよび関連する設定は、chrony.conf ファイルのコンテンツを変更し、それらのコンテンツをマシン設定としてノードに渡して設定できます。
手順
chrony.confファイルのコンテンツを含む Butane 設定を作成します。たとえば、ワーカーノードで chrony を設定するには、99-worker-chrony.buファイルを作成します。注記Butane の詳細は、Butane を使用したマシン設定の作成を参照してください。
variant: openshift version: 4.8.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
-
クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、
関連情報
3.2.2. カーネル引数のノードへの追加
特殊なケースとして、クラスターのノードセットにカーネル引数を追加する必要がある場合があります。これは十分に注意して実行する必要があり、設定する引数による影響を十分に理解している必要があります。
カーネル引数を正しく使用しないと、システムが起動不可能になる可能性があります。
設定可能なカーネル引数の例には、以下が含まれます。
- enforcing=0: SELinux (Security Enhanced Linux) を Permissive モードで実行するように設定します。Permissive モードでは、システムは、SELinux が読み込んだセキュリティーポリシーを実行しているかのように動作します。これには、オブジェクトのラベル付けや、アクセスを拒否したエントリーをログに出力するなどの動作が含まれますが、いずれの操作も拒否される訳ではありません。Permissive モードは、実稼働システムでの使用はサポートされませんが、デバッグには役に立ちます。
-
nosmt: カーネルの対称マルチスレッド (SMT) を無効にします。マルチスレッドは、各 CPU の複数の論理スレッドを許可します。潜在的なクロススレッド攻撃に関連するリスクを減らすために、マルチテナント環境での
nosmtの使用を検討できます。SMT を無効にすることは、基本的にパフォーマンスよりもセキュリティーを重視する選択をしていることになります。
カーネル引数の一覧と説明については、Kernel.org カーネルパラメーター を参照してください。
次の手順では、以下を特定する MachineConfig オブジェクトを作成します。
- カーネル引数を追加する一連のマシン。この場合、ワーカーロールを持つマシン。
- 既存のカーネル引数の最後に追加されるカーネル引数。
- マシン設定の一覧で変更が適用される場所を示すラベル。
前提条件
- 作業用の OpenShift Container Platform クラスターに対する管理者権限が必要です。
手順
OpenShift Container Platform クラスターの既存の
MachineConfigを一覧表示し、マシン設定にラベルを付ける方法を判別します。$ oc get MachineConfig
出力例
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 00-master 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 00-worker 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-master-container-runtime 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-master-kubelet 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-worker-container-runtime 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-worker-kubelet 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-master-generated-registries 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-master-ssh 3.2.0 40m 99-worker-generated-registries 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-worker-ssh 3.2.0 40m rendered-master-23e785de7587df95a4b517e0647e5ab7 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m rendered-worker-5d596d9293ca3ea80c896a1191735bb1 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m
カーネル引数を識別する
MachineConfigオブジェクトファイルを作成します (例:05-worker-kernelarg-selinuxpermissive.yaml)。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker1 name: 05-worker-kernelarg-selinuxpermissive2 spec: config: ignition: version: 3.2.0 kernelArguments: - enforcing=03新規のマシン設定を作成します。
$ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml
マシン設定で新規の追加内容を確認します。
$ oc get MachineConfig
出力例
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 00-master 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 00-worker 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-master-container-runtime 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-master-kubelet 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-worker-container-runtime 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-worker-kubelet 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 05-worker-kernelarg-selinuxpermissive 3.2.0 105s 99-master-generated-registries 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-master-ssh 3.2.0 40m 99-worker-generated-registries 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-worker-ssh 3.2.0 40m rendered-master-23e785de7587df95a4b517e0647e5ab7 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m rendered-worker-5d596d9293ca3ea80c896a1191735bb1 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m
ノードを確認します。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION ip-10-0-136-161.ec2.internal Ready worker 28m v1.21.0 ip-10-0-136-243.ec2.internal Ready master 34m v1.21.0 ip-10-0-141-105.ec2.internal Ready,SchedulingDisabled worker 28m v1.21.0 ip-10-0-142-249.ec2.internal Ready master 34m v1.21.0 ip-10-0-153-11.ec2.internal Ready worker 28m v1.21.0 ip-10-0-153-150.ec2.internal Ready master 34m v1.21.0
変更が適用されているため、各ワーカーノードのスケジューリングが無効にされていることを確認できます。
ワーカーノードのいずれかに移動し、カーネルコマンドライン引数 (ホストの
/proc/cmdline内) を一覧表示して、カーネル引数が機能することを確認します。$ oc debug node/ip-10-0-141-105.ec2.internal
出力例
Starting pod/ip-10-0-141-105ec2internal-debug ... To use host binaries, run `chroot /host` sh-4.2# cat /host/proc/cmdline BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8 rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16... coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 enforcing=0 sh-4.2# exit
enforcing=0引数が他のカーネル引数に追加されていることを確認できるはずです。
3.2.3. RHCOS のカーネル引数でのマルチパスの有効化
Red Hat Enterprise Linux CoreOS (RHCOS) はプライマリーディスクでのマルチパスをサポートするようになり、ハードウェア障害に対する対障害性が強化され、ホストの可用性を強化できるようになりました。インストール後のサポートは、マシン設定を使用してマルチパスをアクティベートすることで利用できます。
インストール時のマルチパスの有効化が、OpenShift Container Platform 4.8 以降でプロビジョニングされるノードでサポートおよび推奨されるようになりました。非最適化パスに対して I/O があると、I/O システムエラーが発生するように設定するには、インストール時にマルチパスを有効にする必要があります。インストール時にマルチパスを有効にする方法は、ベアメタルへのインストールの RHCOS でのカーネル引数を使用したマルチパスの有効化を参照してください。
IBM Z および LinuxONE では、インストール時にクラスターを設定した場合のみマルチパスを有効にできます。詳細は、IBM Z および LinuxONE への z/VM を使用したクラスターのインストールの RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始を参照してください。
前提条件
- バージョン 4.7 以降を使用する OpenShift Container Platform クラスターが実行中である。
- 管理者権限を持つユーザーとしてクラスターにログインしている。
手順
コントロールプレーンノードでマルチパスのポストインストールを有効にするには、以下を実行します。
以下の例のように、
masterラベルを追加し、マルチパスカーネル引数を特定するようクラスターに指示する99-master-kargs-mpath.yamlなどのマシン設定ファイルを作成します。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: "master" name: 99-master-kargs-mpath spec: kernelArguments: - 'rd.multipath=default' - 'root=/dev/disk/by-label/dm-mpath-root'
ワーカーノードでマルチパスのポストインストールを有効にするには、以下を実行します。
workerラベルを追加し、マルチパスカーネル引数などを特定するようクラスターに指示する99-worker-kargs-mpath.yamlなどのマシン設定ファイルを作成します。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: "worker" name: 99-worker-kargs-mpath spec: kernelArguments: - 'rd.multipath=default' - 'root=/dev/disk/by-label/dm-mpath-root'
以前に作成したマスターまたはワーカー YAML ファイルのいずれかを使用して新規のマシン設定を作成します。
$ oc create -f ./99-worker-kargs-mpath.yaml
マシン設定で新規の追加内容を確認します。
$ oc get MachineConfig
出力例
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 00-master 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 00-worker 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-master-container-runtime 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-master-kubelet 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-worker-container-runtime 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-worker-kubelet 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-master-generated-registries 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-master-ssh 3.2.0 40m 99-worker-generated-registries 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-worker-kargs-mpath 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 105s 99-worker-ssh 3.2.0 40m rendered-master-23e785de7587df95a4b517e0647e5ab7 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m rendered-worker-5d596d9293ca3ea80c896a1191735bb1 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m
ノードを確認します。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION ip-10-0-136-161.ec2.internal Ready worker 28m v1.20.0 ip-10-0-136-243.ec2.internal Ready master 34m v1.20.0 ip-10-0-141-105.ec2.internal Ready,SchedulingDisabled worker 28m v1.20.0 ip-10-0-142-249.ec2.internal Ready master 34m v1.20.0 ip-10-0-153-11.ec2.internal Ready worker 28m v1.20.0 ip-10-0-153-150.ec2.internal Ready master 34m v1.20.0
変更が適用されているため、各ワーカーノードのスケジューリングが無効にされていることを確認できます。
ワーカーノードのいずれかに移動し、カーネルコマンドライン引数 (ホストの
/proc/cmdline内) を一覧表示して、カーネル引数が機能することを確認します。$ oc debug node/ip-10-0-141-105.ec2.internal
出力例
Starting pod/ip-10-0-141-105ec2internal-debug ... To use host binaries, run `chroot /host` sh-4.2# cat /host/proc/cmdline ... rd.multipath=default root=/dev/disk/by-label/dm-mpath-root ... sh-4.2# exit
追加したカーネル引数が表示されるはずです。
関連情報
- インストール時のマルチパスの有効化の詳細は、RHCOS のカーネル引数でのマルチパスの有効化 を参照してください。
3.2.4. リアルタイムカーネルのノードへの追加
一部の OpenShift Container Platform ワークロードには、高度な決定論的アプローチが必要になります。Linux はリアルタイムのオペレーティングシステムではありませんが、Linux のリアルタイムカーネルには、リアルタイムの特性を持つオペレーティングシステムを提供するプリエンプティブなスケジューラーが含まれます。
OpenShift Container Platform ワークロードでこれらのリアルタイムの特性が必要な場合、マシンを Linux のリアルタイムカーネルに切り替えることができます。OpenShift Container Platform の場合、4.8 は MachineConfig オブジェクトを使用してこの切り替えを行うことができます。変更はマシン設定の kernelType 設定を realtime に変更するだけで簡単に行えますが、この変更を行う前に他のいくつかの点を考慮する必要があります。
- 現在、リアルタイムカーネルはワーカーノードでのみサポートされ、使用できるのはラジオアクセスネットワーク (RAN) のみになります。
- 以下の手順は、Red Hat Enterprise Linux for Real Time 8 で認定されているシステムを使用したベアメタルのインストールで完全にサポートされます。
- OpenShift Container Platform でのリアルタイムサポートは、特定のサブスクリプションに制限されます。
- 以下の手順は、Google Cloud Platform での使用についてもサポートされます。
前提条件
- OpenShift Container Platform クラスター (バージョン 4.4 以降) が実行中である。
- 管理者権限を持つユーザーとしてクラスターにログインしている。
手順
リアルタイムカーネルのマシン設定を作成します。
realtimeカーネルタイプのMachineConfigオブジェクトが含まれる YAML ファイル (99-worker-realtime.yamlなど) を作成します。以下の例では、すべてのワーカーノードにリアルタイムカーネルを使用するようにクラスターに指示します。$ cat << EOF > 99-worker-realtime.yaml apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: "worker" name: 99-worker-realtime spec: kernelType: realtime EOFマシン設定をクラスターに追加します。以下を入力してマシン設定をクラスターに追加します。
$ oc create -f 99-worker-realtime.yaml
リアルタイムカーネルを確認します。影響を受けるそれぞれのノードの再起動後に、クラスターにログインして以下のコマンドを実行し、リアルタイムカーネルが設定されたノードのセットの通常のカーネルを置き換えていることを確認します。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION ip-10-0-143-147.us-east-2.compute.internal Ready worker 103m v1.21.0 ip-10-0-146-92.us-east-2.compute.internal Ready worker 101m v1.21.0 ip-10-0-169-2.us-east-2.compute.internal Ready worker 102m v1.21.0
$ oc debug node/ip-10-0-143-147.us-east-2.compute.internal
出力例
Starting pod/ip-10-0-143-147us-east-2computeinternal-debug ... To use host binaries, run `chroot /host` sh-4.4# uname -a Linux <worker_node> 4.18.0-147.3.1.rt24.96.el8_1.x86_64 #1 SMP PREEMPT RT Wed Nov 27 18:29:55 UTC 2019 x86_64 x86_64 x86_64 GNU/Linuxカーネル名には
rtが含まれ、PREEMPT RT のテキストは、これがリアルタイムカーネルであることを示します。通常のカーネルに戻るには、
MachineConfigオブジェクトを削除します。$ oc delete -f 99-worker-realtime.yaml
3.2.5. journald の設定
OpenShift Container Platform ノードで journald サービスの設定が必要な場合は、適切な設定ファイルを変更し、そのファイルをマシン設定としてノードの適切なプールに渡すことで実行できます。
この手順では、/etc/systemd/journald.conf ファイルの journald 速度制限の設定を変更し、それらをワーカーノードに適用する方法について説明します。このファイルの使用方法についての情報は、journald.conf man ページを参照してください。
前提条件
- OpenShift Container Platform クラスターが実行中である。
- 管理者権限を持つユーザーとしてクラスターにログインしている。
手順
必要な設定で
/etc/systemd/journald.confファイルが含まれる Butane 設定ファイル40-worker-custom -journald.buを作成します。注記Butane の詳細は、Butane を使用したマシン設定の作成を参照してください。
variant: openshift version: 4.8.0 metadata: name: 40-worker-custom-journald labels: machineconfiguration.openshift.io/role: worker storage: files: - path: /etc/systemd/journald.conf mode: 0644 overwrite: true contents: inline: | # Disable rate limiting RateLimitInterval=1s RateLimitBurst=10000 Storage=volatile Compress=no MaxRetentionSec=30sButane を使用して、ワーカーノードに配信される設定を含む
MachineConfigオブジェクトファイル (40-worker-custom-journald.yaml) を生成します。$ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml
マシン設定をプールに適用します。
$ oc apply -f 40-worker-custom-journald.yaml
新規マシン設定が適用され、ノードの状態が低下した状態にないことを確認します。これには数分の時間がかかる場合があります。各ノードで新規マシン設定が正常に適用されるため、ワーカープールには更新が進行中であることが表示されます。
$ oc get machineconfigpool NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-35 True False False 3 3 3 0 34m worker rendered-worker-d8 False True False 3 1 1 0 34m
変更が適用されたことを確認するには、ワーカーノードにログインします。
$ oc get node | grep worker ip-10-0-0-1.us-east-2.compute.internal Ready worker 39m v0.0.0-master+$Format:%h$ $ oc debug node/ip-10-0-0-1.us-east-2.compute.internal Starting pod/ip-10-0-141-142us-east-2computeinternal-debug ... ... sh-4.2# chroot /host sh-4.4# cat /etc/systemd/journald.conf # Disable rate limiting RateLimitInterval=1s RateLimitBurst=10000 Storage=volatile Compress=no MaxRetentionSec=30s sh-4.4# exit
関連情報
3.2.6. 拡張機能の RHCOS への追加
RHCOS はコンテナー指向の最小限の RHEL オペレーティングシステムであり、すべてのプラットフォームで OpenShift Container Platform クラスターに共通の機能セットを提供するように設計されています。ソフトウェアパッケージを RHCOS システムに追加することは一般的に推奨されていませんが、MCO は RHCOS ノードに最小限の機能セットを追加するために使用できる extensions 機能を提供します。
現時点で、以下の拡張機能が利用可能です。
-
usbguard:
usbguard拡張機能を追加すると、RHCOS システムを割り込みの USB デバイスから保護します。詳細は、USBGuard を参照してください。
以下の手順では、マシン設定を使用して 1 つ以上の拡張機能を RHCOS ノードに追加する方法を説明します。
前提条件
- OpenShift Container Platform クラスター (バージョン 4.6 以降) が実行中である。
- 管理者権限を持つユーザーとしてクラスターにログインしている。
手順
拡張機能のマシン設定を作成します。
MachineConfigextensionsオブジェクトが含まれる YAML ファイル (例:80-extensions.yaml) を作成します。この例では、クラスターに対してusbguard拡張機能を追加するように指示します。$ cat << EOF > 80-extensions.yaml apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 80-worker-extensions spec: config: ignition: version: 3.2.0 extensions: - usbguard EOFマシン設定をクラスターに追加します。以下を入力してマシン設定をクラスターに追加します。
$ oc create -f 80-extensions.yaml
これにより、すべてのワーカーノードで
usbguardの rpm パッケージがインストールされるように設定できます。拡張機能が適用されていることを確認します。
$ oc get machineconfig 80-worker-extensions
出力例
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 80-worker-extensions 3.2.0 57s
新規マシン設定が適用され、ノードの状態が低下した状態にないことを確認します。これには数分の時間がかかる場合があります。各マシンで新規マシン設定が正常に適用されるため、ワーカープールには更新が進行中であることが表示されます。
$ oc get machineconfigpool
出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-35 True False False 3 3 3 0 34m worker rendered-worker-d8 False True False 3 1 1 0 34m
拡張機能を確認します。拡張機能が適用されたことを確認するには、以下を実行します。
$ oc get node | grep worker
出力例
NAME STATUS ROLES AGE VERSION ip-10-0-169-2.us-east-2.compute.internal Ready worker 102m v1.18.3
$ oc debug node/ip-10-0-169-2.us-east-2.compute.internal
出力例
... To use host binaries, run `chroot /host` sh-4.4# chroot /host sh-4.4# rpm -q usbguard usbguard-0.7.4-4.el8.x86_64.rpm
3.2.7. マシン設定マニフェストでのカスタムファームウェアブロブの読み込み
/usr/lib 内のファームウェアブロブのデフォルトの場所は読み取り専用であるため、検索パスを更新して、カスタムファームウェアブロブを特定できます。これにより、ブロブが RHCOS によって管理されない場合に、マシン設定マニフェストでローカルファームウェアブロブを読み込むことができます。
手順
Butane 設定ファイル
98-worker-firmware-blob.buを作成します。このファイルは、root 所有でローカルストレージに書き込みできるように、検索パスを更新します。以下の例では、カスタムブロブファイルをローカルワークステーションからノードの/var/lib/firmware下に配置しています。注記Butane の詳細は、Butane を使用したマシン設定の作成を参照してください。
カスタムファームウェアブロブ用の Butane 設定ファイル
variant: openshift version: 4.9.0 metadata: labels: machineconfiguration.openshift.io/role: worker name: 98-worker-firmware-blob storage: files: - path: /var/lib/firmware/<package_name> 1 contents: local: <package_name> 2 mode: 0644 3 openshift: kernel_arguments: - 'firmware_class.path=/var/lib/firmware' 4- 1
- ファームウェアパッケージのコピー先となるノードのパスを設定します。
- 2
- Butane を実行しているシステムのローカルファイルディレクトリーから読み取るコンテンツを含むファイルを指定します。ローカルファイルのパスは
files-dirディレクトリーからの相対パスで、以下の手順の Butane で--files-dirオプションを使用して指定する必要があります。 - 3
- RHCOS ノードのファイルのパーミッションを設定します。
0644パーミッションを設定することが推奨されます。 - 4
firmware_class.pathパラメーターは、ローカルワークステーションからノードのルートファイルシステムにコピーされたカスタムファームウェアブロブを検索するカーネルの検索パスをカスタマイズします。この例では、/var/lib/firmwareをカスタマイズされたパスとして使用します。
Butane を実行して、ローカルワークステーション上の
98-worker-firmware-blob.yamlという名前のファームウェアブロブのコピーを使用するMachineConfigオブジェクトファイルを生成します。ファームウェアブロブには、ノードに配信される設定が含まれます。次の例では、--files-dirオプションを使用して、ローカルファイルが配置されるワークステーション上のディレクトリーを指定します。$ butane 98-worker-firmware-blob.bu -o 98-worker-firmware-blob.yaml --files-dir <directory_including_package_name>
以下の 2 つの方法のいずれかで、設定をノードに適用します。
-
クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、
MachineConfigオブジェクトファイルを<installation_directory>/openshiftディレクトリーに追加してから、クラスターの作成を続行します。 クラスターがすでに実行中の場合は、ファイルを適用します。
$ oc apply -f 98-worker-firmware-blob.yaml
MachineConfigオブジェクト YAML ファイルは、マシンの設定を終了するために作成されます。
-
クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、
-
将来的に
MachineConfigオブジェクトを更新する必要がある場合に備えて、Butane 設定を保存します。
関連情報
