将旧版应用程序迁移到 AKS

本页是一个重点指南，用于评估和将旧版应用程序迁移到Azure Kubernetes 服务 (AKS)。 它涵盖了一个四阶段就绪框架、切实可行的迁移路径（重构、平台迁移、直接迁移）、Windows 和 .NET Framework 的具体注意事项、运维检查，以及一份简明的常见问题解答，用于解答将旧版工作负载迁移到 AKS 时常会遇到的难点问题。

注意：本文负责介绍 AKS 的旧版迁移流程。 它不会重现已在其他位置提供的分步群集预配、CI/CD 或详细的Azure Migrate教程，请参阅 AKS 迁移概述（aks-migration）和Azure Migrate应用容器化教程，了解动手步骤和工具。 在这些页面上添加指向此旧版迁移指南的醒目交叉链接，以便使用旧版 .NET 或 IIS 工作负载的团队能够找到他们所需的单一、明确的入口。

1. 旧版应用程序评估 - 四阶段框架

在迁移任何工作负载之前，请先进行一次严谨的评估。 使用四阶段框架将即席决策转换为可重复的计划。

阶段 1 - 依赖项映射和就绪性评分

目标：发现应用程序在运行时需要的内容并生成容器化准备分数。

  • 运行自动发现工具（例如 Azure Migrate 应用容器化），尽可能生成基线就绪性报告以及建议的 Dockerfile/清单文件。
  • 梳理服务间和外部依赖关系：
    • 下游数据库、消息总线、旧文件共享、SMTP、AD/LDAP、本地 API、硬件设备。
    • 网络要求（静态 IP、VIP、保留端口）。
    • OS 和内核依赖项（Windows API、本机驱动程序、内核模块）。
  • 使用条件为每个服务创建简单的就绪性分数（0-10）：
    • 无状态 （无状态 = 更高的就绪性）。
    • 外部依赖项复杂性（高复杂性 = 较低就绪性）。
    • 机密信息处理（使用进程内机密还是外部机密存储）。
    • Windows 或原生依赖项（会降低对 Linux 容器的就绪性）。
  • 记录在容器化之前必须解决的任何阻塞项，例如：COM+ 组件、硬件加密狗、所需的桌面用户界面。

交付成果：每个服务的依赖关系图、就绪度评分卡，以及按优先级排序的迁移待办事项列表。

阶段 2 — 工作负载分类：重构、重平台化或直接迁移

目标：为每个服务选择正确的迁移路径。

决策指南：

  • 重构（容器化和现代化）：
    • 最适合接口清晰、代码改动较少且没有仅限 Windows 的依赖项的无状态服务。
    • 如果可以迁移到 .NET（Core/.NET 6/7/8）或现代 Java 运行时，则可作为候选方案。
    • 建议的目标：AKS 上的 Linux 节点池;请考虑使用 AKS 自动执行托管操作。
  • Replatform（使用某些体系结构更改或第三方替换进行容器化）：
    • 当服务的外部依赖易于管理时（例如，可迁移到托管数据库、替换为云服务，或通过边车适配器运行），则是合适的候选方案。
    • 使用Azure Migrate应用容器化生成容器项目，然后验证。
  • 直接迁移（只需极少代码更改，即可在 AKS 的 Windows 节点上运行）：
    • 尤其适用于 IIS、.NET Framework（3.5/4.x）、COM 互操作以及 Windows 身份验证这类重新改造成本高昂的工作负载。
    • 使用 AKS Windows 节点池运行 Windows 容器，只需进行极少的更改。

对每个服务进行分类，并添加预期的迁移工作量估计（天/周）和回滚策略。

阶段 3 — Windows 特定的就绪情况检查

