OpenShift Service Mesh 3.1 の紹介

Red Hat OpenShift Service Mesh 3.1 がリリースされ、Red Hat OpenShift Container Platform および Red Hat OpenShift Platform Plus に組み込まれました。Istio、Envoy、Kiali の各プロジェクトをベースとするこのリリースでは、Istio のバージョンが 1.26 に更新され、Kiali が 2.11 に更新されています。また、このリリースは OpenShift Container Platform 4.16 以降でサポートされます。

これは、Red Hat OpenShift Service Mesh 3.0 以降の最初のマイナーリリースです。 このメジャーアップデートでは、OpenShift Service Mesh をコミュニティ版の Istio プロジェクトと統合し、 Sail operator を使用したインストールと管理が可能になります。この変更により、OpenShift Service Mesh は、Red Hat がサポートする最新の安定した Istio 機能を提供できるようになります。

OpenShift Service Mesh 3.1 へのアップグレード

OpenShift Service Mesh 2.6 以前のリリースを実行している場合は、3.1 にアップグレードする前に OpenShift Service Mesh 3.0 にアップグレードする必要があります。バージョン 2.6 は 2026 年 3 月 12 日にサポート終了を迎えるため、OpenShift Service Mesh 3.0 に速やかに移行することをお勧めします。詳細な移行ガイドは、OpenShift Service Mesh 3.0 のドキュメントをご覧ください。このドキュメントには、 OpenShift Service Mesh 2.6 と 3.0 の違いの分析についての記載もあります。  

また、Kiali コンソールを使用して OpenShift Service Mesh 2.6 と 3.0 間で移行する方法を記載した記事も最近公開しています。

詳細に設定されたメトリクスと Kiali コンソールを使用した OpenShift Service Mesh 3.0 の例については、こちらの ソリューションのパターンを参照してください。

OCP 4.19 以降での Kubernetes Gateway API のサポート

Kubernetes Gateway API は、次世代の Kubernetes Ingress、ロードバランサー、およびサービスメッシュ API です。Istio では、これをサービスメッシュを使用してトラフィックを作成し、管理するためのデフォルトの API セットにする予定であり、Kubernetes Gateway API は Istio のアンビエントモードを使用するために必要です。VirtualService や DestinationRule などの安定した Istio API を削除する予定はないことにご留意ください。Kubernetes Gateway API にまだ追加されていない機能を利用するために、これらの API を使用する必要が生じることもあります。

OpenShift Service Mesh 3.0 には Kubernetes Gateway API が含まれていましたが、その機能を利用するには、サポートされていないカスタムリソース定義 (CRD) をインストールする必要がありました。これは OpenShift Container Platform 4.19 以降では不要となり、必要な CRD が OpenShift でデフォルトで利用できるようになりました。今後、これらの CRD は個別にインストールする必要はなくなります。OpenShift に含まれる Gateway API CRD は、Red Hat によって完全にサポートされています。

生成 AI のワークロードとトラフィックパターンに対する最適化されたサポートを提供するため、OpenShift Service Mesh 3.1 にこの機能をバックポートすることで、Gateway API Inference Extension のテクノロジープレビューを追加しました。

x86 クラスタ向けのデュアルスタックサポート (一般提供)

このリリースにより、x86 ハードウェアを実行している OpenShift クラスタにおいて、OpenShift Service Mesh でのデュアルスタック IPv4 および IPv6 ワークロードのサポートが一般に利用可能になります。OpenShift Service Mesh でデュアルスタックサポートを有効にするには、Istio カスタマーリソースで ISTIO_DUAL_STACK フラグを true に設定する必要があります。これについては、アップストリームの デュアルスタックに関する sail-operator のドキュメントや、コミュニティ版 Istio デュアルスタックのドキュメントで説明されており、OpenShift Service Mesh の製品ドキュメントでも記載される予定です。

UBI Micro コンテナへの移行

このリリースでは、主要な istiod やプロキシ (Enovy) コンテナなど、ほとんどのコンテナを移行し、UBI Micro ベースイメージ を使用することができます。UBI Micro は、Red Hat Enterprise Linux の最小の Universal Base Image (UBI) イメージです。通常はコンテナーイメージに含まれるパッケージマネージャーとすべての依存関係が除外されています。UBI Micro を導入することで、OpenShift Service Mesh の一部として提供されるコンテナーイメージの攻撃対象領域を最小限に抑えることができます。

