当前位置：首页 > 问答 > 正文

原来Kubernetes架构没想象中那么复杂，懂了就简单多了

瞿欣合
问答
2026-01-09 14:48:20
2

（根据B站视频“原来Kubernetes架构没想象中那么复杂，懂了就简单多了”整理）

原来觉得Kubernetes（常简称为K8s）是特别高深莫测的东西，好像是只有大厂的核心技术团队才能玩转的庞然大物，但真正去了解它的核心架构后，发现它的设计思想其实非常直观，甚至可以说有点“简单”，它解决的问题很明确，所以它的组件各司其职，逻辑也就清晰起来了。

我们可以把Kubernetes想象成一个公司的管理团队,这个公司的核心业务就是部署和管理各种各样的应用程序（也就是我们常说的“应用”或“服务”）。

这个团队必须有一个大脑，一个总指挥，在Kubernetes里，这个角色就叫 Master节点（现在更常被称为控制平面），这个总指挥自己不干具体的活儿，比如它不会去亲自运行你的网站程序或者数据库，它的任务是发号施令和监控全局，总指挥由几个核心的“部门经理”组成：

API Server（API服务器）：这是公司的前台和总机，所有想跟Kubernetes集群打交道的人，无论是公司内部的其他系统（比如CI/CD工具）还是管理员敲的命令，都必须通过这个API Server，它负责接收指令、验证指令的合法性，然后把它记录下来，它是整个系统唯一对外的大门，这种设计让管理变得非常统一和简单。
etcd（分布式键值存储）：这是公司的超级账本或者说是中央档案室，集群里所有的重要信息都保存在这里，比如哪个应用应该运行多少份副本、它们的配置是什么、当前它们都在哪里运行、状态如何等等，这个账本的特点是高度一致且可靠，确保了总指挥做出的每一个决策都是基于最新、最准确的信息，API Server收到指令后，所有的状态变化都会先记录到etcd里。
Scheduler（调度器）：这位是公司的人力资源总监或者项目经理，它的工作非常专一：当API Server收到一个指令说“我需要运行一个名为‘我的网站’的应用，要3个副本”时，Scheduler就出场了，它看着etcd账本，检查当前公司里哪些“工位”（也就是Worker节点）是空闲的、资源充足的、符合要求的，然后做出决策：“副本1放在A工位，副本2放在C工位，副本3放在B工位”，它只负责做分配决策，不负责具体执行。
Controller Manager（控制器管理器）：这位是公司的运营总监，它手下有一大群“控制器”，每个控制器都负责盯着某一类资源的状态，有一个叫“Deployment”的控制器，它一直盯着etcd账本，看“我的网站”这个应用是不是始终保持3个副本在运行，如果它发现因为某个工位的机器坏了，导致“我的网站”只剩下2个副本，它不会亲自去处理，而是会通过API Server这个总机发出一个新指令：“嘿！这里少了一个副本，需要补上一个！” 然后Scheduler（人力资源）会再次出动，为这个新副本找个新工位，Controller Manager的作用就是确保公司的实际运营状态，永远向着账本上记录的目标状态去靠拢，这个“调谐” loop（循环）是Kubernetes自动化的核心魔力。

总指挥（控制平面）介绍完了，公司里当然要有干活的员工，这些就是 Worker节点（也叫数据平面），每个Worker节点就是一台（虚拟或物理）服务器，是真正运行你应用程序容器的地方，每个Worker节点上也有几个关键的“基层主管”：

kubelet（节点代理）：这是总指挥安插在每个Worker节点上的现场监工，它负责跟API Server保持通信，接收发自总指挥的指令，在你的节点上启动一个‘我的网站’的容器”，然后它就会调用Docker或者containerd这样的容器运行时（可以理解为具体干活的工具人），来拉取镜像、创建容器，kubelet还会时刻向API Server汇报本节点的健康状况和上面运行的容器的状态。
kube-proxy（网络代理）：这位是公司的网络管理员，它负责处理节点上的网络规则，实现服务的发现和负载均衡，当公司内部另一个应用“前端页面”想访问“我的网站”服务时，它不需要知道“我的网站”的三个副本具体在哪三台机器上，它只需要访问一个统一的虚拟IP地址（Service），kube-proxy就在每个节点上设置了规则，确保这个访问请求能被智能地转发到背后健康的容器副本上去。

整个工作流程就串起来了：我们通过命令行工具kubectl（相当于给CEO递话的秘书）向API Server（总机）发出指令：“部署我的网站，要3个副本”，API Server验明正身后，把“目标状态：我的网站×3”写进etcd（账本），Deployment控制器（运营总监）发现账本上有了新目标，但它发现当前副本数是0，于是它通过API Server说“需要创建3个副本”，Scheduler（人力资源）查看所有Worker节点，为这3个副本找到合适的“工位”，并把分配结果通过API Server写回etcd，目标节点上的kubelet（现场监工）监听到这个属于自己的任务，立刻指挥容器运行时（工具人）把容器跑起来，并汇报状态：“我这里的副本已就绪”，就这样，整个系统通力协作，最终达到了我们期望的状态。

你看,剥开那些专业术语的外壳，Kubernetes的架构就是一个分工明确、各司其职的管理系统，它通过一个声明式的API（告诉系统你想要什么状态，而不是具体怎么做）和一个持续不断的“观察-对比-调整”循环，实现了应用的自动化部署、扩展和管理，一旦理解了每个组件的角色和它们之间简单的协作关系，就会发现，原来Kubernetes的架构真的没想象中那么复杂，懂了就简单多了。