深入对比 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 的流量路径。
Sidecar 模式的本地化感知
在 Sidecar 模式下，可以使用以下命令查看端点表中的本地性信息，从而更好地理解本地性管理：
istioctl proxy-config endpoint <pod-name[.namespace]> -o yaml以下是一个示例输出片段，显示了集群 outbound|9080||reviews.default.svc.cluster.local 的端点信息：
- addedViaApi: truecircuitBreakers:thresholds:- maxConnections: 4294967295maxPendingRequests: 4294967295maxRequests: 4294967295maxRetries: 4294967295- maxConnections: 1024maxPendingRequests: 1024maxRequests: 1024maxRetries: 3priority: HIGHedsServiceName: outbound|9080||reviews.default.svc.cluster.localhostStatuses:- address:socketAddress:address: 10.244.0.98portValue: 9080healthStatus:edsHealthStatus: HEALTHYlocality:region: us-central1zone: us-central1-cstats:- name: cx_connect_fail- name: cx_total- name: rq_error- name: rq_success- name: rq_timeout- name: rq_total- name: cx_activetype: GAUGE- name: rq_activetype: GAUGEweight: 1- address:# 省略- address:# 省略name: outbound|9080||reviews.default.svc.cluster.localobservabilityName: 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 模式的架构。
Istio ambient 模式包含两层：
1. Ztunnel 安全层（L3/L4 流量处理）：在此模式下，ambient 模式仅依赖 zTunnel 进行流量管理，主要处理三层和四层的流量，即网络和传输层。这一方式可减少开销，确保基本的连接和安全要求得到满足。
2. Waypoint 代理层（L7 流量处理）：此模式下引入了 waypoint 代理，以扩展至应用层流量，处理高级路由、观测性和策略执行。然而，waypoint 代理的部署位置对性能至关重要。为避免跨 AZ 流量，建议将 waypoint 代理分布于各个 AZ 内，以确保最佳性能。
Ambient 模式的本地化感知
相比之下，ambient 模式通过 ztunnel 和 waypoint 代理实现不同的架构。zTunnel 确保本地感知的流量路由，类似于 sidecar 模式，优先在同一 AZ 内路由流量，从而限制跨 AZ 流量并减少相应的网络成本。
图 3 展示了 Application 1 在 Istio ambient 模式下访问位于不同 AZ 的 Application 2 的流量路径。
注意：图中 Waypoint Proxy 为演示目的单独显示；在实际中，它并不绑定到特定节点，可以与 Ztunnel 同节点部署。
可以通过以下命令查看 Ambient 模式中 Ztunnel 的详细配置和流量分布：
istioctl ztunnel-config workload -o yaml以下是一个示例输出：
- applicationTunnel:protocol: ""canonicalName: productpagecanonicalRevision: v1clusterId: Kuberneteshostname: ""locality:region: us-central1zone: us-central1-cname: productpage-v1-d5789fdfb-gmw5rnamespace: defaultnode: gke-cilium-default-pool-63a77182-f699protocol: HBONEserviceAccount: bookinfo-productpagestatus: HealthytrustDomain: cluster.localuid: Kubernetes//Pod/default/productpage-v1-d5789fdfb-gmw5rworkloadIps:- 10.28.2.14workloadName: productpage-v1workloadType: 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 模式在复杂性上的表现。
总结
在对比 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/