サイドカーレスのサービスメッシュに向けて：Istio のアンビエントモード

OpenShift Service Mesh 3.1 は Istio 1.26 をベースとしており、Istio 1.24 をベースとした OpenShift Service Mesh 3.0 と比較すると、主に段階的なアップデートが含まれています。これは、Istio コミュニティと Red Hat が、次世代のサービスメッシュデータプレーン、つまり Istio のアンビエントモードを非常に重視しているためです。

過去数年間において、サービスメッシュの使用は着実に増大しましたが、各アプリケーション・コンテナに加えてサイドカーコンテナを実行するためには余分なリソース (主にメモリと CPU) が必要になるため、サイドカープロキシの必要性がしばしば導入の妨げになってきました。サイドカープロキシは Pod のライフサイクルの一部として追加し、更新する必要があるため、サービスメッシュの導入を複雑なものにしてきました。つまり、サービスメッシュの更新を導入するには、アプリケーションを再起動する必要があります。

Istio のアンビエントモードは、サイドカープロキシの必要性を排除し、Istio データプレーンを 2 つの独立したレイヤーに分割することで、これらの問題に対応します。これにより、サービスメッシュ機能を段階的に導入することが可能となり、アプリケーションの所有者にとって複雑性が軽減されます。

この分割アーキテクチャにより、サービスメッシュを有効にするためにデプロイされるプロキシの数が大幅に減少し、サービスメッシュの実行に必要なリソースが大幅に削減されます。Istio のアンビエントモードではサイドカープロキシを必要としないため、アプリケーション Pod を変更したり再起動したりすることなく、アプリケーションをメッシュに追加したり、削除したりできます。

Istio のアンビエントモードは次の 2 つのレイヤーに分かれています。

• Ztunnel：軽量のレイヤー 4 ノードレベルプロキシ (Kubernetes で Daemonset として実行) は、アプリケーション Pod のネットワーク namespace 内にリッスンするソケットを作成し、mTLS 暗号化を使用して Pod レベルのトラフィックを透過的にアップグレードします。Ztunnel は、ノード上の Pod の証明書と ID の管理も行います (ノード上の Pod のみを対象)。Ztunnel のみで、自動 mTLS 暗号化や、レイヤー 4 のテレメトリーおよびポリシー管理を達成できます。
• Waypoint： ゲートウェイに類似したオプションの Envoy プロキシ。(デフォルトでは namespace でスコープされた) 一連のアプリケーションに対してデプロイされ、アプリケーションレベルのセキュリティーやトラフィックポリシー、アプリケーションレベルのテレメトリー、およびメッシュの耐障害性機能などのレイヤー 7 のメッシュ機能を提供します。サイドカーとは異なり、Waypoint プロキシは必要に応じて追加したり、アプリケーションコンテナとは別にスケーリングしたりできます。

Istio アンビエントモードのアーキテクチャとトレードオフの詳細については、Red Hat OpenShift で Istio アンビエントモードの試行についてご覧ください。

OpenShift Service Mesh 3.1 では、Istio のアンビエントモードのステータスがテクノロジープレビューに更新されました。Red Hat が完全にサポートする Ztunnel プロキシは、暗号化に OpenSSL を使用し、FIPS に準拠するようになっています。 OpenShift Service Mesh 3.1 には、インストールガイドの一部として、OpenShift で Istio のアンビエントモードを使用するためのドキュメントが含まれています。更新内容は、一般公開に向けて今後数カ月でさらに強化される予定です。

Istio のアンビエントモードでは Kubernetes Gateway API が必要なため、サポートされている Gateway API CRD がデフォルトでインストールされている OpenShift Container Platform 4.19 以降で使用してください。これよりも前のリリースの OpenShift で Istio のアンビエントモードを試すことを希望される場合は、コミュニティ版 Istio のドキュメントに記載されているように、サポートされていない Kubernetes Gateway API CRD をインストールする必要があります。OCP 4.19 でサポートされている Kubernetes Gateway API CRD にアップグレードすると、ダウンタイムが発生する可能性があることに注意してください。

