了解了K8s的核心概念后，我们再来深入解析K8s的架构，看看控制平面节点和工作节点上的组件都有哪些，它们之间如何协同工作，完成容器的部署、管理和运维。

K8s的架构采用“客户端-服务器”模式，分为控制平面（Control Plane）和数据平面（Data Plane）两部分，控制平面负责决策和控制，数据平面负责执行具体的任务，二者协同工作，构成完整的K8s集群。

1. 控制平面节点（Master Node）组件

控制平面节点是集群的“大脑”，包含四个核心组件，这些组件协同工作，负责管理整个集群的运行，具体如下：

（1）kube-apiserver：集群的“入口”

kube-apiserver是K8s集群的统一入口，所有的操作（如部署Pod、创建Service、查看集群状态）都需要通过kube-apiserver进行，它负责接收用户的请求（如kubectl命令、API请求），验证请求的合法性，然后将请求转发给其他组件，同时存储集群的状态信息（到etcd）。

kube-apiserver是无状态的，支持水平扩展，当集群规模较大时，可以部署多个kube-apiserver实例，通过负载均衡器实现高可用。

（2）etcd：集群的“数据库”

etcd是一个分布式键值存储系统，用于存储K8s集群的所有状态信息，比如Pod的配置、Service的配置、节点的状态、控制器的状态等，是K8s集群的“数据中心”。

etcd具有高可用、强一致性的特点，通常部署在控制平面节点上，对于生产环境，建议部署3个或5个etcd实例，实现高可用，避免单点故障（如果etcd故障，整个集群将无法正常运行）。

（3）kube-scheduler：集群的“调度器”

kube-scheduler的核心作用是“调度Pod”，当用户创建一个Pod时，kube-apiserver会将Pod的请求转发给kube-scheduler，kube-scheduler会根据集群的资源情况（如节点的CPU使用率、内存使用率、剩余资源）、Pod的需求（如CPU请求、内存请求）、调度策略（如亲和性、反亲和性），选择一个最合适的工作节点，将Pod部署到该节点上。

简单来说，kube-scheduler就相当于集群的“调度员”，负责给每个Pod分配一个“工作岗位”（节点），确保Pod能够正常运行，同时优化集群的资源利用率。

（4）kube-controller-manager：集群的“控制器管理器”

kube-controller-manager负责管理集群中的各种控制器（如Deployment、StatefulSet、DaemonSet等），它会运行多个控制器进程，每个控制器负责监控一种资源的状态，当资源的实际状态与期望状态不一致时，控制器会自动进行调整，确保资源的状态符合用户的预期。

例如，Deployment控制器会监控Pod的副本数量，如果实际副本数量少于期望副本数量，控制器会自动创建新的Pod；如果实际副本数量多于期望副本数量，控制器会自动删除多余的Pod；如果Pod故障，控制器会自动重启Pod。

2. 工作节点（Worker Node）组件

工作节点是集群的“手脚”，负责运行容器，执行具体的应用任务，包含三个核心组件，具体如下：

（1）kubelet：节点的“管家”

kubelet是运行在每个工作节点上的代理程序，负责与控制平面节点通信，接收控制平面节点的指令（如部署Pod、停止Pod），然后执行具体的操作，同时监控节点上的Pod和容器的状态，将状态信息汇报给控制平面节点。

kubelet的核心职责：

- 部署Pod：根据控制平面的指令，在节点上部署和运行容器；

- 监控状态：监控Pod和容器的运行状态（如CPU使用率、内存使用率、进程状态），如果容器故障，会尝试重启容器；

- 汇报状态：将节点和Pod的状态信息汇报给kube-apiserver，让控制平面节点了解集群的运行状态。

（2）kube-proxy：节点的“网络代理”

kube-proxy是运行在每个工作节点上的网络代理程序，负责实现K8s的Service功能，处理节点上的网络规则，实现Pod之间、Pod与外部客户端之间的通信。

kube-proxy的核心作用：

- 负载均衡：将Service的请求分发到后端的Pod上，实现负载均衡；

- 网络转发：实现Pod之间的通信，以及外部客户端对Pod的访问；

- 维护网络规则：根据Service的配置，动态更新节点上的iptables或ipvs规则，确保网络通信的正常。

（3）容器运行时（Container Runtime）

容器运行时是负责运行容器的软件，K8s支持多种容器运行时，如Docker、containerd、CRI-O等，其中Docker是最常用的容器运行时（虽然K8s在1.24版本后移除了对Docker的直接支持，但依然可以通过containerd间接支持Docker）。

容器运行时的核心作用：接收kubelet的指令，拉取容器镜像、创建容器、启动容器、停止容器，负责容器的实际运行和管理。

3. 组件协同流程：以部署一个Pod为例

为了让大家更好地理解K8s各组件之间的协同工作流程，我们以“用户部署一个Pod”为例，拆解整个流程：

1. 用户通过kubectl命令（或API请求）向kube-apiserver发送部署Pod的请求，请求中包含Pod的配置信息（如镜像、副本数量、资源需求）；

2. kube-apiserver验证请求的合法性（如用户权限、配置格式），验证通过后，将Pod的配置信息存储到etcd中；

3. kube-scheduler通过监听kube-apiserver的事件，发现有新的Pod需要调度，于是从etcd中获取Pod的配置信息和集群节点的状态信息；

4. kube-scheduler根据调度策略，选择一个最合适的工作节点，将调度结果（Pod分配到哪个节点）发送给kube-apiserver；

5. kube-apiserver将调度结果存储到etcd中，并通知该工作节点上的kubelet；

6. 该工作节点上的kubelet接收指令，通过容器运行时拉取Pod所需的镜像，创建容器，启动Pod；

7. kubelet实时监控Pod的运行状态，将状态信息汇报给kube-apiserver；

8. kube-apiserver将Pod的状态信息更新到etcd中，用户通过kubectl命令查看Pod状态时，kube-apiserver从etcd中获取信息并返回给用户。

整个流程中，各组件分工明确、协同工作，确保Pod能够顺利部署和运行，同时实现了集群的自动化管理。