3.2. MachineConfig オブジェクトを使用したノードの設定
このセクションのタスクを使用して、MachineConfig オブジェクトを作成し、OpenShift Container Platform ノードで実行されているファイル、systemd ユニットファイルその他のオペレーティングシステム機能を変更することができます。マシン設定の使用に関する詳細は、SSH 認証キーの 更新、イメージ署名の検証、SCTP の有効化、および OpenShift Container Platform の iSCSI イニシエーター名の設定 に関するコンテンツを参照してください。
OpenShift Container Platform バージョン 4.7 は 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ファイルのコンテンツを作成し、これを 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
-
クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、そのファイルを
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.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 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 のカーネル引数でのマルチパスの有効化
RHCOS はプライマリーディスクでのマルチパスをサポートするようになり、ハードウェア障害に対する対障害性が強化され、ホストの可用性を強化できるようになりました。
マルチパスは、以下の手順で説明されているようにマシン設定を使用してアクティブ化される場合にのみサポートされます。これは RHCOS のインストール後に有効にされる必要があります。
IBM Z および LinuxONE では、インストール時にクラスターを設定した場合のみマルチパスを有効にできます。詳細は、IBM Z および LinuxONE への z/VM のあるクラスターのインストール に関連して Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成について参照してください。
前提条件
- バージョン 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-master-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-kargs-mpath 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 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.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
追加したカーネル引数が表示されるはずです。
3.2.4. リアルタイムカーネルのノードへの追加
一部の OpenShift Container Platform ワークロードには、高度な決定論的アプローチが必要になります。Linux はリアルタイムのオペレーティングシステムではありませんが、Linux のリアルタイムカーネルには、リアルタイムの特性を持つオペレーティングシステムを提供するプリエンプティブなスケジューラーが含まれます。
OpenShift Container Platform ワークロードでこれらのリアルタイムの特性が必要な場合、マシンを Linux のリアルタイムカーネルに切り替えることができます。OpenShift Container Platform の場合、4.7 は 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.20.0 ip-10-0-146-92.us-east-2.compute.internal Ready worker 101m v1.20.0 ip-10-0-169-2.us-east-2.compute.internal Ready worker 102m v1.20.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 クラスター (バージョン 4.4 以降) が実行中である。
- 管理者権限を持つユーザーとしてクラスターにログインしている。
手順
/etc/systemd/journald.confファイルの内容を作成し、これを base64 としてエンコードします。以下に例を示します。$ cat > /tmp/jrnl.conf <<EOF # Disable rate limiting RateLimitInterval=1s RateLimitBurst=10000 Storage=volatile Compress=no MaxRetentionSec=30s EOF
一時的な
journal.confファイルを base64 に変換し、これを変数 (jrnl_cnf) に保存します。$ export jrnl_cnf=$( cat /tmp/jrnl.conf | base64 -w0 ) $ echo $jrnl_cnf IyBEaXNhYmxlIHJhdGUgbGltaXRpbmcKUmF0ZUxpbWl0SW50ZXJ2YWw9MXMKUmF0ZUxpbWl0QnVyc3Q9MTAwMDAKU3RvcmFnZT12b2xhdGlsZQpDb21wcmVzcz1ubwpNYXhSZXRlbnRpb25TZWM9MzBzCg==
journald.confのエンコードされた内容 (jrnl_cnf変数) を含むマシン設定を作成します。$ cat > /tmp/40-worker-custom-journald.yaml <<EOF apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 40-worker-custom-journald spec: config: ignition: config: {} security: tls: {} timeouts: {} version: 3.1.0 networkd: {} passwd: {} storage: files: - contents: source: data:text/plain;charset=utf-8;base64,${jrnl_cnf} verification: {} filesystem: root mode: 420 path: /etc/systemd/journald.conf systemd: {} osImageURL: "" EOFマシン設定をプールに適用します。
$ oc apply -f /tmp/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 設定を保存します。
