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

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

版权声明
本文为 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 Agentztunnel网络命名空间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"

你将看到例如下面的输出,注意里面的 inboundoutbound 是相对于 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-istioproductpage 的入站流量。流量经过 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/12/03