サービスメッシュ

OpenShift Container Platform 4.7

サービスメッシュのインストール、使用法、およびリリースノート

概要

本書では、OpenShift Container Platform でサービスメッシュを使用する方法について説明します。

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

1.1. OpenShift Service Mesh について

1.1.1. Red Hat OpenShift Service Mesh の概要

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

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

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

1.2. Service Mesh リリースノート

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

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

1.2.2. 新機能

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

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

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

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

Istio

1.6.14

Jaeger

1.24.1

Kiali

1.24.10-1

3scale Istio Adapter

2.0.0

1.2.2.2. Red Hat OpenShift Service Mesh 2.0.7.1 の新機能

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

1.2.2.2.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 をベースとする承認ポリシーが無視できなくなります。

軽減策の新しい動作からオプトインするには、URI の fragment セクションが保持されます。ServiceMeshControlPlane を設定して URI フラグメントを保持することができます。

警告

新しい動作を無効にすると、上記のようにパスを正規化し、安全でないと見なされます。URI フラグメントを保持することを選択する前に、セキュリティポリシーでこれに対応していることを確認してください。

ServiceMeshControlPlane の変更例

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  techPreview:
    meshConfig:
      defaultConfig:
        proxyMetadata: HTTP_STRIP_FRAGMENT_FROM_PATH_UNSAFE_IF_DISABLED: "false"

1.2.2.2.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:*"]

1.2.2.3. Red Hat OpenShift Service Mesh 2.0.7 の新機能

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

1.2.2.4. Red Hat OpenShift Dedicated および Microsoft Azure Red Hat OpenShift 上の Red Hat OpenShift Service Mesh

Red Hat OpenShift Service Mesh は、Red Hat OpenShift Dedicated および Microsoft Azure Red Hat OpenShift 経由でサポートされるようになりました。

1.2.2.5. Red Hat OpenShift Service Mesh 2.0.6 の新機能

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

1.2.2.6. Red Hat OpenShift Service Mesh 2.0.5 の新機能

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

1.2.2.7. Red Hat OpenShift Service Mesh 2.0.4 の新機能

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

重要

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

1.2.2.7.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.2.2.7.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.2.2.7.3. パスの正規化設定の例

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

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

表1.2 設定例

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

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

BASEMERGE_SLASHES、または DECODE_AND_MERGE_SLASHES

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

BASE

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

MERGE_SLASHES

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

DECODE_AND_MERGE_SLASHES

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

NONE

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

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

SMCP v2 pathNormalization

spec:
  techPreview:
    global:
      pathNormalization: <option>

1.2.2.7.5. ケース正規化 (case normalization) の設定

環境によっては、大文字と小文字を区別しない場合の比較用に 2 つのパスを認証ポリシーに用意すると便利な場合があります。たとえば、https://myurl/gethttps://myurl/GeT を同等なものとして扱います。このような場合には、以下に示されている EnvoyFilter を使用できます。このフィルターは、比較用に使用されるパスとアプリケーションに表示されるパスの両方を変更します。この例では、istio-system は、コントロールプレーンプロジェクトです。

EnvoyFilter をファイルに保存して、以下のコマンドを実行します。

$ oc create -f <myEnvoyFilterFile>
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: ingress-case-insensitive
  namespace: istio-system
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
            subFilter:
              name: "envoy.filters.http.router"
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.lua
        typed_config:
            "@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua"
            inlineCode: |
              function envoy_on_request(request_handle)
                local path = request_handle:headers():get(":path")
                request_handle:headers():replace(":path", string.lower(path))
              end

1.2.2.8. Red Hat OpenShift Service Mesh 2.0.3 の新機能

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

また、本リリースには以下の新機能があります。

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

1.2.2.9. Red Hat OpenShift Service Mesh 2.0.2 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、IBM Z および IBM Power Systems のサポートが追加されました。また、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

1.2.2.10. Red Hat OpenShift Service Mesh 2.0.1 の新機能

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

1.2.2.11. Red Hat OpenShift Service Mesh 2.0 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、Istio 1.6.5、Jaeger 1.20.0、Kiali 1.24.2、3scale Istio Adapter 2.0 および OpenShift Container Platform 4.6 のサポートが追加されました。

また、本リリースには以下の新機能があります。

  • コントロールプレーンのインストール、アップグレード、および管理を単純化します。
  • コントロールプレーンのリソース使用量を減らし、起動時間を短縮します。
  • ネットワークのコントロールプレーン間の通信を削減することで、パフォーマンスが向上します。

    • Envoy の Secret Discovery Service (SDS) のサポートが追加されました。SDS は、Envoy サイドカープロキシーにシークレットを提供するためのより安全で効率的なメカニズムです。
  • よく知られているセキュリティーリスクがある Kubernetes シークレットを使用する必要性がなくなります。
  • プロキシーが新しい証明書を認識するのに再起動を必要としなくなったため、証明書のローテーション時にパフォーマンスが向上します。

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

1.2.3. テクノロジープレビュー

重要

テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

1.2.3.1. OVN-Kubernetes テクノロジープレビュー

Red Hat OpenShift Service Mesh 2.0.1 では、OpenShift Container Platform 4.6 および 4.7 での OVN-Kubernetes ネットワークタイプのテクノロジープレビューサポートが導入されました。

1.2.3.2. WebAssembly テクノロジープレビュー

Red Hat OpenShift Service Mesh 2.0.0 では、WebAssembly 拡張のサポートが Envoy Proxy に導入されています。

リリース 1.5 までのバージョンでは、Istio は Mixer Telemetry および Policy コンポーネントを使用して拡張を実装していました。Istio 1.5 Mixer は非推奨となり、Istio での拡張の新規メカニズムとして WebAssembly が導入されました。Envoy は、複数のプログラミング言語で書かれたコードを実行するための形式である WebAssembly (「WASM」) を使用する場合の拡張を許可するようになりました。Mixer は Istio 1.5 で非推奨となり、1.8. で削除されます。今後 Istio の拡張機能は、WebAssembly で作成される Envoy プラグインで実装されます。

新規 Telemetry アーキテクチャーはこれらの WebAssembly 拡張をベースとします。Service Mesh 2.0 では、WebAssembly 拡張をテクノロジープレビュー機能として導入しています。WebAssembly 拡張は、Istio 機能を拡張する新しい方法であり、これは非推奨となり、削除される予定の Mixer コンポーネントを置き換えるものとなります。

注記

組み込まれた WASM 拡張はプロキシーバイナリーに含まれず、アップストリームの Istio コミュニティーの WASM フィルターは Red Hat OpenShift Service Mesh 2.0 でサポートされていないことに注意してください。

WebAssembly 拡張についての詳細は、 拡張について参照してください。

1.2.4. 非推奨の機能

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

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

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

Mixer コンポーネントはリリース 2.0 で非推奨となり、リリース 2.1 で削除されます。Mixer を使用した拡張機能の実装はリリース 2.0 でも引き続きサポートされますが、拡張機能を新規の WebAssembly メカニズムに移行する必要があります。

以下のリソースタイプは Red Hat OpenShift Service Mesh 2.0 でサポートされなくなりました。

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

    • RequestAuthentication (security.istio.io/v1beta1) の使用
    • PeerAuthentication (security.istio.io/v1beta1) の使用
  • ServiceMeshPolicy (maistra.io/v1) はサポートされなくなりました。

    • 上記のように RequestAuthentication または PeerAuthentication を使用しますが、コントロールプレーン namespace に配置します。
  • RbacConfig (rbac.istio.io/v1alpha1) はサポートされなくなりました。

    • AuthorizationPolicy (security.istio.io/v1beta1) に置き換わります。これは RbacConfigServiceRole、および ServiceRoleBinding の動作を包含します。
  • ServiceMeshRbacConfig (maistra.io/v1) がサポートされなくなりました。

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

1.2.5. 既知の問題

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

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

1.2.5.1. サービスメッシュの既知の問題

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

  • Istio-14743 Red Hat OpenShift Service Mesh のこのリリースがベースとしている Istio のバージョンに制限があるため、現時点でサービスメッシュと互換性のないアプリケーションが複数あります。詳細は、リンク先のコミュニティーの問題を参照してください。
  • OSSM-285 Kiali コンソールにアクセスしようとすると、「Error trying to get OAuth Metadata」というエラーメッセージが表示されます。回避策として、Kiali Pod を再起動します。
  • MAISTRA-2411 Operator が ServiceMeshControlPlanespec.gateways.additionaIngress を使用して新規 ingress ゲートウェイを作成する場合、Operator はデフォルトの istio-ingressgateway の場合と同様に追加の Ingress ゲートウェイの NetworkPolicy を作成しません。これにより、新規ゲートウェイのルートから 503 応答が生じました。この問題を回避するには、<istio-system> namespace で NetworkPolicy を手動で作成できます。
  • MAISTRA-1959 2.0 への移行 Prometheus の収集 (spec.addons.prometheus.scrapetrue に設定される) は mTLS が有効にされていると機能しません。また、Kiali は、mTLS が無効にされている場合に余分なグラフデータを表示します。

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

    spec:
      proxy:
        networking:
          trafficControl:
            inbound:
              excludedPorts:
              - 15020
  • MAISTRA-1947 テクノロジープレビュー ServiceMeshExtensions への更新は適用されません。回避策として、ServiceMeshExtensions を削除し、再作成します。
  • MAISTRA-1314 Red Hat OpenShift Service Mesh は IPv6 をサポートしていません。
  • 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 同じホスト名を参照する複数のゲートウェイを適用すると、すべてのゲートウェイが機能しなくなります。

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

1.2.5.3. Jaeger の既知の問題

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

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

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

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

  • BZ-1918920 Elasticsearch Pod は更新後に自動的に再起動しません。回避策として、Pod を手動で再起動します。
  • Trace-809 Jaeger Ingester には Kafka 2.3 との互換性がありません。Jaeger Ingester のインスタンスが複数あり、十分なトラフィックがある場合、リバランスメッセージがログに継続的に生成されます。これは、Kafka 2.3.1 で修正された Kafka 2.3 のリグレッションによって生じます。詳細は、Jaegertracing-1819 を参照してください。

1.2.6. 修正された問題

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

1.2.6.1. サービスメッシュの修正された問題

  • 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 がサービスメッシュのメンバーロールで定義されていない場合でも、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 に表示されません。
  • MAISTRA-2635 非推奨の Kubernetes API を置き換えます。OpenShift Container Platform 4.8 との互換性を維持するために、api extensions.k8s.io/v1beta1 API は Red Hat OpenShift Service Mesh 2.0.8 の時点で非推奨になりました。
  • MAISTRA-2631 は、podman が nsenter バイナリーが存在しないために失敗するため、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-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 で OpenShiftSDN を使用するように設定されており、メッシュに多数の namespace (200+) が含まれる場合に、OpenShift Container Platform ネットワークプラグインは namespace を迅速に設定できません。サービスメッシュがタイムアウトすると、namespace がサービスメッシュから継続的にドロップされ、再リストされます。
  • MAISTRA-2370 は listerInformer で tombstones を処理します。更新されたキャッシュコードベースは、namespace キャッシュからのイベントを集約されたキャッシュに変換する際に tombstones を処理しないため、go ルーチンでパニックが生じました。
  • 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-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-193 ヘルスチェックが citadel で有効になっていると、予期しないコンソール情報メッセージが表示されます。
  • Bug 1821432: OpenShift Container Platform Control Resource の詳細ページのトグルコントロールで CR が正しく更新されない。OpenShift Container Platform Web コンソールの Service Mesh Control Plane (SMCP) Overview ページの UI のトグルコントロールにより、リソースの誤ったフィールドが更新されることがあります。SMCP を更新するには、YAML コンテンツを直接編集するか、トグルコントロールをクリックせずにコマンドラインからリソースを更新します。

1.2.6.2. Jaeger の修正された問題

  • TRACING-2009 Jaeger Operator が Strimzi Kafka Operator 0.23.0 のサポートを追加するように更新されました。
  • TRACING-1907: アプリケーション namespace に設定マップがないため、Jaeger エージェントサイドカーの挿入が失敗していました。設定マップは正しくない 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

1.3. Red Hat OpenShift Service Mesh について

Red Hat OpenShift Service Mesh は、サービスメッシュにおいてネットワーク化されたマイクロサービス全体の動作に関する洞察と運用管理のためのプラットフォームを提供します。Red Hat OpenShift Service Mesh では、OpenShift Container Platform 環境でマイクロサービスの接続、保護、監視を行うことができます。

1.3.1. サービスメッシュについて

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

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

Red Hat OpenShift Service Mesh により、以下を提供するデプロイされたサービスのネットワークを簡単に作成できます。

  • 検出
  • 負荷分散
  • サービス間の認証
  • 障害回復
  • メトリクス
  • モニタリング

Red Hat OpenShift Service Mesh は、以下を含むより複雑な運用機能も提供します。

  • A/B テスト
  • カナリアリリース
  • レート制限
  • アクセス制御
  • エンドツーエンド認証

1.3.2. サービスメッシュアーキテクチャー

サービスメッシュテクノロジーはネットワーク通信レベルで動作します。つまり、サービスメッシュコンポーネントは、マイクロサービスとの間のトラフィックを取得または傍受して、リクエストを変更したり、リダイレクトしたり、他のサービスへの新しいリクエストを作成したりします。

高いレベルでは、Red Hat OpenShift Service Mesh はデータプレーンおよびコントロールプレーンで構成されます。

データプレーン は、Pod のアプリケーションコンテナーとともに実行するインテリジェントプロキシーのセットで、サービスメッシュ内のマイクロサービス間の受信および送信ネットワーク通信をすべて傍受し、制御します。データプレーンは、すべての受信 (ingress) および送信 (egress) ネットワークトラフィックを傍受するように実装されます。Istio データプレーンは、Pod のサイドアプリケーションコンテナーで実行する Envoy コンテナーで構成されます。Envoy コンテナーはプロキシーとして機能し、すべてのネットワーク通信を Pod に対して制御します。

  • Envoy プロキシー は、データプレーントラフィックと対話する唯一の Istio コンポーネントです。プロキシー経由でサービスフロー間の受信 (ingress) および送信 (egress) ネットワークトラフィックはすべて、そのプロキシーを介して行われます。また、Envoy プロキシーは、メッシュ内のサービストラフィックに関連するすべてのメトリクスを収集します。Envoy プロキシーはサイドカーとしてデプロイされ、サービスと同じ Pod で実行されます。Envoy プロキシーは、メッシュゲートウェイの実装にも使用されます。

    • サイドカープロキシー は、割り当てられたワークロードインスタンスへのインバウンドおよびアウトバウンドの通信を管理します。
    • ゲートウェイ は、受信または送信 HTTP/TCP 接続を受信するロードバランサーとして動作するプロキシーです。ゲートウェイ設定は、サービスワークロードと共に実行されるサイドカー Envoy プロキシーではなく、メッシュのエッジで実行されているスタンドアロンの Envoy プロキシーに適用されます。ゲートウェイを使用してメッシュの受信トラフィックおよび送信トラフィックを管理することで、メッシュに入るか、またはメッシュを出るトラフィックを指定できます。

      • Ingress-gateway - ingress コントローラーとしても知られる、Ingress ゲートウェイはサービスメッシュに入るトラフィックを受信し、制御する専用の Envoy プロキシーです。Ingress ゲートウェイは、モニタリングおよびルーティングルールなどの機能をクラスターに入るトラフィックに適用できるようにします。
      • Egress-gateway - egress コントローラーとしても知られる、Egress Gateway はサービスメッシュからトラフィックを管理する専用の Envoy プロキシーです。Egress Gateway は、モニタリングおよびルートルールなどの機能をメッシュのトラフィックに適用できるようにします。

コントロールプレーン は、データプレーンを構成するプロキシーを管理し、設定します。これは、設定用の権威ソースで、アクセス制御および使用状況ポリシーを管理し、サービスメッシュのプロキシーからメトリクスを収集します。

  • Istio コントロールプレーンは、以前の複数のコントロールプレーンコンポーネント (Citadel、Galley、Pilot) を単一バイナリーに統合する Istiod で構成されています。Istiod は、サービス検出、設定、および証明書の管理を行います。これは、高レベルのルーティングルールを Envoy 設定に変換し、それらをランタイム時にサイドカーコンテナーに伝播します。

    • Istiod は認証局 (CA) として機能し、データプレーンでセキュアな mTLS 通信に対応する証明書を生成します。この場合、外部 CA を使用することもできます。
    • Istiod は、サイドカーコンテナーを OpenShift クラスターにデプロイされたワークロードに挿入します。

Red Hat OpenShift Service Mesh は、istio-operator を使用してコントロールプレーンのインストールも管理します。Operator は、OpenShift クラスターで共通アクティビティーを実装し、自動化できるソフトウェアの構成要素です。これはコントローラーとして機能し、クラスター内の必要なオブジェクトの状態 (この場合は Red Hat OpenShift Service Mesh のインストール) を設定または変更できます。

Red Hat OpenShift Service Mesh は以下の Istio アドオンを製品の一部としてバンドルします。

  • Kiali: Kiali は Red Hat OpenShift Service Mesh の管理コンソールです。ダッシュボード、可観測性、および堅牢な構成、ならびに検証機能を提供します。これは、トラフィックトポロジーを推測してサービスメッシュの構造を示し、メッシュの正常性を表示します。Kiali は、Jaeger との分散トレースのための詳細なメトリクス、強力な検証、Grafana へのアクセス、および強力な統合を提供します。
  • Prometheus: Red Hat OpenShift Service Mesh は Prometheus を使用してサービスからのテレメトリー情報を保存します。Kiali は、メトリクス、ヘルスステータス、およびメッシュトポロジーを取得するために Prometheus に依存します。
  • Jaeger: Red Hat OpenShift Service Mesh は分散トレースの Jaeger をサポートします。Jaeger はオープンソースのトレース機能で、複数のサービス間の単一要求に関連付けられたトレースを一元管理し、表示します。Jaeger を使用すると、マイクロサービスベースの分散システムの監視およびトラブルシューティングを行うことができます。
  • Elasticsearch: ElasticSearch はオープンソースで分散された JSON ベースの検索、および解析エンジンです。Jaeger は、データをロギングおよびトレースするための分散ストレージおよびインデックスに ElasticSearch を使用します。
  • Grafana: Grafana は、Istio データの高度なクエリーおよびメトリクス分析、ならびにダッシュボードを使用してメッシュ管理者を提供します。任意で、Grafana を使用してサービスメッシュメトリクスを分析できます。

以下の Istio アダプターは Red Hat OpenShift Service Mesh でサポートされます。

  • 3scale: 3scale Istio アダプターは、Red Hat OpenShift Service Mesh と Red Hat 3scale API Management ソリューションを統合する任意のコンポーネントです。デフォルトの Red Hat OpenShift Service Mesh インストールにはこのコンポーネントが含まれていません。

3scale アダプターのインストール方法に関する詳細は、3scale Istio アダプターのドキュメント を参照してください。

1.3.3. Kiali について

Kiali は、サービスメッシュのマイクロサービスとそれらの接続方法を表示してサービスメッシュを可視化します。

1.3.3.1. Kiali の概要

Kiali では、OpenShift Container Platform で実行されるサービスメッシュの可観測性 (Observability) を提供します。Kiali は、Istio サービスメッシュの定義、検証、および確認に役立ちます。これは、トポロジーの推測によりサービスメッシュの構造を理解しやすくし、またサービスメッシュの健全性に関する情報も提供します。

Kiali は、サーキットブレーカー、要求レート、レイテンシー、トラフィックフローのグラフなどの機能を可視化する、namespace のインタラクティブなグラフビューをリアルタイムで提供します。Kiali では、異なるレベルのコンポーネント (アプリケーションからサービスおよびワークロードまで) についての洞察を提供し、選択されたグラフノードまたはエッジに関するコンテキスト情報やチャートを含む対話を表示できます。Kiali は、ゲートウェイ、宛先ルール、仮想サービス、メッシュポリシーなど、Istio 設定を検証する機能も提供します。Kiali は詳細なメトリクスを提供し、基本的な Grafana 統合は高度なクエリーに利用できます。Jaeger を Kiali コンソールに統合することで、分散トレースを提供します。

Kiali は、デフォルトで Red Hat OpenShift Service Mesh の一部としてインストールされます。

1.3.3.2. Kiali アーキテクチャー

Kiali は Kiali アプリケーションと Kiali コンソールという 2 つのコンポーネントで構成されます。

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

さらに Kiali は、コンテナーアプリケーションプラットフォームと Istio が提供する外部サービスとコンポーネントに依存します。

  • 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 インストールの一部として Jaeger をインストールすると、Kiali コンソールには Jaeger のトレースデータを表示するタブが含まれます。Istio の分散トレース機能を無効にした場合、トレースデータは利用できないことに注意してください。また、Jaeger データを表示するには、コントロールプレーンがインストールされている namespace にユーザーがアクセスできる必要があります。
  • Grafana: Grafana はオプションですが、デフォルトでは Red Hat OpenShift Service Mesh インストールの一部としてインストールされます。使用可能な場合、Kiali のメトリクスページには Grafana 内の同じメトリクスにユーザーを移動させるリンクが表示されます。Grafana ダッシュボードへのリンクと Grafana データを表示するには、コントロールプレーンがインストールされている namespace にユーザーがアクセスできる必要があることに注意してください。

1.3.3.3. Kiali の機能

Kiali コンソールは Red Hat Service Mesh に統合され、以下の機能を提供します。

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

1.3.4. Jaeger について

ユーザーがアプリケーションでアクションを実行するたびに、応答を生成するために多数の異なるサービスに参加を要求する可能性のあるアーキテクチャーによって要求が実行されます。この要求のパスは分散トランザクションです。Jaeger を使用すると、分散トレースを実行できます。これは、アプリケーションを構成するさまざまなマイクロサービスを介して要求のパスを追跡します。

分散トレースは、さまざまな作業ユニットの情報を連携させるために使用される技術です。これは、分散トランザクションでのイベントのチェーン全体を理解するために、通常さまざまなプロセスまたはホストで実行されます。分散トレースを使用すると、開発者は大規模なサービス指向アーキテクチャーで呼び出しフローを可視化できます。シリアル化、並行処理、およびレイテンシーのソースについて理解しておくことも重要です。

Jaeger はマイクロサービスのスタック全体での個々の要求の実行を記録し、トレースとして表示します。トレース とは、システムにおけるデータ/実行パスです。エンドツーエンドトレースは、1 つ以上のスパンで構成されます。

スパン は、オペレーション名、オペレーションの開始時間および期間を持つ、Jaeger の作業の論理単位を表しています。スパンは因果関係をモデル化するためにネスト化され、順序付けられます。

1.3.4.1. Jaeger の概要

サービスの所有者は、Jaeger を使用してサービスをインストルメント化し、サービスアーキテクチャーに関する洞察を得ることができます。Jaeger は、最新のクラウドネイティブ、マイクロサービスベースのアプリケーションにおいてコンポーネント間の対話のモニタリング、ネットワークプロファイリングおよびトラブルシューティングに使用できる、オープンソースの分散トレースプラットフォームです。

Jaeger を使用すると、以下の機能を実行できます。

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

Jaeger は特定のベンダーに依存しない OpenTracing API およびインストルメンテーションに基づいています。

1.3.4.2. Jaeger アーキテクチャー

Jaeger は、複数のコンポーネントで構成されており、トレースデータを収集し、保存し、表示するためにそれらが連携します。

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

1.3.4.3. Jaeger の機能

Jaeger のトレース機能には以下の機能が含まれます。

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

1.3.5. 次のステップ

1.4. サービスメッシュと Istio の相違点

Red Hat OpenShift Service Mesh は、追加機能の提供、OpenShift Container Platform へのデプロイ時の差異の処理を実行する Istio のインストールとは異なります。

1.4.1. Istio と Red Hat OpenShift Service Mesh の相違点

以下の機能はサービスメッシュと Istio で異なります。

1.4.1.1. コマンドラインツール

Red Hat OpenShift Service Mesh のコマンドラインツールは oc です。  Red Hat OpenShift Service Mesh は、istioctl をサポートしません。

1.4.1.2. インストールおよびアップグレード

Red Hat OpenShift Service Mesh は、Istio インストールプロファイルをサポートしません。

Red Hat OpenShift Service Mesh はサービスメッシュのカナリアアップグレードをサポートしません。

1.4.1.3. 自動的な挿入

アップストリームの Istio コミュニティーインストールは、ラベル付けしたプロジェクト内の Pod にサイドカーコンテナーを自動的に挿入します。

Red Hat OpenShift Service Mesh は、サイドカーコンテナーをあらゆる Pod に自動的に挿入することはなく、プロジェクトにラベルを付けることなくアノテーションを使用して挿入をオプトインする必要があります。この方法で必要となる権限は少なく、ビルダー Pod などの他の OpenShift 機能と競合しません。自動挿入を有効にするには、「サイドカーの自動挿入」セクションで説明されているように sidecar.istio.io/inject アノテーションを指定します。

1.4.1.4. Istio ロールベースアクセス制御機能

Istio ロールベースアクセス制御機能 (RBAC) は、サービスへのアクセスを制御するために使用できるメカニズムを提供します。ユーザー名やプロパティーのセットを指定してサブジェクトを特定し、それに応じてアクセス制御を適用することができます。

アップストリームの Istio コミュニティーインストールには、ヘッダーの完全一致の実行、ヘッダーのワイルドカードの一致の実行、または特定のプレフィックスまたはサフィックスを含むヘッダーの有無をチェックするオプションが含まれます。

Red Hat OpenShift Service Mesh は、正規表現を使用して要求ヘッダーと一致させる機能を拡張します。request.regex.headers のプロパティーキーを正規表現で指定します。

アップストリーム Istio コミュニティーの要求ヘッダーのマッチング例

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin-usernamepolicy
spec:
  action: ALLOW
  rules:
    - when:
        - key: 'request.regex.headers[username]'
          values:
            - "allowed.*"
  selector:
    matchLabels:
      app: httpbin

1.4.1.5. OpenSSL

Red Hat OpenShift Service Mesh では、BoringSSL を OpenSSL に置き換えます。OpenSSL は、Secure Sockets Layer (SSL) プロトコルおよび Transport Layer Security (TLS) プロトコルのオープンソース実装を含むソフトウェアライブラリーです。Red Hat OpenShift Service Mesh Proxy バイナリーは、基礎となる Red Hat Enterprise Linux オペレーティングシステムから OpenSSL ライブラリー (libssl および libcrypto) を動的にリンクします。

1.4.1.6. 外部ワークロード

Red Hat OpenShift Service Mesh は外部ワークロード (仮想マシン) をサポートしません。

1.4.1.7. コンポーネントの変更

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

1.4.1.8. Envoy サービス

Red Hat OpenShift Service Mesh は、QUIC ベースのサービスをサポートしません。

1.4.1.9. Istio Container Network Interface (CNI) プラグイン

Red Hat OpenShift Service Mesh には CNI プラグインが含まれ、アプリケーション Pod ネットワーキングを設定する代替の方法が提供されます。CNI プラグインは init-container ネットワーク設定を置き換えます。これにより、昇格した権限でサービスアカウントおよびプロジェクトに SCC (Security Context Constraints) へのアクセスを付与する必要がなくなります。

1.4.1.10. Istio ゲートウェイのルート

Istio ゲートウェイの OpenShift ルートは、Red Hat OpenShift Service Mesh で自動的に管理されます。Istio ゲートウェイがサービスメッシュ内で作成され、更新され、削除されるたびに、OpenShift ルートが作成され、更新され、削除されます。

Istio OpenShift Routing (IOR) と呼ばれる Red Hat OpenShift Service Mesh コントロールプレーンコンポーネントは、ゲートウェイルートを同期させます。詳細は、自動ルートの作成について参照してください。

1.4.1.10.1. catch-all ドメイン

catch-all ドメイン ("*") はサポートされません。ゲートウェイ定義で catch-all ドメインが見つかった場合、Red Hat OpenShift Service Mesh はルートを 作成します が、デフォルトのホスト名を作成するには OpenShift に依存します。つまり、新たに作成されたルートは、catch all ("*") ルート ではなく、代わりに <route-name>[-<project>].<suffix> 形式のホスト名を持ちます。デフォルトのホスト名の仕組みや、cluster-admin がカスタマイズできる仕組みについての詳細は、OpenShift ドキュメントを参照してください。Red Hat OpenShift Dedicated を使用する場合は、Red Hat OpenShift Dedicated の dedicated-admin ロールを参照してください。

1.4.1.10.2. サブドメイン

サブドメイン (e.g.: "*.domain.com") はサポートされます。ただし、この機能は OpenShift ではデフォルトで有効化されていません。つまり、Red Hat OpenShift Service Mesh はサブドメインを持つルートを 作成します が、これは OpenShift が有効にするように設定されている場合にのみ有効になります。

1.4.1.10.3. トランスポート層セキュリティー

トランスポート層セキュリティー (TLS) がサポートされます。ゲートウェイに tls セクションが含まれる場合、OpenShift ルートは TLS をサポートするように設定されます。

1.4.1.10.4. WebAssembly 拡張

Red Hat OpenShift Service Mesh 2.0 では、テクノロジープレビューとして WebAssembly 拡張が Envoy Proxy に導入されています。WASM 拡張はプロキシーバイナリーに含まれず、アップストリームの Istio コミュニティーの WASM フィルターは Red Hat OpenShift Service Mesh 2.0 でサポートされていないことに注意してください。

関連情報

1.4.2. マルチテナントインストール

アップストリームの Istio は単一テナントのアプローチをとりますが、Red Hat OpenShift Service Mesh はクラスター内で複数の独立したコントロールプレーンをサポートします。Red Hat OpenShift Service Mesh はマルチテナント Operator を使用して、コントロールプレーンのライフサイクルを管理します。

Red Hat OpenShift Service Mesh は、デフォルトでマルチテナントコントロールプレーンをインストールします。サービスメッシュにアクセスできるプロジェクトを指定し、サービスメッシュを他のコントロールプレーンインスタンスから分離します。

1.4.2.1. マルチテナンシーとクラスター全体のインストールの比較

マルチテナントインストールとクラスター全体のインストールの主な違いは、コントロールプレーンのデプロイメント (Galley や Pilot など) で使用される権限の範囲です。コンポーネントでは、クラスタースコープのロールベースのアクセス制御 (RBAC) リソース ClusterRoleBinding が使用されなくなりました。

ServiceMeshMemberRoll members 一覧のすべてのプロジェクトには、コントロールプレーンのデプロイメントに関連付けられた各サービスアカウントの RoleBinding があり、各コントロールプレーンのデプロイメントはそれらのメンバープロジェクトのみを監視します。各メンバープロジェクトには maistra.io/member-of ラベルが追加されており、member-of の値はコントロールプレーンのインストールが含まれるプロジェクトになります。

Red Hat OpenShift Service Mesh は各メンバープロジェクトを設定し、それ自体、コントロールプレーン、および他のメンバープロジェクト間のネットワークアクセスを確保できるようにします。詳細な設定は、OpenShift SDN (Software-defined Networking) の設定方法によって異なります。詳細は、「OpenShift SDN について」を参照してください。

OpenShift Container Platform クラスターが SDN プラグインを使用するように設定されている場合:

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

    注記

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

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

1.4.2.2. クラスタースコープのリソース

アップストリーム Istio には、依存するクラスタースコープのリソースが 2 つあります。MeshPolicy および ClusterRbacConfig。これらはマルチテナントクラスターと互換性がなく、以下で説明されているように置き換えられました。

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

1.4.3. Kiali とサービスメッシュ

OpenShift Container Platform でのサービスメッシュを使用した Kiali のインストールは、複数の点でコミュニティーの Kiali インストールとは異なります。以下の変更点は、問題の解決、追加機能の提供、OpenShift Container Platform へのデプロイ時の差異の処理を実行するために必要になることがあります。

  • Kiali はデフォルトで有効になっています。
  • Ingress はデフォルトで有効になっています。
  • Kiali ConfigMap が更新されています。
  • Kiali の ClusterRole 設定が更新されています。
  • ConfigMap または Kiali カスタムリソースファイルを編集しないでください。これらの変更はサービスメッシュまたは Kiali Operator によって上書きされる可能性があるためです。Red Hat OpenShift Service Mesh で実行している Kiali の設定はすべて ServiceMeshControlPlane カスタムリソースファイルで行われ、設定オプションは制限されています。Operator ファイルの更新は、cluster-admin 権限を持つユーザーに制限する必要があります。Red Hat OpenShift Dedicated を使用する場合に、dedicated-admin 権限のあるユーザーだけが Operator ファイルを更新できるようにする必要があります。

1.4.4. Jaeger とサービスメッシュ

OpenShift Container Platform でのサービスメッシュを使用した Jaeger インストールは、複数の点でコミュニティーの Jaeger インストールとは異なります。以下の変更点は、問題の解決、追加機能の提供、OpenShift Container Platform へのデプロイ時の差異の処理を実行するために必要になることがあります。

  • Jaeger はサービスメッシュに対してデフォルトで有効にされています。
  • Ingress は、サービスメッシュに対してデフォルトで有効にされています。
  • Zipkin ポート名が、(http から) jaeger-collector-zipkin に変更されています。
  • Jaeger は、production または streaming デプロイメントオプションのいずれかを選択する際に、デフォルトでストレージに Elasticsearch を使用します。
  • Istio のコミュニティーバージョンは、一般的な「トレース」ルートを提供します。Red Hat OpenShift Service Mesh は Jaeger Operator によってインストールされ、OAuth によってすでに保護されている「jaeger」ルートを使用します。
  • Red Hat OpenShift Service Mesh は Envoy プロキシーにサイドカーを使用し、Jaeger も Jaeger エージェントにサイドカーを使用します。両者は個別に設定し、混同しないようにしてください。プロキシーサイドカーは、Pod の Ingress および Egress トラフィックに関連するスパンを作成します。エージェントサイドカーは、アプリケーションによって出力されるスパンを受け取り、これらを Jaeger Collector に送信します。

1.5. Red Hat OpenShift Service Mesh のインストールの準備

Red Hat OpenShift Service Mesh をインストールする前に、OpenShift Container Platform にサブスクライブし、サポート対象の設定で OpenShift Container Platform をインストールする必要があります。

1.5.1. 前提条件

1.5.2. サポートされる構成

以下の設定は、Red Hat OpenShift Service Mesh の現行リリースでサポートされます。

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

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

  • 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 以降でのみサポートされます。
  • すべてのサービスメッシュコンポーネントが単一の OpenShift Container Platform クラスター内に含まれる設定。Red Hat OpenShift Service Mesh は、サービスメッシュが実行しているクラスター外にあるマイクロサービスの管理をサポートしません。
  • 仮想マシンなどの外部サービスを統合しない設定。

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

1.5.2.1. サポートされるネットワーク設定

Red Hat OpenShift Service Mesh は以下のネットワーク設定をサポートします。

  • OpenShift-SDN
  • OVN-Kubernetes は、OpenShift Container Platform バージョン 4.7 でテクノロジープレビューとしてサポートされます。

1.5.2.2. Kiali のサポートされる設定

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

1.5.2.3. 分散トレースのサポートされる構成

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

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

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

    • 3scale Istio Adapter

1.5.3. 次のステップ

1.6. Operator のインストール

Red Hat OpenShift Service Mesh をインストールするには、まず必要な Operator を OpenShift Container Platform にインストールし、コントロールプレーンをデプロイするために ServiceMeshControlPlane リソースを作成します。

前提条件

以下の手順では、OpenShift Container Platform に Red Hat OpenShift Service Mesh の基本的なインスタンスをインストールする方法について説明します。

1.6.1. Operator の概要

Red Hat OpenShift Service Mesh には、以下の 4 つの Operator が必要です。

  • OpenShift Elasticsearch:(オプション) Jaeger でのトレースおよびロギング用にデータベースストレージを提供します。これはオープンソースの Elasticsearch プロジェクトに基づいています。
  • Jaeger: 複雑な分散システムでのトランザクションを監視し、トラブルシューティングするための追跡機能を提供します。これはオープンソースの Jaeger プロジェクトに基づいています。
  • Kiali: サービスメッシュの可観測性を実現します。これにより、単一のコンソールで設定を表示し、トラフィックを監視し、トレースの分析を実行できます。これはオープンソースの Kiali プロジェクトに基づいています。
  • Red Hat OpenShift Service Mesh: アプリケーションを構成するマイクロサービスを接続し、保護し、制御し、観察することができます。Service Mesh Operator は、サービスメッシュコンポーネントのデプロイメント、更新、および削除を管理する ServiceMeshControlPlane リソースを定義し、監視します。これはオープンソースの Istio プロジェクトに基づいています。

1.6.2. Operator のインストール

Red Hat OpenShift Service Mesh をインストールするには、以下の Operator をこの順序でインストールします。Operator ごとに手順を繰り返します。

  1. (オプション) OpenShift Elasticsearch
  2. Jaeger
  3. Kiali
  4. Red Hat OpenShift Service Mesh

手順

  1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。
  2. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
  3. Operator のフィルターボックスに名前を入力し、Red Hat バージョンの Operator を選択します。Operator のコミュニティーバージョンはサポートされていません。
  4. Install をクリックします。
  5. Install Operator ページで、インストールオプションを選択します。

    1. OpenShift Elasticsearch Operator の場合は、Update Channel セクションで stable-5.x を選択します。
    2. Jaeger、Kiali、および Red Hat OpenShift Service Mesh Operator については、デフォルトを受け入れます。

      Jaeger、Kiali および Red Hat OpenShift Service Mesh Operator は openshift-operators namespace にインストールされます。OpenShift Elasticsearch Operator は openshift-operators-redhat namespace にインストールされます。

  6. Install をクリックします。Operator がインストールされるまで待機してから、一覧で次に来る Operator で手順を繰り返します。
  7. 4 つの Operator すべてをインストールしたら、Operators Installed Operators をクリックし、Operator がインストールされていることを確認します。

1.6.3. 次のステップ

ServiceMeshControlPlane リソースを作成し、サービスメッシュのコンポーネントを設定します。詳細は、「ServiceMeshControlPlane の作成」を参照してください。

1.7. ServiceMeshControlPlane の作成

OpenShift Container Platform Web コンソールを使用するか、または oc クライアントツールを使用してコマンドラインから ServiceMeshControlPlane の基本的なインストールをデプロイできます。

注記

サービスメッシュに関するドキュメントは istio-system をサンプルプロジェクトとして使用しますが、サービスメッシュを任意のプロジェクトにデプロイできます。

注記

この基本的なインストールはデフォルトの OpenShift 設定に基づいて設定され、実稼働環境での使用を目的としていません。このデフォルトインストールを使用してインストールを確認し、お使いの環境に ServiceMeshControlPlane を設定します。

1.7.1. Web コンソールを使用したコントロールプレーンのデプロイ

Web コンソールを使用して基本的な ServiceMeshControlPlane をデプロイできます。この例では、istio-system は、コントロールプレーンプロジェクトです。

