Red Hat OpenShift Service Mesh 3：開発者プレビューの最新情報

今年の初めに、 Red Hat OpenShift 上の Istio 向けの新しい Operator が、次世代 OpenShift Service Mesh バージョン 3 の開発者プレビューとして利用可能になったと発表しました。その記事では 2024 年に OpenShift Service Mesh に予定されている変更に関する重要な背景情報を説明しました。それ以来、 OpenShift Service Mesh 2 のお客様をサポートし、Service Mesh 3 の計画に関するフィードバックを収集しながら、 Sail Operator の開発を続けてきました。新しい Operator は依然として 開発者プレビューですが、この記事では、OpenShift Service Mesh の最新情報や今後の計画について説明し、OpenShift Service Mesh ユーザーが OpenShift Service Mesh 3 に向けて準備できるように初期ガイダンスを提供します。

Service Mesh 3.0 の最新情報

Service Mesh 3 Kubernetes Operator は現在「Sail Operator」として開発中であり、OpenShift の Operator Hub でコミュニティ Kubernetes Operator として利用できます。Sail Kubernetes Operator は毎晩更新されます。開発中の状態であり、変更される可能性があります。将来的にこのブログ記事の内容とは異なったものに発展する可能性もあるので、現時点では実験用としてのみ使用してください。Kubernetes Operator の最新情報については、付属の README を参照してください。

Red Hat では、このコミュニティ版 Kubernetes Operator をアップストリームの istio-ecosystem 組織に移行させて、コミュニティのコラボレーションを強化しつつ、Istio のコアプロジェクトに強化機能を提供して OpenShift 上の Istio の互換性を向上させようと考えています。OpenShift Service Mesh 3 のダウンストリーム製品アーティファクトは新たに作成された openshift-service-mesh 組織に存在しますが、Service Mesh 2 には maistra 組織が引き続き使用されます。

Istio 専用の Kubernetes Operator

前回のブログ記事で説明したように、OpenShift Service Mesh 3 は Istio 用の新しい Kubernetes Operator をベースとします。現在の OpenShift Service Mesh 2 Kubernetes Operator とは異なり、新しい Kubernetes Operator は Istio リソースのみを管理し、Kiali のように Istio 統合の構成は試みません。Kiali、メトリクス、トレーシングなどの補完的なコンポーネントは、独立してサポートされる製品 Kubernetes Operator によって管理されます。

Sail Operator が最初にリリースされたとき、Istio コントロールプレーンをインストールするためのカスタムリソースは IstioHelmInstall と呼ばれていました。このリソースは、Istio の単一のインスタンス (コントロールプレーンとデータプレーン) の作成と管理を担当することにちなんで、「Istio」に名前が変更されました。

OpenShift Service Mesh 2 で使用されている ServiceMeshControlPlane カスタムリソースとは異なり、Istio リソースはアップストリームの Istio の Helm 値を使用して Istio 設定を定義します。これにより、ユーザーがコミュニティの設定例を OpenShift Service Mesh 3 に転換しやすくなります。また、設定を改善するための今後の取り組みが、Istio コミュニティと連携して行われるようにするためにも役立ちます。Red Hat は、コミュニティの Istio Operator API との今後の収束の可能性を除外していません。この API は istioctl のインストールプロセスや、推奨されていませんがアップストリームの Istio Operator のインストールで使用されています。

今後の取り組みとして、設定と機能強化の編成を改良し、Istioの修正、 カナリア方式のアップグレード、マルチテナンシーなどの機能のサポートを改善することが予定されています。最新の情報については、Kubernetes Operator の README ファイルを参照してください。

リリースの選択

Sail Operator を最初にリリースしたとき、それは Istio の最新バージョンをデプロイするもので、実質的には開発中の Istio の Master ブランチをデプロイしていました。これは Istio コミュニティの最新の成果を試すには便利でしたが、ほとんどの場合、ユーザーは istioctl との安定性と互換性や Kiali などの統合を確保するために Istio の公式リリースを使用する必要がありました。

今では、デフォルトで最新バージョンの Istio を使用し、現時点では 1.20 になります。これを、Istio CRD の version フィールドで設定します。OpenShift コンソールで新しいインスタンスを作成する際に、新しいドロップダウンメニューで、利用できる Istio リリースのリストから選択できるようになりました。利用可能な Istio リリースは versions.yaml ファイルで定義され、新たに Istio リリースが利用可能になると更新されます。

