服务网格 26：Ambient 数据面如何转发请求

没有业务 Pod 内的 sidecar，谁在传输层接管

先保留第 04 篇的调用基线：orders → inventory-v1/v2 仍是 Pod 间业务请求，Istiod 下发信息而不转发普通业务流量。Ambient 把原来随每个应用 Pod 部署的代理职责拆开：Istio CNI 处理加入 ambient 的流量接管，节点上的 ztunnel 为工作负载提供传输安全与四层授权；需要 HTTP 路由、方法或路径策略时，另由 waypoint 执行七层处理。本篇只验第一层，不能拿到库存 HTTP 200 就宣称七层规则已生效。

应用请求经过 CNI 接管与节点 ztunnel，以 HBONE 在节点代理间承载 TCP 流；七层 waypoint 不在本篇路径中

图是跨节点情形的待验证路径模型：orders 发出的 TCP 流被转向源节点 ztunnel，经 HBONE 到目标节点 ztunnel，再送达库存应用。HBONE 使用 HTTP/2 CONNECT 封装并以 mTLS 保护所承载的 TCP 流；HTTP/2 是隧道协议，不表示库存应用的 HTTP/1.1 已变成 HTTP/2，也不能从图中推导请求头参与了负载均衡。同节点通信的路径是否同样形成跨 ztunnel 隧道须按实际版本和流量证据核对，不能把跨节点箭头照搬。

身份、四层授权与七层路由的分界

orders、inventory 的 ServiceAccount 可以构成不同工作负载身份；身份从证书签发、代理获取到连接握手必须逐层核验。接收端 ztunnel 能基于受支持的四层属性和身份执行策略；判断 /quote 路径或 x-canary 头需要七层解析，属于第 27 篇 waypoint 的待验证范围。单纯给 namespace 加入 ambient 并不会自动证明所有未入网格来源都被拒绝，也不能把 Service 的成功响应当作 mTLS 身份已核对。

业务数据是否经加密，需要限定哪段连接：源应用到本节点 ztunnel、跨节点 ztunnel 隧道、目标 ztunnel 到库存应用、入口/出口网关和网格外客户端是不同观察点。HBONE mTLS 只解释代理间的受保护段，不能概括“全程加密”。只对 Service 发请求的正例也不能证明直达 Pod IP 或网格外访问受到同样策略保护；对 HTTP 属性的授权写在 L4 执行位置既不能实现期望的七层匹配，具体拒绝表现须在选定 Istio 版本下验证。

从对象到请求的五层证据

先在 examples/service-mesh/ 对具名隔离 context 运行只读前置检查：

1	`SM_CONTEXT=service-mesh-lab SM_NAMESPACE=service-mesh-lab bash scripts/check-02.sh`

通过后再确定实际 Kubernetes/Istio 发布版本、相容矩阵、istio-cni/ztunnel 镜像 digest、ambient 入网标签和生效范围。将同一套 frontend → orders → inventory-v1/v2 与 external-stub 以 Pod 可达监听和 Service DNS 部署，先采无网格基线；随后在同节点与跨节点分别记录：①入网对象和 CNI 重定向状态，②控制面的工作负载身份/目的服务信息，③ztunnel 当前收到的工作负载与策略状态，④带同一请求 ID 的实际网络路径和证书元数据，⑤客户端响应、库存版本、应用日志与账本。只要其中一层缺失，就不能用别层替代。

正例为 orders 使用预期身份向 inventory 请求相同合成 SKU；负例换错误 ServiceAccount、再用未入网格来源以及直达 Pod IP 分别对照。先明确每种请求期望经过哪一层；若策略预期拒绝却仍成功，断言必须以非零退出。拒绝可能表现为连接失败而不是固定 HTTP 状态码；需要同时核对应用端是否收到请求与接收端代理的拒绝记录，防止把网络不可达错判为授权成功。不可在真实生产 context 注入故障或更改安全策略。

当前 examples/service-mesh/evidence/26/20261001T143502Z-2669762/ 的前置脚本退出 127，原始错误为 NOT_RUN: kubectl: command not found；无集群/CNI/ztunnel 及固定镜像，以上两组正反流量实验全部 NOT_RUN。既有进程账本不能充当 HBONE 或真实 mTLS 的证据；即使以后用容器启动单个进程，也不能替代 CNI 与真实 Pod 路径。

练习与参考解答

成功访问 /quote 且 namespace 已打 ambient 标签，能证明请求经 HBONE、并按 HTTP 路径授权了吗？参考解答：不能。至少还需确认 CNI 接管、源/目标 ztunnel 与实际连接/身份；HTTP 路径需要 waypoint 的七层策略及经过 waypoint 的请求证据，标签或 HTTP 200 不足以证明。
保留 orders ServiceAccount 不变，只把目标改成直达 inventory Pod IP，怎样判断先前的四层策略是否仍保护它？参考解答：同时保存原 Service 路径与直达路径的客户端退出码、网络端点、代理记录和应用端同一请求 ID；若预期拒绝却成功，应将断言置为非零并排查接管/策略作用域，不能因为两个请求都返回 200 就断言“策略无差别”。结果依赖冻结版本与实际路径，不预填状态码。