1.20. Service Mesh の接続
フェデレーション は、個別の管理ドメインで管理される個別のメッシュ間でサービスとワークロードを共有できるデプロイメントモデルです。
1.20.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.20.2. フェデレーション機能 リンクのコピーリンクがクリップボードにコピーされました!
メッシュに参加するための Red Hat OpenShift Service Mesh フェデレーションアプローチの機能は以下のとおりです。
- 各メッシュの共通ルート証明書をサポートします。
- 各メッシュの異なるルート証明書をサポートします。
- メッシュ管理者は、フェデレーションメッシュの外部にあるメッシュの証明書チェーン、サービス検出エンドポイント、信頼ドメインを手動で設定する必要があります。
メッシュ間で共有するサービスのみをエクスポート/インポートします。
- デフォルトは、デプロイされたワークロードに関する情報は、フェデレーション内の他のメッシュとは共有されません。サービスを エクスポート すると、他のメッシュからそのサービスが認識されるようになり、そのサービスのメッシュ外部のワークロードからのリクエストが許可されます。
- エクスポートしたサービスを別のメッシュに インポート すると、そのメッシュ上のワークロードがインポートされたサービスにリクエストを送信できるようになります。
- メッシュ間の通信を常時暗号化します。
- ローカルにデプロイされたワークロードおよびフェデレーション内の別のメッシュにデプロイされたワークロードの間における負荷分散の設定をサポートします。
メッシュを別のメッシュに結合すると、次のことが可能になります。
- フェデレーションメッシュに対して自信の信頼情報を提供します。
- フェデレーションメッシュに関する信頼情報を検出します。
- 独自にエクスポートされたサービスに関する情報をフェデレーションメッシュに提供します。
- フェデレーションメッシュでエクスポートされるサービスの情報を検出します。
1.20.3. フェデレーションのセキュリティー リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service Mesh のフェデレーションは、メッシュ間の最小限の信頼を前提とする Service Mesh のマルチクラスター実装に対して独自のアプローチを採用しています。データセキュリティーは、フェデレーション機能の一部として組み込まれています。
- メッシュごとに、テナントや管理が一意となっています。
- フェデレーションで各メッシュに一意の信頼ドメインを作成します。
- フェデレーションメッシュ間のトラフィックは、相互トランスポート層セキュリティー (mTLS) を使用して自動的に暗号化されます。
- Kiali グラフは、インポートしたメッシュとサービスのみを表示します。メッシュにインポートされていない他のメッシュまたはサービスを確認できません。
1.20.4. フェデレーションの制限 リンクのコピーリンクがクリップボードにコピーされました!
メッシュに参加するための Red Hat OpenShift Service Mesh フェデレーションアプローチには、以下の制限があります。
- メッシュのフェデレーションは OpenShift Dedicated ではサポートされていません。
1.20.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.20.6. メッシュフェデレーションのプランニング リンクのコピーリンクがクリップボードにコピーされました!
メッシュフェデレーションの設定を開始する前に、実装の計画に時間をかけるようにしてください。
- フェデレーションに加えるメッシュの数はいくつですか。まずは、2 つから 3 つ程度の限られた数のメッシュで開始する必要があります。
各メッシュにどの命名規則を使用する予定ですか ?事前定義の命名規則があると、設定とトラブルシューティングに役立ちます。このドキュメントの例では、メッシュごとに異なる色を使用します。各メッシュと以下のフェデレーションリソースの所有者および管理者を判断できるように、命名規則を決定する必要があります。
- クラスター名
- クラスターネットワーク名
- メッシュ名と namespace
- フェデレーション Ingress ゲートウェイ
- フェデレーション egress ゲートウェイ
セキュリティー信頼ドメイン
注記フェデレーションの各メッシュには、一意の信頼ドメインが必要です。
各メッシュのどのサービスをフェデレーションメッシュにエクスポートする予定ですか ?各サービスは個別にエクスポートすることも、ラベルを指定したり、ワイルドカードを使用したりすることもできます。
- サービスの namespace にエイリアスを使用しますか ?
- エクスポートされたサービスにエイリアスを使用しますか ?
各メッシュでどのエクスポートサービスを、インポートする予定ですか ?各メッシュは必要なサービスのみをインポートします。
- インポートしたサービスにエイリアスを使用しますか ?
1.20.7. クラスター全体でのメッシュフェデレーション リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Service Mesh のインスタンスを別のクラスターで実行されているインスタンスに接続するには、同じクラスターにデプロイされた 2 つのメッシュに接続する場合とほぼ変わりません。ただし、メッシュの Ingress ゲートウェイに、他のメッシュから到達可できる必要があります。確実に到達できるようにするには、クラスターがこのタイプのサービスをサポートする場合に、ゲートウェイサービスを LoadBalancer サービスとして設定します。
サービスは、OSI モデルのレイヤー 4 で動作するロードバランサー経由で公開する必要があります。
1.20.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.20.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.20.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.20.7.4. Azure でのフェデレーション Ingress の公開 リンクのコピーリンクがクリップボードにコピーされました!
Microsoft Azure では、サービスタイプを LoadBalancer に設定するだけで、メッシュフェデレーションが正しく動作します。
ingress ゲートウェイ Service オブジェクトの .status.loadBalancer.ingress.ip フィールドにある IP アドレスは、ServiceMeshPeer オブジェクトの .spec.remote.addresses フィールドにあるエントリーの 1 つとして指定する必要があります。
1.20.7.5. Google Cloud Platform(GCP) でのフェデレーション Ingress の公開 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud Platform では、サービスタイプを LoadBalancer に設定するだけで、メッシュフェデレーションが正しく動作します。
ingress ゲートウェイ Service オブジェクトの .status.loadBalancer.ingress.ip フィールドにある IP アドレスは、ServiceMeshPeer オブジェクトの .spec.remote.addresses フィールドにあるエントリーの 1 つとして指定する必要があります。
1.20.8. フェデレーション実装のチェックリスト リンクのコピーリンクがクリップボードにコピーされました!
Service Mesh のフェデレーションには、以下のアクティビティーが含まれます。
❏ フェデレーションする予定のクラスター間のネットワークを設定する。
- ❏ 生の TLS トラフィックをサポートするように、フェデレーションゲートウェイに関連付けられたサービスをサポートするロードバランサーを設定する。
- ❏ Red Hat OpenShift Service Mesh バージョン 2.1 以降の Operator を各クラスターにインストールする。
-
❏ バージョン 2.1 以降の
ServiceMeshControlPlaneを各クラスターにデプロイする。 ❏ フェデレーションする各メッシュのフェデレーションに SMCP を設定する。
- ❏ フェデレーションする各メッシュにフェデレーション egress ゲートウェイを作成する。
- ❏ フェデレーションする各メッシュにフェデレーション Ingress ゲートウェイを作成する。
- ❏ 一意の信頼ドメインを設定する。
-
❏ 各メッシュのペアの
ServiceMeshPeerリソースを作成して、2 つ以上のメッシュをフェデレーションする。 -
❏
ExportedServiceSetリソースを作成してサービスをエクスポートし、1 つのメッシュからピアメッシュにサービスが利用できるようにします。 -
❏
ImportedServiceSetリソースを作成してサービスをインポートし、メッシュピアで共有されるサービスをインポートします。
1.20.9. フェデレーション用の Service Mesh コントロールプレーンの設定 リンクのコピーリンクがクリップボードにコピーされました!
メッシュをフェデレーションする前に、メッシュフェデレーションの ServiceMeshControlPlane を設定する必要があります。フェデレーションに所属する全メッシュは同等で、各メッシュは個別に管理されるため、フェデレーションに参加する 各 メッシュに SMCP を設定する必要があります。
以下の例では、red-mesh の管理者は green-mesh と blue-mesh の両方を使用して、フェデレーションに SMCP を設定します。
red-mesh のサンプル SMCP
| パラメーター | 説明 | 値 | デフォルト値 |
|---|---|---|---|
spec:
cluster:
name:
| クラスターの名前。クラスター名は指定する必要はありませんが、トラブルシューティングに役立ちます。 | 文字列 | 該当なし |
spec:
cluster:
network:
| クラスターネットワークの名前。ネットワークの名前は指定する必要はありませんが、設定およびトラブルシューティングに役立ちます。 | 文字列 | 該当なし |
1.20.9.1. フェデレーションゲートウェイについて リンクのコピーリンクがクリップボードにコピーされました!
ゲートウェイ を使用してメッシュの受信トラフィックおよび送信トラフィックを管理することで、メッシュに入るか、メッシュを出るトラフィックを指定できます。
Ingress および egress ゲートウェイを使用して、Service Mesh (North-South トラフィック) に入退出するトラフィックを管理します。フェデレーションメッシュの作成時に、追加の Ingress/egress ゲートウェイを作成し、フェデレーションメッシュ間のサービス検出や通信を用意にして、Service Mesh 間のトラフィックフロー (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:
| ゲートウェイが使用するルーターモード。 |
| |
|
| フェデレーショントラフィックがクラスターのデフォルトのシステムゲートウェイを通過しないように、ゲートウェイに一意のラベルを指定します。 | ||
|
|
TLS およびサービス検出用の |
ポート | |
spec:
gateways:
additionalIngress:
| フェデレーションで、各 メッシュピアの追加の Ingress ゲートウェイを定義します。 | ||
spec:
gateways:
additionalIgress:
<ingressName>:
enabled:
| このパラメーターは、フェデレーション Ingress を有効または無効にします。 |
|
|
spec:
gateways:
additionalIngress:
<ingressName>:
routerMode:
| ゲートウェイが使用するルーターモード。 |
| |
|
| Ingress ゲートウェイサービスは、OSI モデルのレイヤー 4 で動作し、一般公開されているロードバランサー経由で公開する必要があります。 |
| |
|
|
クラスターが |
| |
|
| フェデレーショントラフィックがクラスターのデフォルトのシステムゲートウェイを通過しないように、ゲートウェイに一意のラベルを指定します。 | ||
|
|
TLS およびサービス検出用の |
ポート | |
|
|
クラスターが |
指定した場合は、 |
次の例では、管理者は NodePort サービスを使用して、green-mesh とのフェデレーション用に SMCP を設定しています。
NodePort の SMCP 例
1.20.9.2. フェデレーション信頼ドメインパラメーターについて リンクのコピーリンクがクリップボードにコピーされました!
フェデレーションの各メッシュには、一意の信頼ドメインが必要です。この値は、ServiceMeshPeer リソースでメッシュフェデレーションを設定するときに使用されます。
| パラメーター | 説明 | 値 | デフォルト値 |
|---|---|---|---|
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
$ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443Copy to Clipboard Copied! Toggle word wrap Toggle overflow Service Mesh コントロールプレーンをインストールしたプロジェクト (例: red-mesh-system) に切り替えます。
oc project red-mesh-system
$ oc project red-mesh-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
ServiceMeshControlPlaneファイルを編集し、フェデレーション Ingress および egress ゲートウェイを追加して信頼ドメインを指定します。 以下のコマンドを実行して Service Mesh コントロールプレーンを編集します。ここで、
red-mesh-systemはシステムの namespace であり、red-meshはServiceMeshControlPlaneオブジェクトの名前になります。oc edit -n red-mesh-system smcp red-mesh
$ oc edit -n red-mesh-system smcp red-meshCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、Service Mesh コントロールプレーンのインストールのステータスを確認します。このコマンドでは、
red-mesh-systemがシステム namespace に置き換えます。oc get smcp -n red-mesh-system
$ oc get smcp -n red-mesh-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow READY 列にすべてのコンポーネントが準備状態であることが示されると、インストールは正常に終了しています。
NAME READY STATUS PROFILES VERSION AGE red-mesh 10/10 ComponentsReady ["default"] 2.1.0 4m25s
NAME READY STATUS PROFILES VERSION AGE red-mesh 10/10 ComponentsReady ["default"] 2.1.0 4m25sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.20.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 リソースの例
| パラメーター | 説明 | 値 |
|---|---|---|
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.20.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
$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443Copy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールプレーンをインストールしたプロジェクト (例:
red-mesh-system) に切り替えます。oc project red-mesh-system
$ oc project red-mesh-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow フェデレーションを行う 2 つのメッシュに対して、以下の例に基づいて
ServiceMeshPeerファイルを作成します。red-mesh から green-mesh への ServiceMeshPeer リソースのサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してリソースをデプロイします。ここで、
red-mesh-systemはシステムの namespace に置き換え、servicemeshpeer.yamlには編集したファイルへのフルパスが含まれます。oc create -n red-mesh-system -f servicemeshpeer.yaml
$ oc create -n red-mesh-system -f servicemeshpeer.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow red メッシュと green メッシュ間の接続確立を確認するには、red-mesh-system namespace の green-mesh
ServiceMeshPeerのステータスを調べます。oc -n red-mesh-system get servicemeshpeer green-mesh -o yaml
$ oc -n red-mesh-system get servicemeshpeer green-mesh -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow red-mesh と green-mesh 間の ServiceMeshPeer 接続の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow status.discoveryStatus.active.remotesフィールドは、ピアメッシュ (この例では green メッシュ) が現在のメッシュ (この例では red メッシュ) の 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.20.11. フェデレーションメッシュからのサービスのエクスポート リンクのコピーリンクがクリップボードにコピーされました!
サービスをエクスポートすると、メッシュは、フェデレーションされたメッシュの別のメンバーとサービスを共有できます。
ExportedServiceSet リソースを使用して、フェデレーションメッシュ内の別のピアから利用できるように指定したメッシュからサービスを宣言します。ピアと共有される各サービスを明示的に宣言する必要があります。
- サービスは、namespace または名前別に選択できます。
- ワイルドカードを使用してサービスを選択できます。たとえば、namespace 内のすべてのサービスをエクスポートします。
-
エイリアスを使用してサービスをエクスポートできます。たとえば、
foo/barサービスをcustom-ns/barとしてエクスポートできます。 -
メッシュのシステム namespace に表示されるサービスのみをエクスポートできます。たとえば、
networking.istio.io/exportToラベルが ‘.’ に設定されている別の namespace 内のサービスは、エクスポートの候補にはなりません。 - エクスポートされたサービスの場合、それらのターゲットサービスは、元の要求元 (他のメッシュの egress ゲートウェイや、要求元のワークロードのクライアント ID は表示されない) ではなく、ingress ゲートウェイからのトラフィックのみが表示されます。
以下の例は、red-mesh が green-mesh にエクスポートするサービス向けです。
ExportedServiceSet リソースの例
| パラメーター | 説明 | 値 |
|---|---|---|
metadata: name:
| このサービスを公開する ServiceMeshPeer の名前。 |
|
metadata: namespace:
| このリソースを含むプロジェクト/namespace の名前 (メッシュのシステム namespace を指定する必要があります)。 | |
spec: exportRules: - type:
| このサービスのエクスポートを管理するルールのタイプ。サービスで最初に一致するルールがエクスポートに使用されます。 |
|
|
|
| |
|
|
サービスの | |
|
|
| |
|
|
サービスのエイリアスを使用する |
red-mesh のすべての namespace から blue-mesh へ "ratings" という名前のサービスをエクスポートします。
すべてのサービスを west-data-center namespace から green-mesh にエクスポートします。
1.20.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 サービスにルーティングされます。
importAsLocal パラメーターを true に設定して、リモートエンドポイントをローカルサービスで集約する場合は、サービスのエイリアスを使用する必要があります。パラメーターを false に設定した場合、エイリアスは必要ありません。
前提条件
-
クラスターおよび
ServiceMeshControlPlaneがメッシュフェデレーション用に設定されている。 -
cluster-adminロールを持つアカウントがある。
サービスがまだ存在していない場合でも、エクスポート用にサービスを設定できます。ExportedServiceSet で指定された値に一致するサービスがデプロイされ、自動的にエクスポートされます。
CLI からの手順
以下の手順に従って、コマンドラインから ExportedServiceSet を作成します。
cluster-adminロールを持つユーザーとして OpenShift Container Platform CLI にログインします。以下のコマンドを入力します。次に、プロンプトが表示されたら、ユーザー名とパスワードを入力します。oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443Copy to Clipboard Copied! Toggle word wrap Toggle overflow Service Mesh コントロールプレーンをインストールしたプロジェクト (例:
red-mesh-system) に切り替えます。oc project red-mesh-system
$ oc project red-mesh-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例に基づいて、
ExportedServiceSetファイルを作成します。ここでは、red-meshがサービスをgreen-meshにエクスポートします。red-mesh から green-mesh への ExportedServiceSet リソースの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、red-mesh-system namespace に
ExportedServiceSetリソースをアップロードおよび作成します。oc create -n <ControlPlaneNamespace> -f <ExportedServiceSet.yaml>
$ oc create -n <ControlPlaneNamespace> -f <ExportedServiceSet.yaml>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc create -n red-mesh-system -f export-to-green-mesh.yaml
$ oc create -n red-mesh-system -f export-to-green-mesh.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
フェデレーションメッシュのメッシュピアごとに、必要に応じて追加の
ExportedServiceSetsを作成します。
検証
以下のコマンドを実行して、red-mesh が green-mesh と共有するためにエクスポートしたサービスを検証します。
oc get exportedserviceset <PeerMeshExportedTo> -o yaml
$ oc get exportedserviceset <PeerMeshExportedTo> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc -n red-mesh-system get exportedserviceset green-mesh -o yaml
$ oc -n red-mesh-system get exportedserviceset green-mesh -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow red メッシュからエクスポートして green メッシュに共有したサービスの検証例。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow status.exportedServices配列には、現在エクスポートされているサービスがリストされます (これらのサービスがExportedServiceSet objectのエクスポートルールと一致しました)。配列の各エントリーは、エクスポートされたサービスの名前と、エクスポートされたローカルサービスの詳細を示します。エクスポート予定のサービスがない場合は、Service オブジェクトが存在すること、その名前またはラベルが
ExportedServiceSetオブジェクトで定義されるexportRulesと一致すること、および Service オブジェクトの namespace がServiceMeshMemberRollまたはServiceMeshMemberオブジェクトを使用して Service Mesh のメンバーとして設定されることを確認します。
1.20.12. サービスのフェデレーションメッシュへのインポート リンクのコピーリンクがクリップボードにコピーされました!
サービスをインポートすると、別のメッシュからエクスポートされたサービスの内、サービスメッシュ内でアクセスできるものを明示的に指定できます。
ImportedServiceSet リソースを使用して、インポートするサービスを選択します。メッシュピアによってエクスポートされ、明示的にインポートされるサービスのみがメッシュで利用できます。明示的にインポートしない場合、サービスは、メッシュ内で利用できません。
- サービスは、namespace または名前別に選択できます。
- namespace にエクスポートされたすべてのサービスをインポートするなど、ワイルドカードを使用してサービスを選択できます。
- メッシュにグローバルであるか、特定のメンバーの namespace の範囲内にあるラベルセレクターを使用してエクスポートするサービスを選択できます。
-
エイリアスを使用してサービスをインポートできます。たとえば、
custom-ns/barサービスをother-mesh/barとしてインポートできます。 -
カスタムドメイン接尾辞を指定できます。これは、
bar.other-mesh.imported.localなど、インポートされたサービスのname.namespaceに、完全修飾ドメイン名として追加されます。
以下の例は、red-mesh でエクスポートされたサービスをインポートする green-mesh の例です。
ImportedServiceSet の例
| パラメーター | 説明 | 値 |
|---|---|---|
metadata: name:
| サービスをフェデレーションメッシュにエクスポートした ServiceMeshPeer の名前。 | |
metadata: namespace:
| ServiceMeshPeer リソース (メッシュシステム namespace) を含む namespace の名前。 | |
spec: importRules: - type:
| サービスのインポートを管理するルールのタイプ。サービスで最初に一致するルールがインポートに使用されます。 |
|
|
|
| |
spec:
importRules:
- type: NameSelector
importAsLocal:
|
リモートエンドポイントをローカルサービスで集約するには、 |
|
|
|
サービスの |
red-mesh から blue-mesh への "info/ratings" サービスのインポート
red-mesh の west-data-center namespace からすべてのサービスを green-mesh にインポートします。これらのサービスは、<name>.west-data-center.svc.red-mesh-imports.local としてアクセスできます。
1.20.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 で指定された値に一致するサービスがデプロイされてエクスポートされると、これは自動的にインポートされます。
手順
この手順に従って、コマンドラインから ImportedServiceSet を作成します。
cluster-adminロールを持つユーザーとして OpenShift Container Platform CLI にログインします。以下のコマンドを入力します。次に、プロンプトが表示されたら、ユーザー名とパスワードを入力します。oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443Copy to Clipboard Copied! Toggle word wrap Toggle overflow Service Mesh コントロールプレーンをインストールしたプロジェクト (例:
green-mesh-system) に切り替えます。oc project green-mesh-system
$ oc project green-mesh-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例に基づいて
ImportedServiceSetファイルを作成します。ここでは、green-meshが、red-meshによって以前にエクスポートされたサービスをインポートします。red-mesh から green-mesh への ImportedServiceSet リソースの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、green-mesh-system namespace に
ImportedServiceSetリソースをアップロードおよび作成します。oc create -n <ControlPlaneNamespace> -f <ImportedServiceSet.yaml>
$ oc create -n <ControlPlaneNamespace> -f <ImportedServiceSet.yaml>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc create -n green-mesh-system -f import-from-red-mesh.yaml
$ oc create -n green-mesh-system -f import-from-red-mesh.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
フェデレーションメッシュ内のメッシュピアごとに、必要に応じて追加の
ImportedServiceSetリソースを作成します。
検証
次のコマンドを実行して、サービスが
green-meshにインポートされたことを確認します。oc get importedserviceset <PeerMeshImportedInto> -o yaml
$ oc get importedserviceset <PeerMeshImportedInto> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 'green-mesh-system' namespace の
importedserviceset/red-meshオブジェクトの status セクションを使用して、red mesh からエクスポートされたサービスが green mesh にインポートされたことを確認する例:oc -n green-mesh-system get importedserviceset/red-mesh -o yaml
$ oc -n green-mesh-system get importedserviceset/red-mesh -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記の例では、
localServiceの入力済みフィールドで示されているように、ratings サービスのみがインポートされます。Reviews サービスはインポートできますが、ImportedServiceSetオブジェクトのimportRulesと一致しないため、現時点ではインポートされません。
1.20.13. フェイルオーバー用のフェデレーションメッシュの設定 リンクのコピーリンクがクリップボードにコピーされました!
フェイルオーバーとは、別のサーバーなどの信頼性の高いバックアップシステムに自動的かつシームレスに切り替える機能です。フェデレーションメッシュの場合は、あるメッシュのサービスを設定して、別のメッシュのサービスにフェイルオーバーできます。
ImportedServiceSet リソースで importAsLocal と locality の設定を指定してから、ImportedServiceSet で指定されたローカリティーへのサービスのフェイルオーバーを設定する DestinationRule を指定することにより、フェイルオーバーのフェデレーションを設定します。
前提条件
- 2 つ以上の OpenShift Container Platform 4.6 以降のクラスターがすでにネットワーク化およびフェデレーションされている。
-
フェデレーションメッシュのメッシュピアごとにすでに作成されている
ExportedServiceSetリソース。 -
フェデレーションメッシュのメッシュピアごとにすでに作成されている
ImportedServiceSetリソース。 -
cluster-adminロールを持つアカウントがある。
1.20.13.1. フェイルオーバー用の ImportedServiceSet の設定 リンクのコピーリンクがクリップボードにコピーされました!
ローカリティ加重負荷分散を使用すると、管理者は、トラフィックの発信元と終了場所のローカリティに基づいて、エンドポイントへのトラフィックの分散を制御できます。これらのローカリティは、{region}/{zone}/{sub-zone} 形式でローカリティの階層を指定する任意のラベルを使用して指定します。
このセクションの例では、green-mesh は us-east リージョンにあり、red-mesh は us-west リージョンにあります。
red-mesh から green-mesh への ImportedServiceSet リソースの例
| 名前 | 説明 | 型 |
|---|---|---|
| region: | インポートされたサービスが配置されているリージョン。 | string |
| subzone: | インポートされたサービスが配置されているサブゾーン。サブゾーンが指定されている場合は、ゾーンも指定する必要があります。 | string |
| zone: | インポートされたサービスが配置されているゾーン。ゾーンを指定する場合は、リージョンも指定する必要があります。 | string |
手順
cluster-adminロールを持つユーザーとして OpenShift Container Platform CLI にログインし、次のコマンドを入力します。oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443Copy to Clipboard Copied! Toggle word wrap Toggle overflow Service Mesh コントロールプレーンをインストールしたプロジェクトに変更し、次のコマンドを入力します。
oc project <smcp-system>
$ oc project <smcp-system>Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
green-mesh-systemです。oc project green-mesh-system
$ oc project green-mesh-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow ImportedServiceSetファイルを編集します。ここで、<ImportedServiceSet.yaml>には、編集するファイルへのフルパスが含まれています。以下のコマンドを入力してください。oc edit -n <smcp-system> -f <ImportedServiceSet.yaml>
$ oc edit -n <smcp-system> -f <ImportedServiceSet.yaml>Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、前の
ImportedServiceSetの例で示したように、red-mesh-system から green-mesh-system にインポートするファイルを変更する場合は、以下のようになります。oc edit -n green-mesh-system -f import-from-red-mesh.yaml
$ oc edit -n green-mesh-system -f import-from-red-mesh.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ファイルを変更します。
-
spec.importRules.importAsLocalをtrueに設定します。 -
spec.localityをregion、zone、またはsubzoneに設定します。 - 変更を保存します。
-
1.20.13.2. フェイルオーバー用の DestinationRule の設定 リンクのコピーリンクがクリップボードにコピーされました!
以下を設定する DestinationRule リソースを作成します。
- サービスの外れ値の検出。これは、フェイルオーバーを正しく機能させるには必要です。特に、サービスのエンドポイントが異常である場合は把握できるようにサイドカープロキシーを設定し、最終的に次のローカリティへのフェイルオーバーをトリガーします。
- リージョン間のフェイルオーバーポリシー。これにより、リージョンの境界を超えたフェイルオーバーが予測どおりに動作することが保証されます。
手順
cluster-adminロールを持つユーザーとして OpenShift Container Platform CLI にログインします。以下のコマンドを入力します。次に、プロンプトが表示されたら、ユーザー名とパスワードを入力します。oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443Copy to Clipboard Copied! Toggle word wrap Toggle overflow Service Mesh コントロールプレーンをインストールしたプロジェクトに変更します。
oc project <smcp-system>
$ oc project <smcp-system>Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
green-mesh-systemです。oc project green-mesh-system
$ oc project green-mesh-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例に基づいて
DestinationRuleファイルを作成します。ここで、green-mesh が使用できない場合、トラフィックはus-eastリージョンの green-mesh からus-westの red-mesh にルーティングされます。DestinationRuleの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow DestinationRuleをデプロイします。次のコマンドを入力します。<DestinationRule>にはファイルへのフルパスを追加します。oc create -n <application namespace> -f <DestinationRule.yaml>
$ oc create -n <application namespace> -f <DestinationRule.yaml>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc create -n info -f green-mesh-us-west-DestinationRule.yaml
$ oc create -n info -f green-mesh-us-west-DestinationRule.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.20.14. フェデレーションメッシュからのサービスの削除 リンクのコピーリンクがクリップボードにコピーされました!
フェデレーションメッシュからサービスを削除する必要がある場合 (非推奨になるか、別のサービスで置き換えられる場合など)、削除できます。
1.20.14.1. 単一のメッシュからサービスを削除するには、以下を実行します。 リンクのコピーリンクがクリップボードにコピーされました!
サービスにアクセスすべきでないメッシュピアの ImportedServiceSet リソースからサービスのエントリーを削除します。
1.20.14.2. フェデレーションメッシュ全体からサービスを削除するには、以下を実行します。 リンクのコピーリンクがクリップボードにコピーされました!
サービスを所有するメッシュの ExportedServiceSet リソースからサービスのエントリーを削除します。
1.20.15. フェデレーションメッシュからのメッシュの削除 リンクのコピーリンクがクリップボードにコピーされました!
フェデレーションからメッシュを削除する必要がある場合は、削除できます。
-
削除されたメッシュの
ServiceMeshControlPlaneリソースを編集して、ピアメッシュのすべてのフェデレーション Ingress ゲートウェイを削除します。 削除されたメッシュがフェデレーションされているメッシュピアごとに、以下を実行します。
-
2 つのメッシュをリンクする
ServiceMeshPeerリソースを削除します。 -
ピアメッシュの
ServiceMeshControlPlaneリソースを編集して、削除されたメッシュに対応する egress ゲートウェイを削除します。
-
2 つのメッシュをリンクする