Istio从入门到精通——Istio Deployment Models

Istio Deployment Models

https://istio.io/latest/docs/ops/deployment/deployment-models/

  When configuring a production deployment of Istio, you need to answer a number of questions. Will the mesh be confined to a single cluster or distributed across multiple clusters? Will all the services be located in a single fully connected network, or will gateways be required to connect services across multiple networks? Is there a single control plane, potentially shared across clusters, or are there multiple control planes deployed to ensure high availability (HA)? Are all clusters going to be connected into a single multicluster service mesh or will they be federated into a multi-mesh deployment?

  （在配置 Istio 的生产部署时，您需要回答一些问题。网格是局限于一个集群还是分布在多个集群中？所有服务是位于一个完全连接的网络中，还是需要网关来跨多个网络连接服务？是否有一个可能跨集群共享的控制平面，或者有多个控制平面部署以确保高可用性(HA) ？所有集群是连接到一个单一的多集群服务网格中，还是将它们联合到一个多网格部署中？）

  所有的这些问题，都导向一个 Istio 部署的配置，比如：

• • single or multiple cluster（单个或多个群集）
  • single or multiple network（单个或多个网络）
  • single or multiple control plane（单个或多个控制平面）
  • single or multiple mesh（单个或多个网格）

  In a production environment involving multiple clusters, you can use a mix of deployment models. For example, having more than one control plane is recommended for HA, but you could achieve this for a 3 cluster deployment by deploying 2 clusters with a single shared control plane and then adding the third cluster with a second control plane in a different network. All three clusters could then be configured to share both control planes so that all the clusters have 2 sources of control to ensure HA.

  （在涉及多个集群的生产环境中，可以混合使用多种部署模型。例如，对于 HA 推荐使用多个控制平面，但是您可以通过部署具有单个共享控制平面的2个集群，然后在不同的网络中添加具有第二个控制平面的第三个集群来实现3个集群的部署。然后，可以将所有三个集群配置为共享两个控制平面，以便所有集群都有两个控制源来确保 HA。）

  Choosing the right deployment model depends on the isolation, performance, and HA requirements for your use case. This guide describes the various options and considerations when configuring your Istio deployment.

  （选择正确的部署模型取决于用例的隔离、性能和 HA 要求。本指南描述配置 Istio 部署时的各种选项和注意事项。）

一、Cluster Models

  The workload instances of your application run in one or more clusters. 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 service endpoint 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.

  （在大多数情况下，集群表示配置和端点发现的边界。例如，每个 Kubernetes 集群都有一个 API 服务器，它管理集群的配置，并在 pods up 或 down 时提供服务端点信息。由于 Kubernetes 在每个集群的基础上配置这种行为，这种方法有助于限制由不正确配置引起的潜在问题。）

  In Istio, you can configure a single service mesh to span any number of clusters.

  （在 Istio，您可以配置单个服务网格来跨越任意数量的集群。）

1.1、单集群（SingleCluster）

  In the simplest case, you can confine an Istio mesh to a single cluster. A cluster usually operates over a 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.

  （在最简单的情况下，可以将 Istio 网格限制在单个集群中。集群通常在单个网络上运行，但是在基础设施提供者之间有所不同。单个集群和单个网络模型包括一个控制平面，这导致了最简单的 Istio 部署。）

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.

  （单集群部署提供了简单性，但缺乏其他特性，例如故障隔离和故障转移。如果需要更高的可用性，应该使用多个集群。）

1.2、Multiple Clusters

  You can configure a single mesh to include multiple clusters. （可以将单个网格配置为包含多个群集。）

  Using a multicluster（Multicluster is a deployment model that consists of a mesh with multiple clusters.） deployment within a single mesh affords the following capabilities beyond that of a single cluster deployment: （在单个网格中使用多集群部署提供了单个集群部署之外的以下功能）:

• • • • Fault isolation and fail over:cluster-1goes down, fail over tocluster-2.（故障隔离和故障转移: 集群1出现故障，故障转移到集群2。）

• • • • Location-aware routing and fail over: Send requests to the nearest service.  （位置感知路由和故障转移: 向最近的服务发送请求。）

• • • • Various control plane models: Support different levels of availability.    （各种控制平面模型: 支持不同级别的可用性。）

• • • • Team or project isolation: Each team runs its own set of clusters.        （团队或项目隔离: 每个团队运行自己的集群集。

