Linux容器部署项目教程_DockerComposeKubernetes整合实践

Docker Compose 与 Kubernetes 的平滑迁移关键在于配置复用、环境一致性和分层抽象：Compose 分基础与业务服务、统一环境变量；K8s 迁移用 Kompose 转换后优化镜像、存储和密钥；CI/CD 实现一次构建多环境部署；日志、探针和监控需贯穿始终。

用 Docker Compose 快速启动本地开发环境，再平滑迁移到 Kubernetes 生产集群，是当前主流的容器化落地路径。关键不在于堆砌 工具，而在于配置复用、环境一致性和分层抽象。

一、Docker Compose：写好 docker-compose.yml 就等于搭好脚手架

Compose 文件不是越复杂越好，而是要贴近实际服务依赖关系。建议按“基础服务 + 业务服务”分块组织，用 extends 或 profiles 控制启停组合（如 dev-only 的 mock 服务），避免一个文件里塞满所有环境逻辑。

常见做法：

• 把数据库、Redis、Nginx 等基础设施服务单独抽成 docker-compose.infra.yml
• 业务服务用 build: context 指向项目根目录，配合 .dockerignore 排除 node_modules、.git 等冗余内容
• 环境变量 统一从 .env 加载，敏感信息用 secrets 或外部 vault 工具注入，不硬 编码

二、Kubernetes 迁移：别重写 YAML，用 Kompose 或 Helm 做转换起点

Docker Compose 和 Kubernetes 的语义差异大，但结构可映射。Kompose 能把 docker-compose.yml 自动生成 Deployment、Service、ConfigMap，虽然不能直接上生产，但能快速生成初版资源清单，省去手动翻译时间。

更推荐的做法是：

• 用 Kompose 输出基础 YAML 后，立即替换掉 image 为私有镜像仓库地址（如 harbor.example.com/app/web:v1.2）
• 把 Compose 中的 volumes 改为 PersistentVolumeClaim，并提前创建对应 StorageClass
• 将 environment 拆成 ConfigMap + Secret，Secret 用 kubectl create secret generic --from-file= 导入

三、CI/CD 流水线中打通两者：一次构建，多环境部署

核心原则是镜像不变、配置分离。在 CI 阶段只做一件事：构建镜像并推送到仓库。后续部署阶段才根据目标环境（dev/staging/prod）加载不同配置。

典型流程：

• Git Push 触发 CI，执行 docker build -t $IMAGE_TAG . → docker push $IMAGE_TAG
• Dev 环境用 docker-compose up -f docker-compose.dev.yml 快速验证
• Prod 环境用 kubectl apply -k overlays/prod/（基于 Kustomize）或 helm upgrade --install app ./chart --namespace prod

四、调试与可观测性：日志、网络、状态缺一不可

容器跑起来只是开始，出问题时得快速定位。本地用 Compose 可直接 docker-compose logs -f web；K8s 上则需习惯 kubectl logs -n myapp deploy/web 或 kubectl port-forward svc/web 8080:80 临时调试。

建议上线前就集成：

• 标准日志输出到 stdout/stderr（不要写文件），方便采集
• 每个 Pod 加 livenessProbe 和 readinessProbe，比如 HTTP GET /healthz
• 用 Prometheus + Grafana 抓取 cAdvisor 和应用自定义指标，对比 Compose 本地压测数据判断性能拐点

不复杂但容易忽略。