以下の内容はhttps://rheb.hatenablog.com/entry/OpenShift-Roadmap-2025-CY25Q4より取得しました。

OpenShift Roadmap 2025(CY25Q4) - OpenShiftが観る"次"の景色

ハッピークリスマス🎅🎉☃️
レッドハットで、OpenShift Solution Architectをしている北山です。
そしてクラウドネイティブな皆さん!!「安定したKubernetesクラスタ」をサンタさん🎅にお願いする時期がやってきましたね!!

私からは、OpenShift Advent Calendar最終日のクリスマスプレゼントとして、2026年のOpenShift運用を劇的に変える最新のロードマップアップデート「What's Next: OpenShift Roadmap Update (December 2025)」で紹介された内容から、注目機能をピックアップしてお届けしますっ☃️


ちなみにみなさんは、OpenShiftの最新バージョンをご存知でしょーか？
早いもので、バージョン番号もついに 4.20 という節目を迎えました🎉🎂✨️

これまでのOpenShiftは、コンテナもVMも動く統合アプリケーションプラットフォームを目指してきましたが、2025年のロードマップを見ると、その方向性がさらにエンタープライズ需要に応える機能開発がなされていることを感じますね。

さて、今回動画のなかで紹介された大きなテーマは、以下の5点です。

それでは早速、クリスマスの魔法をお届けしましょう。

1. OpenShift Virtualization: 仮想マシンの存在を忘れる魔法

BroadcomによるVMware社買収以降、レッドハット社にもOpenShift Virtualizationへの問い合わせが増えています。しかし、現場からは「VMwareで当たり前にできていたあの機能は使えるの？」という厳しいツッコミも頂いていました。
2025年のロードマップでは、そのラストワンマイルを埋めに行く機能紹介が盛りだくさんであり、その中から以下の2つを紹介します。

  • 1-1. Load Aware Descheduler
  • 1-2. Storage Class Live Migration

1-1. Load Aware Descheduler

Load Aware Descheduler(負荷検知型リバランシング)とは、従来のPod数やRequest値に基づくスケジューリングではなく、実際のノード負荷(CPUプレッシャーやPSI)を監視し、高負荷時に自動的にVMをライブマイグレーションしてクラスタ全体のバランスを最適化する機能です。
この機能は、KubernetesのDeschedulerとの統合を行って実現されます。

具体的な仕組みとして、LinuxカーネルのPSI(Pressure Stall Information)メトリクスを活用します。
単なるCPU使用率(%)ではなく、「リソース待ちでどれだけ処理が詰まっているか」という実効的な負荷を見てバランシングを判断します。例えば、CPU使用率が低くても、I/O待ちやメモリ競合でプロセスが停滞している状態を検知するような仕組みですね。
そして、Deschedulerがこの情報を元に、VMをライブマイグレーションで空きのあるノードへ逃します。

気になる実際の効果は、以下のブログでも実証されているのでご参照をっ。

分かりづらい話をしましたが、サンタさんに、世界中の全ての家の位置を事前に網羅した地図（EVPN/BGP）を渡し、重いソリを引くトナカイの疲労度（PSI）を検知して自動で休憩やルート変更をさせる（Descheduler）仕組みです。
とても難しい話ですね。はい。次に行きましょう。

Release Target: OpenShift 4.20

1-2. Storage Class Live Migration

Storage Class Live Migrationは、VMwareでもおなじみの「Storage vMotion」に相当する機能です。
この機能により、稼働中のVMを止めることなく仮想ディスク(PVC)を別のStorageClassやボリュームに移動できます。これによって、古いストレージの撤去や、HDDからNVMeへの階層移動が、無停止で可能です。
これでサンタさんも海外から荷物を運ばなくて移動できるわけです。

一つ注意としては、内部的にCSI(Container Storage Interface) Driverの機能をフル活用するため、ストレージバックエンド側の対応(スナップショットやクローン機能)が重要になってきます。
実務での利用を検討する場合は、OpenShift Virtualizationのストレージに関する考慮事項 1 を確認の上、適切なストレージの選択を行いましょう。

また、インストールに関しては、是非こちらの記事もお楽しみください!!
Virt 屋のひとりごと : VM とストレージの Live migration - 赤帽エンジニアブログ

https://cdn-ak.f.st-hatena.com/images/fotolife/u/ututaq/20241221/20241221111635.png

