应用容器化迁移实战：从评估到落地的完整指南

1. 应用容器化迁移的整体思路与方案选型

1.1 为什么“能跑”不等于“该迁”

很多团队第一次做容器化迁移，最容易犯的错误就是“把能跑的 jar 包塞进镜像就算完事”。我见过一个典型场景：某公司把一套跑了五年的单体应用直接打成镜像扔进集群，结果启动时间从原来的 40 秒变成 3 分钟，健康检查频繁超时，滚动更新永远卡在第一个 Pod。问题出在哪？不是容器本身慢，而是应用在启动阶段做了大量本地文件读写和外部依赖同步，这些操作在物理机上“碰巧很快”，在容器里因为存储驱动和网络栈的差异被放大了。

所以容器化迁移的第一原则是：先评估，再动手。评估的核心不是“这个应用能不能跑在容器里”，而是“这个应用在容器环境下的行为特征是否可接受”。具体要看的维度包括：启动耗时、本地状态依赖、日志输出方式、配置加载路径、对内核参数的依赖、进程管理模型。这些维度里只要有一项是“强依赖宿主机特定状态”，迁移方案就得单独设计。

我通常用一个简单的打分表来快速判断迁移优先级：

这张表不是理论推导，是我在多个迁移项目里踩坑之后总结出来的。你会发现，真正决定迁移成本的往往不是代码本身，而是这些“看不见的耦合”。

1.2 迁移策略的三种路径与选择逻辑

应用容器化迁移大致有三条路径，每条路径的适用场景和代价完全不同。

第一条路径是“直接打包”。就是把现有构建产物原封不动放进基础镜像，不改代码、不改启动方式。这条路径最快，适合无状态服务、启动快、日志走标准输出的应用。但它的隐患在于：你只是把物理机的问题带进了容器，并没有真正获得云原生的好处。我一般只建议在 POC 阶段用这条路径，用来验证集群调度和网络连通性。

第二条路径是“轻量改造”。在不重写业务逻辑的前提下，调整启动脚本、配置加载方式、日志输出和健康检查端点。比如把java -jar改成带-Dspring.profiles.active的启动方式，把本地日志文件改成 logback 的 console appender，增加一个/healthz接口。这条路径的投入产出比最高，也是大多数生产迁移的首选。改造点通常集中在三处：入口脚本、配置注入、可观测性埋点。

第三条路径是“重构适配”。当应用本身是单体且耦合严重，或者有大量本地状态时，就需要拆分服务、引入外部化配置、改造数据访问层。这条路径成本最高，但也是真正走向云原生的必经之路。我的建议是：如果应用还有三年以上的生命周期，且业务迭代频繁，那就值得走这条路；如果只是维护型系统，轻量改造就够了。

选择哪条路径，核心看两个指标：应用的生命周期预期和业务迭代频率。生命周期长且迭代频繁，重构适配的长期收益最大；生命周期短或迭代少，轻量改造更划算。这个判断没有绝对标准，但一定要在迁移前和业务方对齐，否则后期返工的成本会非常高。

1.3 镜像分层与构建效率的平衡

容器化迁移绕不开镜像构建。很多人只关心“镜像能不能跑”，不关心“镜像怎么构建”。但实际生产中，镜像构建效率直接影响发布频率和回滚速度。

Dockerfile 的每一层都是缓存单元。如果把频繁变动的代码复制放在前面，每次构建都会失效后续所有层，导致依赖重新下载。正确的做法是：先复制依赖描述文件，安装依赖，再复制源码。以 Java 为例，先COPY pom.xml，执行mvn dependency:go-offline，再COPY src。这样只要 pom 不变，依赖层就一直命中缓存。

另一个容易被忽视的点是基础镜像的选择。不要用latest标签，也不要用体积巨大的通用镜像。我通常选择 alpine 或 distroless 作为基础镜像，前者体积小但需要处理 musl 兼容性，后者更安全但调试困难。折中方案是用 slim 版本，比如eclipse-temurin:17-jre-jammy，体积适中，兼容性好，调试工具也齐全。

还有一点：多阶段构建不是银弹。它确实能减小最终镜像体积，但会增加构建复杂度。如果团队没有成熟的 CI 缓存机制，多阶段构建反而会拖慢构建速度。我的经验是：先用单阶段构建跑通流程，等 CI 稳定后再引入多阶段优化。

