Menu Close
Settings Close

Language and Page Formatting Options

Service Mesh

Red Hat OpenShift Service on AWS 4

Service Mesh のインストール、使用法、およびリリースノート

概要

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

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

1.1. OpenShift Service Mesh について

注記

Red Hat OpenShift Service Mesh は Red Hat OpenShift Service on AWS とは異なる頻度でリリースされ、Red Hat OpenShift Service Mesh Operator は ServiceMeshControlPlane の複数のバージョンのデプロイをサポートしているため、Service Mesh のドキュメントでは、本製品のマイナーバージョン用に個別のドキュメントセットを維持していません。現在のドキュメントセットは、特定のトピックまたは特定の機能でバージョン固有の制限がない限り、現在サポートされている Service Mesh のすべてのバージョンに適用されます。

Red Hat OpenShift Service Mesh のライフサイクルとサポートされるプラットフォームに関する追加情報については、Platform Life Cycle Policy を参照してください。

1.1.1. Red Hat OpenShift Service Mesh の概要

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

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

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

1.1.2. コア機能

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

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

1.2. Service Mesh リリースノート

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

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

1.2.2. 新機能および機能拡張

今回のリリースでは、以下のコンポーネントおよび概念に関連する拡張機能が追加されました。

1.2.2.1. Red Hat OpenShift Service Mesh バージョン 2.3 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures)に対応する新機能が導入され、バグ修正が含まれており、Red Hat OpenShift Service on AWS 4.9、4.10、および 4.11 でサポートされます。

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

Istio

1.14

Envoy プロキシー

1.22.4

Jaeger

1.38

Kiali

1.57.3

1.2.2.1.2. 新規 Container Network Interface (CNI) DaemonSet コンテナーおよび ConfigMap

openshift-operators namespace には、新規の istio CNI DaemonSet istio-cni-node-v2-3 と、新しい ConfigMap リソース istio-cni-config-v2-3 が含まれます

Service Mesh Control Plane 2.3 にアップグレードする場合、既存の istio-cni-node DaemonSet は変更されず、新規の istio-cni-node-v2-3 DaemonSet が 作成されます。

この名前の変更は、以前のリリースを使用してデプロイされた Service Mesh コントロールプレーンに関連付けられた以前のリリースまたは istio-cni-node CNI DaemonSet には影響しません。

1.2.2.1.3. ゲートウェイインジェクションのサポート

本リリースでは、ゲートウェイインジェクションの一般提供サポートが導入されました。ゲートウェイ設定は、サービスワークロードと共に実行されるサイドカー Envoy プロキシーではなく、メッシュのエッジで実行されているスタンドアロンの Envoy プロキシーに適用されます。これにより、ゲートウェイオプションをカスタマイズできます。ゲートウェイインジェクションを使用する場合は、ゲートウェイプロキシーを実行する namespace に、ServiceDeploymentRole、および RoleBinding リソースを作成する必要があります。

1.2.2.1.4. Istio 1.14 サポート

Service Mesh 2.3 は Istio 1.14 をベースとしており、新機能および製品の機能強化が追加されました。多くの Istio 1.14 機能がサポートされていますが、以下の例外に留意する必要があります。

  • proxyConfig API は、image フィールドを除きサポートされます。
  • Telemetry API はテクノロジープレビュー機能です。
  • SPIRE ランタイムはサポート対象外の機能です。
1.2.2.1.5. OpenShift Service Mesh コンソール

本リリースでは、Red Hat OpenShift Service on AWS Service Mesh コンソールの開発者プレビューバージョンが導入されました。これにより、Kiali インターフェイスを直接 OpenShift Web コンソールに統合します。詳細は、Introducing the OpenShift Service Mesh Console (A Developer Preview)を参照してください。

1.2.2.1.6. Cluster-Wide デプロイメント

本リリースでは、テクノロジープレビュー機能としてクラスター全体のデプロイメントが導入されました。クラスター全体のデプロイメントには、クラスター全体のリソースを監視するサービスメッシュコントロールプレーンが含まれます。コントロールプレーンはすべての namespace で単一のクエリーを使用して、メッシュ設定に影響を与える各 Istio または Kubernetes リソースの種類を監視します。一方、マルチテナントアプローチは、リソースの種類ごとに namespace ごとにクエリーを使用します。コントロールプレーンが実行するクエリーの数を減らすと、クラスター全体のデプロイメントで実行されるクエリーの数が減ります。

1.2.2.1.6.1. クラスター全体のデプロイメントの設定

以下の ServiceMeshControlPlane オブジェクトのサンプルは、クラスター全体のデプロイメントを設定します。

クラスター全体のデプロイメント用に SMCP を作成するには、ユーザーは cluster-admin ClusterRole に属している必要があります。SMCP がクラスター全体のデプロイメント用に設定されている場合は、クラスター内の SMCP のみである必要があります。コントロールプレーンモードをマルチテナントからクラスター全体(またはクラスター全体からマルチテナント)に変更することはできません。マルチテナントコントロールプレーンがすでに存在する場合は、削除して新規コントロールプレーンを作成します。

この例では、クラスター全体のデプロイメント向けに SMCP を設定します。

  apiVersion: maistra.io/v2
  kind: ServiceMeshControlPlane
  metadata:
    name: cluster-wide
    namespace: istio-system
  spec:
    version: v2.3
    techPreview:
      controlPlaneMode: ClusterScoped 1
1
Istiod が各 namespace を監視するのではなく、クラスターレベルでリソースを監視できるようにします。

さらに、SMMR もクラスター全体のデプロイメント用に設定する必要があります。この例では、クラスター全体のデプロイメント向けに SMMR を設定します。

  apiVersion: maistra.io/v1
  kind: ServiceMeshMemberRoll
  metadata:
    name: default
  spec:
    members:
    - '*' 1
1
その後に作成する namespace を含む、すべての namespace をメッシュに追加します。以下の namespace はメッシュの一部ではありません:kube、openshift、kube-*、および openshift-*。

1.2.2.2. Red Hat OpenShift Service Mesh バージョン 2.2.4 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures)に対応し、バグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされています。

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

Istio

1.14

Envoy プロキシー

1.20.8

Jaeger

1.36.14

Kiali

1.48.3

1.2.2.3. Red Hat OpenShift Service Mesh バージョン 2.2.3 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応し、OpenShift Container Platform 4.9 以降でサポートされます。

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

Istio

1.12.9

Envoy プロキシー

1.20.8

Jaeger

1.36

Kiali

1.48.3

1.2.2.4. Red Hat OpenShift Service Mesh バージョン 2.2.2 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応し、OpenShift Container Platform 4.9 以降でサポートされます。

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

Istio

1.12.7

Envoy プロキシー

1.20.6

Jaeger

1.36

Kiali

1.48.2-1

1.2.2.4.2. ルートラベルのコピー

この機能強化により、アノテーションのコピーに加えて、OpenShift ルートの特定のラベルをコピーできます。Red Hat OpenShift Service Mesh は、Istio Gateway リソースに存在するすべてのラベルとアノテーション (kubectl.kubernetes.io で始まるアノテーションを除く) を管理対象の OpenShift Route リソースにコピーします。

1.2.2.5. Red Hat OpenShift Service Mesh バージョン 2.2.1 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応し、OpenShift Container Platform 4.9 以降でサポートされます。

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

Istio

1.12.7

Envoy プロキシー

1.20.6

Jaeger

1.34.1

Kiali

1.48.2-1

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

このリリースの Red Hat OpenShift Service Mesh は、新しい機能と拡張機能を追加し、OpenShift Container Platform 4.9 以降でサポートされています。

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

Istio

1.12.7

Envoy プロキシー

1.20.4

Jaeger

1.34.1

Kiali

1.48.0.16

1.2.2.6.2. WasmPlugin API

このリリースでは、WasmPlugin API のサポートが追加され、ServiceMeshExtension API が非推奨になりました。

1.2.2.6.3. ROSA サポート

このリリースでは、マルチクラスターフェデレーションを含む Red Hat OpenShift on AWS(ROSA) のサービスメッシュサポートが導入されています。

1.2.2.6.4. istio-node DaemonSet の名前が変更されました

このリリースでは、istio-node DaemonSet の名前が istio-cni-node に変更され、アップストリーム Istio の名前と同じになりました。

1.2.2.6.5. エンボイサイドカーネットワークの変更

Istio 1.10 は、デフォルトで lo ではなく eth0 を使用してトラフィックをアプリケーションコンテナーに送信するように Envoy を更新しました。

1.2.2.6.6. Service Mesh コントロールプレーン 1.1

このリリースは、すべてのプラットフォームでの Service Mesh 1.1 に基づく Service Mesh コントロールプレーンのサポートの終了を示します。

1.2.2.6.7. Istio 1.12 サポート

Service Mesh 2.2 は Istio 1.12 に基づいており、新機能と製品の機能強化をもたらします。多くの Istio 1.12 機能がサポートされていますが、サポートされていない次の機能に注意する必要があります。

  • AuthPolicy ドライランはテクノロジープレビュー機能です。
  • gRPC Proxyless Service Mesh は、テクノロジープレビュー機能です。
  • Telemetry API は、テクノロジープレビュー機能です。
  • ディスカバリーセレクターはサポート対象外の機能です。
  • 外部コントロールプレーンはサポート対象外の機能です。
  • ゲートウェイインジェクションはサポート対象外の機能です。
1.2.2.6.8. Kubernetes Gateway API
重要

Kubernetes Gateway API はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

Kubernetes Gateway API は、デフォルトで無効になっているテクノロジープレビュー機能です。Kubernetes API デプロイメントコントローラーが無効になっている場合は、Ingress ゲートウェイを手動でデプロイし、作成された Gateway オブジェクトにリンクする必要があります。

Kubernetes API デプロイメントコントローラーが有効にされている場合、ゲートウェイオブジェクトの作成時に Ingress ゲートウェイは自動的にデプロイされます。

1.2.2.6.8.1. Gateway API CRD のインストール

Gateway API CRD は、デフォルトで OpenShift クラスターに事前にインストールされません。SMCP で Gateway API サポートを有効にする前に CRD をインストールします。

$ kubectl get crd gateways.gateway.networking.k8s.io || { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.4.0" | kubectl apply -f -; }
1.2.2.6.8.2. Kubernetes Gateway API の有効化

この機能を有効にするには、ServiceMeshControlPlaneIstiod コンテナーに次の環境変数を設定します。

spec:
  runtime:
    components:
      pilot:
        container:
          env:
            PILOT_ENABLE_GATEWAY_API: "true"
            PILOT_ENABLE_GATEWAY_API_STATUS: "true"
            # and optionally, for the deployment controller
            PILOT_ENABLE_GATEWAY_API_DEPLOYMENT_CONTROLLER: "true"

ゲートウェイ API リスナーでのルート接続を制限するには、SameNamespace または All 設定を使用します。Istio は、listeners.allowedRoutes.namespaces のラベルセレクターの使用を無視し、デフォルトの動作 (SameNamespace) に戻します。

1.2.2.6.8.3. 既存のゲートウェイをゲートウェイリソースに手動でリンクする

Kubernetes API デプロイメントコントローラーが無効になっている場合は、手動でデプロイして、作成したゲートウェイリソースにリンクする必要があります。

  apiVersion: gateway.networking.k8s.io/v1alpha2
  kind: Gateway
  metadata:
    name: gateway
  spec:
    addresses:
    - value: ingress.istio-gateways.svc.cluster.local
      type: Hostname

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

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures)に対応し、バグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされています。

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

Istio

1.14

Envoy プロキシー

1.17.5

Jaeger

1.36

Kiali

1.24.17

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

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応し、OpenShift Container Platform 4.9 以降でサポートされます。

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

Istio

1.9.9

Envoy プロキシー

1.17.5

Jaeger

1.36

Kiali

1.36.13

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

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応し、OpenShift Container Platform 4.9 以降でサポートされます。

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

Istio

1.9.9

Envoy プロキシー

1.17.1

Jaeger

1.36

Kiali

1.36.12-1

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

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

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

Istio

1.9.9

Envoy プロキシー

1.17.1

Jaeger

1.30.2

Kiali

1.36.12-1

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

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

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

Istio

1.9.9

Envoy プロキシー

1.17.1

Jaeger

1.30.2

Kiali

1.36.10-2

1.2.2.12. Red Hat OpenShift Service Mesh 2.1.2.1 の新機能

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

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

Istio

1.9.9

Envoy プロキシー

1.17.1

Jaeger

1.30.2

Kiali

1.36.9

1.2.2.13. Red Hat OpenShift Service Mesh 2.1.2 の新機能

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

このリリースでは、Red Hat 分散トレースプラットフォーム Operator がデフォルトで openshift-distributed-tracing namespace にインストールされるようになりました。以前のリリースでは、デフォルトのインストールは openshift-operator namespace にありました。

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

Istio

1.9.9

Envoy プロキシー

1.17.1

Jaeger

1.30.1

Kiali

1.36.8

1.2.2.14. Red Hat OpenShift Service Mesh 2.1.1 の新機能

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

本リリースでは、ネットワークポリシーの自動作成を無効にする機能も追加されています。

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

Istio

1.9.9

Envoy プロキシー

1.17.1

Jaeger

1.24.1

Kiali

1.36.7

1.2.2.14.2. ネットワークポリシーの無効化

Red Hat OpenShift Service Mesh は、Service Mesh コントロールプレーンおよびアプリケーションネームスペースで多数の NetworkPolicies リソースを自動的に作成し、管理します。これは、アプリケーションとコントロールプレーンが相互に通信できるようにするために使用されます。

NetworkPolicies リソースの自動作成および管理を無効にする場合 (例: 会社のセキュリティーポリシーを適用する場合など) には、これを実行できます。ServiceMeshControlPlane を編集して spec.security.manageNetworkPolicy 設定を falseに設定できます。

注記

spec.security.manageNetworkPolicy を無効にすると、Red Hat OpenShift Service Mesh は、NetworkPolicy オブジェクトをひとつも作成しません。システム管理者は、ネットワークを管理し、この原因の問題を修正します。

手順

  1. Red Hat OpenShift Service on AWS Web コンソールで、OperatorsInstalled Operators をクリックします。
  2. Project メニューから、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. Red Hat OpenShift Service Mesh Operator をクリックします。Istio Service Mesh Control Plane 列で、ServiceMeshControlPlane の名前 (basic-install など) をクリックします。
  4. Create ServiceMeshControlPlane Details ページで、YAML をクリックして設定を変更します。
  5. 以下の例のように、ServiceMeshControlPlane フィールド spec.security.manageNetworkPolicyfalse に設定します。

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    spec:
      security:
          trust:
          manageNetworkPolicy: false
  6. Save をクリックします。

1.2.2.15. Red Hat OpenShift Service Mesh 2.1 の新機能および機能拡張

Red Hat OpenShift Service Mesh の本リリースでは、Istio 1.9.8、Envoy Proxy 1.17.1、Jaeger 1.24.1、および Kiali 1.36.5 のサポートと新機能および機能拡張が Red Hat OpenShift Service on AWS 4.6 EUS、4.7、4.8、および 4.9 で追加されました。

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

Istio

1.9.6

Envoy プロキシー

1.17.1

Jaeger

1.24.1

Kiali

1.36.5

1.2.2.15.2. Service Mesh のフェデレーション

サービスメッシュをフェデレーションできるように新規のカスタムリソース定義 (CRD) が追加されました。サービスメッシュは、同じクラスター内または異なる OpenShift クラスター間でフェデレーションすることができます。これらの新規リソースには以下が含まれます。

  • ServiceMeshPeer: ゲートウェイ設定、ルート信頼証明書設定、ステータスフィールドなど、別のサービスメッシュでのフェデレーションを定義します。フェデレーションされたメッシュのペアでは、各メッシュは独自の ServiceMeshPeer リソースを個別に定義します。
  • ExportedServiceMeshSet: ピアメッシュのインポートに利用できる特定の ServiceMeshPeer サービスを定義します。
  • ImportedServiceSet: ピアメッシュからインポートする特定の ServiceMeshPeer のサービスを定義します。これらのサービスは、ピアの ExportedServiceMeshSet リソースで利用できるようにする必要もあります。

Service Mesh Federation は、Red Hat OpenShift Service on AWS (ROSA)、Azure Red Hat OpenShift (ARO)、または OpenShift Dedicated (OSD) のクラスター間ではサポートされていません。

1.2.2.15.3. OVN-Kubernetes Container Network Interface(CNI) の一般提供

