Red Hat OpenShift 4.20 が仮想化とエンタープライズ AI のイノベーションを加速化

Red Hat OpenShift 4.20 の一般提供が開始されました。これは Kubernetes 1.33 と CRI-O 1.33 をベースとしており、Red Hat OpenShift Platform Plus と同様、このリリースは 信頼できる包括的で一貫性のあるアプリケーション・プラットフォームを提供するという当社の取り組みを示すものです。OpenShift 上では AI ワークロード、コンテナ、仮想化がシームレスに共存するため、企業はセキュリティを損なうことなく、ハイブリッドクラウドで迅速にイノベーションを推進できます。

OpenShift は、セルフマネージドまたはフルマネージドのクラウドサービス・エディションで利用でき、クラウドネイティブ、AI、仮想、従来のワークロードに対応する、包括的な統合ツールとサービスを備えたアプリケーション・プラットフォームを提供します。この記事では、OpenShift 4.20 の最新のイノベーションと主要な機能強化について紹介します。更新と改善の包括的なリストについては、OpenShift 4.20 リリースノートを参照してください。

この最新リリースでは、LeaderWorkerSet、Gateway API 推論拡張、ランタイム Open Container Initiative (OCI) イメージ・ボリュームソースの一般提供により、AI ワークロード向けのプラットフォームの機能を向上させます。また、コア機能を強化し、独自の (bring-your-own) の外部 ID プロバイダー、Zero Trust Workload Identity Manager、ユーザー名前空間、External Secrets Operator for Red Hat OpenShift、Border Gateway Protocol (BGP) サポートなどの重要な改善を導入しています。さらに OpenShift 4.20 では、CPU 負荷認識による再バランス調整やより迅速なライブマイグレーションなど、仮想化における重要な拡張機能を提供し、多様なコンピューティング・ニーズに対応する堅牢で汎用性の高いプラットフォームを提供します。

OpenShift 4.20 では、ポスト量子暗号化 (PQC) のサポート追加に関する取り組みの一環として、Go 1.24 リリース で X25519MLKEM768 ハイブリッド鍵交換メカニズムが有効になりました。これは、API サーバー、kubelet、スケジューラー、コントローラー・マネージャーなど、Kubernetes コントロールプレーンのコア・コンポーネント間の TLS 通信を強化し、量子ベースの攻撃からの保護に役立ちます。

Red Hat の最新リリースである Trusted Artifact Signer 1.3 と Trusted Profile Analyzer 2.2 は、暗号署名機能と高度なサプライチェーン分析という強力な組み合わせを提供します。

LeaderWorkerSet と JobSet を使用して AI/ML ワークロードを分散および拡張する

OpenShift 4.20 は、複雑な分散 AI ワークロードのデプロイを単純化します。一般に提供されている LeaderWorkerSet により、プラットフォームチームは、リーダー Pod を使用してワーカー Pod 間で通信をシームレスにオーケストレーションすることで、単一 Pod の容量を超える AI モデルを効率的に分散し、スケーリングできます。テクノロジープレビュー として利用可能な、柔軟なスケジューリングとフォールトトレランスで分散ジョブをグループ化して管理する JobSet と組み合わせることで、チームは馴染みのある GitOps、ロールベースのアクセス制御 (RBAC)、極めて要求の厳しい機械学習ワークフローの監視パターンを活用できます。これらを組み合わせることで、トレーニング (JobSet) と推論 (LeaderWorkerSet) の両方のワークロードを大規模にエンドツーエンドでオーケストレーションし、OpenShift 内で堅牢で拡張性があり、かつ効率的な AI/ML ライフサイクル管理が可能bになります。

Red Hat OpenShift AI 3 によるネイティブ AI ルーティング

AI と機械学習のワークロードには独自の課題があり、ラウンドロビンのような従来の負荷分散の戦略では対応できません。 Red Hat OpenShift AI 3 は、Kubernetes Gateway API Inference Extensions (GIE) を活用して、llm-d による分散推論でこれらの課題に対処します。OpenShift 4.20 には GIE が含まれており、これは Kubernetes Gateway API をベースとして構築し、AI/ML ワークロード向けの特殊なルーティングおよびトラフィック管理を提供します。アプリケーションに Kubernetes Gateway API を使用している場合は、同じ宣言型のアプローチを AI モデルの提供に適用できます。

