Kubernetes、Node Feature Discovery経由でイメージ互換性メタデータを追加

2025年6月のKubernetes Blogの投稿で、HuaweiとLawrence Livermore National Laboratoryのエンジニアが、コンテナ互換性を処理する新手法について説明しました。この提案は、特殊なアプリケーションが、特定のホストオペレーティングシステムやハードウェアの要件をイメージメタデータ内で直接宣言できるようにする方法を扱っています。このアプローチは、既存のNode Feature Discoveryプロジェクトを活用し、コンテナ要件とクラスタノード機能間のギャップを埋めます。

何が起きたか

通信、高性能コンピューティング（HPC）、AIなどの分野におけるコンテナ化されたアプリケーションは、正確なホスト構成に依存することがよくあります。これらの依存関係には、標準的なコンテナイメージに含まれていない特定のカーネルバージョン、デバイスドライバ、システムライブラリが含まれる場合があります。Open Container Initiative（OCI）はイメージフォーマットの標準を提供していますが、以前はこれらのホストレベルの互換性要件を表現するための統一された方法がありませんでした。このギャップのため、チームは手動での事前設定やイミュータブルインフラストラクチャセットアップに頼らざるを得ず、マルチクラウド環境全体では管理が困難でした。

これを解決するために、著者らはイメージ互換性メタデータの仕様を提案しました。この仕様により、コンテナ作成者はアプリケーションに必要なホスト機能を正確に定義できます。この提案は、Kubernetes Node Feature Discovery（NFD）プロジェクト内で実装されました。NFDは、クラスタノードのハードウェアおよびソフトウェア機能を自動的に検出し、レポートするオープンソースツールです。互換性メタデータをNFDと統合することで、ユーザーはコンテナイメージによって定義された厳格なシステム要件を満たすノードのみでワークロードをスケジュールできるようになります。

この実装は、Kubernetesだけでなく、Singularityやその他のOCIアーティファクトなど、さまざまなコンテナテクノロジーをサポートしています。互換性要件を発見可能かつプログラム可能にすることを目的としています。つまり、特定のワークロードを実行できるかどうかを推測する代わりに、システムはデプロイ開始前に適合性を自動的に検証できます。これにより、ドライバの欠如や互換性のないカーネルモジュールによる実行時障害のリスクが軽減されます。

仕組み

コアメカニズムは、レジストリ内のコンテナイメージに構造化された互換性アーティファクトを添付することに基づいています。このアーティファクトは、OCI referrers APIを使用して、記述する特定のイメージにメタデータをリンクします。メタデータ自体はYAMLファイルであり、必要な「Node Feature Groups」をリストします。これらのグループは、NFDが検出できる機能（読み込まれたカーネルモジュール、CPUモデル、PCIデバイスなど）に基づくルールを定義します。

ユーザーがイメージをデプロイする場合、クライアントツールはレジストリから互換性アーティファクトを取得します。その後、アーティファクトに記載されている要件を、ターゲットノードが報告する実際の機能と比較します。ノードが指定されたすべてのルールに一致する場合、検証は合格となります。このプロセスは、Kubernetesクラスタ内または外で発生する可能性があり、ハイブリッドクラウドシナリオに対する柔軟性を提供します。システムは、match expressionsを使用して、特定の機能の存在を確認したり、値が許容範囲内にあることを検証したりします。

主要な詳細

• この仕様は、Chaoyi Huang、Marcin Franczyk、Vanessa Sochatによって2025年6月25日に公開されました。
• Kubernetes Node Feature Discovery（NFD）と統合され、コンテナ要件とノード機能をマッチングします。
• 互換性メタデータはOCIアーティファクトとして保存され、orasツールを使用してイメージに添付されます。
• スキーマには、version、compatibilities、rules、weight、tag、descriptionのフィールドが含まれます。
• スケジューリング前に、nfd compat validate-nodeコマンドを使用して検証を実行できます。
• このアプローチは、RHCOS、Photon OS、Amazon Linux 2、Azure Linux OSなど、多様な環境をサポートします。

なぜ重要なのか

規制対象や性能に敏感な業界で製品を構築するエンジニアにとって、この変更は運用上の摩擦を減らします。以前は、コンテナが特定のノードで実行できることを保証するには、基盤となるインフラストラクチャに関する深い知識や広範なテストが必要でした。明示的な互換性メタデータがあれば、デプロイパイプラインは不適切なノードを自動的に拒否できます。これにより、高コストの実行時エラーを防ぎ、GPUやInfinibandを使用するなど、厳格なハードウェア依存関係を持つアプリケーションが適切なインフラストラクチャ上で実行されることを保証します。

この開発はまた、マルチクラウドおよびハイブリッドクラウド戦略を簡素化します。異なるクラウドプロバイダーは異なる基本オペレーティングシステムを使用しており、それぞれに固有のカーネル構成とドライバセットがあります。要件を標準化された方法で定義することで、チームは一度書き込み、どこでもデプロイできます（ターゲットノードがNFDを通じて必要な機能を公開している場合）。ベンダーロックインを避けつつ高い信頼性を維持する必要がある組織にとって、この可搬性は極めて重要です。

さらに、これは将来のよりインテリジェントなスケジューリングのための基礎を築きます。エコシステムがこれらの標準を採用するにつれ、スケジューラは宣言された互換性プロファイルに基づいてノードを自動的に構成したり、最適なハードウェアを選択したりできるようになる可能性があります。これは、ワークロード配置が広いラベルではなく、正確な技術的制約によって駆動される、完全に自動化された自己修復型インフラストラクチャへの業界の移行を促進します。

できること

• Node Feature Discoveryプロジェクトのドキュメントを探索し、ハードウェアおよびソフトウェア機能を検出する方法を理解してください。
• orasツールを使用して、OCI準拠レジストリ内のコンテナイメージに互換性アーティファクトを添付してください。
• YAML形式で互換性ルールを定義し、必要なカーネルモジュール、CPUベンダー、PCIデバイスを指定してください。
• nfd compat validate-nodeクライアントツールをテストして、現在のノードがイメージ要件を満たしているか確認してください。
• Kubernetes Node Feature Discoveryコミュニティに参加し、Image Compatibility APIの継続的な開発に貢献してください。
• 既存のコンテナ化されたアプリケーションを見直し、この仕様の恩恵を受けられる隠れたホストOS依存関係を特定してください。