2. Core Platform: 柔軟にクラスタを管理する魔法

OpenShiftを普段から運用している方にとっては、しれっとインパクトの大きいことを言っていたのがこのセクション。
どのプラットフォーム上にOpenShiftを提供しているのかによって、インストールの細かな機能差異もアップデートされていましたねー。

Install Experiences

このセクションで紹介するのは、これまで多くの管理者を悩ませてきたバージョンアップ作業を簡素化する機能についてです。

  • 2-1. RHEL CoreOSの進化
  • 2-2. EUS Jumps Support

2-1. RHEL CoreOSの進化

OpenShiftの専用OSであるRHCOSは、次世代のハードウェア対応やアップグレードリスクの極小化に向けて、次の一歩を踏み出しました。いくつかの機能が混在して話されていたので、3つをピックアップします。

Dual OS Streams
これまでOpenShiftクラスタ内のノードOSはバージョンを統一するのが基本でしたが、RHCOS 9とRHCOS 10を同じクラスター内で実行することが可能になります。これによって、最新のRHEL 10で認定されたハードウェアを既存クラスタに順次導入したり、OSのメジャーバージョンアップに伴うリスクをノード単位で切り離して管理できるようになります。

コンフィデンシャル・コンピューティング対応
実行中のデータを保護するためのConfidential Nodesが計画されており、信頼実行環境(TEE:Trusted Execution Environment)上でのセキュアなOS実行をサポートします。これは後述のセキュリティのセクションで詳しく触れます。

Image Modeによるカスタマイズの効率化
RHCOSにImage Modeが導入されます。これによって、インストール時にCoreOSのカスタマイズ内容を直接インジェクトすることができ、デプロイ後の設定作業を大幅に削減できます。
Image Modeのキャッチアップについては、下記のWebセミナーがおすすめです!!

Red Hat Enterprise Linux 10 /Image mode ご紹介ウェビナー 〜OS 構築・デプロイ・管理をコンテナネイティブなワークフローで実現〜

2-2. EUS Jumps Support

クラスタ運用において、頻繁なアップデートは運用者の負担となります。
安定版(EUS: Extended Update Support)間の移行を極限までスムーズにする戦略が示されました。それが EUS Jumps Support です。

これまでのアップグレードは1バージョンずつ段階を踏む必要がありましたが、新しいEUS戦略では、OCPバージョンNからN+3へのアップグレードを、ワーカーノードの再起動わずか1回で完了させることを目指しています。
これにより、大幅なメンテナンスウィンドウの短縮と運用コストの削減が期待できます。

また、頻繁なアップデートを推奨するため、APIサーバーのエミュレーション機能が導入される予定です。これによって、アップデートを最終確定する前にマイナーバージョンのロールバックが可能になったり、途中のバージョンをスキップしたアップデートがより安全に行えるようになります。
なお、サンタさんにはEUS Jumps(年飛ばし)することなく、毎年来てもらいたいものですね。

3. Networking: 意識せずとも繋がる魔法

ネットワークでは、OpenShift Virtualizationのマイグレーションとして活躍するEVPNやBGPの活用についての話がありました。ハイブリッドクラウドやマルチデータセンター間でのネットワーク接続は、まさにサンタさんの最適ルート選びと同じくらい複雑な問題ですね。
ここでは動画を観るうえで前提となっているUDNについても、少しおさらいしておきましょう。

  • 3-1. Ethernet VPN(EVPN)
  • 3-2. User Defined Networks(UDN)

3-1. Ethernet VPN(EVPN)

これまでは、新しいデバイスを見つけるためにネットワーク全体に「誰かいますかー？」とパケットを投げまくる(フラッディング)必要がありました。
EVPNはBGPを使い、あらかじめ「どこに誰がいるか」という名簿(MAC/IP情報)を配布します。これによって、ARPなどの無駄な通信を劇的に減らし、ネットワークの帯域を有効活用できます。

しかし、これまでのEVPNの実現には、高価な物理スイッチ側で複雑な設定が必要でした。しかし、OpenShiftのOVN-Kubernetesを活用2することで、全てサーバー内部の仮想スイッチ(OVS)で完結できるようになりました。
- 物理スイッチの設定不要： 物理側はシンプルなIP転送さえできればOK。複雑な設定から解放されます。 - IPの重複も可能： テナントごとに全く同じIPアドレスを使っていても、ネットワークを完全に分離して管理できます。

