K8s Pod 安全加固（seccomp + capabilities drop ALL）后 core dump 被禁，线上 OOM 排查如何保留最小调试能力？

【背景】 我负责一套 6 节点自建 K8s 1.28（containerd 1.7）集群，跑 14 个 Go + 3 个 Java 17 微服务。安全基线要求所有 Pod 满足：

• runAsNonRoot: true
• allowPrivilegeEscalation: false
• capabilities.drop: ["ALL"]
• seccompProfile.type: RuntimeDefault
• readOnlyRootFilesystem: true

这套基线本身没问题，上线后也稳定跑了 3 周。

【现象】 第 4 周，Java 服务（Spring Boot 3.2，堆 2G）出现一次 OOMKilled（Pod 被 kernel OOM killer 杀掉），事后想抓 core dump 做堆分析，发现：

1. 容器内 ulimit -c 为 0（seccomp + capabilities drop ALL 把 core 信号处理链打断了）；
2. 即使手动 ulimit -c unlimited，/proc/sys/kernel/core_pattern 指向的是 |/usr/bin/systemd-coredump，而容器内没有 systemd；
3. 把 core_pattern 改成管道写文件后，readOnlyRootFilesystem: true 又导致写不了 /tmp/core。

结果：一次 OOM 事件，没有任何现场数据，只能靠 GC log 和 heap dump（但 heap dump 也写不出来）盲猜根因。

【已尝试的排查与结果】

• 方案 A：加 privileged: true → 安全团队直接否决，基线不允许。
• 方案 B：给 Java Pod 单独开 capabilities.add: ["SYS_PTRACE"] → 能 gcore 了，但安全审计认为 SYS_PTRACE 攻击面太大（可被用来 attach 其他进程），也拒了。
• 方案 C：把 readOnlyRootFilesystem 改成 false，只 mount 一个 /tmp emptyDir → 能写文件了，但 seccomp 仍然拦 core 信号，还是抓不到。
• 方案 D：用 nsenter 从 host 进容器抓 → host 上没装 jattach / jmap，装的话又违反 host 最小化原则。

【期望得到的答案形态】

1. 在不破坏上述安全基线（特别是 seccomp + drop ALL + readOnlyRootFilesystem）的前提下，有没有一套可复现的配置组合，能让 core dump / heap dump 落到一个 emptyDir 里？
2. 如果 seccomp 是硬约束，那 Go 服务的 panic 现场（goroutine dump）和 Java 的 hs_err_pid 分别有什么替代采集手段？
3. 有没有"安全团队能签字通过"的最小权限集（比如只 add SYS_PTRACE 且限定到特定进程）？有没有实际在生产的案例？
4. 如果以上都不行，大家在实际项目里是怎么平衡"安全基线"和"线上可调试性"的？有没有折中方案（比如只保留一个"debug sidecar"特权容器）？

希望得到具体配置片段 + 踩坑记录，纯理论讨论就免了。