前提条件

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

手順

  1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
  2. istio-system という名前のプロジェクトを作成します。

    1. HomeProjects に移動します。
    2. Create Project をクリックします。
    3. Name フィールドに istio-system と入力します。ServiceMeshControlPlane リソースは、マイクロサービスおよび Operator とは異なるプロジェクトにインストールする必要があります。

      これらのステップは istio-system を例として使用しますが、サービスが含まれるプロジェクトから分離されない限り、コントロールプレーンを任意のプロジェクトにデプロイすることができます。

    4. Create をクリックします。
  3. OperatorsInstalled Operators に移動します。
  4. Red Hat OpenShift Service Mesh Operator をクリックした後に、Istio Service Mesh Plane をクリックします。
  5. Istio Service Mesh Control Plane タブで Create ServiceMeshControlPlane をクリックします。
  6. Create ServiceMeshControlPlane ページで、デフォルトのコントロールプレーンバージョンを受け入れて、製品の最新バージョンで利用可能な機能を活用します。コントロールプレーンのバージョンは、Operator のバージョンに関係なく利用可能な機能を判別します。

    ServiceMeshControlPlane 設定は後で設定できます。詳細は、「Red Hat OpenShift Service Mesh の設定」を参照してください。

    1. Create をクリックします。Operator は、設定パラメーターに基づいて Pod、サービス、サービスメッシュコントロールプレーンのコンポーネントを作成します。
  7. Istio Service Mesh Control Plane タブをクリックしてコントロールプレーンが正常にインストールされることを確認します。

    1. 新規コントロールプレーンの名前をクリックします。
    2. Resources タブをクリックして、Red Hat OpenShift Service Mesh コントロールプレーンリソース (Operator が作成し、設定したもの) を表示します。

1.7.2. CLI からのコントロールプレーンのデプロイ

コマンドラインから基本的な ServiceMeshControlPlane をデプロイできます。

前提条件

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

手順

  1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。

    $ oc login https://{HOSTNAME}:6443
  2. istio-system という名前のプロジェクトを作成します。

    $ oc new-project istio-system
  3. 以下の例を使用して istio-installation.yaml という名前の ServiceMeshControlPlane ファイルを作成します。コントロールプレーンのバージョンは、Operator のバージョンに関係なく利用可能な機能を判別します。

    バージョン 2.0 istio-installation.yaml の例

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    metadata:
      name: basic
      namespace: istio-system
    spec:
      version: v2.0
      tracing:
        type: Jaeger
        sampling: 10000
      addons:
        jaeger:
          name: jaeger
          install:
            storage:
              type: Memory
        kiali:
          enabled: true
          name: kiali
        grafana:
          enabled: true

  4. 以下のコマンドを実行してコントロールプレーンをデプロイします。ここで、<istio_installation.yaml> にはファイルへの完全パスが含まれます。

    $ oc create -n istio-system -f <istio_installation.yaml>
  5. 以下のコマンドを実行してコントロールプレーンのインストールを確認します。

    $ oc get smcp -n istio-system

    STATUS 列が ComponentsReady の場合、インストールは正常に終了しています。

Red Hat OpenShift Service Mesh はクラスター内で複数の独立したコントロールプレーンをサポートします。ServiceMeshControlPlane プロファイルを使用すると、再利用可能な設定を作成することができます。詳細は、「コントロールプレーンプロファイルの作成」を参照してください。

1.7.3. 次のステップ

ServiceMeshMemberRoll リソースを作成し、サービスメッシュに関連付けられた namespace を指定します。詳細は、サービスメッシュへのサービスの追加 を参照してください。

1.8. サービスメッシュへのサービスの追加

Operator および ServiceMeshControlPlane リソースのインストール後に、ServiceMeshMemberRoll リソースを作成し、コンテンツが置かれている namespace を指定して、アプリケーション、ワークロード、またはサービスをメッシュに追加します。ServiceMeshMemberRoll リソースに追加するアプリケーション、ワークフロー、またはサービスがすでにある場合には、以下の手順に従います。または、Bookinfo と呼ばれるサンプルアプリケーションをインストールして ServiceMeshMemberRoll リソースに追加するには、Bookinfo サンプルアプリケーション のチュートリアルまで進み、アプリケーションが Red Hat OpenShift Service Mesh でどのように機能するかを確認します。

ServiceMeshMemberRoll リソースに記載される項目は、ServiceMeshControlPlane リソースで管理されるアプリケーションおよびワークフローです。コントロールプレーン (サービスメッシュ Operator、Istiod、および ServiceMeshControlPlane)およびデータプレーン (アプリケーションおよび Envoy プロキシー) は別々の namespace にある必要があります。

注記

namespace を ServiceMeshMemberRoll に追加した後に、その namespace のサービスまたは Pod へのアクセスはサービスメッシュ外の呼び出し元からアクセスできません。

1.8.1. Red Hat OpenShift Service Mesh メンバーロールの作成

ServiceMeshMemberRoll は、コントロールプレーンに属するプロジェクトを一覧表示します。ServiceMeshMemberRoll に一覧表示されているプロジェクトのみがコントロールプレーンの影響を受けます。プロジェクトは、特定のコントロールプレーンのデプロイメント用にメンバーロールに追加するまでサービスメッシュに属しません。

istio-system など、ServiceMeshControlPlane と同じプロジェクトに、 default という名前の ServiceMeshMemberRoll リソースを作成する必要があります。

1.8.1.1. Web コンソールからのメンバーロールの作成

Web コンソールを使用して 1 つ以上のプロジェクトを Service Mesh メンバーロールに追加します。この例では、istio-system は、コントロールプレーンプロジェクトです。

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. メッシュのサービスがない場合や、ゼロから作業を開始する場合は、アプリケーションのプロジェクトを作成します。これは、コントロールプレーンをインストールしたプロジェクトとは異なる必要があります。

    1. HomeProjects に移動します。
    2. Name フィールドに名前を入力します。
    3. Create をクリックします。
  3. OperatorsInstalled Operators に移動します。
  4. Project メニューをクリックし、一覧から ServiceMeshControlPlane リソースがデプロイされているプロジェクト (例: istio-system) を選択します。
  5. Red Hat OpenShift Service Mesh Operator をクリックします。
  6. Istio Service Mesh Member Roll タブをクリックします。
  7. Create ServiceMeshMemberRoll をクリックします。
  8. Members をクリックし、Value フィールドにプロジェクトの名前を入力します。任意の数のプロジェクトを追加できますが、プロジェクトは 単一ServiceMeshMemberRoll リソースしか属することができません。
  9. Create をクリックします。

1.8.1.2. CLI からのメンバーロールの作成

コマンドラインからプロジェクトを ServiceMeshMemberRoll に追加します。

前提条件

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

手順

  1. OpenShift Container Platform CLI にログインします。

    $ oc login https://{HOSTNAME}:6443
  2. メッシュのサービスがない場合や、ゼロから作業を開始する場合は、アプリケーションのプロジェクトを作成します。これは、コントロールプレーンをインストールしたプロジェクトとは異なる必要があります。

    $ oc new-project {your-project}
  3. プロジェクトをメンバーとして追加するには、以下の YAML の例を変更します。任意の数のプロジェクトを追加できますが、プロジェクトは 単一ServiceMeshMemberRoll リソースしか属することができません。この例では、istio-system は、コントロールプレーンプロジェクトです。

    servicemeshmemberroll-default.yaml の例

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system
    spec:
      members:
        # a list of projects joined into the service mesh
        - your-project-name
        - another-project-name

  4. 以下のコマンドを実行して、istio-system namespace に ServiceMeshMemberRoll リソースをアップロードおよび作成します。

    $ oc create -n istio-system -f servicemeshmemberroll-default.yaml
  5. 以下のコマンドを実行して、ServiceMeshMemberRoll が正常に作成されていることを確認します。

    $ oc get smmr -n istio-system default

    STATUS 列が Configured の場合には、インストールは正常に終了しています。

1.8.2. サービスメッシュからのプロジェクトの追加または削除

Web コンソールを使用して既存の Service Mesh ServiceMeshMemberRoll リソースを追加または削除できます。

  • 任意の数のプロジェクトを追加できますが、プロジェクトは 単一ServiceMeshMemberRoll リソースしか属することができません。
  • ServiceMeshMemberRoll リソースは、対応する ServiceMeshControlPlane リソースが削除されると削除されます。

1.8.2.1. Web コンソールを使用したメンバーロールからのプロジェクトの追加または削除

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. OperatorsInstalled Operators に移動します。
  3. Project メニューをクリックし、一覧から ServiceMeshControlPlane リソースがデプロイされているプロジェクト (例: istio-system) を選択します。
  4. Red Hat OpenShift Service Mesh Operator をクリックします。
  5. Istio Service Mesh Member Roll タブをクリックします。
  6. default リンクをクリックします。
  7. YAML タブをクリックします。
  8. YAML を変更して、プロジェクトをメンバーとして追加または削除します。任意の数のプロジェクトを追加できますが、プロジェクトは 単一ServiceMeshMemberRoll リソースしか属することができません。
  9. Save をクリックします。
  10. Reload をクリックします。

1.8.2.2. CLI を使用したメンバーロールからのプロジェクトの追加または削除

コマンドラインを使用して既存の Service Mesh Member Roll を変更できます。

前提条件

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

手順

  1. OpenShift Container Platform CLI にログインします。
  2. ServiceMeshMemberRoll リソースを編集します。

    $ oc edit smmr -n <controlplane-namespace>
  3. YAML を変更して、プロジェクトをメンバーとして追加または削除します。任意の数のプロジェクトを追加できますが、プロジェクトは 単一ServiceMeshMemberRoll リソースしか属することができません。

    servicemeshmemberroll-default.yaml の例

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system #control plane project
    spec:
      members:
        # a list of projects joined into the service mesh
        - your-project-name
        - another-project-name

1.8.3. Bookinfo のサンプルアプリケーション

Bookinfo のサンプルアプリケーションでは、OpenShift Container Platform での Red Hat OpenShift Service Mesh 2.0.8 のインストールをテストすることができます。

Bookinfo アプリケーションは、オンラインブックストアの単一カタログエントリーのように、書籍に関する情報を表示します。このアプリケーションでは、書籍の説明、書籍の詳細 (ISBN、ページ数その他の情報)、および書評のページが表示されます。

Bookinfo アプリケーションはこれらのマイクロサービスで構成されます。

  • productpage マイクロサービスは、detailsreviews マイクロサービスを呼び出して、ページを設定します。
  • details マイクロサービスには書籍の情報が含まれています。
  • reviews マイクロサービスには、書評が含まれます。これは ratings マイクロサービスも呼び出します。
  • ratings マイクロサービスには、書評を伴う書籍のランキング情報が含まれます。

reviews マイクロサービスには、以下の 3 つのバージョンがあります。

  • バージョン v1 は、ratings サービスを呼び出しません。
  • バージョン v2 は、ratings サービスを呼び出して、各評価を 1 から 5 の黒い星で表示します。
  • バージョン v3 は、ratings サービスを呼び出して、各評価を 1 から 5 の赤い星で表示します。

1.8.3.1. Bookinfo アプリケーションのインストール

このチュートリアルでは、プロジェクトの作成、そのプロジェクトへの Bookinfo アプリケーションのデプロイ、サービスメッシュでの実行中のアプリケーションの表示を行い、サンプルアプリケーションを作成する方法を説明します。

前提条件:

  • OpenShift Container Platform 4.1 以降がインストールされている。
  • Red Hat OpenShift Service Mesh 2.0.8 がインストールされている。
  • oc として知られる OpenShift Container Platform コマンドラインインターフェース (CLI) へのアクセス。
  • cluster-admin ロールを持つアカウントが必要です。
注記

Bookinfo サンプルアプリケーションは、IBM Z および IBM Power Systems にインストールできません。

手順

  1. cluster-admin 権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
  2. HomeProjects をクリックします。
  3. Create Project をクリックします。
  4. Project Name として bookinfo を入力し、Display Name を入力します。その後、Description を入力し、Create をクリックします。

    • または、CLI からこのコマンドを実行して、bookinfo プロジェクトを作成できます。

      $ oc new-project bookinfo
  5. OperatorsInstalled Operators をクリックします。
  6. Project メニューをクリックし、コントロールプレーンの namespace を使用します。この例では istio-system を使用します。
  7. Red Hat OpenShift Service Mesh Operator をクリックします。
  8. Istio Service Mesh Member Roll タブをクリックします。

    1. Istio Service Mesh Member Roll がすでに作成されている場合には、名前をクリックしてから YAML タブをクリックし、YAML エディターを開きます。
    2. ServiceMeshMemberRoll を作成していない場合は、Create ServiceMeshMemberRoll をクリックします。
  9. Members をクリックし、Value フィールドにプロジェクトの名前を入力します。
  10. Create をクリックして、更新した Service Mesh Member Roll を保存します。

    1. または、以下のサンプルを YAML ファイルに保存します。

      Bookinfo ServiceMeshMemberRoll の例 (servicemeshmemberroll-default.yaml)

      apiVersion: maistra.io/v1
      kind: ServiceMeshMemberRoll
      metadata:
        name: default
      spec:
        members:
        - bookinfo

    2. 以下のコマンドを実行して、そのファイルをアップロードし、istio-system namespace に ServiceMeshMemberRoll リソースを作成します。この例では、istio-system は、コントロールプレーンプロジェクトです。

      $ oc create -n istio-system -f servicemeshmemberroll-default.yaml
  11. 以下のコマンドを実行して、ServiceMeshMemberRoll が正常に作成されていることを確認します。

    $ oc get smmr -n istio-system

    STATUS 列が Configured の場合には、インストールは正常に終了しています。

    NAME      READY   STATUS       AGE
    default   1/1     Configured   2m27s
  12. CLI で 'bookinfo' プロジェクトに Bookinfo アプリケーションをデプロイするには、bookinfo.yaml ファイルを適用します。

    $ oc apply -n bookinfo -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.0/samples/bookinfo/platform/kube/bookinfo.yaml

    以下のような出力が表示されるはずです。

    service/details created
    serviceaccount/bookinfo-details created
    deployment.apps/details-v1 created
    service/ratings created
    serviceaccount/bookinfo-ratings created
    deployment.apps/ratings-v1 created
    service/reviews created
    serviceaccount/bookinfo-reviews created
    deployment.apps/reviews-v1 created
    deployment.apps/reviews-v2 created
    deployment.apps/reviews-v3 created
    service/productpage created
    serviceaccount/bookinfo-productpage created
    deployment.apps/productpage-v1 created
  13. bookinfo-gateway.yaml ファイルを適用して Ingress ゲートウェイを作成します。

    $ oc apply -n bookinfo -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.0/samples/bookinfo/networking/bookinfo-gateway.yaml

    以下のような出力が表示されるはずです。

    gateway.networking.istio.io/bookinfo-gateway created
    virtualservice.networking.istio.io/bookinfo created
  14. GATEWAY_URL パラメーターの値を設定します。

    注記

    <control_plane_project> をコントロールプレーンプロジェクトの名前に置き換えます。この例では、コントロールプレーンプロジェクトは istio-system です。

    $ export GATEWAY_URL=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.host}')

1.8.3.2. デフォルトの宛先ルールの追加

Bookinfo アプリケーションを使用するには、先にデフォルトの宛先ルールを追加する必要があります。相互トランスポート層セキュリティー (TLS) 認証を有効にしたかどうかによって、2 つの事前設定される YAML ファイルを使用できます。

手順

  1. 宛先ルールを追加するには、以下のいずれかのコマンドを実行します。

    • 相互 TLS を有効にしていない場合:

      $ oc apply -n bookinfo -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.0/samples/bookinfo/networking/destination-rule-all.yaml
    • 相互 TLS を有効にしている場合:

      $ oc apply -n bookinfo -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.0/samples/bookinfo/networking/destination-rule-all-mtls.yaml

      以下のような出力が表示されるはずです。

      destinationrule.networking.istio.io/productpage created
      destinationrule.networking.istio.io/reviews created
      destinationrule.networking.istio.io/ratings created
      destinationrule.networking.istio.io/details created

1.8.3.3. Bookinfo インストールの検証

Bookinfo アプリケーションのサンプルが正常にデプロイされたことを確認するには、以下の手順を実行します。

前提条件

  • Red Hat OpenShift Service Mesh 2.0.8 がインストールされている。
  • oc として知られる OpenShift Container Platform コマンドラインインターフェース (CLI) へのアクセス。
  • Bookinfo サンプルアプリケーションのインストール手順を実行します。

手順

  1. OpenShift Container Platform CLI にログインします。
  2. 以下のコマンドですべての Pod が準備状態にあることを確認します。

    $ oc get pods -n bookinfo

    すべての Pod のステータスは Running である必要があります。以下のような出力が表示されるはずです。

    NAME                              READY   STATUS    RESTARTS   AGE
    details-v1-55b869668-jh7hb        2/2     Running   0          12m
    productpage-v1-6fc77ff794-nsl8r   2/2     Running   0          12m
    ratings-v1-7d7d8d8b56-55scn       2/2     Running   0          12m
    reviews-v1-868597db96-bdxgq       2/2     Running   0          12m
    reviews-v2-5b64f47978-cvssp       2/2     Running   0          12m
    reviews-v3-6dfd49b55b-vcwpf       2/2     Running   0          12m
  3. 以下のコマンドを実行して、製品ページの URL を取得します。

    echo "http://$GATEWAY_URL/productpage"
  4. Web ブラウザーで出力をコピーして貼り付けて、Bookinfo の製品ページがデプロイされていることを確認します。

1.8.3.4. Bookinfo アプリケーションの削除

以下の手順で、Bookinfo アプリケーションを削除します。

前提条件

  • OpenShift Container Platform 4.1 以降がインストールされている。
  • Red Hat OpenShift Service Mesh 2.0.8 がインストールされている。
  • oc として知られる OpenShift Container Platform コマンドラインインターフェース (CLI) へのアクセス。
1.8.3.4.1. Bookinfo プロジェクトの削除

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. HomeProjects をクリックします。
  3. bookinfo メニュー kebab をクリックしてから Delete Project をクリックします。
  4. 確認ダイアログボックスに bookinfo と入力してから Delete をクリックします。

    • または、CLI からこのコマンドを実行して、bookinfo プロジェクトを作成できます。

      $ oc delete project bookinfo
1.8.3.4.2. Service Mesh Member Roll からの Bookinfo プロジェクトの削除

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. OperatorsInstalled Operators をクリックします。
  3. Project メニューをクリックし、一覧から openshift-operators を選択します。
  4. Red Hat OpenShift Service Mesh Operator の Provided APIS で、Istio Service Mesh Member Roll のリンクをクリックします。
  5. ServiceMeshMemberRoll メニュー kebab をクリックし、Edit Service Mesh Member Roll を選択します。
  6. デフォルトの Service Mesh Member Roll YAML を編集し、members 一覧から bookinfo を削除します。

    • または、CLI からこのコマンドを実行して、ServiceMeshMemberRoll から bookinfo プロジェクトを削除できます。この例では、istio-system は、コントロールプレーンプロジェクトです。

      $ oc -n istio-system patch --type='json' smmr default -p '[{"op": "remove", "path": "/spec/members", "value":["'"bookinfo"'"]}]'
  7. Save をクリックして、Service Mesh Member Roll を更新します。

1.8.4. 次のステップ

1.9. サイドカーコンテナーの挿入の有効化

サービスをメッシュに追加したら、アプリケーションのデプロイメントリソースでのサイドカーコンテナーの自動挿入を有効にします。デプロイメントごとにサイドカーコンテナーの自動挿入を有効にする必要があります。

Bookinfo サンプルアプリケーションのインストールが完了している場合は、アプリケーションはデプロイ済みで、サイドカーは挿入されています。独自のプロジェクトおよびサービスを使用している場合は、アプリケーションを OpenShift Container Platform にデプロイします。詳細は、「デプロイメントと DeploymentConfig オブジェクトについて」を参照してください。

1.9.1. 前提条件

1.9.2. サイドカーコンテナーの自動挿入の有効化

アプリケーションをデプロイする場合には、sidecar.istio.io/inject アノテーションを "true" に設定して、挿入をオプトインする必要があります。オプトインにより、サイドカーコンテナーの挿入が OpenShift エコシステム内の複数のフレームワークが使用する、ビルダー Pod などの他の OpenShift 機能に干渉しないようにします。

前提条件

  • 自動のサイドカーコンテナー挿入を有効にするデプロイメントを特定します。

手順

  1. エディターでアプリケーションのデプロイメント設定の YAML ファイルを開きます。デプロイメントを検索するには、oc get コマンドを使用します。たとえば、sleep namespace で sleep というアプリケーションの場合には、以下のコマンドを使用して、YAML 形式でリソースを表示します。

    oc get deployment sleep -o yaml
  2. spec.template.metadata.annotations.sidecar.istio/inject フィールドで "true" の値が含まれる設定 YAML に、sidecar.istio.io/inject を追加します。sleep というアプリケーションについては、以下の例を参照してください。

    スリープテストアプリケーションの例 (sleep.yaml)

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: sleep
      name: sleep
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: sleep
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "true"
          labels:
            app: sleep
        spec:
          containers:
          - name: sleep
            image: curlimages/curl
            command: ["/bin/sleep","3650d"]
            imagePullPolicy: IfNotPresent

  3. 設定を保存します。
  4. ファイルをアプリケーションが含まれるプロジェクトに追加し直します。この例では、sleep は、sleep アプリを含むプロジェクト名で、sleep.yaml は、編集したファイルを指します。

    $ oc apply -n sleep -f sleep.yaml
  5. リソースが正常にアップロードされたことを確認するには、以下のコマンドを実行します。

    oc get deployment sleep -o yaml

1.9.3. アプリケーション Pod の更新

Operator をインストールする際に Automatic Approval Strategy を選択した場合には、Operator はコントロールプレーンを自動的に更新しますが、アプリケーションを更新しません。既存のアプリケーションは、引き続きメッシュの一部になり、それに応じて機能します。アプリケーション管理者は、サイドカーコンテナーをアップグレードするためにアプリケーションを再起動する必要があります。

デプロイメントで自動のサイドカーコンテナー挿入を使用する場合、アノテーションを追加または変更してデプロイメントの Pod テンプレートを更新することができます。以下のコマンドを実行して Pod を再デプロイします。

$ oc patch deployment/<deployment> -p '{"spec":{"template":{"metadata":{"annotations":{"kubectl.kubernetes.io/restartedAt": "'`date -Iseconds`'"}}}}}'

デプロイメントで自動のサイドカーコンテナー挿入を使用しない場合、デプロイメントまたは Pod で指定されたサイドカーコンテナーイメージを変更してサイドカーコンテナーを手動で更新する必要があります。

1.9.4. アノテーションを使用したアプリケーションのプロキシーでの環境変数の設定

デプロイメントの Pod アノテーションを injection-template.yaml ファイルに追加することにより、アプリケーションのサイドカープロキシーで環境変数を設定できます。環境変数がサイドカーコンテナーに挿入されます。

injection-template.yaml の例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: resource
spec:
  replicas: 7
  selector:
    matchLabels:
      app: resource
  template:
    metadata:
      annotations:
        sidecar.maistra.io/proxyEnv: "{ \"maistra_test_env\": \"env_value\", \"maistra_test_env_2\": \"env_value_2\" }"

警告

maistra.io/ ラベルおよびアノテーションは、ユーザーによって作成されるリソースに含めることはできません。それらはリソースが Operator によって生成され、管理されることを示すためです。独自のリソースの作成時に Operator で生成されるリソースからコンテンツをコピーする場合、maistra.io/ で始まるラベルやアノテーションを含めることはできません。さもないと、リソースが次の調整時に Operator によって上書きまたは削除されます。

1.9.5. 次のステップ

ご使用の環境用に Red Hat OpenShift Service Mesh 機能を設定します。

1.10. Red Hat OpenShift Service Mesh のバージョン 1.1 から 2.0 への更新

バージョン 1.1 から 2.0 にアップグレードするには、ワークロードおよびアプリケーションを新規バージョンを実行する Red Hat OpenShift Service Mesh の新規インスタンスに移行する手動の手順が必要です。

前提条件

  • 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 で機能を使用するために実行する必要のある手順があります。

1.10.1. Red Hat OpenShift Service Mesh のアップグレード

Red Hat OpenShift Service Mesh をアップグレードするには、新規の namespace に Red Hat OpenShift Service Mesh ServiceMeshControlPlane 2.0 リソースのインスタンスを作成する必要があります。次に、設定後にマイクロサービスアプリケーションおよびワークロードを古いメッシュから新規のサービスメッシュに移動します。

手順

  1. v1 ServiceMeshControlPlane リソース設定をチェックし、これが有効であることを確認します。

    1. 以下のコマンドを実行して、ServiceMeshControlPlane リソースを v2 リソースとして表示します。

      $ oc get smcp -o yaml
    2. 無効なフィールドについての情報は、出力の spec.techPreview.errored.message フィールドを確認してください。
    3. v1 リソースに無効なフィールドがある場合、リソースは調整されず、v2 リソースとして編集することはできません。v2 フィールドへの更新はすべて、元の v1 設定で上書きされます。無効なフィールドを修正するには、リソースの v1 バージョンを置き換えるか、パッチを適用するか、または編集できます。リソースを修正せずに削除することもできます。リソースの修正後に調整でき、リソースの v2 バージョンを変更または表示できます。
    4. ファイルを編集してリソースを修正するには、oc get を使用してリソースを取得し、テキストファイルをローカルで編集し、リソースを編集したファイルに置き換えます。

      $ oc get smcp.v1.maistra.io <smcp_name> > smcp-resource.yaml
      #Edit the smcp-resource.yaml file.
      $ oc replace -f smcp-resource.yaml
    5. パッチを使用してリソースを修正するには、oc patch を使用します。

      $ oc patch smcp.v1.maistra.io <smcp_name> --type json --patch '[{"op": "replace","path":"/spec/path/to/bad/setting","value":"corrected-value"}]'
    6. コマンドラインツールで編集してリソースを修正するには、oc edit を使用します。

      $ oc edit smcp.v1.maistra.io <smcp_name>
  2. コントロールプレーンの設定のバックアップします。ServiceMeshControlPlane リソースが含まれるプロジェクトに切り替えます。この例では、istio-system は、コントロールプレーンプロジェクトです。

    $ oc project istio-system
  3. 以下のコマンドを実行して、現在の設定を取得します。<smcp_name> は ServiceMeshControlPlane リソースのメタデータに指定されます (例: basic-install または full-install)。

    $ oc get servicemeshcontrolplanes.v1.maistra.io <smcp_name> -o yaml > <smcp_name>.v1.yaml
  4. ServiceMeshControlPlane を、開始点としての設定についての情報が含まれる v2 のコントロールプレーンバージョンに変換します。

    $ oc get smcp <smcp_name> -o yaml > <smcp_name>.v2.yaml
  5. プロジェクトを作成します。OpenShift Container Platform コンソールの Project メニューで、New Project をクリックし、プロジェクトの名前 (例: istio-system-upgrade) を入力します。または、CLI からこのコマンドを実行できます。

    $ oc new-project istio-system-upgrade
  6. v2 ServiceMeshControlPlanemetadata.namespace フィールドを新規のプロジェクト名で更新します。この例では、istio-system-upgrade を使用します。
  7. version フィールドを 1.1 から 2.0 に更新するか、または v2 ServiceMeshControlPlane でこれを削除します。
  8. 新規 namespace に ServiceMeshControlPlane を作成します。コマンドラインで以下のコマンドを実行し、取得した ServiceMeshControlPlane の v2 バージョンでコントロールプレーンをデプロイします。この例では、`<smcp_name.v2> ` をファイルへのパスに置き換えます。

    $ oc create -n istio-system-upgrade -f <smcp_name>.v2.yaml

    または、コンソールを使用してコントロールプレーンを作成できます。OpenShift Container Platform Web コンソールで、 Project をクリックします。次に、入力したプロジェクト名を選択します。

    1. OperatorsInstalled Operators をクリックします。
    2. Create ServiceMeshControlPlane をクリックします。
    3. YAML view を選択し、取得した YAML ファイルのテキストをフィールドに貼り付けます。apiVersion フィールドが maistra.io/v2 に設定されていることを確認し、metadata.namespace フィールドを新規 namespace (例: istio-system-upgrade) を使用するように変更します。
    4. Create をクリックします。

1.10.2. 2.0 ServiceMeshControlPlane の設定

ServiceMeshControlPlane リソースは Red Hat OpenShift Service Mesh バージョン 2.0 用に変更されました。ServiceMeshControlPlane リソースの v2 バージョンを作成したら、新機能を利用し、デプロイメントを適合させるようにこれを変更します。ServiceMeshControlPlane リソースを変更するため、Red Hat OpenShift Service Mesh 2.0 の仕様および動作に以下の変更を加えることを検討してください。使用する機能の更新情報については、Red Hat OpenShift Service Mesh 2.0 の製品ドキュメントを参照してください。v2 リソースは、Red Hat OpenShift Service Mesh 2.0 インストールに使用する必要があります。

1.10.2.1. アーキテクチャーの変更

以前のバージョンで使用されるアーキテクチャーのユニットは Istiod によって置き換えられました。2.0 では、コントロールプレーンのコンポーネント Mixer、Pilot、Citadel、Galley、およびサイドカーインジェクター機能が単一のコンポーネントである Istiod に統合されました。

Mixer はコントロールプレーンコンポーネントとしてサポートされなくなりましたが、Mixer ポリシーおよび Telemetry プラグインは Istiod の WASM 拡張でサポートされるようになりました。レガシー Mixer プラグインを統合する必要がある場合は、ポリシーと Telemetry に対して Mixer を有効にすることができます。

シークレット検出サービス (SDS) は、証明書とキーを Istiod からサイドカーコンテナーに直接配信するために使用されます。Red Hat OpenShift Service Mesh バージョン 1.1 では、シークレットはクライアント証明書およびキーを取得するためにプロキシーによって使用される Citadel で生成されました。

1.10.2.2. アノテーションの変更

v2.0 では、以下のアノテーションに対応しなくなりました。これらのアノテーションのいずれかを使用している場合は、これを v2.0 コントロールプレーンに移行する前にワークロードを更新する必要があります。

  • sidecar.maistra.io/proxyCPULimitsidecar.istio.io/proxyCPULimit に置き換えられました。ワークロードで sidecar.maistra.io アノテーションを使用していた場合は、代わりに sidecar.istio.io を使用するようにこれらのワークロードを変更する必要があります。
  • sidecar.maistra.io/proxyMemoryLimitsidecar.istio.io/proxyMemoryLimit に置き換えられました。
  • sidecar.istio.io/discoveryAddress はサポートされなくなりました。また、デフォルトの検出アドレスが pilot.<control_plane_namespace>.svc:15010 (または mtls が有効にされている場合はポート 15011) から istiod-<smcp_name>.<control_plane_namespace>.svc:15012 に移行しました。
  • ヘルスステータスポートは設定できなくなり、15021 にハードコーディングされています。* カスタムステータスポート (例: status.sidecar.istio.io/port) を定義している場合、ワークロードを v2.0 コントロールプレーンに移行する前にオーバーライドを削除する必要があります。ステータスポートを 0 に設定すると、readiness チェックを依然として無効にできます。
  • Kubernetes シークレットリソースは、サイドカーのクライアント証明書を配信するために使用されなくなりました。証明書は Istiod の SDS サービスを介して配信されるようになりました。マウントされたシークレットに依存している場合、それらは v2.0 コントロールプレーンのワークロードで利用不可になります。

1.10.2.3. 動作上の変更

Red Hat OpenShift Service Mesh 2.0 の機能の一部は、以前のバージョンの機能とは異なります。

  • ゲートウェイの readiness ポートは 15020 から 15021 に移行しました。
  • ターゲットホストの可視性には、VirtualService と ServiceEntry リソースが含まれます。これには、Sidecar リソースを介して適用される制限が含まれます。
  • 自動の相互 TLS はデフォルトで有効になります。プロキシー間の通信は、実施されているグローバルの PeerAuthentication ポリシーに関係なく、mTLS を使用するように自動的に設定されます。
  • セキュアな接続は、spec.security.controlPlane.mtls 設定に関係なく、プロキシーがコントロールプレーンと通信する際に常に使用されます。spec.security.controlPlane.mtls 設定は、Mixer Telemetry またはポリシーの接続を設定する場合にのみ使用されます。

1.10.2.4. サポート対象外のリソースの移行情報

Policy (authentication.istio.io/v1alpha1)

Policy リソースは、v2.0 コントロールプレーン、PeerAuthentication および RequestAuthentication で使用するために新規リソースタイプに移行する必要があります。Policy リソースの特定の設定によっては、同じ効果を実現するために複数のリソースを設定しなければならない場合があります。

相互 TLS

相互 TLS は、security.istio.io/v1beta1 PeerAuthentication リソースを使用して実行されます。レガシーの spec.peers.mtls.mode フィールドは、新規リソースの spec.mtls.mode フィールドに直接マップされます。選定基準は、spec.targets[x].name のでのサービス名の指定から spec.selector.matchLabels のラベルセレクターに変更されました。PeerAuthentication では、ラベルは、ターゲット一覧で名前が指定されたサービスのセレクターと一致する必要があります。ポート固有の設定は spec.portLevelMtls にマップされる必要があります。

認証

spec.origins に指定される追加の認証方法は、security.istio.io/v1beta1 RequestAuthentication リソースにマップされる必要があります。spec.selector.matchLabels は PeerAuthentication の同じフィールドに対して同様に設定される必要があります。spec.origins.jwt アイテムからの JWT プリンシパルに固有の設定は、spec.rules アイテムの同様のフィールドにマップされます。

  • Policy で指定される spec.origins[x].jwt.triggerRules は 1 つ以上の security.istio.io/v1beta1 AuthorizationPolicy リソースにマップされる必要があります。spec.selector.labels は、RequestAuthentication の同じフィールドに対して同様に設定される必要があります。
  • spec.origins[x].jwt.triggerRules.excludedPaths は AuthorizationPolicy にマップされる必要があります。ここで、spec.rules[x].to.operation.path エントリーは除外されたパスに一致する状態で spec.action が ALLOW に設定されます。
  • spec.origins[x].jwt.triggerRules.includedPaths は別個の AuthorizationPolicy にマップされる必要があります。ここで、spec.rules[x].to.operation.path エントリーは組み込まれるパスに一致し、specified spec.origins[x].jwt.issuer と一致するspec.rules.[x].from.source.requestPrincipals エントリーが Policy リソースにある状態で、spec.actionALLOW に設定されます。

ServiceMeshPolicy (maistra.io/v1)

ServiceMeshPolicy は、v1 リソースの spec.istio.global.mtls.enabled または v2 リソース設定の spec.security.dataPlane.mtls でコントロールプレーンに自動的に設定されています。v2 コントロールプレーンの場合、機能的に同等の PeerAuthentication リソースがインストール時に作成されます。この機能は、Red Hat OpenShift Service Mesh バージョン 2.0 で非推奨となりました。

RbacConfig, ServiceRole, ServiceRoleBinding (rbac.istio.io/v1alpha1)

これらのリソースは security.istio.io/v1beta1 AuthorizationPolicy リソースに置き換えられました。

RbacConfig の動作をコピーするには、RbacConfig で指定される spec.mode に依存するデフォルトの AuthorizationPolicy を作成する必要があります。

  • spec.modeOFF に設定されている場合、AuthorizationPolicy が要求に適用されない限り、デフォルトのポリシーが ALLOW であるためリソースは必要ありません。
  • spec.mode が ON に設定されている場合、spec: {} を設定します。メッシュ内のすべてのサービスに対して AuthorizationPolicy ポリシーを作成する必要があります。
  • spec.modeON_WITH_INCLUSION に設定されている場合、 spec: {} が組み込まれている各 namespace に指定された状態で AuthorizationPolicy を作成する必要があります。AuthorizationPolicy では、個別のサービスを含めることはサポートされません。ただし、サービスのワークロードに適用される AuthorizationPolicy が作成されるとすぐに、明示的に許可されない他のすべての要求は拒否されます。
  • spec.modeON_WITH_EXCLUSION に設定されている場合、これは AuthorizationPolicy によってサポートされません。グローバル DENY ポリシーを作成できますが、namespace またはワークロードのいずれかに適用できる allow-all ポリシーがないため、メッシュ内のすべてのワークロードに対して AuthorizationPolicy を作成する必要があります。

AuthorizationPolicy には、ServiceRoleBinding が提供する機能と同様の、設定が適用されるセレクターと、ServiceRole が提供する機能と同様の、適用する必要のあるルールの両方の設定が含まれます。

ServiceMeshRbacConfig (maistra.io/v1)

このリソースは、コントロールプレーンの namespace で security.istio.io/v1beta1 AuthorizationPolicy リソースを使用して置き換えられます。このポリシーは、メッシュ内のすべてのワークロードに適用されるデフォルトの認証ポリシーになります。特定の移行の詳細については、上記の RbacConfig を参照してください。

1.10.2.5. Mixer プラグイン

Mixer コンポーネントは、バージョン 2.0 ではデフォルトで無効にされます。ワークロードで Mixer プラグインを使用する場合は、Mixer コンポーネントを含めるようにバージョン 2.0 ServiceMeshControlPlane を設定する必要があります。

Mixer ポリシーコンポーネントを有効にするには、以下のスニペットを ServiceMeshControlPlane に追加します。

spec:
  policy:
    type: Mixer

Mixer Telemetry コンポーネントを有効にするには、以下のスニペットを ServiceMeshControlPlane に追加します。

spec:
  telemetry:
    type: Mixer

レガシーの Mixer プラグインは、新しい ServiceMeshExtension (maistra.io/v1alpha1) カスタムリソースを使用して WASM に移行し、統合することもできます。

アップストリーム Istio ディストリビューションに含まれるビルトインの WASM フィルターは Red Hat OpenShift Service Mesh 2.0 では利用できません。

1.10.2.6. 相互 TLS の変更

ワークロード固有の PeerAuthentication ポリシーで mTLS を使用する場合、ワークロードポリシーが namespace/グローバルポリシーと異なる場合にトラフィックを許可するために、対応する DestinationRule が必要になります。

自動 mTLS はデフォルトで有効にされますが、spec.security.dataPlane.automtlsServiceMeshControlPlane リソースで false に設定して無効にできます。auto mTLS を無効にする場合、サービス間の適切な通信のために DestinationRules が必要になる場合があります。たとえば、1 つの namespace について PeerAuthentication を STRICT に設定すると、DestinationRule が namespace のサービスに TLS モードを設定しない限り、他の namespace のサービスがそれらにアクセスできなくなります。

mTLS について詳細は、「相互トランスポート層セキュリティー (mTLS) の有効化」を参照してください。

1.10.2.6.1. その他の mTLS の例

bookinfo サンプルアプリケーションで mTLS For productpage サービスを無効にするために、Policy リソースは Red Hat OpenShift Service Mesh v1.1 に対して以下の方法で設定されました。