また、既存のサービスメッシュのデプロイメントとの干渉の可能性を減らすために、OpenShift Service Mesh がまだインストールされていないクラスタで Istio アンビエントモードを試すことをお勧めします。今後は、サイドカーモードのデータプレーン共にアンビエントモードのデータプレーンを実行する方法に関するドキュメントや、サイドカーモードからアンビエントモードにアプリケーションを移行する場合のガイダンスを提供する予定です。

Istio 1.26 の時点では、すべてのサイドカーモード機能はアンビエントモードでサポートされる訳ではなく、一部の機能はアップストリームの Istio で「Alpha」のままです。アンビエントモードは、すべてのサービスメッシュのユースケースに適しているとは限りません。複数のネットワーク、複数のクラスタのセットアップと、アンビエントモードとサイドカーモードのデータプレーンの相互運用性の今後の進展については、最も注目されています。これらの機能および追加の機能は、Istio コミュニティで開発中です。

Kiali の更新

Kiali は、OpenShift Service Mesh に含まれる Istio サービスメッシュのコンソールです。このリリースでは、多くの更新と機能強化 (Istio のアンビエントモードなど) が含まれる 2.11 に更新されます。

メッシュページの更新

メッシュページの機能は、Istio コントロールプレーン自体やデータプレーンのコンポーネント、Prometheus や Tempo などの可観測性アドオンを含む、Istio のインフラストラクチャのステータスを監視するための主要なダッシュボードとして、引き続き強化されます。このリリースには、Istio ゲートウェイや、アンビエントモードのデータプレーンのコンポーネント (Ztunnel と Waypoint) などを含む、複数のアップデートが含まれています。メッシュのページでは、コンポーネントを調べて、各コンポーネントに関連するメトリクスや設定ダンプなどの、主要なステータス情報を確認できます。

大規模メッシュによるパフォーマンスとスケーラビリティ

Kiali でよくある懸念事項は、サービスメッシュ内のワークロード数が増加するにつれてパフォーマンスが低下することです。これまで、Kiali では、非常に大規模なサービスメッシュでは応答性を維持するのが困難でした。Kiali プロジェクトの FAQ には、大規模なメッシュのデプロイメントで Kiali を使用するためのガイダンスが含まれる、パフォーマンスに関する新たなセクションが追加されました。このリリースには、大規模メッシュをより適切に管理するための更新を含む、パフォーマンスを向上させるための更新が含まれています。

たとえば、デフォルトで、Kiali はすぐにページのレンダリングを試み、Refresh Interval のドロップダウンの設定に基づいてほとんどのページを自動的に更新します。非常に大規模なメッシュの場合には、初期レンダリングでさえ遅くなり、コンソールの使用が遅れる可能性があります。現在、Kialiでは Manualの更新設定を提供しており、この設定では、Refresh ボタンを手動でクリックした場合のみページが更新されます。これは、Kiali カスタムリソース定義 (CRD) で spec.kiali_feature_flags.ui_defaults.refresh_interval: manual を指定して設定できます。 

大規模メッシュでのパフォーマンスと応答性を向上させるために、検証を無効にすることもできます。これは、Kiali Operator 設定の spec.external_services.istio.validation_reconcile_interval を 0 に設定して実行できます。

OpenShift Service Mesh の開始

OpenShift Service Mesh を初めて利用する場合は、OpenShift Service Mesh の概要および Day 1 のインストール手順を参照してください。詳細な動作の例については、OpenShift Service Mesh 3 を使用したトラフィックと可観測性の最適化のソリューションパターンを参照してください。

OpenShift Service Mesh 3.0 から移行する場合は、OpenShift Service Mesh 3 Operator、Istio コントロールプレーン、Istio CNI リソース、およびデータプレーンを構成するプロキシを更新するためのさまざまなアプローチについて、アップグレードドキュメントを確認してください。

OpenShift Service Mesh 2.6 以前から移行する場合は、OpenShift Service Mesh 2 と 3 の違いについてや、移行ドキュメントで詳細をご確認ください。また、Kiali を使用した手順についてのブログ記事もご覧ください。