OVN-Kubernetes Container Network Interface(CNI) は、以前は Red Hat OpenShift Service Mesh 2.0.1 のテクノロジープレビュー機能として導入されましたが、Red Hat OpenShift Service on AWS 4.7.32、Red Hat OpenShift Service on AWS 4.8.12、および Red Hat OpenShift Service on AWS 4.9 で使用できるように Red Hat OpenShift Service Mesh 2.1 および 2.0.x で一般提供されています。

1.2.2.15.4. Service Mesh WebAssembly(WASM) 拡張

ServiceMeshExtensions カスタムリソース定義 (CRD) は、最初に 2.0 でテクノロジープレビュー機能として導入され、今回のバージョンで一般公開されました。CRD を使用して独自のプラグインを構築することができますが、Red Hat では、独自に作成されたプラグインはサポートしていません。

Mixer はサービスメッシュ 2.1 で完全に削除されました。Mixer が有効な場合は、Service Mesh 2.0.x リリースから 2.1 へのアップグレードは、ブロックされます。Mixer プラグインは WebAssembly 拡張に移植する必要があります。

1.2.2.15.5. 3scale WebAssembly Adapter(WASM)

Mixer が正式に削除されたため、OpenShift 3scale mixer アダプターは、Service Mesh 2.1 ではサポート対象外となっています。Service Mesh 2.1 にアップグレードする前に、Mixer ベースの 3scale アダプターと追加の Mixer プラグインを削除します。次に、ServiceMeshExtension リソースを使用して、新しい 3scale WebAssembly アダプターを Service Mesh 2.1+ で手動でインストールして設定します。

3scale 2.11 では、WebAssembly に基づく更新された Service Mesh の統合が導入されました。

1.2.2.15.6. Istio 1.9 サポート

Service Mesh 2.1 は Istio 1.9 をベースとしており、製品の新機能および機能拡張が数多く追加されました。Istio 1.9 の大半の機能がサポートされていますが、以下の例外に注意してください。

  • 仮想マシンの統合はまだサポートされていません。
  • Kubernetes Gateway API はまだサポートされていません。
  • WebAssembly HTTP フィルターのリモートフェッチおよびロードはサポートされていません。
  • Kubernetes CSR API を使用したカスタム CA 統合はまだサポートされていません。
  • トラフィック監視要求の分類機能はテクノロジープレビュー機能です。
  • Authorization ポリシーの CUSTOM アクションによる外部承認システムとの統合はテクノロジープレビュー機能です。
1.2.2.15.7. Service Mesh Operator のパフォーマンス向上

ServiceMeshControlPlane の調整の終了時に以前のリソースのプルーニングに使用する期間が短縮されました。これにより、ServiceMeshControlPlane のデプロイメントにかかる時間が短縮され、既存の SMCP に適用される変更がこれまでよりも早く有効になります。

1.2.2.15.8. Kiali の更新

Kiali 1.36 には、以下の機能と拡張機能が含まれています。

  • Service Mesh のトラブルシューティング機能

    • コントロールプレーンおよびゲートウェイの監視
    • プロキシーの同期ステータス
    • Envoy 設定ビュー
    • Envoy プロキシーおよびアプリケーションログのインターリーブを示す統合ビュー
  • フェデレーションされたサービスメッシュビューをサポートする namespace およびクラスターボックス
  • 新しい検証、ウィザード、および分散トレースの機能拡張

1.2.2.16. Red Hat OpenShift Service Mesh 2.0.11.1 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応し、OpenShift Container Platform 4.9 以降でサポートされます。

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

Istio

1.6.14

Envoy プロキシー

1.14.5

Jaeger

1.36

Kiali

1.24.17

1.2.2.17. Red Hat OpenShift Service Mesh 2.0.11 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応し、OpenShift Container Platform 4.9 以降でサポートされます。

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

Istio

1.6.14

Envoy プロキシー

1.14.5

Jaeger

1.36

Kiali

1.24.16-1

1.2.2.18. Red Hat OpenShift Service Mesh 2.0.10 の新機能

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

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

Istio

1.6.14

Envoy プロキシー

1.14.5

Jaeger

1.28.0

Kiali

1.24.16-1

1.2.2.19. Red Hat OpenShift Service Mesh 2.0.9 の新機能

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

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

Istio

1.6.14

Envoy プロキシー

1.14.5

Jaeger

1.24.1

Kiali

1.24.11

1.2.2.20. Red Hat OpenShift Service Mesh 2.0.8 の新機能

Red Hat OpenShift Service Mesh の本リリースでは、バグ修正に対応しています。

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

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

1.2.2.21.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.21.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.22. Red Hat OpenShift Service Mesh 2.0.7 の新機能

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

1.2.2.23. 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.24. Red Hat OpenShift Service Mesh 2.0.6 の新機能

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

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

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

1.2.2.26. 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.26.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.26.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.26.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.26.4. パスを正規化するための SMCP の設定

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

SMCP v2 pathNormalization

spec:
  techPreview:
    global:
      pathNormalization: <option>

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

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

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.27. Red Hat OpenShift Service Mesh 2.0.3 の新機能

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

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

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

1.2.2.28. 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.29. Red Hat OpenShift Service Mesh 2.0.1 の新機能

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

1.2.2.30. 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 および Red Hat OpenShift Service on AWS 4.6 のサポートが追加されました。

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

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

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

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

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

現在、今回のリリースに含まれる機能にはテクノロジープレビューのものがあります。これらの実験的機能は、実稼働環境での使用を目的としていません。

重要

テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

1.2.4. 非推奨および削除された機能

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

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

本製品では、削除機能が除去されています。

1.2.4.1. 非推奨および削除された Red Hat OpenShift Service Mesh 2.3 の機能

以下の暗号スイートのサポートが非推奨になりました。今後のリリースでは、クライアントとサーバー側の両方で TLS ネゴシエーションで使用される暗号のデフォルトリストから削除されます。

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

Red Hat OpenShift Service Mesh バージョン 2.2 で非推奨となった ServiceMeshExtension API は、Red Hat OpenShift Service Mesh バージョン 2.3 で削除されました。ServiceMeshExtension API を使用している場合は、WasmPlugin API に移行して WebAssembly 拡張を引き続き使用する必要があります。

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

ServiceMeshExtension API は、リリース 2.2 で非推奨になり、今後のリリースで削除される予定です。ServiceMeshExtension API はリリース 2.2 でも引き続きサポートされていますが、お客様は新しい WasmPluginAPI への移行を開始する必要があります。

1.2.4.3. Red Hat OpenShift Service Mesh 2.2 から削除された機能

このリリースは、すべてのプラットフォームでの Service Mesh 1.1 に基づく Service Mesh コントロールプレーンのサポートの終了を示します。

1.2.4.4. Red Hat OpenShift Service Mesh 2.1 の新機能

Service Mesh 2.1 では、Mixer コンポーネントが削除されます。バグ修正およびサポートは、Service Mesh 2.0 の最後のライフサイクルで提供されます。

Mixer プラグインが有効な場合は、Service Mesh 2.0.x リリースから 2.1 へのアップグレードは続行されません。Mixer プラグインは、WebAssembly 拡張に移植する必要があります。

1.2.4.5. 非推奨になった 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 を使用しますが、Service Mesh コントロールプレーン namespace に配置します。
  • RbacConfig (rbac.istio.io/v1alpha1) はサポートされなくなりました。

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

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