Policy リソースの例

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: productpage-mTLS-disable
  namespace: <namespace>
spec:
  targets:
  - name: productpage

bookinfo サンプルアプリケーションで mTLS For productpage サービスを無効にするために、以下の例を使用して Red Hat OpenShift Service Mesh v2.0 の PeerAuthentication リソースを設定します。

PeerAuthentication リソースの例

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: productpage-mTLS-disable
  namespace: <namespace>
spec:
  mtls:
    mode: DISABLE
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage

bookinfo サンプルアプリケーションで productpage サービスについて mTLS With JWT 認証を有効にするために、Policy リソースが Red Hat OpenShift Service Mesh v1.1 に対して設定されました。

Policy リソースの例

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  targets:
  - name: productpage
    ports:
    - number: 9000
  peers:
  - mtls:
  origins:
  - jwt:
      issuer: "https://securetoken.google.com"
      audiences:
      - "productpage"
      jwksUri: "https://www.googleapis.com/oauth2/v1/certs"
      jwtHeaders:
      - "x-goog-iap-jwt-assertion"
      triggerRules:
      - excludedPaths:
        - exact: /health_check
  principalBinding: USE_ORIGIN

bookinfo サンプルアプリケーションの productpage サービスの mTLS With JWT 認証を有効にするために、以下の例を使用して Red Hat OpenShift Service Mesh v2.0 の PeerAuthentication リソースを設定します。

PeerAuthentication リソースの例

#require mtls for productpage:9000
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  portLevelMtls:
    9000:
      mode: STRICT
...
#JWT authentication for productpage
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  jwtRules:
  - issuer: "https://securetoken.google.com"
    audiences:
    - "productpage"
    jwksUri: "https://www.googleapis.com/oauth2/v1/certs"
    fromHeaders:
    - name: "x-goog-iap-jwt-assertion"
...
#Require JWT token to access product page service from
#any client to all paths except /health_check
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  action: ALLOW
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  rules:
  - to: # require JWT token to access all other paths
      - operation:
          notPaths:
          - /health_check
    from:
      - source:
          # if using principalBinding: USE_PEER in the Policy,
          # then use principals, e.g.
          # principals:
          # - “*”
          requestPrincipals:
          - “*”
  - to: # no JWT token required to access health_check
      - operation:
          paths:
          - /health_check

1.10.3. 設定レシピ

これらの設定レシピを使用して、以下の項目を設定することができます。

1.10.3.1. データプレーンでの相互 TLS

データプレーン通信の相互 TLS は、ServiceMeshControlPlane リソースの spec.security.dataPlane.mtls で設定されます。これはデフォルトは false になります。

1.10.3.2. カスタム署名キー

Istiod は、サービスプロキシーによって使用されるクライアント証明書とプライベートキーを管理します。デフォルトで、Istiod は署名用に自己署名証明書を使用しますが、カスタム証明書とシークレットキーを設定できます。署名するキーの設定方法についての詳細は、「 外部認証局キーおよび証明書の追加」を参照してください。

1.10.3.3. トレース

トレースは spec.tracing で設定されます。現在、サポートされるトレーサーの唯一のタイプは Jaeger です。サンプリングは 0.01% の増分 (例: 1 は 0.01%、10000 は 100%) を表すスケーリングされた整数です。トレースの実装およびサンプリングレートを指定できます。

spec:
  tracing:
    sampling: 100 # 1%
    type: Jaeger

Jaeger は、ServiceMeshControlPlane リソースの addons セクションで設定します。

spec:
  addons:
    jaeger:
      name: jaeger
      install:
        storage:
          type: Memory # or Elasticsearch for production mode
          memory:
            maxTraces: 100000
          elasticsearch: # the following values only apply if storage:type:=Elasticsearch
            storage: # specific storageclass configuration for the Jaeger Elasticsearch (optional)
              size: "100G"
              storageClassName: "storageclass"
            nodeCount: 3
            redundancyPolicy: SingleRedundancy
  runtime:
    components:
      tracing.jaeger: {} # general Jaeger specific runtime configuration (optional)
      tracing.jaeger.elasticsearch: #runtime configuration for Jaeger Elasticsearch deployment (optional)
        container:
          resources:
            requests:
              memory: "1Gi"
              cpu: "500m"
            limits:
              memory: "1Gi"

Jaeger インストールは install フィールドでカスタマイズできます。リソース制限などのコンテナー設定は、spec.runtime.components.jaeger の関連フィールドに設定されます。spec.addons.jaeger.name の値に一致する Jaeger リソースが存在する場合、コントロールプレーンは既存のインストールを使用するように設定されます。既存の Jaeger リソースを使用して Jaeger インストールを完全にカスタマイズします。

1.10.3.4. 可視化

Kiali および Grafana は、ServiceMeshControlPlane リソースの addons セクションで設定されます。

spec:
  addons:
    grafana:
      enabled: true
      install: {} # customize install
    kiali:
      enabled: true
      name: kiali
      install: {} # customize install

Grafana および Kiali のインストールは、それぞれの install フィールドでカスタマイズできます。リソース制限などのコンテナーのカスタマイズは、 spec.runtime.components.kiali および spec.runtime.components.grafana で設定されます。name の値に一致する既存の Kiali リソースが存在する場合、コントロールプレーンはコントロールプレーンで使用するように Kiali リソースを設定します。accessible_namespaces 一覧や Grafana、Prometheus、およびトレースのエンドポイントなどの Kiali リソースの一部のフィールドは上書きされます。既存のリソースを使用して Kiali インストールを完全にカスタマイズします。

1.10.3.5. リソース使用状況とスケジューリング

リソースは spec.runtime.<component> で設定されます。以下のコンポーネント名がサポートされます。

コンポーネント詳細サポート対象バージョン

セキュリティー

Citadel コンテナー

v1.0/1.1

galley

Galley コンテナー

v1.0/1.1

pilot

Pilot/Istiod コンテナー

v1.0/1.1/2.0

mixer

istio-telemetry および istio-policy コンテナー

v1.0/1.1

mixer.policy

istio-policy コンテナー

v2.0

mixer.telemetry

istio-telemetry コンテナー

v2.0

global.ouathproxy

各種アドオンと共に使用する oauth-proxy コンテナー

v1.0/1.1/2.0

sidecarInjectorWebhook

サイドカーインジェクター Webhook コンテナー

v1.0/1.1

tracing.jaeger

一般的な Jaeger コンテナー: すべての設定が適用されない可能性があります。Jaeger インストールの完全なカスタマイズは、既存の Jaeger リソースをコントロールプレーンの設定に指定することでサポートされます。

v1.0/1.1/2.0

tracing.jaeger.agent

Jaeger エージェントに固有の設定

v1.0/1.1/2.0

tracing.jaeger.allInOne

Jaeger allInOne に固有の設定

v1.0/1.1/2.0

tracing.jaeger.collector

Jaeger コレクターに固有の設定

v1.0/1.1/2.0

tracing.jaeger.elasticsearch

Jaeger elasticsearch デプロイメントに固有の設定

v1.0/1.1/2.0

tracing.jaeger.query

Jaeger クエリーに固有の設定

v1.0/1.1/2.0

prometheus

prometheus コンテナー

v1.0/1.1/2.0

kiali

Kiali コンテナー: Kiali インストールの完全なカスタマイズは、既存の Kiali リソースをコントロールプレーン設定に指定してサポートされます。

v1.0/1.1/2.0

grafana

Grafana コンテナー

v1.0/1.1/2.0

3scale

3scale コンテナー

v1.0/1.1/2.0

wasmExtensions.cacher

WASM 拡張キャッシュコンテナー

V2.0: テクノロジープレビュー

コンポーネントによっては、リソースの制限およびスケジューリングをサポートするものもあります。詳細は、「パフォーマンスおよびスケーラビリティー」を参照してください。

1.10.4. アプリケーションとワークフローを移行するための次のステップ

アプリケーションのワークロードを新規のメッシュに移動し、古いインスタンスを削除してアップグレードを完了します。

1.11. ユーザーおよびプロファイルの管理

1.11.1. Red Hat OpenShift Service Mesh メンバーの作成

ServiceMeshMember リソースは、各ユーザーがサービスメッシュプロジェクトまたはメンバーロールに直接アクセスできない場合でも、Red Hat OpenShift Service Mesh の管理者がプロジェクトをサービスメッシュに追加するパーミッションを委譲する方法を提供します。プロジェクト管理者にはプロジェクトで ServiceMeshMember リソースを作成するためのパーミッションが自動的に付与されますが、サービスメッシュ管理者がサービスメッシュへのアクセスを明示的に付与するまで、これらのプロジェクト管理者はこれを ServiceMeshControlPlane にポイントすることはできません。管理者は、ユーザーに mesh-user ユーザーロールを付与してメッシュにアクセスするパーミッションをユーザーに付与できます。この例では、istio-system は、コントロールプレーンプロジェクトです。

$ oc policy add-role-to-user -n istio-system --role-namespace istio-system mesh-user <user_name>

管理者はコントロールプレーンプロジェクトで mesh user ロールバインディングを変更し、アクセスが付与されたユーザーおよびグループを指定できます。ServiceMeshMember は、プロジェクトを、参照するコントロールプレーンプロジェクト内の ServiceMeshMemberRoll に追加します。

apiVersion: maistra.io/v1
kind: ServiceMeshMember
metadata:
  name: default
spec:
  controlPlaneRef:
    namespace: istio-system
    name: basic

mesh-users ロールバインディングは、管理者が ServiceMeshControlPlane リソースを作成した後に自動的に作成されます。管理者は以下のコマンドを使用してロールをユーザーに追加できます。

$ oc policy add-role-to-user

管理者は、ServiceMeshControlPlane リソースを作成する前に、mesh-user ロールバインディングを作成することもできます。たとえば、管理者は ServiceMeshControlPlane リソースと同じ oc apply 操作でこれを作成できます。

この例では、alice のロールバインディングを追加します。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: istio-system
  name: mesh-users
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: mesh-user
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: alice

1.11.2. コントロールプレーンプロファイルの作成

ServiceMeshControlPlane プロファイルを使用すると、再利用可能な設定を作成することができます。各ユーザーは、作成するプロファイルを独自の設定で拡張することができます。プロファイルは、他のプロファイルから設定情報を継承することもできます。たとえば、会計チーム用の会計コントロールプレーンとマーケティングチーム用のマーケティングコントロールプレーンを作成できます。開発プロファイルと実稼働テンプレートを作成する場合、マーケティングチームおよび会計チームのメンバーは、チーム固有のカスタマイズで開発および実稼働プロファイルを拡張することができます。

ServiceMeshControlPlane と同じ構文に従うコントロールプレーンのプロファイルを設定する場合、ユーザーは階層的に設定を継承します。Operator は、Red Hat OpenShift Service Mesh のデフォルト設定を使用する default プロファイルと共に提供されます。

1.11.2.1. ConfigMap の作成

カスタムプロファイルを追加するには、まず openshift-operators プロジェクトで smcp-templates という名前の ConfigMap を作成し、次に /usr/local/share/istio-operator/templates で Operator コンテナーに ConfigMap をマウントする必要があります。

前提条件

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

手順

  1. cluster-admin として OpenShift Container Platform CLI にログインします。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
  2. CLI で以下のコマンドを実行し、 openshift-operators プロジェクトに smcp-templates という名前の ConfigMap を作成し、<profiles-directory> をローカルディスクの ServiceMeshControlPlane ファイルの場所に置き換えます。

    $ oc create configmap --from-file=<profiles-directory> smcp-templates -n openshift-operators
  3. Operator ClusterServiceVersion 名を見つけます。

    $ oc get clusterserviceversion -n openshift-operators | grep 'Service Mesh'

    出力例

    maistra.v2.0.0            Red Hat OpenShift Service Mesh   2.0.0                Succeeded

  4. Operator クラスターサービスバージョンを編集して、Operator に smcp-templates ConfigMap を使用するよう指示します。

    $ oc edit clusterserviceversion -n openshift-operators servicemeshoperator.v2.0.0.1
  5. ボリュームマウントおよびボリュームを Operator デプロイメントに追加します。

    deployments:
      - name: istio-operator
        spec:
          template:
            spec:
              containers:
                volumeMounts:
                  - name: smcp-templates
                    mountPath: /usr/local/share/istio-operator/templates/
              volumes:
                - name: smcp-templates
                  configMap:
                    name: smcp-templates
    ...
  6. 変更を保存し、エディターを終了します。
  7. ServiceMeshControlPlanetemplate パラメーターを使用して 1 つ以上のテンプレートを指定できます。

      apiVersion: maistra.io/v2
      kind: ServiceMeshControlPlane
      metadata:
        name: basic
      spec:
        profiles:
        - default

1.11.2.2. 適切なネットワークポリシーの設定

サービスメッシュはコントロールプレーンおよびメンバー namespace にネットワークポリシーを作成し、それらの間のトラフィックを許可します。デプロイする前に、以下の条件を考慮し、OpenShift Container Platform ルートで以前に公開されたサービスメッシュのサービスを確認します。

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

1.12. セキュリティー

サービスメッシュアプリケーションが複雑な配列のマイクロサービスで構築されている場合、Red Hat OpenShift Service Mesh を使用してそれらのサービス間の通信のセキュリティーをカスタマイズできます。サービスメッシュのトラフィック管理機能と共に OpenShift Container Platform のインフラストラクチャーを使用すると、アプリケーションの複雑性を管理し、マイクロサービスのセキュリティーを確保できるようにします。

作業を開始する前に

プロジェクトがある場合は、プロジェクトを ServiceMeshMemberRoll リソース に追加します。

プロジェクトがない場合は、Bookinfo サンプルアプリケーションをインストールし、これを ServiceMeshMemberRoll リソースに追加します。サンプルアプリケーションは、セキュリティーの概念を説明するのに役立ちます。

1.12.1. 相互トランスポート層セキュリティー

相互トランスポート層セキュリティー (mTLS) は、二者が相互認証できるようにするプロトコルです。これは、一部のプロトコル(IKE、SSH)での認証のデフォルトモードであり、他 (TLS) ではオプションになります。mTLS は、アプリケーションやサービスコードを変更せずに使用できます。TLS は、サービスメッシュインフラストラクチャーおよび 2 つのサイドカープロキシー間で完全に処理されます。

デフォルトで、Red Hat OpenShift Service Mesh の mTLS は有効にされ、Permissive モードに設定されます。この場合、サービスメッシュのサイドカーは、プレーンテキストのトラフィックと mTLS を使用して暗号化される接続の両方を受け入れます。メッシュのサービスがメッシュ外のサービスと通信している場合、厳密な mTLS によりサービス間の通信に障害が発生する可能性があります。ワークロードをサービスメッシュに移行する間に Permissive モードを使用します。次に、メッシュ、namespace、またはアプリケーションで厳密な mTLS を有効にできます。

コントロールプレーンのレベルでメッシュ全体で mTLS を有効にすると、アプリケーションとワークフローを書き換えずにサービスメッシュ内のすべてのトラフィックのセキュリティーが保護されます。メッシュの namespace のセキュリティーは、ServiceMeshControlPlane リソースのデータプレーンレベルで保護できます。トラフィックの暗号化接続をカスタマイズするには、アプリケーションレベルで namespace を PeerAuthentication および DestinationRule リソースで設定します。

1.12.1.1. サービスメッシュ全体での厳密な mTLS の有効化

ワークロードがメッシュ外のサービスと通信しない場合には、通信を中断せずに mTLS をメッシュ全体ですぐに有効化できます。これを有効にするには、ServiceMeshControlPlane リソースで spec.security.dataPlane.mtlstrue に設定します。Operator は必要なリソースを作成します。

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
spec:
  version: v2.0
  security:
    dataPlane:
      mtls: true

OpenShift Container Platform Web コンソールを使用して mTLS を有効にすることもできます。

手順

  1. Web コンソールにログインします。
  2. Project メニューをクリックし、コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. OperatorsInstalled Operators をクリックします。
  4. Provided APIsService Mesh Control Plane をクリックします。
  5. ServiceMeshControlPlane リソースの名前 (例: basic) をクリックします。
  6. Details ページで、Data Plane SecuritySecurity セクションでトグルをクリックします。
1.12.1.1.1. 特定のサービスの受信接続用のサイドカーの設定

ポリシーを作成して、個別のサービスに mTLS を設定することもできます。

手順

  1. 以下のサンプルを使用して YAML ファイルを作成します。

    PeerAuthentication ポリシーの例 (policy.yaml)

    apiVersion: security.istio.io/v1beta1
    kind: PeerAuthentication
    metadata:
      name: default
      namespace: <namespace>
    spec:
      mtls:
        mode: STRICT

    1. <namespace> は、サービスが置かれている namespace に置き換えます。
  2. 以下のコマンドを実行して、サービスが置かれている namespace にリソースを作成します。先ほど作成した Policy リソースの namespace フィールドと一致させる必要があります。

    $ oc create -n <namespace> -f <policy.yaml>
注記

自動 mTLS を使用しておらず、PeerAuthentication を STRICT に設定する場合は、サービスの DestinationRule リソースを作成する必要があります。

1.12.1.1.2. 送信接続用のサイドカーの設定

宛先ルールを作成し、サービスメッシュがメッシュ内の他のサービスに要求を送信する際に mTLS を使用するように設定します。

手順

  1. 以下のサンプルを使用して YAML ファイルを作成します。

    destinationRule の例 (destination-rule.yaml)

    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: default
      namespace: <namespace>
    spec:
      host: "*.<namespace>.svc.cluster.local"
      trafficPolicy:
       tls:
        mode: ISTIO_MUTUAL

    1. <namespace> は、サービスが置かれている namespace に置き換えます。
  2. 以下のコマンドを実行して、サービスが置かれている namespace にリソースを作成します。先ほど作成した DestinationRule リソースの namespace フィールドと一致させる必要があります。

    $ oc create -n <namespace> -f <destination-rule.yaml>
1.12.1.1.3. 最小および最大のプロトコルバージョンの設定

ご使用の環境のサービスメッシュに暗号化されたトラフィックの特定の要件がある場合、許可される暗号化機能を制御できます。これは、ServiceMeshControlPlane リソースに spec.security.controlPlane.tls.minProtocolVersion または spec.security.controlPlane.tls.maxProtocolVersion を設定して許可できます。コントロールプレーンリソースで設定されるこれらの値は、TLS 経由でセキュアに通信する場合にメッシュコンポーネントによって使用される最小および最大の TLS バージョンを定義します。

デフォルトは TLS_AUTO であり、TLS のバージョンは指定しません。

表1.3 有効な値

詳細

TLS_AUTO

default

TLSv1_0

TLS バージョン 1.0

TLSv1_1

TLS バージョン 1.1

TLSv1_2

TLS バージョン 1.2

TLSv1_3

TLS バージョン 1.3

手順

  1. Web コンソールにログインします。
  2. Project メニューをクリックし、コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. OperatorsInstalled Operators をクリックします。
  4. Provided APIsService Mesh Control Plane をクリックします。
  5. ServiceMeshControlPlane リソースの名前 (例: basic) をクリックします。
  6. YAML タブをクリックします。
  7. 以下のコードスニペットを YAML エディターに挿入します。minProtocolVersion の値は、TLS バージョンの値に置き換えます。この例では、最小の TLS バージョンは TLSv1_2 に設定されます。

    ServiceMeshControlPlane スニペット

    kind: ServiceMeshControlPlane
    spec:
      security:
        controlPlane:
          tls:
            minProtocolVersion: TLSv1_2

  8. Save をクリックします。
  9. Refresh をクリックし、変更が正しく更新されたことを確認します。

1.12.2. ロールベースアクセス制御 (RBAC) の設定

Role-based Access Control (RBAC: ロールベースアクセス制御) オブジェクトは、ユーザーまたはサービスがプロジェクト内で所定のアクションを実行することが許可されるかどうかを決定します。メッシュでワークロードのメッシュ全体、namespace 全体、およびワークロード全体のアクセス制御を定義できます。

RBAC を設定するには、アクセスを設定する namespace で AuthorizationPolicy リソースを作成します。メッシュ全体のアクセスを設定する場合は、コントロールプレーンをインストールしたプロジェクト (例: istio-system) を使用します。

たとえば、RBAC を使用して以下を実行するポリシーを作成できます。

  • プロジェクト内通信を設定します。
  • デフォルト namespace のすべてのワークロードへの完全アクセスを許可または拒否します。
  • ingress ゲートウェイアクセスを許可または拒否します。
  • アクセスにはトークンが必要です。

認証ポリシーには、セレクター、アクション、およびルールの一覧が含まれます。

  • selector フィールドは、ポリシーのターゲットを指定します。
  • action フィールドは、要求を許可または拒否するかどうかを指定します。
  • rules フィールドは、アクションをトリガーするタイミングを指定します。

    • from フィールドは、要求元についての制約を指定します。
    • to フィールドは、要求のターゲットおよびパラメーターの制約を指定します。
    • when フィールドは、ルールを適用する追加の条件を指定します。

手順

  1. AuthorizationPolicy リソースを作成します。以下の例は、ingress-policy AuthorizationPolicy を更新して、IP アドレスが Ingress ゲートウェイにアクセスすることを拒否するリソースを示しています。

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: ingress-policy
      namespace: istio-system
    spec:
      selector:
        matchLabels:
          app: istio-ingressgateway
      action: DENY
      rules:
      - from:
        - source:
          ipBlocks: ["1.2.3.4"]
  2. リソースを作成した後に以下のコマンドを実行して、namespace にリソースを作成します。namespace は、AuthorizationPolicy リソースの metadata.namespace フィールドと一致する必要があります。

    $ oc create -n istio-system -f <filename>

次のステップ

その他の一般的な設定については、以下の例を参照してください。

1.12.2.1. プロジェクト内通信の設定

AuthorizationPolicy を使用してコントロールプレーンを設定し、メッシュまたはメッシュ内のサービスとの通信トラフィックを許可したり、拒否したりすることができます。

1.12.2.1.1. namespace 外のサービスへのアクセス制限

以下の AuthorizationPolicy リソースの例を使用して、bookinfo namespace にないソースからの要求を拒否することができます。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin-deny
 namespace: bookinfo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: DENY
 rules:
 - from:
   - source:
       notNamespaces: ["bookinfo"]
1.12.2.1.2. allow-all およびデフォルトの deny-all 認証ポリシーの作成

以下の例は、bookinfo namespace のすべてのワークロードへの完全なアクセスを許可する allow-all 認証ポリシーを示しています。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-all
  namespace: bookinfo
spec:
  action: ALLOW
  rules:
  - {}

以下の例は、bookinfo namespace のすべてのワークロードへのアクセスを拒否するポリシーを示しています。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: bookinfo
spec:
  {}

1.12.2.2. ingress ゲートウェイへのアクセスの許可または拒否

認証ポリシーを設定し、IP アドレスに基づいて許可または拒否リストを追加できます。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: ingress-policy
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  action: ALLOW
  rules:
  - from:
    - source:
       ipBlocks: ["1.2.3.4", "5.6.7.0/24"]

1.12.2.3. JSON Web トークンを使用したアクセスの制限

JSON Web Token (JWT) を使用してメッシュにアクセスできる内容を制限できます。認証後に、ユーザーまたはサービスはそのトークンに関連付けられたルート、サービスにアクセスできます。

ワークロードでサポートされる認証方法を定義する RequestAuthentication リソースを作成します。以下の例では、http://localhost:8080/auth/realms/master で実行される JWT を受け入れます。

apiVersion: "security.istio.io/v1beta1"
kind: "RequestAuthentication"
metadata:
  name: "jwt-example"
  namespace: bookinfo
spec:
  selector:
    matchLabels:
      app: httpbin
  jwtRules:
  - issuer: "http://localhost:8080/auth/realms/master"
    jwksUri: "http://keycloak.default.svc:8080/auth/realms/master/protocol/openid-connect/certs"

次に、同じ namespace に AuthorizationPolicy リソースを作成し、作成した RequestAuthentication リソースと連携させます。以下の例では、要求を httpbin ワークロードに送信する際に、JWT は Authorization ヘッダーになければなりません。

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "frontend-ingress"
  namespace: bookinfo
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]

1.12.3. 暗号化スイートおよび ECDH 曲線の設定

暗号化スイートおよび ECDH 曲線 (Elliptic-curve Diffie–Hellman) は、サービスメッシュのセキュリティーを保護するのに役立ちます。暗号化スイートのコンマ区切りの一覧を spec.istio.global.tls.cipherSuites を使用して定義し、 ECDH 曲線を ServiceMeshControlPlane リソースの spec.istio.global.tls.ecdhCurves を使用して定義できます。これらの属性のいずれかが空の場合、デフォルト値が使用されます。

サービスメッシュが TLS 1.2 以前のバージョンを使用する場合、cipherSuites 設定が有効になります。この設定は、TLS 1.3 でネゴシエートする場合は影響を与えません。

コンマ区切りの一覧に暗号化スイートを優先度順に設定します。たとえば、ecdhCurves: CurveP256, CurveP384 は、CurveP256CurveP384 よりも高い優先順位として設定します。

注記

暗号化スイートを設定する場合は、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 または TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 のいずれかを追加する必要があります。HTTP/2 のサポートには、1 つ以上の以下の暗号スイートが必要です。

サポートされている暗号化スイートは以下になります。

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA

サポートされる ECDH 曲線は以下のとおりです。

  • CurveP256
  • CurveP384
  • CurveP521
  • X25519

1.12.4. 外部認証局キーおよび証明書の追加

デフォルトで、Red Hat OpenShift Service Mesh は自己署名ルート証明書およびキーを生成し、それらを使用してワークロード証明書に署名します。ユーザー定義の証明書およびキーを使用して、ユーザー定義のルート証明書を使用してワークロード証明書に署名することもできます。このタスクは、証明書およびキーをサービスメッシュにプラグインするサンプルを示しています。

前提条件

  • 相互 TLS を有効にして Red Hat OpenShift Service Mesh をインストールし、証明書を設定する。
  • この例では、Maistra リポジトリーからの証明書を使用します。実稼働環境の場合は、認証局から独自の証明書を使用します。
  • Bookinfo サンプルアプリケーションをデプロイして以下の手順で結果を確認しておく。

1.12.4.1. 既存の証明書およびキーの追加

既存の署名 (CA) 証明書およびキーを使用するには、CA 証明書、キー、ルート証明書が含まれる信頼ファイルのチェーンを作成する必要があります。それぞれの対応する証明書について以下のファイル名をそのまま使用する必要があります。CA 証明書は ca-cert.pem と呼ばれ、キーは ca-key.pem であり、ca-cert.pem を署名するルート証明書は root-cert.pem と呼ばれます。ワークロードで中間証明書を使用する場合は、cert-chain.pem ファイルでそれらを指定する必要があります。

以下の手順に従い、証明書をサービスメッシュに追加します。Maistra リポジトリーからサンプル証明書をローカルに保存し、<path> を証明書へのパスに置き換えます。

  1. シークレット cacert を作成します。これには、入力ファイルの ca-cert.pemca-key.pemroot-cert.pem および cert-chain.pem が含まれます。

    $ oc create secret generic cacerts -n istio-system --from-file=<path>/ca-cert.pem \
        --from-file=<path>/ca-key.pem --from-file=<path>/root-cert.pem \
        --from-file=<path>/cert-chain.pem
  2. ServiceMeshControlPlane リソースで、spec.security.dataPlane.mtls: truetrue に設定し、以下の例のように certificateAuthority を設定します。デフォルトの rootCADir/etc/cacerts です。キーおよび証明書がデフォルトの場所にマウントされている場合は、privateKey を設定する必要はありません。サービスメッシュは、secret-mount ファイルから証明書およびキーを読み取ります。

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    spec:
      security:
        dataPlane:
          mtls: true
        certificateAuthority:
          type: Istiod
          istiod:
            type: PrivateKey
            privateKey:
              rootCADir:  /etc/cacerts
  3. ワークロードが新規証明書を追加することをすぐに確認するには、istio.* という名前のサービスメッシュによって生成されたシークレットを削除します。この例では istio.default です。サービスメッシュはワークロードの新規の証明書を発行します。

    $ oc delete secret istio.default

1.12.4.2. 証明書の確認

Bookinfo サンプルアプリケーションを使用して、証明書が正しくマウントされていることを確認します。最初に、マウントされた証明書を取得します。次に、Pod にマウントされた証明書を確認します。

  1. Pod 名を変数 RATINGSPOD に保存します。

    $ RATINGSPOD=`oc get pods -l app=ratings -o jsonpath='{.items[0].metadata.name}'`
  2. 以下のコマンドを実行して、プロキシーにマウントされている証明書を取得します。

    $ oc exec -it $RATINGSPOD -c istio-proxy -- /bin/cat /var/run/secrets/istio/root-cert.pem > /tmp/pod-root-cert.pem

    /tmp/pod-root-cert.pem ファイルには、Pod に伝播されるルート証明書が含まれます。

    $ oc exec -it $RATINGSPOD -c istio-proxy -- /bin/cat /etc/certs/cert-chain.pem > /tmp/pod-cert-chain.pem

    /tmp/pod-cert-chain.pem ファイルには、ワークロード証明書と Pod に伝播される CA 証明書が含まれます。

  3. ルート証明書が Operator によって指定される証明書と同じであることを確認します。<path> を証明書へのパスに置き換えます。

    $ openssl x509 -in <path>/root-cert.pem -text -noout > /tmp/root-cert.crt.txt
    $ openssl x509 -in /tmp/pod-root-cert.pem -text -noout > /tmp/pod-root-cert.crt.txt
    $ diff /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt

    出力が空になることが予想されます。

  4. CA 証明書が Operator で指定された証明書と同じであることを確認します。<path> を証明書へのパスに置き換えます。

    $ sed '0,/^-----END CERTIFICATE-----/d' /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-ca.pem
    $ openssl x509 -in <path>/ca-cert.pem -text -noout > /tmp/ca-cert.crt.txt
    $ openssl x509 -in /tmp/pod-cert-chain-ca.pem -text -noout > /tmp/pod-cert-chain-ca.crt.txt
    $ diff /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txt

    出力が空になることが予想されます。

  5. ルート証明書からワークロード証明書への証明書チェーンを確認します。<path> を証明書へのパスに置き換えます。

    $ head -n 21 /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-workload.pem
    $ openssl verify -CAfile <(cat <path>/ca-cert.pem <path>/root-cert.pem) /tmp/pod-cert-chain-workload.pem

    出力例

    /tmp/pod-cert-chain-workload.pem: OK

1.12.4.3. 証明書の削除

追加した証明書を削除するには、以下の手順に従います。

  1. シークレット cacerts を削除します。この例では、istio-system は、コントロールプレーンプロジェクトです。

    $ oc delete secret cacerts -n istio-system
  2. ServiceMeshControlPlane リソースで自己署名ルート証明書を使用してサービスメッシュを再デプロイします。

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    spec:
      dataPlane:
        mtls: true

1.13. トラフィック管理の設定

Red Hat OpenShift Service Mesh では、サービス間のトラフィックのフローおよび API 呼び出しを制御できます。サービスメッシュの一部のサービスはメッシュ内で通信する必要があり、他のサービスは非表示にする必要がある場合があります。トラフィックを管理して、特定のバックエンドサービスを非表示にし、サービスを公開し、テストまたはバージョン管理デプロイメントを作成し、または一連のサービスのセキュリティーの層を追加します。

本書では Bookinfo サンプルアプリケーションを参照して、サンプルアプリケーションでのルーティングの例を説明します。Bookinfo アプリケーション をインストールして、これらのルーティングのサンプルがどのように機能するかを確認します。

1.13.1. ルーティングチュートリアル

Service Mesh Bookinfo サンプルアプリケーションは、それぞれが複数のバージョンを持つ 4 つの別個のマイクロサービスで構成されます。Bookinfo サンプルアプリケーションをインストールした後に、reviews マイクロサービスの 3 つの異なるバージョンが同時に実行されます。

ブラウザーで Bookinfo アプリケーションの /product ページにアクセスして数回更新すると、書評の出力に星評価が含まれる場合と含まれない場合があります。ルーティング先の明示的なデフォルトサービスバージョンがない場合、サービスメッシュは、利用可能なすべてのバージョンに要求をルーティングしていきます。

このチュートリアルは、すべてのトラフィックをマイクロサービスの v1 (バージョン 1) にルーティングするルールを適用するのに役立ちます。後に、HTTP リクエストヘッダーの値に基づいてトラフィックをルーティングするためのルールを適用できます。

前提条件:

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

1.13.1.1. 仮想サービスの適用

以下の手順では、マイクロサービスのデフォルトバージョンを設定する仮想サービスを適用して、各マイクロサービスの v1 にすべてのトラフィックをルーティングします。

手順

  1. 仮想サービスを適用します。

    $ oc apply -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.0/samples/bookinfo/networking/virtual-service-all-v1.yaml
  2. 仮想サービスの適用を確認するには、以下のコマンドで定義されたルートを表示します。

    $ oc get virtualservices -o yaml

    このコマンドでは、YAML 形式で kind: VirtualService のリソースを返します。

サービスメッシュを Bookinfo マイクロサービスの v1 バージョン (例: reviews サービスバージョン 1) にルーティングするように設定しています。

1.13.1.2. 新規ルート設定のテスト

Bookinfo アプリケーションの /productpage を更新して、新しい設定をテストします。

手順

  1. GATEWAY_URL パラメーターの値を設定します。この変数を使用して、Bookinfo 製品ページの URL を後で見つけることができます。この例では、istio-system はコントロールプレーンプロジェクトの名前です。

    export GATEWAY_URL=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.host}')
  2. 以下のコマンドを実行して、製品ページの URL を取得します。

    echo "http://$GATEWAY_URL/productpage"
  3. ブラウザーで Bookinfo サイトを開きます。

更新回数に関係なく、ページのレビュー部分は星評価なしに表示されます。これは、サービスメッシュを、reviews サービスのすべてのトラフィックをバージョン reviews:v1 にルーティングするように設定しているためであり、サービスのこのバージョンは星評価サービスにアクセスしません。

サービスメッシュは、トラフィックを 1 つのバージョンのサービスにルーティングするようになりました。

1.13.1.3. ユーザーアイデンティティーに基づくルート

ルート設定を変更して、特定のユーザーからのトラフィックすべてが特定のサービスバージョンにルーティングされるようにします。この場合、jason という名前のユーザーからのトラフィックはすべて、サービス reviews:v2 にルーティングされます。

サービスメッシュには、ユーザーアイデンティティーについての特別な組み込み情報はありません。この例は、productpage サービスが reviews サービスへのすべてのアウトバウンド HTTP リクエストにカスタム end-user ヘッダーを追加することで有効にされます。

手順

  1. 以下のコマンドを実行して、Bookinfo アプリケーション例でユーザーベースのルーティングを有効にします。

    $ oc apply -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.0/samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml
  2. 以下のコマンドを実行して、ルールの作成を確認します。このコマンドは、kind: VirtualService のすべてのリソースを YAML 形式で返します。

    $ oc get virtualservice reviews -o yaml
  3. Bookinfo アプリケーションの /productpage で、パスワードなしでユーザー jason としてログインします。

    1. ブラウザーを更新します。各レビューの横に星評価が表示されます。
  4. 別のユーザーとしてログインします(任意の名前を指定します)。ブラウザーを更新します。これで星がなくなりました。Jason 以外のすべてのユーザーのトラフィックが reviews:v1 にルーティングされるようになりました。

ユーザーアイデンティティーに基づいてトラフィックをルーティングするように Bookinfo のアプリケーションサンプルが正常に設定されています。

1.13.2. トラフィックのルーティングおよび管理

YAML ファイルのカスタムリソース定義を使用して、独自のトラフィック設定を Red Hat OpenShift Service Mesh に追加してサービスメッシュを設定します。

1.13.2.1. 仮想サービスの使用によるトラフィック管理

仮想サービスを使用して、Red Hat OpenShift Service Mesh で複数バージョンのマイクロサービスに要求を動的にルーティングできます。仮想サービスを使用すると、以下が可能になります。

  • 単一の仮想サービスで複数のアプリケーションサービスに対応する。メッシュが Kubernetes を使用する場合などに、仮想サービスを特定の namespace のすべてのサービスを処理するように設定できます。仮想サービスを使用すると、モノリシックなアプリケーションをシームレスに、個別のマイクロサービスで構成されるサービスに変換できます。
  • ingress および egress トラフィックを制御できるようにゲートウェイと組み合わせてトラフィックルールを設定する。
1.13.2.1.1. 仮想サービスの設定

要求は、仮想サービスを使用してサービスメッシュ内のサービスにルーティングされます。それぞれの仮想サービスは、順番に評価される一連のルーティングルールで構成されます。Red Hat OpenShift Service Mesh は、仮想サービスへのそれぞれの指定された要求をメッシュ内の特定の実際の宛先に一致させます。

仮想サービスがない場合、Red Hat OpenShift Service Mesh はすべてのサービスインスタンス間のラウンドロビン負荷分散を使用してトラフィックを分散します。仮想サービスを使用すると、1 つ以上のホスト名のトラフィック動作を指定できます。仮想サービスのルーティングルールでは、仮想サービスのトラフィックを適切な宛先に送信する方法を Red Hat OpenShift Service Mesh に指示します。ルートの宛先は、同じサービスのバージョンまたは全く異なるサービスにすることができます。

手順

  1. アプリケーションに接続するユーザーに基づき、異なるバージョンの Bookinfo アプリケーションサービスのサンプルに、要求をルーティングする以下の例を使用して、YAML ファイルを作成します。

    VirtualService.yaml の例

    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: reviews
    spec:
      hosts:
      - reviews
      http:
      - match:
        - headers:
            end-user:
              exact: jason
        route:
        - destination:
            host: reviews
            subset: v2
      - route:
        - destination:
            host: reviews
            subset: v3

  2. 以下のコマンドを実行して VirtualService.yaml を適用します。VirtualService.yaml はファイルへのパスです。

    $ oc apply -f VirtualService.yaml

1.13.2.2. 仮想ホストの設定

以下のセクションでは、YAML ファイルの各フィールド、および仮想サービスで仮想ホストを作成する方法について説明します。

1.13.2.2.1. ホスト

hosts フィールドには、ルーティングルールが適用される仮想サービスのユーザーの宛先アドレスが一覧表示されます。これは、サービスへの要求送信に使用するアドレスです。

仮想サービスのホスト名は、IP アドレス、DNS 名または完全修飾ドメイン名に解決される短縮名になります。

spec:
  hosts:
  - reviews
1.13.2.2.2. ルーティングルール

http セクションには、ホストフィールドで指定された宛先に送信される HTTP/1.1、HTTP2、および gRPC トラフィックのルーティングの一致条件とアクションを記述する仮想サービスのルーティングルールが含まれます。ルーティングルールは、トラフィックの宛先と、指定の一致条件で構成されます。

一致条件