[Istio Version] 選択ドロップダウンメニュー

今後の OpenShift Service Mesh 3 製品の Kubernetes Operator は Sail Operator をベースとし、OpenShift Service Mesh のリリースを同様の方法で管理する予定です。この version フィールドは、Service Mesh 2.x の ServiceMeshControlPlane リソースの version フィールドと似ていますが、注目すべき違いは、ユーザーが Z「パッチ」リリースレベルまでバージョンを指定できることです (例：3.1.1)。Red Hat は OpenShift Service Mesh の最新のパッチリリースのみをサポートしますが、この機能を使用すると、特定の「z」パッチリリースに固定したりロールバックしたりすることができるため、パッチ更新を管理する際の制御性と柔軟性が向上します。

設定の検証

新しい CRD を使用して Istio を設定するための主なフィールドは、 values フィールドです。この強力なフィールドを使用すると、ユーザーは Istio Helm の設定値を直接参照できます。このフィールドに検証を追加しました。これは、アップストリーム Istio の protobuf 検証に基づいて、存在しない設定値やその他の設定エラーを検出するためです。

これらの検証により、次のように values フィールドを管理することもできます。

$ oc explain istio.spec.values 
KIND:     Istio 
VERSION:  operator.istio.io/v1alpha1 
RESOURCE: values <Object> 
DESCRIPTION: 
    Values defines the values to be passed to the Helm chart when installing 
    Istio. 
FIELDS: 
  base <Object> 
  cni <Object> 
  defaultRevision <string> 
  global <Object> 
  istio_cni <Object> 
  istiodRemote <Object> 
  meshConfig <> 
  ownerName <string> 
  pilot <Object> 
  revision <string> 
  revisionTags <[]string> 
  sidecarInjectorWebhook <Object> 
  telemetry <Object> 
  ztunnel <>

たとえば Istio の protobuf スキーマにまだ含まれていない実験的な設定にアクセスする場合など、これらの検証をオーバーライドすることが望ましい場合があります。そのため、 rawValues フィールドも含めています。これは values と同一ですが、検証されません。

Istio の resource、values、および rawValues フィールドはまだ実験段階であり、変更される可能性があります。最新情報については、プロジェクトの README を参照してください。

Istio のステータスと設定

Istio 設定を適用した後、コントロールプレーンのステータスを検証する必要があります。これには次のコマンドを使用します。

$ kubectl get istioundefinedundefinedundefined

NAME         READY  STATUS VERSION AGE

istio-sample True  Healthy v1.20.0 62sundefinedundefined

または status フィールドを使用します。

Istio カスタムリソース定義

展開すると、 status.appliedValues フィールドを使用して、 spec.values フィールドを使用して設定が想定どおりに適用されたことを確認できます。

OpenShift での Istio

コミュニティ Istio との統合に向けた Red Hat の取り組みの一環として、OpenShift での Istio の互換性を向上させるためにアップストリーム Istio に貢献し続けています。これは Red Hat 自身の利益 (Istio を製品化するための作業を単純化する) のためであり、コミュニティ、お客様、パートナーのためでもあります。当社のコントリビューションにより、OpenShift でのコミュニティ版 Istio の実行が容易になり、サポートされている OpenShift Service Mesh へのシームレスなオンボーディングパスが提供されます。

この取り組みの結果の例として、最近 Istio 1.20で強調されているように、 anyuid Security Context Constraint (SCC) 特権を Istio コントロールプレーンおよびデータプレーン・コンポーネントに付与する必要性がなくなりました。Red Hat は継続的に同様の貢献を行っていく予定ですが、そのうち最も重要な取り組みとして、Istio の Ambient メッシュを OpenShift 上で機能させる取り組みを予定しています。

ゲートウェイのベストプラクティス

この Kubernetes Operator の発表時点では、デフォルトの Istio インストール設定プロファイルと同様に、 ゲートウェイが自動的にインストールされました。これは OpenShift Service Mesh 2.x と整合性があり、 istio-ingressgateway と istio-egressgatewayという名前のデフォルトの ingress および egress ゲートウェイを作成します。

これらの自動作成されたゲートウェイは使い始めには便利ですが、プロダクション環境に必要な設定を行う機能がありません。また、ゲートウェイは、コントロールプレーンではなくデータプレーンのアプリケーションで作成および管理するほうが適切であるとも強く感じています。アプリケーションとともに作成および管理されるゲートウェイはより優れたセキュリティプラクティスとして機能するため、ゲートウェイの範囲が少数のアプリケーションに制限され、コントロールプレーンではなくアプリケーションのライフサイクルを採用することができます。

