K8s架构：控制面与工作节点

可视化演示

演示控制面组件交互、调度器过滤打分绑定流程，以及声明式API的控制循环协调机制，可切换三种模式观察Pod如何被调度运行。

集群总览

假设你经营一家五星酒店。如果所有人都挤在同一个办公室里，既要接电话，又要跑去每个房间打扫，很快前台就会陷入混乱。一家成熟的酒店一定会把“管理区”和“楼层区”分开：管理区负责接单、排班、盯服务标准，楼层区则负责真正铺床、送餐、清扫。Kubernetes 的架构思路和这家酒店完全一致。

K8s 把一台台服务器分成两类角色。控制面（Control Plane）节点相当于酒店的管理区，工作节点（Worker Node）相当于客房楼层。控制面通常由 4 个组件协作完成决策：API Server 负责接单，etcd 负责存档，Scheduler 负责排班，Controller Manager 负责质检。工作节点则运行 kubelet（楼层领班）、容器运行时（清扫工具）和 kube-proxy（礼宾接线）。控制面一般不放业务，专注协调；真正承载业务服务的 Pod 落在工作节点上。

从数学上看，一个 K8s 集群就是控制面集合与工作节点集合的并集。

把集群看作一个整体，理解这层结构后就会发现：控制面再怎么聪明，没有工作节点去执行就是纸上谈兵；工作节点再拼命，没有控制面的调度和校验也会各自为战。酒店的“管理区＋楼层区”缺一不可，Kubernetes 的“控制面＋工作节点”也正是这样形成合力的。

统一入口

在酒店里，客人不会直接冲进档案室或厨房，所有入住、换房、点餐都要从总台登记。总台是唯一的对外窗口，也是唯一有权限修改房态记录的地方。K8s 里的 API Server 就是这样一个总台。

不管你是敲 kubectl 命令，还是用 SDK 调用，所有操作最终都会变成 REST 请求打到 API Server。它是集群里唯一的“写入口”，其他组件都不许绕过它私自改状态。API Server 会先做身份认证和权限校验，再经过准入控制，最后把资源状态写入 etcd。它的 Watch 机制还会主动把变化推送给订阅方，让其他组件第一时间感知。

一次普通请求的流转链路可以写成：

正因为一切都要过总台，K8s 才能保证订单的流程、校验、留痕都统一。设想一下，如果每个管理员都能直接改档案室，酒店必然乱套；让 API Server 大权独揽，虽然多了一道排队，却换来了整个集群的秩序。

状态仓库

档案室管理着一本大簿子，记录每个房间住的是谁、几点退房、是否有维修订单。任何人想了解房态，要么查档案，要么等档案室主动喊一嗓子。etcd 就是这本大簿子。

etcd 是 K8s 的分布式键值数据库，保存所有资源对象，包括 Deployment、Pod、Service 等。它不只存“配置”，而是整个集群的“唯一真相源”。为了不让数据混乱，etcd 通过 Raft 共识算法在多个副本之间同步，只有过半数副本确认才能写入。控制器们不需要反复轮询检查，而是用 Watch 机制盯着感兴趣的键，一旦发生变化立刻收到通知。

Raft 算法的关键数字是“法定人数”：

Raft 的法定人数规则就像开“紧急会议”：3 个档案员只要有 2 个确认就能拍板，5 个只要有 3 个确认。单个档案员请假不影响酒店运转。备份与恢复同样重要，因为档案一旦丢失，整个酒店的房态就成了谜。

调度控制

排班经理拿到入住单，会先看哪些房间空着、资源是否满足要求，再决定派给哪个楼层。质检主管则不会检查一次就下班，而是每天对照标准手册巡逻，发现差距就安排整改。Scheduler 和 Controller Manager 正是这两位关键角色。

