|
| 1 | +--- |
| 2 | +title: Ambient 多集群性能 |
| 3 | +description: Ambient 多集群性能和可扩展性摘要。 |
| 4 | +weight: 30 |
| 5 | +keywords: |
| 6 | + - performance |
| 7 | + - scalability |
| 8 | + - scale |
| 9 | + - multicluster |
| 10 | +owner: istio/wg-environments-maintainers |
| 11 | +test: n/a |
| 12 | +--- |
| 13 | + |
| 14 | +使用 Ambient 模式的多集群部署，您可以以最小的开销提供真正具有全局弹性的大规模应用程序。 |
| 15 | +除了常规功能外，Istio 控制平面还会在所有从集群上创建监视点， |
| 16 | +以保持每个集群提供的全局服务列表的最新状态。 |
| 17 | +Istio 数据平面可以将流量路由到这些远程全局服务，既可以作为正常流量分发的一部分， |
| 18 | +也可以在本地服务不可用时专门进行路由。 |
| 19 | + |
| 20 | +## 控制平面性能 {#control-plane-performance} |
| 21 | + |
| 22 | +如[此处](/zh/docs/ops/deployment/performance-and-scalability)所述， |
| 23 | +Istio 控制平面的扩展通常是部署变更、配置变更和连接代理数量的乘积。 |
| 24 | +Ambient 多集群为控制平面的可扩展性增加了两个新维度：远程集群数量和远程服务数量。 |
| 25 | +由于控制平面不为远程集群编写代理（假设采用多主部署拓扑）， |
| 26 | +因此向网格中添加 10 个远程服务对控制平面性能的影响远低于添加 10 个本地服务。 |
| 27 | + |
| 28 | +我们的多集群控制平面负载测试在 10 个集群中分别创建了 300 个服务， |
| 29 | +包含 4000 个端点，并将这些集群逐个添加到网格中。 |
| 30 | +以这种规模添加远程集群对控制平面的影响约为 **1% 的 CPU 核心和 180 MB 内存**。 |
| 31 | +在这种规模下，如果控制平面规模适当，在网格中扩展到 10 个集群以上应该是安全的。 |
| 32 | +需要注意的是，对于多集群可扩展性，水平扩展控制平面无济于事， |
| 33 | +因为每个控制平面实例都维护着完整的远程服务缓存。我们建议您修改控制平面的资源请求和限制， |
| 34 | +进行垂直扩展以满足多集群网格的需求。 |
| 35 | + |
| 36 | +## 数据平面性能 {#data-plane-performance} |
| 37 | + |
| 38 | +当流量路由到从集群时，源数据平面会建立一条通往目标集群东西向网关的加密隧道。 |
| 39 | +然后，它会在第一个隧道内部建立一条二级加密隧道，该隧道终止于目标数据平面。 |
| 40 | +这种内外隧道的使用使得数据平面能够安全地与从集群通信， |
| 41 | +而无需了解哪些 Pod IP 代表哪些服务的详细信息。 |
| 42 | + |
| 43 | +然而，这种双重加密确实会带来一些开销。 |
| 44 | +数据平面负载测试测量了同一集群内 Pod 之间以及两个不同集群之间 Pod 之间的流量响应延迟， |
| 45 | +以了解双重加密对延迟的影响。此外，双重加密需要两次握手， |
| 46 | +这会不成比例地影响到与远程集群的新连接的延迟。如下所示， |
| 47 | +我们的初始连接平均观察到 2.2 毫秒（346%）的额外延迟， |
| 48 | +而使用现有连接的请求则观察到 0.13 毫秒（72%）的增加。 |
| 49 | +虽然这些数字看起来很显著，但预计大多数多集群流量将跨可用区或区域， |
| 50 | +并且与数据中心之间的整体传输延迟相比，观察到的开销延迟的增加将是微不足道的。 |
| 51 | + |
| 52 | +{{< image link="./ambient-mc-dataplane-reconnect.png" caption="重新连接的请求延迟" width="90%" >}} |
| 53 | + |
| 54 | +{{< image link="./ambient-mc-dataplane-existing.png" caption="无需重新连接即可请求延迟" width="90%" >}} |
0 commit comments