20250720-1-Kubernetes 调度-白话理解创建一个Pod的内部工作流_笔记

一、创建一个Pod的工作流程



1. 创建一个Pod的工作流程



1）Kubernetes架构与组件



• 
• list-watch机制: Kubernetes基于list-watch机制的控制器架构，实现组件间交互的解耦。各组件通过监控自己负责的资源变化实现协作。
• 发布订阅模式: 当资源发生变化时，kube-apiserver会通知相关组件，这个过程类似于发布与订阅模式。

2）创建Pod的命令与响应



• 命令执行: 使用kubectl run pod-test --image=nginx命令创建Pod，该命令会向API Server提交请求。
• 状态变化: 执行命令后，通过kubectl get pods可以看到Pod状态从"ContainerCreating"变为"Running"。

3）API Server的作用



• 集群入口: API Server是Kubernetes集群的访问入口，所有kubectl命令都会提交给它。
• 请求处理: API Server接收创建Pod请求后，不会立即创建Pod，而是先处理配置信息。

4）etcd存储配置信息



• 数据存储: API Server将创建Pod的配置信息存储到etcd中，etcd是Kubernetes的数据库。
• 响应机制: API Server写入etcd后会收到响应，然后返回"pod/pod-test created"给客户端。

5）调度器选择节点



• 节点发现: 调度器检测到未绑定节点的Pod后，根据自身调度算法选择合适的节点。
• 节点绑定: 调度器会给Pod打标记（如nodeName=k8s-node1），并将绑定信息通过API Server写入etcd。

6）kubelet创建容器



• 
• 容器创建: kubelet通过API Server发现有分配到本节点的新Pod后，调用Docker API创建容器。
• 状态上报: 容器创建完成后，kubelet将容器状态上报给API Server，API Server再写入etcd。

7）更新Pod状态与etcd



• 状态同步: kubelet上报的Pod状态会通过API Server同步到etcd中存储。
• 数据完整性: etcd中存储了Pod创建时的配置信息和运行时的状态信息。

8）kubectl get命令获取Pod列表



• 
• 数据来源: kubectl get pods命令请求API Server获取Pod列表，API Server从etcd中提取数据。
• 显示格式: kubectl将获取的数据结构化显示为表格形式，展示Pod的NAME、READY、STATUS等信息。

2. 创建一个Pod的工作流程的组件分析



1）组件间交互的解耦与list-watch机制



• 解耦原理: 通过list-watch机制实现组件间松耦合，各组件只需监控自己负责的资源
• 通知机制: 资源变化时kube-apiserver会主动通知相关组件，类似发布-订阅模式
• 核心流程: API Server作为中枢，etcd存储状态，Scheduler/Kubelet/Docker协同完成Pod生命周期管理

2）创建一个Pod的基本流程



• 
• 阶段1: kubectl提交Pod配置给API Server，写入etcd存储
• 阶段2: Scheduler检测未绑定Pod，选择节点并打标（如nodename=k8s-node1），回写etcd
• 阶段3: Kubelet调用Docker API创建容器，上报状态到API Server
• 阶段4: kubectl get通过API Server从etcd获取最新状态

3）控制器（Controller Manager）的作用与位置



• 缺失发现: 原始流程图中缺少Controller Manager组件（位于Scheduler之前）
• 干预时机: 当创建Deployment等高级资源时才会介入，直接创建Pod时不参与
• 类比决策: 与Scheduler类似都是决策系统，但管理对象不同（Deployment vs Pod）

4）Controller Manager的管理范围与功能



• 管理对象: 负责Deployment/ReplicaSet等控制器的创建和维护
• 工作流程: 创建Deployment → 生成ReplicaSet → 创建Pod → 触发Scheduler介入
• 层级控制: 通过多级控制器实现声明式API的最终一致性

5）CoreDNS组件的作用与功能



• 节点代理: 每个节点独立运行的网络组件（注意：字幕中误称为"酷跑"应为CoreDNS）
• 核心功能:
  • 管理Pod网络规则
  • 维护Service的DNS解析
  • 实时监听Service变更并更新网络配置
• 触发条件: 创建Service资源时自动介入工作

3. 创建Pod工作流程的场景比喻



1）场景介绍：学校小卖铺

• 系统映射:
  • 小卖铺 → Kubernetes集群
  • 老板 → API Server
  • 仓库 → etcd
  • 学生 → 各组件（Scheduler/Kubelet等）
  • 商品 → 资源对象（Pod/Service等）

2）组件对应角色



• 访问控制: 学生不能直接进仓库（组件不能直接操作etcd）
• 中介作用: 所有交易通过老板完成（API Server是唯一入口）
• 状态同步: 商品库存变化由老板通知（watch机制）

3）场景描述：李四同学买烟



• 低效场景:
  • 学生主动轮询询问商品状态（类比轮询检查）
  • 老板被动响应（无事件通知机制）
• 问题本质: 缺少watch机制导致资源浪费

4）流程优化思考



• 优化方向:
  • 建立商品到货通知系统（实现watch机制）
  • 老板主动通知注册过的学生（事件驱动）
• K8s实践: 通过list-watch避免组件轮询，降低系统负载

二、知识小结

知识点	核心内容	关键概念/易混淆点	技术要点
Kubernetes集群架构	将多台服务器组建为容器集群，通过调度算法分配Pod到节点	Service vs Pod直接访问	API Server作为统一入口，etcd存储集群状态
Pod调度机制	调度器根据算法选择合适节点，无需人工干预	节点分组 vs 全局调度	通过nodeName标记实现绑定
工作流程	1. kubectl run提交API Server 2. 写入etcd 3. 调度器绑定节点 4. kubelet创建容器	声明式API vs 命令式操作	List-Watch机制实现组件解耦
组件协作	- Controller Manager：管理Deployment等控制器 - kube-proxy：维护Service网络规则	控制循环 vs 事件驱动	各组件通过API Server交互
特殊调度场景	- 按团队/部门划分节点 - 特殊硬件节点专供特定Pod使用	节点亲和性 vs 污点容忍	需通过标签选择器实现
状态同步机制	kubelet定期上报容器状态到API Server并写入etcd	期望状态 vs 实际状态	kubectl get从etcd获取最新状态
类比说明	小卖部模型： - 老板=API Server - 仓库=etcd - 学生=组件	主动查询 vs 事件通知	优化方案：采用Watch机制减少轮询