为何部署在AKS的dotnet应用对应的Deployment仅部分Pod启动成功

System.IO.FileNotFoundException: Could not load file or assembly ...

• 节点架构不匹配
  若AKS集群同时存在x86、ARM等不同CPU架构的节点，而构建的容器镜像仅支持单一架构，调度到非匹配架构节点上的Pod会因程序集架构不兼容，抛出文件加载失败的异常。已成功运行的Pod实际是调度到了匹配架构的节点。
• 存储卷挂载覆盖了应用目录
  若Deployment配置中将PVC、ConfigMap、Secret或emptyDir挂载到了应用程序集所在的目录（比如默认的/app路径），会覆盖镜像中原有的程序集文件。如果使用的是ReadWriteOnce模式的PVC，仅首个调度到对应可用区节点的Pod可正常挂载，其余Pod会因挂载空目录/挂载失败出现程序集缺失。
• 节点运行时配置存在差异
  部分节点可能配置了自定义安全策略（AppArmor、Seccomp），限制了dotnet运行时对程序集目录的读取权限；或是节点的容器运行时预配置了异常的环境变量，覆盖了DOTNET_ROOT、DOTNET_ASSEMBLY_PROBING_PATHS等 dotnet 程序集搜索路径相关的参数，导致运行时无法定位到已存在的程序集。
• 镜像版本与拉取策略不匹配
  若镜像使用latest这类可覆盖的标签，且拉取策略配置为IfNotPresent，部分节点上可能缓存了存在程序集缺失问题的旧版本镜像，Pod调度到这类节点时会复用旧镜像启动失败，新节点拉取的是最新正常镜像可以正常运行。
• 新旧版本ReplicaSet共存
  若Deployment正在进行滚动更新，或上一次发布未正常完成，集群中会同时存在新旧两个版本的ReplicaSet，旧版本使用的镜像存在程序集缺失问题，新版本镜像正常，就会出现部分Pod运行正常、部分启动失败的现象。
• 单文件发布依赖的临时目录异常
  若dotnet应用采用单文件模式发布，程序启动时会将依赖程序集解压到容器的/tmp目录下。如果部分节点对容器的/tmp目录配置了容量限制、权限限制，或是挂载了异常的存储介质作为临时目录，会导致依赖解压失败，抛出程序集找不到的异常。
• 节点系统依赖版本不兼容
  若集群中存在不同操作系统版本的节点，部分低版本节点缺少dotnet运行时依赖的系统库（如对应版本的glibc、libssl等），加载依赖时抛出的异常会被包装为FileNotFoundException，容易被误认为是应用程序集缺失。

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