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机制减少轮询 |