2. 核心细节解析与实操要点

2.1 入口脚本的设计与信号处理

容器化迁移里最容易被低估的就是入口脚本。很多人直接写CMD ["java", "-jar", "app.jar"]，看起来没问题，但实际运行时会发现：容器收到 SIGTERM 后，Java 进程没有优雅退出，导致正在处理的请求被强制中断。

原因在于：容器里的 1 号进程是 Java 本身，它默认不处理 SIGTERM 信号。解决方案有两种：一是用exec形式的 CMD，让 Java 成为 1 号进程，然后在应用里注册 shutdown hook；二是引入轻量 init 进程（如 tini）来转发信号。我通常推荐第一种，因为改动最小，只需要在 Spring Boot 里加一个@PreDestroy方法或者配置server.shutdown=graceful。

如果应用启动前需要做一些准备工作，比如等待数据库就绪、生成配置文件，那就需要写一个 shell 入口脚本。这个脚本要注意三点：第一，用exec执行最终命令，确保信号能传递到应用进程；第二，脚本本身要能处理异常退出，避免容器一直卡在启动阶段；第三，不要在脚本里做耗时太长的操作，否则健康检查会失败。

一个典型的入口脚本长这样：

#!/bin/sh set -e # 等待依赖服务就绪，最多重试 30 次 for i in $(seq 1 30); do if nc -z "$DB_HOST" "$DB_PORT" 2>/dev/null; then break fi echo "waiting for database..." sleep 2 done # 生成运行时配置 envsubst < /app/config.template > /app/config.yaml # 用 exec 启动应用，确保信号传递 exec java -jar /app/app.jar --spring.config.location=/app/config.yaml

这个脚本里set -e保证任何一步失败就退出，nc -z做端口探测，envsubst做配置注入，最后exec替换当前进程。看起来简单，但每一条都是踩过坑之后加上的。

2.2 配置注入的三种方式与优先级

容器化之后，配置不能再硬编码在镜像里。配置注入有三种常见方式：环境变量、挂载配置文件、配置中心。它们各有适用场景，优先级也不同。

环境变量适合少量、简单的配置项，比如数据库地址、日志级别。优点是注入方便，Kubernetes 的 ConfigMap 和 Secret 都能直接映射成环境变量。缺点是数量多了之后难以管理，而且敏感信息容易在kubectl describe里泄露。

挂载配置文件适合复杂配置，比如多级嵌套的 YAML。优点是结构清晰，可以版本化管理。缺点是更新配置需要重启 Pod（除非用 sidecar 做热加载），而且挂载的文件权限容易出问题。

配置中心适合动态配置和灰度发布。优点是实时生效，支持多环境隔离。缺点是引入了额外依赖，配置中心本身的高可用需要额外保障。

我的建议是：基础配置走环境变量，复杂配置走挂载文件，动态开关走配置中心。优先级上，环境变量覆盖挂载文件，挂载文件覆盖镜像内默认值。这样既能保证灵活性，又能避免配置混乱。

还有一个细节：敏感信息不要直接放环境变量。Kubernetes 的 Secret 虽然名字叫 Secret，但默认只是 base64 编码，不是加密。如果集群有多租户，建议引入外部密钥管理服务，或者至少在 CI 阶段做加密注入。

2.3 健康检查与就绪探针的配置要点

健康检查是容器化迁移里最容易配错的地方。很多人把 liveness 和 readiness 探针配成一样的，结果应用启动慢的时候，liveness 探针失败导致容器被反复重启，永远起不来。

正确的做法是：liveness 探针只检查进程是否存活，readiness 探针检查应用是否准备好接收流量。liveness 的initialDelaySeconds要足够长，覆盖最坏情况下的启动时间；readiness 的检查频率可以高一些，但failureThreshold要留足余量。

以 Spring Boot 为例，如果用了 actuator，可以直接用/actuator/health/liveness和/actuator/health/readiness。如果没有 actuator，可以自己写一个简单的 HTTP 端点，返回 200 表示就绪。注意不要在这个端点里做数据库查询，否则数据库抖动会导致所有 Pod 被摘除。

