Kubernetes（K8s）核心知识点

一、前言：K8s 的定位与核心价值

在云原生技术飞速发展的当下，容器化已成为企业应用部署、微服务架构落地的标准范式，而容器编排工具是支撑容器化体系高效运转的核心基础设施。

Kubernetes（简称 K8s）：开源容器集群管理系统的事实标准，凭借强大的自动化、可扩展性和高可用特性，解决了容器大规模部署场景下的部署、扩缩容、故障恢复、服务治理等核心问题，是互联网大厂分布式架构、中小企业云原生转型的必备技术底座。

本文核心：从诞生背景、核心价值出发，拆解设计原理、集群架构与核心工作机制，夯实 K8s 理论基础，为实战应用铺垫。

二、为什么需要 Kubernetes？（诞生背景与必然性）

容器化解决了"一次打包，到处运行"的环境一致性问题，但随着容器数量激增，分布式容器集群的管理难题凸显，K8s 的诞生正是为了破解这些难题。我们从部署模式的演进，理解 K8s 出现的必要性。

2.1 部署模式的三次迭代（核心：平衡资源效率与隔离性）

部署模式	核心实现	优势	致命痛点
传统物理部署	软件直接安装在物理服务器，无额外虚拟化/容器化干预	部署流程简单直接	1. 资源无隔离，应用间资源竞争严重，相互影响；2. 资源无法精细化分配，利用率极低，浪费严重
虚拟化部署（VM）	物理机虚拟化为多个独立虚拟机，每个 VM 有独立OS和硬件分配	实现彻底的资源隔离，解决应用间干扰问题	1. 资源开销大，每个 VM 需运行完整OS，占用大量CPU、内存；2. 启动速度慢，资源无法灵活共享；3. 成本高、效率低，不适应微服务规模快速增长
容器化部署	基于OS内核隔离，所有容器共享主机OS内核，仅封装应用专属资源（文件系统、运行时、依赖库）	1. 资源损耗少、启动快（秒级）、镜像体积小；2. 资源利用率高；3. 隔离性满足绝大多数企业级需求，兼顾效率与隔离	单台主机管理可行，但大规模分布式集群的容器编排难题无法解决

2.2 容器化的核心痛点：容器编排问题

当容器规模扩展到几百、几千个（分布式集群），人工管理无法解决以下问题，即"容器编排难题"：

• 故障恢复：容器崩溃后，如何快速自动重建，避免服务中断？

• 弹性伸缩：业务高峰期/低谷期，如何自动扩缩容容器，优化资源利用？

• 服务发现：多容器、多服务之间，如何自动发现并高效通信？

• 负载均衡：如何将流量均匀分发到多个相同容器实例，避免单容器过载？

• 版本管理：新版本发布出错时，如何快速回退，降低发布风险？

为解决这些问题，容器编排工具（K8s、Swarm、Mesos）应运而生，K8s 凭借完善功能、强扩展性、活跃社区，成为市场主导。

2.3 K8s 的核心能力（一站式解决编排难题）

K8s 核心价值：实现容器集群的自动化部署、自动扩缩容、全生命周期维护，核心功能覆盖所有编排痛点：

• 自我修复：持续监控容器/节点状态，容器崩溃、节点宕机后，1秒左右在健康节点重建实例，确保副本数量符合预期，避免服务中断。

• 弹性伸缩：支持基于CPU、内存使用率的自动伸缩，也可手动触发；高峰期扩容、低谷期缩容，实现资源最优利用。

• 服务发现：内置DNS服务/环境变量，服务无需手动配置访问地址，自动发现依赖服务，解决分布式通信问题。

• 负载均衡：内置负载均衡策略，实现集群内外请求的均匀分发，提升服务稳定性和处理能力。

• 版本管理：支持滚动更新、灰度发布，新版本出错可一键回退，降低发布风险。

