第1章 サービスメッシュ 1.x

1.1. Service Mesh リリースノート

1.1.1. Red Hat OpenShift Service Mesh の概要

Red Hat OpenShift Service Mesh は動作についての洞察、およびサービスメッシュに対する運用上の制御を提供するプラットフォームであり、マイクロサービスアプリケーションへの接続、そのセキュリティー保護、およびモニターを実行するための統一した方法を提供します。

サービスメッシュ という用語は、分散したマイクロサービスアーキテクチャーの複数のアプリケーションを設定するマイクロサービスのネットワークおよびマイクロサービス間の対話を説明するために使用されます。サービスメッシュのサイズとおよび複雑性が増大すると、これを把握し、管理することがより困難になる可能性があります。

オープンソースの Istio プロジェクトをベースとする Red Hat OpenShift Service Mesh は、サービスコードに変更を加えずに、既存の分散したアプリケーションに透過的な層を追加します。マイクロサービス間のネットワーク通信をすべてインターセプトする環境全体に特別なサイドカープロキシーをデプロイすることで、Red Hat OpenShift Service Mesh のサポートをサービスに追加することができます。コントロールプレーンの機能を使用してサービスメッシュを設定し、管理します。

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

1.1.2. サポート

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

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

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

本書の改善が提案される場合や、エラーが見つかった場合は、Documentation コンポーネントの OpenShift Container Platform 製品に対して、Bugzilla レポート を送信してください。セクション名や 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 の両方の診断情報を提供してください。

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

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

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

--image 引数を指定してコマンドを実行する際にイメージを指定できます。イメージを指定する際、ツールはその機能または製品に関連するデータを収集します。

oc adm must-gather を実行すると、新しい Pod がクラスターに作成されます。データは Pod で収集され、must-gather.local で始まる新規ディレクトリーに保存されます。このディレクトリーは、現行の作業ディレクトリーに作成されます。

1.1.2.2. 前提条件

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

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

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

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

must-gather で特定のコントロールプレーン namespace の Red Hat OpenShift Service Mesh データを収集するには、Red Hat OpenShift Service Mesh イメージおよび namespace を指定する必要があります。この例では、<namespace> を istio-system などのコントロールプレーンの namespace に置き換えます。 

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

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

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

  • Red Hat OpenShift Container Platform バージョン 4.x。
注記

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

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

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

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

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

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

    • 3scale Istio Adapter

1.1.4. 新機能

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

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

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

コンポーネントバージョン

Istio

1.4.8

Jaeger

1.17.8

Kiali

1.12.16

3scale Istio Adapter

1.0.0

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

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

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

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

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

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

重要

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

1.1.4.4.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 設定とは異なります。

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

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

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

表1.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 を解釈する場合があります。拒否ポリシーを使用する場合には、アプリケーションの動作を把握している必要があります。

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

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

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

表1.2 設定例

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

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

BASE、MERGE_SLASHES、または DECODE_AND_MERGE_SLASHES

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

BASE

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

MERGE_SLASHES

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

DECODE_AND_MERGE_SLASHES

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

NONE

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

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

SMCP v1 pathNormalization

spec:
  global:
    pathNormalization: <option>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注記

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

1.1.4.14.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

1.1.4.14.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

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

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

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

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

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

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

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

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

1.1.4.18.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 のいずれかにアップグレードする必要があります。

1.1.5. 非推奨の機能

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

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

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

以下のカスタムリソースは本リリースで非推奨となり、今後のリリースで削除されます。

  • 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: 設定の検証および分散

1.1.6. 既知の問題

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

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