如果服务面向Windows，请验证以下具体信息：

  • IIS 和应用池标识：
    • 应用是否依赖于特定的 AppPool 标识或模拟？ 为 gMSA 或托管标识做好规划。
  • .NET框架兼容性：
    • .NET Framework 3.5 和 4.x 在Windows容器中的Windows Server映像上运行。 如果可以移动到 .NET 6/7/8，首选 Linux 容器，但旧版 Framework 应用支持Windows容器。
  • COM / COM+ / 原生互操作:
    • 许多 COM 和 COM+ 组件无法完全容器化。 选项：重新实现、包装为 VM 中的Windows服务，并在组件在 Windows ServerCore 映像中工作时公开网络 API 或容器化（仔细验证）。
  • Windows身份验证（Kerberos/NTLM）：
    • 为 Kerberos 约束委派场景规划采用 gMSA（组托管服务账户）或 Active Directory 集成。 某些工作负载需要采用 VM/AD 形式，以保留旧有行为。
  • 文件系统和配置文件要求：
    • 依赖计算机级注册表项、本地服务或桌面会话产物的应用可能需要重构。

交付成果：针对每个工作负载的 Windows 兼容性清单，以及决定是进行重构还是在 Windows 节点池上运行。

阶段 4 - 合规性和安全基线

在 AKS 上运行生产流量之前，请定义并强制实施安全基线。

  • 图像来源：
    • 强制执行已签名映像和映像扫描。 为允许使用的注册表和映像标记设置 ACR（Azure 容器注册表）策略。
  • 适用于 AKS 的 Azure Policy 基线：
    • 使用 Azure Policy 的来宾配置策略和 Kubernetes 策略，对命名空间、资源限制、允许使用的容器注册表以及禁止的权限提升实施强制执行。
  • 机密管理：
    • 将基于文件或配置的机密替换为Azure 密钥保管库或密封的机密。 确保 RBAC 和网络控制措施对机密存储提供保护。
  • 注册表分发和可用性：
    • 如果跨区域部署，请使用 ACR 异地复制进行多区域分发和冗余。
  • 认证和供应链：
    • 在合规要求规定时，采用镜像签名和证明流程（例如 Notation/Sigstore 模式）。

交付成果：一套可执行的策略，以及 CI 门禁标准（镜像扫描通过、存在签名、清单已验证）。

2. 旧版迁移路径 - 实用模式

根据分类选择每个服务的路径。 通常，在同一应用程序中使用多个模式（“strangler fig”+ 某些Windows直接迁移部分）。

路径 1 — 结合容器应用程序网关的绞杀者模式

如果您希望进行渐进式迁移，而不进行一次性整体切换，请使用此方式。

  • 方法：
    • 将新的容器化服务部署到 AKS。
    • 使用 Application Gateway（或 Application Gateway for Containers/入口控制器）作为位于传统主机和 AKS 前端的路由入口。
    • 按 URL 路径、主机标头或功能标志标头以增量方式移动流量。
    • 当对于给定路径的流量完全切换到 AKS 后，请停用旧主机。
  • 好处：
    • 影响范围最小；只需将流量切回原有主机即可轻松回滚。
    • 适用于边界清晰的场景，在这种情况下，你可以每次迁移一个路由或一个 API。
  • 考虑：
    • 会话相关性和粘滞会话 - 在迁移之前使用 redis 会话存储或转换为无状态会话。
    • 两端的 TLS 终止和证书管理。

如果您拥有一个具有清晰模块边界的单体应用，或者一个可按路径进行路由的 Web 层，则建议采用。

路径 2 - 使用Windows节点池进行直接迁移

