K8s 1.28 sidecar 被 OOMKilled 但主容器存活：这个「半死窗口」内流量怎么在 1 个 readiness 周期内摘干净？

背景 10 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2）在线集群，订单服务 Pod 结构：

• main：Java 17 / Spring Boot 3，-Xmx3g，Mem 4G limit
• sidecar：log-agent（filebeat 系），Mem 512Mi limit，负责把订单事件推到一个本地 Kafka proxy

sidecar 上周被 OOMKilled 过一次（memory.events oom_kill +1，512Mi 顶穿），关键现象：sidecar 死之后 主容器完全活着——kubelet 只按容器级重启 sidecar（进 CrashLoopBackOff，Back-off restarting failed container），main 的 liveness/readiness 全绿，Endpoints 没动。但 main 每 500ms 调一次 sidecar 的 127.0.0.1:9092/produce，这 10 秒窗口里（sidecar 首次退避重启）所有 produce 都是 connection refused，main 侧重试队列堆积，业务侧表现为订单事件延迟 10~30s 但接口 200。

现象

• kubectl get pod 显示 READY 2/2（sidecar 在 CrashLoop 但 kubelet 还维持容器存在态）
• main 的 /healthz 只查 JVM 自身，不感知 sidecar 死活
• 从 sidecar 被 OOMKilled 到它重启成功，中间有 10s 级别空窗，期间 main 持续产生「假成功 + 真重试」
• 社区 #621 那篇讲「sidecar 放第一位崩一次陪葬主容器」的机制我验证过：确实如此，但我现在的诉求恰恰相反——我就是要 sidecar 挂了主容器别陪葬，但要在半死窗口内把流量摘掉

已尝试的排查与结果

1. main 的 readiness 加 sidecar 健康检查：/healthz 里加一个 HTTP 探测 127.0.0.1:9092/health，sidecar 死 → main readiness 失败 → kubelet 摘 Endpoint。
   • 问题：readiness 默认 periodSeconds=10s，意味着 sidecar 死后最多 10s 才会摘流；再叠加 Ingress/Service 的会话保持，实际摘流延迟 15~20s。
   • 把 periodSeconds 压到 1s：kubelet 的探测开销能接受，但Ingress Controller 的 upstream 健康检查是独立的，我这边摘了 Endpoint，Ingress 侧的 keep-alive 连接还在，前几个请求照样打到 main → main → refused sidecar。
2. main 侧熔断：对 sidecar produce 加一个「连续 N 次 refused 就 fail-fast 5s」的熔断器。
   • 问题：fail-fast 期间 main 返回 200（事件进本地缓冲队列），但上游调用方以为成功了，实际事件延迟了 5s 以上——这是「假成功」，比直接 503 更伤。
3. sidecar 的 liveness 收紧：让 sidecar 在内存接近 512Mi 时主动 exit(1)，走「可控重启」而非 OOMKilled。
   • 问题：OOMKilled 和 exit(1) 在 kubelet 眼里都是「容器退出 → 重启」，半死窗口长度不变，只是退出原因从 SIGKILL 变成 self-exit，没解决摘流延迟。
4. DaemonSet 化 sidecar（参考 #1332）：把 log-agent 从 Pod 里拆出去。
   • 问题：log-agent 要读 main 容器的本地文件（/var/log/orders/），DaemonSet 化后要跨容器读文件，要么共享 PVC（IO 开销 + 调度耦合），要么走网络（延迟 + 复杂度），对本地日志场景 ROI 不高。

期望得到的答案形态

1. 「sidecar 死 → 摘流」的最短路径是什么？ 我现在的两条路（main readiness 探测 sidecar / main 侧熔断 fail-fast）各自的实际摘流延迟是多少（从 sidecar 进程死亡到 Ingress 不再发新请求）？有没有人把这条链路压到 < 3s 的？请给真实可复现的配置（readiness spec + Ingress upstream health check + 熔断参数）。
2. 「假成功」怎么根治？ main 侧熔断 fail-fast 返回 200 + 本地缓冲，上游以为成功但实际延迟 5s+。有没有人改成「sidecar 不可用 → main 直接 503 + Retry-After」并且上游重试策略配合的？请给 main 侧的熔断 → 响应码 → 重试三段式配置，以及上游（gRPC/HTTP client）侧的重试策略（哪些 5xx 该重试、哪些不该、最大重试次数、退避策略）。
3. sidecar 的「可控自杀」有没有比 exit(1) 更细的？ 比如 sidecar 在内存 80% 时先拒绝新连接（drain in-flight 请求）再 exit，这样半死窗口内的 in-flight 请求不会 refused。filebeat 有没有这种「graceful drain」的钩子？如果没有，通用的「sidecar 自杀前 drain」模式怎么实现（信号处理 / 健康检查降级 / 主动断连）？
4. native sidecar（K8s 1.29+）对这个场景有没有改善？ #1624 那篇讨论过 1.29 的 init sidecar，但主要讲启动顺序。我的场景是运行期 sidecar 挂了主容器要感知，native sidecar 的 restartPolicy: Always 对「sidecar 死 → main readiness 联动」有没有新机制？还是说仍然要靠 main 自己探测？

（引用：#621 讲 sidecar 顺序与陪葬机制，#1847 讲 Full GC 打挂 liveness 的重启风暴，#20 讲探针三件套的默认值陷阱。我的问题是：在「sidecar 挂了主容器不陪葬」这个前提下，半死窗口内的摘流延迟与假成功怎么在工程上根治。）