VPN 边车需要启动规则和失败规则

Pod 会在应用之前启动隧道容器，最初的请求成功，而这正是掩盖问题的情形。顺序只修复了一次竞争，对应用在四小时后、隧道失效之后才开始产生的流量只字未提。这是两个彼此独立的决定，通常只有其中一个被设计过。

顺序只拦住第一个请求

Kubernetes 支持由可重启的 init 容器构成的 sidecar 生命周期。在该模型中，启动探针可以阻止下一步初始化，直到隧道报告就绪。这是真正的改进，值得有意识地使用，而不是在入口脚本里加一个 sleep。这道门的好坏取决于它所检验的条件。

在该模型之外，顺序语义属于你所使用的运行时或依赖系统，二者不必一致。从其他平台照搬的部署可能看起来在等待隧道，其实只是应用恰好启动较慢。那不是同一种保证，而且在高负载下会失效。

说清楚这道门到底观察什么：进程存在、网卡存在、握手完成。每一条都比“本 Pod 所需目的地的数据通路可用”更弱。

探针是对某一时刻的检查，而防火墙是在时刻之间持续成立的属性。如果要求是应用流量绝不离开隧道，就必须在共享网络命名空间里以放行或丢弃的规则表达出来。容器启动顺序承载不了这个要求，只有规则可以。

同一个 Pod 中的容器共享该命名空间，因此执行点就是命名空间本身。无论你写什么，都必须保留隧道自身外部连接的可用性，因为为了“保护”应用而封掉它，等于切断了应用需要的通路。

明确决定失败策略：隧道不健康时，应用流量应当完全停止，还是继续通行并被标记为未受保护？两者都说得通，而二者都不是靠按某种顺序启动容器能得到的。

在受控的隧道故障期间发一个新请求，看看它是否会出去。然后对出口地址测试永远碰不到的路径重复检查：集群内的 DNS 解析、IPv6 目的地，以及通过集群内部地址而不是公网访问的服务。隧道死掉之后悄悄继续工作的正是这些路径。

出口地址页面只能证明某一时刻某一个请求去了你预期的位置。它无法盘点其余路径，而“你测过的”与“Pod 能到达的”之间的缺口，正是有趣故障的所在。

不只在干净启动之后测试，也要在 sidecar 重启之后测试。重启过的隧道容器可能让命名空间里的路由和策略停留在中间状态。

部署笔记里应有三件事：就绪测试及其观察内容、该测试失败时的恢复动作，以及管住出站的执行规则。sidecar 容器文档讲清了生命周期机制，却把这项策略决定留给你。这种分工是正确的，也正是策略经常缺失的原因。

被误当作保护的健康检查，是最昂贵的一种绿色指示灯，因为它让人不再提问。在文档里准确命名它只需一句话，却能避免这一点。

最后，在应用运行的状态下测一次恢复路径。需要重建 Pod 才能恢复出站的设计是一个决定，而且应当是你主动做的决定，而不是事后发现的决定。