Kubernetes 核心认知与集群架构（从Docker过渡到K8s）

前言

通过前六篇 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 核心对比表

三、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 完整企业链路

1. Docker：负责底层应用打包，将 Java/Go/Vue 代码打包成标准镜像，是容器的载体
2. Harbor：负责存储 Docker 镜像，统一版本管理、权限管控
3. 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 跑生产，三者缺一不可。