2.20.10. Joining a federated mesh
You declare the federation between two meshes by creating a ServiceMeshPeer resource. The ServiceMeshPeer resource defines the federation between two meshes, and you use it to configure discovery for the peer mesh, access to the peer mesh, and certificates used to validate the other mesh’s clients.
Meshes are federated on a one-to-one basis, so each pair of peers requires a pair of ServiceMeshPeer resources specifying the federation connection to the other service mesh. For example, federating two meshes named red and green would require two ServiceMeshPeer files.
-
On red-mesh-system, create a
ServiceMeshPeerfor the green mesh. -
On green-mesh-system, create a
ServiceMeshPeerfor the red mesh.
Federating three meshes named red, blue, and green would require six ServiceMeshPeer files.
-
On red-mesh-system, create a
ServiceMeshPeerfor the green mesh. -
On red-mesh-system, create a
ServiceMeshPeerfor the blue mesh. -
On green-mesh-system, create a
ServiceMeshPeerfor the red mesh. -
On green-mesh-system, create a
ServiceMeshPeerfor the blue mesh. -
On blue-mesh-system, create a
ServiceMeshPeerfor the red mesh. -
On blue-mesh-system, create a
ServiceMeshPeerfor the green mesh.
Configuration in the ServiceMeshPeer resource includes the following:
- The address of the other mesh’s ingress gateway, which is used for discovery and service requests.
- The names of the local ingress and egress gateways that is used for interactions with the specified peer mesh.
- The client ID used by the other mesh when sending requests to this mesh.
- The trust domain used by the other mesh.
-
The name of a
ConfigMapcontaining a root certificate that is used to validate client certificates in the trust domain used by the other mesh.
In the following example, the administrator for the red-mesh is configuring federation with the green-mesh.
Example ServiceMeshPeer resource for red-mesh
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
| Parameter | Description | Values |
|---|---|---|
| Name of the peer mesh that this resource is configuring federation with. | String |
| System namespace for this mesh, that is, where the Service Mesh control plane is installed. | String |
| List of public addresses of the peer meshes' ingress gateways that are servicing requests from this mesh. | |
| The port on which the addresses are handling discovery requests. | Defaults to 8188 |
| The port on which the addresses are handling service requests. | Defaults to 15443 |
|
Name of the ingress on this mesh that is servicing requests received from the peer mesh. For example, | |
|
Name of the egress on this mesh that is servicing requests sent to the peer mesh. For example, | |
| The trust domain used by the peer mesh. | <peerMeshName>.local |
| The client ID used by the peer mesh when calling into this mesh. | <peerMeshTrustDomain>/ns/<peerMeshSystem>/sa/<peerMeshEgressGatewayName>-service-account |
|
The kind (for example, ConfigMap) and name of a resource containing the root certificate used to validate the client and server certificate(s) presented to this mesh by the peer mesh. The key of the config map entry containing the certificate should be | kind: ConfigMap name: <peerMesh>-ca-root-cert |
2.20.10.1. Creating a ServiceMeshPeer resource 링크 복사링크가 클립보드에 복사되었습니다!
Prerequisites
- Two or more OpenShift Container Platform 4.6 or above clusters.
- The clusters must already be networked.
- The load balancers supporting the services associated with the federation gateways must be configured to support raw TLS traffic.
-
Each cluster must have a version 2.1 or later
ServiceMeshControlPlaneconfigured to support federation deployed. -
An account with the
cluster-adminrole.
Procedure from the CLI
Follow this procedure to create a ServiceMeshPeer resource from the command line. This example shows the red-mesh creating a peer resource for the green-mesh.
Log in to the OpenShift Container Platform CLI as a user with the
cluster-adminrole. Enter the following command. Then, enter your username and password when prompted.$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443Change to the project where you installed the control plane, for example,
red-mesh-system.$ oc project red-mesh-systemCreate a
ServiceMeshPeerfile based the following example for the two meshes that you want to federate.Example ServiceMeshPeer resource for red-mesh to green-mesh
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-certRun the following command to deploy the resource, where
red-mesh-systemis the system namespace andservicemeshpeer.yamlincludes a full path to the file you edited:$ oc create -n red-mesh-system -f servicemeshpeer.yamlTo confirm that connection between the red mesh and green mesh is established, inspect the status of the green-mesh
ServiceMeshPeerin the red-mesh-system namespace:$ oc -n red-mesh-system get servicemeshpeer green-mesh -o yamlExample ServiceMeshPeer connection between red-mesh and green-mesh
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"The
status.discoveryStatus.active.remotesfield shows that istiod in the peer mesh (in this example, the green mesh) is connected to istiod in the current mesh (in this example, the red mesh).The
status.discoveryStatus.active.watchfield shows that istiod in the current mesh is connected to istiod in the peer mesh.If you check the
servicemeshpeernamedred-meshingreen-mesh-system, you can find information about the same two connections from the perspective of the green mesh.When the connection between two meshes is not established, the
ServiceMeshPeerstatus indicates this in thestatus.discoveryStatus.inactivefield.For more information on why a connection attempt failed, inspect the Istiod log, the access log of the egress gateway handling egress traffic for the peer, and the ingress gateway handling ingress traffic for the current mesh in the peer mesh.
For example, if the red mesh cannot connect to the green mesh, check the following logs:
- istiod-red-mesh in red-mesh-system
- egress-green-mesh in red-mesh-system
- ingress-red-mesh in green-mesh-system