4.18. Day 1 カーネルモジュールのロード
				Kernel Module Management (KMM) は通常、Day 2 Operator です。カーネルモジュールは、Linux (RHCOS) サーバーの初期化が完了しなければロードされません。ただし、シナリオによっては、カーネルモジュールを早い段階でロードする必要があります。Day 1 機能を使用すると、Linux systemd の初期化段階で Machine Config Operator (MCO) を使用してカーネルモジュールをロードできます。
			
4.18.1. Day 1 のサポート対象ユースケース
					Day 1 機能がサポートするユースケースの数は限られています。主なユースケースは、NetworkManager サービスの初期化前にツリー外 (OOT) のカーネルモジュールをロードできるようにすることです。initramfs 段階でのカーネルモジュールのロードはサポートされていません。
				
Day 1 機能に必要な条件は次のとおりです。
- カーネルモジュールはカーネルにロードされていない。
- ツリー内カーネルモジュールがカーネルにロードされているが、アンロードして OOT カーネルモジュールに置き換えることができる。これは、ツリー内モジュールが他のカーネルモジュールから参照されていないことを意味します。
- Day 1 機能が正常に機能するためには、ノードに機能するネットワークインターフェイス、つまりそのインターフェイス用のツリー内カーネルドライバーが必要。OOT カーネルモジュールは、正常に機能するネットワークドライバーを置き換えるネットワークドライバーにできます。
4.18.2. OOT カーネルモジュールのローディングフロー
ツリー外 (OOT) カーネルモジュールのロードには、Machine Config Operator (MCO) が利用されます。フローシーケンスは次のとおりです。
手順
- 
							MachineConfigリソースを実行中の既存クラスターに適用します。更新する必要があるノードを特定するには、適切なMachineConfigPoolリソースを作成する必要があります。
- 
							MCO はノードごとに再起動を適用します。再起動されたノードには、pullサービスとloadサービスという 2 つの新しいsystemdサービスがデプロイされます。
- 
							loadサービスは、NetworkConfigurationサービスの前に実行されるように設定されています。サービスは、事前定義されたカーネルモジュールイメージをプルし、次にそのイメージを使用してツリー内モジュールをアンロードし、OOT カーネルモジュールをロードしようとします。
- 
							pullサービスは、NetworkManager サービスの後に実行されるように設定されています。サービスは、事前設定されたカーネルモジュールイメージがノードのファイルシステム上に配置されているか確認します。そのようになっている場合、サービスは正常に存在し、サーバーはブートプロセスを続行します。そうでない場合は、イメージをノードにプルし、その後ノードを再起動します。
4.18.3. カーネルモジュールイメージ
					Day 1 機能は、Day 2 KMM ビルドで利用されるのと同じ DTK ベースのイメージを使用します。ツリー外のカーネルモジュールは、/opt/lib/modules/${kernelVersion} の配下にある必要があります。
				
4.18.4. ツリー内モジュールの置き換え
Day 1 機能は常に、ツリー内のカーネルモジュールを OOT バージョンに置き換えようとします。ツリー内カーネルモジュールがロードされていない場合、フローは影響を受けません。サービスは続行し、OOT カーネルモジュールをロードします。
4.18.5. MCO yaml の作成
KMM は、Day 1 機能の MCO YAML マニフェストの作成に使用する API を提供します。
ProduceMachineConfig(machineConfigName, machineConfigPoolRef, kernelModuleImage, kernelModuleName string) (string, error)
ProduceMachineConfig(machineConfigName, machineConfigPoolRef, kernelModuleImage, kernelModuleName string) (string, error)返される出力は、適用される MCO YAML マニフェストの文字列表現です。この YAML を適用するかどうかはお客様が判断します。
パラメーターは以下のとおりです。
- machineConfigName
- 
								MCO YAML マニフェストの名前。このパラメーターは、MCO YAML マニフェストのメタデータの nameパラメーターとして設定されます。
- machineConfigPoolRef
- 
								ターゲットノードを識別するために使用される MachineConfigPool名。
- kernelModuleImage
- OOT カーネルモジュールを含むコンテナーイメージの名前。
- kernelModuleName
- OOT カーネルモジュールの名前。このパラメーターは、ツリー内カーネルモジュール (カーネルにロードされている場合) のアンロードと OOT カーネルモジュールのロードの両方に使用されます。
					API は、KMM ソースコードの pkg/mcproducer パッケージの下にあります。Day 1 機能を使用するために KMM Operator を実行する必要はありません。必要なのは、pkg/mcproducer パッケージを Operator/ユーティリティーコードにインポートし、API を呼び出し、生成された MCO YAML をクラスターに適用することだけです。
				
4.18.6. MachineConfigPool
					MachineConfigPool は、適用された MCO の影響を受けるノードのコレクションを識別します。
				
					OCP クラスターには、事前定義された MachineConfigPool があります。
				
- 
							worker: クラスター内のすべてのワーカーノードをターゲットにします
- 
							master: クラスター内のすべてのマスターノードをターゲットにします
					マスター MachineConfigPool をターゲットにするために、次の MachineConfig を定義します。
				
metadata:
  labels:
    machineconfiguration.opensfhit.io/role: master
metadata:
  labels:
    machineconfiguration.opensfhit.io/role: master
					ワーカー MachineConfigPool をターゲットにするために、次の MachineConfig を定義します。
				
metadata:
  labels:
    machineconfiguration.opensfhit.io/role: worker
metadata:
  labels:
    machineconfiguration.opensfhit.io/role: worker