Add Istio Deployment Models concept. (#4813)

* Add Istio Deployment Models concept.

This concept replaces the old multi-cluster concept.
Includes new diagrams that comply with the diagram creation guidelines.
Updates the Chinese content to use a local copy of the previous diagrams.
Fixes all internal links to the previous version of the doc.

Signed-off-by: rcaballeromx <grca@google.com>

* Add glossary entries for needed terms.

The terms involved are:

    - Cluster
    - Identity
    - Trust domain

Signed-off-by: rcaballeromx <grca@google.com>

* Define cluster in a platform agnostic way.

Also adds links between `identity` and `trust domain`.

Signed-off-by: rcaballeromx <grca@google.com>

* Add missing `(` in links.

Signed-off-by: rcaballeromx <grca@google.com>

* Fix links to sections and reduce image sizes.

Signed-off-by: rcaballeromx <grca@google.com>

* Simplify the definition of `trust domain`

Signed-off-by: rcaballeromx <grca@google.com>

* Move old images to the ZH content.

Signed-off-by: rcaballeromx <grca@google.com>

* Add reworked control plane content.

Also addresses the comments left on the PR including those regarding the
diagrams.

Signed-off-by: rcaballeromx <grca@google.com>

* Add fail over example and glossary entries.

This update also reworks the control plane models section to fit the example.
Additional adjustments were made to the diagrams too.

Signed-off-by: rcaballeromx <grca@google.com>

* Move mesh models section.

Also minor fixes and edits.

Signed-off-by: rcaballeromx <grca@google.com>

* Fix glossary entries and links.

Signed-off-by: rcaballeromx <grca@google.com>

content/en/blog/2019/announcing-1.1/index.md

@@ -36,16 +36,16 @@ We’ve done work around namespace isolation as well. This lets you use
 Kubernetes namespaces to enforce boundaries of control, and ensures that your
 teams cannot interfere with each other.
 
-We have also improved the [multicluster capabilities and usability](/docs/concepts/multicluster-deployments/).
+We have also improved the [multicluster capabilities and usability](/docs/concepts/deployment-models/).
 We listened to the community and improved defaults for traffic control and
 policy. We introduced a new component called
 [Galley](/docs/concepts/what-is-istio/#galley). Galley validates that sweet,
 sweet YAML, reducing the chance of configuration errors. Galley will also be
 instrumental in [multicluster setups](/docs/setup/install/multicluster/),
 gathering service discovery information from each Kubernetes cluster. We are
-also supporting additional multicluster topologies including [shared control plane](/docs/concepts/multicluster-deployments/#shared-control-plane-topology)
+also supporting additional multicluster topologies including different
-and [dedicated control plane](/docs/concepts/multicluster-deployments/#dedicated-control-plane-topology) topologies
+[control plane models](/docs/concepts/deployment-models/#control-plane-models)
-without requiring a flat network.
+topologies without requiring a flat network.
 
 There is lots more -- see the [release notes](/about/notes/1.1/) for complete
 details.

content/en/blog/2019/multicluster-version-routing/index.md

@@ -17,10 +17,10 @@ wondering if all these things will be just as simple in your real production env
 Fortunately, Istio provides several ways to configure a service mesh so that applications
 can, more-or-less transparently, be part of a mesh where the services are running
 in more than one cluster, i.e., in a
-[multicluster service mesh](/docs/concepts/multicluster-deployments/#multicluster-service-mesh).
+[multi-cluster deployment](/docs/concepts/deployment-models/#multiple-clusters).
-The simplest way to setup a multicluster mesh, because it has no special networking requirements,
+The simplest way to setup a multi-cluster mesh, because it has no special networking requirements,
-is using a
+is using a simple
-[dedicated control plane topology](/docs/concepts/multicluster-deployments/#dedicated-control-plane-topology).
+[control plane model](/docs/concepts/deployment-models/#control-plane-models).
 In this configuration, each Kubernetes cluster contributing to the mesh has its own control plane,
 but each control plane is synchronized and running under a single administrative control.
 
@@ -453,8 +453,8 @@ only see reviews without ratings (`v1`).
 ## Summary
 
 In this article, we've seen how to use Istio route rules to distribute the versions of a service
-across clusters in a multicluster service mesh with a
+across clusters in a multicluster service mesh with a suitable
-[dedicated control plane topology](/docs/concepts/multicluster-deployments/#dedicated-control-plane-topology).
+[control plane model](/docs/concepts/deployment-models/#control-plane-models).
 In this example, we manually configured the `.global` service entry and destination rules needed to provide
 connectivity to one remote service, `reviews`. In general, however, if we wanted to enable any service
 to run either locally or remotely, we would need to create `.global` resources for every service.

content/en/docs/concepts/deployment-models/index.md

@@ -0,0 +1,396 @@
+---
+title: Deployment Models
+description: Describes the system models that impact your overall Istio depolyment.
+weight: 60
+keywords:
+- single-cluster
+- multiple-clusters
+- control-plane
+- tenancy
+- networks
+- identity
+- trust
+- single-mesh
+- multiple-meshes
+aliases:
+- /docs/concepts/multicluster-deployments/
+---
+
+Important system models impact your overall Istio deployment model. This page
+discusses the options for each of these models and describes how you can
+configure Istio to address them.
+
+## Cluster models
+
+The workload instances of your application run in one or more
+{{< gloss "cluster" >}}clusters{{< /gloss >}}. For isolation, performance, and
+high availability, you can confine clusters to availability zones and regions.
+
+Production systems, depending on their requirements, can run across multiple
+clusters spanning a number of zones or regions, leveraging cloud load balancers
+to handle things like locality and zonal or regional fail over.
+
+In most cases, clusters represent boundaries for configuration and endpoint
+discovery. For example, each Kubernetes cluster has an API Server which manages
+the configuration for the cluster as well as serving
+{{< gloss >}}service endpoint{{< /gloss >}} information as pods are brought up
+or down. Since Kubernetes configures this behavior on a per-cluster basis, this
+approach helps limit the potential problems caused by incorrect configurations.
+
+In Istio, you can configure a single service mesh to span any number of
+clusters.
+
+### Single cluster
+
+In the simplest case, you can confine an Istio mesh to a single
+{{< gloss >}}cluster{{< /gloss >}}. A cluster usually operates over a
+[single network](#single-network), but it varies between infrastructure
+providers. A single cluster and single network model includes a control plane,
+which results in the simplest Istio deployment.
+
+{{< image width="50%"
+    link="single-cluster.svg"
+    alt="A service mesh with a single cluster"
+    title="Single cluster"
+    caption="A service mesh with a single cluster"
+    >}}
+
+Single cluster deployments offer simplicity, but lack other features, for
+example, fault isolation and fail over. If you need higher availability, you
+should use multiple clusters.
+
+### Multiple clusters
+
+You can configure a single mesh to include
+multiple {{< gloss "cluster" >}}clusters{{< /gloss >}}. Using a
+{{< gloss >}}multi-cluster{{< /gloss >}} deployment within a single mesh affords
+the following capabilities beyond that of a single cluster deployment:
+
+- Fault isolation and fail over: `cluster-1` goes down, fail over to `cluster-2`.
+- Location-aware routing and fail over: Send requests to the nearest service.
+- Various [control plane models](#control-plane-models): Support different
+  levels of availability.
+- Team or project isolation: Each team runs its own set of clusters.
+
+{{< image width="75%"
+    link="multi-cluster.svg"
+    alt="A service mesh with multiple clusters"
+    title="Multi-cluster"
+    caption="A service mesh with multiple clusters"
+    >}}
+
+Multi-cluster deployments give you a greater degree of isolation and
+availability but increase complexity. If your systems have high availability
+requirements, you likely need clusters across multiple zones and regions. You
+can canary configuration changes or new binary releases in a single cluster,
+where the configuration changes only affect a small amount of user traffic.
+Additionally, if a cluster has a problem, you can temporarily route traffic to
+nearby clusters until you address the issue.
+
+You can configure inter-cluster communication based on the
+[network](#network-models) and the options supported by your cloud provider. For
+example, if two clusters reside on the same underlying network, you can enable
+cross-cluster communication by simply configuring firewall rules.
+
+## Network models
+
+Many production systems require multiple networks or subnets for isolation
+and high availability. Istio supports spanning a service mesh over a variety of
+network topologies. This approach allows you to select the network model that
+fits your existing network topology.
+
+### Single network
+
+In the simplest case, a service mesh operates over a single fully connected
+network. In a single network model, all
+{{< gloss "workload instance" >}}workload instances{{< /gloss >}}
+can reach each other directly without an Istio gateway.
+
+A single network allows Istio to configure service consumers in a uniform
+way across the mesh with the ability to directly address workload instances.
+
+{{< image width="50%"
+    link="single-net.svg"
+    alt="A service mesh with a single network"
+    title="Single network"
+    caption="A service mesh with a single network"
+    >}}
+
+### Multiple networks
+
+You can span a single service mesh across multiple networks; such a
+configuration is known as **multi-network**.
+
+Multiple networks afford the following capabilities beyond that of single networks:
+
+- Overlapping IP or VIP ranges for **service endpoints**
+- Crossing of administrative boundaries
+- Fault tolerance
+- Scaling of network addresses
+- Compliance with standards that require network segmentation
+
+In this model, the workload instances in different networks can only reach each
+other through one or more [Istio gateways](/docs/concepts/traffic-management/#gateways).
+Istio uses **partitioned service discovery** to provide consumers a different
+view of {{< gloss >}}service endpoint{{< /gloss >}}s. The view depends on the
+network of the consumers.
+
+{{< image width="50%"
+    link="multi-net.svg"
+    alt="A service mesh with multiple networks"
+    title="Multi-network deployment"
+    caption="A service mesh with multiple networks"
+    >}}
+
+## Control plane models
+
+An Istio mesh uses the {{< gloss >}}control plane{{< /gloss >}} to configure all
+communication between workload instances within the mesh. You can replicate the
+control plane, and workload instances connect to any control plane instance to
+get their configuration.
+
+In the simplest case, you can run your mesh with a control plane on a single
+cluster.
+
+{{< image width="50%"
+    link="single-cluster.svg"
+    alt="A service mesh with a control plane"
+    title="Single control plane"
+    caption="A service mesh with a control plane"
+    >}}
+
+Multi-cluster deployments can also share control plane instances. In this case,
+the control plane instances can reside in one or more clusters.
+
+{{< image width="75%"
+    link="shared-control.svg"
+    alt="A service mesh with two clusters sharing a control plane"
+    title="Shared control plane"
+    caption="A service mesh with two clusters sharing a control plane"
+    >}}
+
+For high availability, you should deploy a control plane across multiple
+clusters, zones, or regions.
+
+{{< image width="75%"
+    link="multi-control.svg"
+    alt="A service mesh with control plane instances for each region"
+    title="Multiple control planes"
+    caption="A service mesh with control plane instances for each region"
+    >}}
+
+This model affords the following benefits:
+
+- Improved availability: If a control plane becomes unavailable, the scope of
+  the outage is limited to only that control plane.
+
+- Configuration isolation: You can make configuration changes in one cluster,
+  zone, or region without impacting others.
+
+You can improve control plane availability through fail over. When a control
+plane instance becomes unavailable, workload instances can connect to
+another available control plane instance. Fail over can happen across clusters,
+zones, or regions.
+
+{{< image width="50%"
+    link="failover.svg"
+    alt="A service mesh after a control plane instance fails"
+    title="Control plane fail over"
+    caption="A service mesh after a control plane instance fails"
+    >}}
+
+The following list ranks control plane deployment examples by availability:
+
+- One cluster per region (**lowest availability**)
+- Multiple clusters per region
+- One cluster per zone
+- Multiple clusters per zone
+- Each cluster (**highest availability**)
+
+## Identity and trust models
+
+When a workload instance is created within a service mesh, Istio assigns the
+workload an {{< gloss >}}identity{{< /gloss >}}.
+
+The Certificate Authority (CA) creates and signs the certificates used to verify
+the identities used within the mesh. You can verify the identity of the message sender
+with the public key of the CA that created and signed the certificate
+for that identity. A **trust bundle** is the set of all CA public keys used by
+an Istio mesh. With a mesh's trust bundle, anyone can verify the sender of any
+message coming from that mesh.
+
+### Trust within a mesh
+
+Within a single Istio mesh, Istio ensures each workload instance has an
+appropriate certificate representing its own identity, and the trust bundle
+necessary to recognize all identities within the mesh and any federated meshes.
+The CA only creates and signs the certificates for those identities. This model
+allows workload instances in the mesh to authenticate each other when
+communicating.
+
+{{< image width="50%"
+    link="single-trust.svg"
+    alt="A service mesh with a certificate authority"
+    title="Trust within a mesh"
+    caption="A service mesh with a certificate authority"
+    >}}
+
+### Trust between meshes
+
+If a service in a mesh requires a service in another, you must federate identity
+and trust between the two meshes. To federate identity and trust, you must
+exchange the trust bundles of the meshes. You can exchange the trust bundles
+either manually or automatically using a protocol such as [SPIFFE Trust Domain Federation](https://docs.google.com/document/d/1OC9nI2W04oghhbEDJpKdIUIw-G23YzWeHZxwGLIkB8k/edit).
+Once you import a trust bundle to a mesh, you can configure local policies for
+those identities.
+
+{{< image width="50%"
+    link="multi-trust.svg"
+    alt="Multiple service meshes with certificate authorities"
+    title="Trust between meshes"
+    caption="Multiple service meshes with certificate authorities"
+    >}}
+
+## Mesh models
+
+Istio supports having all of your services in a
+{{< gloss "service mesh" >}}mesh{{< /gloss >}}, or federating multiple meshes
+together, which is also known as {{< gloss >}}multi-mesh{{< /gloss >}}.
+
+### Single mesh
+
+The simplest Istio deployment is a single mesh. Within a mesh, service names are
+unique. For example, only one service can have the name `mysvc` in the `foo`
+namespace. Additionally, workload instances share a common identity since
+service account names are unique within a namespace, just like service names.
+
+A single mesh can span [one or more clusters](#cluster-models) and
+[one or more networks](#network-models). Within a mesh,
+[namespaces](#namespace-tenancy) are used for [tenancy](#tenancy-models).
+
+### Multiple meshes
+
+Multiple mesh deployments result from {{< gloss >}}mesh federation{{< /gloss >}}.
+
+Multiple meshes afford the following capabilities beyond that of a single mesh:
+
+- Organizational boundaries: lines of business
+- Service name or namespace reuse: multiple distinct uses of the `default`
+  namespace
+- Stronger isolation: isolating test workloads from production workloads
+
+You can enable inter-mesh communication with {{< gloss >}}mesh federation{{<
+/gloss >}}. When federating, each mesh can expose a set of services and
+identities, which all participating meshes can recognize.
+
+{{< image width="50%"
+    link="multi-mesh.svg"
+    alt="Multiple service meshes"
+    title="Multi-mesh"
+    caption="Multiple service meshes"
+    >}}
+
+To avoid service naming collisions, you can give each mesh a globally unique
+**mesh ID**, to ensure that the fully qualified domain
+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 >}}identity{{< /gloss >}} and **trust bundles** between them. See the
+section on [Multiple Trust Domains](#trust-between-meshes) for an overview.
+
+## 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.
+
+You can configure tenancy models to satisfy the following organizational
+requirements for isolation:
+
+- Security
+- Policy
+- Capacity
+- Cost
+- Performance
+
+Istio supports two types of tenancy models:
+
+- [Namespace tenancy](#namespace-tenancy)
+- [Cluster tenancy](#cluster-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.
+
+{{< 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.
+
+{{< image width="50%"
+    link="exp-ns.svg"
+    alt="A service mesh with two namespaces and an exposed service"
+    title="Namespaces with an exposed service"
+    caption="A service mesh with two namespaces and an exposed service"
+    >}}
+
+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
+endpoints for service discovery and load balancing.
+
+{{< image width="50%"
+    link="cluster-ns.svg"
+    alt="A service mesh with two clusters with the same namespace"
+    title="Multi-cluster namespaces"
+    caption="A service mesh with clusters with the same namespace"
+    >}}
+
+### Cluster tenancy
+
+Istio supports using clusters as a unit of tenancy. In this case, you can give
+each team a dedicated cluster or set of clusters to deploy their
+workloads. Permissions for a cluster are usually limited to the members of the
+team that owns it. You can set various roles for finer grained control, for
+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.
+
+{{< image width="50%"
+    link="cluster-iso.svg"
+    alt="Two isolated service meshes with two clusters and two namespaces"
+    title="Cluster isolation"
+    caption="Two isolated service meshes with two clusters and two namespaces"
+    >}}
+
+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
+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
+concepts described in the [multiple meshes](#multiple-meshes) model.

content/en/docs/concepts/multicluster-deployments/index.md

@@ -1,130 +0,0 @@
----
-title: Multicluster Deployments
-description: Describes how a service mesh can be configured to include services from more than one cluster.
-weight: 60
----
-
-Istio is a [service mesh](/docs/concepts/what-is-istio/#what-is-a-service-mesh),
-the fundamental property of which is its ability to monitor and manage
-a network of cooperating microservices under a single administrative domain.
-A service mesh essentially combines a set of individual microservices into
-a single controllable composite application.
-
-For applications up to a certain size, all of the microservices comprising the
-application can be running on a single orchestration platform (e.g., Kubernetes cluster).
-However, for many reasons such as scale, redundancy, compliance, etc., most applications
-will eventually need to be distributed and have some of their services running elsewhere.
-
-Istio supports many possible topologies for distributing the services of an
-application beyond a single cluster, for example:
-
-* Services within the mesh can use [service entries](/docs/concepts/traffic-management/#service-entries)
-  to access standalone external services or to access services exposed by another loosely-coupled service mesh.
-* You can [expand the service mesh](/docs/examples/mesh-expansion/) to include
-  services running on VMs or bare metal hosts.
-* You can combine the services from more than one cluster into a single composite service mesh.
-
-## Multicluster service mesh
-
-A multicluster service mesh is a mesh composed of services running within more than one underlying
-cluster but with all services running under a single administrative control.
-In a multicluster service mesh, a service named `foo` in namespace `ns1` of cluster 1 is the same service
-as `foo` in `ns1` of cluster 2.
-This is different from a loosely-coupled service mesh where two clusters may have different
-definitions of the same service which will need to be reconciled when integrating the clusters.
-
-A multicluster service mesh has the advantage that all the services look the same to clients,
-regardless of where the workloads are actually running. It's transparent
-to the application whether it's deployed in a single or multicluster service mesh.
-To achieve this behavior, a single logical control plane needs to manage all services,
-however, the single logical control plane doesn't necessarily need to be a single physical
-Istio control plane. There are two possible deployment approaches:
-
-1. Multiple Istio control planes that have replicated service and routing configurations.
-
-1. A shared Istio control plane that can access and configure the services in more than one cluster.
-
-Even with these two approaches, there is more than one way to configure a multicluster service mesh.
-In a large multicluster mesh, a combination of the approaches might even be used. For example,
-two clusters might share a control plane while a third has its own.
-Which approach to use and how to configure it depends on the requirements of the application
-and on the features and limitations of the underlying cloud deployment platform.
-
-### Dedicated control plane topology
-
-In a dedicated control plane topology, each cluster has an identical Istio control plane
-installation and each control plane manages its own endpoints.
-Using Istio gateways, a common root Certificate Authority (CA), and service entries,
-you can configure a single logical service mesh that is composed from the participating clusters.
-This approach has no special networking requirements beyond a functional cloud provider's load balancer
-implementation and is therefore generally considered the easiest approach to start with when
-there is no universal network connectivity between clusters.
-
-{{< image width="80%"
-    link="./multicluster-with-gateways.svg"
-    caption="Istio mesh spanning multiple Kubernetes clusters using multiple Istio control planes and Gateway to reach remote pods"
->}}
-
-To achieve a single Istio service mesh across the clusters, you configure a common root CA
-and replicate any shared services and namespaces in all clusters.
-Cross-cluster communication occurs over the Istio gateways of the respective clusters.
-All clusters are within a shared administrative control for policy enforcement and security.
-
-In this configuration workloads in each cluster can access other local services using their
-Kubernetes DNS suffix, e.g., `foo.ns1.svc.cluster.local`, as usual.
-To provide DNS resolution for services in remote clusters, Istio includes a CoreDNS server
-that can be configured to handle service names of the form `<name>.<namespace>.global`.
-For example, calls from any cluster to `foo.ns1.global` will resolve to the `foo` service in
-namespace `ns1` of a specific cluster where it is running as determined by the service discovery
-configuration. You configure service discovery of `foo.ns.global` by creating an appropriate
-[service entry](/docs/concepts/traffic-management/#service-entries).
-
-To configure this type of multicluster topology, visit our
-[dedicated control planes instructions](/docs/setup/install/multicluster/gateways/).
-
-### Shared control plane topology
-
-This multicluster configuration uses a single Istio control plane running on one of the clusters.
-The control plane's Pilot manages services on the local and remote clusters and configures the
-Envoy sidecars for all of the clusters.
-
-#### Single-network shared control plane topology
-
-The following topology works best in environments where all of the participating clusters
-have VPN or similar connectivity so every pod in the mesh is reachable from anywhere else using the
-same IP address.
-
-{{< image width="80%"
-    link="./multicluster-with-vpn.svg"
-    caption="Istio mesh spanning multiple Kubernetes clusters with direct network access to remote pods over VPN"
->}}
-
-In this topology, the Istio control plane is deployed on one of the clusters while all other
-clusters run a simpler remote Istio configuration which connects them to the single Istio control plane
-that manages all of the Envoy's as a single mesh. The IP addresses on the various clusters must not
-overlap and DNS resolution for services on remote clusters is not automatic. Users need to replicate
-the services on every participating cluster.
-
-To configure this type of multicluster topology, visit our
-[single-network shared control plane instructions](/docs/setup/install/multicluster/shared-vpn/).
-
-#### Multi-network shared control plane topology
-
-If setting up an environment with universal pod-to-pod connectivity is difficult or impossible,
-it may still be possible to configure a shared control plane topology using Istio gateways and
-by enabling Istio Pilot's location-aware service routing feature.
-
-This topology requires connectivity to Kubernetes API servers from all of the clusters. If this is
-not possible, a dedicated control plane topology is probably a better alternative.
-
-{{< image width="80%"
-    link="./multicluster-split-horizon-eds.svg"
-    caption="Istio mesh spanning multiple Kubernetes clusters using single Istio control plane and Gateway to reach remote pods"
->}}
-
-In this topology, a request from a sidecar in one cluster to a service in the same cluster
-is forwarded to the local service IP as usual. If the destination workload is running in a
-different cluster, the remote cluster Gateway IP is used to connect to the service instead.
-
-To configure this type of multicluster topology, visit our
-[multi-network shared control plane instructions](/docs/setup/install/multicluster/shared-gateways/).

content/en/docs/examples/multicluster/_index.md

@@ -4,5 +4,5 @@ description: Multicluster service mesh examples for Istio that you can experimen
 weight: 100
 keywords: [multicluster]
 ---
-Refer to the [multicluster service mesh](/docs/concepts/multicluster-deployments/) concept documentation
+Refer to the [multicluster service mesh](/docs/concepts/deployment-models/) concept documentation
 for more information.

content/en/docs/examples/multicluster/gke/index.md

@@ -8,7 +8,7 @@ aliases:
 ---
 
 This example shows how to configure a multicluster mesh with a
-[single-network shared control plane topology](/docs/concepts/multicluster-deployments/#single-network-shared-control-plane-topology)
+[single-network deployment](/docs/concepts/deployment-models/#single-network)
 over 2 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) clusters.
 
 ## Before you begin

content/en/docs/examples/multicluster/icp/index.md

@@ -10,7 +10,7 @@ aliases:
 This example demonstrates how to setup network connectivity between two
 [IBM Cloud Private](https://www.ibm.com/cloud/private) clusters
 and then compose them into a multicluster mesh using a
-[single-network shared control plane topology](/docs/concepts/multicluster-deployments/#single-network-shared-control-plane-topology).
+[single-network deployment](/docs/concepts/deployment-models/#single-network).
 
 ## Create the IBM Cloud Private Clusters
 

content/en/docs/reference/glossary/cluster.md

@@ -0,0 +1,7 @@
+---
+title: Cluster
+---
+
+A cluster is set of compute nodes that run containerized applications.
+Typically, the compute nodes comprising a cluster can reach each other directly.
+Clusters limit external access through rules or policies.

content/en/docs/reference/glossary/control-plane.md

@@ -0,0 +1,7 @@
+---
+title: Control Plane
+---
+
+A control plane is a set of one or more instances that share the
+same configuration source. The control plane configures the mesh or a subset of
+the mesh to manage the communication between the workload instances within.

content/en/docs/reference/glossary/identity.md

@@ -0,0 +1,43 @@
+---
+title: Identity
+---
+
+Identity is a fundamental security infrastructure concept. The Istio identity
+model is based on a first-class workload identity. At the beginning of
+service-to-service communication, the two parties exchange credentials with
+their identity information for mutual authentication purposes.
+
+Clients check the server’s identity against their secure naming information to
+determine if the server is authorized to run the service.
+
+Servers check the client's identity to determine what information the client can
+access. Servers base that determination on the configured authorization
+policies.
+
+Using identity, servers can audit the time information was accessed and what
+information was accessed by a specific client. They can also charge clients
+based on the services they use and reject any clients that failed to pay their
+bill from accessing the services.
+
+The Istio identity model is flexible and granular enough to represent a human
+user, an individual service, or a group of services. On platforms without
+first-class service identity, Istio can use other identities that can group
+service instances, such as service names.
+
+Istio supports the following service identities on different platforms:
+
+- Kubernetes: Kubernetes service account
+
+- GKE/GCE: GCP service account
+
+- GCP: GCP service account
+
+- AWS: AWS IAM user/role account
+
+- On-premises (non-Kubernetes): user account, custom service account, service
+  name, Istio service account, or GCP service account. The custom service
+  account refers to the existing service account just like the identities that
+  the customer’s Identity Directory manages.
+
+Typically, the [trust domain](/docs/reference/glossary/#trust-domain) specifies
+the mesh the identity belongs to.

content/en/docs/reference/glossary/mesh-federation.md

@@ -0,0 +1,9 @@
+---
+title: Mesh Federation
+---
+
+Mesh federation is the act of exposing services between meshes and enabling
+communication across mesh boundaries. Each mesh may expose a subset of its
+services to enable one or more other meshes to consume the exposed services. You
+can use mesh federation to enable communication between meshes in a
+[multi-mesh deployment](/docs/concepts/deployment-models/#multiple-meshes).

content/en/docs/reference/glossary/multi-cluster.md

@@ -0,0 +1,7 @@
+---
+title: Multi-Cluster
+---
+
+Multi-cluster is a deployment model that consists of a
+[mesh](/docs/reference/glossary/#service-mesh) with multiple
+[clusters](/docs/reference/glossary/#cluster).

content/en/docs/reference/glossary/multi-mesh.md

@@ -0,0 +1,8 @@
+---
+title: Multi-Mesh
+---
+
+Multi-mesh is a deployment model that consists of two or more [service meshes](/docs/reference/glossary/#service-mesh).
+Each mesh has independent administration for naming and identities but you can
+expose services between meshes through [mesh federation](/docs/reference/glossary/#mesh-federation).
+The resulting deployment is a multi-mesh deployment.

content/en/docs/reference/glossary/service-endpoint.md

@@ -2,5 +2,5 @@
 title: Service Endpoint
 ---
 The network-reachable manifestation of a [service](#service).
-Service endpoints are exposed by [workload instances](#workload-instance).
+[Workload instances](#workload-instance) expose service endpoints but not all
-Not all services have service endpoints.
+services have service endpoints.

content/en/docs/reference/glossary/service-mesh.md

@@ -1,5 +1,14 @@
 ---
 title: Service Mesh
 ---
-A shared set of names and identities that allows for common policy enforcement and telemetry collection.
+A *service mesh* or simply *mesh* is an infrastructure layer that enables
-[Service names](#service-name) and [workload instance principals](#workload-instance-principal) are unique within a service mesh.
+managed, observable and secure communication between
+[workload instances](/docs/reference/glossary/#workload-instance).
+
+Service names combined with a namespace are unique within a mesh. For example,
+the `bar` service in the `foo` namespace in `cluster-1` is considered the same
+service as the `bar` service in the `foo` namespace in `cluster-2`.
+
+Since [identities](/docs/reference/glossary/#identity) are shared within the service
+mesh, workload instances can authenticate communication with any other workload
+instance within the same service mesh.

content/en/docs/reference/glossary/trust-domain.md

@@ -0,0 +1,11 @@
+---
+title: Trust Domain
+---
+
+A trust domain is a unique name that Istio uses to create all
+[identities](/docs/reference/glossary/#identity) within a mesh. Every mesh has
+an exclusive trust domain.
+
+For example in `spiffe://mytrustdomain.com/ns/default/sa/myname` the substring
+identifying the mesh is: `mytrustdomain.com`. This substring is the trust
+domain of the mesh.

content/en/docs/setup/additional-setup/config-profiles/index.md

@@ -70,13 +70,13 @@ To further customize Istio and install addons, you can add one or more `--set <k
 ## Multicluster profiles
 
 Istio provides two additional built-in configuration profiles that are used exclusively for configuring a
-[multicluster service mesh](/docs/concepts/multicluster-deployments/#multicluster-service-mesh):
+[multi-cluster deployment](/docs/concepts/deployment-models/#multiple-clusters):
 
 1. **remote**: used for configuring remote clusters of a
-    multicluster mesh with a [shared control plane topology](/docs/concepts/multicluster-deployments/#shared-control-plane-topology).
+    multicluster mesh with a suitable [control plane model](/docs/concepts/deployment-models/#control-plane-models).
 
 1. **multicluster-gateways**: used for configuring all of the clusters of a
-    multicluster mesh with a [dedicated control plane topology](/docs/concepts/multicluster-deployments/#dedicated-control-plane-topology).
+    multicluster mesh with a suitable [control plane model](/docs/concepts/deployment-models/#control-plane-models).
 
 The **remote** profile is configured using the values file `values-istio-remote.yaml`. This profile installs only two
 Istio core components:

content/en/docs/setup/install/multicluster/_index.md

@@ -16,5 +16,5 @@ a combination of the approaches can be used. For example,
 two clusters might share a control plane while a third has its own.
 {{< /tip >}}
 
-Refer to the [multicluster service mesh](/docs/concepts/multicluster-deployments/) concept documentation
+Refer to the [multicluster service mesh](/docs/concepts/deployment-models/#multiple-clusters)
-for more information.
+concept documentation for more information.

content/en/docs/setup/install/multicluster/gateways/index.md

@@ -11,7 +11,7 @@ keywords: [kubernetes,multicluster,gateway]
 ---
 
 Follow this guide to install an Istio
-[multicluster service mesh](/docs/concepts/multicluster-deployments/#multicluster-service-mesh)
+[multicluster service mesh](/docs/concepts/deployment-models/#multiple-clusters)
 with individually deployed Istio control planes in every cluster and using gateways to
 connect services across clusters.
 

content/en/docs/setup/install/multicluster/shared-gateways/index.md

@@ -9,8 +9,8 @@ aliases:
     - /docs/setup/kubernetes/install/multicluster/shared-gateways/
 ---
 
-Follow this guide to configure a multicluster mesh using a
+Follow this guide to configure a multicluster mesh using a suitable
-[shared control plane topology](/docs/concepts/multicluster-deployments/#shared-control-plane-topology)
+[control plane model](/docs/concepts/deployment-models/#control-plane-models)
 with gateways to connect network-isolated clusters.
 Istio's location-aware service routing feature is used to route requests to different endpoints,
 depending on the location of the request source.

content/en/docs/setup/install/multicluster/shared-vpn/index.md

@@ -9,7 +9,7 @@ aliases:
     - /docs/setup/kubernetes/install/multicluster/shared-vpn/
 ---
 
-Follow this guide to install an Istio [multicluster service mesh](/docs/concepts/multicluster-deployments/)
+Follow this guide to install an Istio [multicluster service mesh](/docs/concepts/deployment-models/#multiple-clusters)
 where the Kubernetes cluster services and the applications in each cluster
 have the capability to expose their internal Kubernetes network to other
 clusters.

content/zh/docs/setup/kubernetes/additional-setup/config-profiles/index.md

@@ -56,11 +56,11 @@ keywords: [profiles,install,helm]
 
 ## 多集群配置
 
-Istio 提供了两种附加的内置配置，专门用于搭建[多集群服务网格](/docs/concepts/multicluster-deployments/#multicluster-service-mesh)。
+Istio 提供了两种附加的内置配置，专门用于搭建[多集群服务网格](/docs/concepts/deployment-models/#multiple-clusters)。
 
-1. **remote**：用于搭建[单控制平面拓扑](/docs/concepts/multicluster-deployments/#shared-control-plane-topology)的多集群网格。
+1. **remote**：用于搭建[单控制平面拓扑](/docs/concepts/deployment-models/#control-plane-models)的多集群网格。
 
-1. **multicluster-gateways**：用来搭建[多控制平面拓扑](/docs/concepts/multicluster-deployments/#dedicated-control-plane-topology)的多集群网络。
+1. **multicluster-gateways**：用来搭建[多控制平面拓扑](/docs/concepts/deployment-models/#control-plane-models)的多集群网络。
 
 **remote** 配置对应的配置文件是 `values-istio-remote.yaml`。这个配置仅安装两个核心组件：
 

content/zh/docs/setup/kubernetes/install/multicluster/_index.md

@@ -4,5 +4,5 @@ description: 配置跨越多个 Kubernetes 集群的 Istio 服务网格。
 weight: 30
 keywords: [kubernetes,multicluster]
 ---
-请参阅 [multicluster 服务网格](/docs/concepts/multicluster-deployments/)概念文档
+请参阅 [multicluster 服务网格](/docs/concepts/deployment-models/)概念文档
 欲获得更多信息。

content/zh/docs/tasks/multicluster/gateways/index.md

@@ -7,7 +7,7 @@ aliases:
   - /zh/docs/examples/multicluster/gateways/
 ---
 
-这个示例展示了如何在[多控制平面拓扑](/docs/concepts/multicluster-deployments/#dedicated-control-plane-topology)的多集群网格中
+这个示例展示了如何在[多控制平面拓扑](/docs/concepts/deployment-models/#control-plane-models)的多集群网格中
 配置和调用远程服务。为了演示跨集群访问，会在一个集群中使用 [Sleep 服务]({{<github_tree>}}/samples/sleep)调用另一个集群中的 [httpbin 服务]({{<github_tree>}}/samples/httpbin)。
 
 ## 开始之前 {#before-you-begin}