• 存储编排：集成各类存储系统（本地存储、云存储、NFS、Ceph），自动创建、挂载、释放存储卷，满足数据持久化需求。

补充：还支持密钥管理、配置管理、命名空间隔离、资源配额等企业级功能，适配全场景容器管理。

三、Kubernetes 核心设计原理

K8s 强大功能的核心的是：科学、解耦的主从架构（Master-Node），将集群分为「控制平面（Master）」和「数据平面（Node）」，二者各司其职、协同工作，组件高度解耦，保障集群高可用和可扩展性。

类比理解：Master = 工厂管理层（决策、调度、监控），Node = 生产车间（执行实际生产任务）。

3.1 集群架构核心：Master 与 Node 的分工

节点类型	核心定位	核心职责	部署要求
Master 节点（控制平面）	集群"大脑"，负责决策与管理	1. 接收用户操作指令；2. 调度容器到合适 Node；3. 监控集群所有资源状态；4. 执行故障恢复、自动扩缩容	至少1个，生产环境需多节点部署（高可用），避免单节点故障导致集群失控
Node 节点（数据平面）	集群"手脚"，容器运行载体	1. 提供容器运行环境；2. 按 Master 指令创建、运行、销毁容器；3. 监控本机容器状态，上报给 Master	数量可灵活扩展（几个到上千个），是集群的计算资源载体

3.2 Master 节点核心组件（4个，各司其职，通过 ApiServer 通信）

• ApiServer（门户）：集群资源操作的唯一入口，所有用户指令（kubectl 操作）、组件间通信，均需通过 ApiServer。同时提供认证、授权、API注册/发现机制，校验请求合法性，保障集群安全。

• Scheduler（调度器）：集群"资源调度员"，仅负责 Pod 调度决策（选择最合适的 Node 节点），不负责实际创建 Pod。根据调度策略（节点资源剩余量、负载、亲和性规则等），为待创建 Pod 选择 Node，并将结果告知 ApiServer。

• ControllerManager（状态守护者）：由多个控制器组成（部署控制器、节点控制器、副本控制器等），核心职责是"维护集群期望状态与实际状态一致"。持续对比两种状态，发现不一致时，自动执行操作（如重建 Pod、调度故障节点的 Pod）。

• Etcd（数据库）：高可用键值对存储系统，集群"数据中心"，存储所有资源对象的配置和状态信息（Pod、Service、Node 等）。仅负责存储，不参与业务逻辑，所有读写操作需通过 ApiServer，保障数据强一致性和高可用。

3.3 Node 节点核心组件（3个，接收指令、执行操作、上报状态）

• Kubelet（通信桥梁）：Node 节点核心组件，持续与 ApiServer 通信，接收下发的指令（创建/停止 Pod、更新容器版本），通过容器运行时执行具体操作；同时监控本机 Pod/容器状态，定时上报给 ApiServer，本地故障先尝试恢复，失败则上报 Master。

• KubeProxy（网络代理）：维护节点网络规则（iptables/ipvs），实现集群内部服务发现和负载均衡。为 Service（Pod 统一入口）转发请求到后端 Pod，屏蔽 Pod IP 动态变化的问题，让服务可通过 Service 名称访问。

• Container runtime（容器执行引擎）：K8s 与容器的底层接口（遵循 CRI 标准），负责镜像管理、Pod/容器的实际运行。常见类型：Docker、containerd、CRI-O。核心工作：拉取镜像、创建/销毁容器、资源隔离，Kubelet 不直接操作容器，通过它完成底层操作。

3.4 K8s 核心工作流程（以部署 Nginx 服务为例）

全流程覆盖"用户指令→服务运行→对外提供访问"，清晰展现组件协同逻辑：

1. 集群初始化：K8s 启动后，Master 和 Node 自动将自身信息（IP、资源、状态）上报 ApiServer，并存入 Etcd，完成集群基础数据准备。

