Istio sidecar 和 ambient 模式的网络成本对比

深入对比 Istio sidecar 和 ambient 模式的网络成本与性能,分析其本地性感知及排查方法。

阅读原文请转到:https://jimmysong.io/blog/istio-sidecar-vs-ambient-network-cost-performance/

在服务网格架构不断演进的过程中,了解不同部署模式下的网络成本对于优化性能和资源效率至关重要。本文将对比 Istio 的 sidecar 模式和 ambient 模式的网络成本,分享我在这篇文章[1]中的一些观点。

Sidecar 模式

Istio 的 sidecar 模式通过在每个 pod 旁部署 sidecar 代理来拦截服务间的流量。这种架构引入了额外的网络跳转,可能会增加延迟和计算资源使用量。然而,该模式内置了重要的性能优化特性:本地性感知[2]。

图 1 展示了 Application 1 在 Istio sidecar 模式下访问位于不同可用区(AZ)的 Application 2 的流量路径。


图 1:Application 1 在 Istio sidecar 模式下访问位于不同可用区(AZ)的 Application 2 的流量路径。

Sidecar 模式的本地化感知

在 Sidecar 模式下,可以使用以下命令查看端点表中的本地性信息,从而更好地理解本地性管理:

go 复制代码
istioctl proxy-config endpoint <pod-name[.namespace]> -o yaml

以下是一个示例输出片段,显示了集群 outbound|9080||reviews.default.svc.cluster.local 的端点信息:

go 复制代码
- addedViaApi: true
  circuitBreakers:
    thresholds:
    - maxConnections: 4294967295
      maxPendingRequests: 4294967295
      maxRequests: 4294967295
      maxRetries: 4294967295
    - maxConnections: 1024
      maxPendingRequests: 1024
      maxRequests: 1024
      maxRetries: 3
      priority: HIGH
  edsServiceName: outbound|9080||reviews.default.svc.cluster.local
  hostStatuses:
  - address:
      socketAddress:
        address: 10.244.0.98
        portValue: 9080
    healthStatus:
      edsHealthStatus: HEALTHY
    locality:
      region: us-central1
      zone: us-central1-c
    stats:
    - name: cx_connect_fail
    - name: cx_total
    - name: rq_error
    - name: rq_success
    - name: rq_timeout
    - name: rq_total
    - name: cx_active
      type: GAUGE
    - name: rq_active
      type: GAUGE
    weight: 1
  - address:
    # 省略
  - address:
    # 省略
  name: outbound|9080||reviews.default.svc.cluster.local
  observabilityName: outbound|9080||reviews.default.svc.cluster.local;

从中可以看到 sidecar 模式下对 Envoy 代理对 pod 基于负载均衡的细粒度控制,例如 maxConnections, maxRequests, maxRetries 等 circuit breaker 配置,同时包含流量指标和健康状态。这些细节帮助在 Pod 级别管理流量的健康度、稳定性和延迟。

流量负载均衡考虑到 Locality,如 zone 和 region。Envoy 使用这些信息对流量执行更加精准的区域感知流量分配策略(如优先使用同一 zone 内的服务)。

每个 sidecar 代理都会优先将流量路由至同一可用区(AZ)或区域内的服务。这一设计减少了不必要的跨 AZ 流量,从而降低了由数据传输产生的高延迟和高成本。通过将流量限制在本地区域,sidecar 模式能够优化网络路径,避免跨区域的瓶颈。

尽管 sidecar 架构计算密集,但其本地性感知功能在维护高效流量路由方面起到了关键作用,尤其是在多区域云部署中,该功能有助于降低跨区域流量成本。

Ambient 模式

下图展示的 Istio ambient 模式的架构。


图 2:Istio ambient 模式

Istio ambient 模式包含两层:

    1. Ztunnel 安全层(L3/L4 流量处理):在此模式下,ambient 模式仅依赖 zTunnel 进行流量管理,主要处理三层和四层的流量,即网络和传输层。这一方式可减少开销,确保基本的连接和安全要求得到满足。
    1. Waypoint 代理层(L7 流量处理):此模式下引入了 waypoint 代理,以扩展至应用层流量,处理高级路由、观测性和策略执行。然而,waypoint 代理的部署位置对性能至关重要。为避免跨 AZ 流量,建议将 waypoint 代理分布于各个 AZ 内,以确保最佳性能。

Ambient 模式的本地化感知

相比之下,ambient 模式通过 ztunnel 和 waypoint 代理实现不同的架构。zTunnel 确保本地感知的流量路由,类似于 sidecar 模式,优先在同一 AZ 内路由流量,从而限制跨 AZ 流量并减少相应的网络成本。

