Kubernetes架构是学习 K8s 时必须跨过去的一道门槛。很多初学者第一次接触 Kubernetes，会被一连串组件名称弄得很混乱：Master、Node、Pod、Service、Scheduler、API Server、etcd……看起来每个词都认识，但放在一起就很难建立整体理解。其实学习 Kubernetes 架构，最关键的不是一开始记住所有组件细节，而是先搞清楚：谁负责控制、谁负责运行、谁负责调度、谁负责暴露服务，以及这些能力之间是如何协同工作的。
一、为什么理解Kubernetes架构很重要
Kubernetes 并不只是一个“部署容器的工具”，它本质上是一套分布式控制系统。你向集群提交一个期望状态，比如“我要运行 3 个副本”，Kubernetes 会自动调度资源、拉起 Pod、监控状态并持续纠偏。
因此，如果不理解架构，就很难真正理解：
- 为什么 Pod 会被调度到某个节点
- 为什么 Service 能稳定访问后端实例
- 为什么某个组件异常会影响整个集群
- 为什么生产环境里要把控制面和工作节点分开管理
掌握架构之后，你对 Kubernetes 的部署、排障、性能优化和安全治理都会更有把握。
二、Kubernetes架构可以先分成哪两部分
从整体上看，Kubernetes 架构可以先粗略分成两层：
- 控制平面（Control Plane）
- 工作节点（Worker Node）
1. 控制平面负责“管理和决策”
控制平面更像是整个集群的大脑，负责接收请求、保存状态、做调度决策和持续控制集群状态。
2. 工作节点负责“真正运行应用”
工作节点负责运行 Pod 和容器，是业务应用实际落地的地方。
理解这一层分工后，很多组件的角色就会清晰很多：控制平面负责“想清楚该怎么做”，节点负责“把事情执行出来”。
三、Master在Kubernetes里负责什么
虽然现在更标准的说法是 Control Plane，但很多资料和用户仍然习惯把它叫作 Master。它主要包括以下几个关键组件。
1. API Server
API Server 是 Kubernetes 的统一入口。无论是 kubectl 提交资源、控制器同步状态，还是其他组件查询集群信息，最终都要通过 API Server。
可以把它理解成 Kubernetes 的“总前台”。所有资源对象，如 Pod、Deployment、Service、ConfigMap、Secret 等，都会通过它进行增删改查。
2. etcd
etcd 是 Kubernetes 的分布式键值数据库，用来保存集群的核心状态数据。比如有哪些节点、有哪些 Pod、Deployment 副本数是多少，这些元数据最终都保存在 etcd 中。
如果把 API Server 理解成总前台，那 etcd 就更像“核心账本”。没有 etcd，整个集群状态就无从持久化。
3. Scheduler
Scheduler 负责调度。它会根据节点资源、调度约束、亲和性、污点容忍等条件，决定新创建的 Pod 应该运行到哪台 Node 上。
所以当你看到一个 Pod 从 Pending 变成 Running，背后就有 Scheduler 在发挥作用。
4. Controller Manager
Controller Manager 负责持续比较“期望状态”和“实际状态”是否一致。如果你希望某个 Deployment 永远保持 3 个副本，而实际上只剩 2 个，控制器就会继续拉起新的 Pod，直到状态恢复。
这也是 Kubernetes 能实现自愈能力的关键原因。
图1：Kubernetes集群基础架构示意图
四、Node在Kubernetes里负责什么
Node 是集群中的工作节点，可以是虚拟机，也可以是物理机。应用容器最终不会运行在 Master 上，而是运行在这些工作节点上。
一个 Node 通常会包含以下关键组件：
1. kubelet
kubelet 是节点上的核心代理进程。它负责与控制平面通信，并确保这个节点上运行的 Pod 与控制平面下发的期望状态一致。
比如控制面要求这个节点启动一个 Pod，kubelet 就会去调用容器运行时把容器真正拉起来。
2. Container Runtime
Container Runtime 负责真正运行容器，比如 containerd、CRI-O 等。它接收 kubelet 的指令，完成镜像拉取、容器启动、停止等动作。
3. kube-proxy
kube-proxy 负责节点上的服务网络转发规则。它会根据 Service 的定义，在节点上维护网络访问规则，让流量能够被正确转发到后端 Pod。
所以 Node 的本质职责可以概括为一句话：
控制平面负责决策，Node 负责把容器真正跑起来。
五、Pod在Kubernetes架构里是什么角色
Pod 是 Kubernetes 中最小的部署单元，也是业务应用最直接的承载对象。
很多初学者容易把 Pod 理解成“容器”，其实更准确地说，Pod 是容器的运行载体。一个 Pod 里可以运行一个或多个紧密协作的容器，它们共享网络命名空间和存储卷。
大多数业务场景中，一个 Pod 往往对应一个主业务容器。
Pod 的关键作用包括：
- 承载实际业务进程
- 作为调度单位被分配到某个 Node
- 作为 Service 的后端目标对象
- 被 Deployment、StatefulSet 等更高层对象统一管理
所以你可以把 Pod 看成 Kubernetes 架构里最基础的“应用执行单元”。
图2：Kubernetes中Pod与Service通信示意图
六、Service在Kubernetes架构里负责什么
Service 是 Kubernetes 提供的稳定访问抽象。它解决的问题是：Pod 是动态变化的，IP 会变、实例数量会变、节点会变，如果直接访问 Pod，业务调用关系会非常不稳定。
Service 的作用就是为一组符合标签选择器的 Pod 提供一个固定访问入口，并把流量分发到后端实例。
它的重要价值包括：
- 给动态变化的 Pod 提供稳定访问地址
- 做简单的服务发现和流量转发
- 让前端或调用方不用感知后端实例变化
在微服务架构里，Service 是非常核心的基础能力。
七、Master、Node、Pod、Service之间是怎么协同的
如果把整个流程串起来，大致可以这样理解：
- 用户通过 API Server 提交一个 Deployment
- 控制平面把资源状态写入 etcd
- Scheduler 决定 Pod 应该调度到哪台 Node
- 对应 Node 上的 kubelet 调用容器运行时拉起容器
- Pod 成功运行后，Service 把流量稳定转发到这些 Pod
- Controller 持续检查副本数和运行状态，异常时自动纠偏
这其实就是 Kubernetes 架构的核心运行逻辑：
- API Server 负责统一入口
- etcd 负责保存状态
- Scheduler 负责分配位置
- Controller 负责持续纠偏
- Node 负责执行
- Pod 负责运行应用
- Service 负责暴露访问能力
八、为什么Kubernetes架构适合大规模应用管理
Kubernetes 架构之所以强大，是因为它把分布式应用管理拆成了一套职责清晰的系统：
- 控制和执行分离
- 期望状态和实际状态持续校验
- 应用运行和服务暴露标准化
- 节点、工作负载、流量管理解耦
这种设计使它天然适合：
- 微服务应用部署
- 高可用服务治理
- 弹性扩缩容
- 自动化运维
- 平台工程与内部开发平台建设
对于企业来说，这不只是一个“部署工具”，而是现代应用平台的基础设施底座。
九、学习Kubernetes架构时应该先抓住什么
如果你刚开始学 Kubernetes，不建议一开始陷入过多组件细节。更推荐先抓住下面这个最小认知框架：
- Control Plane：负责管理和决策
- Node：负责执行和运行容器
- Pod：最小部署单元
- Service：稳定访问入口
只要先把这四层关系理顺，再往下看调度、网络、存储、安全、控制器机制，就会容易很多。
结语
Kubernetes架构的核心，不在于记住多少组件名称，而在于理解这套系统如何把“应用应该怎样运行”转化成“应用真的在集群里稳定运行”。Master、Node、Pod、Service 分别承担的是控制、执行、承载和暴露四种关键职责。把这几个角色理解清楚，Kubernetes 就不再是一堆抽象术语，而会变成一套有逻辑、有层次的现代应用平台架构。
转载请注明出处：https://www.cloudnative-tech.com/cloud-native-tech/kubernetes-containers/kubernetes-basics/6138.html