选择Code发布模型的Linux Web App为何仍以容器运行？含Kudu访问问题

为什么Code发布模型下应用仍以容器运行？ #

Azure App Service的Linux环境，所有Web App本质上都是基于容器运行的，不管你选择的是Code还是Container发布模型。区别只在于容器的管理方：
当你选择Code模型+预定义运行时（比如.NET Core 6.0），平台会自动使用官方维护的.NET Core容器镜像，将你部署的代码/发布包注入到这个镜像中启动运行，整个容器的生命周期、运行时更新都由Azure平台负责，你无需手动构建或管理镜像。

Code与Container发布模型的核心区别 #

• Code模型
  • 平台提供预构建的官方运行时容器镜像，无需自己维护镜像
  • 只需上传代码、发布包或通过Git/CI/CD部署，平台自动处理构建（如需要）和部署到容器
  • 运行时更新、容器补丁由Azure负责，省心省力
  • 适合常规应用快速部署，无需自定义运行环境的场景
• Container模型
  • 必须自行提供自定义容器镜像（可存储在Docker Hub、Azure容器注册表等）
  • 完全控制镜像内容，包括运行时版本、系统依赖、环境变量、启动命令等
  • 镜像的构建、更新、维护由你自己负责
  • 适合需要高度自定义运行环境、多服务打包、镜像标准化的场景

Kudu访问超时（ERR_TIMED_OUT）的原因及解决方向 #

F1是免费规格，资源配额有限，大概率是资源不足导致的：

• 免费层CPU、内存限制严格，若应用占用过多资源，会导致Kudu（高级管理工具）无法分配到足够资源启动或响应
• 免费层的Kudu访问存在一定的速率限制或网络优先级限制

建议尝试以下操作：

• 重启Web App，释放当前占用的资源
• 临时升级到B1等基础付费规格，测试Kudu是否能正常访问（验证是否是资源问题）
• 检查应用日志，排查是否有内存泄漏、CPU持续高占用的情况，优化应用资源消耗

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