Service Mesh

• Red Hat OpenShift Service Mesh Operator がテクノロジープレビュー機能として ARM ベースのクラスターで利用できるようになりました。
• envoyExtAuthzGrpc フィールドが追加されました。これは、gRPC API を使用して外部承認プロバイダーを設定するために使用されます。
• Common Vulnerabilities and Exposures (CVE) が解決されました。
• このリリースは、OpenShift Container Platform 4.10 以降のバージョンでサポートされます。

• 指定された 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 拡張を テクノロジープレビュー として導入します。

• ECDHE-ECDSA-AES128-SHA
• ECDHE-RSA-AES128-SHA
• AES128-GCM-SHA256
• AES128-SHA
• ECDHE-ECDSA-AES256-SHA
• ECDHE-RSA-AES256-SHA
• AES256-GCM-SHA384
• AES256-SHA

• ECDHE-ECDSA-AES128-SHA
• ECDHE-RSA-AES128-SHA
• AES128-GCM-SHA256
• AES128-SHA
• ECDHE-ECDSA-AES256-SHA
• ECDHE-RSA-AES256-SHA
• AES256-GCM-SHA384
• AES256-SHA

• 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 プロバイダーを使用した認証が導入されます。

• OSSM-3890 マルチテナントメッシュデプロイメントでゲートウェイ API を使用しようとすると、次のようなエラーメッセージが生成されます。

  2023-05-02T15:20:42.541034Z	error	watch error in cluster Kubernetes: failed to list *v1alpha2.TLSRoute: the server could not find the requested resource (get tlsroutes.gateway.networking.k8s.io)
  2023-05-02T15:20:42.616450Z	info	kube	controller "gateway.networking.k8s.io/v1alpha2/TCPRoute" is syncing...

  マルチテナントメッシュデプロイメントでゲートウェイ API をサポートするには、すべてのゲートウェイ API カスタムリソース定義 (CRD) ファイルがクラスター内に存在する必要があります。

  マルチテナントメッシュデプロイメントでは、CRD スキャンが無効になり、Istio はクラスター内にどの CRD が存在するかを検出する方法がありません。その結果、Istio はサポートされているすべての Gateway API CRD を監視しようとしますが、それらの CRD の一部が存在しない場合はエラーが生成されます。

  Service Mesh 2.3.1 以降のバージョンは、v1alpha2 と v1beta1 の両方の CRD をサポートします。したがって、マルチテナントメッシュデプロイメントでゲートウェイ API をサポートするには、両方の CRD バージョンが存在する必要があります。

  回避策: 次の例では、kubectl get 操作により v1alpha2 および v1beta1 CRD がインストールされます。URL には追加の experimental セグメントが含まれており、それに応じて既存のスクリプトが更新されることに注意してください。

  $ kubectl get crd gateways.gateway.networking.k8s.io ||   { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.5.1" | kubectl apply -f -; }

• OSSM-2042 default という名前の SMCP のデプロイメントが失敗します。SMCP オブジェクトを作成し、そのバージョンフィールドを v2.3 に設定する場合、オブジェクトの名前は default にできません。名前が default の場合、コントロールプレーンはデプロイに失敗し、OpenShift は次のメッセージを含む Warning イベントを生成します。

  Error processing component mesh-config: error: [mesh-config/templates/telemetryv2_1.6.yaml: Internal error occurred: failed calling webhook "rev.validation.istio.io": Post "https://istiod-default.istio-system.svc:443/validate?timeout=10s": x509: certificate is valid for istiod.istio-system.svc, istiod-remote.istio-system.svc, istio-pilot.istio-system.svc, not istiod-default.istio-system.svc, mesh-config/templates/enable-mesh-permissive.yaml

• 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 Service Mesh リソースが単一の YAML ファイルとして作成される場合は、Envoy プロキシーサイドカーが Pod に確実に挿入されません。SMCP、SMMR、およびデプロイメントリソースを個別に作成すると、デプロイメントは想定どおりに機能します。

• OSSM-1115 spec.proxy API の concurrency フィールドが istio-proxy に伝播されませんでした。concurrency フィールドは、ProxyConfig で設定すると機能します。concurrency フィールドは、実行するワーカースレッドの数を指定します。フィールドが 0 に設定されている場合、使用可能なワーカースレッドの数は CPU コアの数と等しくなります。フィールドが設定されていない場合、使用可能なワーカースレッドの数はデフォルトで 2 になります。

  次の例では、concurrency フィールドが 0 に設定されています。

  apiVersion: networking.istio.io/v1beta1
  kind: ProxyConfig
  metadata:
    name: mesh-wide-concurrency
    namespace: <istiod-namespace>
  spec:
    concurrency: 0

• 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 サービスメッシュ拡張機能は現在、IBM Z にデプロイされたメッシュと互換性がありません。

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

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

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

• 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 バージョンのいずれかを使用します。

• OSSM-4851 以前は、runAsGroup、runAsUser、または fsGroup パラメーターが nil の場合、メッシュ内をスコープとする namespace に新しい Pod をデプロイするオペレータでエラーが発生しました。nil 値を回避するために yaml 検証が追加されました。
• OSSM-3771 以前は、Service Mesh Control Plane (SMCP) で定義された追加の Ingress ゲートウェイに対して OpenShift ルートを無効にすることができませんでした。現在、routeConfig ブロックを追加の各 additionalIngress ゲートウェイに追加できるため、ゲートウェイごとに OpenShift ルートの作成を有効または無効にできます。

• OSSM-4197 では、ServiceMeshControlPlane リソースの v2.2 または v2.1 をデプロイしても、/etc/cni/multus/net.d/ ディレクトリーは作成されませんでした。その結果、istio-cni Pod の準備ができず、istio-cni Pod のログに次のメッセージが含まれていました。

  $ error   Installer exits with open /host/etc/cni/multus/net.d/v2-2-istio-cni.kubeconfig.tmp.841118073: no such file or directory

  ここで、ServiceMeshControlPlane リソースの v2.2 または v2.1 をデプロイすると、/etc/cni/multus/net.d/ ディレクトリーが作成され、istio-cni Pod の準備が整います。

• OSSM-3993 以前は、Kiali は標準 HTTPS ポート 443 上のプロキシー経由の OpenShift OAuth のみをサポートしていました。現在、Kiali は非標準の HTTPS ポートを介した OpenShift OAuth をサポートします。ポートを有効にするには、Kiali CR で spec.server.web_port フィールドをプロキシーの非標準 HTTPS ポートに設定する必要があります。
• OSSM-3936 以前は、injection_label_rev および injection_label_name 属性の値がハードコーディングされていました。これにより、カスタム設定が Kiali カスタムリソース定義 (CRD) で有効になりませんでした。今回のリリースより、属性値はハードコーディングされなくなりました。spec.istio_labels 仕様の injection_label_rev および injection_label_name 属性の値をカスタマイズできます。
• OSSM-3644 これまで、フェデレーション egress-gateway はネットワークゲートウェイエンドポイントの誤った更新を受信し、余分なエンドポイントエントリーが発生していました。これで、egress-gateway ゲートウェイはサーバー側で更新され、正しいネットワークゲートウェイエンドポイントを受信できるようになりました。
• OSSM-3595 これまでは、iptables-restore ユーティリティーが /tmp ディレクトリー内のファイルを開くことを SELinux が許可しなかったため、RHEL 上で istio-cni プラグインが失敗することがありました。SELinux は、ファイル経由ではなく stdin 入力ストリーム経由で iptables-restore を渡すようになりました。
• OSSM-3586 以前は、Google Cloud Platform (GCP) メタデータサーバーが利用できない場合に Istio プロキシーの起動が遅くなりました。Istio 1.14.6 にアップグレードすると、メタデータサーバーが利用できない場合でも、Istio プロキシーは GCP 上で期待どおりに起動します。
• OSSM-3025 Istiod が準備完了にならないことがあります。メッシュに多くのメンバーの namespace が含まれている場合は、Istiod 内のデッドロックが原因で Istiod Pod が準備完了にならないことがありました。デッドロックが解決され、Pod が期待どおりに起動するようになりました。
• OSSM-2493 SMCP のデフォルトの nodeSelector と tolerations が Kiali に渡されません。SMCP.spec.runtime.defaults に追加する nodeSelector と tolerations が Kiali リソースに渡されるようになりました。
• OSSM-2492 SMCP のデフォルトの Toleration が Jaeger に渡されません。SMCP.spec.runtime.defaults に追加する nodeSelector と tolerations が Jaeger リソースに渡されるようになりました。
• OSSM-2374 ServiceMeshMember リソースの 1 つを削除すると、Service Mesh Operator が ServiceMeshMemberRoll を削除しました。これは、最後の ServiceMeshMember を削除する際に期待される動作ですが、削除されたメンバーに加えて、メンバーが含まれている場合、Operator は ServiceMeshMemberRoll を削除しないようにする必要があります。この問題は修正され、Operator は最後の ServiceMeshMember リソースが削除された場合のみ、ServiceMeshMemberRoll を削除するようになりました。

• OSSM-2373 ログイン時に OAuth メタデータを取得しようとして、エラーが発生しました。クラスターのバージョンを取得するには、system:anonymous アカウントが使用されます。クラスターのデフォルトのバンドルされた ClusterRole と ClusterRoleBinding を使用すると、匿名アカウントはバージョンを正しく取得できます。system:anonymous アカウントがクラスターバージョンを取得する権限を失うと、OpenShift 認証は使用できなくなります。

  これは、Kiali SA を使用して、クラスターのバージョンを取得することで修正されます。これにより、クラスターのセキュリティーも向上します。

• OSSM-2371 Kiali が view-only として設定されているにもかかわらず、ユーザーはワークロードの詳細の Logs タブの kebab メニューからプロキシーログレベルを変更できます。この問題は修正されており、Kiali が view-only として設定されている場合は、Set Proxy Log Level の下のオプションが無効になります。
• OSSM-2344 Istiod を再起動すると、Kiali によって CRI-O がポート転送リクエストでいっぱいになります。この問題は、Kiali が Istiod に接続できず、Kiali が同時に大量のリクエストを istiod に発行したときに発生しました。Kiali が istiod に送信するリクエストの数が制限されるようになりました。
• OSSM-2335 Traces の散布図のプロット上でマウスポインターをドラッグすると、同時バックエンドリクエストが原因で Kiali コンソールが応答を停止する場合がありました。

• OSSM-2221 以前は、デフォルトで ignore-namespace ラベルが名前空間に適用されていたため、ServiceMeshControlPlane 名前空間へのゲートウェイインジェクションはできませんでした。

  v2.4 コントロールプレーンを作成すると、名前空間に ignore-namespace ラベルが適用されなくなり、ゲートウェイインジェクションが可能になります。

  以下の例では、oc label コマンドは既存のデプロイメントの namespace から ignore-namespace ラベルを削除します。

  $ oc label namespace <istio_system> maistra.io/ignore-namespace-

  上の例では、<istio_system> は ServiceMeshControlPlane namespace の名前を表します。

• 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-1962 フェデレーションコントローラーで EndpointSlices を使用します。フェデレーションコントローラーが EndpointSlices を使用するようになりました。これにより、大規模なデプロイメントでのスケーラビリティとパフォーマンスが向上します。PILOT_USE_ENDPOINT_SLICE フラグはデフォルトで有効になっています。フラグを無効にすると、フェデレーションデプロイメントを使用できなくなります。
• 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 フェイルオーバー用のフェデレーション Service Mesh の設定が想定どおりに機能しません。

  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-535 SMCP での validationMessages のサポート。Service Mesh コントロールプレーンの ValidationMessages フィールドを True に設定できるようになりました。これにより、問題のトラブルシューティングに役立つ、リソースのステータスのログが書き込まれます。
• 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] 非推奨の '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] lds.proto ファイルから非推奨の 'envoy.api.v2.Listener.use_original_dst' オプションを使用。この設定はまもなく 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 コンテンツを直接編集するか、トグルコントロールをクリックせずにコマンドラインからリソースを更新します。

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

• Red Hat Service Mesh (Istio): Istio は Kiali の要件です。Istio は Service Mesh を提供し、制御するコンポーネントです。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 インストールの一部として分散トレースプラットフォーム (Jaeger) をインストールすると、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)。これは、オープンソースの Jaeger プロジェクト に基づいています。
• Red Hat OpenShift 分散トレーシングプラットフォーム (Tempo)。オープンソースの Grafana Tempo プロジェクト に基づいています。
• Red Hat build of OpenTelemetry。オープンソースの OpenTelemetry プロジェクト に基づいています。

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

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

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

  • Gateway: ゲートウェイは、認証、認可、およびディストリビューターまたはクエリーフロントエンドサービスへのリクエストの転送を処理します。
  • Distributor: ディストリビューターは、Jaeger、OpenTelemetry、Zipkin などの複数の形式のスパンを受け入れます。トレース ID をハッシュし、分散一貫性のあるハッシュリングを使用して、スパンを Ingesters にルーティングします。
  • Ingester: Ingester はトレースをブロックにバッチ化し、ブルームフィルターとインデックスを作成してすべてバックエンドにフラッシュします。
  • Query Frontend: Query Frontend は、受信クエリーの検索スペースをシャーディングします。次に、検索クエリーが Querier に送信されます。Query Frontend のデプロイメントでは、Tempo Query サイドカーを介して Jaeger UI が公開されます。
  • Querier: Querier は、Ingester またはバックエンドストレージで要求されたトレース ID を検索します。パラメーターに応じて、Ingester にクエリーを実行し、バックエンドから Bloom インデックスを取得して、オブジェクトストレージ内のブロックを検索できます。
  • Compactor: Compactor は、ブロックをバックエンドストレージとの間でストリーミングして、ブロックの総数を減らします。

