咨询：在AWS EKS容器化.NET应用中使用dump工具生成内存Dump

一、工具适配性对比 #

• createdump：属于.NET Runtime自带工具，无需额外安装，适配Alpine这类轻量镜像。Alpine采用musl libc，.NET 5及后续版本对其兼容性良好，3.14版本的Alpine完全支持。优势是不增加镜像体积，适合资源受限的容器环境。
• dotnet-dump：需要安装对应版本的dotnet-sdk，会增大镜像体积，但操作更灵活，支持交互式分析dump文件，适合需要在容器内快速初步排查的场景。在Alpine上安装时需确保配置正确的软件源，避免包拉取失败。

二、实操步骤 #

使用createdump生成dump #

1. 进入目标容器：

   kubectl exec -it <pod名称> -c <容器名称> -- sh
   

2. 查找.NET进程ID：

   ps aux | grep dotnet
   

3. 生成内存dump（-u生成小型dump，-n生成完整dump）：

   createdump -u <进程ID>
   

4. 将dump文件导出到本地：

   kubectl cp <pod名称>:/<dump文件路径> ./本地存储路径.dmp
   

使用dotnet-dump生成dump #

1. 提前在Dockerfile中添加SDK安装步骤（替换为你的.NET版本）：

   RUN apk add --no-cache dotnet-sdk-6.0
   

2. 进入容器后执行dump收集：

   dotnet dump collect -p <进程ID>
   

3. 同样通过kubectl cp命令将dump文件导出到本地分析。

三、关键注意事项 #

• 若createdump执行失败，优先检查.NET版本是否为5及以上，旧版本对musl libc的兼容性不足。
• 内存dump文件体积可能接近进程占用内存大小，需确保容器所在节点或挂载的可写存储（如emptyDir、PVC）有足够剩余空间。
• 若容器采用只读文件系统，需指定dump文件输出到可写挂载目录，否则会生成失败。
• 生产环境中，建议仅在排查问题时临时使用dotnet-dump，不要将SDK打包进生产镜像，以减少攻击面和镜像体积。

内容的提问来源于stack exchange，提问作者Satyam Pandey