深入探讨环境模式和Sidecar模式共存下的网络流量路径

Istio 有两种部署模式：环境模式和 Sidecar 模式。前者仍在开发中，后者是经典模式。因此，环境模式和 Sidecar 模式共存应该是正常的部署形式，这也是本文可能对 Istio 用户有所帮助的原因。

背景

在现代微服务架构中，服务之间的通信和管理至关重要。为了应对这一挑战，Istio 作为一种服务网格技术应运而生。它通过利用 Sidecar 提供流量控制、安全性和卓越的观察能力。为了进一步提高 Istio 的适应性和灵活性，Istio 社区开始探索一种新的模式——环境模式。在这种模式下，Istio 不再依赖于显式的 Sidecar 注射，而是通过 ztunnel 和 Waypoint 代理实现服务之间的通信和网格管理。环境模式也带来了一系列改进，例如更低的资源消耗、更简单的部署和更灵活的配置选项。启用环境模式时，我们无需重新启动 Pod，这使得 Istio 能够在各种场景中发挥更好的作用。

有很多博客介绍和分析了环境模式，您可以在本文的参考资源部分找到这些博客，本文将分析 Istio 环境模式和 Sidecar 模式下的网络流量路径。

为了阐明网络流量路径并使其更容易理解，本文探讨了以下两种场景并配有相应的图表

• 环境模式服务到 Sidecar 模式服务的网络路径
• Sidecar 模式服务到环境模式服务的网络路径

关于分析的信息

分析基于 Istio 1.18.2，其中环境模式使用 iptables 进行重定向。

环境模式 sleep 到 Sidecar 模式 httpbin

第一个场景的部署和配置

• sleep 部署在 foo 命名空间中
  • sleep Pod 调度到节点 A
• httpbin 部署在 bar 命名空间中
  • httpbin 调度到节点 B
• foo 命名空间启用环境模式（foo 命名空间包含标签：istio.io/dataplane-mode=ambient）
• bar 命名空间启用 Sidecar 注射（bar 命名空间包含标签：istio-injection: enabled）

根据以上描述，部署和网络流量路径如下所示

如果启用了环境模式，ztunnel 将作为 DaemonSet 部署在 istio-system 命名空间中，而 istio-cni 和 ztunnel 将为 ztunnel Pod 和每个节点上的 Pod 生成 iptables 规则和路由。

所有进出启用环境模式的 Pod 的网络流量都将根据网络重定向逻辑通过 ztunnel。然后，ztunnel 将流量转发到正确的端点。

环境模式 sleep 到 Sidecar 模式 httpbin 的网络流量路径分析

根据上图，网络流量路径的详细信息如下所示

(1) (2) (3) sleep 服务的请求流量从 sleep Pod 的 veth 发送出去，它将被标记并通过遵循 iptables 规则和路由规则转发到节点上的 istioout 设备。节点 A 上的 istioout 设备是一个Geneve隧道，隧道的另一端是 pistioout，位于同一节点上的 ztunnel Pod 内部。

(4) (5) 当流量通过 pistioout 设备到达时，Pod 内部的 iptables 规则会拦截并将其通过 Pod 中的 eth0 接口重定向到端口 15001。

(6) 根据原始请求信息，ztunnel 可以获取目标服务的端点列表。然后，它将处理将请求发送到端点，例如其中一个 httpbin Pod。最后，请求流量将通过容器网络进入 httpbin Pod。

(7) 到达 httpbin Pod 的请求流量将被其 iptables 规则拦截并重定向到 Sidecar 的端口 15006。

(8) Sidecar 处理通过端口 15006 传入的入站请求流量，并将流量转发到同一 Pod 中的 httpbin 容器。

Sidecar 模式 sleep 到环境模式 httpbin 和 helloworld

第二个场景的部署和配置

• sleep 部署在 foo 命名空间中
  • sleep Pod 调度到节点 A
• httpbin 部署在 bar-1 命名空间中
  • httpbin Pod 调度到节点 B
  • httpbin 的 Waypoint 代理已禁用
