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 つ以上の 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. フェデレーション実装のチェックリスト
サービスメッシュのフェデレーションには、以下のアクティビティーが含まれます。
❏ フェデレーションする予定のクラスター間のネットワークを設定する。
- ❏ 生の 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.2
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
| パラメーター | 説明 | 値 | デフォルト値 |
|---|---|---|---|
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 ゲートウェイがあります。
| パラメーター | 説明 | 値 | デフォルト値 |
|---|---|---|---|
spec:
gateways:
additionalEgress:
<egressName>:
| フェデレーションの 各 メッシュピアの egress ゲートウェイを追加で定義します。 | ||
spec:
gateways:
additionalEgress:
<egressName>:
enabled:
| このパラメーターは、フェデレーションの egress を有効または無効にします。 |
|
|
spec:
gateways:
additionalEgress:
<egressName>:
requestedNetworkView:
| エクスポートされたサービスに関連付けられたネットワーク。 |
メッシュの SMCP で | |
spec:
gateways:
additionalEgress:
<egressName>:
routerMode:
| ゲートウェイが使用するルーターモード。 |
| |
spec:
gateways:
additionalEgress:
<egressName>:
service:
metadata:
labels:
federation.maistra.io/egress-for:
| フェデレーショントラフィックがクラスターのデフォルトのシステムゲートウェイを通過しないように、ゲートウェイに一意のラベルを指定します。 | ||
spec:
gateways:
additionalEgress:
<egressName>:
service:
ports:
|
TLS およびサービス検出用の |
ポート | |
spec:
gateways:
additionalIngress:
| フェデレーションで、各 メッシュピアの追加の Ingress ゲートウェイを定義します。 | ||
spec:
gateways:
additionalIgress:
<ingressName>:
enabled:
| このパラメーターは、フェデレーション Ingress を有効または無効にします。 |
|
|
spec:
gateways:
additionalIngress:
<ingressName>:
routerMode:
| ゲートウェイが使用するルーターモード。 |
| |
spec:
gateways:
additionalIngress:
<ingressName>:
service:
type:
| Ingress ゲートウェイサービスは、OSI モデルのレイヤー 4 で動作し、一般公開されているロードバランサー経由で公開する必要があります。 |
| |
spec:
gateways:
additionalIngress:
<ingressName>:
service:
type:
|
クラスターが |
| |
spec:
gateways:
additionalIngress:
<ingressName>:
service:
metadata:
labels:
federation.maistra.io/ingress-for:
| フェデレーショントラフィックがクラスターのデフォルトのシステムゲートウェイを通過しないように、ゲートウェイに一意のラベルを指定します。 | ||
spec:
gateways:
additionalIngress:
<ingressName>:
service:
ports:
|
TLS およびサービス検出用の |
ポート | |
spec:
gateways:
additionalIngress:
<ingressName>:
service:
ports:
nodePort:
|
クラスターが |
指定した場合には、 |
次の例では、管理者は 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| パラメーター | 説明 | 値 | デフォルト値 |
|---|---|---|---|
spec:
security:
trust:
domain:
| メッシュの信頼ドメインの一意の名前を指定するために使用されます。ドメインは、フェデレーション内のすべてのメッシュで一意である必要があります。 |
| 該当なし |
コンソールからの手順
以下の手順に従って、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
| パラメーター | 説明 | 値 |
|---|---|---|
metadata: name: | このリソースがフェデレーションを設定するピアメッシュの名前。 | 文字列 |
metadata: namespace: | このメッシュのシステム namespace (Service Mesh コントロールプレーンのインストール先)。 | 文字列 |
spec:
remote:
addresses:
| このメッシュからの要求に対応するピアメッシュの Ingress ゲートウェイのパブリックアドレス一覧。 | |
spec:
remote:
discoveryPort:
| アドレスが検出要求を処理するポート。 | デフォルトは 8188 です。 |
spec:
remote:
servicePort:
| アドレスがサービス要求を処理するポート。 | デフォルトは 15443 です。 |
spec:
gateways:
ingress:
name:
|
ピアメッシュからの受信要求に対応するこのメッシュの Ingress の名前。例: | |
spec:
gateways:
egress:
name:
|
ピアメッシュに送信される要求に対応するこのメッシュ上の egress の名前。例: | |
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 エントリーの鍵は | 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-bookinfo as ratings.bookinfo
- type: NameSelector
nameSelector:
namespace: red-mesh-bookinfo
name: red-ratings
alias:
namespace: bookinfo
name: ratings
# export any service in red-mesh-bookinfo namespace with label export-service=true
- type: LabelSelector
labelSelector:
namespace: red-mesh-bookinfo
selector:
matchLabels:
export-service: "true"
aliases: # export all matching services as if they were in the bookinfo namespace
- namespace: "*"
name: "*"
alias:
namespace: bookinfo
| パラメーター | 説明 | 値 |
|---|---|---|
metadata: name: | このサービスを公開する ServiceMeshPeer の名前。 |
|
metadata: namespace: | このリソースを含むプロジェクト/namespace の名前 (メッシュのシステム namespace を指定する必要があります)。 | |
spec: exportRules: - type: | このサービスのエクスポートを管理するルールのタイプ。サービスで最初に一致するルールがエクスポートに使用されます。 |
|
spec:
exportRules:
- type: NameSelector
nameSelector:
namespace:
name:
|
| |
spec:
exportRules:
- type: NameSelector
nameSelector:
alias:
namespace:
name:
|
サービスの | |
spec:
exportRules:
- type: LabelSelector
labelSelector:
namespace: <exportingMesh>
selector:
matchLabels:
<labelKey>: <labelValue>
|
| |
spec:
exportRules:
- type: LabelSelector
labelSelector:
namespace: <exportingMesh>
selector:
matchLabels:
<labelKey>: <labelValue>
aliases:
- namespace:
name:
alias:
namespace:
name:
|
サービスのエイリアスを使用する |
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-bookinfo という名前のサービスが 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-bookinfo name: ratings alias: namespace: bookinfo name: red-ratings - type: NameSelector nameSelector: namespace: red-mesh-bookinfo 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.bookinfo.svc.green-mesh-exports.local localService: hostname: ratings.red-mesh-bookinfo.svc.cluster.local name: ratings namespace: red-mesh-bookinfo - exportedName: reviews.red-mesh-bookinfo.svc.green-mesh-exports.local localService: hostname: reviews.red-mesh-bookinfo.svc.cluster.local name: reviews namespace: red-mesh-bookinfostatus.exportedServices配列では、現在エクスポートされているサービス (これらのサービスはExportedServiceSet オブジェクトのエクスポートルールに一致) を一覧表示します。配列の各エントリーは、エクスポートされたサービスの名前と、エクスポートされたローカルサービスの詳細を示します。エクスポート予定のサービスがない場合には、Service オブジェクトが存在すること、その名前またはラベルが
ExportedServiceSetオブジェクトで定義されるexportRulesと一致すること、および Service オブジェクトの namespace がServiceMeshMemberRollまたはServiceMeshMemberオブジェクトを使用してサービスメッシュのメンバーとして設定されることを確認します。
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.bookinfo as ratings.bookinfo
- type: NameSelector
importAsLocal: false
nameSelector:
namespace: bookinfo
name: ratings
alias:
# service will be imported as ratings.bookinfo.svc.red-mesh-imports.local
namespace: bookinfo
name: ratings
| パラメーター | 説明 | 値 |
|---|---|---|
metadata: name: | サービスをフェデレーションメッシュにエクスポートした ServiceMeshPeer の名前。 | |
metadata: namespace: | ServiceMeshPeer リソース (メッシュシステム namespace) を含む namespace の名前。 | |
spec: importRules: - type: | サービスのインポートを管理するルールのタイプ。サービスで最初に一致するルールがインポートに使用されます。 |
|
spec:
importRules:
- type: NameSelector
nameSelector:
namespace:
name:
|
| |
spec:
importRules:
- type: NameSelector
importAsLocal:
|
リモートエンドポイントをローカルサービスで集約するには、 |
|
spec:
importRules:
- type: NameSelector
nameSelector:
namespace:
name:
alias:
namespace:
name:
|
サービスの |
red-mesh から blue-mesh への "bookinfo/ratings" サービスのインポート
kind: ImportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
name: red-mesh
namespace: blue-mesh-system
spec:
importRules:
- type: NameSelector
importAsLocal: false
nameSelector:
namespace: bookinfo
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: bookinfo name: red-ratings alias: namespace: bookinfo 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.bookinfo.svc.green-mesh-exports.local localService: hostname: ratings.bookinfo.svc.red-mesh-imports.local name: ratings namespace: bookinfo - exportedName: reviews.red-mesh-bookinfo.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.bookinfo as ratings.bookinfo
- type: NameSelector
importAsLocal: true
nameSelector:
namespace: bookinfo
name: ratings
alias:
# service will be imported as ratings.bookinfo.svc.red-mesh-imports.local
namespace: bookinfo
name: ratings
#Locality within which imported services should be associated.
locality:
region: us-west
| 名前 | 説明 | タイプ |
|---|---|---|
| region: | インポートされたサービスが配置されている地域。 | 文字列 |
| サブゾーン: | インポートされたサービスが配置されているサブゾーン。サブゾーンが指定されている場合は、ゾーンも指定する必要があります。 | 文字列 |
| zone: | インポートされたサービスが配置されているゾーン。ゾーンを指定する場合は、リージョンも指定する必要があります。 | 文字列 |
手順
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
ファイルを変更します。
-
spec.importRules.importAsLocalをtrueに設定します。 -
spec.localityをregion、zone、またはsubzoneに設定します。 - 変更を保存します。
-
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: bookinfo spec: host: "ratings.bookinfo.svc.cluster.local" trafficPolicy: loadBalancer: localityLbSetting: enabled: true failover: - from: us-east to: us-west outlierDetection: consecutive5xxErrors: 3 interval: 10s baseEjectionTime: 1mDestinationRuleをデプロイします。次のコマンドを入力します。<DestinationRule>にはファイルへのフルパスを追加します。$ oc create -n <application namespace> -f <DestinationRule.yaml>
以下に例を示します。
$ oc create -n bookinfo -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 ゲートウェイを削除します。 削除されたメッシュがフェデレーションされているメッシュピアごとに、以下を実行します。
-
2 つのメッシュをリンクする
ServiceMeshPeerリソースを削除します。 -
ピアメッシュの
ServiceMeshControlPlaneリソースを編集して、削除されたメッシュに対応する egress ゲートウェイを削除します。
-
2 つのメッシュをリンクする
