Red Hat Enterprise Linux のコンテナー互換性マトリックス

Red Hat Enterprise Linux には、新しいレベルのワークロードの分離と移植性を可能にする強力なコンテナーテクノロジーが含まれています。コンテナーは他のコンテナー間で確実に分離されていますが、重要なインターフェイスについては、基礎となる Linux ホストおよびカーネルに直接依存します。コンテナーイメージ と コンテナーホスト でオペレーティングシステムのバージョンを混在させたり一致させたりすることには、既知の制限があります。この記事では、ガイダンスとサポートの制限について説明します。

* ドキュメント RHCOS および OpenShift Container Platform で使用される RHEL バージョン を参照して、特定の OpenShift リリースで使用される RHEL CoreOS のバージョンを、ここにリストされている主要な RHEL バージョンにマップしてください。

Red Hat は、(前述のように) RHEL のさまざまなメジャーバージョン間の互換性を確保するために取り組んでおり、お客様が実稼働環境でさまざまなコンテナーイメージとホストを柔軟に運用できるようにします。これらの組み合わせにより、多くのアプリケーションの有用なライフサイクルが拡張され、アップグレードの懸念が軽減されます。

Red Hat Support チームは、「完全互換」設定と「ワークロード固有」設定 (以下に説明) で、提供するサポートを区別する場合があります。 サポート担当者にお問い合わせください。

コンテナー互換性のガイドライン

特定のユースケースでは、Red Hat は、RHEL ベースのコンテナーイメージと RHEL コンテナーホストのメジャーバージョンを調整することを推奨します。Red Hat は、他のコンテナーエンジンとランタイムがサポートされていないため、Red Hat コンテナーサポートポリシー に従うこともお勧めします。

RHEL バージョン 8 以降では、Red Hat は、サポートされているアーキテクチャー (Intel/Amd x86、Arm AArch64、IBM POWER、および zSeries) ごとにコンテナーイメージを提供します。通常、正しいハードウェアアーキテクチャーが自動的に検出され、正しいイメージが使用されます。一致しないハードウェアアーキテクチャーを使用すること (x86 コンテナーホストで AArch64 コンテナーイメージを実行するなど) は推奨またはサポートされておらず、正常に機能しない可能性が高いです。コンテナーイメージが適切に実行され、サポートされるためには、コンテナーイメージとホストアーキテクチャーが一致している必要があります。イメージを正しく実行するには、コンテナーホストのハードウェアが、コンテナーイメージの 最小ハードウェア要件 も満たしている必要があります (例: IBM POWER LE の RHEL 9 コンテナーイメージには POWER9 ハードウェアが必要で、x86_64 の RHEL 10 コンテナーイメージには x86-64-v3 が必要です)。

古いコンテナーホストで新しいコンテナーイメージを実行する場合、既知の制限があり、この設定は多くの場合機能しますが、このような設定では追加のリスクと互換性の問題が発生する可能性があります。お客様がこれらの制限に遭遇した場合、Red Hat ではコンテナーホストをアップグレードすることを推奨しています。

