Kubernetes 核心概念：集群架构、核心组件与资源对象

九皇叔叔2026-09-18 22:08

Kubernetes 核心概念：集群架构、核心组件与资源对象

Kubernetes 核心概念：集群架构、核心组件与资源对象

Kubernetes 是一个用于管理容器化应用的容器编排平台。理解 Kubernetes，首先需要建立一个整体认识：Kubernetes 并不是直接管理应用程序，而是通过管理 Pod，间接管理 Pod 中运行的容器，最终实现对应用程序的管理。

从整体架构来看，一个 Kubernetes 集群主要由 控制节点（Master） 和 工作节点（Node） 两部分组成。控制节点负责整个集群的管理、决策和调度，工作节点负责真正运行应用。

Kubernetes 集群整体架构

一个 Kubernetes 集群可以简单理解为：

其中：

  • Master：负责整个集群的控制和管理。
  • Node：负责运行 Pod 和其中的容器。

可以把 Master 理解成 Kubernetes 集群的"大脑"，Node 则是实际完成工作的"执行节点"。

Master 节点核心组件

Master 是 Kubernetes 的控制平面，主要负责资源管理、任务调度、状态维护等工作。

核心组件主要包括：

  • API Server
  • Scheduler
  • Controller Manager
  • Etcd

API Server

API Server 是 Kubernetes 集群的统一入口。

无论是创建 Pod、删除资源，还是查询集群状态，对 Kubernetes 的操作基本都需要经过 API Server。

它主要负责：

  • 接收资源操作请求
  • 提供 Kubernetes API
  • 身份认证
  • 权限校验
  • API 注册与发现
  • 协调其他组件完成资源操作

因此，可以将 API Server 理解为：

Kubernetes 集群所有操作请求的统一入口。

整体关系可以表示为：

其他核心组件之间通常也是通过 API Server 协作，而不是随意直接操作彼此的数据。

Scheduler

Scheduler 是 Kubernetes 的调度器。

它解决的核心问题是：

一个新的 Pod 应该运行在哪个 Node 上？

例如集群中存在三个工作节点：

当需要创建一个新的 Pod 时，Scheduler 会结合各个节点的资源情况以及调度规则，选择合适的 Node。

因此 Scheduler 主要负责：

  • 获取集群节点状态
  • 判断哪些节点满足运行条件
  • 根据调度策略选择节点
  • 确定 Pod 最终运行的位置

可以简单理解为：

Scheduler 负责选择运行位置，但并不直接启动容器。

Controller Manager

Controller Manager 可以理解为 Kubernetes 的自动化控制中心。

它会不断检查集群当前状态是否符合预期状态。

例如我们希望：

text 复制代码 
nginx Pod 数量 = 3

但实际运行状态变成：

text 复制代码 
nginx Pod 数量 = 2

此时 Controller Manager 会发现：

text 复制代码 
期望状态 != 实际状态

随后推动系统重新创建缺失的 Pod，让实际状态重新恢复到期望状态。

因此 Controller Manager 主要负责：

  • 维护资源状态
  • Pod 副本数量维护
  • 故障检测
  • 自动恢复
  • 扩容与缩容
  • 应用更新

这也是 Kubernetes 自动化能力的重要基础。

其核心思想可以概括为：

Etcd

Etcd 是一个分布式键值存储系统，在 Kubernetes 中主要用于保存集群的各种状态数据和资源信息。

例如：

  • 集群中有哪些 Node
  • 创建了哪些 Pod
  • Pod 配置信息
  • Service 信息
  • Namespace 信息
  • 各种 Kubernetes 资源对象的信息

可以简单理解为：

Etcd 是 Kubernetes 集群的数据存储中心。

整体关系如下：

需要注意的是，用户通常不会直接操作 Etcd，而是通过 API Server 对 Kubernetes 资源进行操作。

Node 节点核心组件

Node 是 Kubernetes 的工作节点。

真正运行应用程序的 Pod，最终都会被调度到某一个 Node 上。

Node 中主要包含：

  • Kubelet
  • Kube Proxy
  • 容器运行环境

Kubelet

Kubelet 是每个 Node 上非常重要的组件。

它负责接收 Kubernetes 控制平面的任务，并保证 Pod 能够按照要求运行。

主要职责包括：

  • 创建容器
  • 启动容器
  • 维护容器运行状态
  • 停止容器
  • 删除容器
  • 管理 Pod 生命周期

可以理解为：

Kubelet 是 Master 和 Node 之间的重要执行者。

整体流程：

Master 负责决策，Kubelet 负责在 Node 上真正执行相关操作。

Kube Proxy

Kube Proxy 主要负责 Kubernetes 集群中的网络访问和服务转发。

Pod 在 Kubernetes 中可能不断被创建和销毁，因此 Pod 的实际地址并不适合作为应用访问入口。

Kube Proxy 会配合 Service 等机制，实现：

  • 集群内部网络访问
  • 请求转发
  • 服务访问
  • 负载分发

可以简单理解为：

Kube Proxy 负责解决服务流量应该如何到达对应 Pod 的问题。

容器运行环境