A service mesh with multiple clusters

  Multicluster 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 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.

  （您可以根据网络和云提供商支持的选项配置集群间通信。例如，如果两个集群位于相同的底层网络上，您可以通过简单地配置防火墙规则来启用跨集群通信。）

  Within a multicluster mesh, all services are shared by default, according to the concept of namespace sameness. Traffic management rules provide fine-grained control over the behavior of multicluster traffic.

  （在多集群网格中，根据名称空间相同的概念，默认情况下所有服务都是共享的。流量管理规则提供了对多簇流量行为的细粒度控制。）

1.3、DNS with multiple cluster

When a client application makes a request to some host, it must first perform a DNS lookup for the hostname to obtain an IP address before it can proceed with the request. In Kubernetes, the DNS server residing within the cluster typically handles this DNS lookup, based on the configured Service definitions.

  (当客户端应用程序向某个主机发出请求时，它必须首先对主机名执行 DNS 查找，以获得 IP 地址，然后才能继续处理请求。在 Kubernetes，驻留在集群中的 DNS 服务器通常根据配置的服务定义处理此 DNS 查找。)

  Istio uses the virtual IP returned by the DNS lookup to load balance across the list of active endpoints for the requested service, taking into account any Istio configured routing rules. Istio uses either Kubernetes Service/Endpoint or Istio ServiceEntry to configure its internal mapping of hostname to workload IP addresses.

  （考虑到任何 Istio 配置的路由规则，Istio 使用 DNS 查找返回的虚拟 IP 来跨请求服务的活动端点列表进行负载平衡。Istio 使用 Kubernetes Service/Endpoint 或 Istio ServiceEntry 配置其主机名到工作负载 IP 地址的内部映射。）

This two-tiered naming system becomes more complicated when you have multiple clusters. Istio is inherently multicluster-aware, but Kubernetes is not (today). Because of this, the client cluster must have a DNS entry for the service in order for the DNS lookup to succeed, and a request to be successfully sent. This is true even if there are no instances of that service’s pods running in the client cluster.

  （当您拥有多个集群时，这种双层命名系统会变得更加复杂。Istio 在本质上具有多集群意识，但 Kubernetes (今天)没有。因此，客户端集群必须为服务提供一个 DNS 条目，以便 DNS 查找成功，并成功发送请求。即使在客户机集群中没有运行该服务的 pods 的实例，也是如此。）

  To ensure that DNS lookup succeeds, you must deploy a Kubernetes Service to each cluster that consumes that service. This ensures that regardless of where the request originates, it will pass DNS lookup and be handed to Istio for proper routing. This can also be achieved with Istio ServiceEntry, rather than Kubernetes Service. However, a ServiceEntry does not configure the Kubernetes DNS server. This means that DNS will need to be configured either manually or with automated tooling such as the Address auto allocation feature of Istio DNS Proxying.

  (要确保 DNS 查找成功，必须将 Kubernetes 服务部署到使用该服务的每个集群。这确保无论请求来自何处，它都会通过 DNS 查找并交给 Istio 进行正确的路由。这也可以通过 Istio ServiceEntry 实现，而不是 Kubernetes Service。但是，ServiceEntry 不配置 Kubernetes DNS 服务器。这意味着 DNS 需要手动配置，或者使用自动工具配置，比如 Istio DNS Proxy 的 Address 自动分配功能。)

There are a few efforts in progress that will help simplify the DNS story:

(正在进行的一些努力将有助于简化域名解析系统的故事):

• DNS sidecar proxy support is available for preview in Istio 1.8. This provides DNS interception for all workloads with a sidecar, allowing Istio to perform DNS lookup on behalf of the application.

  （DNS 边车代理支持可以在 Istio 1.8中预览。这为所有工作负载提供了 DNS 拦截，允许 Istio 代表应用程序执行 DNS 查找。）

• Admiral is an Istio community project that provides a number of multicluster capabilities. If you need to support multi-network topologies, managing this configuration across multiple clusters at scale is challenging. Admiral takes an opinionated view on this configuration and provides automatic provisioning and synchronization across clusters.

  （Adiral 是一个 Istio 社区项目，提供了许多多集群能力。如果您需要支持多网络拓扑，那么跨多个集群大规模地管理这种配置是具有挑战性的。Admiral 对这种配置持有自己的观点，并提供跨集群的自动配置和同步。）

