第2章 Service Mesh 1.x

2.1. Service Mesh リリースノート

警告

こちらは、サポートされなくなった Red Hat OpenShift Service Mesh リリースのドキュメントです。

Service Mesh バージョン 1.0 および 1.1 コントロールプレーンはサポートされなくなりました。Service Mesh コントロールプレーンのアップグレードについては、Service Mesh の アップグレード を参照してください。

特定の Red Hat Service Mesh リリースのサポートステータスについては、製品ライフサイクルページ を参照してください。

2.1.1. 多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。

2.1.2. Red Hat OpenShift Service Mesh の概要

Red Hat OpenShift Service Mesh は、アプリケーションで一元化された制御ポイントを作成して、マイクロサービスアーキテクチャーのさまざまな問題に対応します。OpenShift Service Mesh はアプリケーションコードを変更せずに、既存の分散アプリケーションに透過的な層を追加します。

マイクロサービスアーキテクチャーは、エンタープライズアプリケーションの作業をモジュールサービスに分割するので、スケーリングとメンテナーンスが容易になります。ただし、マイクロサービスアーキテクチャー上に構築されるエンタープライズアプリケーションはサイズも複雑性も増すため、マイクロサービスアーキテクチャーの理解と管理は困難です。Service Mesh は、サービス間のトラフィックをキャプチャーしたり、インターセプトしたりして、他のサービスへの新規要求を変更、リダイレクト、または作成することによってこれらのアーキテクチャーの問題に対応できます。

オープンソースの Istio project をベースにする Service Mesh では、検出、負荷分散、サービス間の認証、障害復旧、メトリクス、およびモニタリングを提供する、デプロイされたサービスのネットワークを簡単に作成できます。サービスメッシュは、A/B テスト、カナリアリリース、レート制限、アクセス制御、エンドツーエンド認証を含む、より複雑な運用機能を提供します。

2.1.3. サポート

本書で説明されている手順、または OpenShift Container Platform で問題が発生した場合は、Red Hat カスタマーポータル にアクセスしてください。カスタマーポータルでは、次のことができます。

  • Red Hat 製品に関するアーティクルおよびソリューションについての Red Hat ナレッジベースの検索またはブラウズ。
  • Red Hat サポートに対するサポートケースの送信。
  • その他の製品ドキュメントへのアクセス。

クラスターの問題を特定するには、OpenShift Cluster Manager で Insights を使用できます。Insights により、問題の詳細と、利用可能な場合は問題の解決方法に関する情報が提供されます。

本書の改善への提案がある場合、またはエラーを見つけた場合は、最も関連性の高いドキュメントコンポーネントの Jira Issue を送信してください。セクション名や OpenShift Container Platform バージョンなどの具体的な情報を提供してください。

サポートケースを作成する際、ご使用のクラスターについてのデバッグ情報を Red Hat サポートに提供していただくと Red Hat のサポートに役立ちます。

must-gather ツールを使用すると、仮想マシンおよび Red Hat OpenShift Service Mesh に関する他のデータを含む、OpenShift Container Platform クラスターについての診断情報を収集できます。

迅速なサポートを得るには、OpenShift Container Platform と Red Hat OpenShift Service Mesh の両方の診断情報を提供してください。

2.1.3.1. must-gather ツールについて

oc adm must-gather CLI コマンドは、以下のような問題のデバッグに必要となる可能性のあるクラスターからの情報を収集します。

  • リソース定義
  • サービスログ

デフォルトで、oc adm must-gather コマンドはデフォルトのプラグインイメージを使用し、./must-gather.local に書き込みを行います。

または、以下のセクションで説明されているように、適切な引数を指定してコマンドを実行すると、特定の情報を収集できます。

  • 1 つ以上の特定の機能に関連するデータを収集するには、以下のセクションに示すように、イメージと共に --image 引数を使用します。

    以下に例を示します。

    $ oc adm must-gather  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.9.0
  • 監査ログを収集するには、以下のセクションで説明されているように -- /usr/bin/gather_audit_logs 引数を使用します。

    以下に例を示します。

    $ oc adm must-gather -- /usr/bin/gather_audit_logs
    注記

    ファイルのサイズを小さくするために、監査ログはデフォルトの情報セットの一部として収集されません。

oc adm must-gather を実行すると、ランダムな名前を持つ新規 Pod がクラスターの新規プロジェクトに作成されます。データは Pod で収集され、must-gather.local で始まる新規ディレクトリーに保存されます。このディレクトリーは、現行の作業ディレクトリーに作成されます。

以下に例を示します。

