Merge pull request #33203 from JStickler/OSSMDOC-217

OSSMDOC-217: Initial Service Mesh deployment model documentation.

Author: bergerhoffer

_topic_map.yml

@@ -2644,6 +2644,8 @@ Topics:
     File: ossm-support
   - Name: Service Mesh architecture
     File: ossm-architecture
+  - Name: Service mesh deployment models
+    File: ossm-deployment-models
   - Name: Service Mesh and Istio differences
     File: ossm-vs-community
   - Name: Preparing to install Service Mesh

modules/ossm-deploy-multi-mesh.adoc

@@ -0,0 +1,12 @@
+// Module included in the following assemblies:
+// * service_mesh/v2x/ossm-deploy-mod-v2x.adoc
+
+
+[id="ossm-deploy-multi-mesh_{context}"]
+= Multimesh or federated deployment model
+
+_Federation_ is a deployment model that lets you share services and workloads between separate meshes managed in distinct administrative domains.
+
+The Istio multi-cluster model requires a high level of trust between meshes and remote access to all Kubernetes API servers on which the individual meshes reside. {ProductName} federation takes an opinionated approach to a multi-cluster implementation of Service Mesh that assumes _minimal_ trust between meshes.
+
+A _federated mesh_ is a group of meshes behaving as a single mesh. The services in each mesh can be unique services, for example a mesh adding services by importing them from another mesh, can provide additional workloads for the same services across the meshes, providing high availability, or a combination of both. All meshes that are joined into a federated mesh remain managed individually, and you must explicitly configure which services are exported to and imported from other meshes in the federation. Support functions such as certificate generation, metrics and trace collection remain local in their respective meshes.

modules/ossm-deploy-multitenant.adoc

@@ -0,0 +1,15 @@
+// Module included in the following assemblies:
+// * service_mesh/v2x/ossm-deploy-mod-v2x.adoc
+
+[id="ossm-deploy-multitenant_{context}"]
+= Multitenant deployment model
+
+{ProductName} installs a `ServiceMeshControlPlane` that is configured for multitenancy by default. {ProductName} uses a multitenant Operator to manage the control plane lifecycle. Within a mesh, namespaces are used for tenancy.
+
+{ProductName} uses `ServiceMeshControlPlane` resources to manage mesh installations, whose scope is limited by default to namespace that contains the resource. You use `ServiceMeshMemberRoll` and `ServiceMeshMember` resources to include additional namespaces into the mesh. A namespace can only be included in a single mesh, and multiple meshes can be installed in a single OpenShift cluster.
+
+Typical service mesh deployments use a single control plane to configure communication between services in the mesh. {ProductName} supports “soft multitenancy”, where there is one control plane and one mesh per tenant, and there can be multiple independent control planes within the cluster. Multitenant deployments specify the projects that can access the {ProductShortName} and isolate the {ProductShortName} from other control plane instances.
+
+The cluster administrator gets control and visibility across all the Istio control planes, while the tenant administrator only gets control over their specific {ProductShortName}, Kiali, and Jaeger instances.
+
+You can grant a team permission to deploy its workloads only to a given namespace or set of namespaces. If granted the `mesh-user` role by the service mesh administrator, users can create a `ServiceMeshMember` resource to add namespaces to the `ServiceMeshMemberRoll`.

modules/ossm-deploy-single-mesh.adoc

@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+// * service_mesh/v2x/ossm-deploy-mod-v2x.adoc
+
+[id="ossm-deploy-single-mesh_{context}"]
+= Single mesh deployment model
+
+The simplest Istio deployment model is a single mesh.
+
+Service names within a mesh must be unique because Kubernetes only allows one service to be named `myservice` in the `mynamespace` namespace. However, workload instances can share a common identity since service account names can be shared across workloads in the same namespace

modules/ossm-deploy-single-tenant.adoc

@@ -0,0 +1,9 @@
+// Module included in the following assemblies:
+// * service_mesh/v2x/ossm-deploy-mod-v2x.adoc
+
+[id="ossm-deploy-single-tenant_{context}"]
+= Single tenancy deployment model
+
+In Istio, a tenant is a group of users that share common access and privileges for a set of deployed workloads. You can use tenants to provide a level of isolation between different teams. You can segregate access to different tenants using `NetworkPolicies`, `AuthorizationPolicies`, and `exportTo` annotations on istio.io or service resources.
+
+Single tenant, cluster-wide control plane configurations are deprecated as of {ProductName} version 1.0. {ProductName} defaults to a multitenant model.

service_mesh/v2x/ossm-deployment-models.adoc

@@ -0,0 +1,14 @@
+[id="ossm-deployment-models"]
+= Service mesh deployment models
+include::modules/ossm-document-attributes.adoc[]
+:context: ossm-deployment-models
+
+{ProductName} supports several different deployment models that can be combined in different ways to best suit your business requirements.
+
+include::modules/ossm-deploy-single-mesh.adoc[leveloffset=+1]
+
+include::modules/ossm-deploy-single-tenant.adoc[leveloffset=+1]
+
+include::modules/ossm-deploy-multitenant.adoc[leveloffset=+1]
+
+include::modules/ossm-deploy-multi-mesh.adoc[leveloffset=+1]