この例の最初のルーティングルールには条件があり、match フィールドで始まります。この例では、このルーティングはユーザー jason からの要求すべてに適用されます。headersend-user、および exact フィールドを追加し、適切な要求を選択します。

spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
      end-user:
        exact: jason

宛先

route セクションの destination フィールドは、この条件に一致するトラフィックの実際の宛先を指定します。仮想サービスのホストとは異なり、宛先のホストは Red Hat OpenShift Service Mesh サービスレジストリーに存在する実際の宛先でなければなりません。これは、プロキシーが含まれるメッシュサービス、またはサービスエントリーを使用して追加されたメッシュ以外のサービスである可能性があります。この例では、ホスト名は Kubernetes サービス名です。

spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
      end-user:
        exact: jason
    route:
    - destination:
      host: reviews
      subset: v2
1.13.2.2.3. 宛先ルール

宛先ルールは仮想サービスのルーティングルールが評価された後に適用されるため、それらはトラフィックの実際の宛先に適用されます。仮想サービスはトラフィックを宛先にルーティングします。宛先ルールでは、その宛先のトラフィックに生じる内容を設定します。

1.13.2.2.3.1. 負荷分散オプション

デフォルトで、Red Hat OpenShift Service Mesh はラウンドロビンの負荷分散ポリシーを使用します。このポリシーでは、プールの各サービスインスタンスが順番に要求を取得します。Red Hat OpenShift Service Mesh は以下のモデルもサポートします。このモデルは、特定のサービスまたはサービスサブセットへの要求の宛先ルールに指定できます。

  • Random: 要求はプール内のインスタンスにランダムに転送されます。
  • Weighted: 要求は特定のパーセンテージに応じてプールのインスタンスに転送されます。
  • Least requests: 要求は要求の数が最も少ないインスタンスに転送されます。

宛先ルールの例

以下の宛先ルールの例では、異なる負荷分散ポリシーで my-svc 宛先サービスに 3 つの異なるサブセットを設定します。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination-rule
spec:
  host: my-svc
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
  - name: v3
    labels:
      version: v3
1.13.2.2.4. ゲートウェイ

ゲートウェイを使用してメッシュの受信トラフィックおよび送信トラフィックを管理することで、メッシュに入るか、またはメッシュを出るトラフィックを指定できます。ゲートウェイ設定は、サービスワークロードと共に実行されるサイドカー Envoy プロキシーではなく、メッシュのエッジで実行されているスタンドアロンの Envoy プロキシーに適用されます。

Kubernetes Ingress API などのシステムに入るトラフィックを制御する他のメカニズムとは異なり、Red Hat OpenShift Service Mesh ゲートウェイではトラフィックのルーティングの機能および柔軟性を最大限に利用できます。Red Hat OpenShift Service Mesh ゲートウェイリソースは、Red Hat OpenShift Service Mesh TLS 設定を公開して構成するポートなど、4-6 の負荷分散プロパティーを階層化できます。アプリケーション層のトラフィックルーティング (L7) を同じ API リソースに追加する代わりに、通常の Red Hat OpenShift Service Mesh 仮想サービスをゲートウェイにバインドし、サービスメッシュ内の他のデータプレーントラフィックのようにゲートウェイトラフィックを管理することができます。

ゲートウェイは ingress トラフィックの管理に主に使用されますが、egress ゲートウェイを設定することもできます。egress ゲートウェイを使用すると、メッシュからのトラフィック専用の終了ノードを設定できます。これにより、サービスメッシュにセキュリティー制御を追加することで、外部ネットワークにアクセスできるサービスを制限できます。また、ゲートウェイを使用して完全に内部のプロキシーを設定することもできます。

ゲートウェイの例

以下の例は、外部 HTTPS Ingress トラフィックのゲートウェイ設定を示しています。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: ext-host-gwy
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - ext-host.example.com
    tls:
      mode: SIMPLE
      serverCertificate: /tmp/tls.crt
      privateKey: /tmp/tls.key

このゲートウェイ設定により、ポート 443 での ext-host.example.com からメッシュへの HTTPS トラフィックが可能になりますが、トラフィックのルーティングは指定されません。

ルーティングを指定し、ゲートウェイが意図される通りに機能するには、ゲートウェイを仮想サービスにバインドする必要もあります。これは、以下の例のように、仮想サービスのゲートウェイフィールドを使用して実行します。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: virtual-svc
spec:
  hosts:
  - ext-host.example.com
  gateways:
    - ext-host-gwy

次に、仮想サービスを外部トラフィックのルーティングルールを使用して設定できます。

1.13.2.2.5. サービスエントリー

サービスエントリーは、Red Hat OpenShift Service Mesh が内部で維持するサービスレジストリーにエントリーを追加します。サービスエントリーの追加後、Envoy プロキシーはメッシュ内のサービスであるかのようにトラフィックをサービスに送信できます。サービスエントリーを使用すると、以下が可能になります。

  • サービスメッシュ外で実行されるサービスのトラフィックを管理します。
  • Web から消費される API やレガシーインフラストラクチャーのサービスへのトラフィックなど、外部宛先のトラフィックをリダイレクトし、転送します。
  • 外部宛先の再試行、タイムアウト、およびフォールトインジェクションポリシーを定義します。
  • 仮想マシンをメッシュに追加して、仮想マシン (VM) でメッシュサービスを実行します。
注記

別のクラスターからメッシュにサービスを追加し、Kubernetes でマルチクラスター Red Hat OpenShift Service Mesh メッシュを設定します。

サービスエントリーの例

以下の mesh-external サービスエントリーの例では、 ext-resource の外部依存関係を Red Hat OpenShift Service Mesh サービスレジストリーに追加します。

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: svc-entry
spec:
  hosts:
  - ext-svc.example.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS

hosts フィールドを使用して外部リソースを指定します。これを完全に修飾することも、ワイルドカードのプレフィックスが付けられたドメイン名を使用することもできます。

仮想サービスおよび宛先ルールを設定して、メッシュ内の他のサービスのトラフィックを設定するのと同じように、サービスエントリーへのトラフィックを制御できます。たとえば、以下の宛先ルールでは、トラフィックルートを、サービスエントリーを使用して設定される ext-svc.example.com 外部サービスへの接続のセキュリティーを保護するために相互 TLS を使用するように設定します。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ext-res-dr
spec:
  host: ext-svc.example.com
  trafficPolicy:
    tls:
      mode: MUTUAL
      clientCertificate: /etc/certs/myclientcert.pem
      privateKey: /etc/certs/client_private_key.pem
      caCertificates: /etc/certs/rootcacerts.pem

1.13.3. Ingress トラフィックの管理

Red Hat OpenShift Service Mesh では、Ingress Gateway は、モニタリング、セキュリティー、ルートルールなどのサービスメッシュ機能をクラスターに入るトラフィックに適用できるようにします。サービスメッシュゲートウェイを使用してサービスメッシュ外のサービスを公開します。

1.13.3.1. Ingress IP およびポートの判別

Ingress 設定は、環境が外部ロードバランサーをサポートするかどうかによって異なります。外部ロードバランサーはクラスターの Ingress IP およびポートに設定されます。クラスターの IP およびポートが外部ロードバランサーに設定されているかどうかを判別するには、以下のコマンドを実行します。この例では、istio-system は、コントロールプレーンプロジェクトです。

$ oc get svc istio-ingressgateway -n istio-system

このコマンドは、namespace のそれぞれの項目の NAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)、および AGE を返します。

EXTERNAL-IP 値が設定されている場合には、環境には Ingress ゲートウェイに使用できる外部ロードバランサーがあります。

EXTERNAL-IP の値が <none> または永続的に <pending> の場合、環境は Ingress ゲートウェイの外部ロードバランサーを提供しません。サービスの ノードポート を使用してゲートウェイにアクセスできます。

お使いの環境に応じて Ingress を判別します。ロードバランサーがサポートされる環境の場合は、ロードバランサーで Ingress ポートを決定します。ロードバランサーをサポートしない環境では、ロードバランサーを使用せずに Ingress ポートを決定 します。Ingress ポートを特定した後に、「ゲートウェイを使用した ingress の設定」で設定を完了します。

1.13.3.1.1. ロードバランサーを使用した Ingress ポートの判別

お使いの環境に外部ロードバランサーがある場合には、以下の手順に従います。

手順

  1. 以下のコマンドを実行して Ingress IP およびポートを設定します。このコマンドは、ターミナルに変数を設定します。

    $ export INGRESS_HOST=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
  2. 以下のコマンドを実行して Ingress ポートを設定します。

    $ export INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
  3. 以下のコマンドを実行してセキュアな Ingress ポートを設定します。

    $ export SECURE_INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].port}')
  4. 以下のコマンドを実行して TCP Ingress ポートを設定します。

    $ export TCP_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="tcp")].port}')
注記

一部の環境では、ロードバランサーは IP アドレスの代わりにホスト名を使用して公開される場合があります。この場合、Ingress ゲートウェイの EXTERNAL-IP 値は IP アドレスではありません。これはホスト名であり、直前のコマンドは INGRESS_HOST 環境変数の設定に失敗します。

失敗した場合には、以下のコマンドを使用して INGRESS_HOST 値を修正します。

$ export INGRESS_HOST=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
1.13.3.1.2. ロードバランサーのない Ingress ポートの判別

お使いの環境に外部ロードバランサーがない場合は、Ingress ポートを判別し、代わりにノードポートを使用します。

手順

  1. Ingress ポートを設定します。

    $ export INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')
  2. 以下のコマンドを実行してセキュアな Ingress ポートを設定します。

    $ export SECURE_INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')
  3. 以下のコマンドを実行して TCP Ingress ポートを設定します。

    $ export TCP_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="tcp")].nodePort}')

1.13.4. ゲートウェイを使用した ingress の設定

Ingress ゲートウェイは、受信 HTTP/TCP 接続を受信するメッシュのエッジで稼働するロードバランサーです。このゲートウェイは、公開されるポートおよびプロトコルを設定しますが、これにはトラフィックルーティングの設定は含まれません。Ingress トラフィックに対するトラフィックルーティングは、内部サービス要求の場合と同様に、ルーティングルールで設定されます。

以下の手順では、ゲートウェイを作成し、/productpage/login のパスの外部トラフィックに、Bookinfo サンプルアプリケーションのサービスを公開するように、VirtualService を設定します。

手順

  1. トラフィックを受け入れるゲートウェイを作成します。

    1. YAML ファイルを作成し、以下の YAML をこれにコピーします。

      ゲートウェイの例 (gateway.yaml)

      apiVersion: networking.istio.io/v1alpha3
      kind: Gateway
      metadata:
        name: bookinfo-gateway
      spec:
        selector:
          istio: ingressgateway
        servers:
        - port:
            number: 80
            name: http
            protocol: HTTP
          hosts:
          - "*"

    2. YAML ファイルを適用します。

      $ oc apply -f gateway.yaml
  2. VirtualService オブジェクトを作成し、ホストヘッダーを再作成します。

    1. YAML ファイルを作成し、以下の YAML をこれにコピーします。

      仮想サービスの例 (vs.yaml)

      apiVersion: networking.istio.io/v1alpha3
      kind: VirtualService
      metadata:
        name: bookinfo
      spec:
        hosts:
        - "*"
        gateways:
        - bookinfo-gateway
        http:
        - match:
          - uri:
              exact: /productpage
          - uri:
              prefix: /static
          - uri:
              exact: /login
          - uri:
              exact: /logout
          - uri:
              prefix: /api/v1/products
          route:
          - destination:
              host: productpage
              port:
                number: 9080

    2. YAML ファイルを適用します。

      $ oc apply -f vs.yaml
  3. ゲートウェイと VirtualService が正しく設定されていることを確認してください。

    1. ゲートウェイ URL を設定します。

      export GATEWAY_URL=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.host}')
    2. ポート番号を設定します。この例では、istio-system は、コントロールプレーンプロジェクトです。

      export TARGET_PORT=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.port.targetPort}')
    3. 明示的に公開されているページをテストします。

      curl -s -I "$GATEWAY_URL/productpage"

      想定される結果は 200 です。

1.13.5. 自動ルート

Istio ゲートウェイの OpenShift ルートは、Service Mesh で自動的に管理されます。Istio ゲートウェイがサービスメッシュ内で作成され、更新され、削除されるたびに、OpenShift ルートが作成され、更新され、削除されます。

1.13.5.1. サブドメイン

Red Hat OpenShift Service Mesh はサブドメインでルートを作成しますが、OpenShift Container Platform はこれを有効にするように設定される必要があります。*.domain.com などのサブドメインはサポートされますが、デフォルトでは設定されません。ワイルドカードホストゲートウェイを設定する前に OpenShift Container Platform ワイルドカードポリシーを設定します。詳細は、ワイルドカードルートの使用 を参照してください。

1.13.5.2. サブドメインルートの作成

以下の例では、サブドメインルートを作成する Bookinfo サンプルアプリケーションにゲートウェイを作成します。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: gateway1
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - www.bookinfo.com
    - bookinfo.example.com

次に、以下の OpenShift ルートが自動的に作成されます。ルートが以下のコマンドを使用して作成されていることを確認できます。この例では、istio-system は、コントロールプレーンプロジェクトです。

$ oc -n istio-system get routes

予想される出力

NAME           HOST/PORT             PATH  SERVICES               PORT  TERMINATION   WILDCARD
gateway1-lvlfn bookinfo.example.com        istio-ingressgateway   <all>               None
gateway1-scqhv www.bookinfo.com            istio-ingressgateway   <all>               None

このゲートウェイが削除されると、Red Hat OpenShift Service Mesh はルートを削除します。ただし、手動で作成されたルートは Red Hat OpenShift Service Mesh によって変更されることはありません。

1.13.5.3. アノテーション

特定のアノテーションが OpenShift ルートに必要です。たとえば、OpenShift Route の高度な機能は 特殊なアノテーション で管理されます。このユースケースおよび他のユースケースでは、Red Hat OpenShift Service Mesh は (kubectl.kubernetes.io で始まるものを除く) Istio Gateway リソースにあるすべてのアノテーションを管理対象の OpenShift Route リソースにコピーします。

Service Mesh によって作成される OpenShift ルートで特定のアノテーションが必要な場合は、それらを Istio Gateway リソースに作成し、Service Mesh で管理される OpenShift Route リソースにコピーされます。

1.13.5.4. 自動ルート作成の無効化

デフォルトで、ServiceMeshControlPlane リソースは Gateway リソースと OpenShift ルートを自動的に同期します。自動ルート作成を無効にすると、特殊なケースがある場合やルートを手動で制御する場合に、ルートをより柔軟に制御できます。

Istio ゲートウェイと OpenShift ルート間の統合を無効にするには、ServiceMeshControlPlane フィールド gateways.openshiftRoute.enabledfalse に設定します。たとえば、以下のリソーススニペットを参照してください。

spec:
  gateways:
    openshiftRoute:
      enabled: false

1.13.5.5. サイドカー

デフォルトで、Red Hat OpenShift Service Mesh は、すべての Envoy プロキシーを、トラフィックの転送時にすべてのポートで関連付けられたワークロードについてのトラフィックを受け入れ、メッシュ内のすべてのワークロードに到達するように設定します。サイドカー設定を使用して以下を実行できます。

  • Envoy プロキシーが受け入れるポートとプロトコルのセットを微調整します。
  • Envoy プロキシーが到達できるサービスのセットを制限します。
注記

サービスメッシュのパフォーマンスを最適化するには、Envoy プロキシー設定の制限を検討してください。

Bookinfo サンプルアプリケーションで、同じ namespace およびコントロールプレーンで実行されている他のサービスに度のサービスからでもアクセスできるように Sidecar を設定します。この Sidecar 設定は、Red Hat OpenShift Service Mesh ポリシーおよび Telemetry 機能での使用に必要になります。

手順

  1. 以下の例を使用して YAML ファイルを作成し、サイドカー設定を特定の namespace の全ワークロードに適用するように指定します。それ以外の場合は、workloadSelector を使用して特定のワークロードを選択します。

    sidecar.yaml の例

    apiVersion: networking.istio.io/v1alpha3
    kind: Sidecar
    metadata:
      name: default
      namespace: bookinfo
    spec:
      egress:
      - hosts:
        - "./*"
        - "istio-system/*"

  2. 以下のコマンドを実行して sidecar.yaml を適用します。ここでは、sidecar.yaml はファイルへのパスです。

    $ oc apply -f sidecar.yaml
  3. サイドカーが正常に作成されたことを確認するには、以下のコマンドを実行します。

    $ oc get sidecar

1.14. メトリクスとトレース

Kiali コンソールでアプリケーションのトポロジー、健全性、およびメトリクスを表示できます。サービスで問題が発生する場合には、Kiali コンソールは、サービス経由でデータフローを表示できます。抽象アプリケーションからサービスおよびワークロードまで、さまざまなレベルでのメッシュコンポーネントに関する洞察を得ることができます。また Kiali は、リアルタイムで namespace のインタラクティブなグラフビューを提供します。

アプリケーションがインストールされている場合には、アプリケーション経由でデータフローを確認できます。独自のアプリケーションがインストールされていない場合、Bookinfo サンプルアプリケーション をインストールして、Red Hat OpenShift Service Mesh での可観測性の機能を確認できます。

1.14.1. CLI からのメトリクスおよびトレースデータへのアクセス

Jaeger、Prometheus、および Grafana コンソールにアクセスして、データを表示し、管理します。

手順

  1. コントロールプレーンプロジェクトに切り替えます。この例では、istio-system はコントロールプレーンプロジェクトです。以下のコマンドを実行します。

    $ oc project istio-system
  2. Red Hat OpenShift Service Mesh コンポーネントへのルートを取得します。以下のコマンドを実行します。

    $ oc get routes

    このコマンドは、Kiali、Jaeger、Prometheus、および Grafana の Web コンソールの URL とサービスメッシュ内の他のルートの URL を返します。

  3. HOST/PORT コラムからブラウザーにコンポーネントの URL をコピーし、コンソールを開きます。

1.14.2. Service Mesh データの表示

Kiali Operator は、Red Hat OpenShift Service Mesh に収集される Telemetry データと連携して、namespace のアプリケーション、サービス、およびワークロードのグラフとリアルタイムのネットワーク図を提供します。

Kiali コンソールにアクセスするには、Red Hat OpenShift Service Mesh がインストールされており、サービスメッシュ用にプロジェクトを設定する必要があります。

手順

  1. パースペクティブスイッチャーを使用して、Administrator パースペクティブに切り替えます。
  2. HomeProjects をクリックします。
  3. プロジェクトの名前をクリックします。たとえば、bookinfo をクリックします。
  4. Launcher セクションで、Kiali をクリックします。
  5. OpenShift Container Platform コンソールにアクセスするときに使用するものと同じユーザー名とパスワードを使用して Kiali コンソールにログインします。

初回の Kiali コンソールへのログイン時に、表示するパーミッションを持つサービスメッシュ内のすべての namespace を表示する Overview ページが表示されます。

コンソールのインストールを検証する場合は、表示するデータがないことがあります。

1.14.2.1. Kiali コンソールでのデータの使用

Kiali コンソールの Graph メニューから、以下のグラフと表示ツールを使用して、サービスメッシュを通過するデータに関する詳細な見解が得られます。これらのツールでは、サービスやワークロードに関する問題を特定することができます。

以下から選択できるグラフがいくつかあります。

  • App グラフ は、同じラベルが付けられたすべてのアプリケーションの集約ワークロードを示します。
  • Versioned App グラフ は、アプリケーションの各バージョンのノードを表示します。アプリケーションの全バージョンがグループ化されます。
  • Workload グラフ は、サービスメッシュの各ワークロードのノードを表示します。このグラフでは、app および version のラベルを使用する必要はありません。アプリケーションが version ラベルを使用しない場合は、このグラフを使用します。
  • Service グラフ は、メッシュ内の各サービスのノードを表示しますが、グラフからすべてのアプリケーションおよびワークロードを除外します。これは高レベルのビューを提供し、定義されたサービスのすべてのトラフィックを集約します。

メトリクスの要約を表示するには、グラフ内のノードまたはエッジを選択し、そのメトリクスの詳細をサマリーの詳細パネルに表示します。

1.14.2.1.1. namespace グラフ

namespace グラフは、namespace のサービス、デプロイメント、およびワークフローのマップであり、それらを通過するデータフローを示す矢印が表示されます。

前提条件

  • Bookinfo サンプルアプリケーションをインストールします。

手順

  1. 以下のコマンドを複数回入力してメッシュにトラフィックを送ります。

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

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

  2. メインナビゲーションで Graph をクリックし、namespace グラフを表示します。
  3. Namespace メニューから bookinfo を選択します。

1.14.3. 分散トレース

分散トレースは、アプリケーションのサービス呼び出しのパスを追跡して、アプリケーション内の個々のサービスのパフォーマンスを追跡するプロセスです。アプリケーションでユーザーがアクションを起こすたびに、要求が実行され、多くのサービスが応答を生成するために対話する必要がある場合があります。この要求のパスは、分散トランザクションと呼ばれます。

Red Hat OpenShift Service Mesh は Jaeger を使用して、開発者がマイクロサービスアプリケーションで呼び出しフローを表示できるようにします。

1.14.3.1. サンプルトレースの生成とトレースデータの分析

Jaeger はオープンソースの分散トレースシステムです。Jaeger を使用すると、トレースを実行でき、アプリケーションを構成するさまざまなマイクロサービスで要求のパスを追跡します。Jaeger はデフォルトでサービスメッシュの一部としてインストールされます。

このチュートリアルでは、サービスメッシュと Bookinfo サンプルアプリケーションを使用して、Jaeger で分散トレースを実行する方法を示します。

前提条件:

  • OpenShift Container Platform 4.1 以降がインストールされている。
  • Red Hat OpenShift Service Mesh 2.0.8 がインストールされている。
  • インストール時に Jaeger が有効にされている。
  • Bookinfo のサンプルアプリケーションがインストールされている。

手順

  1. Bookinfo サンプルアプリケーションのインストール後に、トラフィックをメッシュに送信します。以下のコマンドを数回入力します。

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

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

  2. OpenShift Container Platform コンソールで、NetworkingRoutes に移動し、Jaeger ルートを検索します。これは Location に一覧される URL です。

    • または CLI を使用してルートの詳細のクエリーを実行します。この例では、istio-system はコントロールプレーン namespace です。

      $ export JAEGER_URL=$(oc get route -n istio-system jaeger -o jsonpath='{.spec.host}')
      1. 以下のコマンドを実行して Jaeger コンソールの URL を表示します。結果をブラウザーに貼り付け、その URL に移動します。

        echo $JAEGER_URL
  3. OpenShift Container Platform コンソールへアクセスするときに使用するものと同じユーザー名とパスワードを使用してログインします。
  4. Jaeger ダッシュボードの左側のペインで、サービス メニューから productpage.bookinfo を選択し、ペイン下部の Find Traces ボタンをクリックします。トレースの一覧が表示されます。
  5. 一覧のトレースのいずれかをクリックし、そのトレースの詳細ビューを開きます。一覧で最初の項目をクリックすると、'/productpage の最終更新に対応する詳細が表示されます。

1.14.3.2. サンプリングレートの調整

分散トレースのサンプリングレートは、デフォルトでサービスメッシュでトレースの 100% をサンプリングするようにに設定します。サンプリングレートはクラスターリソースおよびパフォーマンスを消費しますが、問題のデバッグを行う場合に役立ちます。Red Hat OpenShift Service Mesh を実稼働環境でデプロイする前に、値を小さめのトレースサイズに設定します。

トレースは、サービスメッシュ内のサービス間の実行パスです。トレースは、1 つ以上のスパンで構成されます。スパンは、名前、開始時間、および期間を持つ作業の論理単位です。

サンプリングレートは、トレースの生成頻度を定めます。サンプリングは 0.01% の増分を表すスケーリングされた整数として設定します。

基本的なインストールでは、spec.tracing.sampling10000 に設定され、トレースの 100% をサンプリングします。以下は例になります。

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

値を 10000 に設定するとデバッグには役立ちますが、パフォーマンスに影響する可能性があります。実稼働環境の場合は、spec.tracing.sampling100 に設定します。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsInstalled Operators をクリックします。
  2. Project メニューをクリックし、コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. Red Hat OpenShift Service Mesh Operator をクリックします。Istio Service Mesh Control Plane 列で、ServiceMeshControlPlane リソースの名前(basic など) をクリックします。
  4. サンプリングレートを調整するには、spec.tracing.sampling に別の値を設定します。

    1. YAML タブをクリックします。
    2. ServiceMeshControlPlane リソースで spec.tracing.sampling の値を設定します。以下の例では、100 に設定します。

      Jaeger サンプリングの例

      spec:
        tracing:
          sampling: 100

    3. Save をクリックします。
  5. Reload をクリックして、ServiceMeshControlPlane リソースが正しく設定されていることを確認します。

1.14.3.3. スタンドアロン Jaeger の接続

OpenShift Container Platform で分散トレースにスタンドアロンの Jaeger がすでにある場合は、Red Hat OpenShift Service Mesh でインストールされたものではなく、スタンドアロンの Jaeger インスタンスを使用するように ServiceMeshControlPlane リソースを設定します。

前提条件

  • スタンドアロンの Jaeger インスタンスを設定し、デプロイしておく。詳細は、Jaeger ドキュメントを参照してください。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsInstalled Operators をクリックします。
  2. Project メニューをクリックし、コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. Red Hat OpenShift Service Mesh Operator をクリックします。Istio Service Mesh Control Plane 列で、ServiceMeshControlPlane リソースの名前(basic など) をクリックします。
  4. スタンドアロンの Jaeger インスタンスの名前を ServiceMeshControlPlane に追加します。

    1. YAML タブをクリックします。
    2. スタンドアロン Jaeger インスタンスの名前を ServiceMeshControlPlane リソースの spec.addons.jaeger.name に追加します。以下の例では、simple-prod はスタンドアロン Jaeger インスタンスの名前です。

      スタンドアロン Jaeger の例

      spec:
        addons:
          jaeger:
            name: simple-prod

    3. Save をクリックします。
  5. Reload をクリックして、ServiceMeshControlPlane リソースが正しく設定されていることを確認します。

Jaeger の設定に関する詳細は、Jaeger ドキュメント を参照してください。

1.14.4. Grafana へのアクセス

Grafana は、サービスメッシュメトリクスの表示、クエリー、および分析に使用できる解析ツールです。この例では、istio-system はコントロールプレーン namespace です。Grafana にアクセスするには、以下の手順を実施します。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. Project メニューをクリックし、コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. Routes をクリックします。
  4. Grafana 行の Location コラムのリンクをクリックします。
  5. OpenShift Container Platform 認証情報を使用して Grafana コンソールにログインします。

1.14.5. Prometheus へのアクセス

Prometheus は、マイクロサービスに関する多次元データの収集に使用できるモニタリングおよびアラートツールです。この例では、istio-system はコントロールプレーン namespace です。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. Project メニューをクリックし、コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. Routes をクリックします。
  4. Prometheus 行の Location コラムのリンクをクリックします。
  5. OpenShift Container Platform 認証情報を使用して Prometheus コンソールにログインします。

1.15. パフォーマンスおよびスケーラビリティー

デフォルトの ServiceMeshControlPlane 設定は実稼働環境での使用を目的としていません。それらはリソース面で制限のあるデフォルトの OpenShift Container Platform インストールに正常にインストールされるように設計されています。SMCP インストールに成功したことを確認したら、SMCP 内で定義した設定をお使いの環境に合わせて変更する必要があります。

1.15.2. テスト結果の読み込み

アップストリームの Istio コミュニティーの負荷テストのメッシュは、1 秒あたり 70,000 のメッシュ全体の要求を持つ 1000 サービスと 2000 サイドカーで構成されます。Istio 1.6.8 を使用してテストを実行後、以下の結果が生成されました。

  • Envoy プロキシーは、プロキシーを通過する 1 秒あたり/要求 1000 件あたり 0.5 vCPU および 50 MB メモリー を使用します。
  • Istiod は 1 vCPU および 1.5 GB のメモリーを使用します。
  • Envoy プロキシーは 3.12 ms を 90 % レイテンシーに追加します。
  • レガシー istio-telemetry サービス (Service Mesh 2.0 ではデフォルトで無効にされます) は、Mixer を使用するデプロイメントについて、1 秒あたりの 1000 のメッシュ全体の要求ごとに 0.6 vCPU を使用します。データプレーンのコンポーネントである Envoy プロキシーは、システムを通過するデータフローを処理します。コントロールプレーンのコンポーネントである Istiod はデータプレーンを設定します。データプレーンおよびコントロールプレーンには、さまざまなパフォーマンスに関する懸念点があります。

1.15.2.1. コントロールプレーンのパフォーマンス

Istiod は、ユーザーが作成する設定ファイルおよびシステムの現在の状態に基づいてサイドカープロキシーを設定します。Kubernetes 環境では、カスタムリソース定義 (CRD) およびデプロイメントはシステムの設定および状態を構成します。ゲートウェイや仮想サービスなどの Istio 設定オブジェクトは、ユーザーが作成する設定を提供します。プロキシーの設定を生成するために、Istiod は Kubernetes 環境およびユーザー作成の設定から、組み合わせた設定およびシステムの状態を処理します。

コントロールプレーンは、数千のサービスをサポートし、これらは同様の数のユーザーが作成する仮想サービスおよびその他の設定オブジェクトと共に数千の Pod 全体に分散されます。Istiod の CPU およびメモリー要件は、設定数および使用可能なシステムの状態と共にスケーリングされます。CPU の消費は、以下の要素でスケーリングします。

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

ただし、この部分は水平的にスケーリングが可能です。

1.15.2.2. データプレーンのパフォーマンス

データプレーンのパフォーマンスは、以下を含む数多くの要因によって変わります。

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

レイテンシー、スループット、およびプロキシーの CPU およびメモリーの消費は、これらの要素の関数として測定されます。

1.15.2.2.1. CPU およびメモリーの消費

サイドカープロキシーはデータパスで追加の作業を実行するため、CPU およびメモリーを消費します。Istio 1.1 の時点で、プロキシーは 1 秒あたり 1000 要求ベースで 0.6 vCPU を消費します。

プロキシーのメモリー消費は、プロキシーが保持する設定の状態の合計数によって異なります。多数のリスナー、クラスター、およびルートは、メモリーの使用量を増やす可能性があります。

通常、プロキシーは通過するデータをバッファーに入れないため、要求レートはメモリー消費には影響を及ぼしません。

1.15.2.2.2. その他のレイテンシー

Istio はデータパスにサイドカープロキシーを挿入するため、レイテンシーは重要な考慮事項になります。Istio は認証フィルター、Telemetry フィルター、およびメタデータ交換フィルターをプロキシーに追加します。すべての追加フィルターはプロキシー内のパスの長さに追加され、これはレイテンシーに影響を及ぼします。

Envoy プロキシーは、応答がクライアントに送信された後に未加工の Telemetry データを収集します。要求についての未加工の Telemetry の収集に費やされる時間は、その要求の完了にかかる合計時間には影響を与えません。ただし、ワーカーは要求処理にビジー状態になるため、ワーカーは次の要求の処理をすぐに開始しません。このプロセスは、次の要求のキューの待機時間に追加され、平均のレイテンシーおよびテイルレイテンシー (Tail Latency) に影響を及ぼします。実際のテイルレイテンシーは、トラフィックのパターンによって異なります。

メッシュ内で、要求はクライアント側のプロキシーを通過してから、サーバー側のプロキシーを通過します。Istio 1.6.8 のデフォルト設定 (Istio と Telemetry v2) では、2 つのプロキシーは、ベースラインのデータプレーンのレイテンシーに対してそれぞれ約 3.12 ms および 3.13 ms を 90 および 99 番目のパーセンタイルレイテンシーに追加します。

1.16. 実稼働環境のサービスメッシュの設定

基本インストールから実稼働環境に移行する準備ができたら、実稼働環境の要件を満たすようにコントロールプレーン、トレーシング、およびセキュリティー証明書を設定する必要があります。

前提条件

  • Red Hat OpenShift Service Mesh をインストールして設定しておく。
  • ステージング環境で設定をテストしておく

1.16.1. 実稼働環境用の ServiceMeshControlPlane リソース設定

サービスメッシュをテストするために基本的な ServiceMeshControlPlane リソースをインストールしている場合は、実稼働環境で Red Hat OpenShift Service Mesh を使用する前にこれを実稼働仕様に設定する必要があります。

既存の ServiceMeshControlPlane リソースの metadata.name フィールドを変更できません。実稼働デプロイメントの場合は、デフォルトのテンプレートをカスタマイズする必要があります。

手順

  1. 実稼働環境の Jaeger を設定します。

    1. ServiceMeshControlPlane リソースは、production デプロイメントストラテジーを使用するように編集するには、spec.addons.jaeger.install.storage.typeElasticsearch に設定し、install で追加設定オプションを指定します。または、Jaeger インスタンスを作成および設定し、spec.addons.jaeger.name を Jaeger インスタンスの名前 (例: jaeger-production) に設定できます。

      デフォルト Jaeger パラメーター (例: Elasticsearch)

      apiVersion: maistra.io/v2
      kind: ServiceMeshControlPlane
      metadata:
        name: basic
      spec:
        version: v2.0
        tracing:
          sampling: 100
          type: Jaeger
        addons:
          jaeger:
            name: jaeger-production
            install:
              storage:
                type: Elasticsearch
              ingress:
                enabled: true
        runtime:
          components:
            tracing.jaeger.elasticsearch: # only supports resources and image name
              container:
                resources: {}

    2. 実稼働環境のサンプリングレートを設定します。詳細は、「パフォーマンスおよびスケーラビリティー」セクションを参照してください。
  2. 外部認証局からセキュリティー証明書をインストールして、セキュリティー証明書が実稼働可能であることを確認します。詳細は、「セキュリティー」のセクションを参照してください。
  3. 結果を確認します。以下のコマンドを実行して、ServiceMeshControlPlane リソースが適切に更新されていることを確認します。この例では、basicServiceMeshControlPlane リソースの名前です。

    $ oc get smcp basic -o yaml

1.16.2. 関連情報

  • パフォーマンス用のサービスメッシュのチューニングについての詳細は、「Perforance and Scalability」を参照してください。

1.17. 拡張

WebAssembly 拡張を使用して、新機能を直接 Red Hat OpenShift Service Mesh プロキシーに直接追加し、アプリケーションからさらに一般的な機能を移動し、それらを WebAssembly バイトコードにコンパイルする単一言語に実装できます。

1.17.1. WebAssembly 拡張

WebAssembly モジュールは、プロキシーなどの多くのプラットフォームで実行でき、これには、幅広い言語サポート、高速実行、および sandboxed-by-default (デフォルトでサンドボックス化される) セキュリティーモデルが含まれます。

拡張機能

Red Hat OpenShift Service Mesh 拡張機能として Envoy HTTP フィルターを使用でき、幅広い機能を提供します。

  • 要求と応答の本体とヘッダーの操作
  • 認証やポリシーのチェックなど、要求パスにないサービスへの帯域外 HTTP リクエスト
  • 相互に通信するフィルター用のサイドチャネルデータストレージおよびキュー

Red Hat OpenShift Service Mesh 機能の作成は 2 つの部分から構成されます。proxy-wasm API を公開する SDK を使用して拡張を作成し、これを WebAssembly モジュールにコンパイルしてからコンテナーにパッケージ化する必要があります。

サポート言語

WebAssembly バイトコードにコンパイルする言語を使用して Red Hat OpenShift Service Mesh 拡張を作成できますが、以下の言語には proxy-wasm API を公開する既存の SDK があるため、これを直接使用できます。

表1.4 サポート言語

言語保守管理者リポジトリー

AssemblyScript

solo.io

solo-io/proxy-runtime

C++

proxy-wasm チーム (Istio コミュニティー)

proxy-wasm/proxy-wasm-cpp-sdk

Go

tetrate.io

tetratelabs/proxy-wasm-go-sdk

Rust

proxy-wasm チーム (Istio コミュニティー)

proxy-wasm/proxy-wasm-rust-sdk

1.17.1.1. コンテナーのフォーマット

コンテナーイメージを有効な拡張イメージにするために、WebAssembly モジュールのバイトコードを含む .wasm ファイルとコンテナーファイルシステムのルートに manifest.yaml ファイルが必要です。

manifest.yaml

schemaVersion: 1

name: <your-extension>
description: <description>
version: 1.0.0
phase: PreAuthZ
priority: 100
module: extension.wasm

表1.5 manifest.yml フィールドの参照情報

フィールド詳細

schemaVersion

マニフェストスキーマのバージョン管理に使用されます。現時点で使用できる値は 1 のみです。

name

拡張の名前です。このフィールドは単なるメタデータであり、現時点では使用されていません。

description

拡張の説明。このフィールドは単なるメタデータであり、現時点では使用されていません。

version

拡張のバージョンです。このフィールドは単なるメタデータであり、現時点では使用されていません。

phase

拡張のデフォルトの実行フェーズです。これは必須フィールドです。

priority

拡張のデフォルトの優先度です。これは必須フィールドです。

module

コンテナーファイルシステムのルートから WebAssembly モジュールへの相対パスです。これは必須フィールドです。

1.17.1.2. Rust 拡張の例

Rust SDK を使用してビルドされる完全なサンプルについては、header-append-filter を参照してください。このフィルターは、設定に応じて異なる値を使用してヘッダー custom-header をすべての応答に追加します。

1.17.1.3. WebAssembly 拡張サポートの有効化

Red Hat OpenShift Service Mesh への WebAssembly 拡張のサポートは現時点で テクノロジープレビュー であるため、ServiceMeshControlPlane に対して明示的に有効にする必要があります。この例では、istio-system は、コントロールプレーンプロジェクトです。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsInstalled Operators をクリックします。
  2. Project メニューから、コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. Red Hat OpenShift Service Mesh Operator をクリックします。Istio Service Mesh Control Plane 列で、ServiceMeshControlPlane リソースの名前(basic など) をクリックします。
  4. YAML タブをクリックします。
  5. ServiceMeshControlPlane リソース で spec.techPreview.wasmExtensions.enabledtrue に設定します。以下は例になります。

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    metadata:
      name: openid-connect
      namespace: istio-system
    spec:
      techPreview:
        wasmExtensions:
          enabled: true
  6. Save をクリックします。
  7. Reload をクリックして、ServiceMeshControlPlane リソースが正しく設定されていることを確認します。

1.17.1.4. 拡張のデプロイ

Red Hat OpenShift Service Mesh 拡張機能は ServiceMeshExtension リソースを使用して有効にできます。この例では、istio-system は、コントロールプレーンプロジェクトです。

手順

  1. 以下のリソース例を作成します。

    ServiceMeshExtension リソース拡張機能の例

    apiVersion: maistra.io/v1alpha1
    kind: ServiceMeshExtension
    metadata:
      name: header-append
      namespace: istio-system
    spec:
      workloadSelector:
        labels:
          app: httpbin
      config: test
      image: quay.io/maistra-dev/header-append-filter:2.0
      phase: PostAuthZ
      priority: 100

  2. 以下のコマンドを使用して extension.yaml ファイルを適用します。

    $ oc apply -f extension.yaml

