容器镜像"能调试"和"够安全"到底能不能兼得？聊聊你的取舍

【背景】 我做了 5 年嵌入式，近两年主力在容器化和 K8s 运维。最近帮两个团队做镜像安全加固，被问得最多的一句话就是："线上出了 segfault / 内存越界，镜像里连 gdb 都没有，怎么查？"

热榜上有探针、OOM、资源声明的讨论，但镜像本身的可调试性这个话题，社区反而很少认真拆开聊。我把它当成一个"安全 vs 可运维性"的经典冲突来抛出来。

【常见分歧与几种做法】

1. 一套镜像通吃派：Dockerfile 里带着 gdb、strace、vim、curl、tcpdump，开发测试生产全用同一份。优点是排障方便、构建简单；缺点是攻击面大、镜像体积轻松 1–2 GB，安全团队不签字。
2. 严格分离派：开发镜像（带工具链）和生产镜像（distroless / scratch / alpine + 非 root + 只读根）完全分开，两套 Dockerfile 或 multi-stage build。安全合规，但出了线上问题，你只能 kubectl cp 一个 gdb 进去——或者根本进不去（scratch 连 shell 都没有）。
3. debug sidecar 派：主容器保持最小化，另起一个 debug sidecar（带全套工具），需要时 kubectl exec 进 sidecar，用 nsenter 或共享 PID namespace 进主容器排障。架构上优雅，但多一个容器要维护、要调度、要管资源，不是每个团队都愿意。
4. coredump 兜底派：镜像不装工具，但配好 kernel.core_pattern + 外部 coredump 接收端（S3 / NFS / 对象存储），事后用带符号表的工具链离线 gdb 分析。嵌入式场景下这是最实际的，但 K8s 多租户环境下 core_pattern 是节点级全局配置，多个服务互相踩。
5. eBPF 无侵入派：不装任何工具，靠 bpftrace / parca / Pixie 从节点侧观测，容器保持纯净。趋势很好，但对 segfault、use-after-free 这类硬崩溃，eBPF 只能告诉你"它死了"，不能告诉你"为什么死"。

【我的倾向与理由】 我倾向 严格分离 + coredump 兜底 的组合：C/C++ 服务用 distroless，Go 服务用 scratch，同时把 coredump 链路做通——节点侧 kernel.core_pattern 指向一个 DaemonSet coredump agent，core 文件落到对象存储，事后用带 -g 符号表的工具链离线分析。

理由有三：

• 安全加固（非 root、只读根、最小攻击面）是硬约束，不能因为"排障方便"就放松，尤其多租户共享集群；
• 嵌入式和 C/C++ 服务的崩溃，符号表 + core 文件的离线分析效率，往往高于"在线 gdb attach"——因为在线环境内存状态可能已被后续写入破坏，core 文件是崩溃瞬间的快照，信息更完整；
• 对 Go / Rust 这类有 runtime 的语言，pprof / panic trace 已覆盖 80% 的排障需求，不需要在镜像里塞工具。

但我也承认，这套方案在小团队 / 小集群（2–3 个服务、1–2 个节点）里成本偏高，一套镜像通吃可能更务实。安全投入要和团队规模匹配。

【想听大家怎么选】 想请教各位在以下场景下的取舍：

• 你们的 C/C++ 服务在 K8s 里出了 segfault，实际走的是什么排障路径？coredump 离线分析？还是 kubectl exec 直接进容器 attach？
• distroless / scratch 你们用了多少比例？遇到"没有 shell 进不去"的真实卡点有哪些，怎么绕的？
• debug sidecar + 共享 PID namespace 这套，有没有人真的在生产环境长期跑过？维护成本、调度开销如何？
• 嵌入式 / 边缘场景（ARM 交叉编译、几百 MB 内存上限），你们怎么兼顾"镜像要小"和"出了 bug 能查"？
• 有没有人用 parca / Pixie 替代传统 profiling 工具？对 C/C++ 服务的效果到底怎么样，能替代 gdb 吗？
• 符号表怎么管？你们是把 debug info 单独拆一个镜像 / 文件，还是用 objcopy --only-keep-debug + gdbaddrs 的方案？

欢迎贴你的 Dockerfile 片段、coredump 配置、或者踩坑记录，越具体越好。