• Kubernetes Multi-Cluster Services is a Kubernetes Enhancement Proposal (KEP) that defines an API for exporting services to multiple clusters. This effectively pushes the responsibility of service visibility and DNS resolution for the entire clusterset onto Kubernetes. There is also work in progress to build layers of MCS support into Istio, which would allow Istio to work with any cloud vendor MCS controller or even act as the MCS controller for the entire mesh.

  （Kubernetes 多集群服务是一个 Kubernetes 增强提案(KEP) ，它定义了一个 API，用于将服务导出到多个集群。这有效地将整个集群的服务可见性和 DNS 解析的责任推给了 Kubernetes。还有一项工作正在进行中，即在 Istio 中构建 MCS 支持层，这将允许 Istio 与任何云供应商的 MCS 控制器一起工作，甚至作为整个网格的 MCS 控制器。）

二、Network models

  Istio uses a simplified definition of network to refer to workload instances that have direct reachability. For example, by default all workload instances in a single cluster are on the same network.

  （Istio 使用简化的网络定义来引用具有直接可达性的工作负载实例。例如，默认情况下，一个集群中的所有工作负载实例都在同一个网络上。）

  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.

  （许多生产系统需要多个网络或子网来隔离和高可用性。Istio 支持在各种网络拓扑上跨越服务网格。这种方法允许你选择适合你现有网络拓扑的网络模型。）

2.1、Single network

  In the simplest case, a service mesh operates over a single fully connected network. In a single network model, all workload instances can reach each other directly without an Istio gateway.

  （在最简单的情况下，服务网格在单个完全连接的网络上运行。在单一的网络模型中，所有的工作负载实例都可以直接到达彼此，而不需要 Istio 网关。）

  A single network allows Istio to configure service consumers in a uniform way across the mesh with the ability to directly address workload instances.

 （单个网络允许 Istio 跨网格以统一的方式配置服务使用者，并能够直接处理工作负载实例。）

A service mesh with a single network

2.2、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.（服务端点的重叠 IP 或 VIP 范围）

• • • 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. Istio uses partitioned service discovery to provide consumers a different view of service endpoints. The view depends on the network of the consumers.

  （在这个模型中，不同网络中的工作负载实例只能通过一个或多个 Istio 网关相互连接。Istio 使用分区服务发现为使用者提供服务端点的不同视图。视图取决于使用者的网络。）

A service mesh with multiple networks

三、Control plane models

  An Istio mesh uses the control plane to configure all communication between workload instances within the mesh. Workload instances connect to a control plane instance to get their configuration.

  （Istio 网格使用控制平面来配置网格中工作负载实例之间的所有通信。工作负载实例连接到控制平面实例以获取它们的配置。）

  In the simplest case, you can run your mesh with a control plane on a single cluster.

  （在最简单的情况下，可以在单个集群上使用控制平面运行网格。）

A single cluster with a control plane 

A cluster like this one, with its own local control plane, is referred to as a primary cluster.

（像这样一个拥有自己的局部控制平面的集群被称为主集群。）

Multicluster deployments can also share control plane instances. In this case, the control plane instances can reside in one or more primary clusters. Clusters without their own control plane are referred to as remote clusters.

（多集群部署还可以共享控制平面实例。在这种情况下，控制平面实例可以驻留在一个或多个主集群中。没有自己控制平面的集群称为远程集群。）