当重构成本高得难以承受且应用需要在 Windows 上运行时使用。

  • 运作方式：

    • 将Windows节点池添加到 AKS 群集：

      az aks nodepool add \
  --resource-group $RESOURCE_GROUP \
  --cluster-name $CLUSTER_NAME \
  --name winnp \
  --os-type Windows \
  --node-count 2 \
  --node-vm-size Standard_D4s_v3
      • 使用节点选择器部署Windows容器：
      spec:
  nodeSelector:
    "kubernetes.io/os": windows

    • 使用官方基础映像，例如：

      • mcr.azk8s.cn/dotnet/framework/aspnet （.NET Framework 上的 ASP.NET）
      • mcr.azk8s.cn/windows/servercore/iis （IIS 服务器）

    • AKS 中的 Windows 节点池需要使用 Azure CNI（因此需相应规划子网大小）。

  • 何时选择：
    • IIS 托管的应用、严重依赖 Windows API 的 .NET Framework 应用，或者依赖 Windows 身份验证和 COM 互操作的应用。
  • 局限性：
    • Windows 容器具有不同的资源特性，且映像大小更大。
    • 某些 Kubernetes 功能和附加组件在 Windows 上可能存在差异；请验证你的可观测性和系统工具链。
  • 保障性：
    • AKS 节点镜像中的 Windows Server 2019/2022 镜像支持 .NET Framework 3.5 和 4.x。 验证运行时所用的具体补丁版本和映像版本。

路径 3 - 使用 AKS 自动分阶段重构

当您能够进行现代化改造，但又想减轻运维负担时。

  • AKS 自动（托管节点预配和缩放）可以简化群集生命周期任务，使团队专注于应用。
  • 方法：
    • 一次将绑定上下文提取到一个服务的容器中。
    • 使用绞杀榕路由层来管理流量。
    • 让 AKS 自动处理节点预配、自动缩放、OS 修补和升级（如果适用）。
  • 好处：
    • 降低集群运维工作负担；在推进现代化的同时采用云原生最佳实践时尤为理想。
  • 考虑：
    • 需要对 CI/CD 和映像提升进行投资，以防止操作偏移。

3. Windows和.NET框架工作负荷迁移 - 实际清单

本部分合并了特定于 Azure 的命令和对 AKS 中Windows工作负荷的实际检查。

添加Windows节点池（示例）

使用Azure CLI代码片段（自定义资源名称）：

az aks nodepool add \
  --resource-group $RESOURCE_GROUP \
  --cluster-name $CLUSTER_NAME \
  --name winnp \
  --os-type Windows \
  --node-count 2 \
  --node-vm-size Standard_D4s_v3

Notes:

  • Windows节点池需要Azure CNI 网络。 在添加池之前规划子网 IP 容量。
  • 您可以创建混合 OS 群集（Linux + Windows 节点池），并使用 nodeSelector 或 nodeAffinity 来限制 Windows Pod 的调度。

部署Windows容器

示例 Pod 选择器（YAML 片段）：

spec:
  nodeSelector:
    "kubernetes.io/os": windows
  containers:
  - name: legacy-iis
    image: mcr.azk8s.cn/windows/servercore/iis:windowsservercore-ltsc2022
    ports:
    - containerPort: 80
  • 基础映像：
    • 适用于 .NET Framework 上的 ASP.NET 应用的 mcr.azk8s.cn/dotnet/framework/aspnet
    • 用于通用 IIS 工作负载的 mcr.azk8s.cn/windows/servercore/iis
  • 网络：
    • 使用 Azure CNI;确保子网大小足够，并验证网络策略。

Windows身份验证和 gMSA

若要在 AKS 群集上启用 gMSA，请执行以下操作：

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-windows-gmsa

高级步骤：

  • 在 Active Directory 中准备 gMSA 凭据。
  • 创建引用 gMSA 帐户的 Kubernetes 资源 （CredentialSpec）。
  • 在 pod 规范中引用凭据规范。

如果应用依赖于 Kerberos 约束委派或 NTLM，请在迁移生产流量之前使用测试帐户和 AD 集成来验证端到端。

.NET现代化路径

  • 如果应用可以升级到 .NET（Core/.NET 6/7/8），则首选 Linux 容器，以支持较小的映像和更好的生态系统支持。
  • 使用 ASP.NET 容器化教程计划从 .NET Framework 移植到 .NET Core/.NET 6+。
  • 对于无法快速完成现代化改造的应用，请采用 Windows 原样迁移路径，并规划并行推进的现代化改造待办事项清单。