1.1.6.1. Service Mesh の既知の問題

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

  • MAISTRA-1502 バージョン 1.0.10 の CVE の修正により、Istio ダッシュボードは Grafana の Home Dashboard メニューから利用できなくなりました。Istio ダッシュボードは依然として存在しています。アクセスするには、ナビゲーションパネルの Dashboard メニューをクリックし、Manage タブを選択します。
  • Bug 1821432: OpenShift Container Platform Control Resource の詳細ページのトグルコントロールで CR が正しく更新されない。OpenShift Container Platform Web コンソールの Service Mesh Control Plane (SMCP) Overview ページの UI のトグルコントロールにより、リソースの誤ったフィールドが更新されることがあります。SMCP を更新するには、YAML コンテンツを直接編集するか、トグルコントロールをクリックせずにコマンドラインからリソースを更新します。
  • Jaeger/Kiali Operator のアップグレードが Operator の保留によりブロックされる Jaeger または Kiali Operator を Service Mesh 1.0.x がインストールされた状態でアップグレードすると、Operator のステータスは Pending と表示されます。これについては、進行中のソリューションと回避策があります。詳細は、関連するナレッジベースの記事を参照してください。
  • Istio-14743 Red Hat OpenShift Service Mesh のこのリリースがベースとしている Istio のバージョンに制限があるため、現時点でサービスメッシュと互換性のないアプリケーションが複数あります。詳細は、リンク先のコミュニティーの問題を参照してください。

  • 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-193 ヘルスチェックが citadel で有効になっていると、予期しないコンソール情報メッセージが表示されます。
  • MAISTRA-158 同じホスト名を参照する複数のゲートウェイを適用すると、すべてのゲートウェイが機能しなくなります。

1.1.6.2. Kiali の既知の問題

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

1.1.6.3. Jaeger の既知の問題

Jaeger には、以下の制限があります。

  • Kafka パブリッシャーは Jaeger の一部として組み込まれていますが、サポートされていません。
  • Apache Spark はサポートされていません。
  • セルフプロビジョニングされた Elasticsearch インスタンスのみがサポートされます。本リリースでは、外部 Elasticsearch インスタンスはサポートされません。

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

  • 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 を参照してください。

1.1.7. 修正された問題

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

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

  • MAISTRA-2371 は listerInformer で tombstones を処理します。更新されたキャッシュコードベースは、namespace キャッシュからのイベントを集約されたキャッシュに変換する際に tombstones を処理しないため、go ルーチンでパニックが生じました。

  • 本リリースおよび今後のリリースでは、コントロールプレーンのインストールから MAISTRA-1352 Cert-manager カスタムリソース定義 (CRD) が削除されました。Red Hat OpenShift Service Mesh がすでにインストールされている場合、cert-manager が使用されていない場合には CRD を手動で削除する必要があります。

    CRD を削除するには、以下のコマンドを実行します。 

    $ oc delete crd clusterissuers.certmanager.k8s.io
    $ oc delete crd issuers.certmanager.k8s.io
    $ oc delete crd certificates.certmanager.k8s.io
    $ oc delete crd orders.certmanager.k8s.io
    $ oc delete crd challenges.certmanager.k8s.io
  • MAISTRA-1649 ヘッドレス サービスは、異なる namespace にある場合に競合します。異なる namespace にヘッドレスサービスをデプロイする場合、エンドポイント設定はマージされ、無効な Envoy 設定がサイドカーコンテナーにプッシュされます。
  • MAISTRA-1541 コントローラーが所有者の参照に設定されていない場合に kubernetesenv でパニックが生じます。Pod にコントローラーを指定しない ownerReference がある場合は、kubernetesenv cache.go コード内でパニックが生じます。
  • 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 エラーが出されます。
  • OSSM-99 ラベルを持たない直接の Pod から生成されたワークロードは Kiali をクラッシュさせる可能性があります。
  • OSSM-93 IstioConfigList は複数の名前でフィルターをかけることができません。
  • OSSM-92 VS/DR YAML 編集ページで未保存の変更をキャンセルしても、変更はキャンセルされません。
  • OSSM-90 サービスの詳細ページでは、トレースは利用できません。
  • MAISTRA-1001 HTTP/2 接続を閉じると、istio-proxy でセグメント化の障害が生じる可能性があります。
  • MAISTRA-932 Jaeger Operator と Elasticsearch Operator 間の依存関係を追加するために requires メタデータが追加されました。Jaeger Operator のインストール時に、これが利用不可能な場合は 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 ロードバランサーによって提供されるサービスホスト名を使用する必要があります。

1.1.7.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 がある場合に、パフォーマンスの問題が発生する可能性があります。