理解 K8s 工作原理，关键是理清控制平面（决策层） 与节点组件（执行层） 的交互逻辑。下面通过「控制平面协作」「Pod 创建」「Service 服务发现」三个核心场景，用文字流程图拆解各组件的分工与数据流向，内容简洁直观，适合直接嵌入博客。

场景 1：控制平面组件协作（集群“大脑”的协同逻辑）

控制平面是 K8s 的“决策中心”，负责管理集群状态、接收请求、调度资源，核心是「API Server 为枢纽，etcd 为存储，其他组件各司其职」。

文字流程图

1. API Server 启动初始化：作为集群“入口网关”，启动后立即与 etcd 建立连接，成为 etcd 唯一的读写入口；同时监听客户端（如 `kubectl`、UI 工具）的请求。 

2. etcd 存储集群数据：仅接收 API Server 的数据读写请求，存储集群所有配置（如 Pod 模板、Service 规则）和状态（如 Pod 运行状态），不与其他组件直接交互。 

3. Scheduler 监听调度需求：启动后持续向 API Server 发起请求，筛选“未调度的 Pod”（即 `spec.nodeName` 为空的 Pod），一旦发现则执行调度逻辑。 

4. Controller Manager 维护集群状态：启动后运行各类控制器（如 ReplicaSet Controller、Node Controller），持续监听 API Server 中“集群期望状态”（如 Pod 副本数=3）与“实际状态”（如当前副本数=2）的差异，若有差异则发起调谐（如创建新 Pod）。 

5. 状态变更统一同步：无论是 Scheduler 完成 Pod 调度（绑定 Node），还是 Controller Manager 执行调谐（创建 Pod），最终都需通过 API Server 将结果写入 etcd，确保集群数据一致。 

场景 2：Pod 创建全流程（从“提交 YAML”到“容器运行”）

Pod 是 K8s 最小部署单元，其创建流程覆盖“请求提交→调度→容器启动”全链路，是理解组件协作的核心。

文字流程图

1. 用户提交创建请求：通过 `kubectl apply -f pod.yaml` 提交 Pod 创建指令，请求直接发送到 API Server。 

2. API Server 校验与存储： 

   - 先校验请求合法性（如 YAML 字段是否完整、资源限制是否合理）； 

   - 校验通过后，将 Pod 的“期望状态”（如镜像名、CPU 限制、端口）写入 etcd，此时 Pod 标记为“未调度”。 

3. Scheduler 完成 Pod 调度： 

   - Scheduler 持续监听 API Server，发现“未调度的 Pod”后，执行调度算法（筛选逻辑：先匹配资源需求，再检查亲和性/污点容忍，最后选最优 Node）； 

   - 调度完成后，将“Pod 绑定的 Node 名称”（如 `spec.nodeName=node-1`）通过 API Server 写入 etcd，Pod 标记为“已调度”。 

4. Kubelet 启动容器： 

   - 目标 Node（如 node-1）上的 Kubelet 持续监听 API Server，发现“分配给自己的 Pod”后，读取 Pod 详细配置； 

   - Kubelet 调用容器运行时（如 containerd），执行“拉取镜像→创建容器→启动容器”操作； 

   - 容器启动成功后，Kubelet 将 Pod 的“实际状态”（如 `status=Running`）上报给 API Server。 

5. API Server 更新最终状态：接收 Kubelet 上报的 Pod 实际状态，将其写入 etcd；同时向用户反馈“Pod 创建成功”（如 `kubectl get pod` 显示 `Running`）。 

场景 3：Service 服务发现与流量转发（解决 Pod IP 漂移问题）

Pod 会动态创建/销毁（如扩缩容、节点故障），IP 会频繁变化。Service 通过“固定访问地址”解决此问题，核心是 Kube-proxy 维护网络规则。

文字流程图

1. 用户创建 Service：通过 `kubectl apply -f service.yaml` 提交 Service 配置（如 `type: ClusterIP`、`selector: app=nginx`），请求发送到 API Server。 

2. API Server 存储 Service 规则：校验配置合法性后，将 Service 的“固定访问地址”（如 ClusterIP=10.96.0.10）、“端口映射”（如 80→8080）、“Pod 选择器”写入 etcd。 

3. Kube-proxy 同步网络规则：所有 Node 上的 Kube-proxy 持续监听 API Server，获取 Service 与 Pod 的关联关系（通过 selector 匹配 Pod IP）；随后在本地创建网络规则（如 iptables/IPVS），规则内容为“将 Service 地址+端口的流量，转发到匹配的 Pod IP+端口”。 

4. 集群内 Pod 访问 Service：集群内其他 Pod（如客户端 Pod）通过“Service ClusterIP+端口”发起请求，流量到达 Node 网络层后，自动匹配 Kube-proxy 配置的规则，负载均衡到后端 Pod。 

5. 外部客户端访问 Service： 

   - 若 Service 类型为 `NodePort`：Kube-proxy 在每个 Node 上开放一个“节点端口”（如 30080），外部客户端通过“Node IP:节点端口”访问，流量经网络规则转发到 Pod； 

   - 若 Service 类型为 `LoadBalancer`：云厂商负载均衡器（如 AWS ELB）自动绑定所有 Node 的 NodePort，外部客户端访问负载均衡器地址，流量由负载均衡器分发到 Node，再转发到 Pod。