表1.6 ServiceMeshExtension フィールドの参照情報

フィールド詳細

metadata.namespace

ServiceMeshExtension ソースの metadata.namespace には特殊なセマンティクスが含まれます。これが Control Plane Namespace と等しい場合、拡張はその workloadSelector に一致するサービスメッシュのすべてのワークロードに適用されます。これは、その他の Mesh namespace にデプロイされる場合、同じ namespace のワークロードにのみ適用されます。

spec.workloadSelector

spec.workloadSelector フィールドには、Istio Gateway リソースspec.selector フィールドと同じセマンティクスが含まれます。これは Pod ラベルに基づいてワークロードに一致します。workloadSelector が指定されていない場合、拡張は namespace のすべてのワークロードに適用されます。

spec.config

これは、拡張に転送されるパススルー文字列フィールドです。構文とセマンティクスは、デプロイする拡張によって異なります。

spec.image

拡張を保持するイメージを参照するコンテナーイメージ URI です。

spec.phase

このフィールドは、拡張の manifest.yaml で設定される値にデフォルト設定されますが、ユーザーが上書きできます。このフェーズでは、認証、認可、メトリクスの生成などの既存の Istio 機能に関連して、拡張が挿入されるフィルターチェーン内の場所を決定します。有効な値は、PreAuthN、PostAuthN、PreAuthZ、PostAuthZ、PreStats、PostStats です。このフィールドは、拡張の manifest.yaml で設定される値にデフォルト設定されますが、ユーザーが上書きできます。

spec.priority

同じ spec.phase を持つ複数の拡張機能が同じワークロードインスタンスに適用される場合、spec.priority は実行の順序を決定します。優先度が高い拡張機能が最初に実行されます。これにより、相互に依存する拡張が使用可能になります。このフィールドは、拡張の manifest.yaml で設定される値にデフォルト設定されますが、ユーザーが上書きできます。

1.18. 3scale Istio アダプターの使用

3scale Istio アダプターはオプションのアダプターであり、これを使用すると、Red Hat OpenShift Service Mesh 内で実行中のサービスにラベルを付け、そのサービスを 3scale API Management ソリューションと統合できます。これは Red Hat OpenShift Service Mesh には必要ありません。

重要

3scale Istio アダプターで 3scale バックエンドキャッシュを有効にする必要がある場合には、Mixer ポリシーと Mixer Telemetry も有効にする必要があります。「Red Hat OpenShift Service Mesh コントロールプレーンのデプロイ」を参照してください。

1.18.1. 3scale アダプターと Red Hat OpenShift Service Mesh の統合

これらの例を使用して、3scale Istio アダプターを使用してサービスに対する要求を設定できます。

前提条件:

  • Red Hat OpenShift Service Mesh バージョン 2.x
  • 稼働している 3scale アカウント (SaaS または 3scale 2.9 On-Premises)
  • バックエンドキャッシュを有効にするには 3scale 2.9 以上が必要です。
  • Red Hat OpenShift Service Mesh の前提条件
  • Mixer ポリシーの適用が有効になっていることを確認します。Mixer ポリシー適用の更新についてのセクションでは、現在の Mixer ポリシーの適用ステータスをチェックし、ポリシーの適用を有効にする手順が説明されています。
  • Mixer プラグインを使用している場合は、Mixer ポリシーと Telemetry は有効にされる必要があります。

    • アップグレード時に、サービスメッシュコントロールプレーン (SMCP) を適切に設定する必要があります。
注記

3scale Istio アダプターを設定するために、アダプターパラメーターをカスタムリソースファイルに追加する手順については、Red Hat OpenShift Service Mesh カスタムリソースを参照してください。

注記

kind: handler リソースにとくに注意してください。これを 3scale アカウントの認証情報を使用して更新する必要があります。オプションで service_id をハンドラーに追加できますが、この設定は 3scale アカウントの 1 つのサービスに対してのみ有効で、後方互換性を確保するためにだけ維持されています。service_id をハンドラーに追加する場合は、他のサービスに対して 3scale を有効にする必要がある場合は、別の service_ids で追加のハンドラーを作成する必要があります。

以下の手順に従って、3scale アカウントごとに単一のハンドラーを使用します。

手順

  1. 3scale アカウントのハンドラーを作成し、アカウントの認証情報を指定します。サービス識別子を省略します。

      apiVersion: "config.istio.io/v1alpha2"
      kind: handler
      metadata:
       name: threescale
      spec:
       adapter: threescale
       params:
         system_url: "https://<organization>-admin.3scale.net/"
         access_token: "<ACCESS_TOKEN>"
       connection:
         address: "threescale-istio-adapter:3333"

    オプションで、params セクション内の backend_url フィールドを指定して、3scale 設定によって提供される URL を上書きできます。これは、アダプターが 3scale のオンプレミスインスタンスと同じクラスターで実行され、内部クラスター DNS を利用する必要がある場合に役立ちます。

  2. 3scale アカウントに属するサービスの Deployment リソースを編集するか、またはパッチを適用します。

    1. 有効な service_id に対応する値を使用して "service-mesh.3scale.net/service-id" ラベルを追加します。
    2. 手順 1の ハンドラーリソースの名前 の値を使用して "service-mesh.3scale.net/credentials" ラベルを追加します。
  3. 他のサービスを追加する場合には、手順 2 を実行して、3scale アカウントの認証情報とそのサービス識別子にリンクします。
  4. 3scale 設定でルールの設定を変更し、ルールを 3scale ハンドラーにディスパッチします。

    ルール設定の例

      apiVersion: "config.istio.io/v1alpha2"
      kind: rule
      metadata:
        name: threescale
      spec:
        match: destination.labels["service-mesh.3scale.net"] == "true"
        actions:
          - handler: threescale.handler
            instances:
              - threescale-authorization.instance

1.18.1.1. 3scale カスタムリソースの生成

アダプターには、handlerinstance、および rule カスタムリソースの生成を可能にするツールが含まれます。

表1.7 使用法

オプション詳細必須デフォルト値

-h, --help

利用可能なオプションについてのヘルプ出力を生成します

No

 

--name

この URL の一意の名前、トークンのペア

Yes

 

-n, --namespace

テンプレートを生成する namespace

No

istio-system

-t, --token

3scale アクセストークン

Yes

 

-u, --url

3scale 管理ポータル URL

Yes

 

--backend-url

3scale バックエンド URL。これが設定されている場合、システム設定から読み込まれる値がオーバーライドされます。

No

 

-s, --service

3scale API/サービス ID

No

 

--auth

指定する 3scale 認証パターン (1=API Key, 2=App Id/App Key, 3=OIDC)

No

ハイブリッド

-o, --output

生成されたマニフェストを保存するファイル

No

標準出力

--version

CLI バージョンを出力し、即座に終了する

No

 
1.18.1.1.1. URL サンプルからのテンプレートの生成
注記
  • デプロイされたアダプターからのマニフェストの生成 で、3scale アダプターコンテナーイメージからの oc exec を使用して以下のコマンドを実行します。
  • 3scale-config-gen コマンドを使用すると、YAML 構文とインデントエラーを回避するのに役立ちます。
  • このアノテーションを使用する場合は --service を省略できます。
  • このコマンドは、oc exec を使用してコンテナーイメージ内から起動する必要があります。

手順

  • 3scale-config-gen コマンドを使用して、トークンと URL のペアを 1 つのハンドラーとして複数のサービスで共有できるようにテンプレートを自動生成します。

    $ 3scale-config-gen --name=admin-credentials --url="https://<organization>-admin.3scale.net:443" --token="[redacted]"
  • 以下の例では、ハンドラーに埋め込まれたサービス ID を使用してテンプレートを生成します。

    $ 3scale-config-gen --url="https://<organization>-admin.3scale.net" --name="my-unique-id" --service="123456789" --token="[redacted]"

関連情報

1.18.1.2. デプロイされたアダプターからのマニフェストの生成

注記
  • NAME は、3scale で管理するサービスの識別に使用する識別子です。
  • CREDENTIALS_NAME 参照は、ルール設定の match セクションに対応する識別子です。CLI ツールを使用している場合は、NAME 識別子に自動設定されます。
  • この値は具体的なものでなくても構いませんが、ラベル値はルールの内容と一致させる必要があります。詳細は、アダプター経由でのサービストラフィックのルーティング を参照してください。
  1. このコマンドを実行して、istio-system namespace でデプロイされたアダプターからマニフェストを生成します。

    $ export NS="istio-system" URL="https://replaceme-admin.3scale.net:443" NAME="name" TOKEN="token"
    oc exec -n ${NS} $(oc get po -n ${NS} -o jsonpath='{.items[?(@.metadata.labels.app=="3scale-istio-adapter")].metadata.name}') \
    -it -- ./3scale-config-gen \
    --url ${URL} --name ${NAME} --token ${TOKEN} -n ${NS}
  2. これでターミナルにサンプル出力が生成されます。必要に応じて、これらのサンプルを編集し、oc create コマンドを使用してオブジェクトを作成します。
  3. 要求がアダプターに到達すると、アダプターはサービスが 3scale の API にどのようにマッピングされるかを認識している必要があります。この情報は、以下のいずれかの方法で提供できます。

    1. ワークロードにラベルを付ける (推奨)
    2. ハンドラーを service_id としてハードコーディングする
  4. 必要なアノテーションでワークロードを更新します。

    注記

    ハンドラーにまだ組み込まれていない場合は、このサンプルで提供されたサービス ID のみを更新する必要があります。ハンドラーの設定が優先されます

    $ export CREDENTIALS_NAME="replace-me"
    export SERVICE_ID="replace-me"
    export DEPLOYMENT="replace-me"
    patch="$(oc get deployment "${DEPLOYMENT}"
    patch="$(oc get deployment "${DEPLOYMENT}" --template='{"spec":{"template":{"metadata":{"labels":{ {{ range $k,$v := .spec.template.metadata.labels }}"{{ $k }}":"{{ $v }}",{{ end }}"service-mesh.3scale.net/service-id":"'"${SERVICE_ID}"'","service-mesh.3scale.net/credentials":"'"${CREDENTIALS_NAME}"'"}}}}}' )"
    oc patch deployment "${DEPLOYMENT}" --patch ''"${patch}"''

1.18.1.3. アダプター経由でのサービストラフィックのルーティング

以下の手順に従って、3scale アダプターを使用してサービスのトラフィックを処理します。

前提条件

  • 3scale 管理者から受け取る認証情報とサービス ID

手順

  1. kind: rule リソース内で、以前に設定で作成した destination.labels["service-mesh.3scale.net/credentials"] == "threescale" ルールと一致させます。
  2. 上記のラベルを、ターゲットワークロードのデプロイメントで PodTemplateSpec に追加し、サービスを統合します。値 threescale は生成されたハンドラーの名前を参照します。このハンドラーは、3scale を呼び出すのに必要なアクセストークンを保存します。
  3. destination.labels["service-mesh.3scale.net/service-id"] == "replace-me" ラベルをワークロードに追加し、要求時にサービス ID をインスタンス経由でアダプターに渡します。

1.18.2. 3scale での統合設定

以下の手順に従って、3scale の統合設定を行います。

注記

3scale SaaS を使用している場合、Red Hat OpenShift Service Mesh は Early Access プログラムの一部として有効にされています。

手順

  1. [your_API_name]Integration の順に移動します。
  2. Settings をクリックします。
  3. DeploymentIstio オプションを選択します。

    • デフォルトでは AuthenticationAPI Key (user_key) オプションが選択されます。
  4. Update Product をクリックして選択内容を保存します。
  5. Configuration をクリックします。
  6. 設定の更新 をクリックします。

1.18.3. キャッシング動作

3scale System API からの応答は、アダプター内でデフォルトでキャッシュされます。cacheTTLSeconds 値よりも古いと、エントリーはキャッシュから消去されます。また、デフォルトでキャッシュされたエントリーの自動更新は、cacheRefreshSeconds 値に基づいて、期限が切れる前に数秒間試行されます。cacheTTLSeconds 値よりも高い値を設定することで、自動更新を無効にできます。

cacheEntriesMax を正の値以外に設定すると、キャッシングを完全に無効にできます。

更新プロセスを使用すると、到達不能になるホストのキャッシュされた値が、期限が切れて最終的に消去される前に再試行されます。

1.18.4. 認証要求

本リリースでは、以下の認証方法をサポートします。

  • 標準 API キー: 単一のランダム文字列またはハッシュが識別子およびシークレットトークンとして機能します。
  • アプリケーション ID とキーのペア: イミュータブルな識別子とミュータブルなシークレットキー文字列。
  • OpenID 認証方法: JSON Web トークンから解析されるクライアント ID 文字列。

1.18.4.1. 認証パターンの適用

以下の認証方法の例に従って instance カスタムリソースを変更し、認証動作を設定します。認証情報は、以下から受け取ることができます。

  • 要求ヘッダー
  • 要求パラメーター
  • 要求ヘッダーとクエリーパラメーターの両方
注記

ヘッダーの値を指定する場合、この値は小文字である必要があります。たとえば、ヘッダーを User-Key として送信する必要がある場合、これは設定で request.headers["user-key"] として参照される必要があります。

1.18.4.1.1. API キー認証方法

サービスメッシュは、subject カスタムリソースパラメーターの user オプションで指定されたクエリーパラメーターと要求ヘッダーで API キーを検索します。これは、カスタムリソースファイルで指定される順序で値をチェックします。不要なオプションを省略することで、API キーの検索をクエリーパラメーターまたは要求ヘッダーに制限できます。

この例では、サービスメッシュは user_key クエリーパラメーターの API キーを検索します。API キーがクエリーパラメーターにない場合、サービスメッシュは x-user-key ヘッダーを確認します。

API キー認証方法の例

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
  namespace: istio-system
spec:
  template: authorization
  params:
    subject:
      user: request.query_params["user_key"] | request.headers["user-key"] | ""
    action:
      path: request.url_path
      method: request.method | "get"

アダプターが異なるクエリーパラメーターまたは要求ヘッダーを検査するようにする場合は、名前を適宜変更します。たとえば、「key」というクエリーパラメーターの API キーを確認するには、request.query_params["user_key"]request.query_params["key"] に変更します。

1.18.4.1.2. アプリケーション ID およびアプリケーションキーペアの認証方法

サービスメッシュは、subject カスタムリソースパラメーターの properties オプションで指定されるように、クエリーパラメーターと要求ヘッダーでアプリケーション ID とアプリケーションキーを検索します。アプリケーションキーはオプションです。これは、カスタムリソースファイルで指定される順序で値をチェックします。不要なオプションを含めないことで、認証情報の検索をクエリーパラメーターまたは要求ヘッダーのいずれかに制限できます。

この例では、サービスメッシュは最初にクエリーパラメーターのアプリケーション ID とアプリケーションキーを検索し、必要に応じて要求ヘッダーに移動します。

アプリケーション ID およびアプリケーションキーペアの認証方法の例

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
  namespace: istio-system
spec:
  template: authorization
  params:
    subject:
        app_id: request.query_params["app_id"] | request.headers["app-id"] | ""
        app_key: request.query_params["app_key"] | request.headers["app-key"] | ""
    action:
      path: request.url_path
      method: request.method | "get"

アダプターが異なるクエリーパラメーターまたは要求ヘッダーを検査するようにする場合は、名前を適宜変更します。たとえば、identification という名前のクエリーパラメーターのアプリケーション ID を確認するには、request.query_params["app_id"]request.query_params["identification"] に変更します。

1.18.4.1.3. OpenID 認証方法

OpenID Connect (OIDC) 認証方法 を使用するには、subject フィールドで properties 値を使用して client_id および任意で app_key を設定します。

このオブジェクトは、前述の方法を使用して操作することができます。以下の設定例では、クライアント識別子 (アプリケーション ID) は、azp ラベルの JSON Web Token (JWT) から解析されます。これは必要に応じて変更できます。

OpenID 認証方法の例

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
spec:
  template: threescale-authorization
  params:
    subject:
      properties:
        app_key: request.query_params["app_key"] | request.headers["app-key"] | ""
        client_id: request.auth.claims["azp"] | ""
      action:
        path: request.url_path
        method: request.method | "get"
        service: destination.labels["service-mesh.3scale.net/service-id"] | ""

この統合を正常に機能させるには、クライアントがアイデンティティープロバイダー (IdP) で作成されるよう OIDC を 3scale で実行する必要があります。保護するサービスと同じ namespace でサービスの に要求の認証を作成する必要があります。JWT は要求の Authorization ヘッダーに渡されます。

以下に定義されるサンプル RequestAuthentication で、issuerjwksUri、および selector を適宜置き換えます。

OpenID Policy の例

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-example
  namespace: bookinfo
spec:
  selector:
    matchLabels:
      app: productpage
  jwtRules:
  - issuer: >-
      http://keycloak-keycloak.34.242.107.254.nip.io/auth/realms/3scale-keycloak
    jwksUri: >-
      http://keycloak-keycloak.34.242.107.254.nip.io/auth/realms/3scale-keycloak/protocol/openid-connect/certs

1.18.4.1.4. ハイブリッド認証方法

特定の認証方法を適用せず、いずれかの方法の有効な認証情報を受け入れる方法を選択できます。API キーとアプリケーション ID/アプリケーションキーペアの両方が提供される場合、サービスメッシュは API キーを使用します。

この例では、サービスメッシュがクエリーパラメーターの API キーをチェックし、次に要求ヘッダーを確認します。API キーがない場合、クエリーパラメーターのアプリケーション ID とキーをチェックし、次に要求ヘッダーを確認します。

ハイブリッド認証方法の例

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
spec:
  template: authorization
  params:
    subject:
      user: request.query_params["user_key"] | request.headers["user-key"] |
      properties:
        app_id: request.query_params["app_id"] | request.headers["app-id"] | ""
        app_key: request.query_params["app_key"] | request.headers["app-key"] | ""
        client_id: request.auth.claims["azp"] | ""
    action:
      path: request.url_path
      method: request.method | "get"
      service: destination.labels["service-mesh.3scale.net/service-id"] | ""

1.18.5. 3scale アダプターメトリクス

アダプターはデフォルトで、/metrics エンドポイントのポート 8080 で公開されるさまざまな Prometheus メトリクスを報告します。これらのメトリクスから、アダプターと 3scale 間の対話方法についての洞察が提供されます。サービスには、自動的に検出され、Prometheus によって収集されるようにラベルが付けられます。

注記

3scale Istio Adapter メトリクスには、Service Mesh 1.x の以前のリリース以降、互換性のない変更があります。

Prometheus では、以下のメトリクスが Service Mesh 2.0 の時点で使用できるように、バックエンドキャッシュの 1 つの追加と共にメトリクスの名前が変更されています。

表1.8 Prometheus メトリクス

メトリクスタイプ詳細

threescale_latency

ヒストグラム

アダプターと 3scale 間の要求レイテンシーです。

threescale_http_total

カウンター

3scale バックエンドへの要求についての HTTP ステータスの応答コード。

threescale_system_cache_hits

カウンター

設定キャッシュからフェッチされる 3scale システムへの要求の合計数。

threescale_backend_cache_hits

カウンター

バックエンドキャッシュからフェッチされる 3scale バックエンドへの要求の合計数。

1.18.6. 3scale バックエンドキャッシュ

3scale バックエンドキャッシュは、3scale Service Management API のクライアントの認証およびレポートキャッシュを提供します。このキャッシュはアダプターに組み込まれ、管理者がトレードオフを受け入れることが予想される特定の状況での応答の低レイテンシーが可能になります。

注記

3scale バックエンドキャッシュはデフォルトで無効にされます。3scale バックエンドキャッシュ機能では、低レイテンシーとプロセッサーおよびメモリーのリソースの高い使用率と引き換えに、速度制限における不正確な状況が生じたり、フラッシュの最後の実行からのヒットを失う可能性があります。

1.18.6.1. バックエンドキャッシュを有効にする利点

バックエンドキャッシュを有効にする利点には以下が含まれます。

  • 3scale Istio Adapter が管理するサービスへのアクセス時にレイテンシーが高くなる場合にバックエンドキャッシュを有効にします。
  • バックエンドキャッシュを有効にすると、3scale API マネージャーで要求の認証について継続的にチェックされなくなり、これによりレイテンシーが短縮されます。

    • これにより、3scale API マネージャーにアクセスして認証を試行する前に、3scale Istio アダプターが保存し、再利用する 3scale 認証のインメモリーキャッシュが作成されます。これにより、認証の許可または拒否にかかる時間が大幅に少なくなります。
  • バックエンドキャッシュは、3scale Istio アダプターを実行するサービスメッシュとは異なる地理的な場所で 3scale API マネージャーをホストする場合に役立ちます。

    • 通常、これは 3scale のホスト型 (SaaS) プラットフォームに該当しますが、ユーザーが異なるアベイラビリティーゾーンの地理的に異なる場所にある別のクラスターで 3scale API マネージャーをホストする場合や、3scale API Manager に到達するためのネットワークのオーバーヘッドを考慮する必要がある場合にも使用できます。

1.18.6.2. 低レイテンシーを確保するためのトレードオフ

以下は、低レイテンシーを確保するためのトレードオフです。

  • フラッシュが発生するたびに、3scale アダプターの承認状態が更新されます。

    • つまり、アダプターの 2 つ以上のインスタンスで、フラッシュ期間の間隔についての不正確な状態が生じます。
    • 要求が過剰になり、制限を超過し、誤った動作を生じさせ、さらには各要求を処理するアダプターによって処理される要求と処理されない要求とが発生する高い可能性があります。
  • データをフラッシュできず、その認証情報を更新できないアダプターキャッシュは、その情報を API マネージャーに報告せずにシャットダウンまたはクラッシュする可能性があります。
  • アダプターのキャッシュで、API マネージャーと通信する際のネットワーク接続が原因と予想される問題などにより、要求を許可/拒否する必要があるかどうかを判別できない場合に、fail open または fail closed ポリシーが適用されます。
  • キャッシュミスが発生すると、通常はアダプターの起動直後、または接続なしの状態が長く続いた後に、API マネージャーのクエリーを行うためにレイテンシーが増加します。
  • アダプターキャッシュでは、キャッシュを有効にしない場合よりも、認証の計算により多くの作業が必要になります。これにより、より多くのプロセッサーリソースが必要になります。
  • メモリー要件は、キャッシュで管理される制限、アプリケーションおよびサービスの量の組み合わせに比例して増加します。

1.18.6.3. バックエンドキャッシュ設定

以下では、バックエンドキャッシュの設定について説明します。

  • バックエンドキャッシュを設定するための設定内容については、3scale 設定オプションを参照してください。
  • 最後の 3 つの設定では、バックエンドキャッシュの有効化を制御します。

    • PARAM_USE_CACHE_BACKEND: バックエンドキャッシュを有効にするには true に設定します。
    • PARAM_BACKEND_CACHE_FLUSH_INTERVAL_SECONDS: キャッシュデータの API マネージャーへのフラッシュの試行間の時間 (秒単位) を設定します。
    • PARAM_BACKEND_CACHE_POLICY_FAIL_CLOSED: キャッシュされたデータが十分になく、3scale API マネージャーに到達できない場合にサービスへの要求を許可/オープン/または拒否/クローズするかどうかについて設定します。

1.18.7. 3scale Istio Adapter APIcast エミュレーション

3scale Istio アダプターは、以下の条件が満たされる場合に APIcast と同様に動作します。

  • 要求が定義されるマッピングルールと一致しない場合、返される HTTP コードは 404 Not Found になります。これは、以前は 403 Forbidden でした。
  • 要求が制限を超えるために拒否されると、返される HTTP コードは 429 Too Many Requests になります。これは、以前は 403 Forbidden でした。
  • CLI でデフォルトのテンプレートを生成する場合、ヘッダーにはハイフンではなくアンダースコアが使用されます (例: user-key ではなく user_key が使用されます)。

1.18.8. 3scale Istio Adapter の検証

3scale Istio Adapter が予想通りに機能しているかどうかを確認します。アダプターが機能しない場合は、以下の手順に従って問題のトラブルシューティングを行うことができます。

手順

  1. 3scale-adapter Pod がコントロールプレーンの namespace で実行されていることを確認します。

    $ oc get pods -n <istio-system>
  2. そのバージョンなど、3scale-adapter Pod が起動に関する情報を出力したことを確認します。

    $ oc logs <istio-system>
  3. 3scale Adapter の統合で保護されているサービスに対して要求を実行すると、正しい認証情報がかけているという要求を必ず試し、その要求が失敗することを確認します。3scale Adapter ログをチェックして、追加情報を収集します。

1.18.9. 3scale Istio adapter のトラブルシューティングのチェックリスト

管理者が 3scale Istio adapter をインストールすると、統合が適切に機能しなくなる可能性のあるシナリオが複数あります。以下の一覧を使用して、インストールのトラブルシューティングを行います。

  • YAML のインデントが間違っている。
  • YAML セクションがない。
  • YAML の変更をクラスターに適用するのを忘れている。
  • service-mesh.3scale.net/credentials キーでサービスのワークロードにラベルを付けるのを忘れている。
  • service_id が含まれないハンドラーを使用してアカウントごとに再利用できるようにする時に service-mesh.3scale.net/service-id サービスワークロードにラベルを付けるのを忘れている。
  • Rule カスタムリソースが誤ったハンドラーまたはインスタンスカスタムリソースを参照しているか、対応する namespace のサフィックスがかけている参照を指定している。
  • Rule カスタムリソースの match セクションは、設定中のサービスと同じでない可能性があるか、現在実行中でない、または存在しない宛先ワークロードを参照している。
  • ハンドラーの 3scale 管理ポータルのアクセストークンまたは URL が正しくない。
  • クエリーパラメーター、ヘッダー、承認要求などの誤った場所を指定しているか、パラメーター名がテストで使用する要求と一致しないため、インスタンス のカスタムリソースの params/subject/properties セクションで、 app_idapp_key または client_id の正しいパラメーターの表示に失敗する。
  • 設定ジェネレーターがアダプターコンテナーイメージに実際に存在しており、oc exec で呼び出す必要があることに気づかなかったため、設定ジェネレーターの使用に失敗する。

1.19. サービスメッシュのトラブルシューティング

このセクションでは、Red Hat OpenShift Service Mesh で一般的な問題を特定し、解決する方法を説明します。以下のセクションを使用して、OpenShift Container Platform に Red Hat OpenShift Service Mesh をデプロイする際の問題のトラブルシューティングおよびデバッグに役立ちます。

1.19.1. Service Mesh のバージョン管理について

Red Hat OpenShift Service Mesh 2.0 Operator は、v1 および v2 サービスメッシュの両方をサポートします。

  • Operator version - 現在の Operator バージョンは 2.0.8 です。このバージョン番号は、現在インストールされている Operator のバージョンのみを示します。このバージョン番号は、Operator サブスクリプションで指定される Update Channel および Approval Strategy の交差部分で制御されます。Operator のバージョンは、ServiceMeshControlPlane リソースのどのバージョンがデプロイされるかを判別しません。最新の Operator にアップグレードすると、サービスメッシュコントロールプレーンが最新バージョンに自動的にアップグレード されません

    重要

    最新の Operator バージョンにアップグレードしても、コントロールプレーンが最新バージョンに自動的にアップグレードされません。

  • ServiceMeshControlPlane バージョン: 同じ Operator はサービスメッシュコントロールプレーンの複数のバージョンをサポートします。サービスメッシュコントロールプレーンのバージョンは、Red Hat OpenShift Service Mesh のインストールおよびデプロイに使用されるアーキテクチャーおよび設定を制御します。サービスメッシュコントロールプレーンのバージョンを設定または変更するには、新しいコントロールプレーンをデプロイする必要があります。サービスメッシュコントロールプレーンを作成する場合は、以下のいずれかの方法でバージョンを選択できます。

    • Form View で設定するには、Control Plane Version メニューからバージョンを選択します。
    • YAML View で設定するには、YAML ファイルに spec.version の値を設定します。
  • コントロールプレーンの バージョン: SMCP リソースファイルで指定される version パラメーターは spec.version です。サポートされるバージョンは v1.1 および v2.0 です。

Operator Lifecycle Manager (OLM) は v1 から v2 へのアップグレードを管理しないため、SMCP を手動でアップグレードしない限り、Operator および ServiceMeshControlPlane (SMCP) のバージョン番号が一致しない可能性があります。

1.19.2. Operator インストールのトラブルシューティング

このセクションの情報に加えて、次のトピックを確認してください。

1.19.2.1. Operator インストールの検証

Red Hat OpenShift Service Mesh Operator のインストール時に、OpenShift は正常な Operator インストールの一部として以下のオブジェクトを自動的に作成します。

  • 設定マップ
  • カスタムリソース定義
  • デプロイメント
  • pods
  • レプリカセット
  • roles
  • ロールバインディング
  • secrets
  • サービスアカウント
  • services

Openshift コンソールから

OpenShift Container Platform コンソールを使用して Operator Pod が利用可能であり、実行していることを確認できます。

  1. WorkloadsPods に移動します。
  2. openshift-operators namespace を選択します。
  3. 以下の Pod が存在し、ステータスが running であることを確認します。

    • istio-operator
    • jaeger-operator
    • kiali-operator
  4. openshift-operators-redhat namespace を選択します。
  5. elasticsearch-operator Pod が存在し、ステータスが running であることを確認します。

コマンドラインで以下を行います。

  1. 以下のコマンドを使用して、Operator Pod が利用可能で、openshift-operators namespace で実行していることを確認します。

    $ oc get pods -n openshift-operators

    出力例

    NAME                               READY   STATUS    RESTARTS   AGE
    istio-operator-bb49787db-zgr87     1/1     Running   0          15s
    jaeger-operator-7d5c4f57d8-9xphf   1/1     Running   0          2m42s
    kiali-operator-f9c8d84f4-7xh2v     1/1     Running   0          64s

  2. 以下のコマンドを使用して Elasticsearch Operator を確認します。

    $ oc get pods -n openshift-operators-redhat

    出力例

    NAME                                      READY   STATUS    RESTARTS   AGE
    elasticsearch-operator-d4f59b968-796vq     1/1     Running   0          15s

1.19.2.2. サービスメッシュ Operator のトラブルシューティング

Operator に問題が発生した場合は、以下を実行します。

  • Operator サブスクリプションのステータスを確認します。
  • サポートされる Red Hat バージョンではなく、コミュニティーバージョンの Operator をインストールしていないことを確認します。
  • Red Hat OpenShift Service Mesh をインストールするために cluster-admin ロールがあることを確認します。
  • 問題が Operator のインストールに関連する場合は、Operator Pod ログでエラーの有無を確認します。
注記

Operator は OpenShift コンソールからのみインストールでき、OperatorHub はコマンドラインからアクセスできません。

1.19.2.2.1. Operator Pod ログの表示

oc logs コマンドを使用して、Operator ログを表示できます。Red Hat は、サポートケースの解決に役立つログをリクエストする場合があります。

手順

  • Operator Pod ログを表示するには、以下のコマンドを入力します。

    $ oc logs -n openshift-operators <podName>

    以下に例を示します。

    $ oc logs -n openshift-operators istio-operator-bb49787db-zgr87

1.19.3. コントロールプレーンのトラブルシューティング

Service Mesh コントロールプレーン は Istiod で構成されており、以前のいくつかのコントロールプレーンコンポーネント (Citadel、Galley、Pilot) を単一バイナリーに統合します。ServiceMeshControlPlane をデプロイすると、アーキテクチャー で説明されているように、Red Hat OpenShift Service Mesh を構成する他のコンポーネントも作成します。

1.19.3.1. Service Mesh コントロールプレーンのインストールの検証

Service Mesh コントロールプレーンの作成時に、Service Mesh Operator は ServiceMeshControlPlane リソースファイルに指定したパラメーターを使用して以下を実行します。

  • Istio コンポーネントを作成し、以下の Pod をデプロイします。

    • istiod
    • istio-ingressgateway
    • istio-egressgateway
    • grafana
    • prometheus
  • SMCP または Kiali カスタムリソースのいずれかの設定に基づいて Kaili デプロイメントを作成するには、Kiali Operator を呼び出します。

    注記

    Service Mesh Operator ではなく、Kiali Operator で Kiali コンポーネントを表示します。

  • Jaeger Operator を呼び出して、SMCP または Jaeger カスタムリソースのいずれかの設定に基づいて Jaeger コンポーネントを作成します。

    注記

    Jaeger コンポーネントは Jaeger Operator の下に表示され、Elasticsearch コンポーネントは Service Mesh Operator ではなく Elasticsearch Operator の下に表示されます。

    Openshift コンソールから

    OpenShift Web コンソールで Service Mesh コントロールプレーンのインストールを確認できます。

    1. OperatorsInstalled Operators に移動します。
    2. <istio-system> namespace を選択します。
    3. Red Hat OpenShift Service Mesh Operator をクリックします。
    4. Istio Service Mesh Control Plane タブをクリックします。
    5. コントロールプレーンの名前 (basic など) をクリックします。
    6. デプロイメントによって作成されたリソースを表示するには、Resources タブをクリックします。フィルターを使用してビューを絞り込むことができます。たとえば、すべての Pod のステータスが running になっていることを確認できます。
    7. SMCP のステータスが問題を示す場合は、YAML ファイルの status: 出力で詳細を確認してください。

コマンドラインで以下を行います。

  1. 以下のコマンドを実行して、コントロールプレーン Pod が利用可能かどうか確認します。istio-system は SMCP をインストールした namespace になります。

    $ oc get pods -n istio-system

    出力例

    NAME                                    READY   STATUS    RESTARTS   AGE
    grafana-6c47888749-dsztv                2/2     Running   0          37s
    istio-egressgateway-85fdc5b466-dgqgt    1/1     Running   0          36s
    istio-ingressgateway-844f785b79-pxbvb   1/1     Running   0          37s
    istiod-basic-c89b5b4bb-5jh8b            1/1     Running   0          104s
    jaeger-6ff889f874-rz2nm                 2/2     Running   0          34s
    prometheus-578df79589-p7p9k             3/3     Running   0          69s

  2. 以下のコマンドを使用して、コントロールプレーンのデプロイメントのステータスを確認します。ここでは、istio-system は SMCP をデプロイした namespace に置き換えます。

    $ oc get smcp -n <istio-system>

    STATUS 列が ComponentsReady の場合、インストールは正常に終了しています。

    出力例

    NAME    READY   STATUS            PROFILES      VERSION   AGE
    basic   9/9     ComponentsReady   ["default"]   2.0.1.1   19m

    コントロールプレーンを変更および再デプロイする場合、ステータスは UpdateSuccessful が表示されるはずです。

    出力例

    NAME            READY     STATUS             TEMPLATE   VERSION   AGE
    basic-install   9/9       UpdateSuccessful   default               v1.1          3d16h

  3. SMCP のステータスが ComponentsReady 以外の場合は、SCMP リソースの status: 出力で詳細を確認してください。

    $ oc describe smcp <smcp-name> -n <controlplane-namespace>

    出力例

    $ oc describe smcp basic -n istio-system

1.19.3.1.1. Kiali コンソールへのアクセス

インストールプロセスにより、Kiali コンソールにアクセスするためのルートが作成されます。

手順

  1. OpenShift Container Platform コンソールにログインします。
  2. パースペクティブスイッチャーを使用して、Administrator パースペクティブに切り替えます。
  3. HomeProjects をクリックします。
  4. プロジェクトの名前をクリックします。たとえば、bookinfo をクリックします。
  5. Launcher セクションで、Kiali をクリックします。
  6. OpenShift Container Platform コンソールにアクセスするときに使用するものと同じユーザー名とパスワードを使用して Kiali コンソールにログインします。

初回の Kiali コンソールへのログイン時に、表示するパーミッションを持つサービスメッシュ内のすべての namespace を表示する Overview ページが表示されます。

コンソールのインストールを検証する場合は、表示するデータがないことがあります。

1.19.3.1.2. Jaeger コンソールへのアクセス

インストールプロセスにより、Jaeger コンソールにアクセスするためのルートが作成されます。

手順

  1. OpenShift Container Platform コンソールにログインします。
  2. NetworkingRoutes に移動し、Jaeger ルートを検索します。これは Location の下に表示される URL です。
  3. コマンドラインを使用してルートの詳細をクエリーするには、以下のコマンドを入力します。この例では、istio-system はコントロールプレーン namespace です。

    $ export JAEGER_URL=$(oc get route -n istio-system jaeger -o jsonpath='{.spec.host}')
  4. ブラウザーを起動し、https://<JAEGER_URL> に移動します。ここで、<JAEGER_URL> は直前の手順で検出されたルートです。
  5. OpenShift Container Platform コンソールへアクセスするときに使用するものと同じユーザー名とパスワードを使用してログインします。
  6. サービスメッシュにサービスを追加し、トレースを生成している場合は、フィルターと Find Traces ボタンを使用してトレースデータを検索します。

    コンソールインストールを検証すると、表示するトレースデータはありません。

1.19.3.2. Service Mesh コントロールプレーンのトラブルシューティング

Service Mesh コントロールプレーンのデプロイ時に問題が発生した場合は、

  • ServiceMeshControlPlane リソースがサービスおよび Operator とは別のプロジェクトにインストールされていることを確認します。本書では istio-system プロジェクトをサンプルとして使用しますが、Operator およびサービスが含まれるプロジェクトから分離されている限り、コントロールプレーンを任意のプロジェクトにデプロイすることができます。
  • ServiceMeshControlPlane および Jaeger カスタムリソースが同じプロジェクトにデプロイされていることを確認します。たとえば、両方の istio-system プロジェクトを使用します。

1.19.4. データプレーンのトラブルシューティング

データプレーン は、サービスメッシュ内のサービス間の受信および送信ネットワーク通信をすべて傍受し、制御するインテリジェントプロキシーのセットです。

Red Hat OpenShift Service Mesh は、アプリケーションの Pod 内のプロキシーサイドカーに依存して、アプリケーションにサービスメッシュ機能を提供します。

1.19.4.1. サイドカーインジェクションのトラブルシューティング

Red Hat OpenShift Service Mesh は、プロキシーサイドカーコンテナーを Pod に自動的に挿入しません。サイドカーインジェクションをオプトインする必要があります。

1.19.4.1.1. Istio サイドカーインジェクションのトラブルシューティング

アプリケーションのデプロイメントで自動インジェクションが有効になっているかどうかを確認します。Envoy プロキシーの自動インジェクションが有効になっている場合は、spec.template.metadata.annotations の下の Deployment リソースに sidecar.istio.io/inject:"true" アノテーションがなければなりません。

1.19.4.1.2. Jaeger エージェントのサイドカーインジェクションのトラブルシューティング

