Service Mesh

• 指定された Service Mesh コントロールプレーン namespace から情報を収集する must-gather データ収集ツールにオプションが追加されました。詳細は、OSSM-351 を参照してください。
• 数百の namespace が含まれる Service Mesh コントロールプレーンのパフォーマンスの向上

• Service Mesh コントロールプレーンのインストール、アップグレード、および管理を単純化します。
• Service Mesh コントロールプレーンのリソース使用量と起動時間を短縮します。

• ネットワークのコントロールプレーン間の通信を削減することで、パフォーマンスが向上します。

  • Envoy の Secret Discovery Service (SDS) のサポートが追加されました。SDS は、Envoy サイドカープロキシーにシークレットを提供するためのより安全で効率的なメカニズムです。
• よく知られているセキュリティーリスクがある Kubernetes シークレットを使用する必要性がなくなります。

• プロキシーが新しい証明書を認識するのに再起動を必要としなくなったため、証明書のローテーション時にパフォーマンスが向上します。

  • WebAssembly 拡張を使用してビルドされる Istio の Telemetry v2 アーキテクチャーのサポートを追加します。この新しいアーキテクチャーにより、パフォーマンスが大幅に改善されました。
  • ServiceMeshControlPlane リソースを簡素化された設定を含む v2 に更新し、Service Mesh コントロールプレーンの管理を容易にします。
  • WebAssembly 拡張を テクノロジープレビュー として導入します。

• TP: テクノロジープレビュー機能
• GA: 一般公開機能

• Policy (authentication.istio.io/v1alpha1) はサポートされなくなりました。Policy リソースの特定の設定によっては、同じ効果を実現するために複数のリソースを設定しなければならない場合があります。

  • RequestAuthentication (security.istio.io/v1beta1) の使用
  • PeerAuthentication (security.istio.io/v1beta1) の使用

• ServiceMeshPolicy (maistra.io/v1) はサポートされなくなりました。

  • 上記のように RequestAuthentication または PeerAuthentication を使用しますが、Service Mesh コントロールプレーン namespace に配置します。

• RbacConfig (rbac.istio.io/v1alpha1) はサポートされなくなりました。

  • AuthorizationPolicy (security.istio.io/v1beta1) に置き換わります。これは RbacConfig、ServiceRole、および ServiceRoleBinding の動作を包含します。

• ServiceMeshRbacConfig (maistra.io/v1) がサポートされなくなりました。

  • 上記のように AuthorizationPolicy を使用しますが、Service Mesh コントロールプレーンの namespace に配置します。
• ServiceRole (rbac.istio.io/v1alpha1) がサポートされなくなりました。
• ServiceRoleBinding (rbac.istio.io/v1alpha1) がサポートされなくなりました。
• Kiali では、login および LDAP ストラテジーは非推奨になりました。今後のバージョンでは、OpenID プロバイダーを使用した認証が導入されます。

• Istio-14743 Red Hat OpenShift Service Mesh のこのリリースがベースとしている Istio のバージョンに制限があるため、現時点で Service Mesh と互換性のないアプリケーションが存在する可能性があります。詳細は、リンク先のコミュニティーの問題を参照してください。

• OSSM-1655 SMCP で mTLS を有効にした後に、Kiali ダッシュボードにエラーが表示されます。

  SMCP で spec.security.controlPlane.mtls 設定を有効にすると、Kiali コンソールに No subsets defined のエラーメッセージが表示されます。

• OSSM-1505 この問題は、OpenShift Container Platform 4.11 で ServiceMeshExtension リソースを使用する場合にのみ発生します。OpenShift Container Platform 4.11 で ServiceMeshExtension を使用すると、リソースの準備が整いません。oc describe ServiceMeshExtension を使用して問題を調べると、stderr: Error creating mount namespace before pivot: function not implemented というエラーが表示されます。

  回避策: ServiceMeshExtension は Service Mesh 2.2 で廃止されました。ServiceMeshExtension から WasmPlugin リソースに移行します。詳細については、ServiceMeshExtension から WasmPlugin リソースへの移行を参照してください。

• OSSM-1396 ゲートウェイリソースに spec.externalIPs 設定が含まれている場合には、ServiceMeshControlPlane の更新時に再作成されず、ゲートウェイが削除されると再作成されることはありません。
• OSSM-1168 サービスメッシュリソースが単一の YAML ファイルとして作成される場合には、Envoy プロキシーサイドカーが Pod に確実に挿入されません。SMCP、SMMR、およびデプロイメントリソースを個別に作成すると、デプロイメントは想定どおりに機能します。

• OSSM-1052 Service Mesh コントロールプレーンで入力ゲートウェイのサービス ExternalIP を設定すると、サービスは作成されません。SMCP のスキーマには、サービスのパラメーターがありません。

  回避策: SMCP 仕様でゲートウェイの作成を無効にして、(サービス、ロール、および RoleBinding など) ゲートウェイのデプロイメントを完全に手動で管理します。

• OSSM-882 これは、Service Mesh 2.1 以前に適用されます。namespace は accessible_namespace 一覧にありますが、Kiali UI には表示されません。デフォルトでは、Kiali は kube で始まる namespace を表示しません。これらの namespace は通常内部使用のみであり、メッシュの一部ではないためです。

  たとえば、akube-a という名前の namespace を作成し、これを Service Mesh メンバーロールに追加すると、Kiali UI は namespace を表示しません。定義された除外パターンの場合、ソフトウェアは、このパターンで始まるか、そのパターンを含む namespace を除外します。

  回避策: Kiali カスタムリソース設定を変更して、設定に接頭辞としてキャレット (^) を追加します。以下に例を示します。

  api:
    namespaces:
      exclude:
      - "^istio-operator"
      - "^kube-.*"
      - "^openshift.*"
      - "^ibm.*"
      - "^kiali-operator"

