Azure Kubernetes容器中.NET 6应用依赖.exe文件的存储位置咨询

方案一：将.exe纳入Docker镜像 #

优势 #

• 零额外流量成本：exe随镜像拉取到容器本地，每次调用直接读取本地磁盘，完全规避Azure File Share的流量开销。
• 部署与运维简单：和应用代码打包为一体，K8s部署时无需额外配置存储卷挂载，减少运维环节。
• 版本一致性强：每个Pod使用的exe版本与镜像绑定，不会出现版本不一致的问题，版本管控清晰。
• 性能更优：本地磁盘IO远快于远程文件共享，能降低exe启动时的延迟，适配每日1万次调用的吞吐量需求。

劣势 #

• 镜像体积略有增加：在原有.NET 6镜像基础上增加约90MB，但因每年仅更新2-3次，镜像构建、推送的成本可忽略。
• 需处理容器内临时文件：需在容器内生成随机临时目录（如Linux容器的/tmp/$(uuidgen)，Windows容器的C:\Temp\随机字符串），处理完成后删除。不过该逻辑易实现，且容器临时目录在Pod销毁时会自动清理，即使漏删也无长期影响。

方案二：将.exe存储于Azure File Share #

优势 #

• 镜像体积更小：无需打包exe，镜像保持原有大小，拉取速度略有提升，但90MB的增量对拉取速度影响极小。
• exe更新无需重构镜像：直接替换File Share中的exe即可完成更新，但因更新频率极低，该优势不突出。

劣势 #

• 流量成本累积：每次调用exe都需从File Share读取（Pod重启或调度到新节点时需重新加载），每日1万次调用会产生可观的出站流量费用，长期成本不可忽视。
• 性能损耗明显：远程文件共享的IO延迟会拉长exe启动时间，对于部分1-2分钟的调用场景，会降低整体处理效率。
• 运维复杂度高：需在AKS中配置PersistentVolume、PersistentVolumeClaim，挂载File Share到Pod，还要处理容器内的文件权限问题，增加部署与维护的工作量。

最终建议 #

优先选择方案一（将.exe纳入Docker镜像），理由如下：

1. 每年仅2-3次的更新频率，镜像重构与推送的成本极低，完全可接受。
2. 彻底避免了Azure File Share的流量成本与性能损耗，更适配每日高调用量的场景。
3. 部署流程更简洁，版本一致性有保障，减少运维风险。

临时文件处理补充建议 #

在容器内使用系统默认临时目录创建随机文件夹，示例代码逻辑：

var tempDir = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString());
Directory.CreateDirectory(tempDir);
// 调用exe生成文件
// 上传Blob至存储
Directory.Delete(tempDir, recursive: true);

这类临时目录属于容器的 ephemeral storage，Pod销毁时会自动清理，即使代码漏删文件也不会占用持久化资源，契合临时数据的需求。

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