Istio Ambient 模式中的透明流量拦截过程详解

本文是关于 Istio Ambient 模式的系列文章的第一篇，介绍了如何通过透明流量拦截实现无需 Sidecar 的服务网格。详细分析了 Istio CNI Node Agent、ztunnel 以及 Pod 网络命名空间的交互过程。

  • 2024/11/18
  • Istio
  • 7 分钟
  • 1619 字
版权声明
本文为 Jimmy Song 原创。转载请注明来源： https://jimmysong.io/blog/istio-ambient-traffic-interception/
查看本文大纲

这是我关于 Istio ambient 模式系列文章的第一篇。在接下来的几篇中，我将深入探讨 ambient 模式的关键组件及其工作原理，包括 ztunnel 如何将流量转发到 waypoint proxy，waypoint proxy 如何处理流量，以及通过 bookinfo 示例完整理解流量路径的操作。由于流量拦截是服务网格的基础功能，因此我选择从它开始，为大家提供扎实的理解基础。

Istio ambient 模式是一种无需在每个 pod 中注入 sidecar 的服务网格实现方式。它通过在 pod 的网络命名空间内配置透明流量拦截和重定向，使应用程序无需修改即可享受服务网格的功能。以下内容将详细解析透明流量拦截的实现过程，涉及组件如 Istio CNI Node Agent、ztunnel、网络命名空间 和 iptables 规则，并通过流程图和示意图进行说明。

背景知识

Linux 网络命名空间

网络命名空间（Network Namespace） 是 Linux 内核的功能，用于隔离不同进程的网络环境。每个网络命名空间都有独立的网络设备、IP 地址、路由表和 iptables 规则。容器技术（如 Docker、Kubernetes）利用网络命名空间为每个容器（或 pod）提供独立的网络栈。

Istio CNI Node Agent

Istio CNI Node Agent 是 ambient 模式中的核心组件之一，负责在 Kubernetes 节点上检测加入 ambient 网格的 pod，并为这些 pod 配置流量重定向规则。需要注意的是，这里使用的是 Istio CNI Node Agent，而非传统的 Istio CNI 插件。Node Agent 是一个守护进程，与 ztunnel 协同工作，而不是直接参与网络插件的工作。

ztunnel

ztunnel 是 ambient 模式中的重要组件，以 DaemonSet 的形式运行在每个节点上，负责：

  • 接收并处理被重定向的流量；
  • 实现 L4 层的策略，如 mTLS 加密和访问控制；
  • 与控制平面通信以获取配置和证书。

HBONE（基于 HTTP 的隧道协议）

HBONE（HTTP-Based Overlay Network Encapsulation） 是 Istio 引入的协议，用于在 ztunnel 和 waypoint proxy 之间传输任意 TCP 流量。HBONE 利用 HTTP/2 和 HTTP/3 的多路复用及加密特性，提高通信效率和安全性。

流量拦截过程详解

在 ambient 模式下，应用程序 pod 无需修改代码，也不需要注入 sidecar。流量拦截和重定向的主要过程发生在 pod 的网络命名空间 内部，这种方式避免了与底层 CNI 的冲突。以下是其步骤概览：

image
Istio ambient 模式的流量拦截过程

流量拦截详细步骤

  1. pod 启动与网络配置：
    • Kubernetes 创建 pod 时，通过 Container Runtime Interface（CRI）调用底层 CNI 插件（如 Calico、Cilium）为 pod 配置网络。
    • 此时，pod 的网络命名空间（netns）已经建立。
  2. Istio CNI Node Agent 配置流量重定向：
    • Istio CNI Node Agent 监测到新 pod 被标记为 ambient 模式（通过标签 istio.io/dataplane-mode=ambient）。
    • 进入 pod 的网络命名空间，设置 iptables 规则以拦截流量。
    • 将网络命名空间的文件描述符（FD）传递给 ztunnel。
  3. ztunnel 在 pod 网络命名空间中启动监听套接字：
    • ztunnel 接收到网络命名空间的 FD，在其中启动监听套接字以处理重定向的流量。
  4. 透明流量拦截与处理：
    • 应用程序发出的流量被 pod 内的 iptables 规则拦截，并透明地重定向到 ztunnel。
    • ztunnel 对流量执行策略检查、加密等处理后转发到目标服务。
    • 返回的响应流量通过 ztunnel 解密并返回给应用程序。

想了解更多关于 Istio CNI 处理 iptables 的细节请见我的另一篇博客 Istio ambient 模式中的 iptables 规则解析。

ztunnel 日志分析

你可以通过下面的命令查看所有 ztunnel 日志中有关流量拦截的记录，可以帮助你理解 ztunnel 的运行原理：

kubectl -n istio-system logs -l app=ztunnel | grep -E "inbound|outbound"

你将看到例如下面的输出，注意里面的 inbound 和 outbound 是相对于 ztunnel 而言的。

入站流量示例

2024-11-16T10:33:01.410751Z	info	access	connection complete	src.addr=10.28.2.19:58000 src.workload="bookinfo-gateway-istio-64fc6d75d6-s442s" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/bookinfo-gateway-istio" dst.addr=10.28.2.18:15008 dst.hbone_addr=10.28.2.18:9080 dst.service="productpage.default.svc.cluster.local" dst.workload="productpage-v1-57ffb6658c-tgbjs" dst.namespace="default" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-productpage" direction="inbound" bytes_sent=9603 bytes_recv=2052 duration="2110ms"

该日志描述了从 bookinfo-gateway-istio 到 productpage 的入站流量。流量经过 ztunnel 的 15008 端口，使用了 HBONE 隧道加密，身份通过 SPIFFE 确认。

出站流量示例

2024-11-16T10:32:59.360677Z	info	access	connection complete	src.addr=10.28.2.18:51960 src.workload="productpage-v1-57ffb6658c-tgbjs" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/bookinfo-productpage" dst.addr=10.28.2.14:15008 dst.hbone_addr=34.118.226.6:9080 dst.service="details.default.svc.cluster.local" dst.workload="waypoint-7594b5b786-vgjwz" dst.namespace="default" dst.identity="spiffe://cluster.local/ns/default/sa/waypoint" direction="outbound" bytes_sent=794 bytes_recv=414 duration="40ms"

此日志描述了 productpage pod 访问 details 服务时的出站流量。流量由 ztunnel 使用 HBONE 隧道转发到 waypoint pod（15008 端口）。

总结

Istio ambient 模式通过 Istio CNI Node Agent 和 ztunnel 的协作，实现了无需 sidecar 的透明流量拦截。其关键特性包括：

  • 兼容性强：避免与底层 CNI 冲突。
  • 简化运维：无需修改应用程序代码，降低资源消耗。
  • 安全性高：通过 HBONE 实现端到端的加密传输。

后续文章中，我将进一步探讨 Istio ambient 模式的高级功能，包括 L7 流量路径分析和网络拓扑构建过程，敬请期待。

参考

最后更新于 2024/11/18

Istio Ambient