• MAISTRA-2692 Mixer が削除されると、Service Mesh 2.0.x で定義されたカスタムメトリクスを 2.1 で使用できません。カスタムメトリクスは EnvoyFilter を使用して設定できます。明示的に文書化されている場合を除き、Red Hat は EnvoyFilter 設定をサポートできません。これは、下層の Envoy API と疎結合されており、後方互換性を保持することができないためです。
• MAISTRA-2648 ServiceMeshExtensions は現時点で IBM Z Systems にデプロイされたメッシュとは互換性がありません。

• MAISTRA-1959 2.0 への移行 Prometheus の収集 (spec.addons.prometheus.scrape が true に設定される) は mTLS が有効にされていると機能しません。また、Kiali は、mTLS が無効にされている場合に余分なグラフデータを表示します。

  この問題は、たとえば、プロキシー設定からポート 15020 を除外して対応できます。

  spec:
    proxy:
      networking:
        trafficControl:
          inbound:
            excludedPorts:
            - 15020

• MAISTRA-1314 Red Hat OpenShift Service Mesh は IPv6 をサポートしていません。
• MAISTRA-453 新規プロジェクトを作成して Pod を即時にデプロイすると、サイドカーコンテナーの挿入は発生しません。この Operator は Pod の作成前に maistra.io/member-of を追加できないため、サイドカーコンテナーの挿入を発生させるには Pod を削除し、再作成する必要があります。
• MAISTRA-158 同じホスト名を参照する複数のゲートウェイを適用すると、すべてのゲートウェイが機能しなくなります。

• KIALI-2206 初回の Kiali コンソールへのアクセス時に、Kiali のキャッシュされたブラウザーデータがない場合、Kiali サービスの詳細ページの Metrics タブにある View in Grafana リンクは誤った場所にリダイレクトされます。この問題は、Kiali への初回アクセス時にのみ生じます。
• KIALI-507 Kiali は Internet Explorer 11 に対応していません。これは、基礎となるフレームワークが Internet Explorer に対応していないためです。Kiali コンソールにアクセスするには、Chrome、Edge、Firefox、または Safari ブラウザーの最新の 2 バージョンのいずれかを使用します。

• Apache Spark はサポートされていません。
• AMQ/Kafka 経由のストリーミングデプロイメントは、IBM Z および IBM Power Systems ではサポートされません。

• TRACING-2057 Kafka API が v1beta2 に更新され、Strimzi Kafka Operator 0.23.0 がサポートされるようになりました。ただし、この API バージョンは AMQ Streams 1.6.3 ではサポートされません。以下の環境がある場合、Jaeger サービスはアップグレードされず、新規の Jaeger サービスを作成したり、既存の Jaeger サービスを変更したりすることはできません。

  • Jaeger Operator チャネル: 1.17.x stable または 1.20.x stable

  • AMQ Streams Operator チャネル: amq-streams-1.6.x

    この問題を解決するには、AMQ Streams Operator のサブスクリプションチャネルを amq-streams-1.7.x または stable のいずれかに切り替えます。

• OSSM-2053 Red Hat OpenShift Service Mesh Operator 2.2 または 2.3 を使用すると、SMCP の調整中に、SMMR コントローラーがメンバーの namespace を SMMR.status.configuredMembers から削除しました。これにより、メンバーの namespace のサービスがしばらく利用できなくなりました。

  Red Hat OpenShift Service Mesh Operator 2.2 または 2.3 を使用すると、SMMR コントローラーは SMMR.status.configuredMembers から namespace を削除しなくなります。代わりに、コントローラーは namespace を SMMR.status.pendingMembers に追加して、それらが最新ではないことを示します。調整中に、各 namespace が SMCP と同期されると、namespace は SMMR.status.pendingMembers から自動的に削除されます。

• OSSM-1668 新しいフィールド spec.security.jwksResolverCA がバージョン 2.1 SMCP に追加されましたが、2.2.0 および 2.2.1 リリースにはありませんでした。このフィールドが存在する Operator バージョンから、このフィールドが存在しなかった Operator バージョンにアップグレードする場合、SMCP で .spec.security.jwksResolverCA フィールドを使用できませんでした。
• OSSM-1325 istiod Pod がクラッシュし、fatal error: concurrent map iteration and map write のエラーメッセージが表示されます。

• OSSM-1211 フェールオーバー用のフェデレーションサービスメッシュの設定が想定どおりに機能しません。

  Istiod パイロットログに、envoy connection [C289] TLS error: 337047686:SSL routines:tls_process_server_certificate:certificate verify failed のエラーが表示されます。

• OSSM-1099 Kiali コンソールに Sorry, there was a problem を表示していました。Try a refresh or navigate to a different page. メッセージが表示されました
• OSSM-1074 SMCP で定義された Pod アノテーションが Pod に注入されません。
• OSSM-999 Kiali は想定どおりに保持されませんでした。ダッシュボードグラフでは、カレンダーの時刻がグレーアウトされています。
• OSSM-797 Kiali Operator Pod は、Operator のインストールまたはアップグレード時に CreateContainerConfigError を生成します。
• kube で始まる OSSM-722 namespace は Kiali には表示されません。
• OSSM-569: Prometheus istio-proxy コンテナーには CPU メモリー制限がありません。Prometheus istio-proxy サイドカーは、spec.proxy.runtime.container で定義されたリソース制限を使用するようになりました。
• OSSM-449 VirtualService および Service により、以下のエラーが生じます。"Only unique values for domains are permitted.Duplicate entry of domain."
• 同様の名前を持つ OSSM-419 namespace は、namespace が Service Mesh Member Role で定義されていない場合でも、Kiali namespace の一覧に表示されます。
• OSSM-296 ヘルス設定を Kiali カスタムリソース (CR) に追加する場合、これは Kiali configmap にレプリケートされません。
• OSSM-291 Kiali コンソールの、Applications、Services、および Workloads ページの Remove Label from Filters が機能しません。
• OSSM-289 Kiali コンソールの istio-ingressgateway および jaeger-query サービスの Service Details ページにはトレースは表示されません。トレースは Jaeger にあります。
• OSSM-287 Kiali コンソールでは、トレースが Graph Service に表示されません。