• Red Hat build of OpenTelemetry - このコンポーネントは、オープンソースの 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.10 以降
• 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 で使用できます。
• 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 でのみ利用できます。

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

• Kiali コンソールは、Google Chrome、Microsoft Edge、Mozilla Firefox、または Apple Safari ブラウザーの最新の 2 つのリリースでのみサポートされています。
• OpenShift 認証ストラテジーは、Kiali が Red Hat OpenShift Service Mesh (OSSM) とともにデプロイされている場合にサポートされる唯一の認証設定です。openshift ストラテジーは、OpenShift Container Platform の個人のロールベースのアクセス制御 (RBAC) ロールに基づいてアクセスを制御します。

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

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

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされている必要がある。
• cluster-admin ロールを持つアカウントがある。

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされている必要がある。
• OpenShift CLI (oc) へのアクセスがある。

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされています。
• cluster-admin ロールを持つユーザーとしてログインしています。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin ロールを持つユーザーとしてログインします。

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされています。
• cluster-admin ロールを持つユーザーとしてログインしています。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin ロールを持つユーザーとしてログインします。

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされています。
• cluster-admin ロールを持つユーザーとしてログインしています。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin ロールを持つユーザーとしてログインします。

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされています。
• cluster-admin ロールを持つユーザーとしてログインしています。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin ロールを持つユーザーとしてログインします。