Scheduler 负责为新 Pod 选择最合适的工作节点：先过滤掉资源不足或不满足限制的节点，再对剩余候选节点打分，选出最优解。Controller Manager 里有一组控制器，例如 ReplicaSet 控制器，它们维护着一个控制循环：观察当前副本数，与期望副本数比较，若差异不为零就去创建或删除 Pod。你只需要在 YAML 里声明“我要 3 个副本”，系统就会持续调谐到满足期望，这就是声明式模型。

控制循环的“灵魂”是一个差值公式：

控制循环的核心思路，就是“盯着差距、反复修正”。这个逻辑让 K8s 具备强大的自愈能力：Pod 挂了就重新拉起，副本多了就自动回收，完全不需要工程师登录服务器手工处理。

节点执行

酒店管理区做了再完美的排班计划，还是要靠楼层领班敲开房门、检查床单、启用物品。楼层领班是管理区与客房之间的最后一道交接人。在 K8s 中，这道交接人就是 kubelet。

kubelet 运行在每个工作节点上，负责从 API Server 接收 Pod 的期望规格，然后调用容器运行时创建或销毁容器，并持续汇报运行状态。由于它只负责本节点，控制平面不必亲自登录每台机器。节点上的 kube-proxy 则像礼宾接线员：维护网络规则，让来自外部的访问能够负载均衡地转发到正确的 Pod。Pod 是 K8s 上最小的部署单元，可以装一个或多个容器，共享网络 IP 和存储卷。

Pod 的结构可以概括为：

你可以把 Pod 理解成“一间双人房”：几位客人共享同一个水电地址，楼层领班只检查整间房的状态。这样的设计让容器的生命周期、健康检查、流量接入被框进同一个管理单元，K8s 才能整齐划一地指挥成千上万个容器。

运维实践

酒店经营久了，你会发现总台高峰排队、档案室磁盘变慢、某个楼层领班失联。成熟酒店会配置多套总台、定期备份档案，并对每个楼层做心跳巡检。K8s 的运维实践也围绕这几点展开。

首先是高可用设计：控制面通常部署多个节点，etcd 也做多副本，避免单点故障；工作节点通过资源预留避免 Pod 与系统组件争抢资源。其次是调优：给 API Server 配置合理的 QPS 和审计级别，给 etcd 更换高性能磁盘并开启压缩与定期快照，给 Scheduler 调整抢占策略和过滤逻辑。故障排查时，可以先用 kubectl describe、kubectl get events 看事件，再沿着“API Server → etcd → Controller → kubelet”的链路逐层定位。

系统可用性可以用这个公式表达：

可用性公式告诉我们：想让系统更可靠，要么延长“好日子”，要么缩短“坏日子”。K8s 的高可用架构和监控告警，本质上都是为了把这个分数做到 99.99%。

AI 应用场景

Python 演示

import time class ReplicaSetSimulator:    def __init__(self, desired, initial, max_step=2):        self.desired = desired        self.current = initial        self.max_step = max_step     def observe(self):        return self.current     def compute_delta(self):        return self.desired - self.observe()     def reconcile(self):        diff = self.compute_delta()        if diff > 0:            action = min(diff, self.max_step)        elif diff < 0:            action = max(diff, -self.max_step)        else:            action = 0        self.current += action        return action def main():    sim = ReplicaSetSimulator(desired=5, initial=1)    for t in range(8):        action = sim.reconcile()        status = "已到达期望副本数" if sim.current == sim.desired else "继续调谐"        print(f"t={t}: current={sim.current}, delta={sim.desired - sim.current:>+d}, action={action:>+d}, {status}")        if sim.current == sim.desired:            break        time.sleep(0.2) if __name__ == "__main__":    main()

1. def compute_delta(self):计算当前状态与期望状态的差值，这就是控制循环中的核心变量 Δ。
2. def reconcile(self):执行一次调谐动作，对应 Controller Manager 每次循环所做的“纠偏”。
3. action = min(diff, self.max_step)限制单次最大伸缩量，避免系统震荡。
4. if sim.current == sim.desired: break当 Δ=0 时停止调谐，对应 K8s 中“已达到期望状态”。

常见误区

面试题