1.2.5.1. Service Mesh の既知の問題

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

  • Istio-14743 Red Hat OpenShift Service Mesh のこのリリースがベースとしている Istio のバージョンに制限があるため、現時点で Service Mesh と互換性のないアプリケーションが存在する可能性があります。詳細は、リンク先のコミュニティーの問題を参照してください。
  • OSSM-2221 ゲートウェイの挿入はコントロールプレーン namespace では機能しません。ゲートウェイインジェクション機能を使用してコントロールプレーンと同じ場所にゲートウェイを作成すると、インジェクションに失敗し、OpenShift は以下のメッセージを生成します。

    Warning Failed 10s kubelet, ocp-wide-vh8fd-worker-vhqm9 Failed to pull image "auto": rpc error: code = Unknown desc = reading manifest latest in docker.io/library/auto: errors

    コントロールプレーン namespace でゲートウェイを作成するには、SMCP 仕様の gateways パラメーターを使用してメッシュの ingress および egress ゲートウェイを設定します。

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

    コンポーネント mesh-config の処理エラー:[mesh-config/templates/telemetryv2_1.6.yaml: 内部エラーが発生しました:failed calling webhook "rev.validation.istio.io": post "https://istiod-default.istio-system.svc:443/validate?timeout=10s": x509: certificate is valid for istiod.istio-system.svc, istiod-remote.istio-system.svc, istio-pilot.istio-system.svc, not istiod-default.istio-system.svc, mesh-config/templates/enable-mesh-permissive.yaml

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

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

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

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

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

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

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

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

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

    api:
      namespaces:
        exclude:
        - "^istio-operator"
        - "^kube-.*"
        - "^openshift.*"
        - "^ibm.*"
        - "^kiali-operator"
  • MAISTRA-2692 Mixer が削除されると、Service Mesh 2.0.x で定義されたカスタムメトリクスを 2.1 で使用できません。カスタムメトリクスは EnvoyFilter を使用して設定できます。明示的に文書化されている場合を除き、Red Hat は EnvoyFilter 設定をサポートできません。これは、下層の Envoy API と疎結合されており、後方互換性を保持することができないためです。
  • MAISTRA-2648 ServiceMeshExtensions は現時点で IBM Z Systems にデプロイされたメッシュとは互換性がありません。
  • MAISTRA-1959 2.0 への移行 Prometheus の収集 (spec.addons.prometheus.scrapetrue に設定される) は mTLS が有効にされていると機能しません。また、Kiali は、mTLS が無効にされている場合に余分なグラフデータを表示します。

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

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

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. Red Hat OpenShift 分散トレースの既知の問題

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

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

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

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

    • Jaeger Operator チャネル: 1.17.x stable または 1.20.x stable
    • AMQ Streams Operator チャネル: amq-streams-1.6.x

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

1.2.6. 修正された問題

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

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

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

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

  • OSSM-1962 フェデレーションコントローラーで EndpointSlices を使用します。フェデレーションコントローラーは EndpointSlices を使用するようになり、大規模なデプロイメントでのスケーラビリティーとパフォーマンスが向上します。PILOT_USE_ENDPOINT_SLICE フラグはデフォルトで有効になっています。フラグを無効にすると、フェデレーションデプロイメントの使用が阻止されます。
  • OSSM-1668 新しいフィールド spec.security.jwksResolverCA がバージョン 2.1 SMCP に追加されましたが、2.2.0 および 2.2.1 リリースにはありませんでした。このフィールドが存在する Operator バージョンから、このフィールドが存在しなかった Operator バージョンにアップグレードする場合、SMCP.spec.security.jwksResolverCA フィールドを使用できませんでした。
  • OSSM-1325 istiod Pod がクラッシュし、fatal error: concurrent map iteration and map write のエラーメッセージが表示されます。
  • OSSM-1211 フェールオーバー用のフェデレーションサービスメッシュの設定が想定どおりに機能しません。

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

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

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

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

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

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

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

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

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

    • Galley
    • Grafana
    • Istiod
    • Jaeger
    • Kiali
    • Prometheus
    • サイドカーインジェクター
  • MAISTRA-2378 クラスターが ovs-multitenant で OpenShift SDN を使用するように設定されており、メッシュに多数の namespace (200+) が含まれる場合に、Red Hat OpenShift Service on AWS ネットワークプラグインは namespace を迅速に設定することができません。Service Mesh がタイムアウトすると、namespace がサービスメッシュから継続的にドロップされ、再リストされます。
  • MAISTRA-2370 は listerInformer で tombstones を処理します。更新されたキャッシュコードベースは、namespace キャッシュからのイベントを集約されたキャッシュに変換する際に tombstones を処理しないため、go ルーチンでパニックが生じました。
  • MAISTRA-2117 オプションの ConfigMap マウントを Operator に追加します。CSV にはオプションの ConfigMap ボリュームマウントが含まれるようになり、smcp-templates ConfigMap (存在する場合) をマウントします。smcp-templates ConfigMap が存在しない場合には、マウントされたディレクトリーは空になります。ConfigMap を作成すると、ディレクトリーには ConfigMap からのエントリーが設定され、SMCP.spec.profiles で参照できます。Service Mesh Operator の再起動は必要ありません。

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

  • MAISTRA-2010 AuthorizationPolicy は request.regex.headers フィールドをサポートしません。validatingwebhook はこのフィールドのある AuthorizationPolicy を拒否し、これを無効にした場合でも、パイロットは同じコードを使用してこの検証を試行し、機能しません。
  • MAISTRA-1979 2.0 への移行 変換 webhook は、SMCP.status を v2 から v1 に変換する際に以下の重要なフィールドをドロップします。

    • conditions
    • components
    • observedGeneration
    • annotations

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

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

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

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

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

    • [2019-06-03 07:03:28.943][19][warning][misc] [external/envoy/source/common/protobuf/utility.cc:129] Using deprecated option 'envoy.api.v2.listener.Filter.config'.この設定はまもなく Envoy から削除されます。
    • [2019-08-12 22:12:59.001][13][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Listener.use_original_dst' from file lds.proto.この設定はまもなく Envoy から削除されます。
  • MAISTRA-806 エビクトされた Istio Operator Pod により、メッシュおよび CNI はデプロイできなくなります。

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

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

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

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

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

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

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

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

1.3. Service Mesh について

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

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

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

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

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

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

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

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

1.3.2. Service Mesh アーキテクチャー

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

Service Mesh architecture image

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

以下の Istio 統合は Red Hat OpenShift Service Mesh でサポートされます。

  • 3scale: Istio では、オプションで Red Hat 3scale API Management ソリューションとの統合が提供されます。2.1 より前のバージョンでは、この統合は 3scale Istio アダプターを使用して実行されました。バージョン 2.1 以降では、3scale の統合は WebAssembly モジュールを介して行われます。

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

1.3.3. Kiali について

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

1.3.3.1. Kiali の概要

Kiali は、Red Hat OpenShift Service on AWS で実行されている Service Mesh に可観測性を提供します。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 は 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 はサービスメッシュ設定を取得し、解決するために、Red Hat OpenShift Service on AWS (Cluster API) の API を使用します。Kiali は Cluster API に対してクエリーを実行し、たとえば、namespace、サービス、デプロイメント、Pod、その他のエンティティーの定義を取得します。Kiali はクエリーを実行して、異なるクラスターエンティティー間の関係も解決します。Cluster API に対してもクエリーを実行し、仮想サービス、宛先ルール、ルートルール、ゲートウェイ、クォータなどの Istio 設定を取得します。
  • Jaeger: Jaeger はオプションですが、Red Hat OpenShift Service Mesh インストールの一部としてデフォルトでインストールされます。デフォルトの Red Hat OpenShift Service Mesh インストールの一部として分散トレースプラットフォームをインストールすると、Kiali コンソールには分散トレースデータを表示するタブが含まれます。Istio の分散トレース機能を無効にした場合、トレースデータは利用できないことに注意してください。また、トレースデータを表示するには、ユーザーは Service Mesh コントロールプレーンがインストールされている namespace にアクセスできる必要があります。
  • Grafana: Grafana はオプションですが、デフォルトでは Red Hat OpenShift Service Mesh インストールの一部としてインストールされます。使用可能な場合、Kiali のメトリクスページには Grafana 内の同じメトリクスにユーザーを移動させるリンクが表示されます。Grafana ダッシュボードへのリンクと Grafana データを表示するには、Service Mesh コントロールプレーンがインストールされている namespace にユーザーがアクセスできる必要があることに注意してください。

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. 分散トレースについて

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

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

分散トレースプラットフォームは、マイクロサービスのスタック全体で個別のリクエストの実行を記録し、トレースとして表示します。トレース とは、システムにおけるデータ/実行パスです。エンドツーエンドトレースは、1 つ以上のスパンで設定されます。

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

1.3.4.1. 分散トレースの概要

サービスの所有者は、分散トレースを使用してサービスをインストルメント化し、サービスアーキテクチャーに関する洞察を得ることができます。分散トレースを使用して、現代的なクラウドネイティブのマイクロサービスベースのアプリケーションにおける、コンポーネント間の対話の監視、ネットワークプロファイリング、およびトラブルシューティングを行うことができます。

分散トレースを使用すると、以下の機能を実行できます。

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

Red Hat OpenShift の分散トレースは、2 つの主要コンポーネントで設定されています。

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

これらのコンポーネントは共に、特定のベンダーに依存しない OpenTracing API およびインストルメンテーションに基づいています。

1.3.4.2. Red Hat OpenShift 分散トレースのアーキテクチャー

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

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

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

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

1.3.4.3. Red Hat OpenShift 分散トレースの機能

Red Hat OpenShift 分散トレースには、以下の機能が含まれます。

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

1.3.5. 次のステップ

1.4. サービスメッシュのデプロイメントモデル

Red Hat OpenShift Service Mesh は、さまざまなデプロイメントモデルを複数サポートし、ビジネス要件に最も適合するように、各種方法を組み合わせることができます。

1.4.1. 単一メッシュデプロイメントモデル

最も単純な Istio デプロイメントモデルは単一のメッシュです。

Kubernetes では mynamespace namespace で myservice という名前を指定できるのはサービス 1 つであるため、メッシュ内のサービス名は一意である必要があります。ただし、ワークロードインスタンスは、サービスアカウント名を同じ namespace のワークロード間で共有できるため、共通のアイデンティティーを共有できます。

1.4.2. 単一のテナンシーデプロイメントモデル

Istio では、テナントはデプロイされたワークロードで共通のアクセスおよび権限を共有するユーザーのグループです。テナントを使用して、異なるチーム間で一定レベルの分離を確保できます。Istio.io またはサービスリソースの NetworkPoliciesAuthorizationPolicies、および exportTo アノテーションを使用して、異なるテナントへのアクセスを分離できます。

OpenShift Service Mesh バージョン 1.0 の時点では、単一テナントの、クラスター全体での Service Mesh コントロールプレーン設定は推奨されていません。Red Hat OpenShift Service Mesh はデフォルトでマルチテナントモデルに設定されます。

1.4.3. マルチテナントデプロイメントモデル

Red Hat OpenShift Service Mesh は、デフォルトでマルチテナントとして設定される ServiceMeshControlPlane をインストールします。Red Hat OpenShift Service Mesh はマルチテナント Operator を使用して、Service Mesh コントロールプレーンのライフサイクルを管理します。メッシュ内では、テナントに namespace が使用されます。

Red Hat OpenShift Service Mesh は ServiceMeshControlPlane リソースを使用してメッシュインストールを管理します。メッシュのインストールのスコープはデフォルトでは、リソースを含む namespace に限定されます。ServiceMeshMemberRoll および ServiceMeshMember リソースを使用して、別の namespace をメッシュに追加します。Namespace は単一のメッシュにのみ組み込むことができ、複数のメッシュを単一の OpenShift クラスターにインストールできます。

通常のサービスメッシュデプロイメントでは、単一の Service Mesh コントロールプレーンを使用してメッシュ内のサービス間の通信を設定します。Red Hat OpenShift Service Mesh はテナントごとにコントロールプレーン 1 つと、メッシュが 1 つあるソフトマルチテナンシーをサポートします。クラスター内には、複数の独立したコントロールプレーンが存在させることができます。マルチテナントのデプロイメントでは、Service Mesh にアクセスできるプロジェクトを指定し、Service Mesh を他のコントロールプレーンインスタンスから分離します。

クラスター管理者はすべての Istio コントロールプレーンを制御して、表示できますが、テナント管理者は特定の Service Mesh、Kiali、および Jaeger インスタンスしか制御できません。

指定の namespace または namespace 設定だけにワークロードをデプロイするチームパーミッションを付与できます。サービスメッシュ管理者が mesh-user ロールを付与された場合には、ユーザーは ServiceMeshMember リソースを作成して namespace を ServiceMeshMemberRoll に追加できます。

1.4.4. マルチテーマまたはフェデレーションされたデプロイメントモデル

フェデレーション は、個別の管理ドメインで管理される個別のメッシュ間でサービスとワークロードを共有できるデプロイメントモデルです。

Istio マルチクラスターモデルでは、メッシュ間だで高いレベルの信頼が必要なだけでなく、個々のメッシュが存在するすべての Kubernetes API サーバーへのリモートアクセスも必要です。Red Hat OpenShift Service Mesh のフェデレーションは、メッシュ間の最小限の信頼を前提とする Service Mesh のマルチクラスター実装に対して独自のアプローチを採用しています。

フェデレーションされたメッシュ は、単一のメッシュとして動作させるメッシュのグループです。各メッシュのサービスは、独自のサービスにすることができます。たとえば、別のメッシュからサービスをインポートすることでサービスを追加するメッシュは、メッシュ全体で同じサービスにさらにワークロードを追加し、高可用性を提供することや、その両方を組み合わせることができます。フェデレーションされたメッシュに参加するすべてのメッシュは個別に管理されたままなので、フェデレーション内の他のメッシュとの間でエクスポートやインポートされるサービスを明示的に設定する必要があります。証明書の生成、メトリクス、トレース収集などのサポート機能は、それぞれのメッシュのローカルで機能します。

1.5. Service Mesh と Istio の相違点

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

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

以下の機能は Service Mesh と Istio で異なります。

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

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

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

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

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

1.5.1.3. 自動的な挿入

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

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

表1.3 サイドカーインジェクションのラベルとアノテーションの設定

 アップストリーム IstioRed Hat OpenShift Service Mesh

namespace ラベル

"enabled" と "disabled"をサポート

"disabled" をサポート

Pod Label

"true" と "false"をサポート

"true" と "false"をサポート

Pod のアノテーション

"false" のみをサポート

"true" と "false"をサポート

1.5.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.5.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.5.1.6. 外部ワークロード

Red Hat OpenShift Service Mesh は、ベアメタルサーバー上で OpenShift の外部で実行される仮想マシンなどの外部ワークロードをサポートしません。

1.5.1.7. 仮想マシンのサポート

OpenShift Virtualization を使用して、仮想マシンを OpenShift にデプロイできます。次に、メッシュの一部である他の Pod と同様に、mTLS または AuthorizationPolicy などのメッシュポリシーをこれらの仮想マシンに適用できます。

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

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

1.5.1.9. Envoy フィルター

Red Hat OpenShift Service Mesh は、明示的に文書化されている場合を除き、EnvoyFilter の設定はサポートしていません。下層の EnvoyAPI と疎結合されており、後方互換性を確保できません。EnvoyFilter パッチは、Istio によって生成される Envoy 設定の形式に非常に敏感です。Istio で生成された設定を変更すると、EnvoyFilter のアプリケーションが破損する可能性があります。

1.5.1.10. Envoy サービス

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

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

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

1.5.1.12. グローバル mTLS 設定

Red Hat OpenShift Service Mesh は、メッシュ内で相互 TLS 認証 (mTLS) を有効または無効にする PeerAuthentication リソースを作成します。

1.5.1.13. ゲートウェイ

Red Hat OpenShift Service Mesh は、デフォルトで受信および送信用のゲートウェイをインストールします。次の設定を使用して、ServiceMeshControlPlane (SMCP) リソースでゲートウェイのインストールを無効にすることができます。

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

Operator はデフォルトゲートウェイにアノテーションを付けて、それらが Red Hat OpenShift Service Mesh Operator によって生成および管理されていることを示します。

1.5.1.14. マルチクラスター設定

マルチクラスター設定の Red Hat OpenShift Service Mesh のサポートは、複数のクラスターにおけるサービスメッシュのフェデレーションに限定されます。

1.5.1.15. カスタム証明書署名要求 (CSR)

Kubernetes 認証局 (CA) で CSR を処理するように Red Hat OpenShift Service Mesh を設定することはできません。

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

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

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

1.5.1.16.1. catch-all ドメイン

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

1.5.1.16.2. サブドメイン

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

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

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

関連情報

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

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

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

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

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

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

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

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

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

    注記

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

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

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

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

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

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

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

  • Kiali はデフォルトで有効になっている。
  • Ingress はデフォルトで有効になっている。
  • Kiali ConfigMap が更新されている。
  • Kiali の ClusterRole 設定が更新されている。
  • 変更は Service Mesh または Kiali Operator によって上書きされる可能性があるため、ConfigMap を編集しないでください。Kiali Operator が管理するファイルには、kiali.io/ ラベルまたはアノテーションが付いています。Operator ファイルの更新は、cluster-admin 権限を持つユーザーに制限する必要があります。Red Hat OpenShift Dedicated を使用する場合に、dedicated-admin 権限のあるユーザーだけが Operator ファイルを更新できるようにする必要があります。

1.5.4. 分散トレースとサービスメッシュ

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

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

1.6. Service Mesh のインストールの準備

Red Hat OpenShift Service Mesh をインストールする前に、Red Hat OpenShift Service on AWS にサブスクライブし、サポートされている設定で Red Hat OpenShift Service on AWS をインストールする必要があります。

1.6.1. 前提条件

  • Red Hat アカウントにアクティブな Red Hat OpenShift Service on AWS サブスクリプションがある。サブスクリプションをお持ちでない場合は、営業担当者にお問い合わせください。
  • Red Hat OpenShift Service on AWS のバージョンに一致する Red Hat OpenShift Service on AWS コマンドラインユーティリティー (oc クライアントツール) のバージョンをインストールし、それをパスに追加する。

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

1.6.2. サポートされる構成

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

1.6.2.1. サポートされるプラットフォーム

Red Hat OpenShift Service Mesh Operator は、複数のバージョンの ServiceMeshControlPlane リソースをサポートします。バージョン 2.3 Service Mesh コントロールプレーンは、以下のプラットフォームバージョンでサポートされます。

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

1.6.2.2. サポートされない設定

明示的にサポート対象外とされているケースには、以下が含まれます。

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

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

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

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

1.6.2.4. Service Mesh でサポートされる設定

  • Red Hat OpenShift Service Mesh のこのリリースは、Red Hat OpenShift Service on AWS x86_64、IBM Z、および IBM Power Systems でのみ使用できます。

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

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

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

1.6.2.6. 分散トレースのサポートされる設定

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

1.6.2.7. サポート対象の WebAssembly モジュール

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

1.6.3. 次のステップ

1.7. Operator のインストール

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

注記

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

前提条件

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

1.7.1. Operator の概要

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

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

Operator のコミュニティーバージョンはインストールしないでください。コミュニティー Operator はサポートされていません。

1.7.2. Operator のインストール

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

  • OpenShift Elasticsearch
  • Red Hat OpenShift 分散トレースプラットフォーム
  • Kiali
  • Red Hat OpenShift Service Mesh
注記

OpenShift Logging の一部として OpenShift Elasticsearch Operator がすでにインストールされている場合、OpenShift Elasticsearch Operator を再びインストールする必要はありません。Red Hat OpenShift 分散トレースプラットフォーム Operator はインストールされた OpenShift Elasticsearch Operator を使用して Elasticsearch インスタンスを作成します。

手順

  1. cluster-admin ロールを持つユーザーとして Red Hat OpenShift Service on AWS Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
  2. Red Hat OpenShift Service on AWS Web コンソールで、OperatorOperatorHub をクリックします。
  3. Operator のフィルターボックスに名前を入力し、Red Hat バージョンの Operator を選択します。Operator のコミュニティーバージョンはサポートされていません。
  4. Install をクリックします。
  5. 各 Operator の Install Operator ページで、デフォルト設定を受け入れます。
  6. Install をクリックします。Operator がインストールされるまで待機してから、一覧で次に来る Operator で手順を繰り返します。

    • OpenShift Elasticsearch Operator は、openshift-operators-redhat namespace にインストールされ、クラスター内のすべての namespace で使用できます。
    • Red Hat OpenShift 分散トレースプラットフォームは、openshift-distributed-tracing namespace にインストールされ、クラスター内のすべての namespace で使用できます。
    • Kiali および Red Hat Service Mesh Operator は、openshift-operators namespace にインストールされ、クラスター内のすべての namespace で使用できます。
  7. 4 つの Operator すべてをインストールしたら、OperatorsInstalled Operators をクリックし、Operator がインストールされていることを確認します。

1.7.3. 次のステップ

Red Hat OpenShift Service Mesh Operator は、Service Mesh コントロールプレーンをデプロイするまで、さまざまな Service Mesh カスタムリソース定義 (CRD) を作成しません。ServiceMeshControlPlane リソースを使用して、Service Mesh コンポーネントをインストールおよび設定します。詳細は、Creating the ServiceMeshControlPlane を参照してください。

1.8. ServiceMeshControlPlane の作成

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

注記

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

注記

Red Hat OpenShift Service on AWS (ROSA) では、リソースを作成できる場所に関して追加の制限が適用されるので、デフォルトのデプロイメントは機能しません。ROSA 環境に SMCP をデプロイする前に、追加の要件について、Red Hat OpenShift Service on AWS (ROSA) へのインストールを参照してください。

注記

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

1.8.1. Web コンソールからの Service Mesh コントロールプレーンのデプロイ

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

前提条件

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

手順

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

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

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

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

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

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

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

1.8.2. CLI を使用した Service Mesh コントロールプレーンのデプロイ

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

前提条件

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

手順

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

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

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

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

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

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

    $ oc create -n istio-system -f <istio_installation.yaml>
  5. Pod のデプロイメントの進行状況を監視するには、次のコマンドを実行します。

    $ oc get pods -n istio-system -w

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

    NAME                                   READY   STATUS    RESTARTS   AGE
    grafana-b4d59bd7-mrgbr                 2/2     Running   0          65m
    istio-egressgateway-678dc97b4c-wrjkp   1/1     Running   0          108s
    istio-ingressgateway-b45c9d54d-4qg6n   1/1     Running   0          108s
    istiod-basic-55d78bbbcd-j5556          1/1     Running   0          108s
    jaeger-67c75bd6dc-jv6k6                2/2     Running   0          65m
    kiali-6476c7656c-x5msp                 1/1     Running   0          43m
    prometheus-58954b8d6b-m5std            2/2     Running   0          66m

1.8.3. CLI を使用した SMCP インストールの検証

コマンドラインから ServiceMeshControlPlane の作成を検証できます。

手順

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

    $ oc login https://<HOSTNAME>:6443
  2. 次のコマンドを実行して、Service Mesh コントロールプレーンのインストールを確認します。istio-system は、Service Mesh コントロールプレーンをインストールした namespace です。

    $ oc get smcp -n istio-system

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

    NAME    READY   STATUS            PROFILES      VERSION   AGE
    basic   10/10   ComponentsReady   ["default"]   2.1.1     66m

1.8.4. Kiali を使用した SMCP インストールの検証

Kiali コンソールを使用して、Service Mesh のインストールを検証できます。Kiali コンソールには、Service Mesh コンポーネントが適切にデプロイおよび設定されていることを検証する方法がいくつかあります。

手順

  1. cluster-admin 権限を持つユーザーとして Red Hat OpenShift Service on AWS Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
  2. NetworkingRoutes に移動します。
  3. Routes ページで、Namespace メニューから Service Mesh コントロールプレーンプロジェクトを選択します (例: istio-system)。

    Location 列には、各ルートのリンク先アドレスが表示されます。

  4. 必要に応じて、フィルターを使用して Kiali コンソールのルートを見つけます。ルートの Location をクリックしてコンソールを起動します。
  5. Log In With OpenShift をクリックします。

    初回の Kiali コンソールへのログイン時に、表示するパーミッションを持つサービスメッシュ内のすべての namespace を表示する Overview ページが表示されます。概要 ページに複数の namespace が表示されている場合には、Kiali は最初に正常性または検証に問題がある namespace を表示します。

    図1.1 Kiali の概要ページ

    Kiali Overview page showing istio-system

    各 namespace のタイルには、ラベルの数、Istio Config の状態、アプリケーション の状態と数、namespace の トラフィック が表示されます。コンソールのインストールを検証中で、namespace がまだメッシュに追加されていない場合、istio-system 以外のデータは表示されない可能性があります。

  6. Kiali には、Service Mesh コントロールプレーンがインストールされている namespace 専用のダッシュボードが 4 つあります。これらのダッシュボードを表示するには、オプション メニューをクリックします kebab コントロールプレーン namespace のタイル (例: istio-system) で、次のいずれかのオプションを選択します。

    • Istio メッシュダッシュボード
    • Istio コントロールプレーンダッシュボード
    • Istio パフォーマンスダッシュボード
    • Istio Wasm Exetension ダッシュボード

      図1.2 GrafanaIstio コントロールプレーンダッシュボード

      Istio Control Plane Dashboard showing data for bookinfo sample project

      Kiali は、Grafana ホームページ から入手できる追加の Grafana ダッシュボード 2 つもインストールします。

    • Istio ワークロードダッシュボード
    • Istio サービスダッシュボード
  7. Service Mesh コントロールプレーンノードを表示するには、グラフ ページをクリックし、メニューから ServiceMeshControlPlane をインストールした Namespace を選択します (例 :istio-system)。

    1. 必要に応じて、Display idle nodes をクリックします。
    2. グラフ ページの詳細は、グラフツアー リンクをクリックしてください。
    3. メッシュトポロジーを表示するには、namespace メニューの Service Mesh メンバーロールから追加の namespace を 1 つまたは複数選択します。
  8. istio-system namespace 内のアプリケーションのリストを表示するには、アプリケーション ページをクリックします。Kiali は、アプリケーションの状態を表示します。

    1. 情報アイコンの上にマウスをかざすと、詳細 列に記載されている追加情報が表示されます。
  9. istio-system namespace のワークロードのリストを表示するには、ワークロード ページをクリックします。Kiali は、ワークロードの状態を表示します。

    1. 情報アイコンの上にマウスをかざすと、詳細 列に記載されている追加情報が表示されます。
  10. istio-system namespace のサービスのリストを表示するには、サービス ページをクリックします。Kiali は、サービスと設定の状態を表示します。

    1. 情報アイコンの上にマウスをかざすと、詳細 列に記載されている追加情報が表示されます。
  11. istio-system namespace の Istio 設定オブジェクトのリストを表示するには、Istio Config ページをクリックします。Kiali は、設定の正常性を表示します。

    1. 設定エラーがある場合は、行をクリックすると、Kiali が設定ファイルを開き、エラーが強調表示されます。

1.8.5. Red Hat OpenShift Service on AWS (ROSA) へのインストール

バージョン 2.2 以降、Red Hat OpenShift Service Mesh は Red Hat OpenShift Service on AWS (ROSA) へのインストールがサポートされます。本セクションでは、このプラットフォームに Service Mesh をインストールする際の追加の要件について説明します。

1.8.5.1. インストールの場所

Red Hat OpenShift Service Mesh をインストールし、ServiceMeshControlPlane を作成する際に、istio-system などの新規 namespace を作成する必要があります。

1.8.5.2. 必要な Service Mesh コントロールプレーンの設定

ServiceMeshControlPlane ファイルのデフォルト設定は ROSA クラスターでは機能しません。Red Hat OpenShift Service on AWS にインストールする場合は、デフォルトの SMCP を変更し、spec.security.identity.type=ThirdParty を設定する必要があります。

ROSA 用の ServiceMeshControlPlane リソースの例

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
  namespace: istio-system
spec:
  version: v2.3
  security:
    identity:
      type: ThirdParty  #required setting for ROSA
  tracing:
    type: Jaeger
    sampling: 10000
  policy:
    type: Istiod
  addons:
    grafana:
      enabled: true
    jaeger:
      install:
        storage:
          type: Memory
    kiali:
      enabled: true
    prometheus:
      enabled: true
  telemetry:
    type: Istiod

1.8.5.3. Kiali 設定の制限

Red Hat OpenShift Service on AWS では、リソースを作成できる場所に関して追加の制限が適用され、Red Hat 管理の namespace に Kiali リソースを作成することはできません。

つまり、ROSA クラスターでは、spec.deployment.accessible_namespaces の以下の共通設定は許可されません。

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

検証エラーメッセージでは、制限されたすべての namespace の完全なリストが提供されます。

ROSA 用の Kiali リソースの例

apiVersion: kiali.io/v1alpha1
kind: Kiali
metadata:
  name: kiali
  namespace: istio-system
spec:
  auth:
    strategy: openshift
  deployment:
    accessible_namespaces:   #restricted setting for ROSA
      - istio-system
    image_pull_policy: ''
    ingress_enabled: true
    namespace: istio-system

1.8.6. 関連情報

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

1.8.7. 次のステップ

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

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

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

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

注記

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

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

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

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

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

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

前提条件

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

手順

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

    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.9.1.2. CLI からのメンバーロールの作成

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

前提条件

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

手順

  1. Red Hat OpenShift Service on AWS CLI にログインします。

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

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

    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.9.2. サービスメッシュからのプロジェクトの追加または削除

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

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

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

前提条件

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

手順

  1. Red Hat OpenShift Service on AWS 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.9.2.2. CLI を使用したメンバーロールからのプロジェクトの追加または削除

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

前提条件

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

手順

  1. Red Hat OpenShift Service on AWS 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.9.3. Bookinfo のサンプルアプリケーション

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

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

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

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

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

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

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

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

前提条件:

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

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

注記

このセクションのコマンドは、Service Mesh コントロールプレーンプロジェクトが istio-system であると仮定します。コントロールプレーンを別の namespace にインストールしている場合は、実行する前にそれぞれのコマンドを編集します。

手順

  1. cluster-admin 権限を持つユーザーとして Red Hat OpenShift Service on AWS 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. プロジェクト メニューをクリックし、Service Mesh コントロールプレーンの 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 が Service Mesh コントロールプレーンプロジェクトの名前です。

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

    $ oc get smmr -n istio-system -o wide

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

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

    $ oc apply -n bookinfo -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.3/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.3/samples/bookinfo/networking/bookinfo-gateway.yaml

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

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

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

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

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

手順

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

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

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

      $ oc apply -n bookinfo -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.3/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.9.3.3. Bookinfo インストールの検証

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

前提条件

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

CLI からの手順

  1. Red Hat OpenShift Service on AWS 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 の製品ページがデプロイされていることを確認します。

Kiali Web コンソールからの手順

  1. Kiali Web コンソールのアドレスを取得します。

    1. cluster-admin 権限を持つユーザーとして Red Hat OpenShift Service on AWS Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
    2. NetworkingRoutes に移動します。
    3. Routes ページで、Namespace メニューから Service Mesh コントロールプレーンプロジェクトを選択します (例: istio-system)。

      Location 列には、各ルートのリンク先アドレスが表示されます。

    4. Kiali の 場所 列のリンクをクリックします。
    5. Log In With OpenShift をクリックします。Kiali の 概要 画面には、各プロジェクトの namespace のタイルが表示されます。
  2. Kiali で、グラフ をクリックします。
  3. Namespace リストから bookinfo を選択し、Graph Type リストから App graph を選択します。
  4. Display メニューから Display idle nodes をクリックします。

    これにより、定義されているが要求を受信または送信していないノードが表示されます。アプリケーションが適切に定義されていることを確認できますが、要求トラフィックは報告されていません。

    Kiali displaying bookinfo application
    • 期間 メニューを使用して、期間を延ばして、古いトラフィックを取得できるようにします。
    • Refresh Rate メニューを使用して、トラフィックを頻繁に更新するか、まったく更新しないようにします。
  5. ServicesWorkloads または Istio Config をクリックして、bookinfo コンポーネントのリストビューを表示し、それらが正常であることを確認します。

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

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

前提条件

  • Red Hat OpenShift Service on AWS 4.1 以降がインストールされている。
  • Red Hat OpenShift Service Mesh 2.3 がインストールされている。
  • OpenShift CLI (oc) へのアクセスがある。
1.9.3.4.1. Bookinfo プロジェクトの削除

手順

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

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

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

手順

  1. Red Hat OpenShift Service on AWS Web コンソールにログインします。
  2. OperatorsInstalled Operators をクリックします。
  3. Project メニューをクリックし、一覧から istio-system を選択します。
  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 が Service Mesh コントロールプレーンプロジェクトの名前です。

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

1.9.4. 次のステップ

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

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

Bookinfo サンプルアプリケーションをインストールした場合は、アプリケーションがデプロイされ、インストール手順の一部としてサイドカーが注入されています。独自のプロジェクトとサービスを使用している場合は、Red Hat OpenShift Service on AWS にアプリケーションをデプロイします。

1.10.1. 前提条件

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

アプリケーションをデプロイする場合は、deployment オブジェクトで spec.template.metadata.annotations のアノテーション sidecar.istio.io/injecttrue に設定して、インジェクションをオプトインする必要があります。オプトインにより、サイドカーの挿入が Red Hat OpenShift Service on AWS エコシステム内の複数のフレームワークが使用する、ビルダー Pod などの他の Red Hat OpenShift Service on AWS 機能に干渉しないようにします。

前提条件

  • サービスメッシュの一部である namespace と、サイドカーの自動注入が必要なデプロイメントを特定しておく。

手順

  1. デプロイメントを見つけるには、oc get コマンドを使用します。

    $ oc get deployment -n <namespace>

    たとえば、bookinfo namespaxce の ratings-v1 マイクロサービスのデプロイメントファイルを表示するには、次のコマンドを使用して YAML 形式でリソースを表示します。

    oc get deployment -n bookinfo ratings-v1 -o yaml
  2. エディターでアプリケーションのデプロイメント設定の YAML ファイルを開きます。
  3. 次の例に示すように、spec.template.metadata.annotations.sidecar.istio/inject を Deployment YAML に追加し、sidecar.istio.io/injecttrue に設定します。

    bookinfo deployment-ratings-v1.yaml のスニペットの例

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: ratings-v1
      namespace: bookinfo
      labels:
        app: ratings
        version: v1
    spec:
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: 'true'

  4. デプロイメント設定ファイルを保存します。
  5. ファイルをアプリケーションが含まれるプロジェクトに追加し直します。

    $ oc apply -n <namespace> -f deployment.yaml

    この例では、bookinforatings-v1 アプリを含むプロジェクトの名前であり、deployment-ratings-v1.yaml は編集したファイルです。

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

    $ oc get deployment -n <namespace> <deploymentName> -o yaml

    以下に例を示します。

    $ oc get deployment -n bookinfo ratings-v1 -o yaml

1.10.3. サイドカーインジェクションの検証

Kiali コンソールは、アプリケーション、サービス、ワークロードにサイドカープロキシーがあるかどうかを検証するためのいくつかの方法を提供します。

図1.3 サイドカーバッジがない

グラフ ページには、次のグラフに サイドカー がないことを示すノードバッジが表示されます。

  • App graph
  • Versioned app graph
  • Workload graph

図1.4 サイドカーアイコンがない

Missing Sidecar icon

アプリケーション ページでは、サイドカーがない namespace 内のアプリケーションの 詳細 列に Missing Sidecar アイコンが表示されます。

ワークロード ページでは、サイドカーがない namespace 内のアプリケーションの 詳細 列に Missing Sidecar アイコンが表示されます。

サービス ページでは、サイドカーがない namespace 内のアプリケーションの 詳細 列に Missing Sidecar アイコンが表示されます。サービスのバージョンが複数ある場合は、サービスの詳細 ページを使用して、Missing Sidecar アイコンを表示します。

ワークロードの詳細 ページには、アプリケーションログとプロキシーログを表示および相互に関連付けることができる特別な統合 Logs タブがあります。Envoy ログは、アプリケーションワークロードのサイドカーインジェクションを検証する別の方法として表示できます。

ワークロードの詳細 ページには、Envoy プロキシーであるか、Envoy プロキシーが注入されたワークロード用の Envoy タブもあります。このタブには、クラスターリスナールートブートストラップ設定、および メトリック のサブタブなど、組み込みの Envoy ダッシュボードが表示されます。

Envoy アクセスログを有効にする方法については、トラブルシューティング のセクションを参照してください。

Envoy ログの表示については、Kiali コンソールでのログの表示 を参照してください。

1.10.4. アノテーションによるプロキシー環境変数の設定

Envoy サイドカープロキシーの設定は、ServiceMeshControlPlane によって管理されます。

デプロイメントの 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.10.5. サイドカープロキシーの更新

サイドカープロキシーの設定を更新するには、アプリケーション管理者はアプリケーション Pod を再起動する必要があります。

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

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

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

1.10.6. 次のステップ

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

1.11. Service Mesh のアップグレード

Red Hat OpenShift Service Mesh の最新機能にアクセスするには、最新バージョン 2.3 にアップグレードします。

1.11.1. バージョニングについて

Red Hat は、製品リリースにセマンティックバージョニングを使用します。セマンティックバージョニングは、X.Y.Z 形式の 3 つのコンポーネント番号になります。

  • X はメジャーバージョンを表します。メジャーリリースは通常、アーキテクチャーの変更、API の変更、スキーマの変更、および同様のメジャー更新など、何らかの最新の変更を意味します。
  • Y はマイナーバージョンを表します。マイナーリリースには、下位互換性を維持しながら、新しい機能が含まれています。
  • Z はパッチバージョン (z-stream リリースとも呼ばれます) を表します。パッチリリースは、Common Vulnerabilities and Exposures (CVE) に対処し、バグ修正をリリースするために使用されます。通常、新機能はパッチリリースの一部としてリリースされません。

1.11.1.1. バージョニングが Service Mesh のアップグレードに与える影響

実行する更新のバージョンによって、アップグレードプロセスが異なります。

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

1.11.1.2. Service Mesh のバージョンについて

ご使用のシステムにデプロイした Red Hat OpenShift Service Mesh のバージョンを理解するには、各コンポーネントのバージョンがどのように管理されるかを理解する必要があります。

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

    重要

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

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

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

Operator Lifecycle Manager (OLM) は Service Mesh コントロールプレーンのアップグレードをを管理しないため、SMCP を手動でアップグレードしない限り、Operator および ServiceMeshControlPlane (SMCP) のバージョン番号が一致しない可能性があります。

1.11.2. アップグレードに関する考慮事項

maistra.io/ ラベルまたはアノテーションは、ユーザーが作成したカスタムリソースで使用することはできません。これは、Red Hat OpenShift Service Mesh Operator によってリソースが生成され、管理される必要があることを示すためです。

警告

アップグレード時に、Operator はファイルの削除や置換などの変更を、リソースが Operator によって管理されることを示す以下のラベルまたはアノテーションを含むリソースに対して行います。

アップグレードする前に、ユーザーが作成したカスタムリソースで以下のラベルまたはアノテーションが含まれるか確認します。

  • maistra-istio-operator (Red Hat OpenShift Service Mesh) に設定された maistra.io/ および app.kubernetes.io/managed-by ラベル
  • kiali.io/ (Kiali)
  • jaegertracing.io/ (Red Hat OpenShift 分散トレースプラットフォーム)
  • logging.openshift.io/ (Red Hat Elasticsearch)

アップグレードの前に、ユーザーが作成したカスタムリソースで、それらが Operator によって管理されることを示すラベルまたはアノテーションを確認します。Operator によって管理されないカスタムリソースからラベルまたはアノテーションを削除します。

バージョン 2.0 にアップグレードする場合、Operator は SMCP と同じ namespace で、これらのラベルを持つリソースのみを削除します。

バージョン 2.1 にアップグレードする場合、Operator はすべての namespace で、これらのラベルを持つリソースを削除します。

1.11.2.1. アップグレードに影響する可能性のある既知の問題

アップグレードに影響する可能性がある既知の問題には、次のものがあります。

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

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

1.11.3. Operator のアップグレード

Service Mesh に最新のセキュリティー修正、バグ修正、およびソフトウェア更新プログラムを適用し続けるには、Operator を最新の状態に保つ必要があります。パッチの更新は、Operator をアップグレードすることで開始されます。

重要

Operator のバージョンは、お使いのサービスメッシュのバージョンを 判別しません。デプロイされた Service Mesh コントロールプレーンのバージョンによって、Service Mesh のバージョンが決まります。

Red Hat OpenShift Service Mesh Operator は Service Mesh コントロールプレーンの複数のバージョンをサポートするため、Red Hat OpenShift Service Mesh Operator を更新しても、デプロイされた ServiceMeshControlPlanespec.version 値は 更新されません。また、spec.version 値は 2 桁の数字 (2.2 など) であり、パッチの更新 (2.2.1 など) は SMCP バージョン値に反映されないことにも注意してください。

Operator Lifecycle Manager (OLM) は、クラスター内の Operator のインストール、アップグレード、ロールベースのアクセス制御 (RBAC) を制御します。OLM は、Red Hat OpenShift Service on AWS でデフォルトで実行されます。OLM は利用可能な Operator のクエリーやインストールされた Operator のアップグレードを実行します。

Operator をアップグレードするためにアクションを実行する必要があるかどうかは、インストール時に選択した設定によって異なります。各 Operator をインストールしたときに、Update Channel および Approval Strategy を選択しました。これら 2 つの設定の組み合わせによって、Operator が更新されるタイミングと方法が決まります。

表1.4 更新チャネルおよび承認ストラテジーのインタラクション

 バージョン付けされたチャネルstable または Preview チャネル

自動

そのバージョンのみのマイナーリリースおよびパッチリリースの Operator を自動的に更新します。次のメジャーバージョン (バージョン 2.0 から 3.0) には、自動的に自動的に更新されません。次のメジャーバージョンに更新するために必要な Operator サブスクリプションを手動で変更します。

すべてのメジャー、マイナーおよびパッチリリースについて、Operator を自動的に更新します。

手動

指定したバージョンのマイナーおよびパッチリリースに必要な手動更新。次のメジャーバージョンに更新するために必要な Operator サブスクリプションを手動で変更します。

すべてのメジャー、マイナー、およびパッチリリースについて、手動更新が必要になります。

Red Hat OpenShift Service Mesh Operator を更新すると、Operator Lifecycle Manager (OLM) は古い Operator Pod を削除し、新しい Pod を開始します。新しい Operator Pod が開始されると、調整プロセスは ServiceMeshControlPlane (SMCP) をチェックし、いずれかの Service Mesh コントロールプレーンコンポーネントの利用可能な更新されたコンテナーイメージがある場合は、それらの Service Mesh コントロールプレーン Pod を新しいコンテナーイメージを使用するものに置き換えます。

Kiali および Red Hat OpenShift 分散トレースプラットフォーム Operator をアップグレードすると、OLM 調整プロセスがクラスターをスキャンし、管理対象インスタンスを新しい Operator のバージョンにアップグレードします。たとえば、Red Hat OpenShift 分散トレースプラットフォーム Operator をバージョン 1.30.2 からバージョン 1.34.1 に更新する場合、Operator は分散トレースプラットフォームの実行中のインスタンスをスキャンし、それらも 1.34.1 にアップグレードします。

Red Hat OpenShift Service Mesh の特定のパッチバージョンにとどまるには、自動更新を無効にして、Operator のその特定のバージョンにとどまる必要があります。

1.11.4. コントロールプレーンのアップグレード

マイナーおよびメジャーリリースのコントロールプレーンを手動で更新する必要があります。コミュニティーの Istio プロジェクトはカナリアアップグレードを推奨していますが、Red Hat OpenShift Service Mesh はインプレースアップグレードのみをサポートしています。Red Hat OpenShift Service Mesh では、各マイナーリリースから次のマイナーリリースに順番にアップグレードする必要があります。たとえば、バージョン 2.0 からバージョン 2.1 にアップグレードしてから、バージョン 2.2 にアップグレードする必要があります。Red Hat OpenShift Service Mesh 2.0 から 2.2 に直接更新することはできません。

サービスメッシュコントロールプレーンをアップグレードすると、Operator が管理するすべてのリソース (ゲートウェイなど) もアップグレードされます。

複数のバージョンのコントロールプレーンを同じクラスターにデプロイできますが、Red Hat OpenShift Service Mesh は、サービスメッシュのカナリアアップグレードをサポートしていません。つまり、spec.version の値が異なるさまざまな SCMP リソースを使用できますが、同じメッシュを管理することはできません。

エクステンションの移行に関する詳細は、ServiceMeshExtension から WasmPlugin リソースへの移行 を参照してください。

1.11.4.1. バージョン 2.2 から 2.3 へのアップグレードの変更

Service Mesh コントロールプレーンをバージョン 2.2 から 2.3 にアップグレードすると、次の動作変更が導入されます。

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

1.11.4.2. バージョン 2.1 から 2.2 へのアップグレードに伴う変更

Service Mesh コントロールプレーンをバージョン 2.1 から 2.2 にアップグレードすると、次の動作変更が導入されます。

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

1.11.4.3. バージョン 2.0 から 2.1 へのアップグレードに伴う変更

Service Mesh コントロールプレーンをバージョン 2.0 から 2.1 にアップグレードすると、以下のアーキテクチャーおよび動作上の変更が導入されます。

アーキテクチャーの変更

Mixer は Red Hat OpenShift Service Mesh 2.1 で完全に削除されました。Red Hat OpenShift Service Mesh 2.0.x リリースから 2.1 へのアップグレードは、Mixer が有効な場合にはブロックされます。

v2.0 から v2.1 にアップグレード時に以下のメッセージが表示される場合、.spec.version フィールドを更新する前に、既存のコントロールプレーン仕様にすでに存在する Mixer タイプを Istiod タイプに更新します。

An error occurred
admission webhook smcp.validation.maistra.io denied the request: [support for policy.type "Mixer" and policy.Mixer options have been removed in v2.1, please use another alternative, support for telemetry.type "Mixer" and telemetry.Mixer options have been removed in v2.1, please use another alternative]”

以下に例を示します。

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
spec:
  policy:
    type: Istiod
  telemetry:
    type: Istiod
  version: v2.3

動作上の変更

  • AuthorizationPolicy の更新

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

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

1.11.4.4. Service Mesh コントロールプレーンのアップグレード

Red Hat OpenShift Service Mesh をアップグレードするには、Red Hat OpenShift Service Mesh ServiceMeshControlPlane v2 リソースのバージョンフィールドを更新する必要があります。次に、設定と適用が完了したら、アプリケーション Pod を再起動して各サイドカープロキシーとその設定を更新します。

前提条件

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

手順

  1. ServiceMeshControlPlane リソースが含まれるプロジェクトに切り替えます。この例では、istio-system が Service Mesh コントロールプレーンプロジェクトの名前です。

    $ oc project istio-system
  2. v2 ServiceMeshControlPlane リソース設定をチェックし、これが有効であることを確認します。

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

      $ oc get smcp -o yaml
      ヒント

      Service Mesh コントロールプレーン設定をバックアップします。

  3. .spec.version フィールドを更新し、設定を適用します。

    以下に例を示します。

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    metadata:
      name: basic
    spec:
      version: v2.3

    または、コマンドラインの代わりに Web コンソールを使用して Service Mesh コントロールプレーンを編集することもできます。Red Hat OpenShift Service on AWS Web コンソールで Project をクリックし、入力したプロジェクト名を選択します。

    1. OperatorsInstalled Operators をクリックします。
    2. ServiceMeshControlPlane インスタンスを見つけます。
    3. YAML view を選択し、直前の例のように YAML ファイルのテキストを更新します。
    4. Save をクリックします。

1.11.4.5. Red Hat OpenShift Service Mesh のバージョン 1.1 からバージョン 2.0 への移行

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

前提条件

  • Red Hat OpenShift Service Mesh 2.0 にアップグレードする前に Red Hat OpenShift Service on AWS 4.7 にアップグレードする必要がある。
  • Red Hat OpenShift Service Mesh のバージョン 2.0 Operator が必要である。自動 アップグレードパスを選択した場合、Operator は最新情報を自動的にダウンロードします。ただし、Red Hat OpenShift Service Mesh バージョン 2.0 で機能を使用するために実行する必要のある手順があります。
1.11.4.5.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. Service Mesh コントロールプレーン設定をバックアップします。ServiceMeshControlPlane リソースが含まれるプロジェクトに切り替えます。この例では、istio-system が Service Mesh コントロールプレーンプロジェクトの名前です。

    $ 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. プロジェクトを作成します。Red Hat OpenShift Service on AWS コンソールの 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

    または、コンソールを使用して Service Mesh コントロールプレーンを作成することもできます。Red Hat OpenShift Service on AWS 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.11.4.5.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.11.4.5.2.1. アーキテクチャーの変更

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

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

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

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

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

  • 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 Service Mesh コントロールプレーンに移行する前にオーバーライドを削除する必要があります。ステータスポートを 0 に設定すると、readiness チェックを依然として無効にできます。
  • Kubernetes シークレットリソースは、サイドカーのクライアント証明書を配信するために使用されなくなりました。証明書は Istiod の SDS サービスを介して配信されるようになりました。マウントされたシークレットに依存している場合、それらは v2.0 Service Mesh コントロールプレーンのワークロードで利用不可になります。
1.11.4.5.2.3. 動作上の変更

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

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

Policy (authentication.istio.io/v1alpha1)

Policy リソースは、v2.0 Service Mesh コントロールプレーン、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 で Service Mesh コントロールプレーンに自動的に設定されています。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)

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

1.11.4.5.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.11.4.5.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.11.4.5.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.11.4.5.3. 設定レシピ

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

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

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

1.11.4.5.3.2. カスタム署名キー

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

1.11.4.5.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 リソースが存在する場合、Service Mesh コントロールプレーンは既存のインストールを使用するように設定されます。既存の Jaeger リソースを使用して Jaeger インストールを完全にカスタマイズします。

1.11.4.5.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 リソースが存在する場合、Service Mesh コントロールプレーンはコントロールプレーンで使用するように Kiali リソースを設定します。accessible_namespaces 一覧や Grafana、Prometheus、およびトレースのエンドポイントなどの Kiali リソースの一部のフィールドは上書きされます。既存のリソースを使用して Kiali インストールを完全にカスタマイズします。

1.11.4.5.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 リソースを Service Mesh コントロールプレーンの設定に指定することでサポートされます。

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 リソースを Service Mesh コントロールプレーン設定に指定してサポートされます。

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.11.4.5.4. アプリケーションとワークロードを移行するための次の手順

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

1.11.5. データプレーンのアップグレード

コントロールプレーンをアップグレードした後も、データプレーンは引き続き機能します。ただし、Envoy プロキシーに更新を適用し、プロキシー設定に変更を適用するには、アプリケーション Pod とワークロードを再起動する必要があります。

1.11.5.1. アプリケーションおよびワークロードの更新

移行を完了するには、メッシュ内のすべてのアプリケーション Pod を再起動して、Envoy サイドカープロキシーおよびそれらの設定をアップグレードします。

デプロイメントのローリング更新を実行するには、以下のコマンドを使用します。

$ oc rollout restart <deployment>

メッシュを設定するすべてのアプリケーションに対してローリング更新を実行する必要があります。

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

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

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

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

管理者は Service Mesh コントロールプレーンプロジェクトで mesh user ロールバインディングを変更し、アクセスが付与されたユーザーおよびグループを指定できます。ServiceMeshMember は、プロジェクトを、参照する Service Mesh コントロールプレーンプロジェクト内の 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.12.2. Service Mesh コントロールプレーンプロファイルの作成

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

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

1.12.2.1. ConfigMap の作成

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

前提条件

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

手順

  1. cluster-admin として Red Hat OpenShift Service on AWS 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. ServiceMeshControlPlanetemplate パラメーターを使用して 1 つ以上のテンプレートを指定できます。

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

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

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

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

1.13. セキュリティー

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

作業を開始する前に

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

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

1.13.1. Mutual Transport Layer Security (mTLS) について

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

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

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

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

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

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

Red Hat OpenShift Service on AWS Web コンソールを使用して mTLS を有効にすることもできます。

手順

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

宛先ルールを作成し、Service Mesh がメッシュ内の他のサービスに要求を送信する際に 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.13.1.1.3. 最小および最大のプロトコルバージョンの設定

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

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

表1.5 有効な値

説明

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 メニューをクリックし、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: 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.13.1.2. Kiali による暗号化の検証

Kiali コンソールは、アプリケーション、サービス、ワークロードが mTLS 暗号化を有効にしているかどうかを検証するためのいくつかの方法を提供します。

図1.5 マストヘッドアイコン メッシュワイド mTLS が有効

mTLS enabled

サービスメッシュ全体で厳密に mTLS が有効化されている場合、Kiali はマストヘッドの右側にロックアイコンを表示します。これは、メッシュ内のすべての通信に mTLS が使用されていることを意味します。

図1.6 マストヘッドアイコン メッシュワイド mTLS が一部有効

mTLS partially enabled

メッシュが PERMISSIVE モードに設定されているか、メッシュ全体の mTLS 設定にエラーが発生している場合、Kiali は中空ロックアイコンを表示します。

図1.7 セキュリティーバッジ

Security badge

Graph ページには、mTLS が有効であることを示すために、グラフの端に Security バッジを表示するオプションがあります。グラフにセキュリティーバッジを表示するには、Display メニューの Show BadgesSecurity チェックボックスをオンにします。エッジにロックアイコンが表示されている場合、mTLS が有効なリクエストが少なくとも 1 つ存在することを意味します。mTLS と non-TLS の両方のリクエストがある場合、サイドパネルには mTLS を使用するリクエストのパーセンテージが表示されます。

Applications Detail Overview ページでは、mTLS が有効なリクエストが 1 つ以上存在するグラフの端に Security アイコンが表示されます。

Workloads Detail Overview ページでは、mTLS が有効なリクエストが 1 つ以上存在するグラフの端に Security アイコンが表示されます。

Services Detail Overview ページでは、mTLS が有効なリクエストが 1 つ以上存在するグラフの端に Security アイコンが表示されます。また、Kiali では、mTLS を設定したポートの横の Network セクションにロックアイコンが表示されることに注意してください。

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

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

RBAC を設定するには、アクセスを設定する namespace で AuthorizationPolicy リソースを作成します。メッシュ全体のアクセスを設定する場合は、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: 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.13.2.1. プロジェクト内通信の設定

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

1.13.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.13.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.13.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.13.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.13.3. 暗号化スイートおよび ECDH 曲線の設定

暗号化スイートおよび ECDH 曲線 (Elliptic-curve Diffie–Hellman) は、サービスメッシュのセキュリティーを保護するのに役立ちます。暗号化スイートのコンマ区切りの一覧を spec.security.controlplane.tls.cipherSuites を使用して定義し、 ECDH 曲線を ServiceMeshControlPlane リソースの spec.security.controlplane.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.13.4. 外部認証局キーおよび証明書の追加

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

前提条件

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

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

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

  1. Maistra リポジトリー からサンプル証明書をローカルに保存し、< path> を証明書へのパスに置き換えます。
  2. 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
  3. ServiceMeshControlPlane リソースで、spec.security.dataPlane.mtls truetrue に設定し、以下の例のように certificateAuthority フィールドを設定します。デフォルトの rootCADir/etc/cacerts です。キーおよび証明書がデフォルトの場所にマウントされている場合は、privateKey を設定する必要はありません。Service Mesh は、secret-mount ファイルから証明書およびキーを読み取ります。

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    spec:
      security:
        dataPlane:
          mtls: true
        certificateAuthority:
          type: Istiod
          istiod:
            type: PrivateKey
            privateKey:
              rootCADir: /etc/cacerts
  4. cacert シークレットを作成/変更/削除した後に、変更を有効にするために、Service Mesh コントロールプレーンの istiodgateway Pod を再起動する必要があります。以下のコマンドで Pod を再起動します。

    $ oc -n istio-system delete pods -l 'app in (istiod,istio-ingressgateway, istio-egressgateway)'

    Operator は、Pod を削除した後、自動的に再作成します。

  5. bookinfo アプリケーションの Pod を再起動し、sidecar プロキシーがシークレットの変更を取り込むようにします。以下のコマンドで Pod を再起動します。

    $ oc -n bookinfo delete pods --all

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

    pod "details-v1-6cd699df8c-j54nh" deleted
    pod "productpage-v1-5ddcb4b84f-mtmf2" deleted
    pod "ratings-v1-bdbcc68bc-kmng4" deleted
    pod "reviews-v1-754ddd7b6f-lqhsv" deleted
    pod "reviews-v2-675679877f-q67r2" deleted
    pod "reviews-v3-79d7549c7-c2gjs" deleted
  6. 以下のコマンドで、Pod が作成され、準備ができたことを確認します。

    $ oc get pods -n bookinfo

1.13.4.2. 証明書の確認

Bookinfo サンプルアプリケーションを使用して、ワークロード証明書が CA に差し込まれた証明書によって署名されていることを確認します。そのためには、マシンに openssl がインストールされている必要があります。

  1. bookinfo ワークロードから証明書を抽出するには、以下のコマンドを使用します。

    $ sleep 60
    $ oc -n bookinfo exec "$(oc -n bookinfo get pod -l app=productpage -o jsonpath={.items..metadata.name})" -c istio-proxy -- openssl s_client -showcerts -connect details:9080 > bookinfo-proxy-cert.txt
    $ sed -n '/-----BEGIN CERTIFICATE-----/{:start /-----END CERTIFICATE-----/!{N;b start};/.*/p}' bookinfo-proxy-cert.txt > certs.pem
    $ awk 'BEGIN {counter=0;} /BEGIN CERT/{counter++} { print > "proxy-cert-" counter ".pem"}' < certs.pem

    コマンドを実行すると、作業ディレクトリーに proxy-cert-1.pemproxy-cert-2.pemproxy-cert-3.pem の 3 つのファイルが作成されるはずです。

  2. ルート証明書が管理者が指定したものと同じであることを確認します。<path> を証明書へのパスに置き換えます。

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

    ターミナルウィンドウで次の構文を実行します。

    $ openssl x509 -in ./proxy-cert-3.pem -text -noout > /tmp/pod-root-cert.crt.txt

    ターミナルウィンドウで以下の構文を実行して、証明書を比較します。

    $ diff -s /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt

    以下のような結果が表示されるはずです: Files /tmp/root-cert.crt.txt and /tmp/pod-root-cert.crt.txt are identical

  3. CA 証明書が管理者が指定したものと同じであることを確認します。<path> を証明書へのパスに置き換えます。

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

    ターミナルウィンドウで次の構文を実行します。

    $ openssl x509 -in ./proxy-cert-2.pem -text -noout > /tmp/pod-cert-chain-ca.crt.txt

    ターミナルウィンドウで以下の構文を実行して、証明書を比較します。

    $ diff -s /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txt

    以下のような結果が表示されるはずです: Files /tmp/ca-cert.crt.txt and /tmp/pod-cert-chain-ca.crt.txt are identical.

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

    $ openssl verify -CAfile <(cat <path>/ca-cert.pem <path>/root-cert.pem) ./proxy-cert-1.pem

    以下のような出力が表示されるはずです: ./proxy-cert-1.pem: OK

1.13.4.3. 証明書の削除

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

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

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

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

1.14. Service Mesh でのトラフィックの管理

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

1.14.1. ゲートウェイの使用

ゲートウェイを使用してメッシュの受信トラフィックおよび送信トラフィックを管理することで、メッシュに入るか、またはメッシュを出るトラフィックを指定できます。ゲートウェイ設定は、サービスワークロードと共に実行されるサイドカー 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 ゲートウェイを使用すると、メッシュからのトラフィック専用の終了ノードを設定できます。これにより、サービスメッシュにセキュリティー制御を追加することで、外部ネットワークにアクセスできるサービスを制限できます。また、ゲートウェイを使用して完全に内部のプロキシーを設定することもできます。

ゲートウェイの例

ゲートウェイリソースは、着信または発信 HTTP/TCP 接続を受信するメッシュのエッジで動作するロードバランサーを表します。この仕様は、公開する必要のあるポートのセット、使用するプロトコルのタイプ、ロードバランサー用の SNI 設定などについて記述します。

以下の例は、外部 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.14.1.1. ゲートウェイインジェクションの有効化

ゲートウェイ設定は、サービスワークロードと共に実行されるサイドカー Envoy プロキシーではなく、メッシュのエッジで実行されているスタンドアロンの Envoy プロキシーに適用されます。ゲートウェイは Envoy プロキシーであるため、サイドカーコンテナーの挿入方法と同様に、ゲートウェイを自動的に挿入するようにサービスメッシュを設定できます。

ゲートウェイの自動挿入を使用すると、ServiceMeshControlPlane リソースから独立したゲートウェイをデプロイおよび管理し、ユーザーアプリケーションでゲートウェイを管理できます。ゲートウェイデプロイメントに auto-injection を使用すると、開発者はゲートウェイのデプロイメントを完全に制御でき、操作が簡素化されます。新規アップグレードが利用可能になると、または設定を変更した場合は、ゲートウェイ Pod を再起動してそれらを更新します。これを実行すると、ゲートウェイのデプロイメントが操作サイドカーと同じように動作します。

注記

インジェクションは ServiceMeshControlPlane namespace についてデフォルトで無効にされます(例: istio-system namespace)。セキュリティーのベストプラクティスとして、コントロールプレーンとは異なる namespace にゲートウェイをデプロイします。

1.14.1.2. ゲートウェイの自動インジェクションのデプロイ

ゲートウェイのデプロイ時に、挿入ラベルまたはアノテーションをゲートウェイ デプロイメント オブジェクトに追加して挿入をオプトインする必要があります。以下の ConfigMap オブジェクトの例は、自動挿入を使用してゲートウェイをデプロイします。

前提条件

  • namespace は、ServiceMeshMemberRoll で定義するか、ServiceMeshMember リソースを作成してメッシュのメンバーである必要があります。

アノテーションを使用したデプロイメントの例

  apiVersion: v1
  kind: Service
  metadata:
    name: istio-ingressgateway
    namespace: istio-ingress
  spec:
    type: LoadBalancer
    selector:
      istio: ingressgateway
    ports:
    - port: 80
      name: http
    - port: 443
      name: https
  ---
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: istio-ingressgateway
    namespace: istio-ingress
  spec:
    selector:
      matchLabels:
        istio: ingressgateway
    template:
      metadata:
        annotations:
          inject.istio.io/templates: gateway 1
        labels:
          istio: ingressgateway 2
          sidecar.istio.io/inject: "true" 3
      spec:
        containers:
        - name: istio-proxy
          image: auto 4
  ---
  apiVersion: rbac.authorization.k8s.io/v1 5
  kind: Role
  metadata:
    name: istio-ingressgateway-sds
    namespace: istio-ingress
  rules:
    - apiGroups: [""]
      resources: ["secrets"]
      verbs: ["get", "watch", "list"]
  ---
  apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
   name: istio-ingressgateway-sds
   namespace: istio-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: istio-ingressgateway-sds
subjects:
- kind: ServiceAccount
  name: default

1
デフォルトのサイドカーテンプレートではなく、ゲートウェイインジェクションテンプレートを選択します。
2
ゲートウェイに一意のラベルを設定します。この設定は、ゲートウェイがこのワークロードを選択できるようにするために必要です。
3
ゲートウェイインジェクションを有効にします。リビジョン化されたコントロールプレーンに接続する場合は、を istio.io/rev: revision-name に置き換えます。
4
イメージは Pod が起動するたびに自動的に更新されます。
5
TLS の認証情報の読み取りを許可するようにロールを設定します。

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

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

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

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

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

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

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

EXTERNAL-IP の値が <none> または永続的に <pending> の場合、環境は Ingress ゲートウェイの外部ロードバランサーを提供しません。

1.14.1.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.14.1.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.14.1.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 をこれにコピーします。

      仮想サービスの例

      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 が Service Mesh コントロールプレーンプロジェクトの名前です。

      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.14.2. 自動ルートについて

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

1.14.2.1. サブドメインのあるルート

Red Hat OpenShift Service Mesh はサブドメインを使用してルートを作成しますが、Red Hat OpenShift Service on AWS はそのサブドメインを有効にするように設定する必要があります。*.domain.com などのサブドメインはサポートされますが、デフォルトでは設定されません。ワイルドカードホスト Gateway を設定する前に、Red Hat OpenShift Service on AWS ワイルドカードポリシーを設定します。

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

Gateway リソースは、次の OpenShift ルートを作成します。ルートが以下のコマンドを使用して作成されていることを確認できます。この例では、istio-system が Service Mesh コントロールプレーンプロジェクトの名前です。

$ 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.14.2.3. ルートラベルとアノテーション

OpenShift ルートでは、特定のラベルまたはアノテーションが必要になる場合があります。

このユースケースおよび他のユースケースでは、Red Hat OpenShift Service Mesh は (kubectl.kubernetes.io で始まるものを除く) Istio Gateway リソースにあるすべてのラベルとアノテーションを管理対象の OpenShift Route リソースにコピーします。

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

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

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

1.14.2.4.1. 特定のケースでの自動ルート作成の無効化

特定の Istio ゲートウェイの OpenShift ルートの自動管理を無効にする場合は、アノテーション maistra.io/manageRoute: false をゲートウェイのメタデータ定義に追加する必要があります。Red Hat OpenShift Service Mesh は、他の Istio ゲートウェイの自動管理を維持しつつ、このアノテーションの付いた Istio ゲートウェイを無視します。

1.14.2.4.2. すべてのケースでの自動ルート作成の無効化

メッシュ内のすべてのゲートウェイの OpenShift ルートの自動管理を無効にできます。

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

apiVersion: maistra.io/v1alpha1
kind:
metadata:
  namespace: istio-system
spec:
  gateways:
    openshiftRoute:
      enabled: false

1.14.3. サービスエントリーについて

サービスエントリーは、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.14.4. VirtualServices の使用

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

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

1.14.4.1. VirtualServices の設定

要求は、仮想サービスを使用してサービスメッシュ内のサービスにルーティングされます。それぞれの仮想サービスは、順番に評価される一連のルーティングルールで設定されます。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.14.4.2. VirtualService 設定リファレンス

パラメーター説明
spec:
  hosts:

hosts フィールドには、ルーティングルールが適用される仮想サービスのユーザーの宛先アドレスが一覧表示されます。これは、サービスへの要求送信に使用するアドレスです。仮想サービスのホスト名は、IP アドレス、DNS 名または完全修飾ドメイン名に解決される短縮名になります。

spec:
  http:
  - match:

http セクションには、ホストフィールドで指定された宛先に送信される HTTP/1.1、HTTP2、および gRPC トラフィックのルーティングの一致条件とアクションを記述する仮想サービスのルーティングルールが含まれます。ルーティングルールは、トラフィックの宛先と、指定の一致条件で設定されます。この例の最初のルーティングルールには条件があり、match フィールドで始まります。この例では、このルーティングはユーザー jason からの要求すべてに適用されます。headersend-user、および exact フィールドを追加し、適切な要求を選択します。

spec:
  http:
  - match:
    - destination:

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

1.14.5. 宛先ルールについて

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

デフォルトで、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.14.6. ネットワークポリシーについて

Red Hat OpenShift Service Mesh は、Service Mesh コントロールプレーンおよびアプリケーションネームスペースで多数の NetworkPolicies リソースを自動的に作成し、管理します。これは、アプリケーションとコントロールプレーンが相互に通信できるようにするために使用されます。

たとえば、Red Hat OpenShift Service on AWS クラスターが SDN プラグインを使用するように設定されている場合、Red Hat OpenShift Service Mesh は各メンバープロジェクトで NetworkPolicy リソースを作成します。これにより、他のメッシュメンバーおよびコントロールプレーンからのメッシュ内のすべての Pod に対する ingress が有効になります。また、これにより Ingress がメンバープロジェクトのみに制限されます。メンバー以外のプロジェクトの Ingress が必要な場合は、NetworkPolicy を作成してそのトラフィックを許可する必要があります。Service Mesh から namespace を削除する場合、この NetworkPolicy リソースはプロジェクトから削除されます。

1.14.6.1. NetworkPolicy 自動作成の無効化

NetworkPolicy リソースの自動作成および管理を無効にする場合 (例: 会社のセキュリティーポリシーを適用したり、メッシュ内の Pod への直接アクセスを許可する場合など) はこれを実行できます。ServiceMeshControlPlane を編集し、spec.security.manageNetworkPolicyfalse に設定できます。

注記

spec.security.manageNetworkPolicy を無効にすると、Red Hat OpenShift Service Mesh は、NetworkPolicy オブジェクトをひとつも作成しません。システム管理者は、ネットワークを管理し、この原因の問題を修正します。

前提条件

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

手順

  1. Red Hat OpenShift Service on AWS Web コンソールで、OperatorsInstalled Operators をクリックします。
  2. Project メニューから、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. Red Hat OpenShift Service Mesh Operator をクリックします。Istio Service Mesh Control Plane 列で、ServiceMeshControlPlane の名前 (basic-install など) をクリックします。
  4. Create ServiceMeshControlPlane Details ページで、YAML をクリックして設定を変更します。
  5. 以下の例のように、ServiceMeshControlPlane フィールド spec.security.manageNetworkPolicyfalse に設定します。

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    spec:
      security:
          manageNetworkPolicy: false
  6. Save をクリックします。

1.14.7. トラフィック管理のサイドカーの設定

デフォルトで、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.8. ルーティングチュートリアル

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

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

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

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

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

前提条件:

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

1.14.8.2. 仮想サービスの適用

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

手順

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

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

    $ oc get virtualservices -o yaml

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

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

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

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 サイトを開きます。

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

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

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

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

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

手順

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

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

    $ oc get virtualservice reviews -o yaml
  3. Bookinfo アプリケーションの /productpage で、パスワードなしでユーザー jason としてログインします。
  4. ブラウザーを更新します。各レビューの横に星評価が表示されます。
  5. 別のユーザーとしてログインします (任意の名前を指定します)。ブラウザーを更新します。これで星がなくなりました。Jason 以外のすべてのユーザーのトラフィックが reviews:v1 にルーティングされるようになりました。

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

1.15. メトリックス、ログ、およびトレース

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

1.15.1. コンソールアドレスの検出

Red Hat OpenShift Service Mesh は、サービスメッシュデータを表示する以下のコンソールを提供します。

  • Kiali コンソール: Kiali は Red Hat OpenShift Service Mesh の管理コンソールです。
  • Jaeger コンソール: Jaeger は Red Hat OpenShift 分散トレースの管理コンソールです。
  • Grafana コンソール: Grafana は、Istio データの高度なクエリーとメトリックス分析およびダッシュボードをメッシュ管理者に提供します。任意で、Grafana を使用してサービスメッシュメトリクスを分析できます。
  • Prometheus コンソール: Red Hat OpenShift Service Mesh は Prometheus を使用してサービスからのテレメトリー情報を保存します。

Service Mesh コントロールプレーンのインストール時に、インストールされた各コンポーネントのルートを自動的に生成します。ルートアドレスを作成したら、Kiali、Jaeger、Prometheus、または Grafana コンソールにアクセスして、サービスメッシュデータを表示および管理できます。

前提条件

  • コンポーネントが有効で、インストールされていること。たとえば、分散トレースをインストールしていない場合、Jaeger コンソールにはアクセスできません。

OpenShift コンソールからの手順

  1. cluster-admin 権限を持つユーザーとして Red Hat OpenShift Service on AWS Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
  2. NetworkingRoutes に移動します。
  3. Routes ページで、Namespace メニューから Service Mesh コントロールプレーンプロジェクトを選択します (例: istio-system)。

    Location 列には、各ルートのリンク先アドレスが表示されます。

  4. 必要な場合は、フィルターを使用して、アクセスするルートを持つコンポーネントコンソールを検索します。ルートの Location をクリックしてコンソールを起動します。
  5. Log In With OpenShift をクリックします。

CLI からの手順

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

    $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
  2. Service Mesh コントロールプレーンプロジェクトに切り替えます。この例では、istio-system は Service Mesh コントロールプレーンプロジェクトです。以下のコマンドを実行します。

    $ oc project istio-system
  3. 各種 Red Hat OpenShift Service Mesh コンソールのルートを取得するには、以下のコマンドを実行します。

    $ oc get routes

    このコマンドは、Kiali、Jaeger、Prometheus、および Grafana Web コンソールの URL と、サービスメッシュ内の他のルートの URL を返します。以下のような出力が表示されるはずです。

    NAME                    HOST/PORT                         SERVICES              PORT    TERMINATION
    bookinfo-gateway        bookinfo-gateway-yourcompany.com  istio-ingressgateway          http2
    grafana                 grafana-yourcompany.com           grafana               <all>   reencrypt/Redirect
    istio-ingressgateway    istio-ingress-yourcompany.com     istio-ingressgateway  8080
    jaeger                  jaeger-yourcompany.com            jaeger-query          <all>   reencrypt
    kiali                   kiali-yourcompany.com             kiali                 20001   reencrypt/Redirect
    prometheus              prometheus-yourcompany.com        prometheus            <all>   reencrypt/Redirect
  4. HOST/PORT コラムからアクセスするコンソールの URL をブラウザーにコピーして、コンソールを開きます。
  5. Log In With OpenShift をクリックします。

1.15.2. Kiali コンソールへのアクセス

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

Kiali コンソールにアクセスするには、Red Hat OpenShift Service Mesh がインストールされ、Kiali がインストールおよび設定されている必要があります。

インストールプロセスにより、Kiali コンソールにアクセスするためのルートが作成されます。

Kiali コンソールの URL が分かっている場合は、直接アクセスできます。URL が分からない場合は、以下の指示を使用します。

管理者の手順

  1. 管理者ロールで Red Hat OpenShift Service on AWS Web コンソールにログインします。
  2. HomeProjects をクリックします。
  3. Projects ページで、必要に応じてフィルターを使用してプロジェクトの名前を検索します。
  4. プロジェクトの名前をクリックします (例: bookinfo)。
  5. Project details ページの Launcher セクションで、Kiali リンクをクリックします。
  6. Red Hat OpenShift Service on AWS コンソールにアクセスするときに使用するものと同じユーザー名とパスワードを使用して Kiali コンソールにログインします。

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

    コンソールのインストールを検証中で、namespace がまだメッシュに追加されていない場合、istio-system 以外のデータは表示されない可能性があります。

開発者の手順

  1. 開発者ロールで Red Hat OpenShift Service on AWS Web コンソールにログインします。
  2. Project をクリックします。
  3. 必要に応じて、Project Details ページで、フィルターを使用してプロジェクトの名前を検索します。
  4. プロジェクトの名前をクリックします (例: bookinfo)。
  5. Project ページの Launcher セクションで、Kiali リンクをクリックします。
  6. Log In With OpenShift をクリックします。

1.15.3. Kiali コンソールでのサービスメッシュデータの表示

Kiali グラフは、メッシュトラフィックの強力な視覚化を提供します。トポロジーは、リアルタイムの要求トラフィックを Istio 設定情報と組み合わせ、サービスメッシュの動作に関する洞察を即座に得て、問題を迅速に特定できるようにします。複数のグラフタイプを使用すると、トラフィックを高レベルのサービストポロジー、低レベルのワークロードトポロジー、またはアプリケーションレベルのトポロジーとして視覚化できます。

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

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

グラフノードは、さまざまな情報で装飾され、仮想サービスやサービスエントリーなどのさまざまなルートルーティングオプションや、フォールトインジェクションやサーキットブレーカーなどの特別な設定を指定します。mTLS の問題、レイテンシーの問題、エラートラフィックなどを特定できます。グラフは高度な設定が可能で、トラフィックのアニメーションを表示でき、強力な検索機能や非表示機能があります。

Legend ボタンをクリックして、グラフに表示されるシェイプ、色、矢印、バッジに関する情報を表示します。

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

1.15.3.1. Kiali でのグラフレイアウトの変更

Kiali グラフのレイアウトは、アプリケーションのアーキテクチャーや表示データによって異なることがあります。たとえば、グラフノードの数およびそのインタラクションにより、Kiali グラフのレンダリング方法を判別できます。すべての状況に適した単一のレイアウトを作成することは不可能であるため、Kiali は複数の異なるレイアウトの選択肢を提供します。

前提条件

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

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

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

手順

  1. Kiali コンソールを起動します。
  2. Log In With OpenShift をクリックします。
  3. Kiali コンソールで、Graph をクリックし、namespace グラフを表示します。
  4. Namespace メニューから、アプリケーション namespace (例: bookinfo) を選択します。
  5. 別のグラフレイアウトを選択するには、以下のいずれか、または両方を行います。

    • グラフの上部にあるメニューから、異なるグラフデータグループを選択します。

      • App graph
      • Service graph
      • Versioned App graph (デフォルト)
      • Workload graph
    • グラフの下部にある Legend から別のグラフレイアウトを選択します。

      • Layout default dagre
      • Layout 1 cose-bilkent
      • Layout 2 cola

1.15.3.2. Kiali コンソールでのログの表示

Kiali コンソールでワークロードのログを表示することができます。Workload Details ページには Logs タブが含まれており、アプリケーションとプロキシーログの両方を表示する統一されたログビューが表示されます。Kiali でログ表示を更新する頻度を選択できます。

Kiali に表示されるログのロギングレベルを変更するには、ワークロードまたはプロキシーのロギング設定を変更します。

前提条件

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

手順

  1. Kiali コンソールを起動します。
  2. Log In With OpenShift をクリックします。

    Kiali Overview ページには、閲覧権限を持つメッシュに追加された namespace が表示されます。

  3. Workloads をクリックします。
  4. Workloads ページで、Namespace メニューからプロジェクトを選択します。
  5. 必要な場合は、フィルターを使用して、表示するログがあるワークロードを見つけます。ワークロードの名前をクリックします。たとえば、ratings-v1 をクリックします。
  6. Workload Details ページで、Logs タブをクリックしてワークロードのログを表示します。
ヒント

ログエントリーが表示されない場合は、時間範囲または更新間隔のいずれかを調整する必要がある場合があります。

1.15.3.3. Kiali コンソールでのメトリックスの表示

Kiali コンソールで、アプリケーション、ワークロード、サービスのインバウンドおよびアウトバウンドメトリックスを表示できます。詳細ページには、以下のタブが含まれます。

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

これらのタブには、関連するアプリケーション、ワークロード、またはサービスレベルに合わせて調整された事前定義済みのメトリックスダッシュボードが表示されます。アプリケーションおよびワークロードの詳細ビューには、ボリューム、期間、サイズ、TCP トラフィックなどの要求および応答メトリックスが表示されます。サービスの詳細ビューには、インバウンドトラフィックの要求および応答メトリックスのみ表示されます。

Kiali では、チャート化されたディメンションを選択してチャートをカスタマイズできます。Kiali は、ソースまたは宛先プロキシーメトリックスによって報告されるメトリックスを表示することもできます。また、トラブルシューティングのために、Kiali はメトリックスでトレースをオーバーレイできます。

前提条件

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

手順

  1. Kiali コンソールを起動します。
  2. Log In With OpenShift をクリックします。

    Kiali Overview ページには、閲覧権限を持つメッシュに追加された namespace が表示されます。

  3. ApplicationsWorkloads、または Services のいずれかをクリックします。
  4. ApplicationsWorkloads、または Services ページで、Namespace メニューからプロジェクトを選択します。
  5. 必要な場合は、フィルターを使用して、ログを表示するアプリケーション、ワークロード、またはサービスを検索します。名前をクリックします。
  6. Application DetailWorkload Details、または Service Details ページで、Inbound Metrics または Outbound Metrics タブをクリックしてメトリックスを表示します。

1.15.4. 分散トレース

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

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

1.15.4.1. 既存の分散トレースインスタンスの接続

Red Hat OpenShift Service on AWS に既存の Red Hat OpenShift 分散トレースプラットフォームインスタンスがある場合、分散トレースにそのインスタンスを使用するように ServiceMeshControlPlane リソースを設定できます。

前提条件

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

手順

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

    1. YAML タブをクリックします。
    2. 分散トレースプラットフォームインスタンスの名前を ServiceMeshControlPlane リソースの spec.addons.jaeger.name に追加します。以下の例では、str-tracing-production は分散トレースプラットフォームインスタンスの名前です。

      分散トレースの設定例

      spec:
        addons:
          jaeger:
            name: distr-tracing-production

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

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

トレースは、サービスメッシュ内のサービス間の実行パスです。トレースは、1 つ以上のスパンで設定されます。スパンは、名前、開始時間、および期間を持つ作業の論理単位です。サンプリングレートは、トレースが永続化される頻度を決定します。

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

Envoy プロキシーサンプリングレートを、0.01% の増分を表すスケーリングされた整数として設定します。

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

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

Envoy プロキシーサンプリングレートは、Service Mesh で利用可能なアプリケーションに適用され、Envoy プロキシーを使用します。このサンプリングレートは、Envoy プロキシーが収集および追跡するデータ量を決定します。

Jaeger リモートサンプリングレートは、Service Mesh の外部にあるアプリケーションに適用され、データベースなどの Envoy プロキシーを使用しません。このサンプリングレートは、分散トレースシステムが収集および保存するデータ量を決定します。

手順

  1. Red Hat OpenShift Service on AWS 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.15.5. Jaeger コンソールへのアクセス

Jaeger コンソールにアクセスするには、Red Hat OpenShift Service Mesh がインストールされ、Red Hat OpenShift 分散トレースプラットフォームがインストールおよび設定されている必要があります。

インストールプロセスにより、Jaeger コンソールにアクセスするためのルートが作成されます。

Jaeger コンソールの URL が分かっている場合は、これに直接アクセスできます。URL が分からない場合は、以下の指示を使用します。

OpenShift コンソールからの手順

  1. cluster-admin 権限を持つユーザーとして Red Hat OpenShift Service on AWS Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
  2. NetworkingRoutes に移動します。
  3. Routes ページで、Namespace メニューから Service Mesh コントロールプレーンプロジェクトを選択します (例: istio-system)。

    Location 列には、各ルートのリンク先アドレスが表示されます。

  4. 必要な場合は、フィルターを使用して jaeger ルートを検索します。ルートの Location をクリックしてコンソールを起動します。
  5. Log In With OpenShift をクリックします。

Kiali コンソールからの手順

  1. Kiali コンソールを起動します。
  2. 左側のナビゲーションペインで Distributed Tracing をクリックします。
  3. Log In With OpenShift をクリックします。

CLI からの手順

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

    $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
  2. コマンドラインを使用してルートの詳細をクエリーするには、以下のコマンドを入力します。この例では、istio-system が Service Mesh コントロールプレーンの namespace です。

    $ export JAEGER_URL=$(oc get route -n istio-system jaeger -o jsonpath='{.spec.host}')
  3. ブラウザーを起動し、https://<JAEGER_URL> に移動します。ここで、<JAEGER_URL> は直前の手順で検出されたルートです。
  4. Red Hat OpenShift Service on AWS コンソールにアクセスするときに使用するものと同じユーザー名とパスワードを使用してログインします。
  5. サービスメッシュにサービスを追加し、トレースを生成している場合は、フィルターと Find Traces ボタンを使用してトレースデータを検索します。

    コンソールインストールを検証すると、表示するトレースデータはありません。

1.15.6. Grafana コンソールへのアクセス

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

手順

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

1.15.7. Prometheus コンソールへのアクセス

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

手順

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

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

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

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

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

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

1.16.2.1. Service Mesh コントロールプレーンのパフォーマンス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.17. 実稼働環境の Service Mesh の設定

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

前提条件

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

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

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

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

手順

  1. 実稼働環境用の分散トレースプラットフォームを設定します。

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

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

      apiVersion: maistra.io/v2
      kind: ServiceMeshControlPlane
      metadata:
        name: basic
      spec:
        version: v2.3
        tracing:
          sampling: 100
          type: Jaeger
        addons:
          jaeger:
            name: MyJaeger
            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.17.2. 関連情報

1.18. サービスメッシュの接続

フェデレーション は、個別の管理ドメインで管理される個別のメッシュ間でサービスとワークロードを共有できるデプロイメントモデルです。

1.18.1. フェデレーションの概要

フェデレーションは、個別のメッシュ間でサービスを接続できるようにする機能セットであり、複数の別個の管理対象ドメイン間での認証、認可、およびトラフィック管理などの Service Mesh 機能を使用できるようにします。

フェデレーションメッシュを実装すると、複数の OpenShift クラスター全体で実行されている単一のサービスメッシュを実行、管理、および監視できます。Red Hat OpenShift Service Mesh のフェデレーションは、メッシュ間の最小限の信頼を前提とする Service Mesh のマルチクラスター実装に対して独自のアプローチを採用しています。

Service Mesh フェデレーションでは、各メッシュが個別に管理され、独自の管理者を用意することが前提です。デフォルトの動作では、通信が許可されず、メッシュ間で情報を共有されません。メッシュ間の情報、オプトインを明示することで共有されます。共有設定されていない限り、フェデレーションメッシュでは共有されません。証明書の生成、メトリクス、トレース収集などのサポート機能は、それぞれのメッシュのローカルで機能します。

各サービスメッシュで ServiceMeshControlPlane が、フェデレーション専用の ingress および egress ゲートウェイを作成してメッシュの信頼ドメインを指定するように設定します。

フェデレーションでは、追加でフェデレーションファイルも作成されます。以下のリソースを使用して、2 つ以上のメッシュ間のフェデレーションを設定します。

  • ServiceMeshPeer リソースは、サービスメッシュのペア間のフェデレーションを宣言します。
  • ExportedServiceSet リソース: メッシュからの 1 つ以上のサービスがピアメッシュで使用できることを宣言します。
  • ImportedServiceSet リソース: ピアメッシュでエクスポートされたどのサービスがメッシュにインポートされるかを宣言します。

1.18.2. フェデレーション機能

メッシュに参加するための Red Hat OpenShift Service Mesh フェデレーションアプローチの機能は以下のとおりです。

  • 各メッシュの共通ルート証明書をサポートします。
  • 各メッシュの異なるルート証明書をサポートします。
  • メッシュ管理者は、フェデレーションメッシュの外部にあるメッシュの証明書チェーン、サービス検出エンドポイント、信頼ドメインを手動で設定する必要があります。
  • メッシュ間で共有するサービスのみをエクスポート/インポートします。

    • デフォルトは、デプロイされたワークロードに関する情報は、フェデレーション内の他のメッシュとは共有されません。サービスをエクスポートして他のメッシュに公開し、独自のメッシュ外のワークロードから要求できるようにします。
    • エクスポートされたサービスは別のメッシュにインポートでき、そのメッシュのワークロードをインポートされたサービスに送信できるようにします。
  • メッシュ間の通信を常時暗号化します。
  • ローカルにデプロイされたワークロードおよびフェデレーション内の別のメッシュにデプロイされたワークロードの間における負荷分散の設定をサポートします。

メッシュが別のメッシュに参加すると、以下を実行できます。

  • フェデレーションメッシュに対して自信の信頼情報を提供します。
  • フェデレーションメッシュについての信頼情報を検出します。
  • 独自にエクスポートされたサービスに関する情報をフェデレーションメッシュに提供します。
  • フェデレーションメッシュでエクスポートされるサービスの情報を検出します。

1.18.3. フェデレーションセキュリティー

Red Hat OpenShift Service Mesh のフェデレーションは、メッシュ間の最小限の信頼を前提とする Service Mesh のマルチクラスター実装に対して独自のアプローチを採用しています。データセキュリティーは、フェデレーション機能の一部として組み込まれています。

  • メッシュごとに、テナントや管理が一意となっています。
  • フェデレーションで各メッシュに一意の信頼ドメインを作成します。
  • フェデレーションメッシュ間のトラフィックは、相互トランスポート層セキュリティー (mTLS) を使用して自動的に暗号化されます。
  • Kiali グラフは、インポートしたメッシュとサービスのみを表示します。メッシュにインポートされていない他のメッシュまたはサービスを確認できません。

1.18.4. フェデレーションの制限

メッシュに参加するための Red Hat OpenShift Service Mesh フェデレーションアプローチには、以下の制限があります。

  • メッシュのフェデレーションは OpenShift Dedicated ではサポートされていません。
  • メッシュのフェデレーションは、Microsoft Azure Red Hat OpenShift(ARO) ではサポートされません。

1.18.5. フェデレーションの前提条件

メッシュに参加するための Red Hat OpenShift Service Mesh フェデレーションアプローチには、以下の前提条件があります。

  • 2 つ以上の Red Hat OpenShift Service on AWS 4.6 以降のクラスター。
  • フェデレーション機能は Red Hat OpenShift Service Mesh 2.1 で導入されました。フェデレーションする必要のある各メッシュに Red Hat OpenShift Service Mesh 2.1 Operator がインストールされている必要があります。
  • フェデレーションする必要のある各メッシュにバージョン 2.1 の ServiceMeshControlPlane をデプロイする必要があります。
  • 生の TLS トラフィックをサポートするように、フェデレーションゲートウェイに関連付けられたサービスをサポートするロードバランサーを設定する必要があります。フェデレーショントラフィックは、検出用の HTTPS と、サービストラフィック用の生の暗号化 TCP で設定されます。
  • 別のメッシュに公開するサービスは、エクスポートおよびインポートする前にデプロイする必要があります。ただし、これは厳密な要件ではありません。エクスポート/インポート用にまだ存在していないサービス名を指定できます。ExportedServiceSetImportedServiceSet という名前のサービスをデプロイする場合に、これらのサービスは自動的にエクスポート/インポートで利用可能になります。

1.18.6. メッシュフェデレーションのプランニング

メッシュフェデレーションの設定を開始する前に、実装の計画に時間をかけるようにしてください。

  • フェデレーションに参加させる予定のメッシュは何個ありますか ?まずは、2 つから 3 つ程度の限られた数のメッシュで開始する必要があります。
  • 各メッシュにどの命名規則を使用する予定ですか ?事前定義の命名規則があると、設定とトラブルシューティングに役立ちます。本書の例では、メッシュごとに異なる色を使用します。各メッシュと以下のフェデレーションリソースの所有者および管理者を判断できるように、命名規則を決定する必要があります。

    • クラスター名
    • クラスターネットワーク名
    • メッシュ名と namespace
    • フェデレーション Ingress ゲートウェイ
    • フェデレーション egress ゲートウェイ
    • セキュリティー信頼ドメイン

      注記

      フェデレーションの各メッシュには、一意の信頼ドメインが必要です。

  • 各メッシュのどのサービスをフェデレーションメッシュにエクスポートする予定ですか ?各サービスは個別にエクスポートすることも、ラベルを指定したり、ワイルドカードを使用したりすることもできます。

    • サービスの namespace にエイリアスを使用しますか ?
    • エクスポートされたサービスにエイリアスを使用しますか ?
  • 各メッシュでどのエクスポートサービスを、インポートする予定ですか ?各メッシュは必要なサービスのみをインポートします。

    • インポートしたサービスにエイリアスを使用しますか ?

1.18.7. クラスター全体でのメッシュフェデレーション

OpenShift Service Mesh のインスタンスを別のクラスターで実行されているインスタンスに接続するには、同じクラスターにデプロイされた 2 つのメッシュに接続する場合とほぼ変わりません。ただし、メッシュの Ingress ゲートウェイに、他のメッシュから到達可できる必要があります。確実に到達できるようにするには、クラスターがこのタイプのサービスをサポートする場合には、ゲートウェイサービスを LoadBalancer サービスとして設定します。

サービスは、OSI モデルのレイヤー 4 で動作するロードバランサー経由で公開する必要があります。

1.18.7.1. ベアメタルで実行されるクラスターでのフェデレーション Ingress の公開

クラスターがベアメタルで実行され、LoadBalancer サービスを完全にサポートする場合には、ingress ゲートウェイ Service オブジェクトの .status.loadBalancer.ingress.ip フィールドにある IP アドレスを ServiceMeshPeer オブジェクトの .spec.remote.addresses フィールドにあるエントリーの 1 つとして指定する必要があります。

クラスターが LoadBalancer サービスをサポートしない場合には、他のメッシュを実行するクラスターからノードにアクセスできるのであれば NodePort サービスを使用することも可能です。ServiceMeshPeer オブジェクトで、.spec.remote.addresses フィールドのノードの IP アドレスと、.spec.remote.discoveryPort.spec.remote.servicePort フィールドのサービスのノードポートを指定します。

1.18.7.2. IBM Power および IBM Z で実行されているクラスターでのフェデレーション入力の公開

クラスターが IBM Power または IBM Z インフラストラクチャーで実行され、LoadBalancerサービスを完全にサポートする場合には、ingress ゲートウェイ Service オブジェクトの .status.loadBalancer.ingress.ip フィールドにある IP アドレスを ServiceMeshPeer オブジェクトの .spec.remote.addresses フィールドにあるエントリーの 1 つとして指定する必要があります。

クラスターが LoadBalancer サービスをサポートしない場合には、他のメッシュを実行するクラスターからノードにアクセスできるのであれば NodePort サービスを使用することも可能です。ServiceMeshPeer オブジェクトで、.spec.remote.addresses フィールドのノードの IP アドレスと、.spec.remote.discoveryPort.spec.remote.servicePort フィールドのサービスのノードポートを指定します。

1.18.7.3. Amazon Web Services(AWS) でのフェデレーション Ingress の公開

デフォルトでは、AWS で実行されるクラスターの LoadBalancer サービスで L4 負荷分散はサポートされていません。Red Hat OpenShift Service Mesh フェデレーションを正常に機能させるには、以下のアノテーションを Ingress ゲートウェイサービスに追加する必要があります。

service.beta.kubernetes.io/aws-load-balancer-type: nlb

ingress ゲートウェイ Service オブジェクトの .status.loadBalancer.ingress.hostname フィールドにある完全修飾ドメイン名は、ServiceMeshPeer オブジェクトの .spec.remote.addresses フィールドにあるエントリーの 1 つとして指定する必要があります。

1.18.7.4. Azure でのフェデレーション Ingress の公開

Microsoft Azure では、サービスタイプを LoadBalancer に設定するだけで、メッシュフェデレーションが正しく動作します。

ingress ゲートウェイ Service オブジェクトの .status.loadBalancer.ingress.ip フィールドにある IP アドレスは、ServiceMeshPeer オブジェクトの .spec.remote.addresses フィールドにあるエントリーの 1 つとして指定する必要があります。

1.18.7.5. Google Cloud Platform(GCP) でのフェデレーション Ingress の公開

Google Cloud Platform では、サービスタイプを LoadBalancer に設定するだけで、メッシュフェデレーションが正しく動作します。

ingress ゲートウェイ Service オブジェクトの .status.loadBalancer.ingress.ip フィールドにある IP アドレスは、ServiceMeshPeer オブジェクトの .spec.remote.addresses フィールドにあるエントリーの 1 つとして指定する必要があります。

1.18.8. フェデレーション実装のチェックリスト

サービスメッシュのフェデレーションには、以下のアクティビティーが含まれます。

  • ❏ フェデレーションする予定のクラスター間のネットワークを設定する。

    • ❏ 生の TLS トラフィックをサポートするように、フェデレーションゲートウェイに関連付けられたサービスをサポートするロードバランサーを設定する。
  • ❏ Red Hat OpenShift Service Mesh バージョン 2.1 以降の Operator を各クラスターにインストールする。
  • ❏ バージョン 2.1 以降の ServiceMeshControlPlane を各クラスターにデプロイする。
  • ❏ フェデレーションする各メッシュのフェデレーションに SMCP を設定する。

    • ❏ フェデレーションする各メッシュにフェデレーション egress ゲートウェイを作成する。
    • ❏ フェデレーションする各メッシュにフェデレーション Ingress ゲートウェイを作成する。
    • ❏ 一意の信頼ドメインを設定する。
  • ❏ 各メッシュのペアの ServiceMeshPeer リソースを作成して、2 つ以上のメッシュをフェデレーションする。
  • ExportedServiceSet リソースを作成してサービスをエクスポートし、1 つのメッシュからピアメッシュにサービスが利用できるようにします。
  • ImportedServiceSet リソースを作成してサービスをインポートし、メッシュピアで共有されるサービスをインポートします。

1.18.9. フェデレーション用の Service Mesh コントロールプレーンの設定

メッシュをフェデレーションする前に、メッシュフェデレーションの ServiceMeshControlPlane を設定する必要があります。フェデレーションに所属する全メッシュは同等で、各メッシュは個別に管理されるため、フェデレーションに参加する メッシュに SMCP を設定する必要があります。

以下の例では、red-mesh の管理者は green-meshblue-mesh の両方を使用して、フェデレーションに SMCP を設定します。

Red-mesh のサンプル SMCP

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: red-mesh
  namespace: red-mesh-system
spec:
  version: v2.3
  runtime:
    defaults:
      container:
        imagePullPolicy: Always
  gateways:
    additionalEgress:
      egress-green-mesh:
        enabled: true
        requestedNetworkView:
        - green-network
        routerMode: sni-dnat
        service:
          metadata:
            labels:
              federation.maistra.io/egress-for: egress-green-mesh
          ports:
          - port: 15443
            name: tls
          - port: 8188
            name: http-discovery  #note HTTP here
      egress-blue-mesh:
        enabled: true
        requestedNetworkView:
        - blue-network
        routerMode: sni-dnat
        service:
          metadata:
            labels:
              federation.maistra.io/egress-for: egress-blue-mesh
          ports:
          - port: 15443
            name: tls
          - port: 8188
            name: http-discovery  #note HTTP here
    additionalIngress:
      ingress-green-mesh:
        enabled: true
        routerMode: sni-dnat
        service:
          type: LoadBalancer
          metadata:
            labels:
              federation.maistra.io/ingress-for: ingress-green-mesh
          ports:
          - port: 15443
            name: tls
          - port: 8188
            name: https-discovery  #note HTTPS here
      ingress-blue-mesh:
        enabled: true
        routerMode: sni-dnat
        service:
          type: LoadBalancer
          metadata:
            labels:
              federation.maistra.io/ingress-for: ingress-blue-mesh
          ports:
          - port: 15443
            name: tls
          - port: 8188
            name: https-discovery  #note HTTPS here
  security:
    trust:
      domain: red-mesh.local

表1.6 ServiceMeshControlPlane フェデレーション設定パラメーター

パラメーター説明デフォルト値
spec:
  cluster:
    name:

クラスターの名前。クラスター名は指定する必要はありませんが、トラブルシューティングに役立ちます。

文字列

該当なし

spec:
  cluster:
    network:

クラスターネットワークの名前。ネットワークの名前は指定する必要はありませんが、設定およびトラブルシューティングに役立ちます。

文字列

該当なし

1.18.9.1. フェデレーションゲートウェイについて

ゲートウェイ を使用してメッシュの受信トラフィックおよび送信トラフィックを管理することで、メッシュに入るか、またはメッシュを出るトラフィックを指定できます。

Ingress および egress ゲートウェイを使用して、サービスメッシュ (North-South トラフィック) に入退出するトラフィックを管理します。フェデレーションメッシュの作成時に、追加の Ingress/egress ゲートウェイを作成し、フェデレーションメッシュ間のサービス検出や通信を用意にして、サービスメッシュ間のトラフィックフロー (East-West トラフィック) を管理します。

メッシュ間の命名の競合を回避するには、各メッシュに個別の egress および ingress ゲートウェイを作成する必要があります。たとえば、red-mesh には、green-mesh および blue-mesh に移動するトラフィックに対して個別の egress ゲートウェイがあります。

表1.7 フェデレーションゲートウェイパラメーター

パラメーター説明デフォルト値
spec:
  gateways:
    additionalEgress:
      <egressName>:

フェデレーションの メッシュピアの egress ゲートウェイを追加で定義します。

  
spec:
  gateways:
    additionalEgress:
      <egressName>:
        enabled:

このパラメーターは、フェデレーションの egress を有効または無効にします。

true/false

true

spec:
  gateways:
    additionalEgress:
      <egressName>:
        requestedNetworkView:

エクスポートされたサービスに関連付けられたネットワーク。

メッシュの SMCP で spec.cluster.network の値に設定します。それ以外の場合は、<ServiceMeshPeer-name>-network を使用します。たとえば、メッシュの ServiceMeshPeer リソースの名前が west の場合には、ネットワークは west-network になります。

 
spec:
  gateways:
    additionalEgress:
      <egressName>:
        routerMode:

ゲートウェイが使用するルーターモード。

sni-dnat

 
spec:
  gateways:
    additionalEgress:
      <egressName>:
        service:
          metadata:
            labels:
              federation.maistra.io/egress-for:

フェデレーショントラフィックがクラスターのデフォルトのシステムゲートウェイを通過しないように、ゲートウェイに一意のラベルを指定します。

  
spec:
  gateways:
    additionalEgress:
      <egressName>:
        service:
          ports:

TLS およびサービス検出用の port:name: を指定するのに使用します。フェデレーショントラフィックは、サービストラフィック用の生の暗号化 TCP で設定されます。

ポート 15443 は、フェデレーションで TLS サービス要求を他のメッシュに送信するために必要です。ポート 8188 は、フェデレーションでサービス検出要求を他のメッシュに送信するために必要です。

 
spec:
  gateways:
    additionalIngress:

フェデレーションで、 メッシュピアの追加の Ingress ゲートウェイを定義します。

  
spec:
  gateways:
    additionalIgress:
      <ingressName>:
        enabled:

このパラメーターは、フェデレーション Ingress を有効または無効にします。

true/false

true

spec:
  gateways:
    additionalIngress:
      <ingressName>:
        routerMode:

ゲートウェイが使用するルーターモード。

sni-dnat

 
spec:
  gateways:
    additionalIngress:
      <ingressName>:
        service:
          type:

Ingress ゲートウェイサービスは、OSI モデルのレイヤー 4 で動作し、一般公開されているロードバランサー経由で公開する必要があります。

LoadBalancer

 
spec:
  gateways:
    additionalIngress:
      <ingressName>:
        service:
          type:

クラスターが LoadBalancer サービスをサポートしていない場合には、入力ゲートウェイサービスは NodePort サービスを介して公開できます。

NodePort

 
spec:
  gateways:
    additionalIngress:
      <ingressName>:
        service:
          metadata:
            labels:
              federation.maistra.io/ingress-for:

フェデレーショントラフィックがクラスターのデフォルトのシステムゲートウェイを通過しないように、ゲートウェイに一意のラベルを指定します。

  
spec:
  gateways:
    additionalIngress:
      <ingressName>:
        service:
          ports:

TLS およびサービス検出用の port:name: を指定するのに使用します。フェデレーショントラフィックは、サービストラフィック用の生の暗号化 TCP で設定されます。フェデレーショントラフィックは、検出用に HTTPS で設定されます。

ポート 15443 は、フェデレーションの他のメッシュへの TLS サービス要求を受信するために必要です。ポート 8188 は、フェデレーションの他のメッシュへのサービス検出要求を受信するために必要です。

 
spec:
  gateways:
    additionalIngress:
      <ingressName>:
        service:
          ports:
            nodePort:

クラスターが LoadBalancer サービスをサポートしていない場合には、nodePort: を指定するために使用されます。

指定した場合には、port:name: 以外に、TLS とサービス検出の両方でこれが必須です。nodePort: 30000-32767 の範囲である必要があります。

 

次の例では、管理者は NodePort サービスを使用して グリーンメッシュ とのフェデレーション用に SMCP を設定しています。

NodePort の SMCP 例

  gateways:
     additionalIngress:
      ingress-green-mesh:
        enabled: true
        routerMode: sni-dnat
        service:
          type: NodePort
          metadata:
            labels:
              federation.maistra.io/ingress-for: ingress-green-mesh
          ports:
          - port: 15443
            nodePort: 30510
            name: tls
          - port: 8188
            nodePort: 32359
            name: https-discovery

1.18.9.2. フェデレーション信頼ドメインパラメーターについて

フェデレーションの各メッシュには、一意の信頼ドメインが必要です。この値は、ServiceMesh Peer リソースでメッシュフェデレーションを設定する時に使用されます。

kind: ServiceMeshControlPlane
metadata:
  name: red-mesh
  namespace: red-mesh-system
spec:
  security:
    trust:
      domain: red-mesh.local

表1.8 フェデレーションセキュリティーパラメーター

パラメーター説明デフォルト値
spec:
  security:
    trust:
      domain:

メッシュの信頼ドメインの一意の名前を指定するために使用されます。ドメインは、フェデレーション内のすべてのメッシュで一意である必要があります。

<mesh-name>.local

該当なし

コンソールからの手順

この手順に従って、Red Hat OpenShift Service on AWS Web コンソールで ServiceMeshControlPlane を編集します。この例では、red-mesh をサンプルとして使用しています。

  1. cluster-admin ロールを持つユーザーとして Red Hat OpenShift Service on AWS Web コンソールにログインします。
  2. OperatorsInstalled Operators に移動します。
  3. Project メニューをクリックし、Service Mesh コントロールプレーンをインストールしたプロジェクトを選択します。例: red-mesh-system
  4. Red Hat OpenShift Service Mesh Operator をクリックします。
  5. Istio Service Mesh Control Plane タブで、ServiceMeshControlPlane の名前 (red-mesh など) をクリックします。
  6. Create ServiceMeshControlPlane Details ページで、YAML をクリックして設定を変更します。
  7. ServiceMeshControlPlane を変更してフェデレーション Ingress および egress ゲートウェイを追加し、信頼ドメインを指定します。
  8. Save をクリックします。

CLI からの手順

以下の手順に従って、コマンドラインで ServiceMeshControlPlane を作成するか、または編集します。この例では、red-mesh をサンプルとして使用しています。

  1. cluster-admin ロールを持つユーザーとして Red Hat OpenShift Service on AWS CLI にログインします。以下のコマンドを入力します。次に、プロンプトが表示されたら、ユーザー名とパスワードを入力します。

    $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
  2. Service Mesh コントロールプレーンをインストールしたプロジェクト (例: red-mesh-system) に切り替えます。

    $ oc project red-mesh-system
  3. ServiceMeshControlPlane ファイルを編集し、フェデレーション Ingress および egress ゲートウェイを追加して信頼ドメインを指定します。
  4. 以下のコマンドを実行して Service Mesh コントロールプレーンを編集します。ここで、red-mesh-system はシステムの namespace であり、red-meshServiceMeshControlPlane オブジェクトの名前になります。

    $ oc edit -n red-mesh-system smcp red-mesh
  5. 以下のコマンドを実行して、Service Mesh コントロールプレーンのインストールのステータスを確認します。このコマンドでは、red-mesh-system がシステム namespace に置き換えます。

    $ oc get smcp -n red-mesh-system

    READY 列にすべてのコンポーネントが準備状態であることが示されると、インストールは正常に終了しています。

    NAME       READY   STATUS            PROFILES      VERSION   AGE
    red-mesh   10/10   ComponentsReady   ["default"]   2.1.0     4m25s

1.18.10. フェデレーションメッシュへの参加

ServiceMeshPeer リソースを作成して、2 つのメッシュ間のフェデレーションを宣言します。ServiceMeshPeer リソースは、2 つのメッシュ間のフェデレーションを定義し、これを使用してピアメッシュの検出設定、ピアメッシュへのアクセス、および他のメッシュのクライアントの検証に使用