InferencePool リソースを作成すると、GIE を OpenShift 4.20 で自動的に利用できます。InferencePool リソースは、一連の AI または機械学習推論 Pod と、特殊なルーティングロジックを含む「エンドポイントセレクター」を表します。Red Hat OpenShift AI 3 の一部である llm-d 推論スケジューラーは、モデルサーバープロトコルを使用して vLLM によって公開されるテレメトリーデータをキャプチャすることでエンドポイント選択ツールとして機能し、利用可能な最良のモデルインスタンスに基づいて、いつでもスマートなルーティングの決定ができるようにします。

GIE は、OpenShift Service Mesh 3.2 を介して Envoy プロキシによってサポートされる Istio のゲートウェイ実装を使用します。これは、現時点で Red Hat OpenShift AI 3 でのみサポートされています。GIE を使用すると、AI ワークロードは、同じ GitOps パイプラインと RBAC ポリシーを使用して 管理できます。単一モデルを提供する場合でも、複雑なマルチモデル推論パイプラインをオーケストレーションする場合でも、GIE は特殊な AI インフラストラクチャであったものを、クラスタ内の 1 つのルートに変えることができます。

Pod に影響を与えずに AI モデルを更新する

LLM と ML モデルはサイズが 10GB を超えることが多いため、コンテナの再ビルドに時間がかかり、ストレージを大量に消費します。しかし、AI モデルがアップデートするたびにコンテナを再ビルドする必要はなくなりました。OpenShift 4.20 では、モデルの重みをコンテナレジストリーから直接ボリュームとしてマウントできるため、データサイエンティストはモデル提供コンテナは変更せずに、新しいモデルのバージョンをレジストリーにプッシュできます。Pod 仕様の OCI イメージを参照するだけで、OpenShift が残りを処理します。モデルはコードから切り離されたバージョン管理可能なアーティファクトになり、使い慣れたレジストリの認証を使用してオンデマンドでプルされ、パフォーマンス強化のためにローカルにキャッシュされ、デプロイメントに影響を与えることなく更新できるようになりました。

OpenShift または Kubernetes クラスタとの自然言語を使用したチャット

OpenShift と Kubernetes 向けの Kubernetes Model Context Protocol (MCP) サーバーの開発者プレビューを発表できることを嬉しく思います。Kubernetes MCP サーバーは、VS Code、Microsoft Copilot、Cursor などの AI アシスタントを OpenShift および Kubernetes 環境とブリッジすることで、インフラストラクチャ管理に革命をもたらすでしょう。包括的な CRUD 運用、高度な Pod 管理、Helm 統合、クロスプラットフォーム・デプロイメント機能を備えた Kubernetes MCP サーバーは、自然言語クエリを使用してクラスタ管理とトラブルシューティングを変革します。

さらに、MCP を使用して OpenShift Lightspeed にインシデント検出機能を統合しました。これにより、インシデント分析を会話型インタフェースに直接組み込むことができるため、クラスタの問題を調査し、解決する方法が変わります。

NVIDIA Bluefield DPU で AI ワークロードを高速化する

テクノロジープレビューとして利用可能な Red Hat OpenShift と NVIDIA Bluefield DPU の組み合わせは、AI、通信、エンタープライズ用ワークロード向けのセキュリティ、ルーティング、ストレージソリューションをデプロイするための最適化されたアプローチを提供します。このソリューションはインフラストラクチャおよびアプリケーション・ワークロードのハードウェアアクセラレーションとセキュリティの分離を重視し、リソース使用率を向上させ、サーバー容量を最大化します。 Bluefield データ処理ユニット (DPU) は、NVIDIA の Spectrum-X および AI ファクトリーの設計に不可欠な要素であり、今後の OpenShift リリースでは、NVIDIA の Spectrum-X ソリューションおよび AI ファクトリーの設計のシームレスなデプロイとオーケストレーションが有効にされる予定です。

ネイティブ OIDC サポートで ID 管理を最適化する

OpenShift 4.20 では、外部 OpenID Connect (OIDC) アイデンティティープロバイダーと直接統合して認証用のトークンを発行できるようになり、認証システムをより詳細に制御できるようになりました。 外部の OIDC プロバイダーと直接統合することで、ビルトイン OAuth サーバーの機能に制限されるのではなく、優先する OIDC プロバイダーの高度な機能を活用できます。組織は、単一のインタフェースからユーザーとグループを管理し、複数のクラスタ間やハイブリッド環境での認証を最適化できます。