そのため、これらのコントロールプレーン・ゲートウェイを削除し、ゲートウェイ・インジェクションまたは Kubernetes Gateway API を使用してアプリケーションでゲートウェイを作成するようにユーザーに案内することにしました。OpenShift Service Mesh 2.x の ServiceMeshControlPlaneで指定されている istio-ingressgateway および istio-egressgatewayは、Service Mesh 3.0 には含まれません。代わりに、ゲートウェイ・インジェクションと Kubernetes Gateway API を使用して、 Bookinfo アプリケーション用のゲートウェイの構成例を提供します。

 ゲートウェイ・インジェクションでは、ゲートウェイは、Envoy プロキシによって注入される Deployment リソースを使用して、Kubernetes または OpenShift 上の他のワークロードと同じように作成および管理されます。このアプローチにより、アプリケーションオーナーはゲートウェイを完全に制御できます。OpenShift Service Mesh 2.3 以降でゲートウェイを作成および管理する場合は、これが推奨される方法です。

OpenShift Service Mesh 2.4 のテクノロジープレビューで Gateway API を使用すると、ゲートウェイの "Deployment" インスタンスが作成され、各 ゲートウェイインスタンスとともに設定されます。

これらのオプションによりアプリケーションでゲートウェイを作成および管理でき、 GitOps ワークフローの一部とすることができれば理想的です。

Kubernetes Gateway API

Kubernetes Gateway API は、Kubernetes でネットワークをモデリングするための次世代の API です。現在の Kubernetes Ingress APIと比較して、大規模組織のネットワーク管理における柔軟性と拡張性が大幅に向上します。当初は、クラスタ外のクライアントから North-South トラフィックを管理することが目的でしたが、サービスメッシュを含む、East-West トラフィックを含むように拡大しました。 GAMMA イニシアチブは、Gateway API がサービスメッシュのユースケースにどのように対応できるかを定義するために作成されました。Istio には、 トラフィック管理など、ほとんどの文書化されたタスクの Gateway API 設定例が含まれています。

Gateway API は OpenShift Service Mesh 2.4 のテクノロジープレビュー機能のままであり、 機能フラグを使用して有効にする必要がありますが、現在は コミュニティで一般提供されています。API のバージョン 1.0 は Istio 1.20 で利用できます (OpenShift Service Mesh 2.6 以降に含まれます)。Istio は、将来 Gateway API をすべてのトラフィック管理のデフォルト API にする予定ですが、当面は Istio API (Gateway、VirtualService、DestinationRule など) のサポートを継続します。

私たちは、サービスメッシュだけにとどまらず、Gateway API プロジェクトが Kubernetes ネットワークに共通のスタンダードとなる可能性について強い関心を持っています。

Red Hat は、OpenShift Ingress ユーザーが Gateway API Ingress Operator を介してサービスメッシュとは別にデプロイできる、Gateway API ベースの実装を開発しています。この作業と Gateway API の詳細については、この ブログ記事 および最新情報を参照してください。

一方、 3Scale API Management を提供したチームは Kuadrant.io プロジェクトに取り組んでいます。このプロジェクトは、Gateway API を活用して、外部トラフィックが Ingress ゲートウェイに入る方法に関するユースケースに対処します。たとえば、マルチクラスタ接続、グローバル・ロードバランシング、レート制限、認可などです。このプロジェクトに関する詳細は、今後のブログ記事をご覧ください。

Kiali などの Istio アドオンの使用を開始する

OpenShift Service Mesh 3.0 での注目すべき変更点は、Kubernetes Operator が Istio のみを管理することです。Kiali、分散トレーシング、メトリクスなどの統合は個別にインストールされ、管理されます。これによって「始める」ための手順が増えることになりますが、コンポーネントの構成においてモジュール性と柔軟性を高めるというトレードオフには、それだけの価値があると考えています。

ユーザーが迅速に作業を開始できるように、Istioctl、サンプル Gateway、Prometheus、Jaeger、Kiali を使用して Istio を設定するための 手順を Kubernetes Operator README に追加しました。これは、現在 OpenShift Service Mesh 2.x が追加の設定なしに提供するものとほぼ同等のデモ/開発環境を提供します。また、OpenShift Service Mesh 3 で提供する予定のインストール・ワークフローのプレビューも提供します。このワークフローでは、Istio は単体でインストールされ、アドオンは個別にインストールされます。もちろん、サポート対象の Service Mesh 3.0 では、Istioctl のサポート対象のディストリビューションを使用して、各 Istio アドオンに対してサポート対象の製品 Kubernetes Operator を使用します。これらのコミュニティ Istio アドオンの設定は、デモ/開発目的のみに使用し、プロダクション環境では使用しないでください。

