Pod、节点还是集群：VPN Sidecar 究竟重路由了什么

Kubernetes Pod 里的 VPN sidecar 看起来像是行为更规矩的主机级 VPN，而这种相似性止步于命名空间边界。同一 Pod 内的容器共享网络命名空间，包括地址与端口空间，因此安装路由和策略的 sidecar 确实改变了应用数据包的走向。它对节点上的其他 Pod 毫无影响，除非特意配置，也不会触碰节点自身的协议栈。把这条边界搞清楚，同时决定了你能部署什么、又必须测试什么。下面各节从命名空间向外展开。

共享命名空间，共享后果

同一 Pod 内的两个容器通过 loopback 通信、看到相同的网络接口，这正是 sidecar 模式得以成立的原因：应用无需知道隧道的存在，因为它解析到的路由就装在它所用的命名空间里。同一性质也意味着 sidecar 的错误就是应用的错误。一条捕获范围过大的路由，或把 DNS 指向隧道内解析器的改动，会立刻作用于该 Pod 中的每个进程。共享命名空间内不存在按容器划分的路由，所以 sidecar 无法只作用于某一个进程。

这是审查时要记住的机制：影响半径是 Pod，而不是节点，也不是集群。

sidecar 触及不到的地方

其他 Pod 保留各自的命名空间与路由，因此需要同样出口的工作负载要么配同样的 sidecar，要么改用节点级方案。节点自身的流量同样在 Pod 命名空间之外；使用主机网络的 Pod 则有意完全退出这套隔离。如果为了图方便用主机网络运行 sidecar，你就把范围从一个 Pod 扩大到了整个节点，这一点应当明说。

集群服务流量是另一个常见意外。Pod 内一条宽泛的默认路由可能劫持发往 API 服务器或 ClusterIP 服务的请求，随后这些请求以看似隧道故障的方式失败。

路由规划：Pod、服务、节点与 VPN 网段

把四个网段写下来并在部署前检查是否重叠：Pod CIDR、服务 CIDR、节点地址，以及 VPN 背后的目标网段。VPN 私有网段与集群自身空间重叠并不罕见，默认路由是错误解法。路由规划应与清单放在同一个仓库里，因为下一个集群可能分配完全不同的 Pod 与服务网段。

DNS 是规划的一部分，而不是另一件事。改写解析器配置的 sidecar 可能破坏集群内部的服务发现，同时让外部查询完全正常。

启动与失败是显式状态

sidecar 进程在运行不等于出口策略。先决定隧道就绪前允许哪些流量通过，以及之后它挂掉时会发生什么，再把这套决定实现出来：用探针挡住应用容器、用默认拒绝的网络策略，或两者兼用。缺了其中之一，应用就会在隧道仍在连接时启动、解析并把流量从节点的正常路径送出去。

健康集群里这段间隙很短，故障集群里则是永久的；而这正是攻击者或意外数据泄露最偏爱的性质。

把顺序与故障测试配对。杀掉 sidecar，确认应用失去预期出口，而不是悄悄回退。

权限、策略与从应用容器内测试

授予创建接口、改动路由所需的权限是一项特权决定；适合隔离 Pod 的特权，并不会自动适合节点栈。使用集群支持的网络与安全策略机制，也不要假设每种 CNI 或策略实现都以相同方式对待 VPN 接口；差异恰恰会出现在你在意的失败情形里。

从真实的应用容器出发测试，向私有目标、集群服务和公网发出新请求。从 sidecar 里测试只能证明隧道可用，不能证明应用能到达它需要的地方。

把集群网络假设与 VPN 配置写在一起。这样把工作负载迁到另一个集群就成了核对路由规划的工作，而不是一次悄悄失效的镜像变更。