OpenShift 上の Zero Trust でワークロード ID を管理する

Zero Trust Workload Identity Manager の一般提供は、今後数週間以内に OpenShift 4.20 で開始される予定です。Zero Trust Workload Identity Manager は、すべてのワークロードに対して、ランタイム認証済みで暗号的に検証可能な ID を提供します。SPIFFE/SPIRE 上に構築された Zero Trust Workload Identity Manager は、ワークロードの自動登録、ハイブリッドおよびマルチクラウド環境全体でユニバーサルな信頼を実現する SPIRE と SPIRE のフェデレーション、既存のエンタープライズ ID システムとの統合を可能にする OIDC フェデレーション、および Hashicorp Vault 統合によるシークレットレス認証などのコア機能を提供します。

Zero Trust Workload Identity Manager は、ユニバーサルな信頼を確立し、静的シークレットを排除して、セキュリティを重視したワークロード間の通信のための短期的で検証可能な ID を有効にします。従来型のサービスから先進的なエージェント型 AI システムまで、すべてのクラウドネイティブなワークロードに対して一貫性のあるランタイム認証済みの ID を提供し、すべてのワークロードのアクションに対するアカウンタビリティとトレーサビリティを確保して、アプリケーション環境全体にわたるゼロトラスト・アーキテクチャの基盤を形成します。Zero Trust Workload Identity Manager を使用するには、OpenShift Platform Plus、Red Hat Advanced Cluster Security for Kubernetes、または Red Hat Advanced Cluster Management のサブスクリプションが必要であり、複数のクラスタで使用する場合にはクラウド間で使用できるワークロード ID 管理を有効にします。 

External Secrets Operator でシークレット管理を最適化する

OpenShift 4.20 では、External Secrets Operator for Red Hat OpenShift (ESO) が利用可能になりました。ESO は、外部のシークレット管理システムから取得した シークレットのライフサイクル管理を提供するクラスター全体のサービスです。AWS Secrets Manager、HashiCorp Vault、Azure Key Vault などの外部のシークレット管理システムと統合することにより、ESO はクラスタ内でシークレットの取得、更新、プロビジョニングを実行し、アプリケーションの直接の関与なしに、機密性の高いシークレットがより安全かつ効率的にワークロードに送られるようにします。

ユーザー名前空間でコンテナの特権昇格リスクを排除する

OpenShift 4.20 でユーザー名前空間の一般提供を開始したことで、Red Hat は開発者が先進的なアプリケーションの構築に必要な柔軟性を維持しながら、ワークロードの分離を強化した状態でワークロードを実行できるようになります。 OpenShift の ユーザー名前空間 は、コンテナユーザーをホストユーザーから分離し、特権昇格攻撃のリスクを軽減し、操作上、内部 root 権限を維持しながらコンテナをホスト上で非 root ユーザーとして実行できるようにすることで、セキュリティを大幅に強化します。これにより、マルチテナント環境の安全性を向上させ、エンタープライズ・セキュリティ標準へのコンプライアンスを強化します。

Istio のアンビエントモードで可能な、サイドカーなしでのサービスメッシュの利用

OpenShift Service Mesh 3.2 では、Istio のアンビエントモードによる、サイドカーなしでサービスメッシュを使用するためのサポートが利用可能です。これは Istio 用のまったく新しいデータプレーンであり、2 つのレベルのプロキシを使用して、追加のリソース使用を最小限に抑えながら、必要に応じてサービスメッシュ機能を有効にします。 

1 つ目のプロキシは、レイヤ 4 の相互 TLS 暗号化、テレメトリー、および基本的な認証ポリシーを提供するノードレベルの ztunnel (「ゼロトラストの Z」) です。これはノードプロキシですが、各 Pod 固有のネットワーク namespace からトラフィックをリダイレクトし、トラフィックを Pod レベルで分離し、暗号化します。次のプロキシはアプリケーション指向のウェイポイントで、必要に応じてデプロイしてレイヤ 7 のメッシュ機能 (テレメトリーや、HTTP 要求タイプやヘッダーなどのアプリケーション仕様に基づくポリシーなど) を提供します。 