EVPNがGAされることで、OpenShift Virtualizationで動く仮想マシンを別のクラスターへマイグレーションさせる際、IPアドレスを変えずに移動できます。また、vSphereなどの既存基盤とOpenShiftを、あたかも一つのネットワークのように透過的に接続できます。
さらに、User Defined Networks(UDN)と組み合わせれば、OVN-KubernetesがBGPスピーカーとして機能し、UDN内のIPプレフィックスをデータセンターのToR（Top of Rack）スイッチ等の物理ファブリックに直接広報します。これで開発者が自分で専用のL2/L3セグメントを作成できるようになることも考えられます。
まさに、Private Cloud実現の夢が広がる機能ですね。

Release Target: Middle Term

3-2. User Defined Networks(UDN)

Kubernetesの標準的なフラットなPodネットワークは、シンプルである反面、複雑なエンタープライズ要件や厳格なマルチテナンシーには不十分でした。OpenShift 4.18でGAとなったUDNは、クラスタ管理者がNamespace単位、あるいはPod単位で完全に分離されたネットワークトポロジーを定義できる機能です。

こちらの登壇資料がわかりやすいので、もうすこし詳しく知りたい場合はおすすめです。

UDNはOVN-Kubernetes CNIプラグインを拡張したもので、OpenShift 4.20でBGPとの統合やL2/L3セグメントの柔軟な作成が出来るようになりました。

  • Primary UDN: 従来のクラスタデフォルトネットワークを置き換えます。特定のNamespace内のPodは、作成された瞬間からカスタム定義されたネットワーク（例: 192.168.10.0/24）に接続され、デフォルトのPodネットワーク（10.128.0.0/14等）から隔離されます。
  • L2トポロジー: UDNはL2ネットワークを作成できます。これにより、同一UDN内のPodやVMは、あたかも同一のレイヤー2スイッチに接続されているかのように振る舞い、ブロードキャストやマルチキャスト通信が可能になります。
  • L3トポロジー: VRF(Virtual Routing and Forwarding)を用いたL3分離を提供し、テナント間のルーティング制御を柔軟に行います。

Release Target: OpenShift 4.18

4. Developer Experience: 開発に集中したいを叶える魔法

まだまだ続くよどこまでも。ということで次はOpenShift上での開発のお話です。
開発者の皆さんにとって、環境の準備やトラブルシューティングは、日々の開発工数を消費する手間のかかる作業ではないでしょうか。
開発者がKubernetesを意識しなくて済む領域へと踏み出すために、OpenShiftは Red Hat Developer Hub(RHDH) 3 を中心に開発者ポータルの機能を強化しています。RHDHはオープンソースのBackstage 4 をベースとした開発者ポータルであり、サンプルのGolden Pathや、他のRed Hat製品との連携を強化する製品です。

ここでは動画の中で触れられていた、Red Hat Developer Hubの機能から以下の2つをピックアップして紹介します。

  • 4-1. Default Dynamic Plug-ins
  • 4-2. Red Hat Developer Lightspeed for RHDH

4-1. Default Dynamic Plug-ins

Backstageでは、Plug-ins 5 という機構を使って、開発ポータルを拡張します。Plug-insを使うことで、CI/CDの連携やOpenAPIカタログ連携、Gitへの接続ができ、組織独自の開発ポータルが簡単に作成できます。
しかし、RHDHのベースとなっているオープンソースのBackstageでは、これまで新しいPlug-insを追加するたびに、システムのソースコードを書き換え、コンテナイメージを再ビルドする必要がありました。それを解決する仕組みが、Dynamic Plug-insです。
Dynamic Plug-insは、ConfigMapの変更だけでコンパイルなしにPlug-insの追加や削除ができます。今後のロードマップでは、このDynamic Plug-insがRHDHの標準実装になります。
また、RHDHのサブスクリプションの一部として、Red Hatは厳選されたコミュニティPlug-insを提供しています。これらのコミュニティプラグインは、Red HatによってDynamic Plug-insに対応しており、テクニカルプレビュー規約に基づいてサポートが提供されます。

これを活用することで、ビジネスの要望に合わせて即座に機能拡張が可能になり、プラットフォームの鮮度を常に最新に保つことができます。

Release Target: OpenShift 4.18

