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-alpineGo应用直接scratch或distrolessNode应用用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 --frombuilder /build/target/*.jar app.jar RUN chown -R appuser:appgroup /app USER appuser EXPOSE 8080 ENTRYPOINT [java, -XX:MaxRAMPercentage75.0, -jar, app.jar]这里有几个细节值得展开说。dependency:go-offline单独一层利用Docker层缓存只要pom.xml不变依赖就不会重新下载。MaxRAMPercentage75.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: 0maxSurge: 1保证更新过程中可用副本数不减少。resourcesrequests和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看EventsImagePullBackOff镜像地址错、仓库认证失败检查image字段和imagePullSecretsCrashLoopBackOff应用启动报错、配置缺失kubectl logs --previousRunning但NotReady健康检查失败检查探针配置和端点OOMKilled内存超限kubectl describe pod看Last StateEvicted节点资源压力检查节点资源和Pod优先级4.2 性能下降的典型原因与调优迁移后性能下降通常不是容器本身的问题而是资源配置和网络模型的问题。CPU限制过紧容器里看到的CPU核数和宿主机不一样JVM的Runtime.availableProcessors()返回的是limits值。如果limits设成1核JVM会按1核来调优GC线程数性能自然下降。解决方案是用-XX:ActiveProcessorCount显式指定或者把limits设合理。内存限制导致频繁GCJVM堆大小默认是宿主机内存的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 encoderGo应用用zap或logrus的JSON格式。监控方面原来靠宿主机Agent采集的指标现在要改成从应用暴露的metrics端点采集。Prometheus的pull模型是主流。应用要暴露/metrics端点输出Prometheus格式的指标。JVM应用可以用MicrometerGo应用用prometheus/client_golang。提示迁移后一定要重新配置告警规则。原来的告警基于宿主机指标现在要基于Pod和Service指标。我见过迁移后告警全部失效出了故障没人知道的情况。4.4 独家避坑经验汇总最后分享几条我在多次迁移中总结的经验每一条都对应着一次真实的教训第一条不要在生产集群上做第一次部署。先在测试集群跑通全流程包括构建、部署、健康检查、日志采集、监控告警、回滚。生产集群只做验证过的事。第二条镜像标签永远不要用latest。latest是个移动靶今天拉到的和明天拉到的可能不是一个东西。用版本号或Commit SHA保证可追溯、可回滚。第三条资源限制宁松勿紧。迁移初期对应用的真实资源消耗不清楚limits设太紧会导致频繁OOM和CPU throttling。先设宽松一点观察一周后再收紧。第四条优雅停机时间要给足。默认30秒对大多数应用够用但如果有长连接或大文件处理要延长到60秒甚至120秒。停机时间不够会导致请求被强制中断用户看到502。第五条迁移后第一周要有人值守。新环境总有预料不到的问题第一周安排人盯着监控和告警有问题及时处理。等稳定运行两周后再转入正常运维。第六条文档要同步更新。迁移后应用的部署方式、配置方式、排查方式都变了运维文档、值班手册、应急预案都要更新。我见过迁移半年后出故障值班的人还在翻旧文档按旧流程操作越搞越乱。这套迁移方法我在几个不同规模的项目里用过从十几个服务的小系统到上百个服务的中等规模核心逻辑是通的。区别只在于自动化程度和灰度粒度。小系统可以手工多一些大系统必须全流水线化。但不管规模大小先画像、再改造、后灰度、勤观察这四步一步都不能省。省一步后面就要用双倍的时间来还债。 
长河君 · 2026/10/21 1:37:15 · 阅读 1.2k 应用容器化迁移实战：从应用画像到灰度发布的完整指南
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-alpineGo应用直接scratch或distrolessNode应用用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 --frombuilder /build/target/*.jar app.jar RUN chown -R appuser:appgroup /app USER appuser EXPOSE 8080 ENTRYPOINT [java, -XX:MaxRAMPercentage75.0, -jar, app.jar]这里有几个细节值得展开说。dependency:go-offline单独一层利用Docker层缓存只要pom.xml不变依赖就不会重新下载。MaxRAMPercentage75.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: 0maxSurge: 1保证更新过程中可用副本数不减少。resourcesrequests和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看EventsImagePullBackOff镜像地址错、仓库认证失败检查image字段和imagePullSecretsCrashLoopBackOff应用启动报错、配置缺失kubectl logs --previousRunning但NotReady健康检查失败检查探针配置和端点OOMKilled内存超限kubectl describe pod看Last StateEvicted节点资源压力检查节点资源和Pod优先级4.2 性能下降的典型原因与调优迁移后性能下降通常不是容器本身的问题而是资源配置和网络模型的问题。CPU限制过紧容器里看到的CPU核数和宿主机不一样JVM的Runtime.availableProcessors()返回的是limits值。如果limits设成1核JVM会按1核来调优GC线程数性能自然下降。解决方案是用-XX:ActiveProcessorCount显式指定或者把limits设合理。内存限制导致频繁GCJVM堆大小默认是宿主机内存的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 encoderGo应用用zap或logrus的JSON格式。监控方面原来靠宿主机Agent采集的指标现在要改成从应用暴露的metrics端点采集。Prometheus的pull模型是主流。应用要暴露/metrics端点输出Prometheus格式的指标。JVM应用可以用MicrometerGo应用用prometheus/client_golang。提示迁移后一定要重新配置告警规则。原来的告警基于宿主机指标现在要基于Pod和Service指标。我见过迁移后告警全部失效出了故障没人知道的情况。4.4 独家避坑经验汇总最后分享几条我在多次迁移中总结的经验每一条都对应着一次真实的教训第一条不要在生产集群上做第一次部署。先在测试集群跑通全流程包括构建、部署、健康检查、日志采集、监控告警、回滚。生产集群只做验证过的事。第二条镜像标签永远不要用latest。latest是个移动靶今天拉到的和明天拉到的可能不是一个东西。用版本号或Commit SHA保证可追溯、可回滚。第三条资源限制宁松勿紧。迁移初期对应用的真实资源消耗不清楚limits设太紧会导致频繁OOM和CPU throttling。先设宽松一点观察一周后再收紧。第四条优雅停机时间要给足。默认30秒对大多数应用够用但如果有长连接或大文件处理要延长到60秒甚至120秒。停机时间不够会导致请求被强制中断用户看到502。第五条迁移后第一周要有人值守。新环境总有预料不到的问题第一周安排人盯着监控和告警有问题及时处理。等稳定运行两周后再转入正常运维。第六条文档要同步更新。迁移后应用的部署方式、配置方式、排查方式都变了运维文档、值班手册、应急预案都要更新。我见过迁移半年后出故障值班的人还在翻旧文档按旧流程操作越搞越乱。这套迁移方法我在几个不同规模的项目里用过从十几个服务的小系统到上百个服务的中等规模核心逻辑是通的。区别只在于自动化程度和灰度粒度。小系统可以手工多一些大系统必须全流水线化。但不管规模大小先画像、再改造、后灰度、勤观察这四步一步都不能省。省一步后面就要用双倍的时间来还债。