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:
committed by
openshift-cherrypick-robot
parent
e3c9229b45
commit
91987793ae
BIN
images/ossm-architecture.png
Normal file
BIN
images/ossm-architecture.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 46 KiB |
BIN
images/ossm-federated-mesh.png
Normal file
BIN
images/ossm-federated-mesh.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
BIN
images/ossm-federation-export-service.png
Normal file
BIN
images/ossm-federation-export-service.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
BIN
images/ossm-federation-import-service.png
Normal file
BIN
images/ossm-federation-import-service.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 54 KiB |
BIN
images/ossm-federation.png
Normal file
BIN
images/ossm-federation.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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 mesh’s 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.
|
||||
|
||||
Reference in New Issue
Block a user