还有一个坑：探针的超时时间要小于检查间隔。如果timeoutSeconds大于periodSeconds，探针会一直处于超时状态，Kubernetes 会认为检查失败。我见过有人把timeoutSeconds设成 5，periodSeconds设成 3，结果探针永远失败。

2.4 日志与可观测性的最小改造

容器化之后，日志不能再写本地文件。原因很简单：容器随时可能被调度到其他节点，本地文件会丢失；而且写本地文件会占用容器可写层空间，时间长了会导致节点磁盘压力。

最小改造方案是把日志输出到标准输出和标准错误。Java 应用可以通过 logback 的ConsoleAppender实现，Python 应用可以用logging.StreamHandler，Go 应用默认就是标准输出。这样日志会被容器运行时捕获，再由日志采集组件统一收集。

如果应用有审计日志或需要长期保留的日志，可以挂载一个持久化卷，但要注意日志轮转。不要依赖应用自己轮转，因为容器里的磁盘配额可能很小。建议用 sidecar 容器做日志轮转和转发，或者直接接入日志服务。

可观测性方面，至少要在迁移时加上三个指标：请求量、错误率、响应时间。如果应用已经有 Prometheus 指标端点，直接暴露即可；如果没有，可以用 micrometer 或类似的库快速接入。不要等到迁移完成后再补，因为那时候你根本不知道问题出在哪。

3. 实操过程与核心环节实现

3.1 从零构建一个可迁移的镜像

假设我们有一个 Java 应用，需要迁移到容器环境。下面是完整的实操步骤。

第一步，准备基础镜像。选择eclipse-temurin:17-jre-jammy，这个镜像基于 Ubuntu，兼容性好，体积约 250MB。不要用openjdk:latest，因为它的标签会变，导致构建结果不可复现。

第二步，编写 Dockerfile。核心原则是分层缓存和最小权限。

FROM eclipse-temurin:17-jre-jammy # 创建非 root 用户 RUN groupadd -r appuser && useradd -r -g appuser appuser WORKDIR /app # 先复制依赖描述文件，利用缓存 COPY pom.xml . RUN apt-get update && apt-get install -y --no-install-recommends maven \ && mvn dependency:go-offline -B \ && apt-get remove -y maven && apt-get autoremove -y \ && rm -rf /var/lib/apt/lists/* # 再复制源码并构建 COPY src ./src RUN mvn package -DskipTests -B # 切换到非 root 用户 USER appuser # 暴露端口 EXPOSE 8080 # 入口脚本 COPY entrypoint.sh /app/entrypoint.sh RUN chmod +x /app/entrypoint.sh ENTRYPOINT ["/app/entrypoint.sh"]

这个 Dockerfile 的关键点：非 root 用户运行、依赖层缓存、构建工具用完即删。注意mvn dependency:go-offline之后又删掉了 maven，这是为了减小最终镜像体积。如果 CI 环境有缓存，可以把构建阶段拆成多阶段，效果更好。

第三步，编写 entrypoint.sh。参考上一节的脚本，加上环境变量检查和配置生成。

第四步，构建并测试。本地构建命令：

docker build -t myapp:1.0.0 . docker run -p 8080:8080 -e DB_HOST=localhost -e DB_PORT=3306 myapp:1.0.0

测试时要重点验证：启动时间、健康检查端点、日志输出、信号处理。可以用docker stop测试优雅退出，用docker logs检查日志格式。

3.2 Kubernetes 部署清单的关键字段

镜像构建好之后，下一步是写 Kubernetes 部署清单。这里不展开完整的 YAML，只讲几个容易出错的字段。

resources 的 requests 和 limits。requests 影响调度，limits 影响运行时。如果只设 limits 不设 requests，调度器会认为 Pod 不需要资源，可能被调度到资源紧张的节点。如果 requests 设得太高，Pod 会一直 Pending。我的经验是：requests 设为正常负载的 70%，limits 设为峰值负载的 120%。CPU 的 limits 不要设得太低，否则会被 throttle；内存的 limits 要设，否则 OOM 会拖垮节点。

livenessProbe 和 readinessProbe。参考上一节的配置要点。注意initialDelaySeconds要覆盖最坏启动时间，failureThreshold不要设成 1，否则一次网络抖动就会导致重启。

