Docker Compose与Kubernetes是协作关系而非替代：Compose专注本地开发与验证，K8s承担生产部署与治理；应以Compose文件为唯一事实来源，通过Kompose自动转换、健康检查对齐和Compose on Kubernetes渐进式上线实现平滑迁移。
用 Docker Compose 配合 Kubernetes 实现平滑迁移，关键不是“先删掉再重写”，而是让两者在不同阶段各司其职：Compose 专注本地开发与验证，Kubernetes 承担生产部署与治理。真正可行的路径是分层过渡，而不是硬切。
保留 Compose 文件作为源定义
不要急于把 docker-compose.yml 全部手写成 Kubernetes YAML。它本就是一份清晰的服务拓扑描述，可作为唯一事实来源（source of truth）。后续所有转换都应基于它生成，而非人工维护两套配置。这样能避免环境不一致、更新遗漏等问题。
- 确保 Compose 文件使用 v3.8 或更高版本，兼容性更好
- 剥离硬编码的本地路径（如 ./config），改用 config volume + external secrets 引用方式，便于后续映射到 ConfigMap/Secret
- 为每个服务显式定义 healthcheck，这是迁移到 K8s 探针的直接依据
用 Kompose 做自动化初转
Kompose 是最轻量、最贴近实际工程节奏的起点工具。它不追求 100% 覆盖，但能覆盖 80% 的基础资源（Deployment、Service、ConfigMap、PVC），大幅减少手动工作量。
- 运行 kompose convert -f docker-compose.yml，生成一组 Kubernetes 原生 YAML
- 生成的 service 默认是 ClusterIP，如需外部访问，手动加 type: NodePort 或后续配 Ingress
- 注意检查 volumes：本地路径会转成 emptyDir 或 PVC 模板，需按生产需求替换为真实存储类（StorageClass）
用 Compose on Kubernetes 实现渐进式上线
如果你希望零改造就跑上 K8s，Compose on Kubernetes（也叫 Docker Stack on K8s）是更平滑的选择。它不是替代 Kubernetes，而是把 Compose 当作一层声明式 API 输入，由后端 Controller 自动翻译并托管。
- 安装 Compose API Server 和 Controller 后，直接运行 docker stack deploy -c docker-compose.yml myapp
- 整个栈被当作一个 “Stack” CRD 管理，支持滚动更新、状态聚合、事件追踪
- 适合灰度迁移：部分服务继续走原 Compose，新模块或高负载服务优先接入该方案，逐步收口
健康检查与探针对齐是稳定性核心
很多迁移后服务反复重启，问题常出在 readiness/liveness 探针没对齐原有健康逻辑。别跳过这步校验。
- 将 Compose 中的 healthcheck.test 映射为 K8s 的 exec 或 httpGet 探针
- 特别注意 start_period → initialDelaySeconds：数据库等慢启动服务必须设足够延迟，否则 Pod 还没起来就被 kill
- 建议初期保留 exec 探针（如 curl -f http://localhost/health），等稳定后再优化为更轻量的 TCP 或自定义 HTTP 端点
不复杂但容易忽略：迁移不是技术切换，而是协作模式升级。Compose 负责“我怎么写清楚”，Kubernetes 负责“我怎么稳稳跑好”，中间靠工具链和规范对齐来衔接。
