1.18. Service Mesh の接続

1.18.1. フェデレーションの概要

フェデレーションは、個別のメッシュ間でサービスを接続できるようにする機能セットであり、複数の別個の管理対象ドメイン間での認証、認可、およびトラフィック管理などの Service Mesh 機能を使用できるようにします。

フェデレーションメッシュを実装すると、複数の OpenShift クラスター全体で実行されている単一の Service Mesh を実行、管理、および監視できます。Red Hat OpenShift Service Mesh のフェデレーションは、メッシュ間の最小限の信頼を前提とする Service Mesh のマルチクラスター実装に対して独自のアプローチを採用しています。

Service Mesh フェデレーションでは、各メッシュが個別に管理され、独自の管理者を用意することが前提です。デフォルトの動作では、通信が許可されず、メッシュ間で情報を共有されません。メッシュ間の情報、オプトインを明示することで共有されます。共有設定されていない限り、フェデレーションメッシュでは共有されません。証明書の生成、メトリック、トレース収集などのサポート機能は、それぞれのメッシュのローカルで機能します。

各 Service Mesh で ServiceMeshControlPlane が、フェデレーション専用の ingress および egress ゲートウェイを作成してメッシュの信頼ドメインを指定するように設定します。

フェデレーションでは、追加でフェデレーションファイルも作成されます。以下のリソースを使用して、2 つ以上のメッシュ間のフェデレーションを設定します。

ServiceMeshPeer リソースは、Service Mesh のペア間のフェデレーションを宣言します。
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 ではサポートされていません。

1.18.5. フェデレーションの前提条件

メッシュに参加するための Red Hat OpenShift Service Mesh フェデレーションアプローチには、以下の前提条件があります。

2 つ以上の OpenShift Container Platform 4.6 以降のクラスター。
フェデレーションは、Red Hat OpenShift Service Mesh 2.1 以降で導入されました。フェデレーションする必要のある各メッシュに Red Hat OpenShift Service Mesh 2.1 Operator がインストールされている必要があります。
フェデレーションする必要のある各メッシュにバージョン 2.1 以降の ServiceMeshControlPlane をデプロイする必要があります。
生の TLS トラフィックをサポートするように、フェデレーションゲートウェイに関連付けられたサービスをサポートするロードバランサーを設定する必要があります。フェデレーショントラフィックは、検出用の HTTPS と、サービストラフィック用の生の暗号化 TCP で設定されます。
別のメッシュに公開するサービスは、エクスポートおよびインポートする前にデプロイする必要があります。ただし、これは厳密な要件ではありません。エクスポート/インポート用にまだ存在していないサービス名を指定できます。ExportedServiceSet と ImportedServiceSet という名前のサービスをデプロイする場合に、これらのサービスは自動的にエクスポート/インポートで利用可能になります。

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. フェデレーション実装のチェックリスト

Service Mesh のフェデレーションには、以下のアクティビティーが含まれます。

❏ フェデレーションする予定のクラスター間のネットワークを設定する。
- ❏ 生の 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-mesh と blue-mesh の両方を使用して、フェデレーションに SMCP を設定します。

Red-mesh のサンプル SMCP

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: red-mesh
  namespace: red-mesh-system
