1. 应用容器化迁移的整体思路拆解
1.1 为什么“能跑”不等于“该迁”
很多团队第一次做容器化迁移，最容易犯的错就是把“把应用塞进镜像里能启动”当成迁移完成。我见过一个典型场景：某公司把一个跑了五六年的单体应用直接打成镜像扔进集群，结果上线第二天就出问题——日志写进了容器层，Pod一重启数据全丢；配置文件硬编码在镜像里，换个环境就得重新构建；健康检查配的是首页HTTP 200，但数据库连接池早就打满了，流量还在往里灌。
容器化迁移的本质不是“打包”，而是让应用适配云原生的运行契约。这个契约包括几个核心条款：进程要前台运行且能响应信号、状态要外置、配置要注入、日志要走标准输出、健康状态要可探测。任何一条不满足，迁进去就是给自己埋雷。
所以我在做迁移规划时，第一步从来不是写Dockerfile，而是先做一轮应用画像。画像的维度包括：
- 进程模型：是单进程还是多进程？有没有守护进程依赖？启动时有没有初始化脚本？
- 状态分布：哪些数据是临时的、哪些是必须持久化的？会话状态存在哪？
- 配置来源：配置文件、环境变量、启动参数、配置中心，各占多少？
- 依赖关系：依赖哪些中间件、外部服务、文件系统、定时任务？
- 生命周期：启动要多久？优雅停机需要多长时间？有没有预热逻辑？
这张画像表决定了后面所有技术选型。比如画像显示应用启动需要90秒做缓存预热，那健康检查的initialDelaySeconds就不能拍脑袋写10秒，否则Pod永远起不来就被杀掉，陷入重启循环。
1.2 迁移策略的三种路径与选择逻辑
应用容器化迁移不是只有一条路。根据应用的可改造程度和业务容忍度，我通常把策略分成三类：
路径一：直接容器化（Lift & Shift）
把现有应用原封不动打进镜像，只做最小适配（比如改日志输出方式）。适合那些老旧但稳定、短期内不打算重构的系统。优点是快，缺点是只享受到了容器编排的调度红利，没拿到云原生的弹性、可观测性红利。
路径二：适配性改造（Re-platform）
在容器化的同时做适度改造：外置配置、接入健康检查、日志标准化、状态外移。这是大多数业务系统的甜点区——改造成本可控，收益明显。我一般建议团队优先走这条路。
路径三：重构上云（Re-architect）
拆微服务、改通信方式、引入服务网格。适合核心业务且团队有足够工程能力的情况。这条路周期长、风险高，不建议在迁移初期就全面铺开。
选择逻辑可以用一个简单的决策矩阵来判断：
| 维度 | 直接容器化 | 适配性改造 | 重构上云 |
|---|---|---|---|
| 改造成本 | 低 | 中 | 高 |
| 迁移周期 | 天级 | 周级 | 月级 |
| 弹性能力 | 无 | 部分 | 完整 |
| 可观测性 | 基础 | 完善 | 完善 |
| 适用场景 | 边缘系统、临时过渡 | 大多数业务系统 | 核心链路、长期演进 |
我的经验是：先全部走适配性改造，把80%的系统用统一标准迁进去，剩下20%特别复杂的再单独评估。不要一上来就追求完美，迁移是迭代过程，不是一次性工程。
1.3 迁移成熟度模型：你在哪一级
在动手之前，先给团队和系统定个位。我习惯用一个五级成熟度模型来衡量：
- L1 手工打包：手动写Dockerfile，手动构建推送，手动部署。能跑，但不可重复。
- L2 脚本化：有构建脚本和部署脚本，但环境差异靠人肉记忆。
- L3 流水线化：CI/CD流水线自动构建、测试、部署，镜像有版本管理。
- L4 声明式：所有资源用代码描述，环境一致性由工具保证，回滚是一键操作。
- L5 自愈化：健康检查、自动扩缩容、故障自愈全部就位，人只需要关注业务指标。
大多数团队第一次迁移时处在L1到L2之间。目标不是一步到L5，而是先稳定在L3，再逐步向L4演进。L3的核心标志就是：任何人拿到代码仓库，不需要问任何人，就能通过流水线把应用部署到任意环境。这个标准看起来简单，实际能做到的团队不多。
2. 容器化改造的核心细节与实操要点
2.1 Dockerfile的写法决定了镜像质量的上限
Dockerfile谁都会写，但写出生产级质量的Dockerfile是另一回事。我先说几个我踩过的坑，再给一套经过验证的模板。
坑一：基础镜像选太大。有人用ubuntu:latest做基础镜像，一个镜像动辄七八百MB。拉取慢、占用存储、攻击面大。正确做法是根据运行时选最小基础镜像：Java应用用eclipse-temurin:17-jre-alpine，Go应用直接scratch或distroless，Node应用用node:20-alpine。
坑二：层数太多且顺序不合理。每一条RUN、COPY、ADD都是一层。如果把COPY . .放在RUN npm install前面，那每次改一行代码都会导致依赖重新安装。正确顺序是：先拷贝依赖描述文件，安装依赖，再拷贝源码。
坑三：以root运行。容器里默认root，一旦被突破就是宿主机级别的风险。必须创建非root用户并切换。
下面是我常用的一套多阶段构建模板，以Java应用为例：
# 构建阶段 FROM maven:3.9-eclipse-temurin-17 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn package -DskipTests -B # 运行阶段 FROM eclipse-temurin:17-jre-alpine RUN addgroup -S appgroup && adduser -S appuser -G appgroup WORKDIR /app COPY --from=builder /build/target/*.jar app.jar RUN chown -R appuser:appgroup /app USER appuser EXPOSE 8080 ENTRYPOINT ["java", "-XX:MaxRAMPercentage=75.0", "-jar", "app.jar"]这里有几个细节值得展开说。dependency:go-offline单独一层，利用Docker层缓存，只要pom.xml不变，依赖就不会重新下载。MaxRAMPercentage=75.0让JVM根据容器内存限制自动计算堆大小，避免写死-Xmx导致容器内存超限被OOM Kill。用ENTRYPOINT的exec形式而不是shell形式，保证Java进程是PID 1，能正确接收SIGTERM信号实现优雅停机。
2.2 配置外置：十二要素里的第一条硬规矩
配置硬编码在镜像里，是迁移后最常见的返工原因。我见过一个团队，测试环境和生产环境的数据库地址不一样，他们的做法是构建两个镜像。结果有一次发版发错了镜像，生产连到了测试库，数据污染了一大片。
配置外置的核心原则是：镜像不可变，配置可注入。具体做法分三层：
第一层是环境变量，适合简单的键值对配置，比如数据库地址、端口号、日志级别。在Kubernetes里通过ConfigMap和Secret注入。
第二层是配置文件挂载，适合结构复杂的配置，比如Nginx配置、应用的多层级YAML。通过ConfigMap挂载成文件，或者用Init Container从配置中心拉取。
第三层是配置中心，适合需要动态刷新的配置。应用启动时从配置中心拉取，运行时监听变更。这一层需要应用代码配合改造，成本较高，但收益也最大。
我的一般建议是：新项目直接上配置中心，老项目先做环境变量和文件挂载，配置中心作为二期目标。不要为了追求架构统一而拖慢迁移进度。
这里有个容易忽略的点：敏感配置不能走ConfigMap。数据库密码、API密钥这些必须用Secret。而且Secret默认是base64编码不是加密，生产环境要开启etcd加密存储，或者接入外部密钥管理服务。我见过有人把密码写在ConfigMap里提交到了代码仓库，这跟把钥匙插在门上没区别。
2.3 状态外移：有状态应用的迁移难点
无状态应用迁移简单，有状态应用才是真正的考验。状态分几种：文件状态、会话状态、缓存状态、数据库状态。处理方式各不相同。
文件状态的处理原则是：容器内不写本地文件，要写就写挂载卷或对象存储。如果应用有本地文件读写逻辑，迁移前必须改造。我遇到过一个报表系统，生成的Excel临时文件写在/tmp下，容器重启就丢。改造方案是挂载一个emptyDir卷专门放临时文件，或者直接改成流式输出不落盘。
会话状态的处理有两种思路：一是会话粘滞，用Service的sessionAffinity把同一用户的请求打到同一Pod；二是会话外移，把session存到Redis。前者简单但影响负载均衡效果，后者彻底但需要改代码。我的建议是能外移就外移，会话粘滞只是过渡方案。
缓存状态相对好处理，因为缓存本身允许丢失。但要注意缓存预热问题。如果应用启动后需要从数据库加载大量数据到本地缓存，那启动时间会很长，健康检查要相应调整。更好的做法是把缓存层独立出来，用Redis或Memcached，应用本身保持无状态。
数据库状态不在容器化迁移的范围内，但迁移后应用连数据库的方式要调整。连接池大小要跟Pod数量匹配，不能每个Pod都配100个连接，10个Pod就把数据库连接数打满了。我通常建议用连接池大小 = 数据库最大连接数 / Pod数量 * 0.8这个公式来估算。
2.4 健康检查：别让探针成为故障放大器
健康检查配不好，比不配还危险。我见过最离谱的案例是：liveness探针配的是检查数据库连接，结果数据库抖动了一下，所有Pod同时被判定为不健康，集体重启，雪崩。
健康检查分三种，用途完全不同：
- livenessProbe：判断容器是否活着，失败就重启。只检查进程本身，不要检查外部依赖。
- readinessProbe：判断容器是否准备好接收流量，失败就从Service摘除。可以检查关键依赖。
- startupProbe：判断应用是否启动完成，成功前不执行liveness检查。适合启动慢的应用。
参数设置上，initialDelaySeconds要大于应用平均启动时间，periodSeconds不要太短（建议10秒以上），failureThreshold要给足重试次数（建议3次以上）。对于启动需要预热的Java应用，用startupProbe把failureThreshold设大，比如30次乘以10秒等于300秒，给足5分钟启动窗口。
注意：livenessProbe的
timeoutSeconds要小于periodSeconds，否则探针会一直超时。这个细节很多人会忽略。
3. 完整迁移流程与关键环节实现
3.1 迁移前的评估与准备清单
动手之前，先花半天时间把评估做扎实。我整理了一份检查清单，每次迁移前逐项过一遍：
应用侧检查项：
- 应用是否支持前台运行？有没有
nohup、&、systemd依赖？ - 日志输出到哪里？是文件还是标准输出？
- 配置从哪里读？有没有硬编码的环境相关值？
- 有没有本地文件读写？路径是什么？
- 启动需要多长时间？有没有预热逻辑？
- 优雅停机需要多久？有没有正在处理的请求要等待？
- 依赖哪些外部服务？地址是否可配置？
基础设施侧检查项：
- 目标集群的CPU、内存、存储资源是否充足？
- 镜像仓库是否就绪？网络策略是否允许拉取？
- 日志采集、监控告警是否覆盖新集群？
- 域名、证书、负载均衡是否配置？
- 网络策略是否允许应用访问所需的外部服务？
组织侧检查项：
- 谁负责构建镜像？谁负责部署？
- 出问题找谁？值班机制是否明确？
- 回滚方案是什么？回滚需要多长时间？
- 灰度策略是什么？先切多少流量？
这份清单看起来繁琐，但每一条都是血泪教训换来的。我经历过因为没检查网络策略，Pod起来了但连不上数据库，排查了两个小时才发现是NetworkPolicy没放行。
3.2 镜像构建流水线的搭建
手工构建镜像只适合验证阶段，生产必须走流水线。一条合格的镜像构建流水线包含这些环节：
代码提交触发：Git push或Merge Request触发流水线。分支策略上，开发分支构建带分支名的标签，主分支构建带版本号的标签。
代码质量检查：静态代码扫描、单元测试、依赖漏洞扫描。这一步不通过，后面不用走。
镜像构建：用多阶段构建，构建阶段和运行阶段分离。构建完成后打两个标签：一个是具体版本号（如v1.2.3），一个是环境标签（如dev、staging）。生产环境必须用版本号标签，绝对不能用latest。
镜像扫描：用Trivy或类似工具扫描镜像漏洞。高危漏洞直接阻断流水线。这一步很多团队会跳过，但一旦出了安全事件，代价远大于扫描的时间成本。
推送仓库：推送到私有镜像仓库，打上仓库地址前缀。
部署到环境：更新Kubernetes的Deployment镜像版本，触发滚动更新。
这里有个关键决策：镜像标签用版本号还是Git Commit SHA。我的建议是两者都用。版本号给人看，方便沟通；Commit SHA给机器看，方便追溯。标签格式可以是v1.2.3-abc1234。
3.3 Kubernetes资源清单的编写要点
Deployment的YAML看起来简单，但写好需要经验。我挑几个关键字段说：
replicas：初始副本数不要设太高，先设2个验证，稳定后再扩。设太高一旦有bug，影响面大。
strategy：滚动更新策略。maxSurge和maxUnavailable控制更新速度。生产环境建议maxUnavailable: 0，maxSurge: 1，保证更新过程中可用副本数不减少。
resources：requests和limits必须都设。requests影响调度，limits影响运行时。limits不要设得比requests高太多，否则节点资源超卖严重，容易引发连锁OOM。我一般建议limits是requests的1.5到2倍。
env：环境变量注入。敏感值用valueFrom.secretKeyRef，普通配置用valueFrom.configMapKeyRef。
volumeMounts：配置文件挂载。注意挂载会覆盖目录原有内容，如果只想挂载单个文件，用subPath。
securityContext：安全上下文。设置runAsNonRoot: true、readOnlyRootFilesystem: true、allowPrivilegeEscalation: false。这几个开关能挡掉大量容器逃逸攻击。
terminationGracePeriodSeconds：优雅停机时间。要大于应用处理完存量请求所需的时间。Java应用建议30秒以上。
3.4 灰度发布与流量切换
迁移不是一刀切，必须灰度。我的灰度策略分三步：
第一步：旁路验证。新Pod起来后不接生产流量，通过内部测试流量验证功能。这一步用Service的selector切换或者Istio的VirtualService实现。
第二步：小流量灰度。切5%的生产流量到新版本，观察错误率、延迟、资源使用。观察窗口至少30分钟，覆盖一个完整的业务周期。
第三步：全量切换。灰度无异常后，逐步扩大流量比例，最终全量。全量后旧版本保留至少24小时，方便快速回滚。
灰度期间要重点盯的指标：错误率（5xx比例）、P99延迟、CPU和内存使用率、数据库连接数、日志中的异常堆栈。任何一个指标异常，立即回滚。
回滚操作要提前演练。Kubernetes的回滚很简单，kubectl rollout undo一条命令，但前提是旧版本的镜像还在仓库里、旧版本的配置还在Git里。我见过回滚时发现旧镜像被清理了，只能重新构建，耽误了半小时。
4. 常见问题与排查技巧实录
4.1 迁移后应用启动失败的排查路径
Pod起不来是最常见的问题。排查顺序我总结成一条链路：
第一步：看Pod状态。kubectl get pod看是Pending、ImagePullBackOff、CrashLoopBackOff还是Running但NotReady。状态不同，排查方向完全不同。
第二步：看事件。kubectl describe pod看Events区域。Pending通常是资源不足或调度约束不满足；ImagePullBackOff是镜像地址或仓库认证问题；CrashLoopBackOff是应用自身启动失败。
第三步：看日志。kubectl logs看应用日志，kubectl logs --previous看上一次崩溃的日志。启动失败的原因八成在日志里。
第四步：进容器排查。kubectl exec -it进容器，手动执行启动命令，看报错。有时候是文件权限问题、环境变量缺失、依赖库找不到。
我整理了一个速查表：
| 现象 | 可能原因 | 排查命令 |
|---|---|---|
| Pending | 资源不足、节点选择器不匹配 | kubectl describe pod看Events |
| ImagePullBackOff | 镜像地址错、仓库认证失败 | 检查image字段和imagePullSecrets |
| CrashLoopBackOff | 应用启动报错、配置缺失 | kubectl logs --previous |
| Running但NotReady | 健康检查失败 | 检查探针配置和端点 |
| OOMKilled | 内存超限 | kubectl describe pod看Last State |
| Evicted | 节点资源压力 | 检查节点资源和Pod优先级 |
4.2 性能下降的典型原因与调优
迁移后性能下降，通常不是容器本身的问题，而是资源配置和网络模型的问题。
CPU限制过紧：容器里看到的CPU核数和宿主机不一样，JVM的Runtime.availableProcessors()返回的是limits值。如果limits设成1核，JVM会按1核来调优GC线程数，性能自然下降。解决方案是用-XX:ActiveProcessorCount显式指定，或者把limits设合理。
内存限制导致频繁GC：JVM堆大小默认是宿主机内存的1/4，容器里如果不显式设置，可能堆开得太大导致频繁Full GC，或者太小导致OOM。用MaxRAMPercentage让JVM感知容器限制。
网络延迟增加：容器网络比宿主机网络多一层虚拟化，延迟会增加零点几毫秒。对于延迟敏感的应用，可以用hostNetwork模式，但会牺牲隔离性。大多数应用感知不到这个差异。
存储IO下降：容器写本地文件走的是OverlayFS，比直接写宿主机磁盘慢。有大量IO的应用要挂载Volume，或者用本地SSD。
4.3 日志与监控的适配问题
容器化后日志采集方式变了，原来在宿主机上tail文件的方式不适用了。标准做法是应用日志输出到stdout/stderr，由容器运行时收集，再由日志Agent（如Fluent Bit）转发到日志中心。
这里有个常见问题：应用日志格式不统一。有的输出JSON，有的输出纯文本，有的多行堆栈。日志中心解析起来很痛苦。我的建议是迁移时顺便统一日志格式，至少做到结构化输出。Java应用可以用Logback的JSON encoder，Go应用用zap或logrus的JSON格式。
监控方面，原来靠宿主机Agent采集的指标，现在要改成从应用暴露的metrics端点采集。Prometheus的pull模型是主流。应用要暴露/metrics端点，输出Prometheus格式的指标。JVM应用可以用Micrometer，Go应用用prometheus/client_golang。
提示：迁移后一定要重新配置告警规则。原来的告警基于宿主机指标，现在要基于Pod和Service指标。我见过迁移后告警全部失效，出了故障没人知道的情况。
4.4 独家避坑经验汇总
最后分享几条我在多次迁移中总结的经验，每一条都对应着一次真实的教训：
第一条：不要在生产集群上做第一次部署。先在测试集群跑通全流程，包括构建、部署、健康检查、日志采集、监控告警、回滚。生产集群只做验证过的事。
第二条：镜像标签永远不要用latest。latest是个移动靶，今天拉到的和明天拉到的可能不是一个东西。用版本号或Commit SHA，保证可追溯、可回滚。
第三条：资源限制宁松勿紧。迁移初期对应用的真实资源消耗不清楚，limits设太紧会导致频繁OOM和CPU throttling。先设宽松一点，观察一周后再收紧。
第四条：优雅停机时间要给足。默认30秒对大多数应用够用，但如果有长连接或大文件处理，要延长到60秒甚至120秒。停机时间不够会导致请求被强制中断，用户看到502。
第五条：迁移后第一周要有人值守。新环境总有预料不到的问题，第一周安排人盯着监控和告警，有问题及时处理。等稳定运行两周后，再转入正常运维。
第六条：文档要同步更新。迁移后应用的部署方式、配置方式、排查方式都变了，运维文档、值班手册、应急预案都要更新。我见过迁移半年后出故障，值班的人还在翻旧文档，按旧流程操作，越搞越乱。
这套迁移方法我在几个不同规模的项目里用过，从十几个服务的小系统到上百个服务的中等规模，核心逻辑是通的。区别只在于自动化程度和灰度粒度。小系统可以手工多一些，大系统必须全流水线化。但不管规模大小，先画像、再改造、后灰度、勤观察这四步一步都不能省。省一步，后面就要用双倍的时间来还债。
