如何将自定义DLL加载至正在运行的AKS Pod中

你目前调研的两种实现方案都可满足基本需求，但存在明确的架构短板：

• Blob存储运行时拉取方案：强依赖外部存储服务可用性，存储服务抖动、鉴权配置异常都会直接导致新扩容Pod启动失败；多租户场景下需要额外设计复杂的路径鉴权规则，稍有疏漏就会出现跨客户DLL泄露问题；Pod冷启动需要走网络链路拉取DLL，启动速度受网络质量影响大；客户上传错误版本DLL会直接触发线上故障，回滚链路长。
• 应用与DLL打包为单一镜像方案：核心主程序与客户DLL版本强耦合，任意客户更新DLL都需要重新构建、推送整个数百MB级别的应用镜像，CI/CD链路冗余度极高；多客户场景下镜像数量会随客户规模线性增长，给镜像仓库存储、节点镜像缓存带来不必要的压力；核心应用推送安全补丁、版本升级时，需要为所有客户重新构建对应镜像，发版效率极低。

行业通用部署架构方案（仅涉及部署层设计，不含代码实现细节） #

以下方案均为云原生领域处理「主程序+第三方定制插件」场景的成熟标准模式，按普适性优先级排序：

1. Sidecar初始化容器+共享卷方案（优先推荐，CNCF生态事实标准） #

这是绝大多数同类场景的首选方案，核心逻辑是完全解耦主应用与客户DLL的发布链路，依托K8s原生能力实现依赖注入：

• 核心.NET Core应用单独维护基础镜像，不绑定任何客户自定义DLL，独立完成版本迭代、漏洞修复、镜像推送
• 每个客户的自定义DLL单独构建为极简只读镜像，镜像内仅存放对应版本的合规DLL文件，不需要携带任何运行时依赖，单镜像体积通常仅KB到MB级别
• 部署对应客户的业务负载时做三项原生配置：
  • 挂载一个生命周期与Pod一致的emptyDir类型共享卷
  • 注入一个initContainer初始化容器，使用对应客户的DLL镜像启动，启动后仅执行一个动作：将镜像内的DLL拷贝到共享卷的指定目录，执行完成后自动退出
  • 主应用容器将同一个共享卷挂载到自身的DLL读取目录，启动时直接读取本地卷内的DLL文件即可
    该方案的核心优势：
• 发布链路完全解耦：主应用迭代不需要涉及任何客户DLL的调整，客户更新DLL仅需要重新构建自身的轻量DLL镜像，触发对应负载的滚动更新即可，不需要改动主应用镜像
• 无运行时外部依赖：Pod启动所需的所有依赖都通过镜像仓库分发，不依赖Blob等外部存储服务，启动稳定性与普通无状态应用完全一致
• 多租户隔离天然生效：哪个客户的负载就配置哪个客户的DLL初始化容器，不存在跨客户DLL泄露的风险
• 版本管控能力完善：DLL镜像通过标签标记版本，回滚时仅需要将负载中初始化容器的镜像版本切换为历史版本即可，不需要额外的构建操作
• 完全兼容AKS原生能力：适配AKS的镜像缓存、拉取鉴权、滚动更新、故障自愈等所有原生特性，不需要额外开发运维组件

2. 持久化卷只读挂载方案（适合DLL高频更新场景） #

如果客户DLL更新频率极高，且要求DLL更新过程不触发Pod重启，可以选择该方案：

• 按客户维度划分Azure Files/Azure Disk持久化卷的目录，预先将对应版本的客户DLL上传到对应目录，所有目录配置只读权限
• 部署主应用时，将对应客户的持久化卷目录以只读模式挂载到主应用的DLL读取目录，主应用直接读取本地挂载点的文件即可
  该方案优势是更新DLL仅需要替换持久化卷内的文件，不需要重启Pod、不需要重新构建镜像；缺点是需要额外建设持久化卷的权限管控、备份、版本快照能力，整体运维复杂度高于Sidecar方案。

3. 定制逻辑独立服务托管方案（适合高隔离要求场景） #

如果客户的定制逻辑复杂度高、资源消耗大，对故障隔离、资源隔离有强要求，可以选择该方案：

• 不将客户DLL加载到主应用进程内，而是将每个客户的定制逻辑单独部署为独立服务，为每个服务单独配置CPU/内存配额、限流规则、故障熔断策略
• 主应用与定制逻辑服务之间按照预先约定的固定契约做网络调用，实现进程级别的完全隔离
  该方案优势是定制逻辑出现内存泄漏、崩溃等问题时不会影响主应用稳定性，资源可以独立调度；缺点是存在网络调用开销，整体运维复杂度最高。

选型建议 #

• 90%以上的常规场景优先选择Sidecar初始化容器+共享卷方案，在稳定性、运维复杂度、解耦能力上做到了最优平衡
• 如果客户DLL更新频率高于每周1次，且要求更新过程无业务中断，选择持久化卷只读挂载方案
• 如果客户定制逻辑复杂度高、对主应用稳定性要求极强，选择定制逻辑独立服务托管方案

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