• OSSM-285 Kiali コンソールにアクセスしようとすると、Error trying to get OAuth Metadata というエラーメッセージが表示されます。

  回避策: Kiali Pod を再起動します。

• MAISTRA-2735 Red Hat OpenShift Service Mesh バージョン 2.1 では、SMCP の調整時に Service Mesh Operator が削除するリソースが変更されました。以前のバージョンでは、Operator は以下のラベルを持つリソースを削除しました。

  • maistra.io/owner
  • app.kubernetes.io/version

  Operator は app.kubernetes.io/managed-by=maistra-istio-operator ラベルを含まないリソースを無視するようになりました。独自のリソースを作成する場合、app.kubernetes.io/managed-by=maistra-istio-operator ラベルをそれらに追加することはできません。

• MAISTRA-2687 外部証明書を使用する場合には、Red Hat OpenShift Service Mesh 2.1 フェデレーションゲートウェイでは、証明書チェーンが完全に送信されません。Service Mesh フェデレーション egress ゲートウェイはクライアント証明書のみを送信します。フェデレーション Ingress ゲートウェイはルート証明書のみを認識するため、ルート証明書をフェデレーションインポート ConfigMap に追加しない限り、クライアント証明書を検証できません。
• MAISTRA-2635 非推奨の Kubernetes API が置き換えられました。OpenShift Container Platform 4.8 との互換性を維持するために、apiextensions.k8s.io/v1beta1 API は Red Hat OpenShift Service Mesh 2.0.8 で非推奨になりました。
• MAISTRA-2631 nsenter バイナリーが存在しないことが原因で Podman に問題が発生しているため、WASM 機能は使用できません。Red Hat OpenShift Service Mesh は Error: error configuring CNI network plugin exec: "nsenter": executable file not found in $PATH のエラーメッセージを生成します。コンテナーイメージには nsenter が含まれ、WASM が予想通りに機能するようになりました。
• MAISTRA-2534 istiod が JWT ルールで指定された発行者の JWKS の取得を試行する際に、発行者サービスは 502 で応答します。これにより、プロキシーコンテナーの準備ができなくなり、デプロイメントがハングしていました。コミュニティーバグ の修正は、Service Mesh 2.0.7 リリースに含まれています。

• MAISTRA-2411 Operator が ServiceMeshControlPlane で spec.gateways.additionaIngress を使用して新規 ingress ゲートウェイを作成する場合、Operator はデフォルトの istio-ingressgateway の場合と同様に追加の Ingress ゲートウェイの NetworkPolicy を作成しません。これにより、新規ゲートウェイのルートから 503 応答が生じました。

  回避策: <istio-system> namespace に NetworkPolicy を手動で作成します。

• MAISTRA-2401 CVE-2021-3586 servicemesh-operator: NetworkPolicy リソースが Ingress リソースのポートを誤って指定している。Red Hat OpenShift Service Mesh にインストールされた NetworkPolicy リソースでは、アクセス可能なポートが適切に指定されませんでした。これにより、すべての Pod からのこれらのリソース上のすべてのポートにアクセスできていました。以下のリソースに適用されるネットワークポリシーが影響を受けます。

  • Galley
  • Grafana
  • Istiod
  • Jaeger
  • Kiali
  • Prometheus
  • サイドカーインジェクター
• MAISTRA-2378: クラスターが ovs-multitenant で OpenShift SDN を使用するように設定されており、メッシュに多数の namespace (200+) が含まれる場合に、OpenShift Container Platform ネットワークプラグインは namespace を迅速に設定できません。Service Mesh がタイムアウトすると、namespace がサービスメッシュから継続的にドロップされ、再リストされます。
• MAISTRA-2370 は listerInformer で tombstones を処理します。更新されたキャッシュコードベースは、namespace キャッシュからのイベントを集約されたキャッシュに変換する際に tombstones を処理しないため、go ルーチンでパニックが生じました。

• MAISTRA-2117 オプションの ConfigMap マウントを Operator に追加します。CSV にはオプションの ConfigMap ボリュームマウントが含まれるようになり、smcp-templates ConfigMap (存在する場合) をマウントします。smcp-templates ConfigMap が存在しない場合には、マウントされたディレクトリーは空になります。ConfigMap を作成すると、ディレクトリーには ConfigMap からのエントリーが設定され、SMCP.spec.profiles で参照できます。Service Mesh Operator の再起動は必要ありません。

  CSV を変更して 2.0 Operator をを使用して smcp-templates ConfigMap をマウントしている場合には、Red Hat OpenShift Service Mesh 2.1 にアップグレードできます。アップグレード後に、CSV を編集せずに、既存の ConfigMap およびこれに含まれるプロファイルを引き続き使用できます。以前別の名前で ConfigMap を使用していた場合は、ConfigMap の名前を変更するか、またはアップグレード後に CSV を更新する必要があります。

• MAISTRA-2010 AuthorizationPolicy は request.regex.headers フィールドをサポートしません。validatingwebhook はこのフィールドのある AuthorizationPolicy を拒否し、これを無効にした場合でも、パイロットは同じコードを使用してこの検証を試行し、機能しません。

• MAISTRA-1979 2.0 への移行 変換 webhook は、SMCP.status を v2 から v1 に変換する際に以下の重要なフィールドをドロップします。

  • conditions
  • components
  • observedGeneration

  • annotations

    Operator を 2.0 にアップグレードすると、リソースの maistra.io/v1 バージョンを使用する SMCP ステータスを読み取るクライアントツールが破損する可能性があります。

    また、oc get servicemeshcontrolplanes.v1.maistra.io の実行時に READY および STATUS 列が空になります。

