寻求从Azure Web Apps迁移至Azure Kubernetes Service的经验分享

一、前期配置梳理（避免遗漏关键项） #

• 导出Web Apps全量配置：
  • 应用设置：执行az webapp config appsettings list --name <webapp-name> --resource-group <rg-name>
  • 站点核心配置：执行az webapp config show --name <webapp-name> --resource-group <rg-name>（含运行时版本、端口、环境变量规则等）
  • 连接字符串：执行az webapp config connection-string list --name <webapp-name> --resource-group <rg-name>
  • 把导出内容整理成清单，标记**敏感信息（如连接字符串）**后续要存入AKS Secret，普通配置存入ConfigMap
• 匹配运行时依赖：确认Web Apps的运行时版本（如.NET 6、Node.js 18），后续容器镜像要使用对应基础镜像

二、容器化后端服务 #

• 编写Dockerfile：根据运行时选择官方基础镜像（比如mcr.microsoft.com/dotnet/aspnet:6.0），复制服务代码到镜像，设置正确的启动命令（如dotnet YourService.dll）
• 本地验证容器：构建镜像后本地运行，模拟Web Apps的配置环境，验证服务启动、接口调用是否正常
• 推送镜像到Azure Container Registry（ACR）：创建ACR后，用az acr build --registry <acr-name> --image <service-name>:v1 .一键构建并推送镜像

三、AKS集群部署与配置迁移 #

• 关联AKS与ACR：如果已有AKS集群，执行az aks update --name <aks-name> --resource-group <rg-name> --attach-acr <acr-name>，让集群能拉取ACR镜像
• 编写K8s资源文件：
  • Deployment.yaml：指定ACR镜像地址，配置环境变量（引用ConfigMap/Secret），设置资源配额（参考Web Apps实例规格，比如B1实例对应0.5vCPU、1GB内存）
  • Service.yaml：根据访问需求选择类型（ClusterIP用于内部访问，LoadBalancer/Ingress用于对外暴露）
• 迁移配置到AKS：
  • 创建ConfigMap：kubectl create configmap app-settings --from-literal=SETTING_KEY=VALUE
  • 创建Secret：kubectl create secret generic app-secrets --from-literal=CONN_STRING=VALUE
  • 部署应用：kubectl apply -f deployment.yaml && kubectl apply -f service.yaml
• 验证部署：用kubectl get pods查看状态，kubectl logs <pod-name>排查日志，确认服务正常运行

四、流量割接与收尾 #

• 功能验证：调用AKS中服务的接口，对比Web Apps的功能表现，确保配置、依赖、业务逻辑完全一致
• 平滑割接：用Azure流量管理器逐步将流量从Web Apps切换到AKS服务，期间监控服务状态
• 清理旧资源：确认AKS服务稳定运行后，再删除Web Apps相关资源

关于Azure Migrate的说明 #

Azure Migrate主要针对虚拟机、物理机迁移，不支持Azure Web Apps的直接识别与迁移，上述手动迁移流程是当前最可靠的方案，核心在于提前梳理全量配置+容器化本地验证，能有效降低操作失误风险。

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