第8章 低レイテンシーの設定
8.1. 低レイテンシーの設定
低レイテンシー機能を設定してチューニングすることで、エッジデバイスでアプリケーションのパフォーマンスを向上させることができます。
8.1.1. MicroShift アプリケーションのレイテンシーの短縮
レイテンシーは、イベントからそのイベントへの応答までの時間として定義されます。エッジデバイスが外部イベントに迅速に応答する必要がある、運用上またはソフトウェア定義の制御システムで実行されている MicroShift クラスターで、低レイテンシー設定およびチューニングを使用できます。MicroShift の設定とオペレーティングシステムのチューニングとワークロードのパーティション分割を組み合わせることで、低レイテンシーのパフォーマンスを完全に最適化できます。
MicroShift サービス、OVS、CRI-O、MicroShift Pod、分離されたコアなどの管理アプリケーションの CPU セットには、すべてのオンライン CPU が含まれている必要があります。
8.1.1.1. MicroShift アプリケーションの低レイテンシーを設定するためのワークフロー
MicroShift クラスターで実行されているアプリケーションの低レイテンシーを設定するには、次のタスクを完了する必要があります。
- 必須
-
microshift-low-latency
RPM をインストールします。 - ワークロードのパーティション分割を設定します。
-
/etc/microshift/
ディレクトリーにあるconfig.yaml
ファイルのkubelet
セクションを設定します。 - TuneD プロファイルを設定してアクティブ化します。TuneD は、ホストシステムを監視し、特定のワークロードでパフォーマンスを最適化する Red Hat Enterprise Linux (RHEL) のサービスです。
- ホストを再起動します。
-
- 任意
- x86_64 アーキテクチャーを使用している場合は、Red Hat Enterprise Linux for Real Time 9 をインストールできます。
関連情報
- 低レイテンシーについて (OpenShift Container Platform のドキュメント)
8.1.2. MicroShift の低レイテンシー RPM パッケージのインストール
MicroShift をインストールする際に、低レイテンシー RPM パッケージはデフォルトでインストールされません。低レイテンシー RPM は、オプションのパッケージとしてインストールできます。
前提条件
- MicroShift RPM をインストールしている。
- MicroShift のワークロードのパーティション分割を設定している。
手順
次のコマンドを実行して、低レイテンシーの RPM パッケージをインストールします。
$ sudo dnf install -y microshift-low-latency
ヒントTuneD プロファイルがアクティブ化されるのを待ってから、ホストを再起動します。ホストを再起動することで MicroShift と CRI-O が再起動され、低レイテンシーマニフェストが適用され、TuneD プロファイルがアクティブ化されます。
次のステップ
-
MicroShift
config.yaml
で、低レイテンシー用の kubelet パラメーターを設定します。 - オペレーティングシステムを調整してください。たとえば、TuneD プロファイルを設定してアクティブ化します。
- オプション: TuneD プロファイルの自動アクティブ化を設定します。
- オプション: x86_64 アーキテクチャーを使用している場合は、Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) をインストールします。
- 低レイテンシー用にワークロードを準備します。
8.1.3. MicroShift での kubelet パラメーターおよび値の設定
MicroShift クラスターへの低レイテンシーを有効化するための最初の手順は、MicroShift config.yaml
ファイルに設定を追加することです。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - クラスターへの root アクセス権限がある。
-
/etc/microshift/
ディレクトリーにある指定されたconfig.yaml.default
ファイルのコピーを作成し、config.yaml
という名前を付けている。
手順
kubelet 設定を MicroShift
config.yaml
ファイルに追加します。パススルー
kubelet
設定の例apiServer: # ... kubelet: 1 cpuManagerPolicy: static 2 cpuManagerPolicyOptions: full-pcpus-only: "true" 3 cpuManagerReconcilePeriod: 5s memoryManagerPolicy: Static 4 topologyManagerPolicy: single-numa-node reservedSystemCPUs: 0-1 5 reservedMemory: - limits: memory: 1100Mi 6 numaNode: 0 kubeReserved: memory: 500Mi systemReserved: memory: 500Mi evictionHard: 7 imagefs.available: "15%" 8 memory.available: "100Mi" 9 nodefs.available: "10%" 10 nodefs.inodesFree: "5%" 11 evictionPressureTransitionPeriod: 0s # ...
- 1
- kubelet 設定で CPU またはメモリーマネージャーを変更する場合は、以前の設定をキャッシュするファイルを削除する必要があります。ホストを再起動してそれらを自動的に削除するか、
/var/lib/kubelet/cpu_manager_state
ファイルおよび/var/lib/kubelet/memory_manager_state
ファイルを手動で削除します。 - 2
- 使用するポリシーの名前。有効な値は
none
およびstatic
です。CPUManager
フィーチャーゲートを有効化する必要があります。デフォルト値はnone
です。 - 3
CPUManager
ポリシーの動作を微調整する追加のオプションを設定するためのkey=value
ペアのセット。デフォルト値はnull
です。CPUManager
とCPUManagerPolicyOptions
機能ゲートの両方を有効化する必要があります。- 4
- Memory Manager が使用するポリシーの名前。大文字と小文字を区別します。デフォルト値は
none
です。MemoryManager
フィーチャーゲートを有効化する必要があります。 - 5
- 必須。
reservedSystemCPUs
の値は、オフライン化された CPU の逆数である必要があります。なぜなら、これら両方を合わせた値は、システム上のすべての CPU を考慮する必要があるためです。このパラメーターは、管理およびアプリケーションワークロードを分割する上で不可欠です。このパラメーターを使用して、ホストレベルのシステムおよび Kubernetes デーモン、さらに割り込みやタイマーのための静的 CPU セットを定義します。その後、システム上の残りの CPU はワークロード専用に使用できます。 - 6
- この例の
reservedMemory[0].limits.memory
、1100
Mi の値は、kubeReserved.memory
+systemReserved.memory
+evictionHard.memory.available
に相当します。 - 7
evictionHard
パラメーターは、kubelet が Pod をエビクトする条件を定義します。evictionHard
スタンザの 1 つのみのパラメーターのデフォルト値を変更する場合、他のパラメーターのデフォルト値は継承されず、ゼロに設定されます。1 つだけ変更したい場合でも、すべてのしきい値を指定します。- 8
imagefs
は、コンテナーランタイムがコンテナーイメージとコンテナーの書き込み可能な階層を保存するために使用するファイルシステムです。この例では、evictionHard.imagefs.available
パラメーターは、イメージファイルシステムで利用可能な領域が 15% 未満の場合に Pod がエビクトされることを意味します。- 9
- この例では、
evictionHard.memory.available
パラメーターは、ノードの利用可能なメモリーが 100 MiB 未満の場合に Pod がエビクトされることを意味します。 - 10
- この例では、
evictionHard.nodefs.available
パラメーターは、ノードのメインファイルシステムに空き容量が 10% 未満になると Pod がエビクトされることを意味します。 - 11
- この例では、
evictionHard.nodefs.inodesFree
パラメーターは、ノードのメインファイルシステムの inode のうち 15% 強が使用されている場合に Pod がエビクトされることを意味します。
検証
-
次のステップを完了してホストを再起動したら、root-access アカウントを使用して、設定が
/var/lib/microshift/resources/kubelet/config/
ディレクトリーのconfig.yaml
ファイルにあることを確認できます。
次のステップ
- ワークロードのパーティション分割を有効化します。
- オペレーティングシステムを調整します。たとえば、TuneD プロファイルを設定およびアクティブ化します。
- オプション: TuneD プロファイルの自動有効化を設定します。
- オプション: x86_64 アーキテクチャーを使用している場合は、Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) をインストールできます。
- 低レイテンシー用に MicroShift ワークロードを準備します。
関連情報
- YAML 設定ファイルの使用
- KubeletConfiguration リファレンス (Kubernetes アップストリームのドキュメント)
8.1.4. Red Hat Enterprise Linux 9 のチューニング
Red Hat Enterprise Linux (RHEL) システム管理者は、TuneD サービスを使用して、さまざまなユースケースに対して RHEL のパフォーマンスプロファイルを最適化できます。TuneD は、レイテンシーのパフォーマンスを含む、特定のワークロードでシステムパフォーマンスを監視し、最適化します。
- TuneD プロファイルを使用して、低レイテンシーの MicroShift クラスターのデプロイなど、さまざまなユースケースに合わせてシステムを調整します。
- 各プロファイルに定義されたルールを変更し、特定のデバイスのチューニングをカスタマイズできます。
- 別のプロファイルに切り替えたり、TuneD を非アクティブ化すると、以前のプロファイルがシステム設定に加えた変更はすべて、元の状態に戻ります。
- また、TuneD を設定してデバイスの使用状況の変化に対応し、設定を調整して、アクティブなデバイスのパフォーマンスを向上させ、非アクティブなデバイスの消費電力を削減することもできます。
8.1.4.1. MicroShift TuneD プロファイルの設定
microshift-low-latency
RPM パッケージをインストールした後、Red Hat Enterprise Linux (RHEL) /etc/tuned/
host ディレクトリーで提供される microshift-baseline-variables.conf
設定ファイルを使用して、MicroShift ワークロードで低レイテンシーを使用するようにホストの TuneD プロファイルを設定します。
前提条件
- クラスターへの root アクセス権限がある。
-
microshift-low-latency
RPM パッケージをインストールしている。 - RHEL ホストに TuneD がインストールされている。TuneD のスタートガイド (RHEL ドキュメント) を参照してください。
手順
/etc/tuned/
ディレクトリープロファイルでデフォルトのmicroshift-baseline-variables.conf
TuneD プロファイルを使用するか、独自のチューニングを作成してチューニングをさらに追加できます。microshift-baseline-variables.conf
TuneD プロファイルの例# Isolate cores 2-7 for running application workloads isolated_cores=2-7 1 # Size of the hugepages hugepages_size=2M 2 # Number of hugepages hugepages=0 # Additional kernel arguments additional_args= 3 # CPU set to be offlined offline_cpu_set= 4
- 1
- 分離する必要のあるコアを制御します。MicroShift では、ハウスキーピング用にソケットごとに 1 コアがデフォルトで予約されています。他のコアは分離されます。有効な値はコアリストまたは範囲です。任意の範囲 (例:
isolated_cores=2,4-7
またはisolated_cores=2-23
) を分離できます。重要isolated_cores=
変数を 1 つだけ維持する必要があります。注記Kubernetes CPU マネージャーは、kubelet 設定で定義された予約済み CPU を除き、任意の CPU を使用してワークロードを実行できます。このような理由から、以下が最善となります。
- kubelet の予約 CPU と分離されたコアの合計には、すべてのオンライン CPU が含まれます。
- 分離されたコアは、kubelet 設定で定義された予約済み CPU に補完されます。
- 2
- hugepages のサイズ。有効な値は 2M または 1G です。
- 3
- 追加のカーネル引数 (
additional_args=console=tty0 console=ttyS0,115200
など) - 4
- オフラインに設定された CPU。重要
isolated_cores
と重複することはできません。
次のコマンドを実行して、プロファイルを有効化するか、変更をアクティブにします。
$ sudo tuned-adm profile microshift-baseline
- ホストを再起動して、カーネル引数をアクティブにします。
検証
オプション: 起動時に現在実行中のカーネルに指定された引数を含む
/proc/cmdline
ファイルを読み取ることができます。$ cat /proc/cmdline
出力例
BOOT_IMAGE=(hd0,msdos2)/ostree/rhel-7f82ccd9595c3c70af16525470e32c6a81c9138c4eae6c79ab86d5a2d108d7fc/vmlinuz-5.14.0-427.31.1.el9_4.x86_64+rt crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M rd.lvm.lv=rhel/root fips=0 console=ttyS0,115200n8 root=/dev/mapper/rhel-root rw ostree=/ostree/boot.1/rhel/7f82ccd9595c3c70af16525470e32c6a81c9138c4eae6c79ab86d5a2d108d7fc/0 skew_tick=1 tsc=reliable rcupdate.rcu_normal_after_boot=1 nohz=on nohz_full=2,4-5 rcu_nocbs=2,4-5 tuned.non_isolcpus=0000000b intel_pstate=disable nosoftlockup hugepagesz=2M hugepages=10
次のステップ
- 低レイテンシー用に MicroShift ワークロードを準備します。
- オプション: TuneD プロファイルの自動有効化を設定します。
- オプション: x86_64 アーキテクチャーを使用している場合は、Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) をインストールできます。
関連情報
- TuneD のスタートガイド (RHEL ドキュメント)
- How to manage tuning profiles in Linux (Red Hat ブログ)
8.1.4.2. MicroShift TuneD プロファイルを自動的に有効化する
microshift-low-latency
RPM パッケージには、システムの起動時に TuneD プロファイルを自動的に有効化するように設定可能な systemd サービスが含まれています。この機能は、大量のデバイスに MicroShift をインストールする場合に特に便利です。
前提条件
- ホストに microshift-low-latency RPM パッケージをインストールしている。
-
MicroShift の
config.yaml
で低レイテンシーを有効化している。 - TuneD プロファイルを作成している。
-
microshift-baseline-variables.conf
ファイルを設定している。
手順
/etc/microshift/
ディレクトリーでtuned.yaml
を設定します。次に例を示します。tuned.yaml の例
profile: microshift-baseline 1 reboot_after_apply: True 2
重要ホストは、
microshift-tuned.service
の実行時に再起動されますが、新しいコミットのデプロイ時にシステムは再起動されません。ホストを再起動して新しいコミットを有効化する必要があります。その後、起動時にmicroshift-tuned.service
が実行され、プロファイルと変数への変更が検出されたときに、システムが再び起動します。この二重ブートはロールバックに影響を及ぼす可能性があります。自動プロファイルアクティブ化の使用時に、ロールバック前に許可される greenboot での再起動の回数を調整してください。たとえば、greenboot でロールバック前に 3 回の再起動が許可されている場合、その回数を 4 回に増やします。詳細は、関連情報のリストを参照してください。
次のコマンドを入力して、
microshift-tuned.service
が各システムの起動時に実行できるようにします。$ sudo systemctl enable microshift-tuned.service
重要reboot_after_apply
をTrue
に設定する場合は、TuneD プロファイルがアクティブであること、および 他のプロファイルが MicroShift サービス外でアクティブ化されていないことを確認してください。そうしない場合、microshift-tuned.service
を起動すると、ホストが再起動されます。次のコマンドを実行して、
microshift-tuned.service
を起動します。$ sudo systemctl start microshift-tuned.service
注記microshift-tuned.service
は、収集したチェックサムを使用して、一部の TuneD プロファイルと変数への変更を検出します。ディスクにチェックサムがない場合は、サービスは TuneD プロファイルをアクティブ化し、ホストを再起動します。microshift-tuned.service
の初めて起動する際は、ホストの再起動が必要です。
次のステップ
- オプション: x86_64 アーキテクチャーを使用している場合は、Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) をインストールできます。
関連情報
8.1.5. Red Hat Enterprise Linux for Real-Time の使用
ワークロードが割り込み処理やプロセススケジューリングなど、マイクロ秒 (μs) 単位の低レイテンシーかつ決定論的なコアカーネル機能を厳密に求める場合、Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) を使用できます。リアルタイムカーネルの目的は、予測可能な応答時間を提供する、一貫性のある低レイテンシーの決定論です。
システムのチューニングを検討する際には、以下の要素を考慮してください。
- リアルタイムカーネルを使用する場合でも、標準カーネルと同様にシステムのチューニングは重要です。
- RHEL 9 リリースの一部として提供される標準カーネルを実行する未チューニングのシステムに、リアルタイムカーネルをインストールしても、目立った利点はありません。
- 標準カーネルを調整することで、達成可能なレイテンシー改善の 90% が得られます。
- リアルタイムカーネルは、最も要求の厳しいワークロードで必要とされる、レイテンシー改善の最後の 10% を提供します。
8.1.5.1. Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) のインストール
低レイテンシーのワークロードにはリアルタイムカーネルは必要ありませんが、リアルタイムカーネルを使用すると低レイテンシーのパフォーマンスを最適化できます。RPM パッケージを使用してホストにインストールし、Red Hat Enterprise Linux for Edge (RHEL for Edge) イメージのデプロイメントに追加することができます。
前提条件
- Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) を含む Red Hat サブスクリプションがある。たとえば、ホストマシンが登録され、Red Hat Enterprise Linux (RHEL) が RHEL for Real Time サブスクリプにアタッチされています。
- x86_64 アーキテクチャーを使用している。
手順
次のコマンドを実行して、リアルタイムカーネルリポジトリーを有効化します。
$ sudo subscription-manager repos --enable rhel-9-for-x86_64-rt-rpms
次のコマンドを実行して、リアルタイムカーネルをインストールします。
$ sudo dnf install -y kernel-rt
次のコマンドを実行して、リアルタイムカーネルのバージョンをクエリーします。
$ RTVER=$(rpm -q --queryformat '%{version}-%{release}.%{arch}' kernel-rt | sort | tail -1)
次のコマンドを実行して、リアルタイムカーネルをデフォルトのカーネルとして指定する GRUB に永続的な変更を加えます。
$ sudo grubby --set-default="/boot/vmlinuz-${RTVER}+rt"
- ホストを再起動して、リアルタイムカーネルをアクティブ化します。
次のステップ
- 低レイテンシー用に MicroShift ワークロードを準備します。
- オプション: ブループリントを使用して、RHEL for Edge イメージにリアルタイムカーネルをインストールします。
8.1.5.2. Red Hat Enterprise Linux for Edge (RHEL for Edge) イメージに Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) をインストールする
Image Builder を使用して、RHEL for Edge イメージデプロイメントにリアルタイムカーネルを含めることができます。次のブループリントセクションの例には、MicroShift クラスターの低レイテンシーを設定するために必要だった前の手順で収集した参照が含まれています。
前提条件
- Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) を含むホストで Red Hat サブスクリプションを有効化している。
- x86_64 アーキテクチャーを使用している。
-
kernel-rt
リポジトリーを使用するようにosbuild
を設定している。
リアルタイムカーネルを含むサブスクリプションは、コミットのビルドに使用するホストで有効化する必要があります。
手順
RHEL for Edge イメージにリアルタイムカーネルをインストールするための完全なインストールブループリントに、以下の例のブループリントセクションを追加してください。
リアルタイムカーネルのブループリントスニペットの例
[[packages]] name = "microshift-low-latency" version = "*" # Kernel RT is supported only on the x86_64 architecture [customizations.kernel] name = "kernel-rt" [customizations.services] enabled = ["microshift", "microshift-tuned"] [[customizations.files]] path = "/etc/microshift/config.yaml" data = """ kubelet: cpuManagerPolicy: static cpuManagerPolicyOptions: full-pcpus-only: "true" cpuManagerReconcilePeriod: 5s memoryManagerPolicy: Static topologyManagerPolicy: single-numa-node reservedSystemCPUs: 0-1 reservedMemory: - limits: memory: 1100Mi numaNode: 0 kubeReserved: memory: 500Mi systemReserved: memory: 500Mi evictionHard: imagefs.available: 15% memory.available: 100Mi nodefs.available: 10% nodefs.inodesFree: 5% evictionPressureTransitionPeriod: 0s """ [[customizations.files]] path = "/etc/tuned/microshift-baseline-variables.conf" data = """ # Isolated cores should be complementary to the kubelet configuration reserved CPUs. # Isolated and reserved CPUs must contain all online CPUs. # Core #3 is for testing offlining, therefore it is skipped. isolated_cores=2,4-5 hugepages_size=2M hugepages=10 additional_args=test1=on test2=true dummy offline_cpu_set=3 """ [[customizations.files]] path = "/etc/microshift/tuned.yaml" data = """ profile: microshift-baseline reboot_after_apply: True """
次のステップ
- イメージのビルドプロセスを完了します。
- MicroShift クラスターの低レイテンシーを有効化するための以前の手順を完了していない場合は、今すぐ完了してください。これらの手順で収集された情報を使用してブループリントを更新します。
- ワークロードのパーティション分割を設定していない場合は、今すぐ設定してください。
- 低レイテンシー用に MicroShift ワークロードを準備します。
8.1.6. リアルタイムカーネルを使用した Red Hat Enterprise Linux for Edge (RHEL for Edge) イメージのビルド
ビルドプロセスを完了するには、RHEL for Edge イメージに MicroShift を埋め込む以下の手順から開始します。次に、RHEL for Edge イメージに MicroShift をインストールするためのインストールドキュメントの残りの手順を完了します。
関連情報
- Red Hat Enterprise Linux for Real Time 9 (RHEL のドキュメント)
- Using repositories that require subscription (osbuild のドキュメント)
- リアルタイムカーネルを使用した RHEL イメージのビルド
- インストール後の手順 (RHEL for Real Time のドキュメント)
- RHEL for Edge イメージへの埋め込み
- FAQ about RHEL for Real Time (kernel-rt)
8.1.7. 低レイテンシーに対する MicroShift ワークロードの準備
低レイテンシーを利用するには、MicroShift で実行されるワークロードでは、RuntimeClass
機能を使用して microshift-low-latency
コンテナーのランタイム設定を行う必要があります。CRI-O RuntimeClass
オブジェクトは microshift-low-latency
RPM でインストールされるため、Pod アノテーションのみを設定する必要があります。
前提条件
-
microshift-low-latency
RPM パッケージをインストールしている。 - ワークロードのパーティション分割を設定している。
手順
以下の例を使用して、Pod 仕様で次のアノテーションを設定します。
cpu-load-balancing.crio.io: "disable" irq-load-balancing.crio.io: "disable" cpu-quota.crio.io: "disable" cpu-load-balancing.crio.io: "disable" cpu-freq-governor.crio.io: "<governor>"
oslat
テストを実行する Pod の例:apiVersion: v1 kind: Pod metadata: name: oslat annotations: cpu-load-balancing.crio.io: "disable" 1 irq-load-balancing.crio.io: "disable" 2 cpu-quota.crio.io: "disable" 3 cpu-c-states.crio.io: "disable" 4 cpu-freq-governor.crio.io: "<governor>" 5 spec: runtimeClassName: microshift-low-latency 6 containers: - name: oslat image: quay.io/container-perf-tools/oslat imagePullPolicy: Always resources: requests: memory: "400Mi" cpu: "2" limits: memory: "400Mi" cpu: "2" env: - name: tool value: "oslat" - name: manual value: "n" - name: PRIO value: "1" - name: delay value: "0" - name: RUNTIME_SECONDS value: "60" - name: TRACE_THRESHOLD value: "" - name: EXTRA_ARGS value: "" securityContext: privileged: true capabilities: add: - SYS_NICE - IPC_LOCK
- 1
- Pod の CPU 負荷分散を無効化します。
- 2
- Pod の割り込み処理 (IRQ) をオプトアウトします。
- 3
- Pod の実行時に CPU Completely Fair Scheduler (CFS) のクォータを無効にします。
- 4
- 各 CPU の C-状態を有効化または無効化します。優先順位の高い Pod で最高のパフォーマンスを提供するには、値を
disable
に設定します。 - 5
- 各 CPU の
cpufreq
ガバナーを設定します。performance
ガバナーは、優先度の高いワークロードに推奨されます。 - 6
runtimeClassName
は、クラスターで設定したパフォーマンスプロファイルの名前と一致している必要があります。たとえば、microshift-low-latency
です。
注記CPU マネージャーの静的ポリシーが有効化され、CPU 全体を使用する Guaranteed QoS を持つ Pod に対してのみ、CPU 負荷分散を無効化します。これ以外の場合に CPU 負荷分散を無効にすると、クラスター内の他のコンテナーのパフォーマンスに影響する可能性があります。
重要Pod が
Guaranteed
QoS クラスを持つには、要求と制限で CPU およびメモリーの値が同じである必要があります。Guaranteed (Kubernetes アップストリームのドキュメント) を参照してください。
関連情報
- Disabling power saving mode for high priority pods (Red Hat OpenShift Container Platform のドキュメント)
- Disabling CPU CFS quota (Red Hat OpenShift Container Platform のドキュメント)
- Disabling interrupt processing for CPUs where pinned containers are running (Red Hat OpenShift Container Platform のドキュメント)
8.1.8. RHEL for Edge イメージに Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) をインストールするための参照ブループリント
イメージのブループリントは、複数のビルドを作成できる必要なイメージのカスタマイズの永続的な定義です。各イメージビルドのブループリントを再設定する代わりに、ブループリントからイメージを継続的に再ビルドできるように、ブループリントを編集、再ビルド、削除、および保存できます。
RHEL for Edge イメージにリアルタイムカーネルをインストールするために使用されるブループリントの例
name = "microshift-low-latency" description = "RHEL 9.4 and MicroShift configured for low latency" version = "0.0.1" modules = [] groups = [] distro = "rhel-94" [[packages]] name = "microshift" version = "*" [[packages]] name = "microshift-greenboot" version = "*" [[packages]] name = "microshift-networking" version = "*" [[packages]] name = "microshift-selinux" version = "*" [[packages]] name = "microshift-low-latency" version = "*" # Kernel RT is only available for x86_64 [customizations.kernel] name = "kernel-rt" [customizations.services] enabled = ["microshift", "microshift-tuned"] [customizations.firewall] ports = ["22:tcp", "80:tcp", "443:tcp", "5353:udp", "6443:tcp", "30000-32767:tcp", "30000-32767:udp"] [customizations.firewall.services] enabled = ["mdns", "ssh", "http", "https"] [[customizations.firewall.zones]] name = "trusted" sources = ["10.42.0.0/16", "169.254.169.1"] [[customizations.files]] path = "/etc/microshift/config.yaml" data = """ kubelet: cpuManagerPolicy: static cpuManagerPolicyOptions: full-pcpus-only: "true" cpuManagerReconcilePeriod: 5s memoryManagerPolicy: Static topologyManagerPolicy: single-numa-node reservedSystemCPUs: 0-1 reservedMemory: - limits: memory: 1100Mi numaNode: 0 kubeReserved: memory: 500Mi systemReserved: memory: 500Mi evictionHard: imagefs.available: 15% memory.available: 100Mi nodefs.available: 10% nodefs.inodesFree: 5% evictionPressureTransitionPeriod: 0s """ [[customizations.files]] path = "/etc/tuned/microshift-baseline-variables.conf" data = """ # Isolated cores should be complementary to the kubelet configuration reserved CPUs. # Isolated and reserved CPUs must contain all online CPUs. # Core #3 is for testing offlining, therefore it is skipped. isolated_cores=2,4-5 hugepages_size=2M hugepages=10 additional_args=test1=on test2=true dummy offline_cpu_set=3 """ [[customizations.files]] path = "/etc/microshift/tuned.yaml" data = """ profile: microshift-baseline reboot_after_apply: True """
関連情報