适用场景：已经有Spring Cloud应用，希望迁移到K8s运行，或正在评估微服务平台与容器平台如何协同的团队，可以用这篇文章检查部署边界。
Spring Cloud项目在K8s上的部署实践，核心不是把原来的jar包换成镜像，也不是把启动脚本改成Deployment。真正需要处理的是配置、服务发现、网关、环境隔离、发布验证和可观测体系。否则应用虽然运行在K8s里，故障定位、版本发布和调用治理仍然停留在旧模式。
传统Spring Cloud体系往往已有注册中心、配置中心、网关、熔断限流和链路追踪组件。迁移到K8s后，这些能力不会自动消失，也不应该被简单重复建设。平台团队需要判断哪些能力由Spring Cloud继续承担，哪些能力可以交给K8s、Ingress、服务网格或应用交付平台。
第一步：先梳理应用依赖和运行假设
迁移前先盘点应用依赖。很多Spring Cloud项目依赖注册中心、配置中心、消息队列、数据库、缓存、对象存储和第三方接口，如果只关注应用镜像，迁移后很容易在启动、注册、调用或配置加载阶段失败。
建议先整理以下清单：
- 应用模块、端口、启动参数和健康检查路径
- 注册中心、配置中心和网关的当前使用方式
- 数据库、缓存、消息队列和外部接口依赖
- 不同环境的配置差异和敏感信息来源
- 发布时需要验证的核心接口和调用链路
- 日志、指标、链路追踪和告警接入方式
这一步的目标是把运行假设显性化。哪些配置依赖本地文件，哪些地址写死在配置中，哪些服务调用依赖注册中心，哪些接口必须在发布后立即验证，都应在迁移前明确。
第二步：镜像构建要服务可复现交付
Spring Cloud应用通常已经有打包流程，但容器化之后，构建产物需要进入镜像仓库，并与代码版本、构建号和环境配置解耦。镜像不应包含生产密钥，也不应把不同环境的配置固化进去。
镜像阶段至少要关注：
| 检查项 | 常见风险 | 建议做法 |
| 基础镜像 | 版本漂移和漏洞不可控 | 使用统一基础镜像和扫描流程 |
| 应用包 | 镜像无法追溯源码 | 镜像标签关联提交ID或构建号 |
| 配置 | 配置写进镜像 | 运行时注入配置和Secret |
| 启动参数 | 依赖人工修改 | 通过环境变量或配置对象管理 |
| 日志 | 写本地文件无人采集 | 输出到标准输出或统一目录 |
镜像构建完成后，应能回答两个问题：这个镜像来自哪次代码提交，以及它能否在不同环境以相同方式启动。答不上来，后续回滚和排障会很困难。
第三步：处理配置中心、注册发现和K8s服务发现边界
Spring Cloud项目常见的迁移难点，是原有注册中心与K8s Service之间的边界。部分团队会保留注册中心，让应用仍按原有方式发现服务；也有团队逐步把内部访问迁移到K8s Service或网关治理。两种方式都可以，但不能混乱共存。
建议按阶段推进：
- 短期保留原注册中心，降低迁移风险
- 新服务优先通过K8s Service暴露稳定访问入口
- 网关入口统一纳入Ingress、API网关或服务网格治理
- 配置中心继续承担业务配置，但敏感信息交给Secret或统一密钥体系
- 逐步梳理服务调用路径，避免同一服务出现多套入口
关键不是一次性替换所有组件，而是避免调用路径失控。平台团队应画出调用链路，明确哪些流量走Spring Cloud网关，哪些流量走K8s网关，哪些流量仍依赖注册中心。
第四步：用Deployment表达发布和恢复能力
Spring Cloud应用在K8s里通常用Deployment承载。部署清单不只是声明镜像和副本数，还要表达资源、探针、滚动更新和故障恢复边界。
生产部署至少要包含：
- 资源请求与限制，避免调度和容量评估失真
- Readiness探针，避免未就绪实例接收流量
- Liveness或Startup探针，识别启动卡死和运行异常
- 滚动更新策略，控制发布批次和可用副本
- ConfigMap、Secret和环境变量注入
- 标签和注解，支撑监控、日志和发布追踪
不要只验证Pod Running。Spring Cloud应用可能进程已启动，但配置未加载、注册未完成、下游依赖不可达或关键接口不可用。发布验证应从应用可服务角度出发。
第五步：发布验证要覆盖接口、调用链和指标
迁移到K8s后，发布验证应从人工点页面升级为流水线和可观测体系共同验证。至少要检查应用副本、服务端点、网关路由、核心接口、错误率和调用延迟。
建议验证清单包括：
| 验证维度 | 需要确认的问题 |
| 应用状态 | Pod Ready、重启次数和事件是否正常 |
| 服务入口 | Service、Ingress或网关路由是否可访问 |
| 配置加载 | 环境配置、Secret和配置中心是否生效 |
| 服务调用 | 上下游服务是否能稳定调用 |
| 可观测 | 日志、指标、链路追踪是否可查询 |
| 回滚边界 | 镜像、配置和数据库变更是否可回退 |
这张表的作用是防止“发布成功”只等于Deployment更新成功。真正的成功，是应用能对外服务，关键链路可观察，失败时有明确回滚方案。
常见误区：把Spring Cloud能力和K8s能力重复建设
第一个误区是把K8s当成新的服务器。团队仍然登录容器排障、手工改配置、复制脚本发布，结果没有获得平台化能力。
第二个误区是把Spring Cloud组件全部替换掉。注册中心、配置中心、网关和治理组件是否保留，应根据现有应用规模、迁移风险和团队能力决定，不应为了技术一致性一次性重构。
第三个误区是忽略观测和回滚。微服务调用链复杂，迁移后如果没有日志、指标和链路追踪，排障成本会明显增加。
下一步建议
建议先选择一个依赖清晰、调用链不复杂但能代表真实业务的Spring Cloud服务做试点。试点目标不是证明K8s能运行Java应用，而是验证镜像构建、配置注入、服务发现、网关访问、发布验证、日志指标和回滚流程能否跑通。
完成试点后，把经验沉淀为Spring Cloud上K8s部署模板，包括镜像规范、Deployment模板、配置注入方式、网关接入方式、验证清单和回滚流程。
延伸阅读可以查看应用交付分类，并结合容器化改造和容器化服务设计继续完善微服务迁移后的治理边界。
FAQ
Spring Cloud项目迁移K8s是否必须替换注册中心？
不一定。短期可以保留原注册中心，降低迁移风险；长期是否替换，要看服务规模、调用路径和平台治理目标。关键是明确服务发现边界，避免多套入口混用。
Spring Cloud应用在K8s部署最容易出什么问题？
常见问题包括配置未正确注入、注册中心地址不通、Readiness探针缺失、网关路由错误、日志未采集、下游依赖不可达和回滚边界不清晰。
K8s Service和Spring Cloud服务发现如何选择？
K8s Service适合提供集群内稳定访问入口，Spring Cloud服务发现适合延续已有微服务治理模型。迁移期可以并存，但应明确哪个入口用于哪类调用。
如何判断Spring Cloud迁移到K8s已经成功？
不能只看Pod Running。还要验证核心接口、网关路由、服务调用、配置加载、日志指标、链路追踪和回滚流程。只有这些都通过，才算具备生产运行基础。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：https://www.alauda.cn/blog/471/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