NAMESPACE                      NAME                 READY   STATUS      RESTARTS      AGE
...
openshift-must-gather-5drcj    must-gather-bklx4    2/2     Running     0             72s
openshift-must-gather-5drcj    must-gather-s8sdh    2/2     Running     0             72s
...

2.1.3.2. 前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift Container Platform CLI (oc) がインストールされていること。

2.1.3.3. サービスメッシュデータの収集について

oc adm must-gather CLI コマンドを使用してクラスターについての情報を収集できます。これには、Red Hat OpenShift Service Mesh に関連する機能およびオブジェクトが含まれます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift Container Platform CLI (oc) がインストールされていること。

手順

  1. must-gather で Red Hat OpenShift Service Mesh データを収集するには、Red Hat OpenShift Service Mesh イメージを指定する必要があります。

    $ oc adm must-gather --image=registry.redhat.io/openshift-service-mesh/istio-must-gather-rhel8
  2. must-gather で特定の Service Mesh コントロールプレーン namespace の Red Hat OpenShift Service Mesh データを収集するには、Red Hat OpenShift Service Mesh イメージおよび namespace を指定する必要があります。この例では、<namespace>istio-system などの Service Mesh コントロールプレーンの namespace に置き換えます。

    $ oc adm must-gather --image=registry.redhat.io/openshift-service-mesh/istio-must-gather-rhel8 gather <namespace>

2.1.4. Red Hat OpenShift Service Mesh でサポートされている設定

以下は、Red Hat OpenShift Service Mesh で唯一サポートされている設定です。

  • OpenShift Container Platform バージョン 4.6 以降。
注記

OpenShift Online および Red Hat OpenShift Dedicated は Red Hat OpenShift Service Mesh に対してはサポートされていません。

  • デプロイメントは、フェデレーションされていない単一の OpenShift Container Platform クラスターに含まれる必要があります。
  • Red Hat OpenShift Service Mesh の本リリースは、OpenShift Container Platform x86_64 でのみ利用できます。
  • 本リリースでは、すべての Service Mesh コンポーネントが OpenShift Container Platform クラスターに含まれ、動作している設定のみをサポートしています。クラスター外にあるマイクロサービスの管理や、マルチクラスターシナリオにおけるマイクロサービスの管理はサポートしていません。
  • 本リリースでは、仮想マシンなどの外部サービスを統合していない設定のみをサポートしています。

Red Hat OpenShift Service Mesh のライフサイクルおよびサポートされる設定についての詳細は、サポートポリシー について参照してください。

2.1.4.1. Red Hat OpenShift Service Mesh でサポートされている Kiali の設定

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

2.1.4.2. サポートされている Mixer アダプター

  • 本リリースでは、次の Mixer アダプターのみをサポートしています。

    • 3scale Istio Adapter

2.1.5. 新機能

Red Hat OpenShift Service Mesh は、サービスのネットワーク全体で多数の主要機能を均一に提供します。

  • トラフィック管理: サービス間でトラフィックおよび API 呼び出しのフローを制御し、呼び出しの安定度を高め、不利な条件下でもネットワークの堅牢性を維持します。
  • サービス ID とセキュリティー: メッシュのサービスを検証可能な ID で指定でき、サービスのトラフィックがさまざまな信頼度のネットワークに送られる際にそのトラフィックを保護する機能を提供します。
  • ポリシーの適用: サービス間の対話に組織のポリシーを適用し、アクセスポリシーが適用され、リソースはコンシューマー間で均等に分散されるようにします。ポリシー変更は、アプリケーションコードを変更するのではなく、メッシュを設定して行います。
  • Telemetry: サービス間の依存関係やそれらの間のトラフィックの性質やフローを理解するのに役立ち、問題を素早く特定できます。

2.1.5.1. Red Hat OpenShift Service Mesh 1.1.18.2 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) に対応しています。

2.1.5.1.1. Red Hat OpenShift Service Mesh バージョン 1.1.18.2 に含まれるコンポーネントのバージョン
コンポーネントバージョン

Istio

1.4.10

Jaeger

1.30.2

Kiali

1.12.21.1

3scale Istio Adapter

1.0.0

2.1.5.2. Red Hat OpenShift Service Mesh 1.1.18.1 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) に対応しています。

2.1.5.2.1. Red Hat OpenShift Service Mesh バージョン 1.1.18.1 に含まれるコンポーネントのバージョン
コンポーネントバージョン

Istio

1.4.10

Jaeger

1.30.2

Kiali

1.12.20.1

3scale Istio Adapter

1.0.0

2.1.5.3. Red Hat OpenShift Service Mesh 1.1.18 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) に対応しています。