• helloworld 部署在 bar-2 命名空间中
  • helloworld Pod 调度到节点 D
  • helloworld 的 Waypoint 代理已启用
  • Waypoint 代理调度到节点 C
• foo 命名空间启用 Sidecar 注射（foo 命名空间包含标签：istio-injection: enabled）
• bar-1 命名空间启用环境模式（bar-1 命名空间包含标签：istio.io/dataplane-mode=ambient）

根据以上描述，部署和网络流量路径如下所示

Sidecar 模式 sleep 到环境模式 httpbin 的网络流量路径分析

上图上半部分描述了从 sleep Pod（Sidecar 模式）到 httpbin Pod（环境模式）的请求的网络流量路径。

(1) (2) (3) (4) sleep 容器向 httpbin 发送请求。请求被 iptables 规则拦截并定向到 sleep Pod 中 Sidecar 上的端口 15001。然后，Sidecar 处理请求并根据从 Istiod（控制平面）接收到的配置路由流量，将流量转发到节点 B 上与 httpbin Pod 对应的 IP 地址。

(5) (6) 请求发送到设备对（veth httpbin <-> httpbin Pod 内部的 eth0）后，请求会被拦截并使用 iptables 和路由规则转发到节点 B 上的 istioin 设备（httpbin Pod 正在运行的节点），遵循其 iptables 和路由规则。节点 B 上的 istioin 设备和同一节点上 ztunnel Pod 内部的 pistion 设备通过Geneve隧道连接。

(7) (8) 请求进入 ztunnel Pod 的 pistioin 设备后，ztunnel Pod 中的 iptables 规则会拦截并重定向流量，通过 Pod 内运行的 ztunnel 代理上的端口 15008 进行重定向。

(9) 进入端口 15008 的流量将被视为入站请求，然后 ztunnel 会将请求转发到同一节点 B 上的 httpbin Pod。

通过 Waypoint 代理，Sidecar 模式 sleep 到环境模式 httpbin 的网络流量路径分析

与图的上半部分相比，下半部分在 sleep、ztunnel 和 httpbin Pod 之间的路径中插入了一个 Waypoint 代理。Istio 控制平面拥有服务网格的所有服务信息和配置。当 helloworld Pod 与 Waypoint 代理一起部署时，sleep Pod Sidecar 收到的 helloworld 服务的 EDS 配置将更改为 envoy_internal_address 类型。这会导致通过 Sidecar 的请求流量通过基于 HTTP 的覆盖网络 (HBONE)协议转发到节点 C 上 Waypoint 代理的端口 15008。

Waypoint 代理是 Envoy 代理的一个实例，它根据从控制平面接收到的路由配置将请求转发到 helloworld Pod。一旦流量到达节点 D 上的 veth，它将遵循与上一个场景相同的路径。

总结

Sidecar 模式是使 Istio 成为优秀服务网格的原因。但是，Sidecar 模式也可能导致问题，因为它要求应用程序和 Sidecar 容器在同一 Pod 中运行。Istio 环境模式通过集中式代理（ztunnel 和 Waypoint）实现服务之间的通信。环境模式提供了更大的灵活性和可扩展性，减少了资源消耗（因为它不需要为网格中的每个 Pod 都配备一个 Sidecar），并允许更精确的配置。因此，毫无疑问，环境模式是 Istio 的下一个发展方向。很明显，虽然环境模式仍处于 Alpha 阶段，Sidecar 模式仍然是 Istio 的推荐模式，但 Sidecar 和环境模式的共存可能会持续很长时间，随着环境模式走向 Beta 阶段和未来的版本，它将为用户提供一种更轻量级的运行和采用 Istio 服务网格的选项。

参考资源

• 环境网格中的流量：Istio CNI 和节点配置
• 环境网格中的流量：使用 iptables 和 Geneve 隧道进行重定向
• 环境网格中的流量：ztunnel、eBPF 配置和 Waypoint 代理