アプリケーションのデプロイメントで自動インジェクションが有効になっているかどうかを確認します。Jaeger エージェントの自動インジェクションが有効な場合は、Deployment リソースに sidecar.jaegertracing.io/inject:"true" アノテーションが必要です。

サイドカーインジェクションの詳細は、「自動インジェクションの有効化」を参照してください。

1.20. Envoy プロキシーのトラブルシューティング

Envoy プロキシーは、サービスメッシュ内の全サービスの受信トラフィックおよび送信トラフィックをすべてインターセプトします。Envoy はサービスメッシュでテレメトリーを収集し、報告します。Envoy は、同じ Pod の関連するサービスに対してサイドカーコンテナーとしてデプロイされます。

1.20.1. Envoy アクセスログの有効化

Envoy アクセスログは、トラフィックの障害およびフローの診断に役立ち、エンドツーエンドのトラフィックフロー分析に役立ちます。

すべての istio-proxy コンテナーのアクセスロギングを有効にするには、ServiceMeshControlPlane (SMCP) オブジェクトを編集してロギングの出力のファイル名を追加します。

手順

  1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。以下のコマンドを入力します。次に、プロンプトが表示されたら、ユーザー名とパスワードを入力します。

    $ oc login https://{HOSTNAME}:6443
  2. コントロールプレーンをインストールしたプロジェクト (例: istio-system) に切り替えます。

    $ oc project istio-system
  3. ServiceMeshControlPlane ファイルを編集します。

    $ oc edit smcp <smcp_name>
  4. 以下の例で示すように、name を使用してプロキシーログのファイル名を指定します。name の値を指定しないと、ログエントリーは書き込まれません。

    spec:
      proxy:
        accessLogging:
          file:
            name: /dev/stdout     #file name

Pod の問題のトラブルシューティングについての詳細は、「Investigating Pod issues」を参照してください。

1.20.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 バージョンなどの具体的な情報を提供してください。

1.20.2.1. Red Hat ナレッジベースについて

Red Hat ナレッジベース は、お客様が Red Hat の製品やテクノロジーを最大限に活用できるようにするための豊富なコンテンツを提供します。Red Hat ナレッジベースは、Red Hat 製品のインストール、設定、および使用に関する記事、製品ドキュメント、および動画で構成されています。さらに、簡潔な根本的な原因についての説明や修正手順を説明した既知の問題のソリューションを検索できます。

1.20.2.2. Red Hat ナレッジベースの検索

OpenShift Container Platform の問題が発生した場合には、初期検索を実行して、解決策を Red Hat ナレッジベース内ですでに見つけることができるかどうかを確認できます。

前提条件

  • Red Hat カスタマーポータルのアカウントがある。

手順

  1. Red Hat カスタマーポータル にログインします。
  2. 主な Red Hat カスタマーポータルの検索フィールドには、問題に関連する入力キーワードおよび文字列を入力します。これらには、以下が含まれます。

    • OpenShift Container Platform コンポーネント (etcd など)
    • 関連する手順 (installation など)
    • 明示的な失敗に関連する警告、エラーメッセージ、およびその他の出力
  3. Search をクリックします。
  4. OpenShift Container Platform 製品フィルターを選択します。
  5. ナレッジベース のコンテンツタイプフィルターを選択します。

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

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

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

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

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

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

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 で特定のコントロールプレーン 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>

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

1.20.2.5. サポートケースの送信

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • Red Hat カスタマーポータルのアカウントがある。
  • Red Hat の標準またはプレミアムサブスクリプションがある。

手順

  1. Red Hat カスタマーポータル にログインし、SUPPORT CASESOpen a case を選択します。
  2. 問題の該当するカテゴリー (Defect / Bug など)、製品 (OpenShift Container Platform)、および製品バージョン (すでに自動入力されていない場合は 4.7) を選択します。
  3. 報告されている問題に対する一致に基づいて提案される Red Hat ナレッジベースソリューションの一覧を確認してください。提案されている記事が問題に対応していない場合は、Continue をクリックします。
  4. 問題についての簡潔で説明的な概要と、確認されている現象および予想される動作についての詳細情報を入力します。
  5. 報告されている問題に対する一致に基づいて提案される Red Hat ナレッジベースソリューションの更新された一覧を確認してください。ケース作成プロセスでより多くの情報を提供すると、この一覧の絞り込みが行われます。提案されている記事が問題に対応していない場合は、Continue をクリックします。
  6. アカウント情報が予想通りに表示されていることを確認し、そうでない場合は適宜修正します。
  7. 自動入力された OpenShift Container Platform クラスター ID が正しいことを確認します。正しくない場合は、クラスター ID を手動で取得します。

    • OpenShift Container Platform Web コンソールを使用してクラスター ID を手動で取得するには、以下を実行します。

      1. HomeDashboardsOverview に移動します。
      2. Details セクションの Cluster ID フィールドで値を見つけます。
    • または、OpenShift Container Platform Web コンソールで新規サポートケースを作成し、クラスター ID を自動的に入力することができます。

      1. ツールバーから、(?) HelpOpen Support Case に移動します。
      2. Cluster ID 値が自動的に入力されます。
    • OpenShift CLI (oc) を使用してクラスター ID を取得するには、以下のコマンドを実行します。

      $ oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
  8. プロンプトが表示されたら、以下の質問に入力し、Continue をクリックします。

    • 動作はどこで発生しているか?どの環境を使用しているか?
    • 動作はいつ発生するか?頻度は?繰り返し発生するか?特定のタイミングで発生するか?
    • 時間枠およびビジネスへの影響について提供できるどのような情報があるか?
  9. 関連する診断データファイルをアップロードし、Continue をクリックします。まず oc adm must-gather コマンドを使用して収集されるデータと、そのコマンドによって収集されない問題に固有のデータを含めることが推奨されます。
  10. 関連するケース管理の詳細情報を入力し、Continue をクリックします。
  11. ケースの詳細をプレビューし、Submit をクリックします。

1.21. Service Mesh コントロールプレーン設定の参照

デフォルトの ServiceMeshControlPlane (SMCP) リソースを変更するか、または完全にカスタムの SMCP リソースを作成して Red Hat OpenShift Service Mesh をカスタマイズできます。このリファレンスセクションでは、SMCP リソースで利用可能な設定オプションについて説明します。

1.21.1. コントロールプレーンのパラメーター

以下の表は、ServiceMeshControlPlane リソースのトップレベルのパラメーターを一覧表示しています。

表1.9 ServiceMeshControlPlane リソースパラメーター

名前詳細タイプ

apiVersion

APIVersion はオブジェクトのこの表現のバージョンスキーマを定義します。サーバーは認識されたスキーマを最新の内部値に変換し、認識されない値は拒否することがあります。ServiceMeshControlPlane バージョン 2.0 の値は maistra.io/v2 です。

ServiceMeshControlPlane バージョン 2.0 の値は maistra.io/v2 です。

kind

kind はこのオブジェクトが表す REST リソースを表す文字列の値です。

ServiceMeshControlPlane で唯一有効な値は、ServiceMeshControlPlane です。

metadata

この ServiceMeshControlPlane インスタンスについてのメタデータ。コントロールプレーンインストールの名前を指定して作業を追跡できます (basic など)。

文字列

spec

この ServiceMeshControlPlane の必要な状態の仕様です。これには、コントロールプレーンを構成するすべてのコンポーネントの設定オプションが含まれます。

詳細は、表 2 を参照してください。

status

この ServiceMeshControlPlane とコントロールプレーンを構成するコンポーネントの現在のステータスです。

詳細は、表 3 を参照してください。

以下の表は、ServiceMeshControlPlane リソースの仕様を一覧表示しています。これらのパラメーターを変更すると、Red Hat OpenShift Service Mesh コンポーネントが設定されます。

表1.10 ServiceMeshControlPlane リソース仕様

名前詳細設定可能なパラメーター

addons

addons パラメーターを使用して、可視化やメトリクスストレージなどのコアコントロールプレーンコンポーネント以外の追加機能を設定します。

3scalegrafanajaegerkiali、および prometheus

cluster

cluster パラメーターは、クラスターの一般的な設定 (クラスター名、ネットワーク名、マルチクラスター、メッシュ拡張など) の設定を行います。

meshExpansionmultiClustername、および network

gateways

gateways パラメーターを使用して、メッシュの ingress および egress ゲートウェイを設定します。

enabledadditionalEgressadditionalIngressegressingress、および openshiftRoute

general

general パラメーターは、その他の場所には適合しない一般的なコントロールプレーンの設定を表します。

logging および validationMessages

policy

policy パラメーターを使用して、コントロールプレーンのポリシーチェックを設定します。ポリシーチェックを有効にするには、spec.policy.enabledtrue に設定します。

mixer remote、または typetypeIstiodMixer または None に設定できます。

profiles

profiles パラメーターを使用して、デフォルト値に使用するために ServiceMeshControlPlane プロファイルを選択します。

default

proxy

proxy パラメーターを使用してサイドカーのデフォルト動作を設定します。

accessLoggingadminPortconcurrency、および envoyMetricsService

runtime

runtime パラメーターを使用してコントロールプレーンのコンポーネントを設定します。

components、および defaults

security

security パラメーターを使用すると、コントロールプレーンのセキュリティーの各種機能を設定できます。

certificateAuthoritycontrolPlaneidentitydataPlane および trust

techPreview

techPreview パラメーターを使用すると、テクノロジープレビュー機能への早期アクセスが可能になります。

該当なし

telemetry

spec.mixer.telemetry.enabledtrue に設定されている場合、telemetry は有効にされます。

mixerremote、および typetypeIstiodMixer または None に設定できます。

tracing

tracing パラメーターを使用して、メッシュの分散トレースを有効にします。

samplingtypetypeJaeger または None に設定できます。

version

version パラメーターは、インストールするコントロールプレーンの Maistra バージョンを指定します。空のバージョンで ServiceMeshControlPlane を作成する場合、受付 Webhook はバージョンを現行バージョンに設定します。空のバージョンの新規の ServiceMeshControlPlanesv2.0 に設定されます。空のバージョンの既存の ServiceMeshControlPlanes はそれらの設定を保持します。

string

ControlPlaneStatus はサービスメッシュの現在の状態を表します。

表1.11 ServiceMeshControlPlane リソース ControlPlaneStatus

名前詳細タイプ

annotations

annotations パラメーターは、通常は ServiceMeshControlPlane によってデプロイされるコンポーネントの数などの追加の余分なステータス情報を保存します。これらのステータスは、JSONPath 式でオブジェクトのカウントを許可しないコマンドラインツールの oc で使用されます。

設定不可

conditions

オブジェクトの現在の状態として観察される最新の状態を表します。Reconcile は、Operator がデプロイされるコンポーネントの実際の状態の調整を ServiceMeshControlPlane リソースの設定を使用して完了したかどうかを示します。installed は、コントロールプレーンがインストールされているかどうかを示します。Ready は、すべてのコントロールプレーンコンポーネントが準備状態にあるかどうかを示します。

string

components

デプロイされた各コントロールプレーンコンポーネントのステータスを表示します。

string

appliedSpec

すべてのプロファイルが適用された後に生成される設定の仕様です。

ControlPlaneSpec

appliedValues

チャートの生成に使用される生成される values.yaml です。

ControlPlaneSpec

chartVersion

このリソースに対して最後に処理されたチャートのバージョンです。

string

observedGeneration

直近の調整時にコントローラーによって観察される生成です。ステータスの情報は、オブジェクトの特定の生成に関連するものです。status.conditions は、 status.observedGeneration フィールドが metadata.generation に一致しない場合は最新の状態ではありません。

整数

operatorVersion

このリソースを最後に処理した Operator のバージョンです。

string

readiness

コンポーネントおよび所有リソースの準備状態 ( readiness) のステータス

string

この例の ServiceMeshControlPlane の定義には、サポート対象のパラメーターがすべて含まれます。

ServiceMeshControlPlane リソースの例

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  proxy:
    runtime:
      container:
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 128Mi
  tracing:
    type: Jaeger
  gateways:
    ingress: # istio-ingressgateway
      service:
        type: ClusterIP
        ports:
        - name: status-port
          port: 15020
        - name: http2
          port: 80
          targetPort: 8080
        - name: https
          port: 443
          targetPort: 8443
      meshExpansionPorts: []
    egress: # istio-egressgateway
      service:
        type: ClusterIP
        ports:
        - name: status-port
          port: 15020
        - name: http2
          port: 80
          targetPort: 8080
        - name: https
          port: 443
          targetPort: 8443
    additionalIngress:
      some-other-ingress-gateway: {}
    additionalEgress:
      some-other-egress-gateway: {}

  policy:
    type: Mixer
    mixer: # only applies if policy.type: Mixer
      enableChecks: true
      failOpen: false

  telemetry:
    type: Istiod # or Mixer
    mixer: # only applies if telemetry.type: Mixer, for v1 telemetry
      sessionAffinity: false
      batching:
        maxEntries: 100
        maxTime: 1s
      adapters:
        kubernetesenv: true
        stdio:
          enabled: true
          outputAsJSON: true
  addons:
    grafana:
      enabled: true
      install:
        config:
          env: {}
          envSecrets: {}
        persistence:
          enabled: true
          storageClassName: ""
          accessMode: ReadWriteOnce
          capacity:
            requests:
              storage: 5Gi
        service:
          ingress:
            contextPath: /grafana
            tls:
              termination: reencrypt
    kiali:
      name: kiali
      enabled: true
      install: # install kiali CR if not present
        dashboard:
          viewOnly: false
          enableGrafana: true
          enableTracing: true
          enablePrometheus: true
      service:
        ingress:
          contextPath: /kiali
    jaeger:
      name: jaeger
      install:
        storage:
          type: Elasticsearch # or Memory
          memory:
            maxTraces: 100000
          elasticsearch:
            nodeCount: 3
            storage: {}
            redundancyPolicy: SingleRedundancy
            indexCleaner: {}
        ingress: {} # jaeger ingress configuration
  runtime:
    components:
      pilot:
        deployment:
          replicas: 2
        pod:
          affinity: {}
        container:
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 128Mi
      grafana:
        deployment: {}
        pod: {}
      kiali:
        deployment: {}
        pod: {}

1.21.2. 仕様パラメーター

1.21.2.1. 一般的なパラメーター

以下の例は、ServiceMeshControlPlane オブジェクトの spec.general パラメーターと適切な値を持つ利用可能なパラメーターの説明を示しています。

一般的なパラメーターの例

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec
  general:
    logging:
      componentLevels: {}
          # misc: error
      logAsJSON: false
    validationMessages: true

表1.12 Istio の一般的なパラメーター

パラメーター説明デフォルト値
logging:

コントロールプレーンコンポーネントのロギングを設定するのに使用します。

 

該当なし

logging:
 componentLevels:

コンポーネントのロギングレベルを指定するために使用します。

使用できる値は、tracedebuginfowarningerrorfatalpanic です。

該当なし

logging:
 logLevels:

使用できる値は、tracedebuginfowarningerrorfatalpanic です。

 

該当なし

logging:
 logAsJSON:

JSON ロギングを有効または無効にします。

true/false

該当なし

validationMessages:

istio.io リソースの status フィールドへの検証メッセージを有効または無効にするのに使用します。これは、リソースで設定エラーを検出するのに役立ちます。

true/false

該当なし

1.21.2.2. プロファイルパラメーター

ServiceMeshControlPlane オブジェクトプロファイルを使用すると、再利用可能な設定を作成することができます。profile 設定を構成しない場合、Red Hat OpenShift Service Mesh は default プロファイルを使用します。

以下の例は、ServiceMeshControlPlane オブジェクトの spec.profiles パラメーターを示しています。

プロファイルパラメーターの例

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  profiles:
  - YourProfileName

プロファイルの作成に関する詳細は、「コントロールプレーンプロファイルの作成」を参照してください。

セキュリティー設定の詳細な例は、「Mutual Transport Layer Security (mTLS)」を参照してください。

1.21.2.3. techPreview パラメーター

spec.techPreview パラメーターを使用すると、テクノロジープレビュー機能への早期アクセスが可能になります。

重要

テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

1.21.2.4. トレースパラメーター

以下の例は、ServiceMeshControlPlane オブジェクトの spec.tracing パラメーターと適切な値を持つ利用可能なパラメーターの説明を示しています。

トレースパラメーターの例

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  version: v2.0
  tracing:
    sampling: 100
    type: Jaeger

表1.13 Istio トレースパラメーター

パラメーター説明デフォルト値
tracing:
 sampling:

サンプリングレートは、Envoy プロキシーがトレースを生成する頻度を決定します。サンプリングレートを使用して、トレースシステムに報告される要求の割合を制御します。

0 から 10000 までの整数値で、インクリメントは 0.01% (0 から 100%) になります。たとえば、値を 10 に設定するとリクエストの 0.1% がサンプリングされ、値を 100 に設定するとリクエストの 1% がサンプリングされ、値を 500 に設定するとリクエストの 5% がサンプリングされ、10000 に設定するとリクエストの 100% がサンプリングされます。

10000 (トレースの 100%)

tracing:
 type:

現在、サポートされるトレーサーの唯一のタイプは Jaeger です。Jaeger はデフォルトで有効にされます。トレースを無効にするには、type パラメーターを None に設定します。

noneJaeger

Jaeger

1.21.2.5. バージョンパラメーター

version パラメーターは、インストールするコントロールプレーンのバージョンを指定します。空の version パラメーターで ServiceMeshControlPlane オブジェクトを作成する場合、承認 Webhook はバージョンを現行バージョンに設定します。空の version パラメーターを持つ新規の ServiceMeshControlPlanes オブジェクトは v2.0 に設定されます。空の version パラメーターを持つ既存の ServiceMeshControlPlanes オブジェクトは、それらの設定を保持します。

1.21.2.6. 3scale の設定

以下の表では、ServiceMeshControlPlane リソースの 3scale Istio アダプターのパラメーターについて説明しています。

3scale パラメーターの例

spec:
  addons:
    3Scale:
      enabled: false
      PARAM_THREESCALE_LISTEN_ADDR: 3333
      PARAM_THREESCALE_LOG_LEVEL: info
      PARAM_THREESCALE_LOG_JSON: true
      PARAM_THREESCALE_LOG_GRPC: false
      PARAM_THREESCALE_REPORT_METRICS: true
      PARAM_THREESCALE_METRICS_PORT: 8080
      PARAM_THREESCALE_CACHE_TTL_SECONDS: 300
      PARAM_THREESCALE_CACHE_REFRESH_SECONDS: 180
      PARAM_THREESCALE_CACHE_ENTRIES_MAX: 1000
      PARAM_THREESCALE_CACHE_REFRESH_RETRIES: 1
      PARAM_THREESCALE_ALLOW_INSECURE_CONN: false
      PARAM_THREESCALE_CLIENT_TIMEOUT_SECONDS: 10
      PARAM_THREESCALE_GRPC_CONN_MAX_SECONDS: 60
      PARAM_USE_CACHED_BACKEND: false
      PARAM_BACKEND_CACHE_FLUSH_INTERVAL_SECONDS: 15
      PARAM_BACKEND_CACHE_POLICY_FAIL_CLOSED: true

表1.14 3scale パラメーター

パラメーター説明デフォルト値

enabled

3scale アダプターを使用するかどうか

true/false

false

PARAM_THREESCALE_LISTEN_ADDR

gRPC サーバーのリッスンアドレスを設定します。

有効なポート番号

3333

PARAM_THREESCALE_LOG_LEVEL

ログ出力の最小レベルを設定します。

debuginfowarnerror、または none

info

PARAM_THREESCALE_LOG_JSON

ログが JSON としてフォーマットされるかどうかを制御します。

true/false

true

PARAM_THREESCALE_LOG_GRPC

ログに gRPC 情報を含むかどうかを制御します。

true/false

true

PARAM_THREESCALE_REPORT_METRICS

3scale システムおよびバックエンドメトリクスが収集され、Prometheus に報告されるかどうかを制御します。

true/false

true

PARAM_THREESCALE_METRICS_PORT

3scale /metrics エンドポイントをスクラップできるポートを設定します。

有効なポート番号

8080

PARAM_THREESCALE_CACHE_TTL_SECONDS

キャッシュから期限切れのアイテムを消去するまで待機する時間 (秒単位)。

時間 (秒単位)

300

PARAM_THREESCALE_CACHE_REFRESH_SECONDS

キャッシュ要素の更新を試行する場合の期限

時間 (秒単位)

180

PARAM_THREESCALE_CACHE_ENTRIES_MAX

キャッシュにいつでも保存できるアイテムの最大数。キャッシュを無効にするには 0 に設定します。

有効な数字

1000

PARAM_THREESCALE_CACHE_REFRESH_RETRIES

キャッシュ更新ループ時に到達できないホストが再試行される回数

有効な数字

1

PARAM_THREESCALE_ALLOW_INSECURE_CONN

3scale API 呼び出し時の証明書の検証を省略できるようにします。この有効化は推奨されていません。

true/false

false

PARAM_THREESCALE_CLIENT_TIMEOUT_SECONDS

3scale システムおよびバックエンドへの要求を終了するまで待機する秒数を設定します。

時間 (秒単位)

10

PARAM_THREESCALE_GRPC_CONN_MAX_SECONDS

接続を閉じるまでの最大秒数 (+/-10% のジッター) を設定します。

時間 (秒単位)

60

PARAM_USE_CACHE_BACKEND

true の場合、承認要求のインメモリー apisonator キャッシュの作成を試行します。

true/false

false

PARAM_BACKEND_CACHE_FLUSH_INTERVAL_SECONDS

バックエンドキャッシュが有効な場合には、3scale に対してキャッシュをフラッシュする間隔を秒単位で設定します。

時間 (秒単位)

15

PARAM_BACKEND_CACHE_POLICY_FAIL_CLOSED

バックエンドキャッシュが承認データを取得できない場合は常に、要求を拒否する (クローズする) か、許可する (オープンする) かどうか。

true/false

true

1.21.3. ステータスパラメーター

status パラメーターは、サービスメッシュの現在の状態を記述します。この情報は Operator によって生成され、読み取り専用です。

表1.15 Istio ステータスパラメーター

名前詳細タイプ

observedGeneration

直近の調整時にコントローラーによって観察される生成です。ステータスの情報は、オブジェクトの特定の生成に関連するものです。status.conditions は、 status.observedGeneration フィールドが metadata.generation に一致しない場合は最新の状態ではありません。

integer

annotations

annotations パラメーターは、通常は ServiceMeshControlPlane オブジェクトによってデプロイされるコンポーネントの数などの追加の余分なステータス情報を保存します。これらのステータスは、JSONPath 式でオブジェクトのカウントを許可しないコマンドラインツールの oc で使用されます。

設定不可

readiness

コンポーネントおよび所有リソースの readiness ステータスです。

string

operatorVersion

このリソースを最後に処理した Operator のバージョンです。

string

components

デプロイされた各コントロールプレーンコンポーネントのステータスを表示します。

string

appliedSpec

すべてのプロファイルが適用された後に生成される設定の仕様です。

ControlPlaneSpec

conditions

オブジェクトの現在の状態として観察される最新の状態を表します。Reconciled は、Operator がデプロイされるコンポーネントの実際の状態の調整を ServiceMeshControlPlane リソースの設定を使用して完了したかどうかを示します。Installed は、コントロールプレーンがインストールされていることを示します。Ready は、すべてのコントロールプレーンコンポーネントが準備状態にあることを示します。

string

chartVersion

このリソースに対して最後に処理されたチャートのバージョンです。

string

appliedValues

チャートの生成に使用された、生成される values.yaml ファイル。

ControlPlaneSpec

1.21.4. 関連情報

1.22. Jaeger 設定リファレンス

Service Mesh Operator は ServiceMeshControlPlane リソースを作成する際に、分散トレースのリソースも作成します。サービスメッシュは分散トレースに Jaeger を使用します。

1.22.1. トレースの有効化および無効化

ServiceMeshControlPlane リソースでトレースタイプおよびサンプリングレートを指定して、分散トレースを有効にします。

デフォルトのall-in-one Jaeger パラメーター

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  version: v2.0
  tracing:
    sampling: 100
    type: Jaeger

現在、サポートされるトレーサーの唯一のタイプは Jaeger です。

Jaeger はデフォルトで有効にされます。トレースを無効にするには、typeNone に設定します。

サンプリングレートは、Envoy プロキシーがトレースを生成する頻度を決定します。サンプリングレートオプションを使用して、トレースシステムに報告される要求の割合を制御できます。この設定は、メッシュ内のトラフィックおよび収集するトレースデータ量に基づいて設定できます。sampling は 0.01% の増分を表すスケーリングされた整数として設定します。たとえば、値を 10 サンプル (0.1% トレース)、および 500 サンプル (5% トレース)、および 10000 サンプル (100% トレース) に設定します。

注記

SMCP サンプリング設定オプションは Envoy サンプリングレートを制御します。Jaeger トレースサンプリングレートを Jaeger カスタムリソースで設定します。

1.22.2. SMCP での Jaeger 設定の指定

Jaeger は、ServiceMeshControlPlane リソースの addons セクションで設定できます。ただし、SMCP で設定可能な内容にはいくつかの制限があります。

SMCP が設定情報を Jaeger Operator に渡すと、allInOneproduction、または streaming の 3 つのデプロイメントストラテジーのいずれかがトリガーされます。

1.22.3. Jaeger のデプロイ

Jaeger には事前に定義されたデプロイメントストラテジーがあります。Jaeger カスタムリソース (CR) ファイルでデプロイメントストラテジーを指定します。Jaeger インスタンスの作成時に、Operator はこの設定ファイルを使用してデプロイメントに必要なオブジェクトを作成します。

Jaeger Operator は現時点で以下のデプロイメントストラテジーをサポートします。

  • allInOne (デフォルト): このストラテジーは、開発、テスト、およびデモを目的としたものであり、実稼働での使用を目的としたものではありません。主なバックエンドコンポーネントである Agent、Collector、および Query サービスはすべて、インメモリーストレージを使用するように (デフォルトで) 設定された単一の実行可能ファイルにパッケージ化されます。このデプロイメントストラテジーは、SMCP で設定できます。

    注記

    インメモリーストレージには永続性がありません。つまり、Jaeger インスタンスがシャットダウンするか、再起動するか、または置き換えられると、トレースデータが失われます。各 Pod には独自のメモリーがあるため、インメモリーストレージはスケーリングできません。永続ストレージの場合、デフォルトのストレージとして Elasticsearch を使用する production または streaming ストラテジーを使用する必要があります。

  • production: production ストラテジーは、実稼働環境向けのストラテジーであり、トレースデータの長期の保存が重要となり、より拡張性および高可用性のあるアーキテクチャーも必要になります。そのため、バックエンドの各コンポーネントは別々にデプロイされます。エージェントは、インストルメント化されたアプリケーションのサイドカーとして挿入できます。Query および Collector サービスは、サポートされているストレージタイプ (現時点では Elasticsearch) で設定されます。これらの各コンポーネントの複数のインスタンスは、パフォーマンスと回復性を確保するために、必要に応じてプロビジョニングできます。このデプロイメントストラテジーを SMCP に設定できますが、完全にカスタマイズするには、Jaeger CR で設定を指定し、SMCP にリンクする必要があります。
  • streaming: streaming ストラテジーは、Collector と Elasticsearch バックエンドストレージ間に配置されるストリーミング機能を提供することで、production ストラテジーを増強する目的で設計されています。これにより、負荷の高い状況でバックエンドストレージに加わる圧力を軽減し、他のトレース処理後の機能がストリーミングプラットフォーム (AMQ Streams/ Kafka) から直接リアルタイムのスパンデータを利用できるようにします。このデプロイメントストラテジーを SMCP で設定することはできません。Jaeger CR を設定し、SMCP へのリンクを設定する必要があります。
注記

ストリーミングストラテジーには、AMQ Streams 用の追加の Red Hat サブスクリプションが必要です。

1.22.3.1. デフォルト Jaeger デプロイメント

Jaeger 設定オプションを指定しない場合、ServiceMeshControlPlane リソースはデフォルトで allInOne Jaeger デプロイメントストラテジーを使用します。デフォルトの allInOne デプロイメントストラテジーを使用する場合は、spec.addons.jaeger.install.storage.typeMemory に設定します。デフォルトを使用するか、または install で追加設定オプションを許可できます。

コントロールプレーンのデフォルト Jaeger パラメーター (Memory)

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  version: v2.0
  tracing:
    sampling: 10000
    type: Jaeger
  addons:
    jaeger:
      name: jaeger
      install:
        storage:
          type: Memory

1.22.3.2. 実稼働用の Jaeger デプロイメント (最小)

production デプロイメントストラテジーのデフォルト設定を使用するには、spec.addons.jaeger.install.storage.typeElasticsearch に設定し、install で追加設定オプションを指定します。SMCP は Elasticsearch リソースおよびイメージ名の設定のみをサポートすることに注意してください。

コントロールプレーンのデフォルト Jaeger パラメーター (Elasticsearch)

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  version: v2.0
  tracing:
    sampling: 10000
    type: Jaeger
  addons:
    jaeger:
      name: jaeger-production
      install:
        storage:
          type: Elasticsearch
        ingress:
          enabled: true
  runtime:
    components:
      tracing.jaeger.elasticsearch: # only supports resources and image name
        container:
          resources: {}

1.22.3.3. 実稼働環境の Jaeger デプロイメント (完全にカスタマイズ)

SMCP は最小限の Elasticsearch パラメーターのみをサポートします。実稼働環境を完全にカスタマイズし、すべての Elasticsearch 設定パラメーターにアクセスするには、Jaeger カスタムリソース (CR) を使用して Jaeger を設定します。

または、Jaeger インスタンスを作成および設定し、spec.addons.jaeger.name を Jaeger インスタンスの名前 (この例では jaeger-production) に設定できます。

Jaeger production CR がリンクされたコントロールプレーン

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  version: v2.0
  tracing:
    sampling: 1000
    type: Jaeger
  addons:
    jaeger:
      name: jaeger-production-cr #name of Jaeger CR
      install:
        storage:
          type: Elasticsearch
        ingress:
          enabled: true

1.22.3.4. Jaeger デプロイメントのストリーミング

streaming デプロイメントストラテジーを使用するには、まず Jaeger インスタンスを作成および設定してから、spec.addons.jaeger.name を Jaeger インスタンスの名前 (この例では jaeger-streaming) に設定します。

リンクされた Jaeger ストリーミング CR を使用したコントロールプレーン

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  version: v2.0
  tracing:
    sampling: 1000
    type: Jaeger
  addons:
    jaeger:
      name: jaeger-streaming-cr  #name of Jaeger CR

1.22.4. Jaeger カスタムリソースでの Jaeger 設定の指定

ServiceMeshControlPlane (SMCP) リソースではなく Jaeger カスタムリソース (CR) に Jaeger を設定し、Jaeger デプロイメントを完全にカスタマイズすることができます。この設定は SMCP の外部に指定されているため、「外部 Jaeger」と呼ばれることもあります。

注記

SMCP と Jaeger CR を同じ namespace にデプロイする必要があります。たとえば、istio-system となります。

スタンドアロンの Jaeger インスタンスを設定し、デプロイしてから、Jaeger リソースの name を、SMCP リソースの spec.addons.jaeger.name の値として指定できます。name の値に一致する Jaeger CR が存在する場合、コントロールプレーンは既存のインストールを使用します。この方法では、Jaeger 設定を完全にカスタマイズできます。

1.22.4.1. デプロイメントのベストプラクティス

  • Jaeger インスタンス名は一意である必要があります。複数の Jaeger インスタンスがあり、サイドカーが挿入された Jaeger エージェントを使用している場合、Jaeger インスタンスには一意の名前が必要となり、挿入 (injection) のアノテーションはトレースデータを報告する必要のある Jaeger インスタンスの名前を明示的に指定する必要があります。
  • マルチテナントの実装があり、テナントが namespace で分離されている場合、Jaeger インスタンスを各テナント namespace にデプロイします。

    • デーモンセットとしての Jaeger エージェントはマルチテナントインストールまたは OpenShift Dedicated ではサポートされません。サイドカーとしての Jaeger エージェントは、これらのユースケースでサポートされる唯一の設定です。
  • Jaeger を Red Hat OpenShift Service Mesh の一部としてインストールする場合、Jaeger リソースを ServiceMeshControlPlane リソースと同じ namespace にインストールする必要があります。

1.22.4.2. Jaeger のデフォルト設定オプション

Jaeger カスタムリソース (CR) は、Jaeger リソースの作成時に使用されるアーキテクチャーおよび設定を定義します。これらのパラメーターを変更して、Jaeger 実装をビジネスニーズに合わせてカスタマイズできます。

Jaeger 汎用 YAML の例

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: name
spec:
  strategy: <deployment_strategy>
  allInOne:
    options: {}
    resources: {}
  agent:
    options: {}
    resources: {}
  collector:
    options: {}
    resources: {}
  sampling:
    options: {}
  storage:
    type:
    options: {}
  query:
    options: {}
    resources: {}
  ingester:
    options: {}
    resources: {}
  options: {}

表1.16 Jaeger パラメーター

パラメーター説明デフォルト値

apiVersion:

オブジェクトの作成時に使用する Application Program Interface のバージョン。

jaegertracing.io/v1

jaegertracing.io/v1

kind:

作成する Kubernetes オブジェクトの種類を定義します。

jaeger

 

metadata:

name 文字列、UID、およびオプションの namespace などのオブジェクトを一意に特定するのに役立つデータ。

 

OpenShift は UID を自動的に生成し、オブジェクトが作成されるプロジェクトの名前で namespace を完成します。

name:

オブジェクトの名前。

Jaeger インスタンスの名前。

jaeger-all-in-one-inmemory

spec:

作成するオブジェクトの仕様。

Jaeger インスタンスのすべての設定パラメーターが含まれます。(Jaeger コンポーネントすべてに) 共通する定義が必要な場合、これは仕様ノードで定義されます。定義が個別のコンポーネントに関連する場合、これは spec/<component> ノードの下に配置されます。

該当なし

strategy:

Jaeger デプロイメントストラテジー

allInOneproduction、または streaming

allInOne

allInOne:

allInOne イメージはエージェント、Collector、Query、Ingester, Jaeger UI を単一 Pod にデプロイするため、このデプロイメントの設定は、コンポーネント設定を allInOne パラメーターの下でネストする必要があります。

  

agent:

Jaeger エージェントを定義する設定オプション。

  

collector:

Jaeger Collector を定義する設定オプション。

  

sampling:

トレース用のサンプリングストラテジーを定義する設定オプション。

  

storage:

ストレージを定義する設定オプション。すべてのストレージ関連のオプションは、 allInOne または他のコンポーネントオプションではなく、storage に配置される必要があります。

  

query:

Query サービスを定義する設定オプション。

  

ingester:

Ingester サービスを定義する設定オプション。

  

以下の YAML サンプルは、デフォルト設定を使用して Jaeger インスタンスを作成するための最小要件です。

最小要件の jaeger-all-in-one.yaml の例

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger-all-in-one-inmemory

1.22.4.3. Jaeger Collector 設定オプション

Jaeger Collector は、トレーサーによってキャプチャーされたスパンを受信し、production ストラテジーを使用する場合はそれらを永続ストレージ(Elasticsearch) に書き込み、streaming ストラテジーを使用する場合は AMQ Streams に書き込むコンポーネントです。

コレクターはステートレスであるため、Jaeger Collector のインスタンスの多くは並行して実行できます。Elasticsearch クラスターの場所を除き、Collector では設定がほとんど必要ありません。

表1.17 Operator によって使用される Jaeger Collector パラメーターを定義するためのパラメーター

パラメーター説明
collector:
  replicas:

作成する Collector レプリカの数を指定します。

整数 (例: 5)。

表1.18 Collector に渡される Jaeger パラメーター

パラメーター説明
spec:
 collector:
  options: {}

Jaeger Collector を定義する設定オプション。

 
options:
  collector:
    num-workers:

キューからプルするワーカーの数。

整数 (例: 50)。

options:
  collector:
    queue-size:

Collector キューのサイズ。

整数 (例: 2000)。

options:
  kafka:
    producer:
      topic: jaeger-spans

topic パラメーターは、コレクターによってメッセージを生成するために使用され、Ingester によってメッセージを消費するために使用される Kafka 設定を特定します。

プロデューサーのラベル

kafka:
  producer:
    brokers: my-cluster-kafka-brokers.kafka:9092

メッセージを生成するために Collector によって使用される Kafka 設定を特定します。ブローカーが指定されていない場合で、AMQ Streams 1.4.0+ がインストールされている場合、Jaeger は Kafka をセルフプロビジョニングします。

 
log-level:

コレクターのロギングレベル。

tracedebuginfowarningerrorfatalpanic

maxReplicas:

Collector の自動スケーリング時に作成するレプリカの最大数を指定します。

整数 (例: 100)。

num-workers:

キューからプルするワーカーの数。

整数 (例: 50)。

queue-size:

Collector キューのサイズ。

整数 (例: 2000)。

replicas:

作成する Collector レプリカの数を指定します。

整数 (例: 5)。

1.22.4.3.1. 自動スケーリングのための Collector の設定
注記

自動スケーリングは Jaeger 1.20 以降でのみサポートされます。

Collector を自動スケーリングできるように設定できます。Collector は CPU および/またはメモリーの消費に基づいてスケールアップまたはスケールダウンします。Collector を自動スケーリングできるように設定すると、Jaeger 環境は負荷が増加するとスケールアップし、必要なリソースが少なくなるとスケールダウンし、これによってコストを節約できます。自動スケーリングを設定するには、autoscale パラメーターを true に設定し、.spec.collector.maxReplicas の値を、Collector の Pod が消費することが予想されるリソースの妥当な値と共に指定します。.spec.collector.maxReplicas の値を設定しない場合、Operator はこれを 100 に設定します。

デフォルトで、.spec.collector.replicas の値が指定されていない場合、Jaeger Operator は Collector の Horizontal Pod Autoscaler (HPA) 設定を作成します。HPA についての詳細は、Kubernetes ドキュメント を参照してください。

以下は、Collector の制限とレプリカの最大数を設定する自動スケーリングの設定例です。

Collector の自動スケーリングの例

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  collector:
    maxReplicas: 5
    resources:
      limits:
        cpu: 100m
        memory: 128Mi

1.22.4.4. Jaeger サンプリング設定オプション

この Operator は、リモートサンプラーを使用するように設定されているトレーサーに提供されるサンプリングストラテジーを定義するために使用できます。

すべてのトレースが生成される間に、それらの一部のみがサンプリングされます。トレースをサンプリングすると、追加の処理や保存のためにトレースにマークが付けられます。

注記

これは、トレースがサンプリングの意思決定が行われる際に Istio プロキシーによって開始されている場合には関連がありません。Jaeger サンプリングの意思決定は、トレースが Jaeger トレーサーを使用してアプリケーションによって開始される場合にのみ関連します。

