Kubernetes集群架构与组件

系列文章目录

文章目录

系列文章目录
- 前言
- 一、云原生基础概述
- 二、K8S是什么
- 三、为什么要用K8S
- 四、Kubernetes集群架构与组件（重点详解）
- - [4.1 控制平面（Master/Control Plane）：集群的"大脑"](#4.1 控制平面（Master/Control Plane）：集群的“大脑”)
  - [4.2 工作节点（Node/Worker）：应用的"运行载体"](#4.2 工作节点（Node/Worker）：应用的“运行载体”)
  - [4.3 组件协作流程](#4.3 组件协作流程)
- 五、Kubernetes核心概念与资源对象
- 总结

前言

对于初学者而言，K8S 的架构设计、组件协作和部署流程往往是入门的核心难点 ------ 控制平面与工作节点如何分工？核心组件之间如何协同工作？数据在集群中如何流转？这些问题直接决定了对 K8S 的理解深度。本文将围绕 K8S 的核心逻辑展开，以 "概念铺垫 + 重点拆解" 的方式，先简明梳理云原生与 K8S 的基础认知，再聚焦集群架构与组件这一核心，结合实际部署场景，清晰剖析组件职责、协作流程与数据流向，同时补充核心概念与实用部署要点，帮助读者既能建立系统化的理论认知，又能具备落地实践的能力。无论你是刚接触云原生的技术新手，还是需要梳理知识体系的运维从业者，都能从本文中快速 get K8S 的核心逻辑与实践技巧。

一、云原生基础概述

云原生是一套适配动态云环境的技术体系，核心是让应用在公有云、私有云或混合云中弹性扩展、高效运维。

发展历程：从2013年Docker发布推动容器化，到2014年Kubernetes开源成为编排标准，再到CNCF成立推进生态，云原生已成为企业IT架构的主流方向。
核心技术栈：以容器化（Docker/containerd）、微服务、DevOps、服务网格（Istio）为核心，强调应用无状态、声明式API和不可变基础设施。
关键特征：符合12因素应用原则，面向微服务架构，具备自服务敏捷性和抗脆弱性，通过API实现服务协作。

二、K8S是什么

Kubernetes（简称K8S）是开源的容器编排平台，用于自动化部署、扩展和管理容器化应用，源自Google的Borg系统，采用Go语言开发并捐赠给CNCF。

名称含义：源自希腊语，意为"舵手/导航者"，形象体现其集群管理核心作用。
关键版本变动：1.24版本后正式移除dockershim，不再直接支持Docker，需使用containerd、CRI-O等符合CRI标准的容器运行时。
核心定位：容器化应用的"操作系统"，抽象底层基础设施，让开发者专注业务逻辑。

三、为什么要用K8S

K8S的核心价值的是解决传统容器管理的痛点，提供企业级运维能力：

自动化运维：一键完成部署、更新、扩容、删除等操作，无需人工干预。
弹性伸缩：基于CPU、内存等指标自动调整Pod副本数，适配业务流量波动。
容灾自愈：节点或容器故障时，自动重建、迁移Pod，保障服务可用性。
服务发现与负载均衡：通过Service提供稳定访问入口，自动分发请求到后端Pod。
滚动升级与回滚：支持渐进式更新，出错可快速回滚至稳定版本。
集中配置与密钥管理：通过ConfigMap、Secret统一管理配置和敏感数据，无需硬编码。

四、Kubernetes集群架构与组件（重点详解）

K8S采用"控制平面+工作节点"的主从架构，控制平面负责集群调度与管理，工作节点负责运行实际应用负载，组件分工明确、协同工作。

4.1 控制平面（Master/Control Plane）：集群的"大脑"

控制平面是集群的核心决策层，包含4个关键组件，负责维护集群期望状态：

组件	核心职责	关键说明
kube-apiserver	集群统一API入口	接收所有资源操作请求（增删改查、Watch），是组件间通信的唯一桥梁，支持认证、授权和准入控制。
kube-controller-manager	运行各类控制器	维护集群状态，包含节点控制器（监控节点健康）、ReplicaSet控制器（维持Pod副本数）、Service控制器（管理服务端点）等，确保实际状态与期望状态一致。
kube-scheduler	Pod调度器	为未调度的Pod选择最优节点，基于"预选（predicates）+优选（priorities）"策略，考虑节点资源剩余量、亲和性、污点容忍等因素。
etcd	分布式键值存储	持久化保存集群所有资源状态数据（如Pod配置、Service信息），是集群的"数据中心"，需保证高可用（生产环境建议多实例部署）。

4.2 工作节点（Node/Worker）：应用的"运行载体"

工作节点是执行实际计算任务的服务器，每个节点包含3个核心组件，负责响应控制平面指令：

组件	核心职责	关键说明
kubelet	节点代理	运行在每个节点上，接收控制平面下发的Pod任务，监控容器运行状态（启动/停止/健康检查），并向控制平面汇报节点和Pod状态。
kube-proxy	服务网络代理	实现Service的网络规则与负载转发，支持iptables、ipvs等模式，将外部请求分发到后端Pod，维持Service与Pod的映射关系。
container runtime	容器运行时	负责容器镜像拉取、容器启停、资源隔离等底层操作，K8S 1.24+要求使用CRI兼容运行时，主流选择是containerd（轻量、稳定，Docker镜像仍兼容）。

4.3 组件协作流程

1. 组件分工先明确
Master 节点（管控层）：

Kube-APIServer：集群统一入口，所有操作都通过它交互

etcd：分布式存储，保存整个集群的状态（比如 Pod 数量、调度信息）

Kube-controller-manager：维护集群期望状态（比如确保 Pod 数量符合要求）

Kube-scheduler：负责把 Pod 分配到合适的 Node 节点
Node 节点（执行层）：

Kubelet：接收 Pod 任务，调用 Docker 创建 Pod

Kube-proxy：配置网络规则，保障 Pod 之间 / 外部的通信

Docker Engine：实际运行 Pod 容器的环境
2. 工作流程按步骤走

List item运维发起请求（步骤①）：

运维人员通过 Kube-APIServer 提交操作（比如 "创建 2 个 Pod"）。
List item状态存入 etcd（步骤②）：

Kube-APIServer 把请求信息同步到 etcd，etcd 记录下 "期望创建 2 个 Pod" 的集群状态。
List item控制器维护状态（步骤③④）：

Kube-controller-manager 监听 APIServer，确认集群需要达到 "2 个 Pod" 的状态，持续与 APIServer 交互同步状态。
List item调度 Pod 到 Node（步骤⑤⑥）：

Kube-scheduler 监听 APIServer，发现 "未分配的 Pod" 后，根据 Node 的资源情况选合适节点，再把调度结果同步给 APIServer、存入 etcd。
List itemNode 创建 Pod（步骤⑦⑧）：

目标 Node 上的 Kubelet 监听 APIServer，获取到 "分配给自己的 Pod 任务"，调用 Docker Engine 创建 Pod 实例。
List item配置网络通信（步骤⑨）：

Kube-proxy 创建网络规则，让 Pod 之间、Pod 和外部能正常通信。
List item状态循环反馈（步骤⑩）：

Kubelet 把 Pod 的运行状态反馈给 APIServer，APIServer 同步到 etcd；Kube-controller-manager 持续监听，若 Pod 异常（比如挂了），会触发重新创建，维持集群的期望状态。

五、Kubernetes核心概念与资源对象

K8S通过一系列抽象资源对象管理集群，核心概念如下：

Pod：最小可调度单位，包含一个或多个容器，共享网络、存储资源。
控制器（Controller）：管理Pod生命周期，如Deployment（无状态应用）、StatefulSet（有状态应用）、DaemonSet（每节点一个Pod）、Job/CronJob（批处理/定时任务）。
Service：为一组Pod提供稳定访问入口，实现负载均衡，通过标签选择器关联Pod。
Ingress：HTTP/HTTPS层面的路由管理，将外部流量导入集群内Service。
Label/Selector：键值对标签，用于筛选、组织资源（如通过Label将Pod分组，Service通过Selector关联Pod）。
Namespace：集群逻辑隔离空间，用于区分不同环境（如开发、测试、生产）或项目，实现资源隔离和权限管理。

总结

Kubernetes 作为云原生时代的核心编排平台，其 "控制平面 + 工作节点" 的主从架构的设计，既保证了集群管理的集中性，又实现了应用运行的分布式弹性。从核心组件来看，kube-apiserver 作为统一入口串联起所有交互，etcd 提供可靠的数据存储，kube-controller-manager 与 kube-scheduler 保障集群状态合规与资源最优调度，而工作节点的 kubelet、kube-proxy 及容器运行时，则构成了应用落地的坚实基础。