2.1.5.3.1. Red Hat OpenShift Service Mesh バージョン 1.1.18 に含まれるコンポーネントのバージョン
コンポーネントバージョン

Istio

1.4.10

Jaeger

1.24.0

Kiali

1.12.18

3scale Istio Adapter

1.0.0

2.1.5.4. Red Hat OpenShift Service Mesh 1.1.17.1 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) に対応しています。

2.1.5.4.1. Red Hat OpenShift Service Mesh が URI フラグメントを処理する方法の変更

Red Hat OpenShift Service Mesh には、リモートで悪用可能な脆弱性 CVE-2021-39156 が含まれており、URI パスにフラグメント (URI の末尾が # 文字で始まるセクション) を含む HTTP リクエストが Istio URI パスベースの認証ポリシーを無視する可能性があります。たとえば、Istio 認証ポリシーは URI パス /user/profile に送信される要求を拒否します。脆弱なバージョンでは、URI パス /user/profile#section1 のリクエストは、deny ポリシーと、(正規化された URI path /user/profile%23section1 を使用する) バックエンドへのルートを無視するため、セキュリティーのインシデントにつながる可能性があります。

DENY アクションおよび operation.paths、または ALLOW アクションおよび operation.notPaths で認可ポリシーを使用する場合は、この脆弱性の影響を受けます。

軽減策により、リクエストの URI の断片部分が、承認とルーティングの前に削除されます。これにより、URI のフラグメントを持つ要求が、フラグメントの一部のない URI をベースとする承認ポリシーが無視できなくなります。

2.1.5.4.2. 認証ポリシーに必要な更新

Istio はホスト名自体とすべての一致するポートの両方にホスト名を生成します。たとえば、httpbin.foo のホストの仮想サービスまたはゲートウェイは、httpbin.foo and httpbin.foo:*に一致する設定を生成します。ただし、完全一致許可ポリシーは、hosts または notHosts フィールドに指定された完全一致文字列にのみ一致します。

ルールの正確な文字列比較を使用して hosts または notHosts を決定する AuthorizationPolicy リソースがある場合、クラスターは影響を受けます。

完全一致ではなく接頭辞一致を使用するように、認証ポリシー ルール を更新する必要があります。たとえば、最初の AuthorizationPolicy の例で hosts: ["httpbin.com"]hosts: ["httpbin.com:*"] に置き換えます。

接頭辞一致を使用した最初の AuthorizationPolicy の例

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        namespaces: ["dev"]
    to:
    - operation:
        hosts: [“httpbin.com”,"httpbin.com:*"]

接頭辞一致を使用した 2 つ目の AuthorizationPolicy の例

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: default
spec:
  action: DENY
  rules:
  - to:
    - operation:
        hosts: ["httpbin.example.com:*"]

2.1.5.5. Red Hat OpenShift Service Mesh 1.1.17 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

2.1.5.6. Red Hat OpenShift Service Mesh 1.1.16 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

2.1.5.7. Red Hat OpenShift Service Mesh 1.1.15 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

2.1.5.8. Red Hat OpenShift Service Mesh 1.1.14 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

重要

CVE-2021-29492 および CVE-2021-31920 に対応するために、手動による手順を完了する必要があります。

2.1.5.8.1. CVE-2021-29492 および CVE-2021-31920 で必要な手動による更新

Istio にはリモートで悪用可能な脆弱性があり、複数のスラッシュまたはエスケープされたスラッシュ文字 (%2F` または %5C`) を持つ HTTP リクエストパスが、パスベースの認証ルールが使用される場合に Istio 認証ポリシーを無視する可能性があります。

たとえば、Istio クラスター管理者が、パス /admin での要求を拒否する認証 DENY ポリシーを定義すると仮定します。URL パス //admin に送信される要求は、認証ポリシーによって拒否されません。

RFC 3986 に応じて、複数のスラッシュを持つパス //admin は、/admin とは異なるパスとして処理される必要があります。ただし、一部のバックエンドサービスは、複数のスラッシュを単一のスラッシュにマージして URL パスを正規化することを選択します。これにより、認証ポリシーがバイパスされ (//admin/admin に一致しません)、ユーザーはバックエンドのパス (/admin) でリソースにアクセスできます。これにより、セキュリティーのインシデントを示されます。

ALLOW action + notPaths フィールドまたは DENY action + paths field パターンを使用する認証ポリシーがある場合、クラスターはこの脆弱性の影響を受けます。これらのパターンは、予期しないポリシーのバイパスに対して脆弱です。

以下の場合、クラスターはこの脆弱性の影響を受けません。

  • 認証ポリシーがありません。
  • 認証ポリシーは、paths または notPaths フィールドを定義しません。
  • 認証ポリシーは、ALLOW action + paths フィールドまたは DENY action + notPaths フィールドのパターンを使用します。これらのパターンは、ポリシーのバイパスではなく、予期しない拒否を生じさせる可能性があります。このような場合、アップグレードは任意です。
注記

パスの正規化向けの Red Hat OpenShift Service Mesh 設定の場所は、Istio 設定とは異なります。

2.1.5.8.2. パスの正規化設定の更新

Istio 認証ポリシーは、HTTP リクエストの URL パスをベースとする場合があります。URI の正規化として知られる パスの正規化 は、正規化されたパスを標準の方法で処理できるように、受信要求のパスを変更し、標準化します。構文の異なるパスは、パスの正規化後と同一になる場合があります。

Istio は、認証ポリシーに対して評価し、要求をルーティングする前の、要求パスでの以下の正規化スキームをサポートします。

表2.1 正規化スキーム

オプション説明注記

NONE

正規化は行われません。Envoy が受信する内容はそのまますべて、どのバックエンドサービスにも完全に転送されます。

../%2fa../b は認証ポリシーによって評価され、サービスに送信されます。

この設定は CVE-2021-31920 に対して脆弱です。

BASE

現時点で、これは Istio の デフォルト インストールで使用されるオプションです。これにより、Envoy プロキシーで normalize_path オプションが適用されます。これは、追加の正規化において RFC 3986 に従い、バックスラッシュをフォワードスラッシュに変換します。

/a/../b/b に正規化されます。\da/da に正規化されます。

この設定は CVE-2021-31920 に対して脆弱です。

MERGE_SLASHES

スラッシュは BASE の正規化後にマージされます。

/a//b/a/b に正規化されます。

この設定に対して更新を行い、CVE-2021-31920 のリスクを軽減します。

DECODE_AND_MERGE_SLASHES

デフォルトですべてのトラフィックを許可する場合の最も厳密な設定です。この設定の場合、認証ポリシーのルートを詳細にテストする必要がある点に注意してください。パーセントでエンコードされた スラッシュおよびバックスラッシュ文字 (%2F%2f%5C および %5c) は、MERGE_SLASHES の正規化の前に / または \ にデコードされます。

/a%2fb/a/b に正規化されます。

この設定に対して更新を行い、CVE-2021-31920 のリスクを軽減します。この設定はより安全ですが、アプリケーションが破損する可能性があります。実稼働環境にデプロイする前にアプリケーションをテストします。

正規化アルゴリズムは以下の順序で実行されます。

  1. パーセントでデコードされた %2F%2f%5C および %5c
  2. Envoy の normalize_path オプションで実装された RFC 3986 およびその他の正規化。
  3. スラッシュをマージします。
警告

これらの正規化オプションは HTTP 標準および一般的な業界プラクティスの推奨事項を表しますが、アプリケーションは独自に選択したいずれかの方法で URL を解釈する場合があります。拒否ポリシーを使用する場合には、アプリケーションの動作を把握している必要があります。

2.1.5.8.3. パスの正規化設定の例

Envoy がバックエンドサービスの期待値に一致するように要求パスを正規化することは、システムのセキュリティーを保護する上で非常に重要です。以下の例は、システムを設定するための参考として使用できます。正規化された URL パス、または NONE が選択されている場合は元の URL パスは以下のようになります。

  1. 認証ポリシーの確認に使用されます。
  2. バックエンドアプリケーションに転送されます。

表2.2 設定例

アプリケーションの条件選択内容

プロキシーを使用して正規化を行う。

BASEMERGE_SLASHES、または DECODE_AND_MERGE_SLASHES

RFC 3986 に基づいて要求パスを正規化し、スラッシュをマージしない。

BASE

RFC 3986 に基づいて要求パスを正規化し、スラッシュをマージするが、パーセントでエンコードされた スラッシュをデコードしない。

MERGE_SLASHES

RFC 3986 に基づいて要求パスを正規化し、パーセントでエンコードされた スラッシュをデコードし、スラッシュをマージする。

DECODE_AND_MERGE_SLASHES

RFC 3986 と互換性のない方法で要求パスを処理する。

NONE

2.1.5.8.4. パスを正規化するための SMCP の設定

Red Hat OpenShift Service Mesh のパスの正規化を設定するには、ServiceMeshControlPlane で以下を指定します。設定例を使用すると、システムの設定を判断するのに役立ちます。

SMCP v1 pathNormalization

spec:
  global:
    pathNormalization: <option>

2.1.5.9. Red Hat OpenShift Service Mesh 1.1.13 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

2.1.5.10. Red Hat OpenShift Service Mesh 1.1.12 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

2.1.5.11. Red Hat OpenShift Service Mesh 1.1.11 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

2.1.5.12. Red Hat OpenShift Service Mesh 1.1.10 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

2.1.5.13. Red Hat OpenShift Service Mesh 1.1.9 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

2.1.5.14. Red Hat OpenShift Service Mesh 1.1.8 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

2.1.5.15. Red Hat OpenShift Service Mesh 1.1.7 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

2.1.5.16. Red Hat OpenShift Service Mesh 1.1.6 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

2.1.5.17. Red Hat OpenShift Service Mesh 1.1.5 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

本リリースでは、暗号化スイートの設定に対するサポートも追加しています。

2.1.5.18. Red Hat OpenShift Service Mesh 1.1.4 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

注記

CVE-2020-8663 に対応するために、手動による手順を完了する必要があります。

2.1.5.18.1. CVE-2020-8663 で必要な手動による更新

CVE-2020-8663 の修正:envoy: Resource exhaustion when accepting too many connections により、ダウンストリーム接続に設定可能な制限が追加されました。この制限の設定オプションは、この脆弱性を軽減するように設定する必要があります。

重要

1.1 バージョンまたは 1.0 バージョンの Red Hat OpenShift Service Mesh を使用しているかどうかに関係なく、この CVE に対応するには、これらの手動の手順が必要です。

この新しい設定オプションは overload.global_downstream_max_connections と呼ばれ、プロキシーの runtime 設定として設定できます。Ingress ゲートウェイで制限を設定するには、以下の手順を実行します。

手順

  1. 以下のテキストで bootstrap-override.json という名前のファイルを作成し、プロキシーがブートストラップテンプレートを上書きし、ディスクからランタイム設定を読み込むように強制します。

      {
        "runtime": {
          "symlink_root": "/var/lib/istio/envoy/runtime"
        }
      }
  2. bootstrap-override.json ファイルからシークレットを作成し、<SMCPnamespace> を、サービスメッシュコントロールプレーン (SMCP) を作成した namespace に置き換えます。

    $  oc create secret generic -n <SMCPnamespace> gateway-bootstrap --from-file=bootstrap-override.json
  3. SMCP 設定を更新して上書きを有効にします。

    更新された SMCP 設定例 #1

    apiVersion: maistra.io/v1
    kind: ServiceMeshControlPlane
    spec:
      istio:
        gateways:
          istio-ingressgateway:
            env:
              ISTIO_BOOTSTRAP_OVERRIDE: /var/lib/istio/envoy/custom-bootstrap/bootstrap-override.json
            secretVolumes:
            - mountPath: /var/lib/istio/envoy/custom-bootstrap
              name: custom-bootstrap
              secretName: gateway-bootstrap

  4. 新規設定オプションを設定するには、overload.global_downstream_max_connections 設定の必要な値を持つシークレットを作成します。以下の例では、10000 の値を使用します。

    $  oc create secret generic -n <SMCPnamespace> gateway-settings --from-literal=overload.global_downstream_max_connections=10000
  5. SMCP を再度更新して、Envoy がランタイム設定を検索する場所にシークレットをマウントします。

更新された SMCP 設定例 #2

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  template: default
#Change the version to "v1.0" if you are on the 1.0 stream.
  version: v1.1
  istio:
    gateways:
      istio-ingressgateway:
        env:
          ISTIO_BOOTSTRAP_OVERRIDE: /var/lib/istio/envoy/custom-bootstrap/bootstrap-override.json
        secretVolumes:
        - mountPath: /var/lib/istio/envoy/custom-bootstrap
          name: custom-bootstrap
          secretName: gateway-bootstrap
        # below is the new secret mount
        - mountPath: /var/lib/istio/envoy/runtime
          name: gateway-settings
          secretName: gateway-settings

2.1.5.18.2. Elasticsearch 5 から Elasticsearch 6 へのアップグレード

Elasticsearch 5 から Elasticsearch 6 に更新する場合、証明書に関する問題があるために Jaeger インスタンスを削除してから Jaeger インスタンスを再作成する必要があります。Jaeger インスタンスを再作成すると、証明書の新たなセットの作成がトリガーされます。永続ストレージを使用している場合、新規の Jaeger インスタンスの Jaeger 名および namespace が削除された Jaeger インスタンスと同じである限り、新規の Jaeger インスタンスについて同じボリュームをマウントできます。

Jaeger が Red Hat Service Mesh の一部としてインストールされている場合の手順

  1. Jaeger カスタムリソースファイルの名前を判別します。

    $ oc get jaeger -n istio-system

    以下のような出力が表示されます。

    NAME     AGE
    jaeger   3d21h
  2. 生成されたカスタムリソースファイルを一時ディレクトリーにコピーします。

    $ oc get jaeger jaeger -oyaml -n istio-system > /tmp/jaeger-cr.yaml
  3. Jaeger インスタンスを削除します。

    $ oc delete jaeger jaeger -n istio-system
  4. カスタムリソースファイルのコピーから Jaeger インスタンスを再作成します。

    $ oc create -f /tmp/jaeger-cr.yaml -n istio-system
  5. 生成されたカスタムリソースファイルのコピーを削除します。

    $ rm /tmp/jaeger-cr.yaml

Jaeger が Red Hat Service Mesh の一部としてインストールされていない場合の手順

開始する前に、Jaeger カスタムリソースファイルのコピーを作成します。

  1. カスタムリソースファイルを削除して Jaeger インスタンスを削除します。

    $ oc delete -f <jaeger-cr-file>

    以下に例を示します。

    $ oc delete -f jaeger-prod-elasticsearch.yaml
  2. カスタムリソースファイルのバックアップコピーから Jaeger インスタンスを再作成します。

    $ oc create -f <jaeger-cr-file>
  3. Pod が再起動したことを確認します。

    $ oc get pods -n jaeger-system -w

2.1.5.19. Red Hat OpenShift Service Mesh 1.1.3 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

2.1.5.20. Red Hat OpenShift Service Mesh 1.1.2 の新機能

Red Hat OpenShift Service Mesh の本リリースは、セキュリティー脆弱性に対応しています。

2.1.5.21. Red Hat OpenShift Service Mesh 1.1.1 の新機能

Red Hat OpenShift Service Mesh のリリースでは、非接続インストールのサポートが追加されました。

2.1.5.22. Red Hat OpenShift Service Mesh 1.1.0 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、1.4.6 および Jaeger 1.17.1 のサポートが追加されました。

2.1.5.22.1. 1.0 から 1.1 への手動更新

Red Hat OpenShift Service Mesh 1.0 から 1.1 に更新する場合、ServiceMeshControlPlane リソースを更新してコントロールプレーンのコンポーネントを新規バージョンに更新する必要があります。

  1. Web コンソールで、Red Hat OpenShift Service Mesh Operator をクリックします。
  2. Project メニューをクリックし、一覧から ServiceMeshControlPlane がデプロイされているプロジェクト (例: istio-system) を選択します。
  3. コントロールプレーンの名前 (basic-install など) をクリックします。
  4. YAML をクリックし、バージョンフィールドを ServiceMeshControlPlane リソースの spec: に追加します。たとえば、Red Hat OpenShift Service Mesh 1.1.0 に更新するには、version: v1.1 を追加します。
spec:
  version: v1.1
  ...

バージョンフィールドでは、インストールする ServiceMesh のバージョンを指定し、デフォルトは利用可能な最新バージョンに設定されます。

注記

Red Hat OpenShift Service Mesh v1.0 のサポートは 2020 年 10 月に終了していることに注意してください。v1.1 または v2.0 のいずれかにアップグレードする必要があります。

2.1.6. 非推奨の機能

以前のリリースで利用可能であった一部の機能が非推奨になるか、または削除されました。

非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。

2.1.6.1. 非推奨になった Red Hat OpenShift Service Mesh 1.1.5 の機能

以下のカスタムリソースはリリース 1.1.5 で非推奨となり、リリース 1.1.12 で削除されました。

  • Policy: Policy リソースは非推奨となり、今後のリリースで PeerAuthentication リソースに置き換えられます。
  • MeshPolicy: MeshPolicy リソースは非推奨となり、今後のリリースで PeerAuthentication リソースに置き換えられます。
  • v1alpha1 RBAC API: v1alpha1 RBAC ポリシーは v1beta1 AuthorizationPolicy で非推奨にされています。RBAC (ロールベースアクセス制御) は ServiceRole および ServiceRoleBinding オブジェクトを定義します。

    • ServiceRole
    • ServiceRoleBinding
  • RbacConfig: RbacConfig は、Istio RBAC 動作を制御するためにカスタムリソース定義を実装します。

    • ClusterRbacConfig (Red Hat OpenShift Service Mesh 1.0 より前のバージョン)
    • ServiceMeshRbacConfig (Red Hat OpenShift Service Mesh バージョン 1.0 以降)
  • Kiali では、login および LDAP ストラテジーは非推奨になりました。今後のバージョンでは、OpenID プロバイダーを使用した認証が導入されます。

以下のコンポーネントは本リリースで非推奨となり、今後のリリースで Istiod コンポーネントに置き換えられます。

  • Mixer: アクセス制御および使用ポリシー
  • Pilot: サービス検出およびプロキシー設定
  • Citadel: 証明書の生成
  • Galley: 設定の検証および分散

2.1.7. 既知の問題

Red Hat OpenShift Service Mesh には以下のような制限が存在します。

  • アップストリームの Istio プロジェクトでサポートされておらず、また OpenShift Container Platform でも完全にサポートされていないため、Red Hat OpenShift Service Mesh は IPv6 をサポートしていません
  • グラフレイアウト: Kiali グラフのレイアウトは、アプリケーションのアーキテクチャーや表示データ (グラフィックノードとその対話の数) によって異なることがあります。すべての状況に適した単一のレイアウトを作成することは不可能ではないにしても困難であるため、Kiali は複数の異なるレイアウトの選択肢を提供します。別のレイアウトを選択するには、Graph Settings メニューから異なる Layout Schema を選択します。
  • Kiali コンソールから Jaeger や Grafana などの関連サービスに初めてアクセスする場合、OpenShift Container Platform のログイン認証情報を使用して証明書を受け入れ、再認証する必要があります。これは、フレームワークが組み込まれたページをコンソールで表示する方法に問題があるために生じます。

2.1.7.1. Service Mesh の既知の問題

Red Hat OpenShift Service Mesh には次のような既知の問題が存在します。

  • Jaeger/Kiali Operator のアップグレードが Operator の保留によりブロックされる Jaeger または Kiali Operator を Service Mesh 1.0.x がインストールされた状態でアップグレードすると、Operator のステータスは Pending と表示されます。

    回避策: 詳細は、関連するナレッジベースの記事を参照してください。

  • Istio-14743 Red Hat OpenShift Service Mesh のこのリリースがベースとしている Istio のバージョンに制限があるため、現時点で Service Mesh と互換性のないアプリケーションが複数あります。詳細は、リンク先のコミュニティーの問題を参照してください。
  • 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 コントロールプレーンに多くの namespace がある場合に、パフォーマンスの問題が発生する可能性があります。
  • MAISTRA-465 Maistra Operator が、Operator メトリクスのサービスの作成に失敗します。
  • MAISTRA-453 新規プロジェクトを作成して Pod を即時にデプロイすると、サイドカーコンテナーの挿入は発生しません。この Operator は Pod の作成前に maistra.io/member-of を追加できないため、サイドカーコンテナーの挿入を発生させるには Pod を削除し、再作成する必要があります。
  • MAISTRA-158 同じホスト名を参照する複数のゲートウェイを適用すると、すべてのゲートウェイが機能しなくなります。

2.1.7.2. Kiali の既知の問題

注記

Kiali についての新たな問題は、ComponentKiali に設定された状態の OpenShift Service Mesh プロジェクトに作成される必要があります。

Kiali の既知の問題は以下のとおりです。

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

2.1.7.3. Red Hat OpenShift 分散トレースの既知の問題

Red Hat OpenShift 分散トレースには、以下の制限があります。

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

これらは Red Hat OpenShift 分散トレースの既知の問題です。

  • 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 のいずれかに切り替えます。

2.1.8. 修正された問題

次の問題は、現在のリリースで解決されています。

2.1.8.1. Service Mesh の修正された問題

  • MAISTRA-2371 は listerInformer で tombstones を処理します。更新されたキャッシュコードベースは、namespace キャッシュからのイベントを集約されたキャッシュに変換する際に tombstones を処理しないため、go ルーチンでパニックが生じました。
  • OSSM-542 Galley はローテーション後、新しい証明書を使用していません。
  • OSSM-99 ラベルを持たない直接の Pod から生成されたワークロードは Kiali をクラッシュさせる可能性があります。
  • OSSM-93 IstioConfigList は複数の名前でフィルターをかけることができません。
  • OSSM-92 VS/DR YAML 編集ページで未保存の変更をキャンセルしても、変更はキャンセルされません。
  • OSSM-90 サービスの詳細ページでは、トレースは利用できません。
  • MAISTRA-1649 ヘッドレス サービスは、異なる namespace にある場合に競合します。異なる namespace にヘッドレスサービスをデプロイする場合、エンドポイント設定はマージされ、無効な Envoy 設定がサイドカーコンテナーにプッシュされます。
  • MAISTRA-1541 コントローラーが所有者の参照に設定されていない場合に kubernetesenv でパニックが生じます。Pod にコントローラーを指定しない ownerReference がある場合は、kubernetesenv cache.go コード内でパニックが生じます。
  • 本リリースおよび今後のリリースでは、コントロールプレーンのインストールから MAISTRA-1352 Cert-manager カスタムリソース定義 (CRD) が削除されました。Red Hat OpenShift Service Mesh がすでにインストールされている場合、cert-manager が使用されていない場合には CRD を手動で削除する必要があります。
  • MAISTRA-1001 HTTP/2 接続を閉じると、istio-proxy でセグメント化の障害が生じる可能性があります。
  • MAISTRA-932 Jaeger Operator と OpenShift Elasticsearch Operator 間の依存関係を追加するために requires メタデータが追加されました。Jaeger Operator のインストール時に、これが利用不可能な場合は OpenShift Elasticsearch Operator を自動的にデプロイします。
  • MAISTRA-862 Galley は namespace が数多く削除および再作成されると、 watch (監視) をドロップし、他のコンポーネントへの設定の提供を停止しました。
  • MAISTRA-833 Pilot は namespace が数多く削除および再作成されると設定の配信を停止しました。
  • MAISTRA-684 istio-operator のデフォルトの Jaeger バージョンは 1.12.0 で、Red Hat OpenShift Service Mesh 0.12.TechPreview で提供される Jaeger バージョン 1.13.1 と一致しません。
  • MAISTRA-622 Maistra 0.12.0/TP12 では、パーミッシブモードは機能しません。ユーザーには Plain text モードまたは Mutual TLS モードを使用するオプションがありますが、パーミッシブモードのオプションはありません。
  • MAISTRA-572 Jaeger を Kiali と併用できません。本リリースでは、Jaeger は OAuth プロキシーを使用するように設定されていますが、ブラウザーでのみ機能するようにも設定され、サービスアクセスを許可しません。Kiali は Jaeger エンドポイントと適切に通信できないため、Jaeger が無効であると見なします。TRACING-591 も参照してください。
  • MAISTRA-357 AWS の OpenShift 4 Beta では、デフォルトでポート 80 以外のポートの Ingress ゲートウェイを介して TCP または HTTPS サービスにアクセスすることはできません。AWS ロードバランサーには、サービスエンドポイントのポート 80 がアクティブであるかどうかを検証するヘルスチェックがあります。サービスがポート 80 で実行されていないと、ロードバランサーのヘルスチェックは失敗します。
  • MAISTRA-348 AWS の OpenShift 4 Beta は、80 または 443 以外のポートでの Ingress ゲートウェイトラフィックをサポートしません。Ingress ゲートウェイが 80 または 443 以外のポート番号の TCP トラフィックを処理するように設定する場合、回避策として OpenShift ルーターではなく AWS ロードバランサーによって提供されるサービスホスト名を使用する必要があります。
  • MAISTRA-193 ヘルスチェックが citadel で有効になっていると、予期しないコンソール情報メッセージが表示されます。
  • Bug 1821432: OpenShift Container Platform Control Resource の詳細ページのトグルコントロールで CR が正しく更新されない。OpenShift Container Platform Web コンソールの Service Mesh Control Plane (SMCP) Overview ページの UI のトグルコントロールにより、リソースの誤ったフィールドが更新されることがあります。ServiceMeshControlPlane を更新するには、YAML コンテンツを直接編集するか、トグルコントロールをクリックせずにコマンドラインからリソースを更新します。

2.1.8.2. Kiali の修正された問題

  • KIALI-3239 Kiali Operator Pod が Evicted のステータスで失敗すると、Kiali Operator のデプロイがブロックされます。回避策として、エビクトされた Pod を削除して、Kiali Operator を再デプロイします。
  • KIALI-3118 ServiceMeshMemberRoll の変更 (プロジェクトの追加または削除などの) 後、Kiali Pod が再起動し、その間にグラフページにエラーが表示されます。
  • KIALI-3096 Service Mesh でラインタイムメトリクスが失敗します。Service Mesh と Prometheus 間には OAuth フィルターがあり、アクセスを付与するにはベアラートークンを Prometheus に渡す必要があります。Kiali は Prometheus サーバーと通信する際にこのトークンを使用するように更新されていますが、アプリケーションメトリクスは現在 403 エラーで失敗しています。
  • KIALI-3070 このバグは、デフォルトのダッシュボードではなく、カスタムダッシュボードにのみ影響します。メトリクス設定でラベルを選択し、ページを更新すると、メニュー上でそれらの選択は保持されますが、その選択はチャート上に表示されません。
  • KIALI-2686 コントロールプレーンに多くの namespace がある場合に、パフォーマンスの問題が発生する可能性があります。

2.1.8.3. Red Hat OpenShift 分散トレースの修正された問題

  • 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 を手動で再起動します。