securityContext。至少设置runAsNonRoot: true和readOnlyRootFilesystem: true。后者要求应用不写本地文件，如果必须写，挂载一个 emptyDir 到临时目录。

terminationGracePeriodSeconds。默认是 30 秒，如果应用处理长请求，需要调大。同时要确保应用能响应 SIGTERM 并优雅退出，否则调大也没用。

3.3 迁移后的验证清单

迁移完成不等于结束，必须做一轮完整的验证。我通常用下面这个清单：

这个清单看起来简单，但每一条都对应一个真实的故障场景。比如“优雅退出”这一条，如果没验证，滚动更新时就会丢请求；“资源限制”这一条，如果没验证，上线后可能因为内存泄漏导致节点雪崩。

3.4 灰度发布与回滚方案

容器化迁移的最后一步是上线。不要一次性全量切换，要用灰度发布。Kubernetes 原生支持滚动更新，但滚动更新不等于灰度。滚动更新是逐步替换，灰度是按比例引流。

如果集群有服务网格，可以用流量切分做灰度。如果没有，可以用两个 Deployment 加一个 Service，通过调整副本数比例来模拟灰度。比如旧版本 9 个副本，新版本 1 个副本，观察一段时间后再调整。

回滚方案要提前准备好。镜像要打上明确的版本标签，不要用latest。回滚时直接改 Deployment 的镜像标签，或者用kubectl rollout undo。注意回滚也要验证，因为数据库 schema 可能已经变了，回滚应用不一定能兼容新数据。

4. 常见问题与排查技巧实录

4.1 启动慢导致的探针失败

这是迁移初期最常见的问题。现象是 Pod 一直重启，事件里显示Liveness probe failed。原因通常是initialDelaySeconds设得太短，或者应用启动时做了大量初始化。

排查方法：先看 Pod 日志，确认应用启动到哪一步卡住。如果是数据库连接超时，检查网络策略和数据库地址；如果是加载本地文件慢，检查挂载卷的性能。临时解决方案是调大initialDelaySeconds和failureThreshold，但根本方案是优化启动逻辑，把非必要的初始化改成懒加载。

我遇到过一个案例：应用启动时要加载一个 200MB 的字典文件，从网络存储读取耗时 90 秒。后来把字典文件打进镜像，启动时间降到 5 秒。这个优化在物理机上不明显，但在容器里效果立竿见影。

4.2 内存限制导致的 OOM

Java 应用在容器里跑，如果不设置 JVM 的堆内存参数，JVM 会按照宿主机内存来计算默认堆大小。比如宿主机有 64GB 内存，容器限制是 2GB，JVM 可能把堆设成 16GB，结果一启动就被 OOM Kill。

解决方案是设置-XX:MaxRAMPercentage=75，让 JVM 按容器内存限制的百分比来算堆大小。或者显式设置-Xmx，但要注意留出堆外内存的空间。除了堆，还要关注 Metaspace、线程栈、直接内存，这些加起来可能占用几百 MB。

排查 OOM 时，先看kubectl describe pod里的Last State，确认退出码是 137（OOM Kill）。然后看监控里的内存曲线，如果是一直上涨然后突然掉下来，基本就是内存泄漏。如果是启动后很快 OOM，那就是堆参数没设对。

4.3 网络策略导致的连接超时

容器化之后，网络模型变了。物理机上直接连 IP 就行，容器里要走 Service 和 DNS。常见问题是：应用配置里写的是硬编码 IP，迁移后 IP 变了，连不上。

排查方法：先在 Pod 里用nslookup或dig测试 DNS 解析，再用nc或curl测试端口连通性。如果 DNS 解析失败，检查 Service 名称和命名空间；如果端口不通，检查 NetworkPolicy 和防火墙规则。

还有一个坑：DNS 缓存。Java 默认会缓存 DNS 解析结果，如果 Service 的 IP 变了，应用可能还在用旧 IP。解决方案是设置networkaddress.cache.ttl为较短的值，或者用 Headless Service 直接解析 Pod IP。

4.4 镜像拉取失败的排查

