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

Sidecar 模式

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

图 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: 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 模式的架构。

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: 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 模式在复杂性上的表现。

总结

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

如果希望深入了解四种主要的服务网格数据平面部署模式，建议阅读[深入解析服务网格的四种数据平面部署模式：性能、安全性与成本分析]/blog/service-mesh-data-plane-deployment-modes/)。