4-2. Red Hat Developer Lightspeed for RHDH

たとえRHDHを使い、開発ポータルが社内で利用できたとしても「このツールの使い方は？」「テストが失敗したけど原因がわからない…」と立ち止まる時間は意外と多いものです。その時間をもっと効率的な生産活動に変えるのが、生成AIを活用した仮想アシスタント Red Hat Developer Lightspeed for RHDH です。

簡単に言うと、RHDHの画面上に専用のAIコンシェルジュを呼べる製品です。よくある問い合わせ窓口ではあるのですが、開発時の手助けをしてくれます。

  • 自然言語で相談：「RHDHで新しいPlug-insを設定するにはどうすればいい？」と問いかけるだけで、ドキュメントに基づいた正確な回答をくれます。
  • トラブルを即解決：例えばCI/CDパイプラインでテストが失敗したとき、そのエラー内容を渡すと、文脈を理解して修正案を提案してくれます。
  • テスト作成もお任せ：アプリケーションのユニットテストの計画策定や、実装のヒントもAIが教えてくれます。

これまでドキュメントを読み漁っていた時間をコーディング時間に変えることで、組織全体のイノベーションを加速させます。

Release Target: OpenShift 4.18

5. Security: すべての攻撃を守り抜く魔法

サプライチェーン攻撃が年間742%増加6している現代、セキュリティは「後付け」では間に合わなくなりました。
サンタさんからのプレゼントを横取りされたり、中身を変えられたなんて事件も増加しています。しらんけど。
OpenShiftのセキュリティは、プラットフォームのあらゆるレイヤーを要塞化し、Zero Trust, Secure by Design を具現化することにあります。今回はその中でも、特にアプリケーションやワークロードの信頼のあり方を根本から変える2つの技術のアップデートを紹介します。

  • 5-1. Zero Trust Workload Identity Manager - SPIFFE/SPIRE
  • 5-2. Confidential Containers

5-1. Zero Trust Workload Identity Manager - SPIFFE/SPIRE

Zero Trust Workload Identity Manager(ZTWIM)は、オープンソースのSPIFFE/SPIREプロジェクトをベースとした製品です。
従来の静的なシークレット(パスワードやAPIキー)に頼らず、全てのワークロードに対して実行時に暗号化し、暗号学的に検証可能な短寿命のアイデンティティを自動で付与してくる機能です。

https://next.redhat.com/wp-content/uploads/2024/06/screenshot-980x439.png

SPIFFE (Secure Production Identity Framework for Everyone)
SPIFFEはセキュアなワークロード識別のためのプロトコルと仕様を定義します。

  • SPIFFE ID: ワークロードに割り当てられる一意のURI形式の識別子。
  • SVID (SPIFFE Verifiable Identity Document): SPIFFE IDを保持する暗号学的に検証可能なドキュメント。通常はX.509証明書またはJWTトークンの形式で実装されます。
  • Workload API: ワークロードが自身のSVIDを取得し、他のワークロードのSVIDを検証するためのAPI仕様。

SPIRE (SPIFFE Runtime Environment)
SPIREはSPIFFE標準の「本番環境向けリファレンス実装」であり、実際のIDの発行、管理、ローテーションを行います。SPIREは主に以下の2つのコンポーネントで構成されます。

  • SPIRE Server: トラストドメイン（信頼境界）内のIDの署名局（認証局）として機能します。またワークロードの登録情報と、IDを発行するための条件（セレクター）を管理します。
  • SPIRE Agent: 各ノード（ホストマシン、VM）上で実行されます。ノードおよびワークロードの「アテステーション（実証・認証）」を行い、サーバーと連携してSVIDを安全に発行します。そしてWorkload APIをローカルで公開し、ワークロードにSVIDを提供します。

これらの機能によって、たとえネットワーク内に侵入されたとしても、正当なアイデンティティを持たないワークロードは一切の通信ができない、真のゼロトラスト環境が実現します。
今後ZTWIMはService MeshやOpenShift Virtualizationと統合され、コンテナだけでなくVMに対しても一貫したID基盤を提供するようになることが紹介されていました。また将来的には、AIエージェント間のセキュアな通信やエッジ環境、サプライチェーン全体の信頼性を保証する仕組みへと拡張される予定です。

Release Target: OpenShift 4.20

5-2. Confidential Containers

