# istio部署方式

## 部署模型

在配置Istio的生产部署时,您需要考虑许多问题。将网格限制为单个集群或分布在多个集群中？是将所有服务都放置在单个完全连接的网络中,还是需要网关才能跨多个网络连接服务？有没有一个控制平面,可能在集群之间共享,还是部署了多个控制平面以确保高可用性(HA)？是否所有集群都将连接成一个集群多集群服务网格,或者将它们联合成一个多网部署？

可以总结为以下几个问题,除此之外,都代表Istio部署的独立配置维度。

* 单个或多个集群
* 单个或多个网络
* 单或多控制平面
* 单个或多个网格

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

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

## 集群模型

您的应用程序的工作负载实例在一个或多个集群中运行。为了实现隔离,性能和高可用性,您可以将集群限制在可用性zone和region中。

根据需求,生产系统可以跨多个区域或区域的多个集群运行,从而利用云负载均衡器来处理诸如本地性,区域性或区域性故障转移之类的事情。

在大多数情况下,集群代表配置和端点发现的边界。例如,每个Kubernetes集群都有一个API服务器,该服务器管理集群的配置并提供service endpoint 关于pod启停时的信息。由于Kubernetes在每个集群的基础上配置此行为,因此这种方法有助于限制由于配置错误而引起的潜在问题。

在Istio中,您可以配置单个服务网格以跨越任意数量的集群。

## 单集群

在最简单的情况下,您可以将Istio网格限制为单个 簇。集群通常在 单个网络上运行,但是在基础架构提供商之间会有所不同。单个集群和单个网络模型包括一个控制平面,这导致最简单的Istio部署