Service Mesh 3.0 の準備

OpenShift Service Mesh 2 ユーザーが Service Mesh 3.0 の導入の準備のために今すぐ実行できることがいくつかあります。

OpenShift Service Mesh 3 は引き続き Istio をベースとし、エンドユーザーが使用する可能性が高い Istio の安定した API は変更されません。OpenShift Service Mesh 3 で変更され、移行が必要となるのは、 ServiceMeshControlPlane、 ServiceMeshMemberRoll、  ServiceMeshMemberRoll などのコントロールプレーン設定リソースです。これらのリソースを管理するのは、通常、アプリケーションオーナーではなく、管理者またはプラットフォームチームです。管理者が既存のコントロールプレーンの設定を Service Mesh 3 の設定に移行する方法を引き続き模索していきます。

アプリケーション固有の設定 (VirtualServices、 DestinationRules、 PeerAuthentication などの Istio リソース) は変更されません。したがってユーザーは、OpenShift Service Mesh 3 に移行するときにアプリケーションやサービス固有の設定を移行することなく、OpenShift Service Mesh 2 の使用方法をそのまま開始したり、拡張したりできると確信できます。

OpenShift Service Mesh 3.0 への移行を容易にするために、ユーザーが現在実行できることがいくつかあります。最新の OpenShift Service Mesh リリース (2.4 以降) の使用に加えて、次のことができます。

• ゲートウェイ・インジェクションを導入または移行し、Istio コントロールプレーン (Service Mesh 2.0 のデフォルト) ではなく、アプリケーションで Istio ゲートウェイを作成して管理します。前述のとおり、3.0 のコントロールプレーンはゲートウェイを作成しません。
• 複数のコントロールプレーンが必要ない場合は、 クラスタ全体モードを使用します。このモードでは、Istiod はクラスタレベルのリソースとして実行されます。これが Service Mesh 3.0 のデフォルトとなり、有望な マルチコントロールプレーン機能を使用して複数のコントロールプレーンを作成することができます。
• メトリクスの取得に OpenShift のユーザーワークロード監視または Red Hat Advanced Cluster Management の Observability を使用するように Service Mesh を設定します。これらにより、OpenShift Service Mesh 2.x でインストールされるメトリクススタック (これは Service Mesh 3 で削除されます) よりもはるかに設定可能性と拡張性の高いアラート機能を備えたプロダクショングレードのモニタリングスタックが提供されます。
• ServiceMeshControlPlane リソース内で直接設定するのではなく、外部で設定された Kiali と Jaeger のリソースを使用します。Kiali と Jaeger の管理の柔軟性を向上させるだけでなく、これらは Service Mesh 3 で個別に設定されます。

これらの各トピックについてさらに深く掘り下げたブログ記事を、後日公開する予定です。

OpenShift Service Mesh の次のステップ

次のリリースは OpenShift Service Mesh 2.5 (Istio 1.18 ベース) で、2024 年初めに予定されています。また、2024 年中に Istio 1.20 またはそれ以降をベースとする 2.6 リリースを提供することも決定しました。これは、お客様が OpenShift Service Mesh 2 から 3 にアップグレードするために重複サポートを少なくとも 1 年間は受けられるようにするためです。2.6 リリースによって、テクノロジープレビュー状態にある OpenShift Service Mesh 3 に対するフィードバックを収集するための時間の余裕が生まれます。

OpenShift Service Mesh 3 では、Istio 設定をより適切に管理できるようカスタムリソース定義を微調整したり、Istio コントロールプレーンのカナリアアップグレードをより適切にサポートする機能を追加したりするなど、新しい Kubernetes Operator を継続的に進化させています。テクノロジープレビューは 2024 年第 1 四半期後半を目指し、2024 年下半期に一般提供を開始する予定です。もちろん、これらの目標は変更される場合があります。Red Hat は、OpenShift Service Mesh 3 の一般提供が完了するまで、OpenShift Service Mesh 2.x のお客様を引き続きサポートします。

Red Hat OpenShift Service Mesh の詳細については、 このページをご覧ください。