2. 用户发起请求：通过 kubectl 向 ApiServer 发送"部署 Nginx"请求，包含镜像版本、Pod 副本数、端口等配置。

3. 请求校验与存储：ApiServer 完成认证、授权和配置校验，将 Nginx 期望状态存入 Etcd。

4. Pod 调度：ApiServer 触发 Scheduler，Scheduler 读取 Node 状态和 Nginx 配置，选择合适 Node，将调度结果更新到 Etcd。

5. 状态维护：ControllerManager 监控到 Etcd 中的期望状态，触发部署控制器，确保 Pod 创建流程执行。

6. Pod 创建运行：指定 Node 上的 Kubelet 发现自身任务，调用容器运行时，拉取 Nginx 镜像，创建并启动 Pod。

7. 网络配置：ApiServer 创建对应 Service（若配置），KubeProxy 维护网络规则，为 Nginx Pod 配置网络代理，提供统一访问入口。

8. 状态同步：Kubelet 将 Pod 运行状态上报 ApiServer，ApiServer 更新 Etcd，ControllerManager 确认实际状态与期望状态一致，Nginx 服务部署完成并对外提供访问。

3.5 K8s 核心名词解析（必备基础）

核心名词对应 K8s 核心资源对象，是操作和管理集群的基本单元：

• Master：控制节点，集群"大脑"，负责管控和决策，生产环境需高可用部署。

• Node：工作节点，集群"手脚"，接收 Master 任务，提供容器运行环境，是集群计算资源载体。

• Pod：K8s 最小控制和部署单元，容器必须运行在 Pod 中。一个 Pod 可包含1个或多个容器，同一 Pod 内容器共享网络、存储、主机名，可通过 localhost 通信（适用于紧密耦合组件）。

• Controller（控制器）：管理 Pod 的核心组件，定义 Pod 期望状态，实现全生命周期管理。常见类型：Deployment（无状态应用）、StatefulSet（有状态应用）、DaemonSet（每个 Node 一个 Pod）、Job（一次性任务）。

• Service：Pod 对外统一访问入口，维护同一类多个 Pod。提供固定 IP 和域名，屏蔽 Pod IP 动态变化，实现服务持久化访问，内置负载均衡。

• Label（标签）：键值对标识，用于资源分类、标记、关联。无语义，仅用于筛选和分组（如用 app: nginx 标记所有 Nginx Pod）。

• NameSpace（命名空间）：集群资源的逻辑隔离，相当于"虚拟集群"。不同命名空间资源可重名、相互隔离，适用于多团队、多环境（开发/测试/生产）资源管理，避免冲突。

四、核心总结与学习指引

4.1 核心总结

• K8s 核心价值：将分布式容器集群管理从"人工化"推向"自动化、标准化、智能化"，解决容器规模部署后的运维难题，提供稳定、高效、可扩展的云原生应用运行平台。

• 架构精髓：解耦与分工------控制平面（Master）负责决策管理，数据平面（Node）负责实际执行；组件间通过 ApiServer 标准化通信，通过 Etcd 统一存储数据，保障高可用、可扩展、易维护。

• 核心逻辑：以 Pod 为最小单元，通过 Controller 维护期望状态，通过 Service 提供稳定访问，通过 Kubelet、KubeProxy 等组件实现指令执行和网络管控。

4.2 学习指引

• 基础前提：理解 K8s 核心原理和集群架构，是后续集群搭建、应用部署、运维调优的基础，避免机械执行命令，能快速定位和解决问题。

• 学习路径：循序渐进------先掌握理论（架构、组件、名词），再落地实战（集群搭建、应用部署），最后学习高级特性（高可用、调优、监控）。

• 实战衔接：下一篇将讲解基于 CentOS 7 的 K8s 一主多从集群搭建，实现理论落地。

• 重要性：K8s 是云原生时代核心技术，是后端开发、运维、云原生工程师的必备技能。