IT策士 10余年一线大厂经验专注 IT 思维、架构、职场进阶。我会在各个平台持续发布最新文章助你少走弯路。18 篇文章从第一行docker run hello-world到能够用 Compose 编排 WordPress MySQL 这样的完整应用栈。你亲手经历了编写 Dockerfile 把应用打成镜像用 Volume 实现数据持久化用自定义网络让容器互访用 Compose 一键启停多服务用健康检查和depends_on控制启动顺序用多文件和环境变量实现多环境切换。现在我们要迈出整个系列中最重要的一步从单机编排走向集群编排从 Docker Compose 走向 Kubernetes。这也是我们整个大纲的分水岭——前 18 篇是基础后 32 篇是核心。这篇文章不是教你具体的 K8s 命令而是帮你建立概念映射。当你理解了 Compose 中的每一个概念在 K8s 中对应什么、为什么这样设计你后续的学习就不再是“从零开始”而是“在已有的认知框架上叠加新知识”。一、从第 1 篇到第 17 篇我们究竟掌握了什么先快速回顾一下我们走过的完整技术演进路线这能帮你锚定当前所处的位置。阶段一单容器第 1-6 篇——让应用跑起来我们学会了用 Dockerfile 构建镜像管理容器的生命周期配置重启策略和健康检查。核心价值是让单机应用具备了可移植性——不再有“我机器上能跑你机器上不行”的问题。阶段二多容器手动编排第 7-10 篇——让多个服务协同工作我们引入了 Volume 做数据持久化容器删了数据还在通过自定义网络让容器之间互访手动创建网络和卷来启动 Flask Redis 应用。用脚本把多个手动命令串起来但仍然是“过程式”的——需要告诉机器每一步怎么做。阶段三声明式单机编排第 11-17 篇——用 YAML 描述期望状态Compose 的核心突破在于你不再需要告诉 Docker“怎么做”先创建网络再启动 Redissleep 3 秒再启动 Flask而是用 YAML 描述“我想要什么”两个服务、一个网络、两个卷、Redis 健康后启动 Flask。Compose 自己决定执行顺序。环境变量和多文件组合进一步实现了“同一份描述适配多套环境”。二、Compose 的能力边界为什么需要 KubernetesCompose 已经很好用了但它有一个根本性的局限Compose 只能管理单台宿主机上的容器。现实世界中的生产环境可不止一台机器。当你的应用需要跨多台服务器部署、需要在流量突增时自动扩容、需要在某台服务器宕机时自动迁移容器、需要灰度发布让 10% 的用户先体验新版本、需要按服务粒度控制网络隔离——这些需求全都指向一个事实你需要一个跨主机的容器编排平台。以下是 Compose 无法解决的核心生产需求三、概念映射Compose 的每件事K8s 都是谁在做你现在脑海中的 Compose 模型是这样的docker-compose.yml里定义了几个services每个 service 有一些environment、volumes、ports通过networks互通通过depends_on控制启动顺序。在 K8s 中这些概念被拆解为更细粒度的“对象”各司其职。下面这张对照表是你从 Compose 到 K8s 的“概念翻译词典”关键思维转换在 Compose 中docker compose up -d是直接操作容器——创建、启动、连接网络。在 K8s 中kubectl apply -f是把 YAML 提交到 API Server然后控制器Controller在后台持续工作确保集群的实际状态与你声明的一致。你不再直接对容器下命令而是告诉 K8s “我要 3 个副本”控制循环自己会去创建、监控、修复。四、同一个应用两种声明方式拿我们最熟悉的 Flask Redis 计数器应用来看Compose 和 K8s 的表达方式有什么异同。Compose 版本你已经熟悉的services: redis: image: redis:alpine volumes: - redis-data:/data networks: - app-net healthcheck: test:[CMD,redis-cli,ping]flask-app: image: flask-redis-counter:2.0 ports: -5000:5000environment: -REDIS_HOSTredis networks: - app-net depends_on: redis: condition: service_healthy volumes: redis-data: networks: app-net:K8s 版本你现在可以先看懂大意# Redis DeploymentapiVersion: apps/v1 kind: Deployment metadata: name: redis spec: replicas:1selector: matchLabels: app: redis template: metadata: labels: app: redis spec: containers: - name: redis image: redis:alpine ports: - containerPort:6379volumeMounts: - name: redis-data mountPath: /data volumes: - name: redis-data persistentVolumeClaim: claimName: redis-pvc ---# Flask DeploymentapiVersion: apps/v1 kind: Deployment metadata: name: flask-app spec: replicas:2selector: matchLabels: app: flask-app template: metadata: labels: app: flask-app spec: containers: - name: flask-app image: flask-redis-counter:2.0 ports: - containerPort:5000env: - name: REDIS_HOST value: redis-service ---# ServicesapiVersion: v1 kind: Service metadata: name: redis-service spec: selector: app: redis ports: - port:6379--- apiVersion: v1 kind: Service metadata: name: flask-service spec: type: NodePort selector: app: flask-app ports: - port:5000nodePort:30080核心差异一览K8s 的 YAML 看起来更长因为它把每个关注点调度、网络、存储、配置都拆成了独立的对象。这种拆解初看增加了复杂度但它带来了更精细的控制能力——你可以独立地更新网络策略而不碰 Deployment可以单独扩容某个服务而不影响其他配置。这种“关注点分离”是 K8s 应对大规模集群管理的核心设计思想。五、从“手动管理”到“控制器驱动”思维方式的根本转变理解 Compose 和 K8s 的区别最关键的不是记住对象名称的对应关系而是理解管理模式的差异。Compose 的思维模型你发出一条命令docker compose up -dDocker 同步执行一系列操作创建网络、创建卷、启动容器执行完毕返回结果。这是命令式 同步的模式——你告诉 Docker “做这个”Docker 做完之后告诉你结果。K8s 的思维模型你用kubectl apply -f提交一份 YAML 到 API ServerK8s 的控制器组件如 Deployment Controller、ReplicaSet Controller在后台异步工作持续监控集群状态一旦发现“实际运行的 Pod 数量不等于你声明的 replicas”就自动创建或删除 Pod。这是声明式 异步的模式——你告诉 K8s “我想要这样”K8s 不断地自我调整直到达成目标。这一转变带来的好处是巨大的你不再需要写脚本处理“如果容器挂了怎么办”、“如果节点宕机了怎么办”——K8s 的控制循环会自动处理这些故障。你只需要声明期望状态剩下的交给平台。六、系列第三部分预告Kubernetes 核心全景从第 19 篇开始我们将正式进入 Kubernetes 核心的系统学习。以下是后续 20 篇的路线图第 19-20 篇入门与实验环境。先整体理解 K8s 架构控制平面、工作节点、核心组件然后动手搭建 Minikube 本地集群安装 kubectl跑通第一个 Pod。第 21-27 篇Pod 与控制器。深入 Pod 的 YAML 结构、生命周期、多容器设计模式Sidecar再掌握 Deployment、DaemonSet、Job/CronJob 等控制器的使用。第 28-31 篇网络与服务发现。学习 ServiceClusterIP/NodePort/LoadBalancer、Ingress域名路由、TLS、以及 K8s DNS 解析机制。第 32-33 篇配置管理。ConfigMap 与 Secret 的创建、挂载、更新策略。第 34-38 篇存储、资源与安全。PV/PVC/StorageClass 动态供应Requests 与 Limits 资源管理亲和性调度RBAC 权限控制。学完这 20 篇你就能独立把一个应用从 Docker 镜像变成 K8s 集群上可运维的服务。然后再进入第四部分第 39-50 篇的生产级生态——Helm、监控、日志、CI/CD、服务网格。七、本篇总结这篇文章的核心目的是在你头脑中建立一张“概念映射表”让你带着 Compose 的经验进入 K8s 时不会感到陌生。几个关键要点Compose 管理单机容器K8s 管理跨主机集群——这是两者最根本的能力差异。Compose 的 service → K8s 的 Deployment Pod Service——原本一个 service 承载的所有职责在 K8s 中被拆解为多个独立对象各司其职。Compose 的环境变量 → K8s 的 ConfigMap / Secret——配置与镜像解耦的思想一致但 K8s 提供了更安全的敏感信息管理。Compose 的 volumes → K8s 的 PV/PVC/StorageClass——持久化存储的声明式管理K8s 实现了真正的“动态供应”。命令式 vs 声明式Compose 是“你下命令Docker 执行”K8s 是“你声明期望状态控制器持续调和”——这是思维方式的根本转变。从下一篇开始我们将正式学习 Kubernetes 的架构和核心组件动手搭建实验集群。想了解更多还可以去各个平台搜索「IT策士」一起升级 IT 思维
Docker 从 0 到 1 再到 Kubernetes 实战：第18篇 从 Docker Compose 到 Kubernetes 的思考
IT策士 10余年一线大厂经验专注 IT 思维、架构、职场进阶。我会在各个平台持续发布最新文章助你少走弯路。18 篇文章从第一行docker run hello-world到能够用 Compose 编排 WordPress MySQL 这样的完整应用栈。你亲手经历了编写 Dockerfile 把应用打成镜像用 Volume 实现数据持久化用自定义网络让容器互访用 Compose 一键启停多服务用健康检查和depends_on控制启动顺序用多文件和环境变量实现多环境切换。现在我们要迈出整个系列中最重要的一步从单机编排走向集群编排从 Docker Compose 走向 Kubernetes。这也是我们整个大纲的分水岭——前 18 篇是基础后 32 篇是核心。这篇文章不是教你具体的 K8s 命令而是帮你建立概念映射。当你理解了 Compose 中的每一个概念在 K8s 中对应什么、为什么这样设计你后续的学习就不再是“从零开始”而是“在已有的认知框架上叠加新知识”。一、从第 1 篇到第 17 篇我们究竟掌握了什么先快速回顾一下我们走过的完整技术演进路线这能帮你锚定当前所处的位置。阶段一单容器第 1-6 篇——让应用跑起来我们学会了用 Dockerfile 构建镜像管理容器的生命周期配置重启策略和健康检查。核心价值是让单机应用具备了可移植性——不再有“我机器上能跑你机器上不行”的问题。阶段二多容器手动编排第 7-10 篇——让多个服务协同工作我们引入了 Volume 做数据持久化容器删了数据还在通过自定义网络让容器之间互访手动创建网络和卷来启动 Flask Redis 应用。用脚本把多个手动命令串起来但仍然是“过程式”的——需要告诉机器每一步怎么做。阶段三声明式单机编排第 11-17 篇——用 YAML 描述期望状态Compose 的核心突破在于你不再需要告诉 Docker“怎么做”先创建网络再启动 Redissleep 3 秒再启动 Flask而是用 YAML 描述“我想要什么”两个服务、一个网络、两个卷、Redis 健康后启动 Flask。Compose 自己决定执行顺序。环境变量和多文件组合进一步实现了“同一份描述适配多套环境”。二、Compose 的能力边界为什么需要 KubernetesCompose 已经很好用了但它有一个根本性的局限Compose 只能管理单台宿主机上的容器。现实世界中的生产环境可不止一台机器。当你的应用需要跨多台服务器部署、需要在流量突增时自动扩容、需要在某台服务器宕机时自动迁移容器、需要灰度发布让 10% 的用户先体验新版本、需要按服务粒度控制网络隔离——这些需求全都指向一个事实你需要一个跨主机的容器编排平台。以下是 Compose 无法解决的核心生产需求三、概念映射Compose 的每件事K8s 都是谁在做你现在脑海中的 Compose 模型是这样的docker-compose.yml里定义了几个services每个 service 有一些environment、volumes、ports通过networks互通通过depends_on控制启动顺序。在 K8s 中这些概念被拆解为更细粒度的“对象”各司其职。下面这张对照表是你从 Compose 到 K8s 的“概念翻译词典”关键思维转换在 Compose 中docker compose up -d是直接操作容器——创建、启动、连接网络。在 K8s 中kubectl apply -f是把 YAML 提交到 API Server然后控制器Controller在后台持续工作确保集群的实际状态与你声明的一致。你不再直接对容器下命令而是告诉 K8s “我要 3 个副本”控制循环自己会去创建、监控、修复。四、同一个应用两种声明方式拿我们最熟悉的 Flask Redis 计数器应用来看Compose 和 K8s 的表达方式有什么异同。Compose 版本你已经熟悉的services: redis: image: redis:alpine volumes: - redis-data:/data networks: - app-net healthcheck: test:[CMD,redis-cli,ping]flask-app: image: flask-redis-counter:2.0 ports: -5000:5000environment: -REDIS_HOSTredis networks: - app-net depends_on: redis: condition: service_healthy volumes: redis-data: networks: app-net:K8s 版本你现在可以先看懂大意# Redis DeploymentapiVersion: apps/v1 kind: Deployment metadata: name: redis spec: replicas:1selector: matchLabels: app: redis template: metadata: labels: app: redis spec: containers: - name: redis image: redis:alpine ports: - containerPort:6379volumeMounts: - name: redis-data mountPath: /data volumes: - name: redis-data persistentVolumeClaim: claimName: redis-pvc ---# Flask DeploymentapiVersion: apps/v1 kind: Deployment metadata: name: flask-app spec: replicas:2selector: matchLabels: app: flask-app template: metadata: labels: app: flask-app spec: containers: - name: flask-app image: flask-redis-counter:2.0 ports: - containerPort:5000env: - name: REDIS_HOST value: redis-service ---# ServicesapiVersion: v1 kind: Service metadata: name: redis-service spec: selector: app: redis ports: - port:6379--- apiVersion: v1 kind: Service metadata: name: flask-service spec: type: NodePort selector: app: flask-app ports: - port:5000nodePort:30080核心差异一览K8s 的 YAML 看起来更长因为它把每个关注点调度、网络、存储、配置都拆成了独立的对象。这种拆解初看增加了复杂度但它带来了更精细的控制能力——你可以独立地更新网络策略而不碰 Deployment可以单独扩容某个服务而不影响其他配置。这种“关注点分离”是 K8s 应对大规模集群管理的核心设计思想。五、从“手动管理”到“控制器驱动”思维方式的根本转变理解 Compose 和 K8s 的区别最关键的不是记住对象名称的对应关系而是理解管理模式的差异。Compose 的思维模型你发出一条命令docker compose up -dDocker 同步执行一系列操作创建网络、创建卷、启动容器执行完毕返回结果。这是命令式 同步的模式——你告诉 Docker “做这个”Docker 做完之后告诉你结果。K8s 的思维模型你用kubectl apply -f提交一份 YAML 到 API ServerK8s 的控制器组件如 Deployment Controller、ReplicaSet Controller在后台异步工作持续监控集群状态一旦发现“实际运行的 Pod 数量不等于你声明的 replicas”就自动创建或删除 Pod。这是声明式 异步的模式——你告诉 K8s “我想要这样”K8s 不断地自我调整直到达成目标。这一转变带来的好处是巨大的你不再需要写脚本处理“如果容器挂了怎么办”、“如果节点宕机了怎么办”——K8s 的控制循环会自动处理这些故障。你只需要声明期望状态剩下的交给平台。六、系列第三部分预告Kubernetes 核心全景从第 19 篇开始我们将正式进入 Kubernetes 核心的系统学习。以下是后续 20 篇的路线图第 19-20 篇入门与实验环境。先整体理解 K8s 架构控制平面、工作节点、核心组件然后动手搭建 Minikube 本地集群安装 kubectl跑通第一个 Pod。第 21-27 篇Pod 与控制器。深入 Pod 的 YAML 结构、生命周期、多容器设计模式Sidecar再掌握 Deployment、DaemonSet、Job/CronJob 等控制器的使用。第 28-31 篇网络与服务发现。学习 ServiceClusterIP/NodePort/LoadBalancer、Ingress域名路由、TLS、以及 K8s DNS 解析机制。第 32-33 篇配置管理。ConfigMap 与 Secret 的创建、挂载、更新策略。第 34-38 篇存储、资源与安全。PV/PVC/StorageClass 动态供应Requests 与 Limits 资源管理亲和性调度RBAC 权限控制。学完这 20 篇你就能独立把一个应用从 Docker 镜像变成 K8s 集群上可运维的服务。然后再进入第四部分第 39-50 篇的生产级生态——Helm、监控、日志、CI/CD、服务网格。七、本篇总结这篇文章的核心目的是在你头脑中建立一张“概念映射表”让你带着 Compose 的经验进入 K8s 时不会感到陌生。几个关键要点Compose 管理单机容器K8s 管理跨主机集群——这是两者最根本的能力差异。Compose 的 service → K8s 的 Deployment Pod Service——原本一个 service 承载的所有职责在 K8s 中被拆解为多个独立对象各司其职。Compose 的环境变量 → K8s 的 ConfigMap / Secret——配置与镜像解耦的思想一致但 K8s 提供了更安全的敏感信息管理。Compose 的 volumes → K8s 的 PV/PVC/StorageClass——持久化存储的声明式管理K8s 实现了真正的“动态供应”。命令式 vs 声明式Compose 是“你下命令Docker 执行”K8s 是“你声明期望状态控制器持续调和”——这是思维方式的根本转变。从下一篇开始我们将正式学习 Kubernetes 的架构和核心组件动手搭建实验集群。想了解更多还可以去各个平台搜索「IT策士」一起升级 IT 思维