• MAISTRA-1947 テクノロジープレビュー ServiceMeshExtensions への更新は適用されません。

  回避策: ServiceMeshExtensions を削除し、再作成します。

• MAISTRA-1983 2.0 への移行 既存の無効な ServiceMeshControlPlane を使用した 2.0.0 へのアップグレードは修復できません。ServiceMeshControlPlane リソース内の無効な項目により、回復不可能なエラーが発生しました。修正により、エラーが回復可能になりました。無効なリソースを削除してこれを新しいリソースに置き換えるか、またはリソースを編集してエラーを修正できます。リソースの編集に関する詳細は、 [Red Hat OpenShift Service Mesh インストールの設定] を参照してください。
• MAISTRA-1502 バージョン 1.0.10 の CVE の修正により、Istio ダッシュボードは Grafana の Home Dashboard メニューから利用できなくなりました。Istio ダッシュボードにアクセスするには、ナビゲーションパネルの Dashboard メニューをクリックし、Manage タブを選択します。
• MAISTRA-1399 Red Hat OpenShift Service Mesh では、サポート対象外の CNI プロトコルがインストールされなくなりました。サポート対象のネットワーク設定は変更されていません。
• MAISTRA-1089 2.0 への移行 コントロールプレーン以外の namespace で作成されたゲートウェイは自動的に削除されます。SMCP 仕様からゲートウェイ定義を削除した後にこれらのリソースを手動で削除する必要があります。