spec:
  version: v2.4
  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 ゲートウェイを使用して、Service Mesh (North-South トラフィック) に入退出するトラフィックを管理します。フェデレーションメッシュの作成時に、追加の Ingress/egress ゲートウェイを作成し、フェデレーションメッシュ間のサービス検出や通信を用意にして、Service Mesh 間のトラフィックフロー (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`	該当なし

コンソールからの手順

以下の手順に従って、OpenShift Container Platform Web コンソールで ServiceMeshControlPlane を編集します。この例では、red-mesh をサンプルとして使用しています。

cluster-admin ロールが割り当てられたユーザーとして OpenShift Container Platform Web コンソールにログインします。
Operators Installed Operators に移動します。
Project メニューをクリックし、Service Mesh コントロールプレーンをインストールしたプロジェクトを選択します。例: red-mesh-system
Red Hat OpenShift Service Mesh Operator をクリックします。
Istio Service Mesh Control Plane タブで、ServiceMeshControlPlane の名前 (red-mesh など) をクリックします。
Create ServiceMeshControlPlane Details ページで、YAML をクリックして設定を変更します。
ServiceMeshControlPlane を変更してフェデレーション Ingress および egress ゲートウェイを追加し、信頼ドメインを指定します。
Save をクリックします。

CLI からの手順

以下の手順に従って、コマンドラインで ServiceMeshControlPlane を作成するか、編集します。この例では、red-mesh をサンプルとして使用しています。

cluster-admin ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。以下のコマンドを入力します。次に、プロンプトが表示されたら、ユーザー名とパスワードを入力します。
```
$ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
```
Service Mesh コントロールプレーンをインストールしたプロジェクト (例: red-mesh-system) に切り替えます。
```
$ oc project red-mesh-system
```
ServiceMeshControlPlane ファイルを編集し、フェデレーション Ingress および egress ゲートウェイを追加して信頼ドメインを指定します。
以下のコマンドを実行して Service Mesh コントロールプレーンを編集します。ここで、red-mesh-system はシステムの namespace であり、red-mesh は ServiceMeshControlPlane オブジェクトの名前になります。
```
$ oc edit -n red-mesh-system smcp red-mesh
```
以下のコマンドを実行して、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 つのメッシュ間のフェデレーションを定義し、これを使用してピアメッシュの検出設定、ピアメッシュへのアクセス、および他のメッシュのクライアントの検証に使用される証明書を定義します。

メッシュは 1 対 1 でフェデレーションされるため、ピアの各ペアでは、他のサービスメッシュへのフェデレーション接続を指定する ServiceMeshPeer リソースのペアが必要です。たとえば、red および green という名前の 2 つのメッシュには 2 つの ServiceMeshPeer ファイルが必要です。

Red-mesh-system で、Green メッシュの ServiceMeshPeer を作成します。
Green-mesh-system で、Red メッシュの ServiceMeshPeer を作成します。

red、blue および green という名前の 3 つのメッシュのフェデレーションには 6 つの ServiceMeshPeer ファイルが必要になります。

Red-mesh-system で、Green メッシュの ServiceMeshPeer を作成します。
Red-mesh-system で、Blue メッシュの ServiceMeshPeer を作成します。
Green-mesh-system で、Red メッシュの ServiceMeshPeer を作成します。
Green-mesh-system で、Blue メッシュの ServiceMeshPeer を作成します。
Blue-mesh-system で、Red メッシュの ServiceMeshPeer を作成します。
Blue-mesh-system で、Green メッシュの ServiceMeshPeer を作成します。

ServiceMeshPeer リソースの設定には、以下が含まれます。

検出およびサービス要求に使用される他のメッシュの Ingress ゲートウェイのアドレス。
指定のピアメッシュとの対話に使用されるローカル ingress および egress ゲートウェイの名前。
このメッシュへの要求の送信時に他のメッシュで使用されるクライアント ID。
他のメッシュで使用される信頼ドメイン。
ConfigMap の名前。これには、他のメッシュで使用される信頼ドメインのクライアント証明書の検証に使用するルート証明書が含まれます。

以下の例では、red-mesh の管理者は green-mesh でフェデレーションを設定します。

Red-mesh の ServiceMeshPeer リソースの例

kind: ServiceMeshPeer
apiVersion: federation.maistra.io/v1
metadata:
  name: green-mesh
  namespace: red-mesh-system
spec:
  remote:
    addresses:
    - ingress-red-mesh.green-mesh-system.apps.domain.com
  gateways:
    ingress:
      name: ingress-green-mesh
    egress:
      name: egress-green-mesh
  security:
    trustDomain: green-mesh.local
    clientID: green-mesh.local/ns/green-mesh-system/sa/egress-red-mesh-service-account
    certificateChain:
      kind: ConfigMap
      name: green-mesh-ca-root-cert

表1.9 ServiceMeshPeer 設定パラメーター
パラメーター	説明	値
metadata: name:	このリソースがフェデレーションを設定するピアメッシュの名前。	文字列
metadata: namespace:	このメッシュのシステム namespace (Service Mesh コントロールプレーンのインストール先)。	文字列
spec: remote: addresses:	このメッシュからの要求に対応するピアメッシュの Ingress ゲートウェイのパブリックアドレスリスト。
spec: remote: discoveryPort:	アドレスが検出要求を処理するポート。	デフォルトは 8188 です。
spec: remote: servicePort:	アドレスがサービス要求を処理するポート。	デフォルトは 15443 です。
spec: gateways: ingress: name:	ピアメッシュからの受信要求に対応するこのメッシュの Ingress の名前。例: `ingress-green-mesh`
spec: gateways: egress: name:	ピアメッシュに送信される要求に対応するこのメッシュ上の egress の名前。例: `egress-green-mesh`
spec: security: trustDomain:	ピアメッシュで使用される信頼ドメイン。	<peerMeshName>.local
spec: security: clientID:	このメッシュの呼び出し時にピアメッシュが使用するクライアント ID。	<peerMeshTrustDomain>/ns/<peerMeshSystem>/sa/<peerMeshEgressGatewayName>-service-account
spec: security: certificateChain: kind: ConfigMap name:	ピアメッシュがこのメッシュに提示したクライアント証明書の検証に使用されるルート証明書が含まれるリソースの種類 (例: ConfigMap) と名前。証明書が含まれる Config Map エントリーの鍵は `root-cert.pem` である必要があります。	kind: ConfigMap name: <peerMesh>-ca-root-cert

1.18.10.1. ServiceMeshPeer リソースの作成

前提条件

2 つ以上の OpenShift Container Platform 4.6 以降のクラスター。
クラスターのネットワーク設定が完了している。
生の TLS トラフィックをサポートするように、フェデレーションゲートウェイに関連付けられたサービスをサポートするロードバランサーを設定する必要があります。
各クラスターには、フェデレーションデプロイをサポートするようにバージョン 2.1 以降の ServiceMeshControlPlane が設定されている必要があります。
cluster-admin ロールを持つアカウントがある。

CLI からの手順

以下の手順に従って、コマンドラインから ServiceMeshPeer リソースを作成します。以下の例では、red-mesh が green-mesh のピアリソースを作成しています。

cluster-admin ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。以下のコマンドを入力します。次に、プロンプトが表示されたら、ユーザー名とパスワードを入力します。
```
$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
```
コントロールプレーンをインストールしたプロジェクト (例: red-mesh-system) に切り替えます。
```
$ oc project red-mesh-system
```

フェデレーションを行う 2 つのメッシュに対して、以下の例に基づいて ServiceMeshPeer ファイルを作成します。

Red-mesh から green-mesh への ServiceMeshPeer リソースのサンプル

kind: ServiceMeshPeer
apiVersion: federation.maistra.io/v1
metadata:
  name: green-mesh
  namespace: red-mesh-system
spec:
  remote:
    addresses:
    - ingress-red-mesh.green-mesh-system.apps.domain.com
  gateways:
    ingress:
      name: ingress-green-mesh
    egress:
      name: egress-green-mesh
  security:
    trustDomain: green-mesh.local
    clientID: green-mesh.local/ns/green-mesh-system/sa/egress-red-mesh-service-account
    certificateChain:
      kind: ConfigMap
      name: green-mesh-ca-root-cert

以下のコマンドを実行してリソースをデプロイします。ここで、red-mesh-system はシステムの namespace に置き換え、servicemeshpeer.yaml には編集したファイルへのフルパスが含まれます。
```
$ oc create -n red-mesh-system -f servicemeshpeer.yaml
```
red メッシュと green メッシュ間の接続確立を確認するには、red-mesh-system namespace の green-mesh ServiceMeshPeer のステータスを調べます。
```
$ oc -n red-mesh-system get servicemeshpeer green-mesh -o yaml
```
Red-mesh と green-mesh 間の ServiceMeshPeer 接続の例
```
status:
  discoveryStatus:
    active:
    - pod: istiod-red-mesh-b65457658-9wq5j
      remotes:
      - connected: true
        lastConnected: "2021-10-05T13:02:25Z"
        lastFullSync: "2021-10-05T13:02:25Z"
        source: 10.128.2.149
      watch:
        connected: true
        lastConnected: "2021-10-05T13:02:55Z"
        lastDisconnectStatus: 503 Service Unavailable
        lastFullSync: "2021-10-05T13:05:43Z"
```
status.discoveryStatus.active.remotes フィールドは、ピアメッシュ (この例では Green メッシュ) が現在のメッシュ (この例では赤のメッシュ) の istiod に接続されていることを示します。
status.discoveryStatus.active.watch フィールドは、現在のメッシュの istiod がピアメッシュで istiod に接続されていることを示します。
green-mesh-system で red-mesh という名前の servicemeshpeer を確認すると、Green メッシュの観点からの 2 つの同じ接続に関する情報が表示されます。
2 つのメッシュ間の接続が確立されていない場合、ServiceMeshPeer ステータスは、status.discoveryStatus.inactive フィールドにこれを示します。
接続の試みが失敗した理由の詳細については、Istiod ログ、ピアの egress トラフィックを処理する egress ゲートウェイのアクセスログ、およびピアメッシュ内の現在のメッシュの ingress トラフィックを処理する ingress ゲートウェイのアクセスログを調べてください。
たとえば、red メッシュが green メッシュに接続できない場合は、以下のログを確認します。
- red-mesh-system の istiod-red-mesh
- red-mesh-system の Egress-green-mesh
- green-mesh-system の ingress-red-mesh

1.18.11. フェデレーションメッシュからのサービスのエクスポート

サービスをエクスポートすると、メッシュは、フェデレーションされたメッシュの別のメンバーとサービスを共有できます。

ExportedServiceSet リソースを使用して、フェデレーションメッシュ内の別のピアから利用できるように指定したメッシュからサービスを宣言します。ピアと共有される各サービスを明示的に宣言する必要があります。

サービスは、namespace または名前別に選択できます。
ワイルドカードを使用してサービスを選択できます。たとえば、namespace 内のすべてのサービスをエクスポートします。
エイリアスを使用してサービスをエクスポートできます。たとえば、foo/bar サービスを custom-ns/bar としてエクスポートできます。
メッシュのシステム namespace に表示されるサービスのみをエクスポートできます。たとえば、networking.istio.io/exportTo ラベルが '.' に設定された別の namespace のサービスは、エクスポートの候補にはなりません。
エクスポートされたサービスの場合、それらのターゲットサービスは、元の要求元 (他のメッシュの egress ゲートウェイや、要求元のワークロードのクライアント ID は表示されない) ではなく、ingress ゲートウェイからのトラフィックのみが表示されます。

以下の例は、 red-mesh が green-mesh にエクスポートするサービス向けです。

ExportedServiceSet リソースの例

kind: ExportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
  name: green-mesh
  namespace: red-mesh-system
spec:
  exportRules:
  # export ratings.mesh-x-info as ratings.bookinfo
  - type: NameSelector
    nameSelector:
      namespace: red-mesh-info
      name: red-ratings
      alias:
        namespace: info
        name: ratings
  # export any service in red-mesh-info namespace with label export-service=true
  - type: LabelSelector
    labelSelector:
      namespace: red-mesh-info
      selector:
        matchLabels:
          export-service: "true"
      aliases: # export all matching services as if they were in the info namespace
      - namespace: "*"
        name: "*"
        alias:
          namespace: info

表1.10 ExportedServiceSet パラメーター
パラメーター	説明	値
metadata: name:	このサービスを公開する ServiceMeshPeer の名前。	`ServiceMeshPeer` リソースのメッシュの `name` 値と一致する必要があります。
metadata: namespace:	このリソースを含むプロジェクト/namespace の名前 (メッシュのシステム namespace を指定する必要があります)。
spec: exportRules: - type:	このサービスのエクスポートを管理するルールのタイプ。サービスで最初に一致するルールがエクスポートに使用されます。	`NameSelector`, `LabelSelector`
spec: exportRules: - type: NameSelector nameSelector: namespace: name:	`NameSelector` ルールを作成するには、サービスの `namespace` およびサービスの `namespace` を `Service` リソースで定義されるとおり指定します。
spec: exportRules: - type: NameSelector nameSelector: alias: namespace: name:	サービスの `namespace` と `name` を指定した後に、`namespace` のエイリアスと、サービスの `name` として使用するエイリアスを指定し、このサービスのエイリアスに使用する `NameSelector` ルールを作成します。
spec: exportRules: - type: LabelSelector labelSelector: namespace: <exportingMesh> selector: matchLabels: <labelKey>: <labelValue>	`LabelSelector` ルールを作成するには、サービスの `namespace` を指定し、`Service` リソースで定義されている `ラベル` を指定します。上記の例では、ラベルは `export-service` です。
spec: exportRules: - type: LabelSelector labelSelector: namespace: <exportingMesh> selector: matchLabels: <labelKey>: <labelValue> aliases: - namespace: name: alias: namespace: name:	サービスのエイリアスを使用する `LabelSelector` ルールを作成するには、`selector` を指定した後で、サービスの `name` または `namespace` に使用するエイリアスを指定します。上記の例では、一致するすべてのサービスの namespace エイリアスは `info` です。

Red-mesh のすべての namespace から blue-mesh へ ratings という名前のサービスをエクスポートします。

kind: ExportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
  name: blue-mesh
  namespace: red-mesh-system
spec:
  exportRules:
  - type: NameSelector
    nameSelector:
      namespace: "*"
      name: ratings

すべてのサービスを west-data-center namespace から green-mesh にエクスポートします。

kind: ExportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
  name: green-mesh
  namespace: red-mesh-system
spec:
  exportRules:
  - type: NameSelector
    nameSelector:
      namespace: west-data-center
      name: "*"

1.18.11.1. ExportedServiceSet の作成

ExportedServiceSet リソースを作成し、メッシュピアで利用可能なサービスを明示的に宣言します。

サービスは <export-name>.<export-namespace>.svc.<ServiceMeshPeer.name>-exports.local としてエクスポートされ、ターゲットサービスに自動的にルーティングされます。これは、エクスポートメッシュでエクスポートされたサービスで認識される名前です。Ingress ゲートウェイが宛先がこの名前の要求を受信すると、エクスポートされる実際のサービスにルーティングされます。たとえば、ratings.red-mesh-info という名前のサービスが ratings.bookinfo として green-mesh にエクスポートされると、サービスは ratings.bookinfo.svc.green-mesh-exports.local という名前でエクスポートされ、そのホスト名の ingress ゲートウェイが受信するトラフィックは ratings.red-mesh-bookinfo サービスにルーティングされます。

前提条件

クラスターおよび ServiceMeshControlPlane がメッシュフェデレーション用に設定されている。
cluster-admin ロールを持つアカウントがある。

注記

サービスがまだ存在していない場合でも、エクスポート用にサービスを設定できます。ExportedServiceSet で指定された値に一致するサービスがデプロイされ、自動的にエクスポートされます。

CLI からの手順

以下の手順に従って、コマンドラインから ExportedServiceSet を作成します。

cluster-admin ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。以下のコマンドを入力します。次に、プロンプトが表示されたら、ユーザー名とパスワードを入力します。
```
$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
```
Service Mesh コントロールプレーンをインストールしたプロジェクト (例: red-mesh-system) に切り替えます。
```
$ oc project red-mesh-system
```

以下の例に基づいて、ExportedServiceSet ファイルを作成します。ここでは、red-mesh がサービスを green-mesh にエクスポートします。

red-mesh から green-mesh への ExportedServiceSet リソースの例

apiVersion: federation.maistra.io/v1
kind: ExportedServiceSet
metadata:
  name: green-mesh
  namespace: red-mesh-system
spec:
  exportRules:
  - type: NameSelector
    nameSelector:
      namespace: red-mesh-info
      name: ratings
      alias:
        namespace: info
        name: red-ratings
  - type: NameSelector
    nameSelector:
      namespace: red-mesh-info
      name: reviews

以下のコマンドを実行して、red-mesh-system namespace に ExportedServiceSet リソースをアップロードおよび作成します。
```
$ oc create -n <ControlPlaneNamespace> -f <ExportedServiceSet.yaml>
```
以下に例を示します。
```
$ oc create -n red-mesh-system -f export-to-green-mesh.yaml
```
フェデレーションメッシュのメッシュピアごとに、必要に応じて追加の ExportedServiceSets を作成します。
red-mesh からエクスポートして green-mesh に共有したサービスを検証するには、以下のコマンドを実行します。
```
$ oc get exportedserviceset <PeerMeshExportedTo> -o yaml
```
以下に例を示します。
```
$ oc get exportedserviceset green-mesh -o yaml
```
以下のコマンドを実行して、red-mesh が green-mesh と共有するためにエクスポートしたサービスを検証します。
```
$ oc get exportedserviceset <PeerMeshExportedTo> -o yaml
```
以下に例を示します。
```
$ oc -n red-mesh-system get exportedserviceset green-mesh -o yaml
```
red メッシュからエクスポートして Green メッシュに共有したサービスの検証例。
```
  status:
    exportedServices:
    - exportedName: red-ratings.info.svc.green-mesh-exports.local
      localService:
        hostname: ratings.red-mesh-info.svc.cluster.local
        name: ratings
        namespace: red-mesh-info
    - exportedName: reviews.red-mesh-info.svc.green-mesh-exports.local
      localService:
        hostname: reviews.red-mesh-info.svc.cluster.local
        name: reviews
        namespace: red-mesh-info
```
status.exportedServices 配列では、現在エクスポートされているサービス (これらのサービスは ExportedServiceSet オブジェクト のエクスポートルールに一致) をリスト表示します。配列の各エントリーは、エクスポートされたサービスの名前と、エクスポートされたローカルサービスの詳細を示します。
エクスポート予定のサービスがない場合は、Service オブジェクトが存在すること、その名前またはラベルが ExportedServiceSet オブジェクトで定義される exportRules と一致すること、および Service オブジェクトの namespace が ServiceMeshMemberRoll または ServiceMeshMember オブジェクトを使用して Service Mesh のメンバーとして設定されることを確認します。

1.18.12. サービスのフェデレーションメッシュへのインポート

サービスをインポートすると、別のメッシュからエクスポートされたサービスの内、サービスメッシュ内でアクセスできるものを明示的に指定できます。

ImportedServiceSet リソースを使用して、インポートするサービスを選択します。メッシュピアによってエクスポートされ、明示的にインポートされるサービスのみがメッシュで利用できます。明示的にインポートしない場合、サービスは、メッシュ内で利用できません。

サービスは、namespace または名前別に選択できます。
namespace にエクスポートされたすべてのサービスをインポートするなど、ワイルドカードを使用してサービスを選択できます。
メッシュにグローバルであるか、特定のメンバーの namespace の範囲内にあるラベルセレクターを使用してエクスポートするサービスを選択できます。
エイリアスを使用してサービスをインポートできます。たとえば、custom-ns/bar サービスを other-mesh/bar としてインポートできます。
カスタムドメイン接尾辞を指定できます。これは、bar.other-mesh.imported.local など、インポートされたサービスの name.namespace に、完全修飾ドメイン名として追加されます。

以下の例は、red-mesh でエクスポートされたサービスをインポートする green-mesh の例です。

ImportedServiceSet の例

kind: ImportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
  name: red-mesh #name of mesh that exported the service
  namespace: green-mesh-system #mesh namespace that service is being imported into
spec:
  importRules: # first matching rule is used
  # import ratings.info as ratings.bookinfo
  - type: NameSelector
    importAsLocal: false
    nameSelector:
      namespace: info
      name: ratings
      alias:
        # service will be imported as ratings.info.svc.red-mesh-imports.local
        namespace: info
        name: ratings

表1.11 ImportedServiceSet パラメーター
パラメーター	説明	値
metadata: name:	サービスをフェデレーションメッシュにエクスポートした ServiceMeshPeer の名前。
metadata: namespace:	ServiceMeshPeer リソース (メッシュシステム namespace) を含む namespace の名前。
spec: importRules: - type:	サービスのインポートを管理するルールのタイプ。サービスで最初に一致するルールがインポートに使用されます。	`NameSelector`
spec: importRules: - type: NameSelector nameSelector: namespace: name:	`NameSelector` ルールを作成するには、`namespace` およびエクスポートされたサービスの `name` を指定します。
spec: importRules: - type: NameSelector importAsLocal:	リモートエンドポイントをローカルサービスで集約するには、 `true` に設定します。`true` の場合、サービスは `<name>.<namespace>.svc.cluster.local` としてインポートされます。	`true`/`false`
spec: importRules: - type: NameSelector nameSelector: namespace: name: alias: namespace: name:	サービスの `namespace` と `name` を指定した後に、`namespace` のエイリアスと、サービスの `name` として使用するエイリアスを指定し、このサービスのエイリアスに使用する `NameSelector` ルールを作成します。

red-mesh から blue-mesh への "info/ratings" サービスのインポート

kind: ImportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
  name: red-mesh
  namespace: blue-mesh-system
spec:
  importRules:
  - type: NameSelector
    importAsLocal: false
    nameSelector:
      namespace: info
      name: ratings

Red-mesh の west-data-center namespace からすべてのサービスを green-mesh にインポートします。これらのサービスは、<name>.west-data-center.svc.red-mesh-imports.local としてアクセスできます。

kind: ImportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
  name: red-mesh
  namespace: green-mesh-system
spec:
  importRules:
  - type: NameSelector
    importAsLocal: false
    nameSelector:
      namespace: west-data-center
      name: "*"

1.18.12.1. ImportedServiceSet の作成

ImportedServiceSet リソースを作成し、メッシュにインポートするサービスを明示的に宣言します。

サービスは、<exported-name>.<exported-namespace>.svc.<ServiceMeshPeer.name>.remote という名前でインポートされます。これは非表示のサービスで、egress ゲートウェイ namespace にのみ表示され、エクスポートされたサービスのホスト名に関連付けられます。このサービスは、ローカルから <export-name>.<export-namespace>.<domainSuffix> として利用可能になります。ここでは、importAsLocal が true に設定されていない限り、domainSuffix はデフォルトで svc.<ServiceMeshPeer.name>-imports.local となっています。True の場合、domainSuffix は svc.cluster.local となります。ImportAsLocal が false に設定されている場合は、インポートルールのドメイン接尾辞が適用されます。ローカルインポートは、メッシュ内の他のサービスと同様に扱うことができます。これは egress ゲートウェイを介して自動的にルーティングされ、エクスポートされたサービスのリモート名にリダイレクトされます。

前提条件

クラスターおよび ServiceMeshControlPlane がメッシュフェデレーション用に設定されている。
cluster-admin ロールを持つアカウントがある。

注記

サービスがまだエクスポートされていない場合でも、インポートするように設定できます。ImportedServiceSet で指定された値に一致するサービスがデプロイされてエクスポートされると、これは自動的にインポートされます。

CLI からの手順

この手順に従って、コマンドラインから ImportedServiceSet を作成します。

cluster-admin ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。以下のコマンドを入力します。次に、プロンプトが表示されたら、ユーザー名とパスワードを入力します。
```
$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
```
Service Mesh コントロールプレーンをインストールしたプロジェクト (例: green-mesh-system) に切り替えます。
```
$ oc project green-mesh-system
```

以下の例に基づいて ImportedServiceSet ファイルを作成します。ここでは、green-mesh が、red-mesh によって以前にエクスポートされたサービスをインポートします。

red-mesh から green-mesh への ImportedServiceSet リソースの例

kind: ImportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
  name: red-mesh
  namespace: green-mesh-system
spec:
  importRules:
  - type: NameSelector
    importAsLocal: false
    nameSelector:
      namespace: info
      name: red-ratings
      alias:
        namespace: info
        name: ratings

以下のコマンドを実行して、green-mesh-system namespace に ImportedServiceSet リソースをアップロードおよび作成します。
```
$ oc create -n <ControlPlaneNamespace> -f <ImportedServiceSet.yaml>
```
以下に例を示します。
```
$ oc create -n green-mesh-system -f import-from-red-mesh.yaml
```
フェデレーションメッシュ内のメッシュピアごとに、必要に応じて追加の ImportedServiceSet リソースを作成します。
green-mesh にインポートしたサービスを検証するには、以下のコマンドを実行します。
```
$ oc get importedserviceset <PeerMeshImportedInto> -o yaml
```
以下に例を示します。
```
$ oc get importedserviceset green-mesh -o yaml
```
以下のコマンドを実行して、メッシュにインポートされたサービスを検証します。
```
$ oc get importedserviceset <PeerMeshImportedInto> -o yaml
```
red mesh からエクスポートされたサービスが 'green-mesh-system namespace の importedserviceset/red-mesh' オブジェクト のステータスセクションを使用して、green メッシュにインポートされていることを検証する例:
```
$ oc -n green-mesh-system get importedserviceset/red-mesh -o yaml
```
```
status:
  importedServices:
  - exportedName: red-ratings.info.svc.green-mesh-exports.local
    localService:
      hostname: ratings.info.svc.red-mesh-imports.local
      name: ratings
      namespace: info
  - exportedName: reviews.red-mesh-info.svc.green-mesh-exports.local
    localService:
      hostname: ""
      name: ""
      namespace: ""
```
上記の例では、localService の入力済みフィールドで示されているように、ratings サービスのみがインポートされます。Reviews サービスはインポートできますが、ImportedServiceSet オブジェクトの importRules と一致しないため、現時点ではインポートされません。

1.18.13. フェイルオーバー用のフェデレーションメッシュの設定

フェイルオーバーとは、別のサーバーなどの信頼性の高いバックアップシステムに自動的かつシームレスに切り替える機能です。フェデレーションメッシュの場合は、あるメッシュのサービスを設定して、別のメッシュのサービスにフェイルオーバーできます。

ImportedServiceSet リソースで importAsLocal と locality の設定を指定してから、ImportedServiceSet で指定されたローカリティーへのサービスのフェイルオーバーを設定する DestinationRule を指定することにより、フェイルオーバーのフェデレーションを設定します。

前提条件

2 つ以上の OpenShift Container Platform 4.6 以降のクラスターがすでにネットワーク化およびフェデレーションされている。
フェデレーションメッシュのメッシュピアごとにすでに作成されている ExportedServiceSet リソース。
フェデレーションメッシュのメッシュピアごとにすでに作成されている ImportedServiceSet リソース。
cluster-admin ロールを持つアカウントがある。

1.18.13.1. フェイルオーバー用の ImportedServiceSet の設定

ローカリティ加重負荷分散を使用すると、管理者は、トラフィックの発信元と終了場所のローカリティに基づいて、エンドポイントへのトラフィックの分散を制御できます。これらのローカリティは、{region}/{zone}/{sub-zone} 形式でローカリティの階層を指定する任意のラベルを使用して指定します。

このセクションの例では、green-meshは米国us-east地域にあり、us-eastはus-east地域にあります。

red-mesh から green-mesh への ImportedServiceSet リソースの例

kind: ImportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
  name: red-mesh #name of mesh that exported the service
  namespace: green-mesh-system #mesh namespace that service is being imported into
spec:
  importRules: # first matching rule is used
  # import ratings.info as ratings.bookinfo
  - type: NameSelector
    importAsLocal: true
    nameSelector:
      namespace: info
      name: ratings
      alias:
        # service will be imported as ratings.info.svc.red-mesh-imports.local
        namespace: info
        name: ratings
  #Locality within which imported services should be associated.
  locality:
    region: us-west

表1.12 ImportedServiceLocalityフィールドテーブル
名前	説明	型
region:	インポートされたサービスが配置されている地域。	string
サブゾーン:	インポートされたサービスが配置されているサブゾーン。サブゾーンが指定されている場合は、ゾーンも指定する必要があります。	string
zone:	インポートされたサービスが配置されているゾーン。ゾーンを指定する場合は、リージョンも指定する必要があります。	string

手順

cluster-admin ロールを持つユーザーとして OpenShift Container Platform CLI にログインし、次のコマンドを入力します。
```
$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
```
Service Mesh コントロールプレーンをインストールしたプロジェクトに変更し、次のコマンドを入力します。
```
$ oc project <smcp-system>
```
たとえば、green-mesh-system です。
```
$ oc project green-mesh-system
```
ImportedServiceSet ファイルを編集します。ここで、<ImportedServiceSet.yaml> には、編集するファイルへのフルパスが含まれています。以下のコマンドを入力してください。
```
$ oc edit -n <smcp-system> -f <ImportedServiceSet.yaml>
```
たとえば、前の ImportedServiceSet の例で示したように、red-mesh-system から green-mesh-system にインポートするファイルを変更する場合は、以下のようになります。
```
$ oc edit -n green-mesh-system -f import-from-red-mesh.yaml
```
ファイルを変更します。
1. spec.importRules.importAsLocalをtrueに設定します。
2. spec.locality を region 、zone、または subzone に設定します。
3. 変更を保存します。

1.18.13.2. フェイルオーバー用の DestinationRule の設定

以下を設定する DestinationRule リソースを作成します。

サービスの外れ値の検出。これは、フェイルオーバーを正しく機能させるには必要です。特に、サービスのエンドポイントが異常である場合は把握できるようにサイドカープロキシーを設定し、最終的に次のローカリティへのフェイルオーバーをトリガーします。
リージョン間のフェイルオーバーポリシー。これにより、リージョンの境界を超えたフェイルオーバーが予測どおりに動作することが保証されます。

手順

cluster-admin ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。以下のコマンドを入力します。次に、プロンプトが表示されたら、ユーザー名とパスワードを入力します。
```
$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
```
Service Mesh コントロールプレーンをインストールしたプロジェクトに変更します。
```
$ oc project <smcp-system>
```
たとえば、green-mesh-system です。
```
$ oc project green-mesh-system
```

次の例に基づいて DestinationRule ファイルを作成します。ここで、green-mesh が使用できない場合、トラフィックは us-east リージョンの green-mesh から us-west の red-mesh にルーティングされます。

DestinationRule の例

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: default-failover
  namespace: info
spec:
  host: "ratings.info.svc.cluster.local"
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        enabled: true
        failover:
          - from: us-east
            to: us-west
    outlierDetection:
      consecutive5xxErrors: 3
      interval: 10s
      baseEjectionTime: 1m

DestinationRule をデプロイします。次のコマンドを入力します。<DestinationRule> にはファイルへのフルパスを追加します。
```
$ oc create -n <application namespace> -f <DestinationRule.yaml>
```
以下に例を示します。
```
$ oc create -n info -f green-mesh-us-west-DestinationRule.yaml
```

1.18.14. フェデレーションメッシュからのサービスの削除

フェデレーションメッシュからサービスを削除する必要がある場合 (非推奨になるか、別のサービスで置き換えられる場合など)、削除できます。

1.18.14.1. 単一のメッシュからサービスを削除するには、以下を実行します。

サービスにアクセスすべきでないメッシュピアの ImportedServiceSet リソースからサービスのエントリーを削除します。

1.18.14.2. フェデレーションメッシュ全体からサービスを削除するには、以下を実行します。

サービスを所有するメッシュの ExportedServiceSet リソースからサービスのエントリーを削除します。

1.18.15. フェデレーションメッシュからのメッシュの削除

フェデレーションからメッシュを削除する必要がある場合は、削除できます。

削除されたメッシュの ServiceMeshControlPlane リソースを編集して、ピアメッシュのすべてのフェデレーション Ingress ゲートウェイを削除します。
削除されたメッシュがフェデレーションされているメッシュピアごとに、以下を実行します。
1. 2 つのメッシュをリンクする ServiceMeshPeer リソースを削除します。
2. ピアメッシュの ServiceMeshControlPlane リソースを編集して、削除されたメッシュに対応する egress ゲートウェイを削除します。

1.18.1. フェデレーションの概要

1.18.2. フェデレーション機能

1.18.3. フェデレーションセキュリティー

1.18.4. フェデレーションの制限

1.18.5. フェデレーションの前提条件

1.18.6. メッシュフェデレーションのプランニング

1.18.7. クラスター全体でのメッシュフェデレーション

1.18.7.1. ベアメタルで実行されるクラスターでのフェデレーション Ingress の公開

1.18.7.2. IBM Power および IBM Z で実行されているクラスターでのフェデレーション入力の公開

1.18.7.3. Amazon Web Services(AWS) でのフェデレーション Ingress の公開

1.18.7.4. Azure でのフェデレーション Ingress の公開

1.18.7.5. Google Cloud Platform(GCP) でのフェデレーション Ingress の公開

1.18.8. フェデレーション実装のチェックリスト

1.18.9. フェデレーション用の Service Mesh コントロールプレーンの設定

1.18.9.1. フェデレーションゲートウェイについて

1.18.9.2. フェデレーション信頼ドメインパラメーターについて

1.18.10. フェデレーションメッシュへの参加

1.18.10.1. ServiceMeshPeer リソースの作成

1.18.11. フェデレーションメッシュからのサービスのエクスポート

1.18.11.1. ExportedServiceSet の作成

1.18.12. サービスのフェデレーションメッシュへのインポート

1.18.12.1. ImportedServiceSet の作成

1.18.13. フェイルオーバー用のフェデレーションメッシュの設定

1.18.13.1. フェイルオーバー用の ImportedServiceSet の設定

1.18.13.2. フェイルオーバー用の DestinationRule の設定

1.18.14. フェデレーションメッシュからのサービスの削除

1.18.14.1. 単一のメッシュからサービスを削除するには、以下を実行します。

1.18.14.2. フェデレーションメッシュ全体からサービスを削除するには、以下を実行します。

1.18.15. フェデレーションメッシュからのメッシュの削除

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links