A service mesh with a primary and a remote cluster

  To support remote clusters in a multicluster mesh, the control plane in a primary cluster must be accessible via a stable IP (e.g., a cluster IP). For clusters spanning networks, this can be achieved by exposing the control plane through an Istio gateway. Cloud vendors may provide options, such as internal load balancers, for providing this capability without exposing the control plane on the public internet. Such an option, if it exists and meets your requirements, will likely be the best choice.

  （为了在多集群网格中支持远程集群，主集群中的控制平面必须可以通过一个稳定的 IP (例如，一个集群 IP)访问。对于跨越网络的集群，这可以通过将控制平面暴露在 Istio 网关中来实现。云供应商可以提供诸如内部负载均衡器之类的选项，以便在不将控制平面暴露在公共互联网上的情况下提供此功能。这样的选择，如果它存在并满足您的需求，将可能是最好的选择。）

  In multicluster deployments with more than one primary cluster, each primary cluster receives its configuration (i.e., Service and ServiceEntry, DestinationRule, etc.) from the Kubernetes API Server residing in the same cluster. Each primary cluster, therefore, has an independent source of configuration. This duplication of configuration across primary clusters does require additional steps when rolling out changes. Large production systems may automate this process with tooling, such as CI/CD systems, in order to manage configuration rollout.

  （在具有多个主集群的多集群部署中，每个主集群从驻留在同一集群中的 Kubernetes API Server 接收其配置(即，Service and ServiceEntry，DestinationRule 等)。因此，每个主集群都有一个独立的配置源。在推出更改时，这种跨主集群的配置重复确实需要额外的步骤。大型生产系统可以使用工具(如 CI/CD 系统)自动化这一过程，以便管理配置的推出。）

  Instead of running control planes in primary clusters inside the mesh, a service mesh composed entirely of remote clusters can be controlled by an external control plane. This provides isolated management and complete separation of the control plane deployment from the data plane services that comprise the mesh.

  （一个完全由远程集群组成的服务网格可以由一个外部控制平面来控制，而不是在网格内部的主要集群中运行控制平面。这提供了隔离管理，并将控制平面部署与构成网格的数据平面服务完全分离。）

A single cluster with an external control plane

 

A cloud vendor’s managed control plane is a typical example of an external control plane.

（云供应商的托管控制平面是外部控制平面的典型例子。）

For high availability, you should deploy multiple control planes across clusters, zones, or regions.

（对于高可用性，您应该跨集群、区域或区域部署多个控制平面。）

 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 workloads in clusters managed by that control plane.

      （改进的可用性: 如果控制平面变得不可用，那么中断的范围仅限于由该控制平面管理的集群中的工作负载。）

    • Configuration isolation: You can make configuration changes in one cluster, zone, or region without impacting others.

      (配置隔离: 您可以在一个群集、区域或区域中进行配置更改，而不会影响其他群集、区域或区域。)

    • Controlled rollout: You have more fine-grained control over configuration rollout (e.g., one cluster at a time). You can also canary configuration changes in a sub-section of the mesh controlled by a given primary cluster.

      (受控的展示: 您可以对配置展示进行更细粒度的控制(例如，一次一个集群)。您还可以在由给定的主集群控制的网格子节中进行金丝雀配置更改。)

    • Selective service visibility: You can restrict service visibility to part of the mesh, helping to establish service-level isolation. For example, an administrator may choose to deploy the HelloWorld service to Cluster A, but not Cluster B. Any attempt to call HelloWorld from Cluster B will fail the DNS lookup.

      (选择性服务可见性: 您可以将服务可见性限制为网格的一部分，这有助于建立服务级隔离。例如，管理员可以选择将 HelloWorld 服务部署到群集 A，但不部署群集 B。从群集 B 调用 HelloWorld 的任何尝试都将导致 DNS 查找失败。)

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).（每个集群 最高可用性）

3.1、Endpoint discovery with multiple control planes

  An Istio control plane manages traffic within the mesh by providing each proxy with the list of service endpoints. In order to make this work in a multicluster scenario, each control plane must observe endpoints from the API Server in every cluster.

  （一个 Istio 控制平面通过向每个代理提供服务端点列表来管理网格中的流量。为了使其在多集群场景中工作，每个控制平面必须观察每个集群中来自 API 服务器的端点。）

  To enable endpoint discovery for a cluster, an administrator generates a remote secret and deploys it to each primary cluster in the mesh. The remote secret contains credentials, granting access to the API server in the cluster. The control planes will then connect and discover the service endpoints for the cluster, enabling cross-cluster load balancing for these services.

  （为了启用集群的端点发现，管理员生成一个远程秘密，并将其部署到网格中的每个主集群。远程秘密包含凭据，授予对集群中 API 服务器的访问权限。然后，控制平面将连接并发现集群的服务端点，从而支持这些服务的跨集群负载平衡。）

Primary clusters with endpoint discovery

By default, Istio will load balance requests evenly between endpoints in each cluster. In large systems that span geographic regions, it may be desirable to use locality load balancing to prefer that traffic stay in the same zone or region.

  （默认情况下，Istio 将在每个集群中的端点之间均匀地进行请求负载平衡。在跨越地理区域的大型系统中，可能需要使用局部负载平衡，以使流量保持在同一区域或区域中。）

  In some advanced scenarios, load balancing across clusters may not be desired. For example, in a blue/green deployment, you may deploy different versions of the system to different clusters. In this case, each cluster is effectively operating as an independent mesh. This behavior can be achieved in a couple of ways:

  （在一些高级场景中，可能不需要跨集群的负载平衡。例如，在蓝色/绿色部署中，可以将系统的不同版本部署到不同的集群。在这种情况下，每个集群有效地作为一个独立的网格运行。这种行为可以通过以下几种方式实现）:

• • • Do not exchange remote secrets between the clusters. This offers the strongest isolation between the clusters.

      （不要在集群之间交换远程机密。这样可以在集群之间提供最强的隔离。）

    • Use VirtualService and DestinationRule to disallow routing between two versions of the services.

      （使用 VirtualService 和 DestinationRule 禁止在两个服务版本之间进行路由。）

  In either case, cross-cluster load balancing is prevented. External traffic can be routed to one cluster or the other using an external load balancer.

  （在这两种情况下，都会阻止跨集群负载平衡。可以使用外部负载均衡器将外部流量路由到一个集群或另一个集群。

Blue-green deployment without cross-cluster load balancing

 四、 Identity and trust models

  When a workload instance is created within a service mesh, Istio assigns the workload an identity.

  （当在服务网格中创建工作负载实例时，Istio 为工作负载分配一个标识。）

  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.

  （证书颁发机构(CA)创建并签署用于验证网格中使用的标识的证书。您可以使用创建并签署该身份证书的 CA 的公钥来验证消息发送方的身份。信任包是一个 Istio 网格使用的所有 CA 公钥的集合。通过网格的信任包，任何人都可以验证来自该网格的任何消息的发送者。）

4.1、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 creates and signs the certificates for those identities. This model allows workload instances in the mesh to authenticate each other when communicating.

  （在单个 Istio 网格中，Istio 确保每个工作负载实例都有一个表示其自身身份的适当证书，以及识别网格和任何联邦网格中的所有身份所必需的信任包。CA 为这些身份创建并签名证书。此模型允许网格中的工作负载实例在通信时相互验证。）

 A service mesh with a common certificate authority

4.2、Trust between meshes

  To enable communication between two meshes with different CAs, you must exchange the trust bundles of the meshes. Istio does not provide any tooling to exchange trust bundles across meshes. You can exchange the trust bundles either manually or automatically using a protocol such as SPIFFE Trust Domain Federation. Once you import a trust bundle to a mesh, you can configure local policies for those identities.

  （为了在两个具有不同 CA 的网格之间进行通信，必须交换网格的信任包。Istio 没有提供任何工具来跨网格交换信任包。可以使用 SPIFFE 信任域联邦之类的协议手动或自动交换信任包。一旦将信任包导入到网格中，就可以为这些标识配置本地策略。）

Multiple service meshes with different certificate

五、Mesh Models

  Istio supports having all of your services in a mesh, or federating multiple meshes together, which is also known as multi-mesh.

  （Istio 支持将所有服务放在一个网格中，或者将多个网格联合在一起，也称为多网格。）

5.1、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 namemysvcin thefoonamespace. Additionally, workload instances share a common identity since service account names are unique within a namespace, just like service names.

  （最简单的 Istio 部署是单个网格。在网格中，服务名称是唯一的。例如，在 foo 命名空间中只能有一个服务的名称 mysvc。此外，工作负载实例共享一个公共标识，因为服务帐户名称在名称空间中是唯一的，就像服务名称一样。）

  A single mesh can span one or more clusters and one or more networks. Within a mesh, namespaces are used for tenancy.

  (单个网格可以跨越一个或多个集群和一个或多个网络。在网格中，名称空间用于租赁。)

5.2、Multiple meshes

Multiple mesh deployments result from mesh federation.

(网格联合导致多个网格部署。)

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 mesh federation. When federating, each mesh can expose a set of services and identities, which all participating meshes can recognize.

  （您可以使用网格联合来启用网格间通信。在联合时，每个网格可以公开一组服务和身份，所有参与的网格都可以识别这些服务和身份。

  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. 

（为了避免服务命名冲突，可以为每个网格提供一个全局唯一的网格 ID，以确保每个服务的完全限定域名(FQDN)是不同的。） 

When federating two meshes that do not share the same trust domain, you must federate identity and trust bundles between them. See the section on Trust between meshes for more details. 