手順

• Istiod、Ingress Gateway、Egress Gateway Pod に関連付けられたノードがインフラストラクチャーノードであることを確認します。

  $ oc -n istio-system get pods -owide

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされています。
• cluster-admin ロールを持つアカウントを使用してログインしているか、Red Hat OpenShift Dedicated を dedicated-admin ロールを持つアカウントを使用してログインしています。

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされています。
• OpenShift CLI (oc) にアクセスできる。

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

前提条件

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

前提条件

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

前提条件

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

前提条件

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

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされています。
• ServiceMeshControlPlane リソースの名前と、リソースが属するプロジェクトの名前はわかっています。
• メッシュに追加するプロジェクトの名前はわかっています。
• Service Mesh 管理者は、Service Mesh へのアクセスを明示的に付与する必要があります。管理者は、RoleBinding または ClusterRoleBinding を使用して mesh-user ロール をユーザーに割り当てて、メッシュにアクセスする権限を付与できます。詳細は、Red Hat OpenShift Service Mesh メンバーの作成 を参照してください。

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされています。
• ServiceMeshControlPlane リソースの名前と、それが属するプロジェクトの名前はわかっています。
• メッシュに追加するプロジェクトの名前はわかっています。
• Service Mesh 管理者は、Service Mesh へのアクセスを明示的に付与する必要があります。管理者は、RoleBinding または ClusterRoleBinding を使用して mesh-user ロール をユーザーに割り当てて、メッシュにアクセスする権限を付与できます。詳細は、Red Hat OpenShift Service Mesh メンバーの作成 を参照してください。

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされています。
• デプロイメントには既存の ServiceMeshMemberRoll リソースがあります。
• cluster-admin ロールを持つユーザーとしてログインしています。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin ロールを持つユーザーとしてログインします。