图 3 展示了 Application 1 在 Istio ambient 模式下访问位于不同 AZ 的 Application 2 的流量路径。


图 3:Application 1 在 Istio ambient 模式下访问位于不同可用区(AZ)的 Application 2 的流量路径。

注意:图中 Waypoint Proxy 为演示目的单独显示;在实际中,它并不绑定到特定节点,可以与 Ztunnel 同节点部署。

可以通过以下命令查看 Ambient 模式中 Ztunnel 的详细配置和流量分布:

go 复制代码
istioctl ztunnel-config workload -o yaml

以下是一个示例输出:

go 复制代码
- applicationTunnel:
    protocol: ""
  canonicalName: productpage
  canonicalRevision: v1
  clusterId: Kubernetes
  hostname: ""
  locality:
    region: us-central1
    zone: us-central1-c
  name: productpage-v1-d5789fdfb-gmw5r
  namespace: default
  node: gke-cilium-default-pool-63a77182-f699
  protocol: HBONE
  serviceAccount: bookinfo-productpage
  status: Healthy
  trustDomain: cluster.local
  uid: Kubernetes//Pod/default/productpage-v1-d5789fdfb-gmw5r
  workloadIps:
    - 10.28.2.14
  workloadName: productpage-v1
  workloadType: deployment

从中可以看到 ztunnel 隧道的本地化信息,ztunnel 可以对进出该节点所有 pod 的流量进行集中式管理,比如统一执行负载均衡、健康检查和区域感知等操作。

Waypoint 代理优化

然而,waypoint 代理并非自动具有 AZ 感知功能。关键问题在于它们的部署位置。为优化成本与性能,waypoint 代理需要跨所有 AZ 进行扩展,以便本地处理流量。否则,可能导致跨 AZ 流量和额外成本。此外,当流量进入 waypoint 代理时,原始本地性信息可能被隐藏,进一步增加了路由优化的难度。

为优化性能和成本,建议 waypoint 代理在各个 AZ 内分布,以便能够本地处理流量。此外,ztunnel 与 waypoint 代理的通信设计为接近感知,从而确保流量被路由至最近的 waypoint 代理。这一特性进一步减少了跨 AZ 费用和延迟。

使用 Kiali dashboard 进行可视化

在对比 sidecar 和 ambient 模式时,为了更直观地理解本地性和路由行为,建议使用 Kiali dashboard。Kiali 能够直观展示不同模式下的流量路径,有助于理解 ambient 模式在复杂性上的表现。
Kiali 页面

总结

在对比 Istio 的 sidecar 和 ambient 模式的网络成本时,两种架构都提供了本地性感知的路由以减少跨 AZ 流量。然而,sidecar 模式在每个代理的本地性管理上更加完善,而 ambient 模式需要谨慎管理 waypoint 代理以避免额外成本。此外,需要考虑 ambient 模式的两种子模式(有或无 waypoint 代理)来理解它们对网络成本和性能的不同影响。

如果希望深入了解四种主要的服务网格数据平面部署模式,建议阅读完整文章这里[3]。


引用链接

[1] 这篇文章: https://tetrate.io/blog/ambient-vs-sidecar/
[2] 本地性感知: https://istio.io/latest/docs/tasks/traffic-management/locality-load-balancing/
[3] 这里: https://tetrate.io/blog/ambient-vs-sidecar/

相关推荐
是Dream呀41 分钟前
Python从0到100(七十八):神经网络--从0开始搭建全连接网络和CNN网络
网络·python·神经网络
Karoku0661 小时前
【k8s集群应用】kubeadm1.20高可用部署(3master)
运维·docker·云原生·容器·kubernetes
kaixin_learn_qt_ing1 小时前
了解RPC
网络·网络协议·rpc
安全小王子2 小时前
Kali操作系统简单介绍
网络·web安全
Hacker_LaoYi3 小时前
【漏洞分析】DDOS攻防分析(四)——TCP篇
网络·tcp/ip·ddos
爱吃水果蝙蝠汤3 小时前
DATACOM-IP单播路由(BGP)-复习-实验
网络·网络协议·tcp/ip
Sun_12_24 小时前
SQL注入(SQL lnjection Base)21
网络·数据库
网络安全Jack5 小时前
网络安全概论——身份认证
网络·数据库·web安全
易我数据恢复大师5 小时前
如何彻底删除电脑数据以防止隐私泄露
网络·电脑·数据删除·擦除