![具有单个集群的服务网格](https://istio.io/latest/docs/ops/deployment/deployment-models/single-cluster.svg)

单集群部署提供了简单性,但缺少其他功能,例如,故障隔离和故障转移。如果需要更高的可用性,则应使用多个集群。

## 多个集群

您可以配置单个网格以包含多个网格 集群。用一个 多集群 在单个网格中进行部署可以提供除单个集群部署之外的以下功能:

* 故障隔离和故障转移:失败cluster-1,故障转移至cluster-2。
* 位置感知路由和故障转移:将请求发送到最近的服务。
* 各种控制平面模型:支持不同级别的可用性。
* 团队或项目隔离:每个团队都运行自己的一组集群。

![具有多个集群的服务网格](https://istio.io/latest/docs/ops/deployment/deployment-models/multi-cluster.svg)

多集群部署可为您提供更大程度的隔离和可用性,但会增加复杂性。如果您的系统具有高可用性要求,则可能需要跨多个区域和区域的集群。您可以在单个集群中进行金丝雀的配置更改或新的二进制发行版,其中配置更改只会影响少量的用户流量。此外,如果集群有问题,您可以暂时将流量路由到附近的集群,直到解决该问题为止。

您可以基于网络和云提供商所支持的选项来配置集群间通信 。例如,如果两个集群位于同一基础网络上,则可以通过简单地配置防火墙规则来启用跨集群通信。

## 多集群的DNS

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

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

当您有多个集群时,此两层命名系统将变得更加复杂。Istio本质上是支持多集群的,但Kubernetes目前尚未支持。因此,客户端集群必须具有用于该服务的DNS条目,才能使DNS查找成功,并成功发送请求。即使在客户端集群中没有运行该服务的Pod的实例也是如此。

为了确保DNS查找成功,您必须将Kubernetes部署Service到使用该服务的每个集群。这样可以确保无论请求来自何处,它都将通过DNS查找,并传递给Istio以进行正确的路由。这也可以使用IstioServiceEntry而非Kubernetes 来实现Service。但是,ServiceEntry没有配置Kubernetes DNS服务器。这意味着将需要手动配置DNS或使用Istio CoreDNS插件之类的自动化工具进行配置 。

目前有几种方式实现了跨集群的DNS:

* DNS sidecar代理 支持可在Istio 1.8中进行预览。这可通过附带工具为所有工作负载提供DNS拦截,从而使Istio可以代表应用程序执行DNS查找,本书将使用该方法进行跨集群DNS解析。
* Admiral是一个Istio社区项目,提供了许多多集群功能。如果您需要支持多网络拓扑,则在多个集群之间大规模管理此配置将是一项挑战。Admiral对此配置持坚定态度,并提供跨集群的自动配置和同步。
* Kubernetes多集群服务 是一个Kubernetes增强提案(KEP),它定义了将服务导出到多个集群的API。这有效地将整个服务的可见性和DNS解析责任推clusterset到了Kubernetes上。正在进行将MCSIstio内置支持层的工作,这将使Istio可以与任何云供应商MCS 控制器一起使用,甚至可以充当MCS整个网格的控制器。

## 网络模型

stio使用的简化定义 网络 指 工作量实例具有直接可达性的。例如,默认情况下,单个集群中的所有工作负载实例都在同一网络上。 许多生产系统需要多个网络或子网来实现隔离和高可用性。Istio支持跨多种网络拓扑扩展服务网格。这种方法使您可以选择适合您现有网络拓扑的网络模型。

## 单网

在最简单的情况下,服务网格在单个完全连接的网络上运行。在单个网络模型中,所有 工作量实例 无需Istio网关即可直接相互访问。 单个网络使Istio能够在网格中以统一的方式配置服务使用者,并具有直接处理工作负载实例的能力。

![具有单个网络的服务网格](https://istio.io/latest/docs/ops/deployment/deployment-models/single-net.svg)

## 多个网络

您可以跨多个网络跨越一个服务网格。这样的配置称为多网络。

多个网络提供了除单个网络之外的以下功能:

* 服务端点的重叠IP或VIP范围
* 跨越行政界限
* 容错能力
* 网络地址扩展
* 符合要求网络分段的标准

在此模型中,不同网络中的工作负载实例只能通过一个或多个Istio网关相互访问。Istio使用分区服务发现为消费者提供了不同的视图服务端点s。该视图取决于消费者的网络。

![](https://istio.io/latest/docs/ops/deployment/deployment-models/multi-net.svg)

此解决方案要求通过网关公开所有服务(或子集)。云供应商可能会提供不需要在公共互联网上公开服务的选项。如果存在并且满足您的要求,那么这样的选择将是最佳选择

## 控制平面模型

Istio网格使用控制平面配置网格内工作负载实例之间的所有通信。工作负载实例连接到控制平面实例以获取其配置。 在最简单的情况下,可以在单个集群上使用控制平面运行网格。

![具有控制平面的单个集群](https://istio.io/latest/docs/ops/deployment/deployment-models/single-cluster.svg)

像这样的集群,具有自己的本地控制平面,称为 主集群。

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

![具有主集群和远程集群的服务网格](https://istio.io/latest/docs/ops/deployment/deployment-models/shared-control.svg)

为了支持多集群网格中的远程集群,必须可以通过稳定的IP(例如集群IP)访问主集群中的控制平面。对于跨网络的集群,这可以通过通过Istio网关公开控制平面来实现。云供应商可能会提供选项,例如内部负载均衡器,以提供此功能而不会在公共Internet上暴露控制平面。如果存在并且满足您的要求,那么这样的选择将是最佳选择。

在具有多于一个的主集群的多组的部署中,每个主集群接收其配置(即,Service和ServiceEntry, DestinationRule从驻留在相同集群中的Kubernetes API服务器,等等)。因此,每个主集群都有一个独立的配置源。部署更改时,跨主集群的这种重复配置确实需要其他步骤。大型生产系统可以使用诸如CI/CD系统之类的工具来自动执行此过程,以管理配置部署。

代替在网格内部的主集群中运行控制平面,可以完全由远程集群组成的服务网格可以通过 外部控制平面。这提供了隔离的管理,并将控制平面部署与构成网格的数据平面服务完全隔离。

![具有外部控制平面的单个集群](https://istio.io/latest/docs/ops/deployment/deployment-models/single-cluster-external-control-plane.svg)

云供应商的 管理的控制平面 是外部控制平面的典型示例。 为了获得高可用性,您应该在集群,区域或区域中部署多个控制平面。

![每个区域都有控制平面实例的服务网格](https://istio.io/latest/docs/ops/deployment/deployment-models/multi-control.svg)

该模型具有以下优点:

* 更高的可用性:如果控制平面不可用,则中断范围仅限于由该控制平面管理的集群中的工作负载。
* 配置隔离:您可以在一个集群,区域或区域中进行配置更改,而不会影响其他集群,区域或区域。
* 受控的部署:您可以对配置的部署进行更细粒度的控制(例如,一次配置一个集群)。您还可以在由给定的主集群控制的网格的子区域中更改金丝雀的配置。
* 选择性的服务可见性:您可以将服务可见性限制在部分网格中,以帮助建立服务级别隔离。例如,管理员可以选择将HelloWorld服务部署到集群A,而不部署到集群B。HelloWorld从集群B进行呼叫的任何尝试都会使DNS查找失败。

以下列表按可用性对控制平面部署示例进行了排名:

* 每个区域一个集群(可用性最低)
* 每个区域多个集群
* 每个区域一个集群
* 每个区域多个集群
* 每个集群(最高可用性)

## 具有多个控制平面的端点发现

Istio控制平面通过为每个代理提供服务端点列表来管理网状网络内的流量。为了在多集群方案中实现此目的,每个控制平面必须观察每个集群中来自API Server的端点。

要为集群启用端点发现,管理员会生成一个, remote secret并将其部署到网格中的每个主集群中。该 remote secret包含凭证,授权访问集群中的API服务器。然后,控制平面将连接并发现集群的服务端点,从而为这些服务实现跨集群的负载均衡。

![具有端点发现的主集群](https://istio.io/latest/docs/ops/deployment/deployment-models/endpoint-discovery.svg)

默认情况下,Istio将在每个集群的端点之间平均负载均衡请求。在跨越地理区域的大型系统中,可能希望使用位置负载均衡 来使流量保持在相同的区域或区域中。

在某些高级方案中,可能不需要跨集群的负载均衡。例如,在蓝/绿部署中,您可以将系统的不同版本部署到不同的集群。在这种情况下,每个集群实际上都作为独立的网格运行。可以通过以下两种方法来实现此行为:

* 不要在集群之间交换远程secret。这提供了集群之间最强的隔离。
* 使用VirtualService和DestinationRule禁止在两个版本的服务之间路由。

在这两种情况下,都将避免跨集群的负载均衡。可以使用外部负载均衡器将外部流量路由到一个集群或另一个集群。

![无跨集群负载均衡的蓝绿色部署](https://istio.io/latest/docs/ops/deployment/deployment-models/blue-green.svg)

## 身份和信任模型

在服务网格内创建工作负载实例时,Istio会为工作负载分配一个 身份。

证书颁发机构(CA)创建并签署用于验证网格中使用的身份的证书。您可以使用为该身份创建并签署证书的CA的公钥来验证消息发件人的身份。一个信任捆绑是一组用于由Istio网所有CA的公钥。使用网格的信任包,任何人都可以验证来自该网格的任何消息的发送者。

## 网格内的信任

在单个Istio网格中,Istio确保每个工作负载实例都有一个代表其自身身份的适当证书,以及识别网格和所有联合网格中所有身份所必需的信任束。CA为这些身份创建并签署证书。此模型允许网格中的工作负载实例在进行通信时相互进行身份验证。

![具有通用证书颁发机构的服务网格](https://istio.io/latest/docs/ops/deployment/deployment-models/single-trust.svg)

## 网格之间的信任

要启用具有不同CA的两个网格之间的通信,必须交换网格的信任束。Istio不提供任何工具来跨网格交换信任束。您可以使用SPIFFE Trust Domain Federation等协议手动或自动交换信任束。将信任包导入网格后,即可为这些身份配置本地策略。

![具有不同证书颁发机构的多个服务网格](https://istio.io/latest/docs/ops/deployment/deployment-models/multi-trust.svg)

## 网格模型

Istio支持将所有服务都包含在 网状,或将多个网格联合在一起,也称为 多网。

### 单网格

最简单的Istio部署是单个网格。在网格中,服务名称是唯一的。例如,只有一个服务可以有名称mysvc的foo 命名空间。此外,工作负载实例具有相同的标识,因为服务帐户名称在名称空间中是唯一的,就像服务名称一样。

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

## 多个网格

多个网状部署来自网格联邦。

多个网格提供了除单个网格之外的以下功能:

* 组织界限:业务范围
* 服务名称或命名空间复用:在多个不同的用途default 命名空间
* 加强隔离:将测试工作负载与生产工作负载隔离

您可以启用与 网格联合。联合时,每个网格可以公开一组服务和身份,所有参与的网格都可以识别。

![多个服务网格](https://istio.io/latest/docs/ops/deployment/deployment-models/multi-mesh.svg)

为避免服务命名冲突,可以为每个网格赋予全局唯一的网格ID,以确保每个服务的完全限定域名(FQDN)是唯一的 。

当联合不同信任域的网格时,您必须联合他们之间的身份和信任绑定。有关更多详细信息,请参见"网格之间的信任"部分。

## 租户模式

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

您可以配置租赁模型以满足以下组织隔离要求:

* 安全
* 政策
* 容量
* 成本
* 性能 Istio支持三种类型的租赁模型:
* 命名空间租户
* 集群租户
* 网格租户

## 命名空间租赁

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

默认情况下,来自多个名称空间的服务可以相互通信,但是您可以通过有选择地选择向其他名称空间公开哪些服务来提高隔离度。您可以为公开服务配置授权策略,以将访问权限限制为仅对适当的呼叫者进行访问。

![具有两个名称空间和公开服务的服务网格](https://istio.io/latest/docs/ops/deployment/deployment-models/exp-ns.svg)

命名空间租赁可以扩展到单个集群之外。使用多个集群时,默认情况下,每个集群中共享相同名称的名称空间都被视为相同的名称空间。例如,Service B在Team-1集群的命名空间West,并Service B在 Team-1集群的命名空间East是指相同的服务,并Istio合并他们的服务发现和负载均衡的端点。

![具有两个具有相同名称空间的集群的服务网格](https://istio.io/latest/docs/ops/deployment/deployment-models/cluster-ns.svg)

## 集群租赁

Istio支持使用集群作为租户单位。在这种情况下,您可以为每个团队提供一个专用集群或一组集群来部署其工作负载。通常,集群的权限仅限于拥有该集群的团队成员。您可以设置各种角色来进行更精细的控制,例如:

* 集群管理员
* 开发者

要将集群租用与Istio结合使用,请为每个团队的集群配置自己的集群 控制平面,允许每个团队管理自己的配置。或者,您可以使用Istio通过以下方式将一组集群实现为单个租户:远程集群 或多个同步 主要集群。有关详细信息,请参阅控制平面模型。

## 网格租户

在多网格部署中 网格联合,每个网格都可以用作隔离单位。

![两个具有两个集群和两个名称空间的隔离服务网格](https://istio.io/latest/docs/ops/deployment/deployment-models/cluster-iso.svg)

由于不同的团队或组织操作每个网格,因此服务命名很少是不同的。例如,Service C在foo集群的命名空间Team-1和Service C在服务foo集群的命名空间 Team-2将不是指相同的服务。最常见的示例是Kubernetes中的场景,其中许多团队将其工作负载部署到default 名称空间。

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://rocdu.gitbook.io/deep-understanding-of-istio/4/1.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.