Node 最终需要依赖容器运行环境启动真正的容器。

整个层级关系可以理解为：

Kubernetes 自己并不是应用程序的直接运行环境，它主要负责资源编排和管理，真正的应用最终运行在容器中。

Kubernetes 核心组件如何协作

理解单独的组件之后，更重要的是理解这些组件之间如何协作。

以部署一个 Nginx 应用为例，可以将整个过程拆分为以下几个阶段。

集群状态注册

Kubernetes 集群启动以后，各个节点及资源的相关状态会被记录下来。

Etcd 负责保存这些集群状态信息。

例如：

text 复制代码 
Master
Node1
Node2
Node3

相关状态数据最终都由 Kubernetes 进行统一管理。

提交应用创建请求

当用户希望运行一个 Nginx 应用时，请求首先会到达：

text 复制代码 
API Server

API Server 作为整个 Kubernetes 的统一入口，接收并处理资源操作请求。

流程：

Scheduler 选择 Node

API Server 接收到创建需求后，需要确定新的 Pod 应该运行在哪一个 Node 上。

Scheduler 会根据当前集群节点状态以及调度策略进行计算。

例如：

最终 Scheduler 给出调度结果。

Controller Manager 维护资源状态

Controller Manager 负责持续维护 Kubernetes 中资源的期望状态。

如果系统要求某个应用必须存在，那么 Controller Manager 会保证对应资源能够按照预期运行。

例如：

Kubelet 创建 Pod

当任务被分配到具体 Node 后，该 Node 上的 Kubelet 开始执行。

Kubelet 调用容器运行环境，最终创建并启动对应容器。

但 Kubernetes 并不会直接把 Container 当作最基本的管理对象。

Container 会运行在：

text 复制代码 
Pod

之中。

因此最终结构是：

对外提供访问能力

Nginx 启动完成之后，还需要解决如何访问的问题。

Kubernetes 会通过 Service、Kube Proxy 等机制，将访问请求转发到对应的 Pod。

可以抽象成：

至此，一个应用从创建需求到真正运行并能够被访问的基本流程就形成了。

Pod：Kubernetes 的核心运行单元

Pod 是 Kubernetes 中最重要的概念之一。

可以将 Pod 理解为：

Kubernetes 对容器进行管理时使用的基本运行单元。

Kubernetes 并不是简单地直接管理单个容器，而是将一个或多个相关容器组织到 Pod 中，再对 Pod 进行管理。

层级关系：

也就是说：

Pod 和 Container 的关系

一个 Pod 中至少运行一个容器，也可以包含多个关系紧密的容器。

常见结构：

也可以是：

对于 Kubernetes 来说，主要管理对象是 Pod。

因此创建、删除、调度等操作，本质上都是围绕 Pod 展开的。

Controller：Pod 的管理者

如果只有 Pod，还不足以完成复杂的应用管理。

例如：

text 复制代码 
创建 3 个 Pod

运行一段时间后，其中一个 Pod 出现故障：

text 复制代码 
Pod1    正常
Pod2    故障
Pod3    正常

如果完全依靠人工处理，就需要管理员发现故障后重新创建。

Controller 的作用就是对 Pod 进行自动化管理。

主要可以实现：

  • 创建 Pod
  • 删除 Pod
  • 维护 Pod 数量
  • Pod 故障恢复
  • 扩容
  • 缩容
  • 更新应用

可以简单理解为：

因此：

Pod 负责承载应用，Controller 负责管理 Pod。

不同 Controller 具有不同的使用场景，后续针对不同类型的应用，可以选择对应的控制器进行管理。

Service：Pod 的统一访问入口

Pod 存在一个非常重要的问题：

Pod 并不是永久不变的。

Pod 发生故障以后可能会被重新创建，扩容时也可能产生新的 Pod。

例如某个应用有三个 Pod：

text 复制代码 
Pod1
Pod2
Pod3

如果客户端直接访问具体 Pod，那么随着 Pod 的创建、销毁和变化，客户端就需要频繁调整访问目标。

因此 Kubernetes 提供了 Service。

Service 可以作为一组 Pod 的统一访问入口。

结构如下：

客户端只需要访问 Service，而不用关心请求最终被转发到哪个 Pod。

因此可以将 Service 理解为：

一组相同功能 Pod 的稳定访问入口。

Label：资源分类与识别机制

Kubernetes 集群中可能存在大量 Pod。

例如：

text 复制代码 
Pod1  nginx
Pod2  nginx
Pod3  mysql
Pod4  redis
Pod5  nginx

如果希望找出所有属于 Nginx 应用的 Pod，就需要一种资源分类机制。

Kubernetes 使用：

text 复制代码 
Label

也就是标签。

例如：

text 复制代码 
app=nginx

可以给多个 Pod 设置相同标签：

text 复制代码 
Pod1   app=nginx
Pod2   app=nginx
Pod3   app=mysql
Pod4   app=redis
Pod5   app=nginx

这样就可以根据：

text 复制代码 
app=nginx

快速找到：

text 复制代码 
Pod1
Pod2
Pod5

因此 Label 的核心作用就是：

给 Kubernetes 资源进行分类和标识。