前提条件

• Red Hat OpenShift Service Mesh Operator がインストールされています。
• デプロイメントには既存の ServiceMeshMemberRoll リソースがあります。
• cluster-admin ロールを持つユーザーとしてログインしています。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin ロールを持つユーザーとしてログインします。

前提条件:

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

前提条件

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

前提条件

• OpenShift Container Platform 4.1 以降がインストールされている。
• Red Hat OpenShift Service Mesh 2.4.5 がインストールされている。
• 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.4.5 です。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 の値を設定します。

• Operator をアップグレードする際に、Jaeger または Kiali のカスタム設定が元に戻される可能性があります。Operator をアップグレードする前に、Service Mesh の実稼働環境用デプロイメント内にある Jaeger オブジェクトまたは Kiali オブジェクトのカスタム設定をメモし、再作成できるようにしてください。
• 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 OpenShift Routing (IOR) のサポートは非推奨になりました。IOR 機能は引き続き有効ですが、将来のリリースでは削除される予定です。

• 次の暗号スイートはサポートされなくなり、クライアント側とサーバー側の TLS ネゴシエーションで使用される暗号のリストから削除されました。

  • ECDHE-ECDSA-AES128-SHA
  • ECDHE-RSA-AES128-SHA
  • AES128-GCM-SHA256
  • AES128-SHA
  • ECDHE-ECDSA-AES256-SHA
  • ECDHE-RSA-AES256-SHA
  • AES256-GCM-SHA384

  • AES256-SHA

    これらの暗号スイートのいずれかを使用するサービスにアクセスする必要があるアプリケーションは、プロキシーが TLS 接続を開始すると接続に失敗します。

• このリリースでは、WasmPlugin API を使用する必要があります。2.2 で非推奨化された ServiceMeshExtension API のサポートが廃止されました。ServiceMeshExtension API の使用中にアップグレードを試みると、アップグレードは失敗します。

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

動作上の変更

• 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 デプロイメントの場所。
• OpenShift CLI (oc) へのアクセスがある。

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