镜像拉取失败通常有三个原因：镜像不存在、权限不足、网络不通。排查顺序是：先在本地docker pull测试，确认镜像存在且可拉取；然后检查 Kubernetes 的 Secret 配置，确认imagePullSecrets正确；最后检查节点到镜像仓库的网络连通性。

如果用的是私有仓库，注意证书问题。自签名证书需要配置节点的 CA，否则 kubelet 会拒绝拉取。还有一个细节：镜像标签不要用latest，因为latest的拉取策略默认是Always，每次启动都会尝试拉取，如果仓库不稳定就会导致启动失败。

4.5 常见问题速查表

这张表是我在迁移过程中逐步积累的，每一条都对应至少一次真实的故障。建议在迁移前就把这张表打印出来，遇到问题先对照排查，能省很多时间。

4.6 几个容易被忽视的细节

第一个细节是时区。容器默认是 UTC 时间，如果应用依赖本地时区，日志时间会对不上。解决方案是在 Dockerfile 里设置TZ环境变量，或者挂载宿主机的时区文件。

第二个细节是文件句柄数。容器默认的ulimit可能比物理机小，高并发场景下会出现Too many open files。解决方案是在 Deployment 里设置securityContext的ulimits，或者调整节点的默认值。

第三个细节是临时目录。很多应用会在/tmp下写临时文件，如果容器根文件系统是只读的，就会失败。解决方案是挂载一个emptyDir到/tmp，并设置合适的大小限制。

第四个细节是启动顺序。如果应用依赖多个外部服务，启动时可能因为某个服务未就绪而失败。解决方案是在入口脚本里做依赖检查，或者用 Kubernetes 的initContainer做前置检查。

这些细节看起来琐碎，但每一个都可能导致迁移失败。我的经验是：迁移前把这些问题列成清单，逐项确认，比事后排查效率高得多。

5. 迁移后的持续优化方向

5.1 从“能跑”到“跑得好”

迁移完成只是起点，不是终点。接下来要关注的是资源利用率、启动速度、发布效率。资源利用率方面，可以通过监控数据调整 requests 和 limits，把 CPU 利用率从 10% 提升到 40% 以上。启动速度方面，可以通过应用瘦身、类加载优化、懒加载等手段，把启动时间从分钟级降到秒级。

发布效率方面，可以引入 CI/CD 流水线，把镜像构建、测试、部署自动化。我见过一个团队，迁移前发布一次需要 2 小时，迁移后通过流水线缩短到 10 分钟。关键不是工具多先进，而是流程标准化：每次发布都走同样的步骤，每次回滚都有明确的触发条件。

5.2 安全加固的渐进式策略

容器安全不是一次性的，是持续的过程。起步阶段至少做到：非 root 运行、只读根文件系统、最小化基础镜像。进阶阶段可以引入镜像扫描、运行时安全策略、网络微隔离。高级阶段可以做供应链安全，包括镜像签名、SBOM 生成、依赖漏洞追踪。

我的建议是：不要一开始就追求全覆盖，先从非 root 和只读根文件系统做起，这两项能挡住大部分常见风险。等团队熟悉了容器运维节奏，再逐步引入其他安全措施。

5.3 团队协作与知识沉淀

容器化迁移不只是技术问题，更是协作问题。开发团队要理解容器的最佳实践，运维团队要掌握 Kubernetes 的排障技能，测试团队要适应容器化的测试环境。我通常建议在迁移过程中做三件事：第一，建立内部文档，记录每个应用的迁移方案和踩坑记录；第二，定期做故障演练，模拟 Pod 重启、节点故障等场景；第三，把常见问题整理成速查表，降低新人的上手成本。

我在实际迁移中最大的体会是：迁移的难点不在技术，而在沟通。开发觉得“能跑就行”，运维觉得“不稳定不能上”，两边标准不一致，项目就会卡住。解决方法是提前对齐验收标准，把“能跑”定义清楚：启动时间多少、错误率多少、资源占用多少。标准明确了，后面的工作就顺了。

最后分享一个小技巧：迁移时先选一个非核心应用做试点，跑通全流程后再推广到核心应用。试点应用的选择标准是：无状态、启动快、依赖少、业务容忍度高。这样即使出问题，影响也可控，团队也能积累经验。等试点稳定运行一个月后，再开始第二批迁移，节奏会快很多。