diff --git a/images/ossm-architecture.png b/images/ossm-architecture.png new file mode 100644 index 0000000000..fc6b8ea8ec Binary files /dev/null and b/images/ossm-architecture.png differ diff --git a/images/ossm-federated-mesh.png b/images/ossm-federated-mesh.png new file mode 100644 index 0000000000..c7af735dcf Binary files /dev/null and b/images/ossm-federated-mesh.png differ diff --git a/images/ossm-federation-export-service.png b/images/ossm-federation-export-service.png new file mode 100644 index 0000000000..242ef17976 Binary files /dev/null and b/images/ossm-federation-export-service.png differ diff --git a/images/ossm-federation-import-service.png b/images/ossm-federation-import-service.png new file mode 100644 index 0000000000..b5f5dcec2b Binary files /dev/null and b/images/ossm-federation-import-service.png differ diff --git a/images/ossm-federation.png b/images/ossm-federation.png new file mode 100644 index 0000000000..000505be8c Binary files /dev/null and b/images/ossm-federation.png differ diff --git a/modules/ossm-architecture.adoc b/modules/ossm-architecture.adoc index c20d5878ba..adc918161d 100644 --- a/modules/ossm-architecture.adoc +++ b/modules/ossm-architecture.adoc @@ -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. diff --git a/modules/ossm-federation-config-export.adoc b/modules/ossm-federation-config-export.adoc index e7666e2e56..73650a8dea 100644 --- a/modules/ossm-federation-config-export.adoc +++ b/modules/ossm-federation-config-export.adoc @@ -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. diff --git a/modules/ossm-federation-config-import.adoc b/modules/ossm-federation-config-import.adoc index e7819823e9..3770194f0b 100644 --- a/modules/ossm-federation-config-import.adoc +++ b/modules/ossm-federation-config-import.adoc @@ -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. diff --git a/modules/ossm-federation-config-meshPeer.adoc b/modules/ossm-federation-config-meshPeer.adoc index a4c8ff0a26..36f2c177db 100644 --- a/modules/ossm-federation-config-meshPeer.adoc +++ b/modules/ossm-federation-config-meshPeer.adoc @@ -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.