• MAISTRA-858 Istio 1.1.x に関連する非推奨のオプションと設定 について説明する以下のような Envoy ログメッセージが予想されます。

  • [2019-06-03 07:03:28.943][19][warning][misc] [external/envoy/source/common/protobuf/utility.cc:129] Using deprecated option 'envoy.api.v2.listener.Filter.config'.この設定はまもなく Envoy から削除されます。
  • [2019-08-12 22:12:59.001][13][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Listener.use_original_dst' from file lds.proto.この設定はまもなく Envoy から削除されます。

• MAISTRA-806 エビクトされた Istio Operator Pod により、メッシュおよび CNI はデプロイできなくなります。

  回避策: コントロールペインのデプロイ時に istio-operator Pod がエビクトされる場合は、エビクトされた istio-operator Pod を削除します。

• MAISTRA-681 Service Mesh コントロールプレーンに多くの namespace がある場合に、パフォーマンスの問題が発生する可能性があります。
• MAISTRA-193 ヘルスチェックが citadel で有効になっていると、予期しないコンソール情報メッセージが表示されます。
• Bugzilla 1821432: OpenShift Container Platform カスタムリソースの詳細ページのトグルコントロールで CR が正しく更新されません。OpenShift Container Platform Web コンソールの Service Mesh Control Plane (SMCP) Overview ページの UI のトグルコントロールにより、リソースの誤ったフィールドが更新されることがあります。SMCP を更新するには、YAML コンテンツを直接編集するか、トグルコントロールをクリックせずにコマンドラインからリソースを更新します。

• TRACING-2337 Jaeger が、Jaeger ログに以下のような警告メッセージを繰り返しロギングする。

  {"level":"warn","ts":1642438880.918793,"caller":"channelz/logging.go:62","msg":"[core]grpc: Server.Serve failed to create ServerTransport: connection error: desc = \"transport: http2Server.HandleStreams received bogus greeting from client: \\\"\\\\x16\\\\x03\\\\x01\\\\x02\\\\x00\\\\x01\\\\x00\\\\x01\\\\xfc\\\\x03\\\\x03vw\\\\x1a\\\\xc9T\\\\xe7\\\\xdaCj\\\\xb7\\\\x8dK\\\\xa6\\\"\"","system":"grpc","grpc_log":true}

  この問題は、gRPC ポートではなく、クエリーサービスの HTTP(S) ポートのみを公開することで解決されました。

• TRACING-2009 Jaeger Operator が Strimzi Kafka Operator 0.23.0 のサポートを追加するように更新されました。
• TRACING-1907: アプリケーション namespace に Config Map がないため、Jaeger エージェントサイドカーの挿入が失敗していました。Config Map は正しくない OwnerReference フィールドの設定により自動的に削除され、そのため、アプリケーション Pod は ContainerCreating ステージから移動しませんでした。誤った設定が削除されました。
• TRACING-1725 は TRACING-1631 に対応しています。これはもう 1 つの修正であり、同じ名前だが異なる namespace にある複数の Jaeger 実稼働インスタンスがある場合に Elasticsearch 証明書を適切に調整することができるようになりました。BZ-1918920 も参照してください。
• TRACING-1631 同じ名前を使用するが、異なる namespace 内にある複数の Jaeger 実稼働インスタンスを使用すると、Elasticsearch 証明書に問題が発生します。複数のサービスメッシュがインストールされている場合、すべての Jaeger Elasticsearch インスタンスは個別のシークレットではなく同じ Elasticsearch シークレットを持ち、これにより、OpenShift Elasticsearch Operator がすべての Elasticsearch クラスターと通信できなくなりました。
• TRACING-1300 Istio サイドカーを使用する場合に、Agent と Collector 間の接続が失敗します。Jaeger Operator で有効にされた TLS 通信の更新は、Jaeger サイドカーエージェントと Jaeger Collector 間でデフォルトで提供されます。
• TRACING-1208 Jaeger UI にアクセスする際に、認証の 500 Internal Error が出されます。OAuth を使用して UI に対する認証を試行すると、oauth-proxy サイドカーが additionalTrustBundle でインストール時に定義されたカスタム CA バンドルを信頼しないため、500 エラーが出されます。
• TRACING-1166 現時点で、Jaeger ストリーミングストラテジーを非接続環境で使用することはできません。Kafka クラスターがプロビジョニングされる際に、以下のエラーが出されます: Failed to pull image registry.redhat.io/amq7/amq-streams-kafka-24-rhel7@sha256:f9ceca004f1b7dccb3b82d9a8027961f9fe4104e0ed69752c0bdd8078b4a1076
• Trace-809 Jaeger Ingester には Kafka 2.3 との互換性がありません。Jaeger Ingester のインスタンスが複数あり、十分なトラフィックがある場合、リバランスメッセージがログに継続的に生成されます。これは、Kafka 2.3.1 で修正された Kafka 2.3 のリグレッションによって生じます。詳細は、Jaegertracing-1819 を参照してください。

• BZ-1918920/LOG-1619 Elasticsearch Pod は更新後に自動的に再起動しません。

  回避策: Pod を手動で再起動します。

• Kiali アプリケーション (バックエンド): このコンポーネントはコンテナーアプリケーションプラットフォームで実行され、サービスメッシュコンポーネントと通信し、データを取得し、処理し、そのデータをコンソールに公開します。Kiali アプリケーションはストレージを必要としません。アプリケーションをクラスターにデプロイする場合、設定は ConfigMap およびシークレットに設定されます。
• Kiali コンソール (フロントエンド): Kiali コンソールは Web アプリケーションです。Kiali アプリケーションは Kiali コンソールを提供し、データをユーザーに表示するためにバックエンドに対してデータのクエリーを実行します。

• Red Hat Service Mesh (Istio): Istio は Kiali の要件です。Istio はサービスメッシュを提供し、制御するコンポーネントです。Kiali と Istio を個別にインストールすることはできますが、Kiali は Istio に依存し、Istio が存在しない場合は機能しません。Kiali は、Prometheus および Cluster API 経由で公開される Istio データおよび設定を取得する必要があります。
• Prometheus: 専用の Prometheus インスタンスは Red Hat OpenShift Service Mesh インストールの一部として組み込まれています。Istio Telemetry が有効にされている場合、メトリクスデータは Prometheus に保存されます。Kiali はこの Prometheus データを使用して、メッシュトポロジーの判別、メトリクスの表示、健全性の算出、可能性のある問題の表示などを行います。Kiali は Prometheus と直接通信し、Istio Telemetry で使用されるデータスキーマを想定します。Prometheus は Istio に依存しており、Kiali と明示的な依存関係があるため、Kiali の機能の多くは Prometheus なしに機能しません。
• Cluster API: Kiali はサービスメッシュ設定を取得し、解決するために、OpenShift Container Platform (Cluster API) の API を使用します。Kiali は Cluster API に対してクエリーを実行し、たとえば、namespace、サービス、デプロイメント、Pod、その他のエンティティーの定義を取得します。Kiali はクエリーを実行して、異なるクラスターエンティティー間の関係も解決します。Cluster API に対してもクエリーを実行し、仮想サービス、宛先ルール、ルートルール、ゲートウェイ、クォータなどの Istio 設定を取得します。
• Jaeger: Jaeger はオプションですが、Red Hat OpenShift Service Mesh インストールの一部としてデフォルトでインストールされます。デフォルトの Red Hat OpenShift Service Mesh インストールの一部として分散トレースプラットフォームをインストールすると、Kiali コンソールには分散トレースデータを表示するタブが含まれます。Istio の分散トレース機能を無効にした場合、トレースデータは利用できないことに注意してください。また、トレースデータを表示するには、ユーザーは Service Mesh コントロールプレーンがインストールされている namespace にアクセスできる必要があります。
• Grafana: Grafana はオプションですが、デフォルトでは Red Hat OpenShift Service Mesh インストールの一部としてインストールされます。使用可能な場合、Kiali のメトリクスページには Grafana 内の同じメトリクスにユーザーを移動させるリンクが表示されます。Grafana ダッシュボードへのリンクと Grafana データを表示するには、Service Mesh コントロールプレーンがインストールされている namespace にユーザーがアクセスできる必要があることに注意してください。

• 健全性: アプリケーション、サービス、またはワークロードの問題を素早く特定します。
• トポロジー: Kiali グラフを使用して、アプリケーション、サービス、またはワークロードの通信方法を可視化します。
• メトリクス: 事前定義済みのメトリクスダッシュボードを使用すると、Go、Node.js、Quarkus、Spring Boot、Thorntail、および Vert.xまた、独自のカスタムダッシュボードを作成することもできます。
• トレース: Jaeger との統合により、アプリケーションを設定するさまざまなマイクロサービスで要求のパスを追跡できます。
• 検証: 最も一般的な Istio オブジェクト (宛先ルール、サービスエントリー、仮想サービスなど) で高度な検証を実行します。
• 設定: ウィザードを使用するか、または Kiali コンソールの YAML エディターを直接使用して、Istio ルーティング設定を作成し、更新し、削除できるオプションの機能です。

• 分散トランザクションの監視
• パフォーマンスとレイテンシーの最適化
• 根本原因分析の実行

• Red Hat OpenShift 分散トレースプラットフォーム: このコンポーネントは、オープンソースの Jaeger プロジェクト に基づいています。
• Red Hat OpenShift 分散トレースデータ収集: このコンポーネントは、オープンソースの OpenTelemetry プロジェクト に基づいています。

• Red Hat OpenShift 分散トレースプラットフォーム: このコンポーネントは、オープンソースの Jaeger プロジェクト に基づいています。

  • クライアント (Jaeger クライアント、Tracer、Reporter、インストルメント化されたアプリケーション、クライアントライブラリー): 分散トレースプラットフォームクライアントは、OpenTracing API の言語固有の実装です。それらは、手動または (Camel (Fuse)、Spring Boot (RHOAR)、MicroProfile (RHOAR/Thorntail)、Wildfly (EAP)、その他 OpenTracing にすでに統合されているものを含む) 各種の既存オープンソースフレームワークを使用して、分散トレース用にアプリケーションをインストルメント化するために使用できます。
  • エージェント (Jaeger エージェント、Server Queue、Processor Worker): 分散トレースプラットフォームエージェントは、User Datagram Protocol (UDP) で送信されるスパンをリッスンするネットワークデーモンで、 Collector にバッチ処理や送信を実行します。このエージェントは、インストルメント化されたアプリケーションと同じホストに配置されることが意図されています。これは通常、Kubernetes などのコンテナー環境にサイドカーコンテナーを配置することによって実行されます。
  • Jaeger Collector (Collector、Queue、Worker): Jaeger エージェントと同様に、Jaeger Collector はスパンを受信し、これらを処理するために内部キューに配置します。これにより、Jaeger Collector はスパンがストレージに移動するまで待機せずに、クライアント/エージェントにすぐに戻ることができます。
  • Storage (Data Store): コレクターには永続ストレージのバックエンドが必要です。Red Hat OpenShift 分散トレースプラットフォームには、スパンストレージ用のプラグ可能なメカニズムがあります。本リリースでは、サポートされているストレージは Elasticsearch のみであることに注意してください。
  • Query (Query Service): Query は、ストレージからトレースを取得するサービスです。
  • Ingester (Ingester Service): Red Hat OpenShift 分散トレースは Apache Kafka を Collector と実際の Elasticsearch バッキングストレージ間のバッファーとして使用できます。Ingester は、Kafka からデータを読み取り、Elasticsearch ストレージバックエンドに書き込むサービスです。
  • Jaeger Console: Red Hat OpenShift 分散トレースプラットフォームユーザーインターフェイスを使用すると、分散トレースデータを可視化できます。検索ページで、トレースを検索し、個別のトレースを設定するスパンの詳細を確認することができます。

• Red Hat OpenShift 分散トレースデータ収集: このコンポーネントは、オープンソースの OpenTelemetry プロジェクト に基づいています。

  • OpenTelemetry Collector: OpenTelemetry Collector は、テレメトリーデータを受信、処理、エクスポートするためのベンダーに依存しない方法です。OpenTelemetry Collector は、Jaeger や Prometheus などのオープンソースの可観測性データ形式をサポートし、1 つ以上のオープンソースまたは商用バックエンドに送信します。Collector は、インストルメンテーションライブラリーがテレメトリーデータをエクスポートするデフォルトの場所です。

• Kiali との統合: 適切に設定されている場合、Kiali コンソールから分散トレースデータを表示できます。
• 高いスケーラビリティー: 分散トレースバックエンドは、単一障害点がなく、ビジネスニーズに合わせてスケーリングできるように設計されています。
• 分散コンテキストの伝播: さまざまなコンポーネントからのデータをつなぎ、完全なエンドツーエンドトレースを作成できます。
• Zipkin との後方互換性: Red Hat OpenShift 分散トレースには、Zipkin のドロップイン置き換えで使用できるようにする API がありますが、本リリースでは、Red Hat は Zipkin の互換性をサポートしていません。

• すべてのリソースに maistra-version ラベルが追加されました。
• すべての Ingress リソースが OpenShift ルートリソースに変換されました。
• Grafana、分散トレース (Jaeger)、および Kiali はデフォルトで有効にされ、OpenShift ルート経由で公開されます。
• すべてのテンプレートから Godebug が削除されました。
• istio-multi ServiceAccount および ClusterRoleBinding が削除されました。また、istio-reader ClusterRole も削除されました。

• spec.gateways.enabled=false は、ingress ゲートウェイと egress ゲートウェイの両方を無効にします。
• spec.gateways.ingress.enabled=false は、ingress ゲートウェイを無効にします。
• spec.gateways.egress.enabled=false は、egress ゲートウェイを無効にします。

• NetworkPolicy: Red Hat OpenShift Service Mesh は、各メンバープロジェクトで NetworkPolicy リソースを作成し、他のメンバーおよびコントロールプレーンからのすべての Pod に対する Ingress を許可します。Service Meshからメンバーを削除すると、この NetworkPolicy リソースがプロジェクトから削除されます。

  注記

  また、これにより Ingress がメンバープロジェクトのみに制限されます。メンバー以外のプロジェクトの Ingress が必要な場合は、NetworkPolicy を作成してそのトラフィックを許可する必要があります。

• Multitenant: Red Hat OpenShift Service Mesh は、各メンバープロジェクトの NetNamespace をコントロールプレーンプロジェクトの NetNamespace に追加します (oc adm pod-network join-projects --to control-plane-project member-project の実行と同じです)。Service Meshからメンバーを削除すると、その NetNamespace はコントロールプレーンから分離されます (oc adm pod-network isolate-projects member-project の実行と同じです)。
• Subnet: 追加の設定は実行されません。

• コントロールプレーン全体の認証ポリシーを設定するために、MeshPolicy は ServiceMeshPolicy に置き換えられます。これは、コントロールプレーンと同じプロジェクトに作成する必要があります。
• コントロールプレーン全体のロールベースのアクセス制御を設定するために、ClusterRbacConfig は ServicemeshRbacConfig に置き換えられます。これは、コントロールプレーンと同じプロジェクトに作成する必要があります。

• Red Hat OpenShift Container Platform バージョン 4.9 以降
• Red Hat OpenShift Dedicated バージョン 4
• Azure Red Hat OpenShift (ARO) バージョン 4
• Red Hat OpenShift Service on AWS (ROSA)

• OpenShift Online は Red Hat OpenShift Service Mesh に対してはサポートされていません。
• Red Hat OpenShift Service Mesh では、Service Mesh が実行されているクラスター以外にあるマイクロサービスの管理はサポートしていません。

• OpenShift-SDN
• OVN-Kubernetes は OpenShift Container Platform 4.7.32+、OpenShift Container Platform 4.8.12+、および OpenShift Container Platform 4.9+ でサポートされます。
• OpenShift Container Platform で認定され、さらに Service Mesh 適合テストに合格したサードパーティーの Container Network Interface(CNI) プラグイン。詳細は、認定 OpenShift CNI プラグイン を参照してください。

• Red Hat OpenShift Service Mesh の本リリースは、OpenShift Container Platform x86_64、IBM Z、および IBM Power Systems でのみ利用できます。

  • IBM Z は OpenShift Container Platform 4.6 以降でのみサポートされます。
  • IBM Power Systems は OpenShift Container Platform 4.6 以降でのみサポートされます。
• すべての Service Mesh コンポーネントが単一の OpenShift Container Platform クラスター内に含まれる設定。
• 仮想マシンなどの外部サービスを統合しない設定。
• Red Hat OpenShift Service Mesh は、明示的に文書化されている場合を除き、EnvoyFilter の設定はサポートしていません。

• Kiali コンソールは Chrome、Edge、Firefox、または Safari ブラウザーの 2 つの最新リリースでのみサポートされています。

• サイドカーとしての Jaeger エージェントは、Jaeger について唯一サポートされる設定です。デーモンセットとしての Jaeger はマルチテナントインストールまたは OpenShift Dedicated ではサポートされません。

• 3scale WebAssembly は、提供されている唯一の WebAssembly モジュールです。カスタム WebAssembly モジュールを作成できます。

• ['**'] (すべての namespaces)
• default
• codeready-*
• openshift-*
• redhat-*

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされ、検証されていること。
• サービスメッシュに追加する既存プロジェクトの一覧。

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされ、検証されていること。
• サービスメッシュに追加するプロジェクトの一覧。
• OpenShift CLI (oc) へのアクセスがある。

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされ、検証されていること。
• 既存の ServiceMeshMemberRoll リソース。
• ServiceMeshMemberRoll リソースを持つプロジェクトの名前。
• メッシュに/から追加または削除するプロジェクトの名前。

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされ、検証されていること。
• 既存の ServiceMeshMemberRoll リソース。
• ServiceMeshMemberRoll リソースを持つプロジェクトの名前。
• メッシュに/から追加または削除するプロジェクトの名前。
• OpenShift CLI (oc) へのアクセスがある。

前提条件:

• OpenShift Container Platform 4.1 以降がインストールされている。
• Red Hat OpenShift Service Mesh 2.2.3 がインストールされている。
• OpenShift CLI (oc) へのアクセスがある。
• cluster-admin ロールを持つアカウントがある。

前提条件

• Red Hat OpenShift Service Mesh がインストールされている。
• Bookinfo サンプルアプリケーションのインストール手順を実行します。

前提条件

• OpenShift Container Platform 4.1 以降がインストールされている。
• Red Hat OpenShift Service Mesh 2.2.3 がインストールされている。
• OpenShift CLI (oc) へのアクセスがある。

• パッチの更新: パッチのアップグレードは、Operator Lifecycle Manager (OLM) によって管理されます。Operator を更新すると自動的に発生します。
• マイナーアップグレード: マイナーアップグレードでは、最新の Red Hat OpenShift Service Mesh Operator バージョンに更新することと、ServiceMeshControlPlane リソースの spec.version 値を手動で変更することの両方が必要です。
• メジャーアップグレード: メジャーアップグレードでは、最新の Red Hat OpenShift Service Mesh Operator バージョンに更新することと、ServiceMeshControlPlane リソースの spec.version 値を手動で変更することの両方が必要です。メジャーアップグレードには後方互換性のない変更が含まれている可能性があるため、手動による追加の変更が必要になる場合があります。

• Operator バージョン: 最新の Operator バージョンは 2.2.3 です。Operator バージョン番号は、現在インストールされている Operator のバージョンのみを示します。Red Hat OpenShift Service Mesh Operator は Service Mesh コントロールプレーンの複数のバージョンをサポートするため、Operator のバージョンはデプロイされた ServiceMeshControlPlane リソースのバージョンを決定しません。

  重要

  最新の Operator バージョンにアップグレードすると、パッチの更新が自動的に適用されますが、Service Mesh コントロールプレーンは最新のマイナーバージョンに自動的にアップグレードされません。

• ServiceMeshControlPlane バージョン: ServiceMeshControlPlane バージョンは、使用している Red Hat OpenShift Service Mesh のバージョンを決定します。ServiceMeshControlPlane リソースの spec.version フィールドの値は、Red Hat OpenShift Service Mesh のインストールとデプロイに使用されるアーキテクチャーと設定を制御します。Service Mesh コントロールプレーンを作成する場合は、以下の 2 つの方法のいずれかでバージョンを設定できます。

  • Form View で設定するには、Control Plane Version メニューからバージョンを選択します。
  • YAML View で設定するには、YAML ファイルに spec.version の値を設定します。

• Red Hat OpenShift Service Mesh は、明示的に文書化されている場合を除き、EnvoyFilter 設定の使用はサポートしていません。これは、下層の Envoy API と疎結合されており、後方互換性を保持することができないためです。Envoy フィルターを使用していて、ServiceMeshControlPlane のアップグレードによって導入された新しいバージョンの Envoy が原因で Istio によって生成された設定が変更された場合、実装した EnvoyFilter が壊れる可能性があります。
• OSSM-1505 ServiceMeshExtension は、OpenShift Container Platform バージョン 4.11 では機能しません。ServiceMeshExtension は Red Hat OpenShift Service Mesh 2.2 で非推奨となったため、この既知の問題は修正されず、エクステンションを WasmPluging に移行する必要があります。
• OSSM-1396 ゲートウェイリソースに spec.externalIPs 設定が含まれている場合には、ゲートウェイは、ServiceMeshControlPlane の更新時に再作成されずに削除され、再作成されることはありません。

• OSSM-1052 Service Mesh コントロールプレーンで入力ゲートウェイのサービス ExternalIP を設定すると、サービスは作成されません。SMCP のスキーマには、サービスのパラメーターがありません。

  回避策: SMCP 仕様でゲートウェイの作成を無効にして、(サービス、ロール、および RoleBinding など) ゲートウェイのデプロイメントを完全に手動で管理します。

• istio-node DaemonSet は、アップストリームの Istio の名前と一致するように istio-cni-node に名前が変更されました。
• Istio 1.10 は、デフォルトで lo ではなく eth0 を使用してトラフィックをアプリケーションコンテナーに送信するように Envoy を更新しました。
• このリリースでは、WasmPlugin API のサポートが追加され、ServiceMeshExtentionAPI が廃止されました。

動作上の変更

• AuthorizationPolicy の更新

  • PROXY プロトコルでは、ipBlocks および notIpBlocks を使用してリモート IP アドレスを指定する場合は、代わりに remoteIpBlocks および notRemoteIpBlocks を使用するように設定を更新します。
  • ネストされた JSON Web Token(JWT) 要求のサポートが追加されました。

• EnvoyFilter の重大な変更

  • typed_config を使用する必要があります。
  • Xds v2 はサポート対象外になりました。
  • フィルター名が非推奨になりました。
• 以前のバージョンのプロキシーは、新しいプロキシーから 1xx または 204 ステータスコードを受信すると、503 ステータスコードを報告する場合があります。

前提条件

• OpenShift Container Platform 4.9 以降を実行している。
• 最新の Red Hat OpenShift Service Mesh Operator がある。

前提条件

• OpenShift Container Platform 4.7 にアップグレードしてから Red Hat OpenShift Service Mesh 2.0 にアップグレードする必要があります。
• Red Hat OpenShift Service Mesh のバージョン 2.0 Operator が必要です。自動 アップグレードパスを選択した場合、Operator は最新情報を自動的にダウンロードします。ただし、Red Hat OpenShift Service Mesh バージョン 2.0 で機能を使用するために実行する必要のある手順があります。

前提条件

• Service Mesh Operator がインストールされ、検証されていること。
• cluster-admin ロールを持つアカウントがある。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
• Operator デプロイメントの場所。
• oc として知られる OpenShift Container Platform コマンドラインインターフェイス (CLI) へのアクセス。

• Istio が適切に機能するには、サービスメッシュへのトラフィックが常に ingress-gateway を経由する必要があります。
• サービスメッシュ外のサービスは、サービスメッシュにない個別の namespace にデプロイします。
• サービスメッシュでリストされた namespace 内にデプロイする必要のあるメッシュ以外のサービスでは、それらのデプロイメント maistra.io/expose-route: "true" にラベルを付けます。これにより、これらのサービスへの OpenShift Container Platform ルートは依然として機能します。

前提条件

• Red Hat OpenShift Service Mesh Operator バージョン 2.1.1 以降がインストールされている。
• ServiceMeshControlPlane リソースはバージョン 2.1 以降に更新されている。

前提条件:

• 以下の例に合わせて Bookinfo サンプルアプリケーションをデプロイする。

前提条件

• 独自のアプリケーションがインストールされていない場合は、Bookinfo サンプルアプリケーションをインストールします。次に、以下のコマンドを複数回入力して Bookinfo アプリケーションのトラフィックを生成します。

  $ curl "http://$GATEWAY_URL/productpage"

  このコマンドはアプリケーションの productpage マイクロサービスにアクセスするユーザーをシミュレートします。

前提条件

• Service Mesh がインストールされ、設定されている。
• Kiali がインストールされ、設定されている。
• Kiali コンソールのアドレス。
• アプリケーションまたは Bookinfo サンプルアプリケーションがメッシュに追加されました。

• inbound Application metrics
• outbound Application metrics
• inbound Workload metrics
• outbound Workload metrics
• inbound Service metrics

前提条件

• Service Mesh がインストールされ、設定されている。
• Kiali がインストールされ、設定されている。
• Kiali コンソールのアドレス。
• (オプション): 分散トレースがインストールされ、設定されます。

前提条件

• Red Hat OpenShift 分散トレースインスタンスがインストールされ、設定されている。

• この値を 10 サンプル (トレースの 0.1%) に設定します。
• この値を 500 サンプル (トレースの 5%) に設定します。

• デプロイメントの変更レート。
• 設定の変更レート。
• Istiod へのプロキシー数。

• クライアント接続の数
• ターゲットの要求レート
• 要求サイズおよび応答サイズ
• プロキシーワーカーのスレッド数
• プロトコル
• CPU コア数
• プロキシーフィルターの数およびタイプ (とくに Telemetry v2 関連のフィルター)。

前提条件

• 2 つ以上の OpenShift Container Platform 4.6 以降のクラスター。
• クラスターのネットワーク設定が完了している。
• 生の TLS トラフィックをサポートするように、フェデレーションゲートウェイに関連付けられたサービスをサポートするロードバランサーを設定する必要があります。
• 各クラスターには、フェデレーションデプロイをサポートするようにバージョン 2.1 ServiceMeshControlPlane が設定されている必要があります。
• cluster-admin ロールを持つアカウントがある。

前提条件

• クラスターおよび ServiceMeshControlPlane がメッシュフェデレーション用に設定されている。
• cluster-admin ロールを持つアカウントがある。

前提条件

• クラスターおよび ServiceMeshControlPlane がメッシュフェデレーション用に設定されている。
• cluster-admin ロールを持つアカウントがある。