服务网格 04：Sidecar 怎样接管流量

注入了代理，应用为何不必改 orders 的地址

第 03 篇把 orders 的库存地址显式改成了 Envoy listener。sidecar 模式希望应用继续访问原有 Service 地址，由同 Pod 的代理接管特定出入站流量。这里的“接管”不是 Istiod 替应用转发请求，而是 Pod 生命周期中添加代理并建立网络重定向规则；应用、代理和真正的目标 Pod 都需要从实际运行状态里核对。

sidecar 出站与入站流量分别从 Pod 网络命名空间中的重定向规则进入代理

图的左半段是 orders 的出站请求，右半段是 inventory 的入站请求。两个代理均在各自 Pod 附近工作；控制面向代理提供配置但通常不在业务连接中间。读者需先理解 Pod 多容器共享网络命名空间、Service 地址与 Envoy listener/cluster 的区别。

从 Pod 创建到一条连接被代理处理

Pod 被创建时，已配置且适用的注入机制可能修改新 Pod 的定义，加入代理容器以及代理启动所需配置。只给现存 namespace 打标签不会凭空改写已经运行的 Pod；必须检查新 Pod的容器列表和注入状态。控制面安装、webhook 匹配、Pod/namespace 标签、revision 及显式不注入设置都会影响结果。不能用“部署了 istiod”代替注入证据。

在典型的透明接管方式中，Pod 网络命名空间内的重定向规则把应用发起的出站连接送到代理的出站 listener，把面向应用端口的入站连接送到代理的入站 listener。规则可以由初始化容器或 Istio CNI 负责配置；具体组件、端口和链名依安装版本/模式而定。之后出站 Envoy 按其路由/cluster 配置寻找后端，后端 Pod 的入站 Envoy 再按规则把请求交给 inventory。网络可达与网格能识别为 HTTP不是同一命题：未识别协议时的治理能力须另行核验。

这条路径有两个容易误判的地方。第一，应用依旧向 inventory 的 Service 地址发送请求，不代表连接一定绕过代理：捕获发生在应用的 socket 与目标网络之间。第二，看见两个容器或一条重定向规则也不等于测试流量实际经过了 Envoy；必须用请求 ID 同时关联应用、代理访问日志与后端响应。istioctl proxy-config 可检查 listener/cluster 等当前配置，但静态快照不能代替这条请求的日志。

排除规则不是功能验证

Istio 的流量排除注解可以按端口或地址改变捕获范围；其名称和具体支持范围要与部署版本的注解参考核对。设合成 external-stub 在某端口监听：对该端口应用出站排除后，相同输入可能仍拿到相同业务响应。但这只能说明服务还可达，不能独自证明绕过。应比较改变前后的 Pod 捕获规则、代理访问日志/连接计数、进程 socket 的目标，以及 external-stub 的请求 ID；并排除其他调用也打到该端口的混淆。排除传输捕获不等于获得业务授权，也不自动建立端到端 TLS。

注入失败、代理尚未就绪或应用先发连接时，具体失败表现取决于启动策略和版本，不能把某次 503 全部归因为重定向。主线下一篇专门拆解应用与代理就绪及终止顺序。

集群实验入口和当前证据

沿用 examples/service-mesh/ 的同一读请求 sku=paper 与 X-Request-ID。先在隔离集群固定 Istio 版本、安装 profile、Kubernetes/CNI 版本和镜像 digest，再核对当前 context；使用专用 service-mesh-lab namespace。要保存三个层次的对照：未注入 Pod 的成功路径；新建已注入 Pod 的相同请求；仅对合成 external-stub 端口作排除后的请求。每种情况分别保存 Pod 容器与 revision 标签、捕获规则/代理配置、同一请求 ID 的代理与应用日志，以及应用响应。排除场景的失败断言若代理仍拦截预期绕过的请求，必须返回非零；不能只凭功能成功判定通过。

按下面的只读前置命令检查环境（在 examples/service-mesh/ 执行；实际 context 名必须先从隔离集群确认）：

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

目前前置检查的证据 examples/service-mesh/evidence/02/20261001T130351Z-2539112/ 显示 kubectl 不在 PATH，退出 127；宿主没有容器运行时或 Istio 安装，Sidecar 注入、重定向及排除实验全部 NOT_RUN。没有经实测的 Pod 清单、CNI 规则、代理日志或出口请求数据。可复建环境与未完成的验收步骤见 writing-plans/service-mesh/CONTINUE.md，不能把上一期独立 Envoy 模板视为已经有 sidecar。

练习与参考解答

对现有 namespace 打开自动注入后，原 Pod 仍只有应用容器，另一新 Pod 有代理。哪个更可能被透明捕获？参考解答：首先按 Pod 实际容器、状态和捕获规则确认；注入通常影响创建阶段，原 Pod 不会因为标签变化被原地加入容器。仍需对新 Pod 发带标识请求并比对代理与后端记录，不能仅凭容器数宣布流量已接管。
给外部依赖端口加排除配置后，业务仍返回 200。如何构造反例说明“200 不是绕过证据”？参考解答：让同一合成请求分别走被捕获端口与排除端口，记录各自的请求 ID、代理访问日志/连接统计及目标进程日志，并检查捕获规则；若排除前后业务均为 200，却只有前者出现在对应代理处理记录中，则说明仅看响应无法判断路径。必须防止日志采样或端口复用造成误读。