sidecar（Envoy）内存失控时，怎么在「拖垮主容器/节点」之前拦住它：预算护栏 + 隔离 + 自动处置的工程方案有没有可复现的？

先说背景，免得各说各话。我见过太多「主容器全绿、sidecar 先炸」的事故，社区里 sidecar 的「观测与预算」（#1403 聊过堆全绿仍 OOMKilled）、sidecar 抢资源治理（#1332 讲过 requests/limits 按容器独立核算但节点调度看之和）、节点驱逐排序（#473 讲过 Burstable 排到队首）都讨论得不少。但有一个更靠后的环节我一直没找到标准答案——当 sidecar 真的开始失控（内存泄漏 / 连接表暴涨 / 规则爆炸）时，怎么在它拖垮主容器或整个节点之前，用一套可复现的「护栏 + 隔离 + 自动处置」把它摁住？

背景

我们 K8s 1.28 + Istio（Envoy 1.23），一批 Java 17 订单服务，Pod 双容器：主容器 request=2C/4G、limit=2C/4G；sidecar（istio-proxy）request=100m/128Mi、limit=500m/512Mi。稳态 sidecar 内存 180–260Mi，但没有任何针对 sidecar 的自动处置——它只是「一个 limit 卡着上限的容器」。

现象（三种失控形态都踩过）

• 内存缓涨：一次 mTLS 证书轮换后，Envoy 的 cluster_manager 连接表没回收，内存 4h 从 200Mi 爬到 512Mi 触 limit，内核 cgroup OOM 直接 kill 掉 sidecar。Istio 自动重建了 sidecar，但重建那 8s 里主容器的所有出向流量被切断，P99 飙到 3s。更糟的是这台节点同时还有 5 个 Pod，sidecar 反复 OOM 重建时节点内存压力把同节点的 Burstable 主容器一起拖进了驱逐队列（正好印证 #473 的排序）。
• CPU 尖峰：一次 Envoy 规则热加载（新增 3000 条 vhost）瞬间 CPU 打满，和主容器抢 2C，主容器 GC 停顿放大。
• 静默占满：sidecar 没被 OOM，但长期贴着 512Mi 跑，节点水位被抬到驱逐阈值附近，整台节点的「可用余量」被一个 sidecar 吃掉。

已尝试过的排查与结果

• 给 sidecar 设 limit=512Mi 卡上限 → 治标：要么 OOM 重建（断流 8s），要么贴着上限跑抬节点水位，两种都不可接受。
• 想给 sidecar 加「内存超过某值就主动重启」的自愈 → 但 istio-proxy 没有内置的「自杀阈值」，只能靠外部 agent 或 Envoy 的 health_check / 管理端口，没找到现成开关。
• 想过把 sidecar 从 Pod 里拆出去（独立代理 / DaemonSet），但服务网格的 sidecar 模式在 mesh 里是「必须 co-located」的，拆出去要改架构，成本高。
• 查过 Envoy 的 memory_accounting、max_connections、runtime 值，能限连接数但限不住「规则/连接表」这类结构性泄漏。

期望得到的答案形态

希望有同学给一套可复现的方案，我关心的是：

1. 护栏（预算）：sidecar 的 limit 到底按什么公式定（稳态用量 × 安全系数？还是按连接数 × 每连接内存）？怎么从「拍脑袋 512Mi」变成「可推导」？
2. 隔离：怎么让 sidecar 的失控只影响它自己，不拖节点、不拖同 Pod 主容器？cgroup v2 的 memory.max + memory.high（soft limit 触发回收而非 OOM）怎么配才既兜底又不「一刀切 OOM」？有没有用 cpuset / 独立 cgroup 把 sidecar 和主容器真正隔开 CPU 的做法？
3. 自动处置：sidecar 内存超阈时，怎么做到「优雅重启不切断在途流量」——Istio 有没有 drain 机制？还是得自己写 agent 监控 envoy_admin /stats 的内存，超阈主动 kill -SIGTERM 让 Envoy 先 drain 再退？阈值怎么定？
4. 可观测：sidecar 内存的「该看哪个指标」——是 envoy_admin /stats 的 server.memory_allocated、还是 cgroup 的 memory.current、还是 cluster_manager 连接表？三者口径差多少？
5. 终极问题：如果 sidecar 反复 OOM 是「结构性泄漏」（规则/连接表只增不减），除了重启，有没有根治路径（比如拆分规则、升级 Envoy、或迁到 ambient 模式把 sidecar 变 DaemonSet）？

一句话：sidecar 是「寄生在主容器 Pod 里的另一个进程」，它的失控不该由主容器或节点来买单。想听听大家怎么给它套上「预算 + 隔离 + 自动处置」这套缰绳。