K8s 1.28 native sidecar 的优雅退出顺序到底和老式 sidecar 差在哪？

背景 我在一个 12 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2）的在线业务集群里，日志采集一直用老式 sidecar 模式——主容器跑业务，sidecar 容器跑 filebeat 采集本地日志。最近想升级到 K8s 1.28 的 native sidecar（initContainers + restartPolicy: Always），核心诉求是让 sidecar 的退出顺序可控、不再丢日志尾部。

现象 / 卡点 老式 sidecar 模式下，Pod 收到 SIGTERM 后，主容器和 sidecar 容器是同时收到终止信号的。如果主容器（业务进程）响应 SIGTERM 后 2 秒就退出了，filebeat 可能还没来得及把最后几秒的日志 flush 完就被 SIGKILL，日志尾部丢失。我们现在的 workaround 是在 filebeat 的 preStop hook 里 sleep 5，本质上是"赌"主容器退出得比 sidecar 慢，不够稳，而且每次调参都在赌。

已尝试的排查与结果

1. 查了 K8s 1.28 native sidecar 的官方文档（KEP-753），文档说 native sidecar 会在所有普通容器退出后才开始终止，但我没找到具体时序图或"谁先收到 SIGTERM、谁先被 SIGKILL、terminationGracePeriodSeconds 怎么分配给各容器"的详细说明；
2. 试了把 filebeat 改成 native sidecar 写法，但发现 filebeat 的 shutdown 信号处理和老式 sidecar 不完全一样（它默认是 SIGTERM → 等 flush → 退出），不确定在 native sidecar 模式下是否真的会"等所有普通容器退完"才收到 SIGTERM；
3. 在 GitHub K8s issues 里搜了 native sidecar termination order，找到几个讨论但都没有给出 containerd 1.7.x 下的实测结论；
4. 没找到一篇把"老式 sidecar vs native sidecar 在优雅退出顺序上的差异"讲清楚的实战文章，大部分文章只讲"怎么配"，不讲"配完之后退出到底谁先谁后"。

期望得到的答案形态

1. K8s 1.28 native sidecar 的优雅退出确切时序是什么？（谁先收到 SIGTERM → 谁先被 SIGKILL → terminationGracePeriodSeconds 是"所有容器共享"还是"每容器独立"？）最好有可复现的验证方法（比如用 kubectl debug 或 crictl 抓信号时序）；
2. 老式 sidecar 模式下，有没有比 preStop sleep N 更稳的"保证 sidecar 最后退出"的写法？（比如用 initContainer 的某种 trick、或者用 K8s 1.28 的 native sidecar 但需要改 filebeat 的 shutdown_timeout 配置？）
3. 如果最后发现 native sidecar 的退出顺序依赖容器运行时（containerd vs CRI-O）的实现细节，那 containerd 1.7.13 下有没有已知的 bug、限制或 workaround？

我会把你们给的结论和验证方法整理成一篇"sidecar 优雅退出对账"笔记，方便后来人直接抄。