1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00

OSSMDOC-382: add federation images to existing docs

This commit is contained in:
rh-tokeefe
2021-10-04 13:59:49 -04:00
committed by openshift-cherrypick-robot
parent e3c9229b45
commit 91987793ae
9 changed files with 7 additions and 3 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 46 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 41 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 40 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 54 KiB

BIN
images/ossm-federation.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 34 KiB

View File

@@ -7,7 +7,9 @@
Service mesh technology operates at the network communication level. That is, service mesh components capture or intercept traffic to and from microservices, either modifying requests, redirecting them, or creating new requests to other services.
At a high level, {ProductName} consists of a data plane and a control plane:
image::ossm-architecture.png[Service Mesh architecture image]
At a high level, {ProductName} consists of a data plane and a control plane
The *data plane* is a set of intelligent proxies, running alongside application containers in a pod, that intercept and control all inbound and outbound network communication between microservices in the service mesh.
The data plane is implemented in such a way that it intercepts all inbound (ingress) and outbound (egress) network traffic. The Istio data plane is composed of Envoy containers running along side application containers in a pod. The Envoy container acts as a proxy, controlling all network communication into and out of the pod.

View File

@@ -8,7 +8,7 @@ This module included in the following assemblies:
Exporting services allows a mesh to share one or more of its services with another member of the federated mesh.
//Insert ExportedServiceSet diagram here
image::ossm-federation-export-service.png[Service Mesh federation exporting service illustration]
You use an `ExportedServiceSet` resource to declare the services from one mesh that you are making available to another peer in the federated mesh. You must explicitly declare each service to be shared with a peer.

View File

@@ -8,7 +8,7 @@ This module included in the following assemblies:
Importing services lets you explicitly specify which services exported from another mesh should be accessible within your service mesh.
//Insert ImportedServiceSet diagram here
image::ossm-federation-import-service.png[Service Mesh federation importing service illustration]
You use an `ImportedServiceSet` resource to select services for import. Only services exported by a mesh peer and explicitly imported are available to the mesh. Services that you do not explicitly import are not made available within the mesh.

View File

@@ -8,6 +8,8 @@ This module included in the following assemblies:
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 meshs clients.
image::ossm-federated-mesh.png[Service Mesh federated mesh peers illustration]
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 `ServiceMeshPeer` for the green mesh.