k8s 是典型的master-worker架构。master 是大脑，worker负责执行。官网架构图：

控制平面组件

来控制节点的负载均衡，实时监控节点的负载状态。

控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，安装脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此计算机上运行用户容器。具体关系如下图：
 

Kube-apiserver

API 服务器是 Kubernetes 控制平面的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。

我们可以把它想象成一个大型跨国公司的“总服务台”兼“安保中心”。

角色	作用	类比
统一入口 (Gateway)	所有操作（增删改查）的唯一入口，无论是人（kubectl）还是机器（Scheduler）都通过它交互。	公司的总机/前台，所有电话都经过它转接。
安全卫士 (Security)	负责认证（你是谁）、鉴权（你能干嘛）和准入控制（你做的事合不合规）。	保安和合规部，防止坏人进入或违规操作。
数据枢纽 (Hub)	它是唯一能读写 etcd 的组件，负责把“期望状态”存进去，把“实际状态”读出来，让各个组件通过它来“间接沟通”。	公司的中央数据库管理员，各部门不直接互换文件，而是通过它来同步信息。

etcd

一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。如果你的 Kubernetes 集群使用 etcd 作为其后台数据库， 请确保你针对这些数据有一份 备份计划。

该组件用于存k8s 集群的统一存储，存储节点的数据。如果没有 etcd，这些信息可能散落在各个服务的内存里，导致数据不一致。任何配置变更、状态更新，必须写在 etcd 上才算数。

etcd 是强一致性的，因此无论你去问集群里的哪个节点，读到的数据永远是一样的。

kube-scheduler

负责监视新创建的、未指定运行节点的 Pod，并选择节点来让 Pod 在上面运行。

调度决策考虑的因素包括单个 Pod 及多个 Pod 集合的资源需求、 软硬件及策略约束、亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。

kube-controller-manager

确保期望结果和实际结果一致的工具。为了降低复杂性，Kubernetes 把上面提到的所有“工头”（节点控制器、副本控制器等）都打包编译到了同一个程序里运行。这个程序就是 kube-controller-manager。你可以把它理解为“控制器的大本营”。

下表是controller的类比表格：

组件	角色类比	核心作用	关键特性
控制器 (Controller)	具体的工头	调节状态。通过“调谐循环”不断对比“期望”与“实际”，并执行操作来消除差异。	自动化、自愈。你只管声明“我要什么”，它负责“怎么做到”和“坏了怎么修”。
kube-controller-manager	工头大本营	运行控制器。它是一个守护进程，负责把各种内置的控制器跑起来，管理集群的生命周期。	集成化。它把多个逻辑上独立的控制器打包在一起运行，方便管理和部署。

cloud-controller-manager

嵌入了特定于云平台的控制逻辑。 云控制器管理器（Cloud Controller Manager）允许将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。

它的核心作用是将 Kubernetes 集群与云厂商的 API 解耦。它让 K8s 能够利用云厂商的“超能力”（负载均衡、云存储、路由），同时让 K8s 核心代码保持干净，不再被云厂商的特定代码“绑架”。

kube-controller-manager 管的是集群内部的逻辑（比如 Pod 的数量、配置更新）。cloud-controller-manager 管的是集群与云厂商的交互（比如申请公网 IP、管理云路由表）。

节点组件

是master-worker中的worker,节点组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行时环境。

kubelet

kubelet 会在集群中每个节点（node）上运行。 它保证容器（containers）都运行在 Pod 中。

PodSpec：一份详细的“任务说明书”或“设计蓝图”。它是一个YAML或JSON格式的文件，精确描述了Pod应该是什么样子，比如需要运行哪些容器、使用什么镜像、需要多少CPU和内存、挂载哪些存储卷等。

kubelet 接收一组通过各类机制提供给它的 PodSpec，确保这些 PodSpec 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。确定要管理那些容器。

kube-proxy（可选）

是集群中每个节点（node）上所运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。

kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。

如果你使用网络插件为 Service 实现本身的数据包转发， 并提供与 kube-proxy 等效的行为，那么你不需要在集群中的节点上运行 kube-proxy。

iptables三种代理模式 ⽤户空间模式性 能问题较严重基本不再使⽤应⽤最多的是iptables和ipvs模式。

容器运行时

这个基础组件使 Kubernetes 能够有效运行容器。 它负责管理 Kubernetes 环境中容器的执行和生命周期。负责拉取镜像，运行容器。

Kubelet 并不直接与具体的容器运行时打交道，而是通过一个标准化的接口——CRI (Container Runtime Interface) 来进行通信。

• Kubelet：作为节点上的代理，负责接收来自 API Server 的 Pod 调度指令。
• CRI：作为 Kubelet 和容器运行时之间的“翻译官”，它定义了一套标准的 gRPC 接口。
• 容器运行时：实现了 CRI 接口，接收来自 Kubelet 的指令，并负责在操作系统层面真正地创建和管理容器。