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/

相关推荐
_丿丨丨_4 小时前
XSS(跨站脚本攻击)
前端·网络·xss
一只栖枝5 小时前
HCIA-Security 认证精讲!网络安全理论与实战全掌握
网络·web安全·网络安全·智能路由器·hcia·it·hcia-security
FileLink跨网文件交换5 小时前
文件摆渡系统十大软件|文件摆渡系统如何构建网络安全呢?
网络
指月小筑7 小时前
K8s 自定义调度器 Part1:通过 Scheduler Extender 实现自定义调度逻辑
云原生·容器·kubernetes·go
晨欣8 小时前
大型语言模型(LLM)在网络安全中最具商业价值的应用场景(Grok3 回答 DeepSearch模式)
网络·web安全·语言模型
有书Show9 小时前
个人IP的塑造方向有哪些?
网络·网络协议·tcp/ip
HHRL-yx9 小时前
C++网络编程 5.TCP套接字(socket)通信进阶-基于多线程的TCP多客户端通信
网络·c++·tcp/ip
迈威通信9 小时前
接口黑洞?破!安全堡垒?筑!冰火炼狱?战!MES7114W终极掌控
网络·安全
baynk10 小时前
wireshark的常用用法
网络·测试工具·wireshark·ctf
莫到空离11 小时前
LVS三种模式实战
linux·服务器·网络