4. 旧版迁移常见问题解答 （快速解答）

问：是否可以在 AKS 上的容器中运行 IIS？ A:是的。 使用Windows节点池和 IIS 基础映像。 Azure Migrate应用容器化可以为许多 IIS 应用生成 Dockerfile 和 Kubernetes 清单，从而减少手动步骤。 对于Windows身份验证方案，请配置 gMSA。

问：是否可以容器化 COM+ 或 COM 互操作组件？ A：通常不是——COM+ 和深度原生互操作通常与容器化模式不兼容。 选项：

  • 重新实现或包装为托管在 VM 中的网络服务（REST/gRPC），或重构为.NET服务。
  • 如果 COM 组件在 ServerCore 映像中正常运行，并且没有内核或硬件依赖项，则你也许可以测试 Windows 容器，但要预期存在兼容性风险。

问：如何为 Pod 启用 Kerberos/NTLM（Windows 身份验证）？ 答：在群集上启用 gMSA（请参阅 az aks update --enable-windows-gmsa），在 AD 中创建 gMSA 凭据规范，并在 Pod 规范中引用它们。 验证票证转发和 SPN 端到端。

问：来自 ACR 的 ImagePullBackOff - 常见原因和修复

  • 确保群集标识（托管标识或服务主体）在目标 ACR 上具有 AcrPull 角色分配。
  • 确认 ACR URI 和映像标记正确，ACR 和群集具有网络连接（VNet 规则、专用终结点）。
  • 如果使用专用终结点，请确保群集中注册表的 DNS 解析正确解析。

问：添加 Windows 节点池后，Azure CNI IP 地址耗尽

  • Windows节点需要每个节点更多的保留 IP;相应地规划子网大小。
  • 缓解措施：

    • 在添加Windows节点池之前，使用足够的 IP 预先调整子网的大小。

    • 创建节点池时，请使用较低的 --max-pods 设置，以减少每个节点上的 Pod IP 数量：

      az aks nodepool add ... --max-pods 20

    • 仅在受支持的环境中评估 Azure CNI 覆盖网络或其他网络方案。

问：如何处理已迁移应用中的机密？

  • 将基于文件的敏感信息和镜像中的配置替换为 Azure 密钥保管库，或替换为由 密钥保管库 提供程序支持的 Kubernetes Secret。
  • 使用 Azure RBAC 和 Kubernetes RBAC 强制实施机密访问;使用最低权限。

问：ACR 异地复制和内容信任呢？

  • 使用 ACR 异地复制将映像推送到区域群集更近，并减少冷拉。
  • 采用镜像签名和供应链证明（例如 Sigstore/Notation 或其他解决方案），并在合规性有要求时，使用 Azure Policy 强制实施来源证明。

迁移清单（实际后续步骤）

  1. 运行自动发现（Azure Migrate应用容器化）并生成就绪情况报告。
  2. 生成依赖项映射并为每个服务评分，以便实现容器化准备。
  3. 对每个服务（重构、重新调整、直接迁移）进行分类，并确定积压工作优先级。
  4. 对于Windows工作负荷：
    • 运行Windows兼容性清单（IIS、.NET Framework 版本、COM、gMSA）。
    • 规划 Azure CNI 子网大小
    • 在测试群集中添加Windows节点池，并验证端到端行为。
  5. 定义安全基线：
    • ACR 策略、镜像扫描、镜像签名、适用于 AKS 的 Azure Policy。
    • 机密迁移计划（密钥保管库）。
  6. 选择迁移方案，并以低风险流量开展试点：
    • 使用 Application Gateway for Containers 的绞杀榕模式实现渐进式切换。
    • 验证性能、日志记录和可观测性（App Insights、Prometheus、Fluentd）。
  7. 迭代推进：迁移下一个限界上下文，让遗留组件退役，并准备好回滚方案。
  • Last updated on