From df9db64b274a41d2cf934e08ce9e5cb83fd32fb6 Mon Sep 17 00:00:00 2001 From: Rigs Caballero Date: Fri, 30 Aug 2019 10:34:30 -0700 Subject: [PATCH] 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 * Add glossary entries for needed terms. The terms involved are: - Cluster - Identity - Trust domain Signed-off-by: rcaballeromx * Define cluster in a platform agnostic way. Also adds links between `identity` and `trust domain`. Signed-off-by: rcaballeromx * Add missing `(` in links. Signed-off-by: rcaballeromx * Fix links to sections and reduce image sizes. Signed-off-by: rcaballeromx * Simplify the definition of `trust domain` Signed-off-by: rcaballeromx * Move old images to the ZH content. Signed-off-by: rcaballeromx * Add reworked control plane content. Also addresses the comments left on the PR including those regarding the diagrams. Signed-off-by: rcaballeromx * 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 * Move mesh models section. Also minor fixes and edits. Signed-off-by: rcaballeromx * Fix glossary entries and links. Signed-off-by: rcaballeromx --- content/en/blog/2019/announcing-1.1/index.md | 8 +- .../multicluster-version-routing/index.md | 12 +- .../deployment-models/cluster-iso.svg | 1 + .../concepts/deployment-models/cluster-ns.svg | 1 + .../concepts/deployment-models/exp-ns.svg | 1 + .../concepts/deployment-models/failover.svg | 1 + .../docs/concepts/deployment-models/index.md | 396 ++++++++++++++++++ .../concepts/deployment-models/iso-ns.svg | 1 + .../deployment-models/multi-cluster.svg | 1 + .../deployment-models/multi-control.svg | 1 + .../concepts/deployment-models/multi-mesh.svg | 1 + .../concepts/deployment-models/multi-net.svg | 1 + .../deployment-models/multi-trust.svg | 1 + .../deployment-models/shared-control.svg | 1 + .../deployment-models/single-cluster.svg | 1 + .../concepts/deployment-models/single-net.svg | 1 + .../deployment-models/single-trust.svg | 1 + .../multicluster-deployments/index.md | 130 ------ .../en/docs/examples/multicluster/_index.md | 2 +- .../docs/examples/multicluster/gke/index.md | 2 +- .../docs/examples/multicluster/icp/index.md | 2 +- content/en/docs/reference/glossary/cluster.md | 7 + .../docs/reference/glossary/control-plane.md | 7 + .../en/docs/reference/glossary/identity.md | 43 ++ .../reference/glossary/mesh-federation.md | 9 + .../docs/reference/glossary/multi-cluster.md | 7 + .../en/docs/reference/glossary/multi-mesh.md | 8 + .../reference/glossary/service-endpoint.md | 4 +- .../docs/reference/glossary/service-mesh.md | 13 +- .../docs/reference/glossary/trust-domain.md | 11 + .../additional-setup/config-profiles/index.md | 6 +- .../docs/setup/install/multicluster/_index.md | 4 +- .../install/multicluster/gateways/index.md | 2 +- .../multicluster/shared-gateways/index.md | 4 +- .../install/multicluster/shared-vpn/index.md | 2 +- .../multicluster-split-horizon-eds.svg | 0 .../multicluster-with-gateways.svg | 0 .../multicluster-with-vpn.svg | 0 .../additional-setup/config-profiles/index.md | 6 +- .../kubernetes/install/multicluster/_index.md | 2 +- .../docs/tasks/multicluster/gateways/index.md | 2 +- 41 files changed, 542 insertions(+), 161 deletions(-) create mode 100644 content/en/docs/concepts/deployment-models/cluster-iso.svg create mode 100644 content/en/docs/concepts/deployment-models/cluster-ns.svg create mode 100644 content/en/docs/concepts/deployment-models/exp-ns.svg create mode 100644 content/en/docs/concepts/deployment-models/failover.svg create mode 100644 content/en/docs/concepts/deployment-models/index.md create mode 100644 content/en/docs/concepts/deployment-models/iso-ns.svg create mode 100644 content/en/docs/concepts/deployment-models/multi-cluster.svg create mode 100644 content/en/docs/concepts/deployment-models/multi-control.svg create mode 100644 content/en/docs/concepts/deployment-models/multi-mesh.svg create mode 100644 content/en/docs/concepts/deployment-models/multi-net.svg create mode 100644 content/en/docs/concepts/deployment-models/multi-trust.svg create mode 100644 content/en/docs/concepts/deployment-models/shared-control.svg create mode 100644 content/en/docs/concepts/deployment-models/single-cluster.svg create mode 100644 content/en/docs/concepts/deployment-models/single-net.svg create mode 100644 content/en/docs/concepts/deployment-models/single-trust.svg delete mode 100644 content/en/docs/concepts/multicluster-deployments/index.md create mode 100644 content/en/docs/reference/glossary/cluster.md create mode 100644 content/en/docs/reference/glossary/control-plane.md create mode 100644 content/en/docs/reference/glossary/identity.md create mode 100644 content/en/docs/reference/glossary/mesh-federation.md create mode 100644 content/en/docs/reference/glossary/multi-cluster.md create mode 100644 content/en/docs/reference/glossary/multi-mesh.md create mode 100644 content/en/docs/reference/glossary/trust-domain.md rename content/{en => zh}/docs/concepts/multicluster-deployments/multicluster-split-horizon-eds.svg (100%) rename content/{en => zh}/docs/concepts/multicluster-deployments/multicluster-with-gateways.svg (100%) rename content/{en => zh}/docs/concepts/multicluster-deployments/multicluster-with-vpn.svg (100%) diff --git a/content/en/blog/2019/announcing-1.1/index.md b/content/en/blog/2019/announcing-1.1/index.md index 65d6e9673e..a7ba8d932f 100644 --- a/content/en/blog/2019/announcing-1.1/index.md +++ b/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) -and [dedicated control plane](/docs/concepts/multicluster-deployments/#dedicated-control-plane-topology) topologies -without requiring a flat network. +also supporting additional multicluster topologies including different +[control plane models](/docs/concepts/deployment-models/#control-plane-models) +topologies without requiring a flat network. There is lots more -- see the [release notes](/about/notes/1.1/) for complete details. diff --git a/content/en/blog/2019/multicluster-version-routing/index.md b/content/en/blog/2019/multicluster-version-routing/index.md index b4bb6d6c18..11b6e0555d 100644 --- a/content/en/blog/2019/multicluster-version-routing/index.md +++ b/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). -The simplest way to setup a multicluster mesh, because it has no special networking requirements, -is using a -[dedicated control plane topology](/docs/concepts/multicluster-deployments/#dedicated-control-plane-topology). +[multi-cluster deployment](/docs/concepts/deployment-models/#multiple-clusters). +The simplest way to setup a multi-cluster mesh, because it has no special networking requirements, +is using a simple +[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 -[dedicated control plane topology](/docs/concepts/multicluster-deployments/#dedicated-control-plane-topology). +across clusters in a multicluster service mesh with a suitable +[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. diff --git a/content/en/docs/concepts/deployment-models/cluster-iso.svg b/content/en/docs/concepts/deployment-models/cluster-iso.svg new file mode 100644 index 0000000000..39ef424a9c --- /dev/null +++ b/content/en/docs/concepts/deployment-models/cluster-iso.svg @@ -0,0 +1 @@ +cluster-isoIstio Mesh: Business Unit 1Istio Mesh: Business Unit 2 Cluster: Team-1Cluster: Team-2Namespace: barNamespace: fooService CService AService DService B \ No newline at end of file diff --git a/content/en/docs/concepts/deployment-models/cluster-ns.svg b/content/en/docs/concepts/deployment-models/cluster-ns.svg new file mode 100644 index 0000000000..9b0f1be7ca --- /dev/null +++ b/content/en/docs/concepts/deployment-models/cluster-ns.svg @@ -0,0 +1 @@ +cluster-nsIstio MeshCluster: WestCluster: EastNamespace: Team-1Namespace: Team-1Service BService AService AService B \ No newline at end of file diff --git a/content/en/docs/concepts/deployment-models/exp-ns.svg b/content/en/docs/concepts/deployment-models/exp-ns.svg new file mode 100644 index 0000000000..d103173b96 --- /dev/null +++ b/content/en/docs/concepts/deployment-models/exp-ns.svg @@ -0,0 +1 @@ +exp-nsIstio MeshNamespace: Team-1Namespace: Team-2Service CService AService DService B \ No newline at end of file diff --git a/content/en/docs/concepts/deployment-models/failover.svg b/content/en/docs/concepts/deployment-models/failover.svg new file mode 100644 index 0000000000..5c97856e47 --- /dev/null +++ b/content/en/docs/concepts/deployment-models/failover.svg @@ -0,0 +1 @@ +failoverIstio Mesh after control plane failureCluster: WestCluster: EastControl PlaneControl PlaneService AService BService BService A \ No newline at end of file diff --git a/content/en/docs/concepts/deployment-models/index.md b/content/en/docs/concepts/deployment-models/index.md new file mode 100644 index 0000000000..95055011b4 --- /dev/null +++ b/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. diff --git a/content/en/docs/concepts/deployment-models/iso-ns.svg b/content/en/docs/concepts/deployment-models/iso-ns.svg new file mode 100644 index 0000000000..75492fc8e1 --- /dev/null +++ b/content/en/docs/concepts/deployment-models/iso-ns.svg @@ -0,0 +1 @@ +iso-nsIstio MeshNamespace: Team-1Namespace: Team-2Service CService AService DService B \ No newline at end of file diff --git a/content/en/docs/concepts/deployment-models/multi-cluster.svg b/content/en/docs/concepts/deployment-models/multi-cluster.svg new file mode 100644 index 0000000000..c00ee241e2 --- /dev/null +++ b/content/en/docs/concepts/deployment-models/multi-cluster.svg @@ -0,0 +1 @@ +multi-clusterIstio MeshControl PlaneCluster: West-NorthCluster: West-SorthCluster: East-NorthNetwork: EastNetwork: WestService AService AService BService AService BService B \ No newline at end of file diff --git a/content/en/docs/concepts/deployment-models/multi-control.svg b/content/en/docs/concepts/deployment-models/multi-control.svg new file mode 100644 index 0000000000..587238bdf1 --- /dev/null +++ b/content/en/docs/concepts/deployment-models/multi-control.svg @@ -0,0 +1 @@ +multi-controlService BService AIstio MeshCluster: West-1Cluster: East-1Cluster: East-2Control PlaneControl PlaneService AService BService BService ACluster: West-2Service AService B \ No newline at end of file diff --git a/content/en/docs/concepts/deployment-models/multi-mesh.svg b/content/en/docs/concepts/deployment-models/multi-mesh.svg new file mode 100644 index 0000000000..394532b17e --- /dev/null +++ b/content/en/docs/concepts/deployment-models/multi-mesh.svg @@ -0,0 +1 @@ +multi-meshIstio Mesh: foo.comIstio Mesh: bar.comService CService AService DService BTrust bundle:bar.comTrust bundle:foo.com \ No newline at end of file diff --git a/content/en/docs/concepts/deployment-models/multi-net.svg b/content/en/docs/concepts/deployment-models/multi-net.svg new file mode 100644 index 0000000000..7e2dc78989 --- /dev/null +++ b/content/en/docs/concepts/deployment-models/multi-net.svg @@ -0,0 +1 @@ +multi-netIstio MeshNetwork 1Network 2Service AService AService BService BGatewayGateway \ No newline at end of file diff --git a/content/en/docs/concepts/deployment-models/multi-trust.svg b/content/en/docs/concepts/deployment-models/multi-trust.svg new file mode 100644 index 0000000000..8b3a5a7e39 --- /dev/null +++ b/content/en/docs/concepts/deployment-models/multi-trust.svg @@ -0,0 +1 @@ +multi-trustIstio Mesh: foo.comIstio Mesh: bar.comTrust bundle:foo.comTrust bundle:bar.comTrust Domainbar.comCertificate authorityServiceB.bar.comTrust Domainfoo.comCertificate authority \ No newline at end of file diff --git a/content/en/docs/concepts/deployment-models/shared-control.svg b/content/en/docs/concepts/deployment-models/shared-control.svg new file mode 100644 index 0000000000..44e7f4bea2 --- /dev/null +++ b/content/en/docs/concepts/deployment-models/shared-control.svg @@ -0,0 +1 @@ +shared-controlIstio MeshCluster: WestCluster: EastService BService AService AService BControl Plane \ No newline at end of file diff --git a/content/en/docs/concepts/deployment-models/single-cluster.svg b/content/en/docs/concepts/deployment-models/single-cluster.svg new file mode 100644 index 0000000000..9295577a9e --- /dev/null +++ b/content/en/docs/concepts/deployment-models/single-cluster.svg @@ -0,0 +1 @@ +single-clusterControl PlaneService BService AIstio MeshCluster \ No newline at end of file diff --git a/content/en/docs/concepts/deployment-models/single-net.svg b/content/en/docs/concepts/deployment-models/single-net.svg new file mode 100644 index 0000000000..47814f5542 --- /dev/null +++ b/content/en/docs/concepts/deployment-models/single-net.svg @@ -0,0 +1 @@ +single-netIstio MeshSubnet 1Subnet 2Service BService AService AService BNetwork \ No newline at end of file diff --git a/content/en/docs/concepts/deployment-models/single-trust.svg b/content/en/docs/concepts/deployment-models/single-trust.svg new file mode 100644 index 0000000000..f3ef49f937 --- /dev/null +++ b/content/en/docs/concepts/deployment-models/single-trust.svg @@ -0,0 +1 @@ +single-trustIstio MeshClusterService BService ACertificateAuthoritymTLSControl Plane \ No newline at end of file diff --git a/content/en/docs/concepts/multicluster-deployments/index.md b/content/en/docs/concepts/multicluster-deployments/index.md deleted file mode 100644 index 06026c8e52..0000000000 --- a/content/en/docs/concepts/multicluster-deployments/index.md +++ /dev/null @@ -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 `..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/). diff --git a/content/en/docs/examples/multicluster/_index.md b/content/en/docs/examples/multicluster/_index.md index 69cdb6cf49..59652659d9 100644 --- a/content/en/docs/examples/multicluster/_index.md +++ b/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. diff --git a/content/en/docs/examples/multicluster/gke/index.md b/content/en/docs/examples/multicluster/gke/index.md index 06e1995e3a..9b00e89446 100644 --- a/content/en/docs/examples/multicluster/gke/index.md +++ b/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 diff --git a/content/en/docs/examples/multicluster/icp/index.md b/content/en/docs/examples/multicluster/icp/index.md index a8f538d6c6..4b570fd40e 100644 --- a/content/en/docs/examples/multicluster/icp/index.md +++ b/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 diff --git a/content/en/docs/reference/glossary/cluster.md b/content/en/docs/reference/glossary/cluster.md new file mode 100644 index 0000000000..f596b4990c --- /dev/null +++ b/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. diff --git a/content/en/docs/reference/glossary/control-plane.md b/content/en/docs/reference/glossary/control-plane.md new file mode 100644 index 0000000000..a3b216f50e --- /dev/null +++ b/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. diff --git a/content/en/docs/reference/glossary/identity.md b/content/en/docs/reference/glossary/identity.md new file mode 100644 index 0000000000..e1b20049d7 --- /dev/null +++ b/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. diff --git a/content/en/docs/reference/glossary/mesh-federation.md b/content/en/docs/reference/glossary/mesh-federation.md new file mode 100644 index 0000000000..d66ac78983 --- /dev/null +++ b/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). diff --git a/content/en/docs/reference/glossary/multi-cluster.md b/content/en/docs/reference/glossary/multi-cluster.md new file mode 100644 index 0000000000..d28ac37b0a --- /dev/null +++ b/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). diff --git a/content/en/docs/reference/glossary/multi-mesh.md b/content/en/docs/reference/glossary/multi-mesh.md new file mode 100644 index 0000000000..4a47147339 --- /dev/null +++ b/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. diff --git a/content/en/docs/reference/glossary/service-endpoint.md b/content/en/docs/reference/glossary/service-endpoint.md index 5cb8971453..9bc2a8a7e2 100644 --- a/content/en/docs/reference/glossary/service-endpoint.md +++ b/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). -Not all services have service endpoints. +[Workload instances](#workload-instance) expose service endpoints but not all +services have service endpoints. diff --git a/content/en/docs/reference/glossary/service-mesh.md b/content/en/docs/reference/glossary/service-mesh.md index d8f398f71b..5d0bfc674c 100644 --- a/content/en/docs/reference/glossary/service-mesh.md +++ b/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. -[Service names](#service-name) and [workload instance principals](#workload-instance-principal) are unique within a service mesh. +A *service mesh* or simply *mesh* is an infrastructure layer that enables +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. diff --git a/content/en/docs/reference/glossary/trust-domain.md b/content/en/docs/reference/glossary/trust-domain.md new file mode 100644 index 0000000000..47abc714e4 --- /dev/null +++ b/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. diff --git a/content/en/docs/setup/additional-setup/config-profiles/index.md b/content/en/docs/setup/additional-setup/config-profiles/index.md index 7e490821b0..a75b4b57ce 100644 --- a/content/en/docs/setup/additional-setup/config-profiles/index.md +++ b/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 }} -Refer to the [multicluster service mesh](/docs/concepts/multicluster-deployments/) concept documentation -for more information. +Refer to the [multicluster service mesh](/docs/concepts/deployment-models/#multiple-clusters) +concept documentation for more information. diff --git a/content/en/docs/setup/install/multicluster/gateways/index.md b/content/en/docs/setup/install/multicluster/gateways/index.md index 44898878b6..e796b96255 100644 --- a/content/en/docs/setup/install/multicluster/gateways/index.md +++ b/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. diff --git a/content/en/docs/setup/install/multicluster/shared-gateways/index.md b/content/en/docs/setup/install/multicluster/shared-gateways/index.md index abede50611..68e4a05c9f 100644 --- a/content/en/docs/setup/install/multicluster/shared-gateways/index.md +++ b/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 -[shared control plane topology](/docs/concepts/multicluster-deployments/#shared-control-plane-topology) +Follow this guide to configure a multicluster mesh using a suitable +[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. diff --git a/content/en/docs/setup/install/multicluster/shared-vpn/index.md b/content/en/docs/setup/install/multicluster/shared-vpn/index.md index dff2325cbe..28507564d1 100644 --- a/content/en/docs/setup/install/multicluster/shared-vpn/index.md +++ b/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. diff --git a/content/en/docs/concepts/multicluster-deployments/multicluster-split-horizon-eds.svg b/content/zh/docs/concepts/multicluster-deployments/multicluster-split-horizon-eds.svg similarity index 100% rename from content/en/docs/concepts/multicluster-deployments/multicluster-split-horizon-eds.svg rename to content/zh/docs/concepts/multicluster-deployments/multicluster-split-horizon-eds.svg diff --git a/content/en/docs/concepts/multicluster-deployments/multicluster-with-gateways.svg b/content/zh/docs/concepts/multicluster-deployments/multicluster-with-gateways.svg similarity index 100% rename from content/en/docs/concepts/multicluster-deployments/multicluster-with-gateways.svg rename to content/zh/docs/concepts/multicluster-deployments/multicluster-with-gateways.svg diff --git a/content/en/docs/concepts/multicluster-deployments/multicluster-with-vpn.svg b/content/zh/docs/concepts/multicluster-deployments/multicluster-with-vpn.svg similarity index 100% rename from content/en/docs/concepts/multicluster-deployments/multicluster-with-vpn.svg rename to content/zh/docs/concepts/multicluster-deployments/multicluster-with-vpn.svg diff --git a/content/zh/docs/setup/kubernetes/additional-setup/config-profiles/index.md b/content/zh/docs/setup/kubernetes/additional-setup/config-profiles/index.md index 8d33e54932..1b6648f1a0 100644 --- a/content/zh/docs/setup/kubernetes/additional-setup/config-profiles/index.md +++ b/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`。这个配置仅安装两个核心组件： diff --git a/content/zh/docs/setup/kubernetes/install/multicluster/_index.md b/content/zh/docs/setup/kubernetes/install/multicluster/_index.md index 50a2ff43e1..f276a47ad1 100644 --- a/content/zh/docs/setup/kubernetes/install/multicluster/_index.md +++ b/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/)概念文档 欲获得更多信息。 diff --git a/content/zh/docs/tasks/multicluster/gateways/index.md b/content/zh/docs/tasks/multicluster/gateways/index.md index 789c9a34d6..d99bb1351e 100644 --- a/content/zh/docs/tasks/multicluster/gateways/index.md +++ b/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 服务]({{}}/samples/sleep)调用另一个集群中的 [httpbin 服务]({{}}/samples/httpbin)。 ## 开始之前 {#before-you-begin}