4.21. Day 0 から Day 2 までの kmod インストール
Kernel Module Management (KMM) を使用せずに、Day 0 から Day 2 の操作中にいくつかのカーネルモジュール (kmod) をインストールできます。これは、kmod から KMM への移行に役立ちます。
適切な kmod インストールを決定するには、次の基準を使用します。
- Day 0
クラスター内でノードが
Ready
になるために必要な最も基本的な kmods。これらのタイプの kmod の例は次のとおりです。- ブートプロセスの一部として rootFS をマウントするために必要なストレージドライバー
-
マシンがブートストラップノード上の
machine-config-server
にアクセスして ignition をプルし、クラスターに参加するために必要なネットワークドライバー
- Day 1
クラスター内でノードが
Ready
になるために必要ではありませんが、ノードがReady
のときにアンロードできない Kmods。このタイプの kmod の例としては、
NetworkManager
が依存している間に NIC の潜在能力を最大限に活用するために、古くなったツリー内ドライバーを置き換えるツリー外 (OOT) ネットワークドライバーがあります。ノードがReady
の場合、NetworkManager
の依存関係のため、ドライバーをアンロードすることはできません。- Day 2
接続性などのクラスターインフラストラクチャーに干渉することなく、カーネルに動的にロードしたり、カーネルから削除したりできる Kmod。
これらのタイプの kmod の例は次のとおりです。
- GPU Operator
- セカンダリーネットワークアダプター
- Field-Programmable Gate Array (FPGA) デバイス
4.21.1. 背景のレイヤー化
Day 0 kmod がクラスターにインストールされると、Machine Config Operator (MCO) を通じてレイヤー化が適用され、OpenShift Container Platform のアップグレードによってノードのアップグレードはトリガーされません。
ノードのオペレーティングシステムは同じままなので、ドライバーに新しい機能を追加する場合にのみ、ドライバーを再コンパイルする必要があります。
4.21.2. ライフサイクル管理
ドライバーが許可している場合は、KMM を活用して、再起動せずに kmod の Day 0 から Day 2 までのライフサイクルを管理できます。
たとえば、initramfs
ファイルの再構築が必要な場合など、アップグレードにノードの再起動が必要な場合、これは機能しません。
ライフサイクル管理には、次のいずれかのオプションを使用します。
4.21.2.1. kmod をツリー内ドライバーとして扱う
kmods をアップグレードする場合は、この方法を使用します。この場合、kmod をインツリードライバーとして扱い、inTreeRemoval
フィールドを持つクラスター内に Module
を作成して、古いバージョンのドライバーをアンロードします。
kmod をインツリードライバーとして扱う場合の次の特性に注意してください。
- KMM が選択されたすべてのノードで同時に kmod をアンロードおよびロードしようとすると、ダウンタイムが発生する可能性があります。
- これは、KMM が単一の Pod を使用してドライバーをアンロードおよびロードするため、ドライバーを削除するとノードの接続が失われる場合に機能します。
4.21.2.2. 順序付きアップグレードの使用
順序付きアップグレード (ordered_upgrade.md) を使用すると、kmod がすでにロードされているため、効果のない kmod を表すクラスター内にバージョン管理された Module
を作成できます。
順序付きアップグレードを使用する場合は、次の特性に注意してください。
- アップグレードのペースと同時にアップグレードされるノードの数を制御できるため、クラスターのダウンタイムは発生しません。したがって、ダウンタイムのないアップグレードが可能になります。
- ドライバーをアンロードするとノードへの接続が失われる場合、この方法は機能しません。これは、KMM がアンロード用とロード用に 2 つの異なるワーカー Pod を作成するためです。これらの Pod はスケジュールされません。