5.3. Linux コントロールグループバージョン 2 (cgroups v2) の有効化
マシン設定を使用して、クラスター内の特定ノードで Linux コントロールグループバージョン 2 (cgroups v2) を有効化できます。cgroups v2 を有効にする OpenShift Container Platform プロセスにより、cgroups バージョン 1 コントローラーおよび階層がすべて無効になります。
OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。
前提条件
- バージョン 4.10 以降を使用する OpenShift Container Platform クラスターが実行中である。
- 管理者権限を持つユーザーとしてクラスターにログインしている。
設定するノードの
node-role.kubernetes.io
値を把握している。$ oc describe node <node-name>
出力例
Name: ci-ln-v05w5m2-72292-5s9ht-worker-a-r6fpg Roles: worker Labels: beta.kubernetes.io/arch=amd64 beta.kubernetes.io/instance-type=n1-standard-4 beta.kubernetes.io/os=linux failure-domain.beta.kubernetes.io/region=us-central1 failure-domain.beta.kubernetes.io/zone=us-central1-a kubernetes.io/arch=amd64 kubernetes.io/hostname=ci-ln-v05w5m2-72292-5s9ht-worker-a-r6fpg kubernetes.io/os=linux node-role.kubernetes.io/worker= 1 #...
- 1
- この値は、必要なノードロールです。
手順
ノードで cgroups v2 を有効にします。
worker-cgroups-v2.yaml
などのマシン設定ファイル YAML を作成します。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: "worker" 1 name: worker-enable-cgroups-v2 spec: kernelArguments: - systemd.unified_cgroup_hierarchy=1 2 - cgroup_no_v1="all" 3
新規のマシン設定を作成します。
$ oc create -f worker-enable-cgroups-v2.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-ssh 3.2.0 40m rendered-master-23e785de7587df95a4b517e0647e5ab7 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m rendered-worker-5d596d9293ca3ea80c896a1191735bb1 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m worker-enable-cgroups-v2 3.2.0 10s
ノードを確認して、影響を受ける各ノードでスケジューリングが無効にされていることを確認します。これは、変更が適用されていることを示しています。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION ci-ln-fm1qnwt-72292-99kt6-master-0 Ready master 58m v1.24.0 ci-ln-fm1qnwt-72292-99kt6-master-1 Ready master 58m v1.24.0 ci-ln-fm1qnwt-72292-99kt6-master-2 Ready master 58m v1.24.0 ci-ln-fm1qnwt-72292-99kt6-worker-a-h5gt4 Ready,SchedulingDisabled worker 48m v1.24.0 ci-ln-fm1qnwt-72292-99kt6-worker-b-7vtmd Ready worker 48m v1.24.0 ci-ln-fm1qnwt-72292-99kt6-worker-c-rhzkv Ready worker 48m v1.24.0
ノードが
Ready
状態に戻ったら、sys/fs/cgroup/cgroup.controllers
ファイルがノードに存在することを確認して、cgroups v2 が有効になっていることを確認できます。このファイルは cgroups v2 によって作成されます。そのノードのデバッグセッションを開始します。
$ oc debug node/<node_name>
sys/fs/cgroup/cgroup.controllers
ファイルを探します。このファイルが存在する場合は、cgroups v2 がそのノードで有効になっています。出力例
cgroup.controllers cgroup.stat cpuset.cpus.effective io.stat pids cgroup.max.depth cgroup.subtree_control cpuset.mems.effective kubepods.slice system.slice cgroup.max.descendants cgroup.threads init.scope memory.pressure user.slice cgroup.procs cpu.pressure io.pressure memory.stat
関連情報
- インストール時に cgroups v2 を有効にする方法は、インストールプロセスの Installation configuration parameters セクションの Optional parameters の表を参照してください。
5.3.1. リアルタイムカーネルのノードへの追加
一部の OpenShift Container Platform ワークロードには、高度な決定論的アプローチが必要になります。Linux はリアルタイムのオペレーティングシステムではありませんが、Linux のリアルタイムカーネルには、リアルタイムの特性を持つオペレーティングシステムを提供するプリエンプティブなスケジューラーが含まれます。
OpenShift Container Platform ワークロードでこれらのリアルタイムの特性が必要な場合、マシンを Linux のリアルタイムカーネルに切り替えることができます。OpenShift Container Platform 4.11 の場合、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.24.0 ip-10-0-146-92.us-east-2.compute.internal Ready worker 101m v1.24.0 ip-10-0-169-2.us-east-2.compute.internal Ready worker 102m v1.24.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
5.3.2. 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.11.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=30s
Butane を使用して、ワーカーノードに配信される設定を含む
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
関連情報
5.3.3. 拡張機能の RHCOS への追加
RHCOS はコンテナー指向の最小限の RHEL オペレーティングシステムであり、すべてのプラットフォームで OpenShift Container Platform クラスターに共通の機能セットを提供するように設計されています。ソフトウェアパッケージを RHCOS システムに追加することは一般的に推奨されていませんが、MCO は RHCOS ノードに最小限の機能セットを追加するために使用できる extensions
機能を提供します。
現時点で、以下の拡張機能が利用可能です。
-
usbguard:
usbguard
拡張機能を追加すると、RHCOS システムを割り込みの USB デバイスから保護します。詳細は、USBGuard を参照してください。 -
kerberos:
kerberos
拡張機能を追加すると、ユーザーとマシンの両方がネットワークに対して自分自身を識別し、管理者が設定したエリアとサービスへの定義済みの制限付きアクセスを取得できるメカニズムが提供されます。Kerberos クライアントのセットアップ方法や Kerberos 化された NFS 共有のマウント方法などの詳細は、Kerberos の使用 を参照してください。
以下の手順では、マシン設定を使用して 1 つ以上の拡張機能を RHCOS ノードに追加する方法を説明します。
前提条件
- OpenShift Container Platform クラスター (バージョン 4.6 以降) が実行中である。
- 管理者権限を持つユーザーとしてクラスターにログインしている。
手順
拡張機能のマシン設定を作成します。
MachineConfig
extensions
オブジェクトが含まれる 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.24.0
$ 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
5.3.4. マシン設定マニフェストでのカスタムファームウェアブロブの読み込み
/usr/lib
内のファームウェアブロブのデフォルトの場所は読み取り専用であるため、検索パスを更新して、カスタムファームウェアブロブを特定できます。これにより、ブロブが RHCOS によって管理されない場合に、マシン設定マニフェストでローカルファームウェアブロブを読み込むことができます。
手順
Butane 設定ファイル
98-worker-firmware-blob.bu
を作成します。このファイルは、root 所有でローカルストレージに書き込みできるように、検索パスを更新します。以下の例では、カスタムブロブファイルをローカルワークステーションからノードの/var/lib/firmware
下に配置しています。注記Butane の詳細は、Butane を使用したマシン設定の作成を参照してください。
カスタムファームウェアブロブ用の Butane 設定ファイル
variant: openshift version: 4.11.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 設定を保存します。
関連情報