これまでのセキュリティ対策は「保存してあるデータ」と「転送中のデータ」の保護が中心でした。しかし、データがメモリ上で処理されている間は、特権ユーザーやホストOSから中身が見えてしまうという課題残っていました。まぁー。この世の中、サンタさん自身がプレゼントを変えちゃうってこともあるわけですよ。
この実行中のデータ保護を実現する技術の総称が、コンフィデンシャル・コンピューティング であり、それをコンテナで実現する一要素がConfidential Containers です。
Confidential Containersは、ハードウェアベースのセキュリティ機能を利用して、実行中のワークロードを周囲から完全に隔離し、秘密を保護します。
アーキテクチャの概要は以下の通りです。

1. Podごとに専用の「安全な箱(VM)」を作る
Confidential Containersは、Kata Containersという技術をベースにしています。通常のコンテナはホストOS上で直接動きますが、Condidential ContainersではPodごとに専用のConfidential VM（機密仮想マシン）を立ち上げ、その中でコンテナを実行します。

https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fi9l6ko3h8c764592vuo3.png

これの実装には、Intel TDXやAMD SEV-SNPといった特殊なCPUの機能を利用しながらメモリをハードウェアレベルで暗号化し、その中でコンテナを動かします。この技術によりクラウド事業者やKubernetesの管理者のような特権ユーザーであっても、この「安全な箱」の中身を覗いたり、書き換えたりすることはできません。

2. 正しさを確認する(リモートアテステーション)
VMを起動しただけでは、その中身が本当に安全な設定で動いているか確信が持てません。そこで、リモートアテステーション（構成証明）という確認プロセスが自動で行われます。
VM内のAttestation Agent (AA)が、ハードウェアの状態やOSの構成などのEvidenceを収集し、それを信頼できる場所に置かれたTrustee（トラスティ）と呼ばれる検証サービスへ送信します。
そして、検証が成功(環境が改ざんされていないと証明)された場合にのみ、暗号化されたコンテナイメージを解凍するための秘密情報がVMに送られます。

従来の仕組みでは、コンテナイメージを解凍するのはホストOS(クラウド側)の役割でしたが、Confidential Containerでは「安全な箱（VM）」の中でイメージの取得と解凍を行います。これによって、コンテナに含まれる独自のアルゴリズムや機密データが、実行前の段階で外部に漏れるのを防ぎます。
今回の動画では、このConfidential ContainersがARO (Azure Red Hat OpenShift) やベアメタル、さらにはNVIDIA GPU搭載環境においても、Confidential Containersの対応がGAおよびテックプレビューとして進められていることが紹介されました。この技術により、パブリッククラウドや共有インフラの上であっても、誰からも覗き見ることができない「安全な箱」の中で、機密性の高い処理を安心して実行できるようになります。

まとめ

いかがだったでしょうか？相変わらず情報盛りだくさんのUpdateで、何がなんだか。。。と感じた方もいらっしゃるかもですが、ご安心を！
全部詳細まで把握できている人などいませんw

オープンソースが進化していくたびに、OpenShiftも成長を続け、新たな発見があります。
なにか1つでもみなさんの興味のある機能が見つかったのであれば、是非コメントを添えてシェアお待ちしていますー。
2026年は、OpenShiftにとっても新たな幕開けにしていくので是非お楽しみをっ！

オープンソースのチカラで世の中を少しでも変えてみたい。と思った方は、年末年始に是非レッドハットのポジションも検討してみてください~。

それでは良いお年を!!

Bye for now.

  1. OpenShift Virtualization のストレージに関する考慮事項 - https://developers.redhat.com/articles/2025/07/10/storage-considerations-openshift-virtualization↩
  2. A native way of integrating OVN into the fabric through BGP EVPN - https://www.youtube.com/watch?v=KE-CF8bD1CU↩
  3. Getting started with the Red Hat Developer Hub - https://www.youtube.com/watch?v=tvVOC0mFR_4↩
  4. Spotifyがオープンソース化した、開発ポータル - https://backstage.io/↩
  5. Backstage Plugin directory - https://backstage.io/Plug-ins/↩
  6. State of the Software Supply Chain - https://www.sonatype.com/state-of-the-software-supply-chain/introduction↩


以上の内容はhttps://rheb.hatenablog.com/entry/OpenShift-Roadmap-2025-CY25Q4より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14