文章目录
-
- 前言
- [一、彻底厘清：Docker Compose 为什么不能上生产？](#一、彻底厘清：Docker Compose 为什么不能上生产？)
-
- [1.1 Docker Compose 核心局限性](#1.1 Docker Compose 核心局限性)
- [1.2 企业技术分工（必考认知）](#1.2 企业技术分工（必考认知）)
- [二、K8s 是什么？核心作用与企业价值](#二、K8s 是什么？核心作用与企业价值)
-
- [2.1 什么是 Kubernetes？](#2.1 什么是 Kubernetes？)
- [2.2 K8s 专门解决的生产痛点](#2.2 K8s 专门解决的生产痛点)
- [2.3 Compose vs K8s 核心对比表](#2.3 Compose vs K8s 核心对比表)
- [三、K8s 整体集群架构（通俗详解）](#三、K8s 整体集群架构（通俗详解）)
-
- [3.1 两大核心角色](#3.1 两大核心角色)
-
- [1、Master 节点（控制平面）](#1、Master 节点（控制平面）)
- [2、Node 节点（工作平面）](#2、Node 节点（工作平面）)
- [3.2 架构核心总结（必背）](#3.2 架构核心总结（必背）)
- [四、K8s 四大核心资源（入门重中之重）](#四、K8s 四大核心资源（入门重中之重）)
-
- [4.1 Pod：K8s 最小运行单元](#4.1 Pod：K8s 最小运行单元)
- [4.2 Deployment：无状态服务部署控制器](#4.2 Deployment：无状态服务部署控制器)
- [4.3 Service：服务网络与负载均衡](#4.3 Service：服务网络与负载均衡)
- [4.4 YAML：资源声明式配置文件](#4.4 YAML：资源声明式配置文件)
- [五、Docker 与 K8s 企业联动终极解答](#五、Docker 与 K8s 企业联动终极解答)
-
- [5.1 完整企业链路](#5.1 完整企业链路)
- [5.2 一句话总结](#5.2 一句话总结)
- 六、总结
前言
通过前六篇 Docker 系列教程，我们已经完整掌握了容器开发的全套基础能力：Docker 镜像制作、容器运行、数据持久化、网络配置、Docker Compose 多容器编排、Harbor 私有镜像仓库搭建与镜像管理。
到这里，很多同学会产生一个疑问：既然 Docker Compose 已经能一键启动多容器、统一管理开发环境，为什么企业生产环境还要用复杂的 K8s？
这也是新手学习容器技术最大的误区：混淆「开发环境」和「生产环境」的技术选型。
我们前面学的 Docker + Compose + Harbor，完全适配本地开发、单机测试场景，但完全无法应对企业线上生产的核心需求：高可用、容灾自愈、弹性扩容、集群调度、滚动更新、灰度发布。
所以，容器技术的学习必须完成最后一块核心拼图：Kubernetes（简称 K8s）。
本篇作为 K8s 入门第一篇，带你彻底搞懂 K8s 核心价值、技术定位、集群架构、核心概念，清晰区分 Docker Compose 与 K8s 的企业分工，为后续 K8s 实操、企业 CI/CD 自动化部署打下坚实基础。
一、彻底厘清：Docker Compose 为什么不能上生产？
先明确核心结论：Docker Compose 只适合单机开发/测试，绝对不适合生产环境。
我们结合企业真实生产场景，拆解 Compose 的致命短板，这也是 K8s 存在的核心意义。
1.1 Docker Compose 核心局限性
- 仅限单机运行：Compose 所有服务只能运行在一台服务器上，无法搭建集群，服务器宕机则整套服务全部瘫痪，无任何容灾能力。
- 无自愈能力：容器崩溃后，Compose 仅能通过 restart 策略重启容器，无法自动调度、迁移服务，也无法补偿实例。
- 无弹性扩容：业务流量暴涨时，无法自动新增容器实例分担压力，只能手动修改配置重启服务。
- 发布风险极高：更新服务只能停止重建，存在服务中断时间，不支持滚动更新、灰度发布，无法满足线上 7*24 小时不间断服务需求。
- 无资源调度能力：无法监控服务器 CPU、内存资源，不能合理分配容器运行节点，极易出现资源闲置或过载问题。
1.2 企业技术分工（必考认知）
至此，我们可以敲定企业容器技术标准分工体系，适配 99% 互联网公司：
- 本地开发环境：Docker + Docker Compose（轻量、快速、简单高效）
- 镜像存储管理：Docker + Harbor（统一打包、私有存储、版本管控）
- 线上生产环境：K8s 集群编排（高可用、自愈、扩容、不停机发布）
二、K8s 是什么？核心作用与企业价值
2.1 什么是 Kubernetes？
Kubernetes 是 Google 基于 Borg 系统开源的容器集群编排管理平台，是目前容器 orchestration（编排）领域的行业标准、事实王者。
通俗大白话解释：
Docker 负责把应用打包成镜像、运行单个容器；K8s 负责管理成千上万台服务器上的成千上万个 Docker 容器。
2.2 K8s 专门解决的生产痛点
所有功能都是为生产高可用、高并发、高稳定量身打造：
- 故障自愈：容器崩溃、节点宕机，自动重启、自动迁移服务，业务无感知
- 弹性扩缩容：流量高峰期自动增加容器实例，低峰期自动缩减，节省服务器资源
- 不停机发布：支持滚动更新、灰度发布、版本回滚，线上服务零中断更新
- 集群调度：自动监控集群资源，智能将容器调度到资源充足的服务器
- 负载均衡：内置集群负载均衡，自动分发流量到多个服务实例
2.3 Compose vs K8s 核心对比表
| 对比维度 | Docker Compose | Kubernetes |
|---|---|---|
| 运行架构 | 单机架构 | 分布式集群架构 |
| 适用环境 | 开发、测试、单机小项目 | 企业生产、大规模集群 |
| 自愈能力 | 弱，仅支持容器重启 | 强，节点/容器故障自动迁移恢复 |
| 扩容能力 | 手动扩容，无自动机制 | 支持自动弹性扩缩容 |
| 发布方式 | 停机更新，有服务中断 | 滚动更新，零停机发布 |
| 运维难度 | 极低，开箱即用 | 较高，功能强大、配置规范 |
三、K8s 整体集群架构（通俗详解）
K8s 是典型的主从架构（Master + Node） ，整个集群分为控制平面和工作节点两大部分，新手无需死记硬背，理解分工即可。
3.1 两大核心角色
1、Master 节点（控制平面）
集群的「大脑」，不运行业务容器，只负责管理、调度、管控整个集群，统一指挥所有工作节点。
Master 包含 4 个核心组件：
- kube-apiserver：集群统一入口，所有操作命令（创建、删除、更新服务）都通过它接收处理，是 K8s 的网关
- kube-controller-manager：控制器管理器，负责监控集群状态，实现故障自愈、实例数量维持
- kube-scheduler：调度器，负责将新的容器任务，智能分配到资源充足的 Node 节点
- etcd：集群数据库，存储集群所有配置、状态数据，是 K8s 的核心存储
2、Node 节点（工作平面）
集群的「干活小弟」，真正运行业务容器，所有项目服务、中间件容器都运行在 Node 节点上。
每个 Node 节点都包含 3 个必备组件：
- kubelet：节点代理，接收 Master 指令，管理当前节点的所有 Pod（容器组）
- kube-proxy：网络代理，负责节点网络转发、负载均衡，实现服务互通、外网访问
- container runtime：默认 Docker，负责真正拉取镜像、启动、停止容器（核心！这就是 Docker 和 K8s 的联动点）
3.2 架构核心总结（必背）
- Master：管调度、管管理、不管业务
- Node：跑业务、跑容器、接受 Master 管理
- Docker：K8s 的容器运行底层依赖，负责容器生命周期
四、K8s 四大核心资源（入门重中之重）
K8s 所有操作都是围绕「资源对象」实现，新手先吃透 4 个最核心、最常用的资源，覆盖 95% 日常开发部署场景。
4.1 Pod：K8s 最小运行单元
Pod 是 K8s 中最小、最基本的部署单元。
通俗理解：
- 一个 Pod 可以包含一个或多个 Docker 容器
- K8s 不直接管理容器，只管理 Pod
- 同一 Pod 内的容器共享网络、存储，本地互通
企业规范：一个 Pod 只跑一个业务容器，结构清晰、方便运维。
4.2 Deployment：无状态服务部署控制器
Pod 本身是临时性、易销毁的，单独创建的 Pod 崩溃后不会自动恢复。
Deployment 是用来管理 Pod 的控制器，企业 99% 的业务服务都通过它部署。
核心能力：
- 指定 Pod 运行副本数，保证服务实例数量稳定
- Pod 崩溃、节点宕机，自动重建 Pod，实现自愈
- 支持滚动更新、版本回滚、扩容缩容
4.3 Service：服务网络与负载均衡
每个 Pod 的 IP 是动态变化的，重启后 IP 会改变，无法直接对外提供稳定访问。
Service 的作用就是：给一组 Pod 提供固定访问入口 + 负载均衡。
无论后端 Pod 如何重启、迁移、扩容，访问地址永远不变，彻底解决动态 IP 失联问题。
4.4 YAML：资源声明式配置文件
和 Docker Compose 一致，K8s 所有资源创建、配置，全部通过 YAML 文件声明。
优势：配置标准化、可版本控制、可复用、团队统一，适配自动化部署。
五、Docker 与 K8s 企业联动终极解答
这里解答所有开发者的终极疑惑：有了 K8s，Docker 是不是没用了？
答案：完全不是，二者是上下级、互补关系，不是替代关系。
5.1 完整企业链路
- Docker：负责底层应用打包，将 Java/Go/Vue 代码打包成标准镜像，是容器的载体
- Harbor：负责存储 Docker 镜像，统一版本管理、权限管控
- K8s：负责拉取 Harbor 镜像，调度、运行、维护容器，保障线上高可用
5.2 一句话总结
Docker 负责造容器、跑容器；K8s 负责管容器、管集群、管服务稳定性。
六、总结
1、Docker Compose 仅限单机开发测试使用，因无集群、自愈、扩容、零停机发布能力，无法用于企业生产环境；
2、K8s 是企业生产级容器编排标准，核心解决集群高可用、故障自愈、弹性扩缩容、不停机发布等线上核心问题；
3、K8s 采用 Master+Node 主从架构，Master 管控集群，Node 运行业务容器，Docker 作为底层运行时支撑 K8s 容器启动；
4、K8s 入门核心四要素：Pod、Deployment、Service、YAML，是后续所有实操的基础；
5、企业标准技术栈：Docker 打包 + Harbor 存镜像 + K8s 跑生产，三者缺一不可。