このアーキテクチャにより、とりわけ Pod 間の mTLS 暗号化などの ztunnel プロキシのみを必要とする機能において、サービスメッシュの実行に使用されるリソースコストを大幅に削減できます。詳細については、OpenShift サービスメッシュ 3 を使用したトラフィックと可観測性の最適化について参照してください。 

OpenShift Networking のネイティブ BGP サポート

Red Hat OpenShift Networking では、デフォルトのネットワークプラグインである OVN-Kubernetes 内で、ネイティブな Border Gateway Protocol (BGP)ルーティング機能を提供します。この機能強化により、これまで MetalLB (外部サービス負荷分散) と Cluster Network Operator (レイヤ 3 ネットワークファブリック、マルチホーミング、リンクの冗長性、高速コンバージェンス) でサポートされていたネットワークのユースケースを大幅に拡張します。 

OpenShift 4.20 以降の BGP では、クラスタースコープの Pod や仮想マシン (VM) ネットワークを、外部ネットワークの BGP ルーターを介して BGP 対応プロバイダーネットワークに直接アドバタイズできます。また、BGP で学習したルートをプロバイダーネットワークから OVN-Kubernetes にインポートして、デフォルトの Pod ネットワークまたは指定のユーザー定義ネットワーク (UDN) にインポートすることができます。この双方向の統合により、OpenShift と外部ネットワークファブリック間でシームレスなルート交換を可能にします。サポートはベアメタル・プラットフォーム向けにまず提供されますが、クラウド・プラットフォームのサポートは次のリリース以降に予定されています。

スケーラビリティを向上させるために、必要に応じてクラスターと外部ネットワークの間にルートリフレクターをデプロイできます。BGP ベースのルートアドバタイズの動的な性質とメリットを示す一般的な例は、VM の移行またはフェイルオーバーイベントです。VM が別のノードに移動する際、VM は静的 IP アドレスを保持し、BGP テーブルがその VM のネットワークのアドバタイズされたルートを自動的かつ迅速に更新するため、中断を最小限に抑えて継続的な接続を確保します。

クラスタを更新する前に問題を発見する

OpenShift 4.20 では、2 つの新しいコマンドによって、更新前および更新中の更新に関連する潜在的な問題の可視性をユーザーに提供されます。oc adm upgrade recommend と oc adm upgrade status コマンドの両方が使用可能になりました。 

更新の開始前に、oc adm upgrade recommend は既知のアラートについてクラスターを分析します。これにより、制限された PodDisruptionBudget や、使用できない Cluster Operator、ノードのドレインを低下させる可能性のあるアラートなど、問題の原因となるアラートが表示されます。更新チャネルで利用可能なバージョンや、それらのリリースの既知の問題、さらに重要な点として、通常のクラスターの動作と比較してどの状態が実際に問題となるかを確認できます。 

$ oc adm upgrade recommend
Failing=True:
Reason: ClusterOperatorNotAvailable
Message: Cluster operator monitoring is not available
The following conditions found no cause for concern in updating this cluster to later releases: recommended/NodeAlerts (AsExpected), recommended/PodImagePullAlerts (AsExpected)
The following conditions found cause for concern in updating this cluster to later releases: recommended/PodDisruptionBudgetAlerts/PodDisruptionBudgetAtLimit/1
recommended/PodDisruptionBudgetAlerts/PodDisruptionBudgetAtLimit/1=False:
Reason: Alert: firing
Message: warning alert PodDisruptionBudgetAtLimit firing, which might slow node drains. Namespace=openshift-monitoring, PodDisruptionBudget-prometheus-k8s. The pod disruption budget is preventing further disruption to pods. The alert description is: The pod disruption budget is at the minimum disruptions allowed level. The number of current healthy pods is equal to the desired healthy pods.
https://github.com/openshift/runbooks/blob/master/alerts/cluster-kube-controller-manager-operator/PodDisruptionBudgetAtLimit.md
Upstream update service: https://api.integration.openshift.com/api/upgrades_info/graph
Channel: candidate-4.18 (available channels: candidate-4.18, candidate-4.19, candidate-4.18, eus-4.18, fast-4.18, fast-4.19, stable-4.18, stable-4.19)
Updates to 4.18:
VERSION    ISSUES
4.18.32    no known issues relevant to this cluster
4.18.30    no known issues relevant to this cluster
And 2 older 4.18 updates you can see with '--show-outdated-releases' or '--version VERSION'.

