docker compose 与 kubernetes 是协作而非替代关系：compose 适用于本地开发和简单部署，kubernetes 用于生产级集群编排；可先用 compose 快速验证业务，再分层迁移到 k8s。
用 Docker Compose 快速启动多容器应用，用 Kubernetes 管理生产级集群——两者不是替代关系，而是不同阶段的协作工具。
Docker Compose 适合本地开发和简单部署
Compose 是声明式定义多个容器如何协同工作的工具，通过 docker-compose.yml 文件描述服务、网络、卷等。它不处理跨主机调度、自动扩缩容或高可用，但对调试、CI 测试、小团队交付非常高效。
- 确保已安装 Docker 和 docker-compose（新版 Docker 桌面版自带，Linux 可用
sudo apt install docker-compose-plugin） - 一个典型 docker-compose.yml 至少包含
version、services、networks（可选）、volumes（可选） - 运行
docker compose up -d启动全部服务；docker compose logs -f实时看日志；docker compose down清理环境 - 用
profiles字段区分 dev/test/prod 配置，避免写多份 yml 文件
Kubernetes 是面向分布式生产的编排系统
K8s 解决的是容器在多节点集群中如何可靠运行的问题：自动恢复故障 Pod、滚动更新、服务发现、配置与密钥管理、水平扩缩容等。它抽象层级更高，学习曲线更陡，但不可替代。
- 本地快速体验推荐
kind（Kubernetes in Docker）或minikube，比直接装 kubeadm 更轻量 - 核心对象要理解清楚：
Pod（最小调度单元）、Deployment（管理 Pod 副本）、Service（稳定访问入口）、ConfigMap和Secret（解耦配置） - 不要手写大量 YAML，用
kubectl create deploy nginx --image=nginx --dry-run=client -o yaml > deploy.yaml生成模板再修改 - 用
kubectl port-forward service/myapp 8080:80临时访问集群内服务，比暴露 NodePort 更安全方便
从 Compose 迁移到 Kubernetes 不是重写，而是分层演进
很多团队卡在“要不要上 K8s”的纠结里。其实可以先用 Compose 跑通业务逻辑，再逐步将关键服务迁入 K8s，保留 Compose 给非核心模块或边缘场景使用。
- 把 Compose 的
environment拆成 ConfigMap + Secret；把volumes映射转为 PersistentVolumeClaim - 用
kompose convert工具可将 docker-compose.yml 初步转成 K8s 资源清单，但仅作参考，需人工校验网络策略、健康检查、资源限制等 - 优先迁移有状态服务（如数据库）以外的无状态 Web/API 服务，风险更低
- 监控和日志方案也要同步升级：Prometheus + Grafana 替代
docker stats，Loki + Promtail 替代docker logs
实战建议：别跳过基础，但别困在 YAML 里
真正卡住人的往往不是命令记不住，而是对“为什么这样设计”没感觉。动手前花 20 分钟画个架构草图：哪些组件需要高可用？流量怎么进来？配置哪里来？数据存在哪？问题就清晰了。
- 新手先跑通一个 Nginx + Redis + Python Flask 的三容器 Compose 应用，再把它拆成 K8s 的三个 Deployment + Service
- 用
kubectl get all -n default和kubectl describe pod xxx养成排查习惯，比盲目改 YAML 有效得多 - 生产环境务必设置
resources.requests/limits和livenessProbe/readinessProbe，否则调度器无法合理分配资源，服务也可能假死不自愈 - CI/CD 流水线里，Compose 用于测试环境构建验证，K8s manifests 用 Helm 或 Kustomize 管理，避免硬编码