コンテナーが 特権 付きで実行される場合 (例: podman run --privileged)) や、基礎となるホストを変更する場合、Red Hat はコンテナーイメージとコンテナーホスト間で一致するメジャーバージョンのみをサポートします (例: RHEL 10 ホスト上の RHEL 10 イメージ）。この推奨事項は、検査またはモニタリングの目的で、コンテナーに他のコンテナーと対話するためのセキュリティー特権が付与されている場合にも該当します。イメージとホストのメジャーバージョンを揃えることで、最高レベルの互換性が確保され、異なるバージョンのコンテナーイメージ (ユーザー空間) とコンテナーホスト (カーネル) を混在させるときにユーザーが遭遇する多くのエッジケースが排除されます。

最後に、新しいコンテナーホストで非常に古いイメージを実行すると、問題が発生する可能性があります (例: RHEL 9 または 10 ホスト上の RHEL 6 コンテナーイメージ)。 このような状況では、Red Hat は上記の表でサポートされているバージョン (RHEL 9 ホストでの RHEL 8、RHEL 9、RHEL 10 イメージなど) を使用することを推奨します。

詳細なサポート条件

以下に定義される設定は、 Red Hat Enterprise Linux 10: Application Compatibility Guide に取って代わるものではなく、コンテナーイメージ内で提供される Red Hat ソフトウェアのサポートは、引き続きこれらのガイドラインによって管理されます。ワークロードのより具体的な定義については、以下のガイドラインを参照してください。

完全互換 (推奨)

「完全互換」 設定とは、UBI10 ベースイメージに基づくコンテナーを実行する RHEL10 ホストなど、コンテナーホストのメジャーバージョンがコンテナーベースイメージのメジャーバージョンと一致する設定です。

コンテナーイメージとホスト間で最も互換性を必要とするアプリケーションの開発やデプロイメントには、“完全互換” 設定が推奨されます。

“完全互換” 設定とは、コンテナーイメージとコンテナーホストが完全にサポートされ、一緒にテストされていることを意味します。この設定により、すべての低レベルのカーネルサブシステムが、同じユーザー空間およびカーネルドライバーコンポーネントを使用するようになります。特権コンテナーの実行はサポートされていますが、特定のワークロードでは、コンテナーホストのマイナーバージョンがコンテナーイメージのマイナーバージョンと同じである必要がある場合があります。

ワークロード固有

「ワークロード固有」設定とは、UBI8 ベースイメージに基づくコンテナーを実行する RHEL10 ホストなど、コンテナーホストのメジャーバージョンがコンテナーベースイメージのメジャーバージョンと一致しない設定です。

”ワークロード固有” (権限のない) 設定とは、コンテナーイメージとコンテナーホストの組み合わせにサポートの制限があることを意味します。公開される可能性のある問題は、以下で説明されているように、Red Hat Enterprise Linux のライフサイクル およびサポートポリシーに従って処理されます。

1. 以下の条件をすべて満たす場合には、サポート可能な方法で、新しいコンテナーホストでそのホストよりも古いコンテナーのイメージを実行できます。
   1. コンテナーイメージ内の Red Hat Enterprise Linux のメジャーバージョンは、サポート対象の RHEL ライフサイクル に含まれている。 たとえば、RHEL 8 が延長ライフフェーズに達すると、使用されている基礎となるコンテナーホストバージョンに関係なく、RHEL 8 コンテナーイメージをサポートするために適切な ELS サブスクリプションが必要です。
   2. アプリケーションが非特権コンテナーとして実行されている。--privileged, などを指定して特権付きコンテナーを実行すると、分離が軽減され、コンテナーとホストインターフェイス間の接続が緊密になるため、これらの設定ではサポートされません。
   3. アプリケーションまたはそのアプリケーションの RHEL 以外の依存関係は、カーネルバージョン固有のデータ構造 (ioctl、/proc、/sys、ルーティング、iptables、nftables、eBPF など) またはカーネルバージョン固有のモジュール (KVM、OVS、SystemTap など) と直接対話しない。ioctls および /proc へのアクセスのサポートは、非特権ユーザーが必要とする最も一般的なユースケースに制限されます。他の用途ではすべて、“完全互換” 設定である必要があります。
2. 次の条件を満たす場合には、以前のコンテナーホストで、それよりも新しいコンテナーイメージを実行する場合に、ビジネス的に妥当なサポートを受けることができます。
   1. 以前の ”ワークロード固有” のサポート条件がすべて 適用される。
   2. “完全互換” 設定で問題を再現でき、根本原因が同じであることを Support チームに示すことができる。
   3. ユーザーが責任を持ってコンテナーイメージ (アプリケーション) とコンテナーホストの互換性を検証する。
   4. ユーザーが、(strace または systemtap トレースを介して) コンテナーイメージ (アプリケーション) が syscall のみを必要とすること、およびすべての syscall 機能 (フラグ、オプション、およびパスを含む) が基になるコンテナーホストカーネルに存在することを提示する。

** ホストのバージョンがコンテナーイメージのバージョンよりも古い場合でも、一般的にデプロイされるワークロードの多くは機能しますが、起動時またはその後の実行時に失敗する可能性があります。時間の経過とともに、新しいコンテナーイメージのユーザー空間コンポーネントが適切に動作するには、新しいカーネル機能が必要になり、古いカーネルはこれらの要件を満たすことができなくなります。この組み合わせでは、ソフトウェアバージョンの不整合や、予定外のダウンタイムやデータ損失などの深刻な障害が発生するリスクが最も高くなります。 ユーザーは、“完全互換” 設定に移行する準備ができている必要があります。Red Hat は、アプリケーションの互換性テストを行いません。また、Red Hat のサポートは、ビジネス的に妥当な範囲で分析を支援しますが、互換性のない状況を解決するためのバグ修正は提供しません。