更新後は、oc adm upgrade status により、コントロールプレーンとワーカーノードの進行状況、完了率、見積もり時間、および問題が発生した場合は警告がリアルタイムで表示されます。どちらのコマンドも読み取り専用であり、OpenShift クラスター内は何も変更されません。詳細については、CLI を使用したクラスタの更新について参照してください。

2 ノードの OpenShift でエッジデプロイメントを最適化する

Two-Node OpenShift with Arbiter でエッジデプロイメントを最適化できます。これにより、標準的な 3 ノードの OpenShift クラスタと同じ高可用性の特性を活用でき、2 台のフルサイズのサーバーが必要となるのみで、クォーラム用の軽量の Arbiter ノードがこれを補完します。 

Arbiter ノードは、2 つの vCPU と 8 GB のメモリーのみを使用して、クォーラム用の 3 つ目の etcd インスタンスとして実行されます。2 台のフルサイズのノードが実際のワークロードすべてを処理する一方で、小型の Arbiter がクラスターの可用性を損なうことなく単一ノードの障害を許容できるようにします。必要なのはベアメタルサブスクリプションが 2 つだけであり、Arbiter ノードはライセンス費用に計上されません。詳細は、Red Hat OpenShift および Portworx/Pure Storage で提供される効率的な 2 ノードのエッジインフラストラクチャについてご覧ください。

Red Hat OpenShift Virtualization 4.20 の負荷認識型の再バランス機能と高速な VM 移行

Red Hat OpenShift Virtualization 4.20 の CPU の負荷に基づく負荷認識の再バランス調整機能も利用可能になりました。これにより、ノードのリアルタイムのリソース使用率を動的に考慮され、過剰に使用されているノードから容量のあるノードに VM を移行されるため、クラスタノード間のワークロード分散が改善されます。

また、OpenShift Virtualization は、マルチクラスタ機能による単純化された VM 管理、主要ストレージベンダー・ソリューションからのストレージオフロード機能を備えた仮想化移行ツールキットによる OpenShift への移行速度の向上、特定のノードへのライブマイグレーション、および 拡張された Arm サポートを導入しています。ネットワークの改善 (L2 ユーザー定義ネットワーク向けの BGP など) により、仮想化ワークロードの効率と柔軟性がさらに向上します。

Oracle Cloud Infrastructure で仮想化ワークロードをスケーリングする

現在、Oracle Cloud Infrastructure のベアメタルインスタンスで OpenShift Virtualization を使用できます。これにより、両社のお客様には、OCI の分散クラウドを介してあらゆる場所から VM ワークロードを実行できる柔軟性が提供されます。詳細は、Unlocking Virtualization at Scale on OCI を参照してください。

OpenShift を Oracle のソブリンクラウドに拡張する

最後に重要な点をお知らせします。OpenShift は Oracle Cloud Infrastructure のサポートを拡張しており、とりわけ Oracle EU Sovereign Cloud、Oracle US Government Cloud、Oracle Cloud for UK Government & Defence、Oracle Cloud Isolated Regions、Oracle Alloy などのソブリンクラウドに重点を置いています。この機能強化により、組織は、データ主権、規制へのコンプライアンス、特殊なクラウド環境内でのセキュリティ強化に関する重要なニーズに対応するクラウドに OpenShift をデプロイする上で、より高い柔軟性と選択肢を得ることができます。詳細については、Expanded Oracle Cloud Infrastructure Support を参照してください。

Red Hat OpenShift 4.20 を今すぐ試す

Red Hat Hybrid Cloud Console の使用を今すぐ開始して、OpenShift の最新機能と拡張機能を活用してください。今後の予定については、以下のリソースをご覧ください。

• What’s New and What’s Next in Red Hat OpenShift
• What’s New in Red Hat OpenShift 4.20
• 新しい OpenShift 4.20 の インタラクティブデモ を試す
• In the Clouds
• OpenShift YouTube Channel
• OpenShift Blogs
• OpenShift Commons
• Red Hat Developer Blogs
• Red Hat Portfolio Architecture Center
• Validated Patterns

Red Hat OpenShift 4.20 のアップデートの詳細リストは、OpenShift 4.20 リリースノートで確認できます。Red Hat の担当者を通じてフィードバックをお寄せいただくか、GitHub で問題を作成してください。