diff --git a/content/en/docs/ops/deployment/deployment-models/index.md b/content/en/docs/ops/deployment/deployment-models/index.md index d8f81cb5d3..71eb97163e 100644 --- a/content/en/docs/ops/deployment/deployment-models/index.md +++ b/content/en/docs/ops/deployment/deployment-models/index.md @@ -476,17 +476,15 @@ To avoid service naming collisions, you can give each mesh a globally unique name (FQDN) for each service is distinct. When federating two meshes that do not share the same -{{< gloss >}}trust domain{{< /gloss >}}, you must -{{< gloss "mesh federation">}}federate{{< /gloss >}} +{{< gloss >}}trust domain{{< /gloss >}}, you must federate {{< gloss >}}identity{{< /gloss >}} and **trust bundles** between them. See the -section on [Multiple Trust Domains](#trust-between-meshes) for an overview. +section on [Trust between meshes](#trust-between-meshes) for more details. ## Tenancy models In Istio, a **tenant** is a group of users that share -common access and privileges to a set of deployed workloads. Generally, you -isolate the workload instances from multiple tenants from each other through -network configuration and policies. +common access and privileges for a set of deployed workloads. +Tenants can be used to provide a level of isolation between different teams. You can configure tenancy models to satisfy the following organizational requirements for isolation: @@ -497,30 +495,22 @@ requirements for isolation: - Cost - Performance -Istio supports two types of tenancy models: +Istio supports three types of tenancy models: - [Namespace tenancy](#namespace-tenancy) - [Cluster tenancy](#cluster-tenancy) +- [Mesh tenancy](#mesh-tenancy) ### Namespace tenancy -Istio uses [namespaces](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-namespace) -as a unit of tenancy within a mesh. Istio also works in environments that don't -implement namespace tenancy. In environments that do, you can grant a team -permission to deploy their workloads only to a given namespace or set of -namespaces. By default, services from multiple tenant namespaces can communicate -with each other. +A cluster can be shared across multiple teams, each using a different namespace. +You can grant a team permission to deploy its workloads only to a given namespace +or set of namespaces. -{{< image width="50%" - link="iso-ns.svg" - alt="A service mesh with two isolated namespaces" - title="Isolated namespaces" - caption="A service mesh with two isolated namespaces" - >}} - -To improve isolation, you can selectively choose which services to expose to -other namespaces. You can configure authorization policies for exposed services -to restrict access to only the appropriate callers. +By default, services from multiple namespaces can communicate with each other, +but you can increase isolation by selectively choosing which services to expose to other +namespaces. You can configure authorization policies for exposed services to restrict +access to only the appropriate callers. {{< image width="50%" link="exp-ns.svg" @@ -529,10 +519,11 @@ to restrict access to only the appropriate callers. caption="A service mesh with two namespaces and an exposed service" >}} +Namespace tenancy can extend beyond a single cluster. When using [multiple clusters](#multiple-clusters), the namespaces in each -cluster sharing the same name are considered the same namespace. For example, -`Service B` in the `foo` namespace of `cluster-1` and `Service B` in the -`foo` namespace of `cluster-2` refer to the same service, and Istio merges their +cluster sharing the same name are considered the same namespace by default. +For example, `Service B` in the `Team-1` namespace of cluster `West` and `Service B` in the +`team-1` namespace of cluster `East` refer to the same service, and Istio merges their endpoints for service discovery and load balancing. {{< image width="50%" @@ -553,11 +544,17 @@ example: - Cluster administrator - Developer -To use cluster tenancy with Istio, you configure each cluster as an independent -mesh. Alternatively, you can use Istio to implement a group of clusters as a -single tenant. Then, each team can own one or more clusters, but you configure -all their clusters as a single mesh. To connect the meshes of the various teams -together, you can federate the meshes into a multi-mesh deployment. +To use cluster tenancy with Istio, you configure each team's cluster with its +own {{< gloss >}}control plane{{< /gloss >}}, allowing each team to manage its own configuration. +Alternatively, you can use Istio to implement a group of clusters as a single tenant +using {{< gloss "remote cluster" >}}remote clusters{{< /gloss >}} or multiple +synchronized {{< gloss "primary cluster" >}}primary clusters{{< /gloss >}}. +Refer to [control plane models](#control-plane-models) for details. + +### Mesh Tenancy + +In a multi-mesh deployment with {{< gloss >}}mesh federation{{< /gloss >}}, each mesh +can be used as the unit of isolation. {{< image width="50%" link="cluster-iso.svg" @@ -567,11 +564,11 @@ together, you can federate the meshes into a multi-mesh deployment. >}} Since a different team or organization operates each mesh, service naming -is rarely distinct. For example, the `mysvc` in the `foo` namespace of -`cluster-1` and the `mysvc` service in the `foo` namespace of -`cluster-2` do not refer to the same service. The most common example is the +is rarely distinct. For example, a `Service C` in the `foo` namespace of +cluster `Team-1` and the `Service C` service in the `foo` namespace of cluster +`Team-2` will not refer to the same service. The most common example is the scenario in Kubernetes where many teams deploy their workloads to the `default` namespace. -When each team has their own mesh, cross-mesh communication follows the +When each team has its own mesh, cross-mesh communication follows the concepts described in the [multiple meshes](#multiple-meshes) model. diff --git a/content/en/docs/ops/deployment/deployment-models/iso-ns.svg b/content/en/docs/ops/deployment/deployment-models/iso-ns.svg deleted file mode 100644 index b404bd3201..0000000000 --- a/content/en/docs/ops/deployment/deployment-models/iso-ns.svg +++ /dev/null @@ -1 +0,0 @@ -Istio MeshNamespace: Team-1Namespace: Team-2Service CService AService DService B \ No newline at end of file