容器化迁移方案最容易低估的风险，不是镜像构建失败，而是应用已经启动却无法稳定切流、观测和回退。对准备把存量应用迁到 Kubernetes 或容器平台的团队来说，迁移评估要先把运行入口、依赖、状态和回滚边界说清楚。
先回答哪些应用能先迁、哪些配置要外置、哪些数据不能随便切、失败时退到哪里，再进入 Dockerfile、YAML 和流水线改造[1]。下面先从应用画像开始拆解迁移边界。
图1：从存量应用画像到容器资源、配置和依赖的迁移映射关系
迁移前先做应用画像，而不是直接改部署脚本
存量应用能否顺利容器化，通常取决于它和运行环境的耦合程度。迁移前需要把“应用是什么”变成可检查的清单，而不是只问“能不能启动”。
应用画像至少包含：
- 运行入口：启动命令、端口、工作目录、依赖进程。
- 配置来源：配置文件、环境变量、启动参数、配置中心。
- 数据状态：本地文件、缓存目录、上传文件、数据库连接、会话状态。
- 外部依赖：中间件、第三方 API、内部服务、DNS 和证书。
- 发布方式：当前包格式、发布窗口、灰度方式、回滚动作。
- 健康判断：探针接口、日志关键字、业务可用性验证方法。
这一步的输出不是文档归档，而是决定后续改造优先级。例如，完全无状态的 Web 服务可以先迁；依赖本地文件和固定 IP 的应用要先拆状态；强依赖共享目录和手工发布脚本的应用，则需要先做发布链路治理。
如果团队还在补基础概念，可以先结合站内 容器是什么 理解镜像、运行时和隔离边界；本文则把重点放在迁移项目怎么拆、怎么验、怎么回退。图型选择说明：本文使用资源映射、前后架构对比和回滚流程三类图承接迁移路径。
应用改造的核心是把环境差异显式化
容器化迁移常见误区是把原服务器上的目录、脚本和隐式依赖原样塞进镜像。这样短期可能跑起来，但会让镜像不可复现，后续扩缩容和回滚都很困难。
Kubernetes Workloads 官方文档[1]把 Deployment、StatefulSet 等对象归入 Workloads，用于描述应用运行的期望状态；应用迁移时应把进程、配置、存储和暴露方式显式表达为平台对象，而不是继续依赖某台机器的历史状态。
改造优先级可以按下面顺序推进：
- 镜像可复现：固定基础镜像版本，构建过程不依赖构建机上的临时文件。
- 配置可外置：把环境差异放到 ConfigMap、Secret 或配置中心，而不是写死在镜像里。
- 状态可定位：明确哪些数据进入数据库、对象存储、PVC 或缓存服务。
- 健康可判断：提供 readiness 和 liveness 所需的检查接口或命令。
- 日志可采集：标准输出优先，避免日志只写本地文件且无人采集。
例如一个 Java 应用迁移后，启动脚本可以保留，但端口、JVM 参数、配置路径、数据库连接和外部服务地址应通过环境或挂载配置传入。这样同一镜像才能在测试、预发和生产环境中复用。
图2：传统服务器部署与容器平台部署在配置、日志、存储和入口流量
迁移路径要按风险拆批，而不是按系统名称排队
迁移计划不应简单按部门或系统名称排队。更稳妥的方式是按风险拆批，让团队先迁低耦合、低状态、低流量的应用，积累构建、部署、监控和回滚经验，再进入复杂系统。
| 迁移批次 | 应用特征 | 主要动作 | 验收重点 |
|---|---|---|---|
| 第一批 | 无状态、依赖少、流量低 | 镜像化、Deployment、Service | 启动、探针、日志、回滚 |
| 第二批 | 有配置中心或中间件依赖 | 配置外置、Secret、网络策略 | 配置切换、连接稳定性 |
| 第三批 | 有本地文件或会话状态 | 存储改造、会话外置 | 数据一致性、扩缩容 |
| 第四批 | 核心交易或高并发服务 | 灰度、容量评估、压测 | SLO、容量和回退窗口 |
每批迁移都要有退出条件
这张表的价值在于帮助平台和业务团队对齐风险。不是所有应用都要一次性改成“理想云原生架构”，但每一批都要有明确退出条件。
如果企业同时在重构发布链路，可以把镜像构建、制品版本、环境发布和回滚记录串起来，避免迁移后仍靠人工复制命令上线。
回滚边界必须在切流前定义
容器化迁移最危险的说法是“出了问题再回滚”。如果回滚对象、回滚条件和数据兼容性没有提前定义，真正故障时往往无法快速恢复。
上线前至少确认三类回滚边界：
- 版本回滚：镜像、配置、Deployment 版本和入口流量能否退回旧状态。
- 流量回滚：Ingress、Gateway、Service 或外部负载均衡是否能快速切回旧环境。
- 数据回滚：数据库结构、消息格式、文件写入和缓存键是否与旧版本兼容。
这里尤其要注意数据边界。无状态服务通常可以通过流量切换回退；一旦迁移过程修改了数据库结构或写入了新格式数据，回滚就不再是简单切流。此时需要双写、兼容字段、灰度窗口或回滚脚本。
图3：容器化迁移中从灰度放量、监控观察到失败回退的关键节点
验收清单要覆盖平台、应用和业务三层
迁移验收不能只看 Pod Running。Pod 正常只说明进程被调度起来，不代表业务可用、日志可查、故障可恢复。
推荐按三层验收：
- 平台层：镜像来源可信、资源请求合理、探针配置有效、日志和指标可采集。
- 应用层：核心接口可用、配置加载正确、外部依赖连通、异常日志可定位。
- 业务层：灰度用户路径正常、关键交易或任务闭环、回滚条件已演练。
Kubernetes 官方文档将 ConfigMap[2]用于非敏感配置、Secret[3]用于敏感信息管理；迁移验收时应检查这些对象的权限、版本和变更记录，避免把生产密码或环境差异固化进镜像。
关键结论：容器化迁移的验收对象是“可持续运行的服务”，不是“成功启动的容器”。
小结
容器化迁移方案应围绕应用画像、环境解耦、风险分批、灰度切流和回滚边界展开。先识别依赖和状态，再决定改造深度；先定义验收和回滚，再推进上线；先迁低风险应用，再把经验沉淀到平台模板和发布流程。
对多数企业而言，容器化迁移不是一次性项目，而是一条逐步现代化的路径。只要每一批迁移都能留下可复用模板、检查清单和回滚经验，后续迁移成本就会持续下降。
参考资料
常见问题
1. 容器化迁移方案一定要先改造成微服务吗？
不一定。很多应用可以先完成镜像化、配置外置、日志标准化和健康检查，再逐步拆分。是否拆微服务取决于业务边界、发布频率、团队能力和数据一致性要求，不应把拆分当成迁移的前置条件。
2. 有状态应用能不能做容器化迁移？
可以，但要更谨慎。需要先确认状态存在哪里、是否支持多副本、备份恢复怎么做、扩缩容是否安全。数据库、消息队列这类核心有状态组件，不建议只靠简单 YAML 迁移，应先完成数据保护和回滚演练。
3. 迁移后发现性能变差，应该先扩容还是回滚？
先确认影响范围和瓶颈来源。如果是资源请求过低、探针误判或连接池配置不适配，可以在灰度范围内调整；如果核心业务指标明显下降且原因不清，应优先按预案切回旧入口，再做复盘。
4. 容器化迁移回滚是否只需要保留旧镜像？
不够。旧镜像只是版本回滚的一部分，还需要保留旧配置、旧入口规则、旧数据库兼容状态和明确的流量切回方式。没有这些信息，镜像回退也可能无法恢复业务。