サービスがトレースコンテキストが含まれていない要求を受信すると、Jaeger トレーサーは新しいトレースを開始し、これにランダムなトレース ID を割り当て、現在インストールされているサンプリングストラテジーに基づいてサンプリングの意思決定を行います。サンプリングの意思決定はトレース内の後続のすべての要求に伝播され、他のサービスが再度サンプリングの意思決定を行わないようにします。

Jaeger ライブラリーは以下のサンプラーをサポートします。

  • Probabilistic: サンプラーは、sampling.param プロパティーの値と等しいサンプリングの確率で、ランダムなサンプリングの意思決定を行います。たとえば、sampling.param=0.1 の場合に、約 10 の内 1 のトレースがサンプリングされます。
  • Rate Limiting: サンプラーは、リーキーバケット (leaky bucket) レートリミッターを使用して、トレースが一定のレートでサンプリングされるようにします。たとえば、sampling.param=2.0 の場合、1 秒あたり 2 トレースの割合で要求がサンプリングされます。

表1.19 Jaeger サンプリングのオプション

パラメーター説明デフォルト値
spec:
 sampling:
  options: {}
    default_strategy:
    service_strategy:

トレース用のサンプリングストラテジーを定義する設定オプション。

 

設定を指定しない場合、コレクターはすべてのサービスの確率 0.001 (0.1%) のデフォルトの確率的なサンプリングポリシーを返します。

default_strategy:
  type:
service_strategy:
  type:

使用するサンプリングストラテジー。(上記の説明を参照してください。)

有効な値は probabilistic、および ratelimiting です。

probabilistic

default_strategy:
  param:
service_strategy:
  param:

選択したサンプリングストラテジーのパラメーター

10 進値および整数値 (0、.1、1、10)

1

この例では、トレースインスタンスをサンプリングする確率が 50% の確率的なデフォルトサンプリングストラテジーを定義します。

確率的なサンプリングの例

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: with-sampling
spec:
  sampling:
    options:
      default_strategy:
        type: probabilistic
        param: 0.5
      service_strategies:
        - service: alpha
          type: probabilistic
          param: 0.8
          operation_strategies:
            - operation: op1
              type: probabilistic
              param: 0.2
            - operation: op2
              type: probabilistic
              param: 0.4
        - service: beta
          type: ratelimiting
          param: 5

ユーザーによって指定される設定がない場合、Jaeger は以下の設定を使用します。

デフォルトのサンプリング

spec:
  sampling:
    options:
      default_strategy:
        type: probabilistic
        param: 1

1.22.4.5. Jaeger ストレージ設定のオプション

spec.storage の下で Collector、Ingester、および Query サービスのストレージを設定します。これらの各コンポーネントの複数のインスタンスは、パフォーマンスと回復性を確保するために、必要に応じてプロビジョニングできます。

表1.20 Jaeger ストレージを定義するために Operator によって使用される一般的なストレージパラメーター

パラメーター説明デフォルト値
spec:
  storage:
    type:

デプロイメントに使用するストレージのタイプ。

memory または elasticsearchメモリーストレージは、Pod がシャットダウンした場合にデータが永続化されないため、開発、テスト、デモ、および概念検証用の環境にのみに適しています。実稼働環境については、Jaeger は永続ストレージの Elasticsearch をサポートします。

メモリー

storage:
  secretname:

シークレットの名前 (例: jaeger-secret)

 

該当なし

storage:
  options: {}

ストレージを定義する設定オプション。

  

表1.21 Elasticsearch インデックスクリーナーのパラメーター

パラメーター説明デフォルト値
storage:
  esIndexCleaner:
    enabled:

Elasticsearch ストレージを使用する場合、デフォルトでジョブが作成され、古いトレースをインデックスからクリーンアップします。このパラメーターは、インデックスクリーナージョブを有効または無効にします。

true/ false

true

storage:
  esIndexCleaner:
    numberOfDays:

インデックスの削除を待機する日数。

整数値

7

storage:
  esIndexCleaner:
    schedule:

Elasticsearch インデックスを消去する頻度についてのスケジュールを定義します。

cron 式

"55 23 * * *"

1.22.4.5.1. Elasticsearch インスタンスの自動プロビジョニング

storage:typeelasticsearch に設定されているが、spec:storage:options:es:server-urls に値が設定されていない場合、Jaeger Operator は OpenShift Elasticsearch Operator を使用してカスタムリソースファイルの storage セクションで指定される設定に基づいて Elasticsearch クラスターを作成します。

制限

  • namespace ごとにセルフプロビジョニングされた Elasticsearch インスタンスがある Jaeger 1 つだけを使用できます。Elasticsearch クラスターは単一の Jaeger インスタンスの専用のクラスターになります。
  • namespace ごとに 1 つの Elasticsearch のみを使用できます。
注記

Elasticsearch を OpenShift ロギングの一部としてインストールしている場合、Jaeger Operator はインストールされた OpenShift Elasticsearch Operator を使用してストレージをプロビジョニングできます。

以下の設定パラメーターは、セルフプロビジョニングされた Elasticsearch インスタンスについてのものです。これは、OpenShift Elasticsearch Operator を使用して Jaeger Operator によって作成されるインスタンスです。セルフプロビジョニングされた Elasticsearch の設定オプションは、設定ファイルの spec:storage:elasticsearch の下で指定します。

表1.22 Elasticsearch リソース設定パラメーター

パラメーター説明デフォルト値
elasticsearch:
  nodeCount:

Elasticsearch ノードの数。高可用性を確保するには、少なくとも 3 つのノードを使用します。「スプリットブレイン」の問題が生じる可能性があるため、2 つのノードを使用しないでください。

整数値。例: 概念実証用 = 1、最小デプロイメント = 3

3

elasticsearch:
  resources:
    requests:
      cpu:

ご使用の環境設定に基づく、要求に対する中央処理単位の数。

コアまたはミリコアで指定されます (例: 200m、0.5、1)。例: 概念実証用 = 500m、最小デプロイメント = 1

1

elasticsearch:
  resources:
    requests:
      memory:

ご使用の環境設定に基づく、要求に使用できるメモリー。

バイト単位で指定されます (例: 200Ki、50Mi、5Gi)。例: 概念実証用 = 1Gi、最小デプロイメント = 16Gi*

16Gi

elasticsearch:
  resources:
    limits:
      cpu:

ご使用の環境設定に基づく、中央処理単位数の制限。

コアまたはミリコアで指定されます (例: 200m、0.5、1)。例: 概念実証用 = 500m、最小デプロイメント = 1

 
elasticsearch:
  resources:
    limits:
      memory:

ご使用の環境設定に基づく、利用可能なメモリー制限。

バイト単位で指定されます (例: 200Ki、50Mi、5Gi)。例: 概念実証用 = 1Gi、最小デプロイメント = 16Gi*

 
elasticsearch:
  redundancyPolicy:

データレプリケーションポリシーは、Elasticsearch シャードをクラスター内のデータノードにレプリケートする方法を定義します。指定されていない場合、Jaeger Operator はノード数に基づいて最も適切なレプリケーションを自動的に判別します。

ZeroRedundancy(レプリカシャードなし)、SingleRedundancy(レプリカシャード 1 つ)、MultipleRedundancy(各インデックスはデータノードの半分に分散される)、FullRedundancy (各インデックスはクラスター内のすべてのデータノードに完全にレプリケートされます)

 

各 Elasticsearch ノードはこれより低い値のメモリー設定でも動作しますが、これは実稼働環境でのデプロイメントには推奨されません。実稼働環境で使用する場合、デフォルトで各 Pod に割り当てる設定を 16Gi 未満にすることはできず、Pod ごとに最大 64Gi を割り当てることを推奨します。

実稼働ストレージの例

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    elasticsearch:
      nodeCount: 3
      resources:
        requests:
          cpu: 1
          memory: 16Gi
        limits:
          memory: 16Gi

永続ストレージを含むストレージの例:

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    elasticsearch:
      nodeCount: 1
      storage: 1
        storageClassName: gp2
        size: 5Gi
      resources:
        requests:
          cpu: 200m
          memory: 4Gi
        limits:
          memory: 4Gi
      redundancyPolicy: ZeroRedundancy

1
永続ストレージの設定。この場合、AWS gp2 のサイズは 5Gi です。値の指定がない場合、Jaeger は emptyDir を使用します。OpenShift Elasticsearch Operator は、Jaeger インスタンスで削除されない PersistentVolumeClaim および PersistentVolume をプロビジョニングします。同じ名前および namespace で Jaeger インスタンスを作成する場合は、同じボリュームをマウントできます。
1.22.4.5.2. 既存の Elasticsearch インスタンスへの接続

Jaeger でのストレージに、既存の Elasticsearch クラスター (Jaeger Operator で自動プロビジョニングされなかったインスタンス) を使用できます。これは、設定で既存クラスターの URL を spec:storage:options:es:server-urls 値に指定して実行します。

制限

  • Jaeger で Red Hat OpenShift Service Mesh ロギング Elasticsearch インスタンスを共有したり、再利用したりすることはできません。Elasticsearch クラスターは単一の Jaeger インスタンスの専用のクラスターになります。
注記

Red Hat は、外部 Elasticsearch インスタンスのサポートを提供しません。カスタマーポータル でテスト済み統合マトリックスを確認できます。

以下の設定パラメーターは、外部 Elasticsearch インスタンスとして知られる、既存の Elasticsearch インスタンス向けです。この場合、カスタムリソースファイルの spec:storage:options:es で、Elasticsearch の設定オプションを指定します。

表1.23 汎用 ES 設定パラメーター

パラメーター説明デフォルト値
es:
  server-urls:

Elasticsearch インスタンスの URL。

Elasticsearch サーバーの完全修飾ドメイン名。

http://elasticsearch.<namespace>.svc:9200

es:
  max-doc-count:

Elasticsearch クエリーから返す最大ドキュメント数。これは集約にも適用されます。es.max-doc-countes.max-num-spans の両方を設定する場合、Elasticsearch は 2 つの内の小さい方の値を使用します。

 

10000

es:
  max-num-spans:

[非推奨: 今後のリリースで削除されます。代わりに es.max-doc-count を使用してください。] Elasticsearch のクエリーごとに、1 度にフェッチするスパンの最大数。es.max-num-spanses.max-doc-count の両方を設定する場合、Elasticsearch は 2 つの内の小さい方の値を使用します。

 

10000

es:
  max-span-age:

Elasticsearch のスパンについての最大ルックバック。

 

72h0m0s

es:
  sniffer:

Elasticsearch のスニファー設定。クライアントはスニファープロセスを使用してすべてのノードを自動的に検出します。デフォルトでは無効にされています。

true/ false

false

es:
  sniffer-tls-enabled:

Elasticsearch クラスターに対してスニッフィングする際に TLS を有効にするためのオプション。クライアントはスニッフィングプロセスを使用してすべてのノードを自動的に検索します。デフォルトでは無効にされています。

true/ false

false

es:
  timeout:

クエリーに使用されるタイムアウト。ゼロに設定するとタイムアウトはありません。

 

0s

es:
  username:

Elasticsearch で必要なユーザー名。Basic 認証は、指定されている場合に CA も読み込みます。es.password も参照してください。

  
es:
  password:

Elasticsearch で必要なパスワード。es.username も参照してください。

  
es:
  version:

主要な Elasticsearch バージョン。指定されていない場合、値は Elasticsearch から自動検出されます。

 

0

表1.24 ES データレプリケーションパラメーター

パラメーター説明デフォルト値
es:
  num-replicas:

Elasticsearch のインデックスごとのレプリカ数。

 

1

es:
  num-shards:

Elasticsearch のインデックスごとのシャード数。

 

5

表1.25 ES インデックス設定パラメーター

パラメーター説明デフォルト値
es:
  create-index-templates:

true に設定されている場合、アプリケーションの起動時にインデックステンプレートを自動的に作成します。テンプレートが手動でインストールされる場合は、false に設定されます。

true/ false

true

es:
  index-prefix:

Jaeger インデックスのオプションのプレフィックス。たとえば、これを「production」に設定すると、「production-jaeger-*」という名前のインデックスが作成されます。

  

表1.26 ES バルクプロセッサー設定パラメーター

パラメーター説明デフォルト値
es:
  bulk:
    actions:

バルクプロセッサーがディスクへの更新のコミットを決定する前にキューに追加できる要求の数。

 

1000

es:
  bulk:
    flush-interval:

time.Duration: この後に、他のしきい値に関係なく一括要求がコミットされます。バルクプロセッサーのフラッシュ間隔を無効にするには、これをゼロに設定します。

 

200ms

es:
  bulk:
    size:

バルクプロセッサーがディスクへの更新をコミットするまでに一括要求が発生する可能性のあるバイト数。

 

5000000

es:
  bulk:
    workers:

一括要求を受信し、Elasticsearch にコミットできるワーカーの数。

 

1

表1.27 ES TLS 設定パラメーター

パラメーター説明デフォルト値
es:
  tls:
    ca:

リモートサーバーの検証に使用される TLS 認証局 (CA) ファイルへのパス。

 

デフォルトではシステムトラストストアを使用します。

es:
  tls:
    cert:

リモートサーバーに対するこのプロセスの特定に使用される TLS 証明書ファイルへのパス。

  
es:
  tls:
    enabled:

リモートサーバーと通信する際に、トランスポート層セキュリティー (TLS) を有効にします。デフォルトでは無効にされています。

true/ false

false

es:
  tls:
    key:

リモートサーバーに対するこのプロセスの特定に使用される TLS 秘密鍵ファイルへのパス。

  
es:
  tls:
    server-name:

リモートサーバーの証明書の予想される TLS サーバー名を上書きします。

  
es:
  token-file:

ベアラートークンが含まれるファイルへのパス。このフラグは、指定されている場合は認証局 (CA) ファイルも読み込みます。

  

表1.28 ES アーカイブ設定パラメーター

パラメーター説明デフォルト値
es-archive:
  bulk:
    actions:

バルクプロセッサーがディスクへの更新のコミットを決定する前にキューに追加できる要求の数。

 

0

es-archive:
  bulk:
    flush-interval:

time.Duration: この後に、他のしきい値に関係なく一括要求がコミットされます。バルクプロセッサーのフラッシュ間隔を無効にするには、これをゼロに設定します。

 

0s

es-archive:
  bulk:
    size:

バルクプロセッサーがディスクへの更新をコミットするまでに一括要求が発生する可能性のあるバイト数。

 

0

es-archive:
  bulk:
    workers:

一括要求を受信し、Elasticsearch にコミットできるワーカーの数。

 

0

es-archive:
  create-index-templates:

true に設定されている場合、アプリケーションの起動時にインデックステンプレートを自動的に作成します。テンプレートが手動でインストールされる場合は、false に設定されます。

true/ false

false

es-archive:
  enabled:

追加ストレージを有効にします。

true/ false

false

es-archive:
  index-prefix:

Jaeger インデックスのオプションのプレフィックス。たとえば、これを「production」に設定すると、「production-jaeger-*」という名前のインデックスが作成されます。

  
es-archive:
  max-doc-count:

Elasticsearch クエリーから返す最大ドキュメント数。これは集約にも適用されます。

 

0

es-archive:
  max-num-spans:

[非推奨: 今後のリリースで削除されます。代わりに es-archive.max-doc-count を使用してください。] Elasticsearch のクエリーごとに、1 度にフェッチするスパンの最大数。

 

0

es-archive:
  max-span-age:

Elasticsearch のスパンについての最大ルックバック。

 

0s

es-archive:
  num-replicas:

Elasticsearch のインデックスごとのレプリカ数。

 

0

es-archive:
  num-shards:

Elasticsearch のインデックスごとのシャード数。

 

0

es-archive:
  password:

Elasticsearch で必要なパスワード。es.username も参照してください。

  
es-archive:
  server-urls:

Elasticsearch サーバーのコンマ区切りの一覧。完全修飾 URL(例: http://localhost:9200) として指定される必要があります。

  
es-archive:
  sniffer:

Elasticsearch のスニファー設定。クライアントはスニファープロセスを使用してすべてのノードを自動的に検出します。デフォルトでは無効にされています。

true/ false

false

es-archive:
  sniffer-tls-enabled:

Elasticsearch クラスターに対してスニッフィングする際に TLS を有効にするためのオプション。クライアントはスニッフィングプロセスを使用してすべてのノードを自動的に検索します。デフォルトでは無効にされています。

true/ false

false

es-archive:
  timeout:

クエリーに使用されるタイムアウト。ゼロに設定するとタイムアウトはありません。

 

0s

es-archive:
  tls:
    ca:

リモートサーバーの検証に使用される TLS 認証局 (CA) ファイルへのパス。

 

デフォルトではシステムトラストストアを使用します。

es-archive:
  tls:
    cert:

リモートサーバーに対するこのプロセスの特定に使用される TLS 証明書ファイルへのパス。

  
es-archive:
  tls:
    enabled:

リモートサーバーと通信する際に、トランスポート層セキュリティー (TLS) を有効にします。デフォルトでは無効にされています。

true/ false

false

es-archive:
  tls:
    key:

リモートサーバーに対するこのプロセスの特定に使用される TLS 秘密鍵ファイルへのパス。

  
es-archive:
  tls:
    server-name:

リモートサーバーの証明書の予想される TLS サーバー名を上書きします。

  
es-archive:
  token-file:

ベアラートークンが含まれるファイルへのパス。このフラグは、指定されている場合は認証局 (CA) ファイルも読み込みます。

  
es-archive:
  username:

Elasticsearch で必要なユーザー名。Basic 認証は、指定されている場合に CA も読み込みます。es-archive.password も参照してください。

  
es-archive:
  version:

主要な Elasticsearch バージョン。指定されていない場合、値は Elasticsearch から自動検出されます。

 

0

ボリュームマウントを含むストレージの例

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    options:
      es:
        server-urls: https://quickstart-es-http.default.svc:9200
        index-prefix: my-prefix
        tls:
          ca: /es/certificates/ca.crt
    secretName: jaeger-secret
  volumeMounts:
    - name: certificates
      mountPath: /es/certificates/
      readOnly: true
  volumes:
    - name: certificates
      secret:
        secretName: quickstart-es-http-certs-public

以下の例は、ボリュームからマウントされる TLS CA 証明書およびシークレットに保存されるユーザー/パスワードを使用して外部 Elasticsearch クラスターを使用する Jaeger CR を示しています。

外部 Elasticsearch の例:

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    options:
      es:
        server-urls: https://quickstart-es-http.default.svc:9200 1
        index-prefix: my-prefix
        tls: 2
          ca: /es/certificates/ca.crt
    secretName: jaeger-secret 3
  volumeMounts: 4
    - name: certificates
      mountPath: /es/certificates/
      readOnly: true
  volumes:
    - name: certificates
      secret:
        secretName: quickstart-es-http-certs-public

1
デフォルト namespace で実行されている Elasticsearch サービスへの URL。
2
TLS 設定。この場合、CA 証明書のみを使用できますが、相互 TLS を使用する場合に es.tls.key および es.tls.cert を含めることもできます。
3
環境変数 ES_PASSWORD および ES_USERNAME を定義するシークレット。Created by kubectl create secret generic jaeger-secret --from-literal=ES_PASSWORD=changeme --from-literal=ES_USERNAME=elastic
4
すべてのストレージコンポーネントにマウントされるボリュームのマウントとボリューム。

OpenShift Container Platform で Elasticsearch を設定する方法についての詳細は、「ログストアの設定」または「 Jaeger の設定およびデプロイ」を参照してください。

外部 Elasticsearch インスタンスへの接続については、既存の Elasticsearch インスタンスへの接続について参照してください。

1.22.4.6. Jaeger Query 設定オプション

Query とは、ストレージからトレースを取得し、ユーザーインターフェースをホストしてそれらを表示するサービスです。

表1.29 Operator で使用される Jaeger Query を定義するためのパラメーター

パラメーター説明デフォルト値
spec:
  query:
    replicas:

作成する Query レプリカの数を指定します。

整数 (例: 2)

 

表1.30 Query に渡される Jaeger パラメーター

パラメーター説明デフォルト値
spec:
  query:
    options: {}

Query サービスを定義する設定オプション。

  
options:
  log-level:

Query のロギングレベル。

使用できる値は、tracedebuginfowarningerrorfatalpanic です。

 
options:
  query:
    base-path:

すべての jaeger-query HTTP ルートのベースパスは、root 以外の値に設定できます。たとえば、/jaeger ではすべての UI URL が /jaeger で開始するようになります。これは、リバースプロキシーの背後で jaeger-query を実行する場合に役立ちます。

/{path}

 

Query 設定の例

apiVersion: jaegertracing.io/v1
kind: "Jaeger"
metadata:
  name: "my-jaeger"
spec:
  strategy: allInOne
  allInOne:
    options:
      log-level: debug
      query:
        base-path: /jaeger

1.22.4.7. Jaeger Ingester 設定オプション

Ingester は、Kafka トピックから読み取り、別のストレージバックエンド (Elasticsearch) に書き込むサービスです。allInOne または production デプロイメントストラテジーを使用している場合は、Ingester サービスを設定する必要はありません。

表1.31 Ingester に渡される Jaeger パラメーター

パラメーター説明
spec:
  ingester:
    options: {}

Ingester サービスを定義する設定オプション。

 
options:
  deadlockInterval:

Ingester が終了するまでメッセージを待機する間隔 (秒単位または分単位) を指定します。システムの初期化中にメッセージが到達されない場合に Ingester が終了しないようにするため、デッドロック間隔はデフォルトで無効に(0 に設定)されます。

分と秒 (例: 1m0s)デフォルト値は 0 です。

options:
  kafka:
    consumer:
      topic:

topic パラメーターは、コレクターによってメッセージを生成するために使用され、Ingester によってメッセージを消費するために使用される Kafka 設定を特定します。

コンシューマーのラベル例: jaeger-spans

kafka:
  consumer:
    brokers:

メッセージを消費するために Ingester によって使用される Kafka 設定を特定します。

ブローカーのラベル (例: my-cluster-kafka-brokers.kafka:9092)

ingester:
  deadlockInterval:

Ingester が終了するまでメッセージを待機する間隔 (秒単位または分単位) を指定します。システムの初期化中にメッセージが到達されない場合に Ingester が終了しないようにするため、デッドロック間隔はデフォルトで無効に(0 に設定)されます。

分と秒 (例: 1m0s)デフォルト値は 0 です。

log-level:

Ingester のロギングレベル。

使用できる値は、tracedebuginfowarningerrorfatalpanic です。

maxReplicas:

Ingester の自動スケーリング時に作成するレプリカの最大数を指定します。

整数 (例: 100)

ストリーミング Collector および Ingester の例

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-streaming
spec:
  strategy: streaming
  collector:
    options:
      kafka:
        producer:
          topic: jaeger-spans
          brokers: my-cluster-kafka-brokers.kafka:9092
  ingester:
    options:
      kafka:
        consumer:
          topic: jaeger-spans
          brokers: my-cluster-kafka-brokers.kafka:9092
      ingester:
        deadlockInterval: 5
  storage:
    type: elasticsearch
    options:
      es:
        server-urls: http://elasticsearch:9200

1.22.4.7.1. 自動スケーリングのための Ingester の設定
注記

自動スケーリングは Jaeger 1.20 以降でのみサポートされます。

Ingester を自動スケーリングできるように設定できます。Ingester は CPU および/またはメモリーの消費に基づいてスケールアップまたはスケールダウンします。Ingester を自動スケーリングできるように設定すると、Jaeger 環境は負荷が増加するとスケールアップし、必要なリソースが少なくなるとスケールダウンし、これによってコストを節約できます。自動スケーリングを設定するには、autoscale パラメーターを true に設定し、.spec.ingester.maxReplicas の値を、Ingester の Pod が消費することが予想されるリソースの妥当な値と共に指定します。.spec.ingester.maxReplicas の値を設定しない場合、Operator はこれを 100 に設定します。

デフォルトで、.spec.ingester.replicas の値が指定されていない場合、Jaeger Operator は Ingester の Horizontal Pod Autoscaler (HPA) 設定を作成します。HPA についての詳細は、Kubernetes ドキュメント を参照してください。

以下は、Ingester の制限とレプリカの最大数を設定する自動スケーリングの設定例です。

Ingester の自動スケーリングの例

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-streaming
spec:
  strategy: streaming
  ingester:
    maxReplicas: 8
    resources:
      limits:
        cpu: 100m
        memory: 128Mi

1.23. Red Hat OpenShift Service Mesh のアンインストール

Red Hat OpenShift Service Mesh を既存の OpenShift Container Platform インスタンスからアンインストールし、そのリソースを削除するには、コントロールプレーンと Operator を削除してから、コマンドを実行してリソースを手動で削除する必要があります。

1.23.1. Red Hat OpenShift Service Mesh コントロールプレーンの削除

既存の OpenShift Container Platform インスタンスからサービスメッシュをアンインストールするには、まずコントロールプレーンおよび Operator を削除する必要があります。次に、コマンドを実行して必要なリソースを手動で削除する必要があります。

1.23.1.1. Web コンソールを使用したコントロールプレーンの削除

Web コンソールを使用して Red Hat OpenShift Service Mesh コントロールプレーンを削除します。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. Project メニューをクリックし、コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. OperatorsInstalled Operators に移動します。
  4. Provided APIsService Mesh Control Plane をクリックします。
  5. ServiceMeshControlPlane メニュー kebab をクリックします。
  6. Delete Service Mesh Control Plane をクリックします。
  7. 確認ダイアログウィンドウで Delete をクリックし、ServiceMeshControlPlane を削除します。

1.23.1.2. CLI からのコントロールプレーンの削除

CLI を使用して Red Hat OpenShift Service Mesh コントロールプレーンを削除します。この例では、istio-system は、コントロールプレーンプロジェクトです。

手順

  1. OpenShift Container Platform CLI にログインします。
  2. 以下のコマンドを実行して、インストールした ServiceMeshControlPlane の名前を取得します。

    $ oc get smcp -n istio-system
  3. <name_of_custom_resource> を先のコマンドの出力に置き換え、以下のコマンドを実行してカスタムリソースを削除します。

    $ oc delete smcp -n istio-system <name_of_custom_resource>

1.23.2. インストールされた Operator の削除

Red Hat OpenShift Service Mesh を正常に削除するには、Operator を削除する必要があります。Red Hat OpenShift Service Mesh Operator を削除したら、Kiali Operator、Jaeger Operator、および OpenShift Elasticsearch Operator を削除する必要があります。

1.23.2.1. Operator の削除

以下の手順に従って、Red Hat OpenShift Service Mesh を構成する Operator を削除します。以下の Operator ごとに手順を繰り返します。

  • Red Hat OpenShift Service Mesh
  • Kiali
  • Jaeger
  • OpenShift Elasticsearch

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. OperatorInstalled Operators ページから、スクロールするか、またはキーワードを Filter by name に入力して各 Operator を見つけます。次に、Operator 名をクリックします。
  3. Operator Details ページで、Actions メニューから Uninstall Operator を選択します。プロンプトに従って各 Operator をアンインストールします。

1.23.3. Operator リソースのクリーンアップ

OpenShift コンソールを使用して、Red Hat OpenShift Service Mesh Operator を削除した後に残ったリソースを手動で削除します。

前提条件

  • クラスター管理アクセスを持つアカウント。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
  • oc として知られる OpenShift Container Platform コマンドラインインターフェース (CLI) へのアクセス。

手順

  1. クラスター管理者として OpenShift Container Platform CLI にログインします。
  2. 以下のコマンドを実行して、Operator のアンインストール後にリソースをクリーンアップします。サービスメッシュなしで Jaeger をスタンドアロンのサービスとして引き続き使用する場合は、Jaeger リソースを削除しないでください。

    注記

    Openshift Elasticsearch Operator はデフォルトで openshift-operators-redhat にインストールされます。他の Operator はデフォルトで openshift-operators namespace にインストールされます。Operator を別の namespace にインストールしている場合、openshift-operators を Red Hat OpenShift Service Mesh Operator がインストールされていたプロジェクトの名前に置き換えます。

    $ oc delete validatingwebhookconfiguration/openshift-operators.servicemesh-resources.maistra.io
    $ oc delete mutatingwebhookconfigurations/openshift-operators.servicemesh-resources.maistra.io
    $ oc delete svc maistra-admission-controller -n openshift-operators
    $ oc delete -n openshift-operators daemonset/istio-node
    $ oc delete clusterrole/istio-admin clusterrole/istio-cni clusterrolebinding/istio-cni
    $ oc delete clusterrole istio-view istio-edit
    $ oc delete clusterrole jaegers.jaegertracing.io-v1-admin jaegers.jaegertracing.io-v1-crdview jaegers.jaegertracing.io-v1-edit jaegers.jaegertracing.io-v1-view
    $ oc get crds -o name | grep '.*\.istio\.io' | xargs -r -n 1 oc delete
    $ oc get crds -o name | grep '.*\.maistra\.io' | xargs -r -n 1 oc delete
    $ oc get crds -o name | grep '.*\.kiali\.io' | xargs -r -n 1 oc delete
    $ oc delete crds jaegers.jaegertracing.io
    $ oc delete secret -n openshift-operators maistra-operator-serving-cert
    $ oc delete cm -n openshift-operators maistra-operator-cabundle

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

2.1. Service Mesh リリースノート

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

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

2.1.2. Red Hat OpenShift Service Mesh の概要

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

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

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

2.1.3. サポート

本書で説明されている手順、または 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 の両方の診断情報を提供してください。

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

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

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

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

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

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 で特定のコントロールプレーン 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>

2.1.4. 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 クラスターに含まれ、動作している設定のみをサポートしています。クラスター外にあるマイクロサービスの管理や、マルチクラスターシナリオにおけるマイクロサービスの管理はサポートしていません。
  • 本リリースでは、仮想マシンなどの外部サービスを統合していない設定のみをサポートしています。

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.16 に含まれるコンポーネントのバージョン

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

Istio

1.4.8

Jaeger

1.24.0

Kiali

1.12.18

3scale Istio Adapter

1.0.0

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

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

2.1.5.2.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.2.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.3. Red Hat OpenShift Service Mesh 1.1.17 の新機能

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

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

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

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

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

2.1.5.6. 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.6.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.6.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.6.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.6.4. パスを正規化するための SMCP の設定

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

SMCP v1 pathNormalization

spec:
  global:
    pathNormalization: <option>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注記

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

2.1.5.16.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.16.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.17. Red Hat OpenShift Service Mesh 1.1.3 の新機能

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

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

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

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

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

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

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

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

2.1.7.1. サービスメッシュの既知の問題

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 のバージョンに制限があるため、現時点でサービスメッシュと互換性のないアプリケーションが複数あります。詳細は、リンク先のコミュニティーの問題を参照してください。
  • 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. Jaeger の既知の問題

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

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

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

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

  • BZ-1918920 Elasticsearch Pod は更新後に自動的に再起動しません。回避策として、Pod を手動で再起動します。
  • Trace-809 Jaeger Ingester には Kafka 2.3 との互換性がありません。Jaeger Ingester のインスタンスが複数あり、十分なトラフィックがある場合、リバランスメッセージがログに継続的に生成されます。これは、Kafka 2.3.1 で修正された Kafka 2.3 のリグレッションによって生じます。詳細は、Jaegertracing-1819 を参照してください。

2.1.8. 修正された問題

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

2.1.8.1. サービスメッシュの修正された問題

  • MAISTRA-2371 は listerInformer で tombstones を処理します。更新されたキャッシュコードベースは、namespace キャッシュからのイベントを集約されたキャッシュに変換する際に tombstones を処理しないため、go ルーチンでパニックが生じました。
  • 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 サービスメッシュでラインタイムメトリクスが失敗します。サービスメッシュと Prometheus 間には OAuth フィルターがあり、アクセスを付与するにはベアラートークンを Prometheus に渡す必要があります。Kiali は Prometheus サーバーと通信する際にこのトークンを使用するように更新されていますが、アプリケーションメトリクスは現在 403 エラーで失敗しています。
  • KIALI-3070 このバグは、デフォルトのダッシュボードではなく、カスタムダッシュボードにのみ影響します。メトリクス設定でラベルを選択し、ページを更新すると、メニュー上でそれらの選択は保持されますが、その選択はチャート上に表示されません。
  • KIALI-2686 コントロールプレーンに多くの namespace がある場合に、パフォーマンスの問題が発生する可能性があります。

2.1.8.3. Jaeger の修正された問題

  • TRACING-2009 Jaeger Operator が Strimzi Kafka Operator 0.23.0 のサポートを追加するように更新されました。
  • TRACING-1907: アプリケーション namespace に設定マップがないため、Jaeger エージェントサイドカーの挿入が失敗していました。設定マップは正しくない 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

2.2. Red Hat OpenShift Service Mesh について

Red Hat OpenShift Service Mesh は、サービスメッシュにおいてネットワーク化されたマイクロサービス全体の動作に関する洞察と運用管理のためのプラットフォームを提供します。Red Hat OpenShift Service Mesh では、OpenShift Container Platform 環境でマイクロサービスの接続、保護、監視を行うことができます。

2.2.1. サービスメッシュについて

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

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

Red Hat OpenShift Service Mesh により、以下を提供するデプロイされたサービスのネットワークを簡単に作成できます。

  • 検出
  • 負荷分散
  • サービス間の認証
  • 障害回復
  • メトリクス
  • モニタリング

Red Hat OpenShift Service Mesh は、以下を含むより複雑な運用機能も提供します。

  • A/B テスト
  • カナリアリリース
  • レート制限
  • アクセス制御
  • エンドツーエンド認証

2.2.2. Red Hat OpenShift Service Mesh アーキテクチャー

Red Hat OpenShift Service Mesh は、データプレーンとコントロールプレーンに論理的に分割されます。

データプレーン は、サイドカーコンテナーとしてデプロイされたインテリジェントプロキシーのセットです。これらのプロキシーは、サービスメッシュ内のマイクロサービス間の受信および送信ネットワーク通信をすべてインターセプトし、制御します。サイドカープロキシーは、Mixer、汎用ポリシーおよび Telemetry ハブとも通信します。

  • Envoy プロキシー は、サービスメッシュ内の全サービスの受信トラフィックおよび送信トラフィックをすべてインターセプトします。Envoy は、同じ Pod の関連するサービスに対してサイドカーコンテナーとしてデプロイされます。

コントロールプレーン は、プロキシーがトラフィックをルーティングするように管理および設定し、Mixer がポリシーを適用し、Telemetry を収集するように設定します。

  • Mixer は、アクセス制御と使用ポリシー (認可、レート制限、クォータ、認証、および要求トレースなど) を適用し、Envoy プロキシーやその他のサービスから Telemetry データを収集します。
  • Pilot はランタイム時にプロキシーを設定します。Pilot は、Envoy サイドカーコンテナーのサービス検出、インテリジェントルーティング (例: A/B テストまたはカナリアデプロイメント) のトラフィック管理機能、および回復性 (タイムアウト、再試行、サーキットブレーカー) を提供します。
  • Citadel は証明書を発行し、ローテーションします。Citadel は、組み込み型のアイデンティティーおよび認証情報の管理機能を使用して、強力なサービス間認証およびエンドユーザー認証を提供します。Citadel を使用して、サービスメッシュで暗号化されていないトラフィックをアップグレードできます。Operator は、Citadel を使用して、ネットワーク制御ではなく、サービスアイデンティティーに基づいてポリシーを適用することができます。
  • Galley は、サービスメッシュ設定を取り込み、その後設定を検証し、処理し、配布します。Galley は、他のサービスメッシュコンポーネントが OpenShift Container Platform からユーザー設定の詳細を取得できないようにします。

Red Hat OpenShift Service Mesh は、istio-operator を使用してコントロールプレーンのインストールも管理します。Operator は、OpenShift クラスターで共通アクティビティーを実装し、自動化できるソフトウェアの構成要素です。これはコントローラーとして動作し、クラスター内の必要なオブジェクトの状態を設定したり、変更したりできます。

2.2.3. Kiali について

Kiali は、サービスメッシュのマイクロサービスとそれらの接続方法を表示してサービスメッシュを可視化します。

2.2.3.1. Kiali の概要

Kiali では、OpenShift Container Platform で実行されるサービスメッシュの可観測性 (Observability) を提供します。Kiali は、Istio サービスメッシュの定義、検証、および確認に役立ちます。これは、トポロジーの推測によりサービスメッシュの構造を理解しやすくし、またサービスメッシュの健全性に関する情報も提供します。

Kiali は、サーキットブレーカー、要求レート、レイテンシー、トラフィックフローのグラフなどの機能を可視化する、namespace のインタラクティブなグラフビューをリアルタイムで提供します。Kiali では、異なるレベルのコンポーネント (アプリケーションからサービスおよびワークロードまで) についての洞察を提供し、選択されたグラフノードまたはエッジに関するコンテキスト情報やチャートを含む対話を表示できます。Kiali は、ゲートウェイ、宛先ルール、仮想サービス、メッシュポリシーなど、Istio 設定を検証する機能も提供します。Kiali は詳細なメトリクスを提供し、基本的な Grafana 統合は高度なクエリーに利用できます。Jaeger を Kiali コンソールに統合することで、分散トレースを提供します。

Kiali は、デフォルトで Red Hat OpenShift Service Mesh の一部としてインストールされます。

2.2.3.2. Kiali アーキテクチャー

Kiali は Kiali アプリケーションと Kiali コンソールという 2 つのコンポーネントで構成されます。

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

さらに Kiali は、コンテナーアプリケーションプラットフォームと Istio が提供する外部サービスとコンポーネントに依存します。

  • 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 インストールの一部として Jaeger をインストールすると、Kiali コンソールには Jaeger のトレースデータを表示するタブが含まれます。Istio の分散トレース機能を無効にした場合、トレースデータは利用できないことに注意してください。また、Jaeger データを表示するには、コントロールプレーンがインストールされている namespace にユーザーがアクセスできる必要があります。
  • Grafana: Grafana はオプションですが、デフォルトでは Red Hat OpenShift Service Mesh インストールの一部としてインストールされます。使用可能な場合、Kiali のメトリクスページには Grafana 内の同じメトリクスにユーザーを移動させるリンクが表示されます。Grafana ダッシュボードへのリンクと Grafana データを表示するには、コントロールプレーンがインストールされている namespace にユーザーがアクセスできる必要があることに注意してください。

2.2.3.3. Kiali の機能

Kiali コンソールは Red Hat Service Mesh に統合され、以下の機能を提供します。

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

2.2.4. Jaeger について

ユーザーがアプリケーションでアクションを実行するたびに、応答を生成するために多数の異なるサービスに参加を要求する可能性のあるアーキテクチャーによって要求が実行されます。この要求のパスは分散トランザクションです。Jaeger を使用すると、分散トレースを実行できます。これは、アプリケーションを構成するさまざまなマイクロサービスを介して要求のパスを追跡します。

分散トレースは、さまざまな作業ユニットの情報を連携させるために使用される技術です。これは、分散トランザクションでのイベントのチェーン全体を理解するために、通常さまざまなプロセスまたはホストで実行されます。分散トレースを使用すると、開発者は大規模なサービス指向アーキテクチャーで呼び出しフローを可視化できます。シリアル化、並行処理、およびレイテンシーのソースについて理解しておくことも重要です。

Jaeger はマイクロサービスのスタック全体での個々の要求の実行を記録し、トレースとして表示します。トレース とは、システムにおけるデータ/実行パスです。エンドツーエンドトレースは、1 つ以上のスパンで構成されます。

スパン は、オペレーション名、オペレーションの開始時間および期間を持つ、Jaeger の作業の論理単位を表しています。スパンは因果関係をモデル化するためにネスト化され、順序付けられます。

2.2.4.1. Jaeger の概要

サービスの所有者は、Jaeger を使用してサービスをインストルメント化し、サービスアーキテクチャーに関する洞察を得ることができます。Jaeger は、最新のクラウドネイティブ、マイクロサービスベースのアプリケーションにおいてコンポーネント間の対話のモニタリング、ネットワークプロファイリングおよびトラブルシューティングに使用できる、オープンソースの分散トレースプラットフォームです。

Jaeger を使用すると、以下の機能を実行できます。

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

Jaeger は特定のベンダーに依存しない OpenTracing API およびインストルメンテーションに基づいています。

2.2.4.2. Jaeger アーキテクチャー

Jaeger は、複数のコンポーネントで構成されており、トレースデータを収集し、保存し、表示するためにそれらが連携します。

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

2.2.4.3. Jaeger の機能

Jaeger のトレース機能には以下の機能が含まれます。

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

2.2.5. 次のステップ

2.3. サービスメッシュと Istio の相違点

Red Hat OpenShift Service Mesh のインストールは、多くの点でアップストリームの Istio コミュニティーインストールとは異なります。Red Hat OpenShift Service Mesh の変更点は、問題の解決、追加機能の提供、OpenShift Container Platform へのデプロイ時の差異の処理を実行するために必要になることがあります。

Red Hat OpenShift Service Mesh の現行リリースは、以下の点で現在のアップストリーム Istio コミュニティーのリリースとは異なります。

2.3.1. マルチテナントインストール

アップストリームの Istio は単一テナントのアプローチをとりますが、Red Hat OpenShift Service Mesh はクラスター内で複数の独立したコントロールプレーンをサポートします。Red Hat OpenShift Service Mesh はマルチテナント Operator を使用して、コントロールプレーンのライフサイクルを管理します。

Red Hat OpenShift Service Mesh は、デフォルトでマルチテナントコントロールプレーンをインストールします。サービスメッシュにアクセスできるプロジェクトを指定し、サービスメッシュを他のコントロールプレーンインスタンスから分離します。

2.3.1.1. マルチテナンシーとクラスター全体のインストールの比較

マルチテナントインストールとクラスター全体のインストールの主な違いは、コントロールプレーンのデプロイメント (Galley や Pilot など) で使用される権限の範囲です。コンポーネントでは、クラスタースコープのロールベースのアクセス制御 (RBAC) リソース ClusterRoleBinding が使用されなくなりました。

ServiceMeshMemberRoll members 一覧のすべてのプロジェクトには、コントロールプレーンのデプロイメントに関連付けられた各サービスアカウントの RoleBinding があり、各コントロールプレーンのデプロイメントはそれらのメンバープロジェクトのみを監視します。各メンバープロジェクトには maistra.io/member-of ラベルが追加されており、member-of の値はコントロールプレーンのインストールが含まれるプロジェクトになります。

Red Hat OpenShift Service Mesh は各メンバープロジェクトを設定し、それ自体、コントロールプレーン、および他のメンバープロジェクト間のネットワークアクセスを確保できるようにします。詳細な設定は、OpenShift SDN (Software-defined Networking) の設定方法によって異なります。詳細は、「OpenShift SDN について」を参照してください。

OpenShift Container Platform クラスターが SDN プラグインを使用するように設定されている場合:

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

    注記

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

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

2.3.1.2. クラスタースコープのリソース

アップストリーム Istio には、依存するクラスタースコープのリソースが 2 つあります。MeshPolicy および ClusterRbacConfig。これらはマルチテナントクラスターと互換性がなく、以下で説明されているように置き換えられました。

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

2.3.2. Istio と Red Hat OpenShift Service Mesh の相違点

Red Hat OpenShift Service Mesh のインストールは、多くの点で Istio のインストールとは異なります。Red Hat OpenShift Service Mesh への変更は、問題の解決、追加機能の提供、OpenShift へのデプロイ時の差異の処理を実行するために必要になることがあります。

2.3.2.1. コマンドラインツール

Red Hat OpenShift Service Mesh のコマンドラインツールは oc です。  Red Hat OpenShift Service Mesh は、istioctl をサポートしません。

2.3.2.2. 自動的な挿入

アップストリームの Istio コミュニティーインストールは、ラベル付けしたプロジェクト内の Pod にサイドカーコンテナーを自動的に挿入します。

Red Hat OpenShift Service Mesh は、サイドカーコンテナーをあらゆる Pod に自動的に挿入することはなく、プロジェクトにラベルを付けることなくアノテーションを使用して挿入をオプトインする必要があります。この方法で必要となる権限は少なく、ビルダー Pod などの他の OpenShift 機能と競合しません。自動挿入を有効にするには、「サイドカーの自動挿入」セクションで説明されているように sidecar.istio.io/inject アノテーションを指定します。

2.3.2.3. Istio ロールベースアクセス制御機能

Istio ロールベースアクセス制御機能 (RBAC) は、サービスへのアクセスを制御するために使用できるメカニズムを提供します。ユーザー名やプロパティーのセットを指定してサブジェクトを特定し、それに応じてアクセス制御を適用することができます。

アップストリームの Istio コミュニティーインストールには、ヘッダーの完全一致の実行、ヘッダーのワイルドカードの一致の実行、または特定のプレフィックスまたはサフィックスを含むヘッダーの有無をチェックするオプションが含まれます。

Red Hat OpenShift Service Mesh は、正規表現を使用して要求ヘッダーと一致させる機能を拡張します。request.regex.headers のプロパティーキーを正規表現で指定します。

アップストリーム Istio コミュニティーの要求ヘッダーのマッチング例

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: httpbin-client-binding
  namespace: httpbin
spec:
  subjects:
  - user: "cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
    properties:
      request.headers[<header>]: "value"

Red Hat OpenShift Service Mesh の正規表現による要求ヘッダーのマッチング

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: httpbin-client-binding
  namespace: httpbin
spec:
  subjects:
  - user: "cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
    properties:
      request.regex.headers[<header>]: "<regular expression>"

2.3.2.4. OpenSSL

Red Hat OpenShift Service Mesh では、BoringSSL を OpenSSL に置き換えます。OpenSSL は、Secure Sockets Layer (SSL) プロトコルおよび Transport Layer Security (TLS) プロトコルのオープンソース実装を含むソフトウェアライブラリーです。Red Hat OpenShift Service Mesh Proxy バイナリーは、基礎となる Red Hat Enterprise Linux オペレーティングシステムから OpenSSL ライブラリー (libssl および libcrypto) を動的にリンクします。

2.3.2.5. コンポーネントの変更

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

2.3.2.6. Envoy、シークレット検出サービス、および証明書

  • Red Hat OpenShift Service Mesh は、QUIC ベースのサービスをサポートしません。
  • Istio の Secret Discovery Service (SDS) 機能を使用した TLS 証明書のデプロイメントは、現在 Red Hat OpenShift Service Mesh ではサポートされていません。Istio 実装は、hostPath マウントを使用する nodeagent コンテナーに依存します。

2.3.2.7. Istio Container Network Interface (CNI) プラグイン

Red Hat OpenShift Service Mesh には CNI プラグインが含まれ、アプリケーション Pod ネットワーキングを設定する代替の方法が提供されます。CNI プラグインは init-container ネットワーク設定を置き換えます。これにより、昇格した権限でサービスアカウントおよびプロジェクトに SCC (Security Context Constraints) へのアクセスを付与する必要がなくなります。

2.3.2.8. Istio ゲートウェイのルート

Istio ゲートウェイの OpenShift ルートは、Red Hat OpenShift Service Mesh で自動的に管理されます。Istio ゲートウェイがサービスメッシュ内で作成され、更新され、削除されるたびに、OpenShift ルートが作成され、更新され、削除されます。

Istio OpenShift Routing (IOR) と呼ばれる Red Hat OpenShift Service Mesh コントロールプレーンコンポーネントは、ゲートウェイルートを同期させます。詳細は、自動ルートの作成について参照してください。

2.3.2.8.1. catch-all ドメイン

catch-all ドメイン ("*") はサポートされません。ゲートウェイ定義で catch-all ドメインが見つかった場合、Red Hat OpenShift Service Mesh はルートを 作成します が、デフォルトのホスト名を作成するには OpenShift に依存します。つまり、新たに作成されたルートは、catch all ("*") ルート ではなく、代わりに <route-name>[-<project>].<suffix> 形式のホスト名を持ちます。デフォルトのホスト名の仕組みや、クラスター管理者がカスタマイズできる仕組みについての詳細は、OpenShift ドキュメントを参照してください。

2.3.2.8.2. サブドメイン

サブドメイン (e.g.: "*.domain.com") はサポートされます。ただし、この機能は OpenShift ではデフォルトで有効化されていません。つまり、Red Hat OpenShift Service Mesh はサブドメインを持つルートを 作成します が、これは OpenShift が有効にするように設定されている場合にのみ有効になります。

2.3.2.8.3. トランスポート層セキュリティー

トランスポート層セキュリティー (TLS) がサポートされます。ゲートウェイに tls セクションが含まれる場合、OpenShift ルートは TLS をサポートするように設定されます。

関連情報

2.3.3. Kiali とサービスメッシュ

OpenShift Container Platform でのサービスメッシュを使用した Kiali のインストールは、複数の点でコミュニティーの Kiali インストールとは異なります。以下の変更点は、問題の解決、追加機能の提供、OpenShift Container Platform へのデプロイ時の差異の処理を実行するために必要になることがあります。

  • Kiali はデフォルトで有効になっています。
  • Ingress はデフォルトで有効になっています。
  • Kiali ConfigMap が更新されています。
  • Kiali の ClusterRole 設定が更新されています。
  • ConfigMap または Kiali カスタムリソースファイルを編集しないでください。これらの変更はサービスメッシュまたは Kiali Operator によって上書きされる可能性があるためです。Red Hat OpenShift Service Mesh で実行している Kiali の設定はすべて ServiceMeshControlPlane カスタムリソースファイルで行われ、設定オプションは制限されています。Operator ファイルの更新は、cluster-admin 権限を持つユーザーに制限する必要があります。Red Hat OpenShift Dedicated を使用する場合に、dedicated-admin 権限のあるユーザーだけが Operator ファイルを更新できるようにする必要があります。

2.3.4. Jaeger とサービスメッシュ

OpenShift Container Platform でのサービスメッシュを使用した Jaeger インストールは、複数の点でコミュニティーの Jaeger インストールとは異なります。以下の変更点は、問題の解決、追加機能の提供、OpenShift Container Platform へのデプロイ時の差異の処理を実行するために必要になることがあります。

  • Jaeger はサービスメッシュに対してデフォルトで有効にされています。
  • Ingress は、サービスメッシュに対してデフォルトで有効にされています。
  • Zipkin ポート名が、(http から) jaeger-collector-zipkin に変更されています。
  • Jaeger は、production または streaming デプロイメントオプションのいずれかを選択する際に、デフォルトでストレージに Elasticsearch を使用します。
  • Istio のコミュニティーバージョンは、一般的な「トレース」ルートを提供します。Red Hat OpenShift Service Mesh は Jaeger Operator によってインストールされ、OAuth によってすでに保護されている「jaeger」ルートを使用します。
  • Red Hat OpenShift Service Mesh は Envoy プロキシーにサイドカーを使用し、Jaeger も Jaeger エージェントにサイドカーを使用します。両者は個別に設定し、混同しないようにしてください。プロキシーサイドカーは、Pod の Ingress および Egress トラフィックに関連するスパンを作成します。エージェントサイドカーは、アプリケーションによって出力されるスパンを受け取り、これらを Jaeger Collector に送信します。

2.4. Red Hat OpenShift Service Mesh のインストールの準備

Red Hat OpenShift Service Mesh をインストールするには、インストールアクティビティーを確認し、前提条件を満たしていることを確認してください。

2.4.1. 前提条件

2.4.2. 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 クラスターに含まれ、動作している設定のみをサポートしています。クラスター外にあるマイクロサービスの管理や、マルチクラスターシナリオにおけるマイクロサービスの管理はサポートしていません。
  • 本リリースでは、仮想マシンなどの外部サービスを統合していない設定のみをサポートしています。

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

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

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

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

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

    • 3scale Istio Adapter

2.4.3. Operator の概要

Red Hat OpenShift Service Mesh には、以下の 4 つの Operator が必要です。

  • OpenShift Elasticsearch:(オプション) Jaeger でのトレースおよびロギング用にデータベースストレージを提供します。これはオープンソースの Elasticsearch プロジェクトに基づいています。
  • Jaeger: 複雑な分散システムでのトランザクションを監視し、トラブルシューティングするための追跡機能を提供します。これはオープンソースの Jaeger プロジェクトに基づいています。
  • Kiali: サービスメッシュの可観測性を実現します。これにより、単一のコンソールで設定を表示し、トラフィックを監視し、トレースの分析を実行できます。これはオープンソースの Kiali プロジェクトに基づいています。
  • Red Hat OpenShift Service Mesh: アプリケーションを構成するマイクロサービスを接続し、保護し、制御し、観察することができます。Service Mesh Operator は、サービスメッシュコンポーネントのデプロイメント、更新、および削除を管理する ServiceMeshControlPlane リソースを定義し、監視します。これはオープンソースの Istio プロジェクトに基づいています。
警告

実稼働環境で Elasticsearch のデフォルトの Jaeger パラメーターを設定する方法についての詳細は、「ログストアの設定」を参照してください。

2.4.4. 次のステップ

2.5. Red Hat OpenShift Service Mesh のインストール

サービスメッシュのインストールには、OpenShift Elasticsearch、Jaeger、Kiali、Service Mesh Operator のインストール、コントロールプレーンをデプロイするための ServiceMeshControlPlane リソースの作成および管理、サービスメッシュに関連する namespace を指定するための ServiceMeshMemberRoll リソースの作成が含まれます。

注記

Mixer のポリシーの適用はデフォルトで無効にされています。ポリシータスクを実行するには、これを有効にする必要があります。Mixer ポリシーの適用を有効にする方法については、「Mixer ポリシーの適用の更新」を参照してください。

注記

マルチテナントコントロールプレーンのインストールは、Red Hat OpenShift Service Mesh 1.0 以降のデフォルト設定です。

注記

サービスメッシュに関するドキュメントは istio-system をサンプルプロジェクトとして使用しますが、サービスメッシュを任意のプロジェクトにデプロイできます。

2.5.1. 前提条件

サービスメッシュのインストールプロセスでは、OperatorHub を使用して openshift-operators プロジェクト内に ServiceMeshControlPlane カスタムリソース定義をインストールします。Red Hat OpenShift Service Mesh は、コントロールプレーンのデプロイメント、更新、および削除に関連する ServiceMeshControlPlane を定義し、監視します。

Red Hat OpenShift Service Mesh 1.1.16 以降では、Red Hat OpenShift Service Mesh Operator がコントロールプレーンをインストールする前に、OpenShift Elasticsearch Operator、Jaeger Operator、および Kiali Operator をインストールする必要があります。

2.5.2. OpenShift Elasticsearch Operator のインストール

デフォルトの Jaeger デプロイメントはインメモリーストレージを使用します。それは、Jaeger の評価、デモの提供、またはテスト環境での Jaeger の使用を目的としてすぐにインストールできるように設計されているためです。実稼働環境で Jaeger を使用する予定がある場合、永続ストレージのオプション (この場合は Elasticsearch) をインストールし、設定する必要があります。

前提条件

  • OpenShift Container Platform Web コンソールへのアクセスが可能です。
  • cluster-admin ロールを持つアカウントが必要です。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
警告

Operator のコミュニティーバージョンはインストールしないでください。コミュニティー Operator はサポートされていません。

注記

OpenShift Logging の一部として OpenShift Elasticsearch Operator がすでにインストールされている場合、OpenShift Elasticsearch Operator を再びインストールする必要はありません。Jaeger Operator はインストールされた OpenShift Elasticsearch Operator を使用して Elasticsearch インスタンスを作成します。

手順

  1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
  2. OperatorsOperatorHub に移動します。
  3. Elasticsearch とフィルターボックスに入力して、OpenShift Elasticsearch Operator を検索します。
  4. Red Hat が提供する OpenShift Elasticsearch Operator をクリックし、Operator についての情報を表示します。
  5. Install をクリックします。
  6. Install Operator ページの Installation Mode で、 All namespaces on the cluster (default) を選択します。これにより、Operator をクラスター内のすべてのプロジェクトで利用可能にできます。
  7. Installed Namespaces で、メニューから openshift-operators-redhat を選択します。

    注記

    Elasticsearch インストールでは、 Elasticsearch Operator に openshift-operators-redhat namespace が必要です。他の Red Hat OpenShift Service Mesh Operator は openshift-operators namespace にインストールされます。

  8. Update Channel として stable-5.x を選択します。
  9. Automatic Approval Strategy を選択します。

    注記

    手動の承認ストラテジーには、Operator のインストールおよびサブスクリプションプロセスを承認するための適切な認証情報を持つユーザーが必要です。

  10. Install をクリックします。
  11. Installed Operators ページで、openshift-operators-redhat プロジェクトを選択します。OpenShift Elasticsearch Operator が「InstallSucceeded」のステータスを表示するまで待機してから続行します。

2.5.3. Jaeger Operator のインストール

Jaeger をインストールするには、OperatorHub を使用して Jaeger Operator をインストールします。

デフォルトで、Operator は openshift-operators プロジェクトにインストールされます。

前提条件

  • OpenShift Container Platform Web コンソールへのアクセスが可能です。
  • cluster-admin ロールを持つアカウントが必要です。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
  • 永続ストレージが必要な場合、Jaeger Operator をインストールする前に OpenShift Elasticsearch Operator もインストールする必要があります。
警告

Operator のコミュニティーバージョンはインストールしないでください。コミュニティー Operator はサポートされていません。

手順

  1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
  2. OperatorsOperatorHub に移動します。
  3. Jaeger とフィルターに入力して、Jaeger Operator を検索します。
  4. Red Hat が提供する Jaeger Operator をクリックし、Operator についての情報を表示します。
  5. Install をクリックします。
  6. Install Operator ページで、stable 更新チャネルを選択します。これにより、新しいバージョンがリリースされると Jaeger が自動的に更新されます。1.17-stable などのメンテナンスチャネルを選択すると、そのバージョンのサポートサイクルの期間、バグ修正およびセキュリティーパッチが送信されます。
  7. All namespaces on the cluster(default) を選択します。これにより、Operator がデフォルトの openshift-operators プロジェクトにインストールされ、Operator はクラスター内のすべてのプロジェクトで利用可能になります。

    • Approval Strategy を選択します。Automatic または Manual の更新を選択できます。インストールされた Operator について自動更新を選択する場合、Operator の新規バージョンが利用可能になると、Operator Lifecycle Manager (OLM) は人の介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。手動更新を選択する場合、Operator の新規バージョンが利用可能になると、OLM は更新要求を作成します。クラスター管理者は、Operator が新規バージョンに更新されるように更新要求を手動で承認する必要があります。

      注記

      手動の承認ストラテジーには、Operator のインストールおよびサブスクリプションプロセスを承認するための適切な認証情報を持つユーザーが必要です。

  8. Install をクリックします。
  9. Subscription Overview ページで、openshift-operators プロジェクトを選択します。Jaeger Operator に「InstallSucceeded」のステータスが表示されるまで待機してから続行します。

2.5.4. Kiali Operator のインストール

コントロールプレーンをインストールするには、Red Hat OpenShift Service Mesh Operator の Kiali Operator をインストールする必要があります。

警告

Operator のコミュニティーバージョンはインストールしないでください。コミュニティー Operator はサポートされていません。

前提条件

  • OpenShift Container Platform Web コンソールへのアクセスが可能です。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. OperatorsOperatorHub に移動します。
  3. Kiali とフィルターボックスに入力して、Kiali Operator を検索します。
  4. Red Hat が提供する Kiali Operator をクリックし、Operator についての情報を表示します。
  5. Install をクリックします。
  6. Operator Installation ページで、stable 更新チャネルを選択します。
  7. All namespaces on the cluster(default) を選択します。これにより、Operator がデフォルトの openshift-operators プロジェクトにインストールされ、Operator はクラスター内のすべてのプロジェクトで利用可能になります。
  8. Automatic Approval Strategy を選択します。

    注記

    手動の承認ストラテジーには、Operator のインストールおよびサブスクリプションプロセスを承認するための適切な認証情報を持つユーザーが必要です。

  9. Install をクリックします。
  10. Installed Operators ページには、Kiali Operator のインストールの進捗状況が表示されます。

2.5.5. Operator のインストール

Red Hat OpenShift Service Mesh をインストールするには、以下の Operator をこの順序でインストールします。Operator ごとに手順を繰り返します。

  1. (オプション) OpenShift Elasticsearch
  2. Jaeger
  3. Kiali
  4. Red Hat OpenShift Service Mesh

手順

  1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。
  2. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
  3. Operator のフィルターボックスに名前を入力し、Red Hat バージョンの Operator を選択します。Operator のコミュニティーバージョンはサポートされていません。
  4. Install をクリックします。
  5. Install Operator ページで、インストールオプションを選択します。

    1. OpenShift Elasticsearch Operator の場合は、Update Channel セクションで stable-5.x を選択します。
    2. Jaeger、Kiali、および Red Hat OpenShift Service Mesh Operator については、デフォルトを受け入れます。

      Jaeger、Kiali および Red Hat OpenShift Service Mesh Operator は openshift-operators namespace にインストールされます。OpenShift Elasticsearch Operator は openshift-operators-redhat namespace にインストールされます。

  6. Install をクリックします。Operator がインストールされるまで待機してから、一覧で次に来る Operator で手順を繰り返します。
  7. 4 つの Operator すべてをインストールしたら、Operators Installed Operators をクリックし、Operator がインストールされていることを確認します。

2.5.6. Red Hat OpenShift Service Mesh コントロールプレーンのデプロイ

ServiceMeshControlPlane リソースは、インストール時に使用される設定を定義します。Red Hat が提供するデフォルト設定をデプロイするか、またはビジネスのニーズに合わせて ServiceMeshControlPlane ファイルをカスタマイズすることができます。

Web コンソールを使用するか、または oc クライアントツールを使用してコマンドラインからサービスメッシュコントロールプレーンをデプロイすることができます。

2.5.6.1. Web コンソールを使用したコントロールプレーンのデプロイ

以下の手順に従って、Web コンソールを使用して Red Hat OpenShift Service Mesh コントロールプレーンをデプロイします。この例では、istio-system は、コントロールプレーンプロジェクトです。

前提条件

  • Red Hat OpenShift Service Mesh Operator がインストールされている必要があります。
  • Red Hat OpenShift Service Mesh のインストールのカスタマイズ方法についての手順を確認します。
  • cluster-admin ロールを持つアカウントが必要です。

手順

  1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。
  2. istio-system という名前のプロジェクトを作成します。

    1. HomeProjects に移動します。
    2. Create Project をクリックします。
    3. Name フィールドに istio-system を入力します。
    4. Create をクリックします。
  3. OperatorsInstalled Operators に移動します。
  4. 必要な場合は、Project メニューから istio-system を選択します。Operator が新規プロジェクトにコピーされるまでに数分待機する必要がある場合があります。
  5. Red Hat OpenShift Service Mesh Operator をクリックします。Provided APIs の下に、Operator は 2 つのリソースタイプを作成するためのリンクを提供します。

    • ServiceMeshControlPlane リソース
    • ServiceMeshMemberRoll リソース
  6. Istio Service Mesh Control PlaneCreate ServiceMeshControlPlane をクリックします。
  7. Create Service Mesh Control Plane ページで、必要に応じてデフォルト ServiceMeshControlPlane テンプレートの YAML を変更します。

    注記

    コントロールプレーンのカスタマイズについての詳細は、Red Hat OpenShift Service Mesh インストールのカスタマイズについて参照してください。実稼働環境の場合は、デフォルトの Jaeger テンプレートを変更する 必要 があります。

  8. Create をクリックしてコントロールプレーンを作成します。Operator は、設定パラメーターに基づいて Pod、サービス、サービスメッシュコントロールプレーンのコンポーネントを作成します。
  9. Istio Service Mesh Control Plane タブをクリックします。
  10. 新規コントロールプレーンの名前をクリックします。
  11. Resources タブをクリックして、Red Hat OpenShift Service Mesh コントロールプレーンリソース (Operator が作成し、設定したもの) を表示します。

2.5.6.2. CLI からのコントロールプレーンのデプロイ

以下の手順に従って、CLI を使用して Red Hat OpenShift Service Mesh コントロールプレーンをデプロイします。

前提条件

  • Red Hat OpenShift Service Mesh Operator がインストールされている必要があります。
  • Red Hat OpenShift Service Mesh のインストールのカスタマイズ方法についての手順を確認します。
  • cluster-admin ロールを持つアカウントが必要です。
  • OpenShift CLI (oc) へのアクセスが可能です。

手順

  1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。

    $ oc login https://{HOSTNAME}:6443
  2. istio-system という名前のプロジェクトを作成します。

    $ oc new-project istio-system
  3. 「Customize the Red Hat OpenShift Service Mesh installation」にある例を使用して、istio-installation.yaml という名前の ServiceMeshControlPlane ファイルを作成します。必要に応じて値をカスタマイズして、ユースケースに合わせて使用することができます。実稼働デプロイメントの場合は、デフォルトの Jaeger テンプレートを変更する 必要 があります。
  4. 以下のコマンドを実行してコントロールプレーンをデプロイします。

    $ oc create -n istio-system -f istio-installation.yaml
  5. 以下のコマンドを実行して、コントロールプレーンのインストールのステータスを確認します。

    $ oc get smcp -n istio-system

    STATUS 列が InstallSuccessful の場合、インストールは正常に終了しています。

    NAME            READY   STATUS              TEMPLATE   VERSION   AGE
    basic-install   9/9     InstallSuccessful   default    v1.1      4m25s
  6. 以下のコマンドを実行して、インストールプロセス時の Pod の進捗を確認します。

    $ oc get pods -n istio-system -w

    以下のような出力が表示されるはずです。

    出力例

    NAME                                     READY   STATUS             RESTARTS   AGE
    grafana-7bf5764d9d-2b2f6                 2/2     Running            0          28h
    istio-citadel-576b9c5bbd-z84z4           1/1     Running            0          28h
    istio-egressgateway-5476bc4656-r4zdv     1/1     Running            0          28h
    istio-galley-7d57b47bb7-lqdxv            1/1     Running            0          28h
    istio-ingressgateway-dbb8f7f46-ct6n5     1/1     Running            0          28h
    istio-pilot-546bf69578-ccg5x             2/2     Running            0          28h
    istio-policy-77fd498655-7pvjw            2/2     Running            0          28h
    istio-sidecar-injector-df45bd899-ctxdt   1/1     Running            0          28h
    istio-telemetry-66f697d6d5-cj28l         2/2     Running            0          28h
    jaeger-896945cbc-7lqrr                   2/2     Running            0          11h
    kiali-78d9c5b87c-snjzh                   1/1     Running            0          22h
    prometheus-6dff867c97-gr2n5              2/2     Running            0          28h

マルチテナントインストールでは、Red Hat OpenShift Service Mesh はクラスター内で複数の独立したコントロールプレーンをサポートします。ServiceMeshControlPlane テンプレートを使用すると、再利用可能な設定を作成することができます。詳細は、「コントロールプレーンテンプレートの作成」を参照してください。

2.5.7. Red Hat OpenShift Service Mesh メンバーロールの作成

ServiceMeshMemberRoll は、コントロールプレーンに属するプロジェクトを一覧表示します。ServiceMeshMemberRoll に一覧表示されているプロジェクトのみがコントロールプレーンの影響を受けます。プロジェクトは、特定のコントロールプレーンのデプロイメント用にメンバーロールに追加するまでサービスメッシュに属しません。

istio-system など、ServiceMeshControlPlane と同じプロジェクトに、 default という名前の ServiceMeshMemberRoll リソースを作成する必要があります。

2.5.7.1. Web コンソールからのメンバーロールの作成

Web コンソールを使用して 1 つ以上のプロジェクトを Service Mesh メンバーロールに追加します。この例では、istio-system は、コントロールプレーンプロジェクトです。

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. メッシュのサービスがない場合や、ゼロから作業を開始する場合は、アプリケーションのプロジェクトを作成します。これは、コントロールプレーンをインストールしたプロジェクトとは異なる必要があります。

    1. HomeProjects に移動します。
    2. Name フィールドに名前を入力します。
    3. Create をクリックします。
  3. OperatorsInstalled Operators に移動します。
  4. Project メニューをクリックし、一覧から ServiceMeshControlPlane リソースがデプロイされているプロジェクト (例: istio-system) を選択します。
  5. Red Hat OpenShift Service Mesh Operator をクリックします。
  6. Istio Service Mesh Member Roll タブをクリックします。
  7. Create ServiceMeshMemberRoll をクリックします。
  8. Members をクリックし、Value フィールドにプロジェクトの名前を入力します。任意の数のプロジェクトを追加できますが、プロジェクトは 単一ServiceMeshMemberRoll リソースしか属することができません。
  9. Create をクリックします。

2.5.7.2. CLI からのメンバーロールの作成

コマンドラインからプロジェクトを ServiceMeshMemberRoll に追加します。

前提条件

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

手順

  1. OpenShift Container Platform CLI にログインします。

    $ oc login https://{HOSTNAME}:6443
  2. メッシュのサービスがない場合や、ゼロから作業を開始する場合は、アプリケーションのプロジェクトを作成します。これは、コントロールプレーンをインストールしたプロジェクトとは異なる必要があります。

    $ oc new-project {your-project}
  3. プロジェクトをメンバーとして追加するには、以下の YAML の例を変更します。任意の数のプロジェクトを追加できますが、プロジェクトは 単一ServiceMeshMemberRoll リソースしか属することができません。この例では、istio-system は、コントロールプレーンプロジェクトです。

    servicemeshmemberroll-default.yaml の例

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system
    spec:
      members:
        # a list of projects joined into the service mesh
        - your-project-name
        - another-project-name

  4. 以下のコマンドを実行して、istio-system namespace に ServiceMeshMemberRoll リソースをアップロードおよび作成します。

    $ oc create -n istio-system -f servicemeshmemberroll-default.yaml
  5. 以下のコマンドを実行して、ServiceMeshMemberRoll が正常に作成されていることを確認します。

    $ oc get smmr -n istio-system default

    STATUS 列が Configured の場合には、インストールは正常に終了しています。

2.5.8. サービスメッシュからのプロジェクトの追加または削除

Web コンソールを使用して既存の Service Mesh ServiceMeshMemberRoll リソースを追加または削除できます。

  • 任意の数のプロジェクトを追加できますが、プロジェクトは 単一ServiceMeshMemberRoll リソースしか属することができません。
  • ServiceMeshMemberRoll リソースは、対応する ServiceMeshControlPlane リソースが削除されると削除されます。

2.5.8.1. Web コンソールを使用したメンバーロールからのプロジェクトの追加または削除

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. OperatorsInstalled Operators に移動します。
  3. Project メニューをクリックし、一覧から ServiceMeshControlPlane リソースがデプロイされているプロジェクト (例: istio-system) を選択します。
  4. Red Hat OpenShift Service Mesh Operator をクリックします。
  5. Istio Service Mesh Member Roll タブをクリックします。
  6. default リンクをクリックします。
  7. YAML タブをクリックします。
  8. YAML を変更して、プロジェクトをメンバーとして追加または削除します。任意の数のプロジェクトを追加できますが、プロジェクトは 単一ServiceMeshMemberRoll リソースしか属することができません。
  9. Save をクリックします。
  10. Reload をクリックします。

2.5.8.2. CLI を使用したメンバーロールからのプロジェクトの追加または削除

コマンドラインを使用して既存の Service Mesh Member Roll を変更できます。

前提条件

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

手順

  1. OpenShift Container Platform CLI にログインします。
  2. ServiceMeshMemberRoll リソースを編集します。

    $ oc edit smmr -n <controlplane-namespace>
  3. YAML を変更して、プロジェクトをメンバーとして追加または削除します。任意の数のプロジェクトを追加できますが、プロジェクトは 単一ServiceMeshMemberRoll リソースしか属することができません。

    servicemeshmemberroll-default.yaml の例

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system #control plane project
    spec:
      members:
        # a list of projects joined into the service mesh
        - your-project-name
        - another-project-name

2.5.9. 手動更新

手動で更新することを選択する場合、Operator Lifecycle Manager (OLM) は、クラスター内の Operator のインストール、アップグレード、ロールベースのアクセス制御 (RBAC) を制御します。OLM はデフォルトで OpenShift Container Platform で実行されます。OLM は CatalogSource を使用します。これは Operator Registry API を使用して利用可能な Operator やインストールされた Operator のアップグレードについてクエリーします。

  • OpenShift Container Platform のアップグレードの処理方法についての詳細は、Operator Lifecycle Manager のドキュメントを参照してください。

2.5.9.1. アプリケーション Pod の更新

Operator をインストールする際に Automatic Approval Strategy を選択した場合には、Operator はコントロールプレーンを自動的に更新しますが、アプリケーションを更新しません。既存のアプリケーションは、引き続きメッシュの一部になり、それに応じて機能します。アプリケーション管理者は、サイドカーコンテナーをアップグレードするためにアプリケーションを再起動する必要があります。

デプロイメントで自動のサイドカーコンテナー挿入を使用する場合、アノテーションを追加または変更してデプロイメントの Pod テンプレートを更新することができます。以下のコマンドを実行して Pod を再デプロイします。

$ oc patch deployment/<deployment> -p '{"spec":{"template":{"metadata":{"annotations":{"kubectl.kubernetes.io/restartedAt": "'`date -Iseconds`'"}}}}}'

デプロイメントで自動のサイドカーコンテナー挿入を使用しない場合、デプロイメントまたは Pod で指定されたサイドカーコンテナーイメージを変更してサイドカーコンテナーを手動で更新する必要があります。

2.5.10. 次のステップ

2.6. サービスメッシュのセキュリティーのカスタマイズ

サービスメッシュアプリケーションが複雑な配列のマイクロサービスで構築されている場合、Red Hat OpenShift Service Mesh を使用してそれらのサービス間の通信のセキュリティーをカスタマイズできます。サービスメッシュのトラフィック管理機能と共に OpenShift Container Platform のインフラストラクチャーを使用すると、アプリケーションの複雑性を管理し、マイクロサービスのサービスおよびアイデンティティーのセキュリティーを提供することができます。

2.6.1. 相互トランスポート層セキュリティー (mTLS) の有効化

相互トランスポート層セキュリティー (mTLS) は、二者が相互の認証を行うプロトコルです。これは、一部のプロトコル(IKE、SSH)での認証のデフォルトモードであり、他のプロトコル (TLS) ではオプションになります。

mTLS は、アプリケーションやサービスコードを変更せずに使用できます。TLS は、サービスメッシュインフラストラクチャーおよび 2 つのサイドカープロキシー間で完全に処理されます。

デフォルトで、Red Hat OpenShift Service Mesh は Permissive モードに設定されます。この場合、サービスメッシュのサイドカーは、プレーンテキストのトラフィックと mTLS を使用して暗号化される接続の両方を受け入れます。メッシュのサービスがメッシュ外のサービスと通信している場合、厳密な mTLS によりサービス間の通信に障害が発生する可能性があります。ワークロードをサービスメッシュに移行する間に Permissive モードを使用します。

2.6.1.1. メッシュ全体での厳密な mTLS の有効化

ワークロードがメッシュ外のサービスと通信せず、暗号化された接続のみを受け入れることで通信が中断されない場合は、メッシュ全体で mTLS をすぐに有効にできます。ServiceMeshControlPlane リソースで spec.istio.global.mtls.enabledtrue に設定します。Operator は必要なリソースを作成します。

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      mtls:
        enabled: true
2.6.1.1.1. 特定のサービスの受信接続用のサイドカーの設定

ポリシーを作成して、個別のサービスまたは namespace に mTLS を設定することもできます。

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: default
  namespace: <NAMESPACE>
spec:
  peers:
    - mtls: {}

2.6.1.2. 送信接続用のサイドカーの設定

宛先ルールを作成し、サービスメッシュがメッシュ内の他のサービスに要求を送信する際に mTLS を使用するように設定します。

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "default"
  namespace: <CONTROL_PLANE_NAMESPACE>>
spec:
  host: "*.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

2.6.1.3. 最小および最大のプロトコルバージョンの設定

ご使用の環境のサービスメッシュに暗号化されたトラフィックの特定の要件がある場合、許可される暗号化機能を制御できます。これは、ServiceMeshControlPlane リソースに spec.security.controlPlane.tls.minProtocolVersion または spec.security.controlPlane.tls.maxProtocolVersion を設定して許可できます。コントロールプレーンリソースで設定されるこれらの値は、TLS 経由でセキュアに通信する場合にメッシュコンポーネントによって使用される最小および最大の TLS バージョンを定義します。

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic-install
  namespace: istio-system
spec:
  security:
    controlPlane:
      tls:
        minProtocolVersion: TLSv1_2
        maxProtocolVersion: TLSv1_3

デフォルトは TLS_AUTO であり、TLS のバージョンは指定しません。

表2.3 有効な値

詳細

TLS_AUTO

default

TLSv1_0

TLS バージョン 1.0

TLSv1_1

TLS バージョン 1.1

TLSv1_2

TLS バージョン 1.2

TLSv1_3

TLS バージョン 1.3

2.6.2. 暗号化スイートおよび ECDH 曲線の設定

暗号化スイートおよび ECDH 曲線 (Elliptic-curve Diffie–Hellman) は、サービスメッシュのセキュリティーを保護するのに役立ちます。暗号化スイートのコンマ区切りの一覧を spec.istio.global.tls.cipherSuites を使用して定義し、 ECDH 曲線を ServiceMeshControlPlane リソースの spec.istio.global.tls.ecdhCurves を使用して定義できます。これらの属性のいずれかが空の場合、デフォルト値が使用されます。

サービスメッシュが TLS 1.2 以前のバージョンを使用する場合、cipherSuites 設定が有効になります。この設定は、TLS 1.3 でネゴシエートする場合は影響を与えません。

コンマ区切りの一覧に暗号化スイートを優先度順に設定します。たとえば、ecdhCurves: CurveP256, CurveP384 は、CurveP256CurveP384 よりも高い優先順位として設定します。

注記

暗号化スイートを設定する場合は、<