Kubernetes 架构剖析：Master 节点与 Worker 节点组件

Kubernetes 的架构，说白了就是「大脑」加「手脚」的配合。Master 节点负责决策，Worker 节点负责干活。我刚开始接触 K8s 时，总觉得组件太多记不住。后来拆开来看，其实每个组件各司其职，逻辑非常清晰。

下面这张图是我自己总结的 K8s 核心架构，你先有个整体印象。

Kubernetes 核心架构图 Master 节点（控制平面） API Server 集群入口，认证/授权/准入控制 Scheduler Pod 调度决策，绑定到合适节点 Controller Manager 控制器循环，维持期望状态 etcd 分布式键值存储，集群状态持久化 Worker 节点（数据平面） kubelet 节点代理，管理 Pod 生命周期 kube-proxy 网络代理，实现 Service 负载均衡 Container Runtime 容器运行时（Docker/containerd） Pod 最小调度单元，包含一个或多个容器 kubectl / REST 💡 Master 节点通常部署奇数台（3 或 5）实现高可用，Worker 节点按业务需求弹性扩缩

Master 节点：集群的大脑

Master 节点上跑着四个核心组件：API Server、Scheduler、Controller Manager 和 etcd。它们共同构成了控制平面。我个人习惯把 Master 节点比作「机场塔台」——它不直接开飞机，但所有起降指令都从这儿发出。

API Server

API Server 是集群的唯一入口。所有组件、kubectl、外部系统，都得通过它来跟集群打交道。它负责三件事：认证你是谁、授权你能干什么、准入控制检查你的请求是否合规。

我的经验：API Server 是无状态的，你可以水平扩展。我曾经在生产环境压测时发现 API Server 成了瓶颈，后来加了负载均衡和缓存，吞吐量直接翻倍。

API Server 背后是 etcd，所有数据都持久化在这里。你想想看，如果 etcd 挂了，整个集群就失忆了。所以 etcd 一定要做备份，我建议至少 3 节点起步。

Scheduler

Scheduler 负责把新创建的 Pod 分配到合适的 Worker 节点上。它怎么选？说白了就是两步：先过滤（Filter），再打分（Score）。

  • 过滤阶段：排除不满足条件的节点，比如资源不足、端口冲突、污点不匹配。
  • 打分阶段：对剩余节点按策略打分，选最高分的那个。

默认调度策略考虑的是资源均衡。但我遇到过一种情况：某些 Pod 对网络延迟特别敏感，这时候就得用自定义调度器，或者给节点打标签做亲和性调度。

避坑指南：我曾经在生产环境遇到过调度「风暴」——同时创建几百个 Pod，Scheduler 压力暴增，调度延迟从毫秒级变成秒级。后来加了调度队列的限流，才稳住。

Controller Manager

Controller Manager 是一个控制器集合。它里面跑着几十个控制器，比如 Node Controller、Replication Controller、Endpoint Controller 等等。每个控制器都在自己的循环里不断检查「当前状态」和「期望状态」是否一致，不一致就调协。

举个例子：你声明了 3 个副本，某个 Pod 挂了，Replication Controller 检测到实际只有 2 个，就会立即创建第 3 个。整个过程不需要人工干预。

etcd

etcd 是分布式键值存储，存的是集群的「真相」。所有组件的状态、配置、元数据，全在 etcd 里。它基于 Raft 协议保证一致性。

嗯，这里要注意：etcd 对磁盘 IO 很敏感。我见过有人把 etcd 跑在机械盘上，结果集群频繁超时。建议用 SSD，并且单独挂载。

Worker 节点：集群的手脚

Worker 节点是真正跑业务的地方。每个 Worker 节点上都有三个核心组件：kubelet、kube-proxy 和容器运行时。

kubelet

kubelet 是 Master 派到 Worker 节点上的「监工」。它负责管理本节点上的 Pod 生命周期——创建、启动、监控、重启、销毁。

kubelet 定期向 API Server 汇报节点状态和 Pod 状态。如果某个 Pod 挂了，kubelet 会尝试重启它。但如果重启多次还失败，kubelet 会把状态标记为 CrashLoopBackOff。

我的经验：排查 Pod 起不来时，第一件事就是看 kubelet 日志。我遇到过好几次，问题出在容器镜像拉取失败，但 kubelet 日志里写得清清楚楚。

kube-proxy

kube-proxy 负责实现 Service 的负载均衡。它监听 API Server 上 Service 和 Endpoint 的变化，然后更新本机的 iptables 或 IPVS 规则。

说白了，当你访问一个 Service 的 ClusterIP 时，流量会被 kube-proxy 设置的规则转发到后端的某个 Pod 上。默认模式是 iptables，性能一般但稳定。如果对性能有要求，可以切到 IPVS 模式。

避坑指南：我曾经在大型集群里遇到 iptables 规则过多导致性能下降的问题。几万个 Service 的规则，iptables 查表越来越慢。后来切到 IPVS 模式，延迟降了 80%。

容器运行时

容器运行时负责真正拉取镜像、启动容器。Kubernetes 通过 CRI（Container Runtime Interface）与运行时交互。常见的运行时包括 Docker、containerd、CRI-O。

你可能会问：Docker 不是被 Kubernetes 弃用了吗？其实弃用的是 dockershim，不是 Docker 本身。如果你用 containerd 作为运行时，性能更好，也更轻量。

组件协作流程

咱们走一遍完整的流程，看看这些组件是怎么配合的：

  1. 你执行 kubectl create deployment nginx --image=nginx:latest
  2. kubectl 把请求发给 API Server
  3. API Server 认证、授权、准入检查通过后，把 Deployment 对象写入 etcd
  4. Controller Manager 中的 Deployment Controller 检测到新的 Deployment，创建 ReplicaSet
  5. ReplicaSet Controller 检测到副本数为 0，创建 Pod 对象
  6. Scheduler 监听到新的未调度 Pod，经过过滤和打分，选择一个 Worker 节点
  7. Scheduler 把绑定结果写回 API Server，更新 Pod 的 nodeName 字段
  8. 目标 Worker 节点上的 kubelet 监听到 Pod 被调度到自己身上
  9. kubelet 通过 CRI 调用容器运行时，拉取镜像、启动容器
  10. kube-proxy 更新 iptables 规则，确保 Service 能路由到新 Pod

整个过程看起来步骤多，但实际上从你敲命令到 Pod 运行，通常只需要几秒钟。这就是 Kubernetes 的魅力——复杂但高效。

组件对比速查表

组件 所属节点 核心职责 通信方式
API Server Master 集群入口，认证/授权/准入 REST API
Scheduler Master Pod 调度决策 Watch API Server
Controller Manager Master 控制器循环，维持期望状态 Watch API Server
etcd Master 分布式存储，集群状态持久化 gRPC
kubelet Worker 节点代理，管理 Pod 生命周期 Watch API Server
kube-proxy Worker 网络代理，Service 负载均衡 Watch API Server
Container Runtime Worker 容器运行环境 CRI

总结一下：Master 节点管决策，Worker 节点管执行。API Server 是枢纽，etcd 是记忆，Scheduler 是调度员，Controller Manager 是监工，kubelet 是现场执行人，kube-proxy 是网络交警。理解了这些角色，Kubernetes 就不再神秘了。

← 上一章 📖 返回目录 下一章 →