（当联合两个不共享相同信任域的网格时，必须在它们之间联合标识和信任包。有关更多细节，请参见网格之间的信任部分。）

六、Tenancy Models

  In Istio, a tenant is a group of users that share common access and privileges for a set of deployed workloads. Tenants can be used to provide a level of isolation between different teams.

  （在 Istio，租户是一组用户，它们共享一组已部署工作负载的公共访问权限和特权。租户可用于在不同团队之间提供一定程度的隔离。）

  You can configure tenancy models to satisfy the following organizational requirements for isolation:

  （您可以对租赁模型进行配置，以满足以下组织对隔离的要求):

• • Security
  • Policy
  • Capacity
  • Cost
  • Performance

Istio supports three types of tenancy models:

• • Namespace tenancy（名称空间租赁）
  • Cluster tenancy （群组租约）
  • Mesh tenancy   （网眼租约）

 6.1、Namespace tenancy

  A cluster can be shared across multiple teams, each using a different namespace. You can grant a team permission to deploy its workloads only to a given namespace or set of namespaces.

  （集群可以跨多个团队共享，每个团队使用不同的名称空间。您可以授予团队权限，只将其工作负载部署到给定的命名空间或一组命名空间。）

  By default, services from multiple namespaces can communicate with each other, but you can increase isolation by selectively choosing which services to expose to other namespaces. You can configure   authorization policies for exposed services to restrict access to only the appropriate callers.

  （默认情况下，来自多个名称空间的服务可以相互通信，但是可以通过选择将哪些服务公开给其他名称空间来增加隔离性。您可以为公开的服务配置授权策略，以限制对适当调用方的访问。）

  A service mesh with two namespaces and an exposed

  Namespace tenancy can extend beyond a single cluster. When using multiple clusters, the namespaces in each cluster sharing the same name are considered the same namespace by default. For example, Service B in the Team-1 namespace of cluster West and Service B in the Team-1 namespace of cluster East refer to the same service, and Istio merges their endpoints for service discovery and load balancing. 

  （名称空间租赁可以扩展到单个集群之外。在使用多个集群时，默认情况下，共享同一名称的每个集群中的名称空间被视为相同的名称空间。例如，集群 West 的 Team-1名称空间中的服务 b 和集群 East 的 Team-1名称空间中的服务 b 引用相同的服务，Istio 合并它们的端点以进行服务发现和负载平衡。）

6.2、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:

  （Istio 支持使用集群作为租赁单元。在这种情况下，您可以为每个团队提供一个专用集群或一组集群来部署他们的工作负载。集群的权限通常仅限于拥有该集群的团队成员。您可以为更细粒度的控制设置各种角色，例如）:

• • Cluster administrator （群集管理员）
  • Developer （开发者）

  To use cluster tenancy with Istio, you configure each team’s cluster with its own control plane, allowing each team to manage its own configuration. Alternatively, you can use Istio to implement a group of clusters as a single tenant using remote clusters or multiple synchronized primary clusters. Refer to control plane models for details.

  （要在 Istio 中使用集群租赁，可以使用每个团队自己的控制平面来配置每个团队的集群，从而允许每个团队管理自己的配置。或者，您可以使用 Istio 作为一个租户实现一组集群，使用远程集群或多个同步主集群。详情请参阅控制平面模型。）

6.3、Mesh Tenancy

  In a multi-mesh deployment with mesh federation, each mesh can be used as the unit of isolation.

  （在具有网格联邦的多网格部署中，每个网格都可以用作隔离单元。）

Two isolated service meshes with two clusters and

  Since a different team or organization operates each mesh, service naming is rarely distinct. For example, a Service C in the foo namespace of cluster Team-1 and the Service C service in the foo namespace of cluster Team-2 will not refer to the same service. The most common example is the scenario in Kubernetes where many teams deploy their workloads to the default namespace.

  （由于每个网格由不同的团队或组织操作，因此服务命名很少是不同的。例如，集群 Team-1的 foo 命名空间中的服务 C 和集群 Team-2的 foo 命名空间中的服务 C 将不引用相同的服务。最常见的例子是在 Kubernetes 的场景中，许多团队将他们的工作负载部署到默认名称空间。）

  When each team has its own mesh, cross-mesh communication follows the concepts described in the multiple meshes model.

  （当每个团队都有自己的网格时，跨网格通信遵循多网格模型中描述的概念。）