Label 与 Service 的关系

Service 本身并不需要手动保存具体 Pod 地址。

它可以根据标签找到对应的一组 Pod。

例如：

text 复制代码 
Service
selector:
    app=nginx

集群中：

text 复制代码 
Pod1    app=nginx
Pod2    app=nginx
Pod3    app=mysql

那么 Service 会关联：

text 复制代码 
Pod1
Pod2

而不会关联：

text 复制代码 
Pod3

整体关系：

Label 是 Kubernetes 中资源关联的重要基础。

Namespace：资源逻辑隔离

随着 Kubernetes 集群中资源越来越多，如果全部资源都放在一起管理，会变得非常混乱。

例如一个集群可能同时存在：

text 复制代码 
开发环境
测试环境
生产环境

Kubernetes 使用 Namespace 对资源进行逻辑上的划分。

例如：

每个 Namespace 中可以分别存在自己的：

  • Pod
  • Service
  • Controller
  • 其他 Kubernetes 资源

例如：

即使资源名称相同，只要位于不同 Namespace 中，也可以进行逻辑上的区分。

因此 Namespace 的主要作用可以理解为：

对 Kubernetes 集群中的资源进行逻辑分组和隔离。

核心概念之间的关系

将前面的内容整合起来，可以得到 Kubernetes 最基本的资源关系：

从资源管理角度，又可以表示为：

用一个完整场景串联所有概念

假设现在需要运行一个 Nginx 应用。

首先，用户向 Kubernetes 提交创建需求：

API Server 接收到请求。

随后 Scheduler 判断：

text 复制代码 
这个 Pod 应该运行在哪个 Node？

经过计算后：

Node2 上的 Kubelet 接收到任务：

此时：

为了标识这个 Pod，可以添加：

text 复制代码 
app=nginx

如果存在多个 Nginx Pod：

text 复制代码 
Pod1 app=nginx
Pod2 app=nginx
Pod3 app=nginx

则 Service 可以通过标签找到它们：

客户端只需要访问 Service：

而 Controller 则持续维护这些 Pod：

如果希望把这些资源放在某个独立环境中，还可以使用 Namespace：

这样，一个 Kubernetes 应用的基本管理体系就形成了。

核心组件职责速记

组件/对象 核心作用
Master 集群控制与管理
Node 实际运行 Pod
API Server Kubernetes 统一操作入口
Scheduler 决定 Pod 运行在哪个 Node
Controller Manager 维护资源的期望状态
Etcd 保存集群状态和资源数据
Kubelet 在 Node 上管理 Pod 和容器生命周期
Kube Proxy 网络转发与服务访问
Pod Kubernetes 基本运行单元
Controller 自动管理 Pod
Service 一组 Pod 的统一访问入口
Label 对资源进行分类和标识
Namespace 对资源进行逻辑分组与隔离

总结

Kubernetes 的核心思想并不是单纯地"启动容器"，而是通过一套完整的资源管理体系对应用进行自动化管理。

首先从集群架构来看：

text 复制代码 
Master 负责管理
Node 负责运行

Master 中：

Node 中：

在资源对象层面：

把这些概念串联起来后，可以形成一条非常重要的理解链路：

掌握这条关系链，就建立了理解 Kubernetes 整体工作机制的基础。

若有转载，请标明出处：https://blog.csdn.net/CharlesYuangc/article/details/165613055

相关推荐
rustfs2 小时前
MinIO 国产开源平替正式 GA
分布式·docker·云原生·rust
wdfk_prog6 小时前
ROS教程07：从 ros::start() 顺着源码读懂 Master、XML-RPC 与 Topic 注册发现
运维·缓存·docker·容器·ros
mengge.cloud6 小时前
0917Docker 小白实验教程（理论+实操）
linux·服务器·网络·docker
两点王爷8 小时前
常用的 Docker 镜像拉取地址仓库及常用命令详解
运维·服务器·容器
wdfk_prog8 小时前
用 Git Submodule + Sparse Checkout 管理 RT-Thread：内核、BSP、第三方库与业务代码分层实践
运维·缓存·docker·容器·ros
努力努力再努力wz8 小时前
【Docker入门系列】镜像为什么能复用？一文吃透 Docker Image、Registry、运行时架构与常用命令
缓存·docker·容器
weixin_420284149 小时前
Kubernetes 开发自定义CRD资源
云原生·kubernetes·kubelet
极小狐9 小时前
CI 算力饥渴症：Runner 弹性伸缩的架构权衡与落地
ci/cd·kubernetes·devops·弹性伸缩
java_logo11 小时前
Docker 部署填鸭表单完整教程：搭建私有化问卷与表单收集平台
docker·表单·问卷·tduck·轩辕镜像·填鸭表单·tduck platform
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02历年考研数学一、数学二、数学三真题试卷及答案PDF03GitHub 镜像站点04蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接05微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新062026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？07人工智能（AI）发展史：详细里程碑08ZCode 周末送额度活动开启：3 亿 Token 免费领取09数学公理体系大全:第六章 选择公理的等价形式及证明10【一等奖版】2026 国赛 A题 药材的烘干问题