20250720-2-Kubernetes 调度-资源限制对Pod调度的影响（1）_笔记

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

1. k8s架构解析



• 
• 组件交互模式: Kubernetes采用list-watch机制的控制器架构，实现组件间交互的解耦。各组件通过监控自己负责的资源，当资源发生变化时由kube-apiserver通知相关组件。
• 类比说明: 类似小卖铺场景，API Server相当于老板，其他组件(控制器、调度器、kubelet)相当于学生。当有新Pod需要处理时，API Server会主动通知对应组件，避免组件不断轮询检查的低效行为。
• 架构特点:
  • 各组件之间不直接通信，全部通过API Server进行协调
  • 采用发布-订阅模式实现事件通知
  • 相比轮询机制更高效，是现代事件通知系统的常见实现方式

二、Pod中影响调度的主要属性



• 

1. 资源配额与调度依据



• 资源配置: 通过resources字段设置容器的CPU和内存资源限制
  • 示例配置：requests: memory: "64Mi" cpu: "250m" 和 limits: memory: "128Mi" cpu: "500m"
  • CPU单位：可以写m(毫核)或浮点数，如

    0.5=500m0.5=500m0.5=500m，1=1000m1=1000m1=1000m

• 调度影响: 调度器会根据requests值判断节点是否有足够资源容纳Pod

2. 调度器名称与自定义调度器



• 默认调度器: 通过schedulerName: default-scheduler指定
• 自定义调度器: Kubernetes支持多个调度器并存，可通过指定不同调度器名称使用自定义调度逻辑

3. 节点选择器(nodeSelector)



• 匹配机制: 基于节点标签进行调度匹配，Pod只会被调度到带有指定标签的节点上
• 使用场景: 简单场景下的节点定向调度

4. 亲和性(affinity)



• 功能: 可配置节点亲和性和Pod亲和性，通过约束条件控制Pod在集群中的分布
• 优势: 比nodeSelector提供更灵活的调度控制能力

5. 污点与污点容忍(tolerations)



• 污点机制: 控制Pod不在哪些节点上运行
• 容忍机制: 允许Pod在特定条件下运行在污点节点上

6. 调度器筛选与打分机制



• 筛选阶段: 调度器首先排除不满足Pod配置要求的节点
• 打分阶段: 对符合条件的节点进行评分，选择最优节点
• 考虑因素:
  • 节点空闲资源情况
  • 服务质量要求
  • 其他调度策略(如尽量打散Pod分布)
  • 不会简单追求各节点均匀分配Pod

三、资源限制对Pod调度的影响

1. 资源限制容器的创建



• 创建命令：使用kubectl run命令创建容器，示例创建名为part1的nginx容器
• 资源配置项：
  • limits：定义容器最大使用的CPU和内存资源
  • requests：定义容器请求的基础资源量
• 配置方法：通过YAML文件中的resources字段进行定义，需结合应用程序实际需求设置

2. 资源请求对调度的影响

1）资源请求的理解



• 本质含义：request代表容器向集群请求的基础资源量
• 调度影响：决定Pod能否被调度到某个节点的关键因素
• 配置示例：在YAML中通过requests.cpu和requests.memory字段定义

2）预留资源的概念



• 核心定义：request是K8s层面的资源预留机制
• 工作方式：节点分配Pod时，会预先扣除request指定的资源量
• 实际占用：预留资源未被实际占用，其他Pod无法使用这部分资源

3）预留资源与最小使用资源的区别



• JVM示例：
  • 最小资源：像JVM配置的-Xms参数，物理内存立即被占用
  • 预留资源：仅做逻辑预留，实际使用可能低于request值
• 关键区别：
  • 最小资源：立即物理分配，不可回收
  • 预留资源：逻辑预留，实际使用动态变化

4）预留资源在K8s调度中的作用



• 调度逻辑：
  • 节点剩余资源 = 总资源 - 所有Pod的request总和
  • 新Pod的request必须 ≤ 节点剩余资源才能调度
• 示例说明：2核4G节点上预留512M内存后，剩余3.5G可供其他Pod使用

5）预留资源的配置方法



• 
• 配置原则：
  • 应设置为应用常规运行所需的基本资源量
  • 需要结合应用实际资源使用特征进行调整
• 配置建议：
  • 初始可设置较小值，根据监控逐步优化
  • 典型场景：nginx等轻量应用可设置较低request值

四、知识小结

知识点	核心内容	考试重点/易混淆点	难度系数
API Server角色	类比小卖铺老板，作为核心协调组件，所有组件(学生)都需通过API Server交互	组件间无直接通信，必须通过API Server中转	⭐⭐
List-Watch机制	事件通知架构，避免组件轮询查询(学生不用来回跑)，通过监听API Server事件触发动作	与轮询机制对比理解，事件驱动更高效	⭐⭐⭐
调度器工作原理	1. 筛选符合基本配置的节点 2. 对候选节点打分评级 3. 分配Pod到最优节点	不会均匀分配，考虑节点空闲率/配置差异/服务质量等多维度	⭐⭐⭐⭐
影响调度的6大因素	1. 资源配额(resources) 2. 指定调度器(schedulerName) 3. 节点名称(nodeName) 4. 节点标签选择器(nodeSelector) 5. 亲和性(affinity) 6. 污点容忍(tolerations)	resource.requests≠limits：requests是预留资源，limits是硬限制	⭐⭐⭐⭐
资源限制配置	- limits：容器资源使用上限 - requests：调度预留资源(非实际占用)	OOM风险：内存超限会被Kill，CPU超限会被限流	⭐⭐⭐
资源耗尽影响	节点资源利用率>90%时会导致： - 服务响应延迟 - SSH操作卡顿 - 整体服务不可用	需配置合理limits防止单Pod拖垮节点	⭐⭐⭐
多调度器机制	可通过schedulerName字段指定自定义调度器，支持多调度器共存	默认调度器名称：default-scheduler	⭐⭐
控制器协作模式	各控制器(Deployment/StatefulSet等)通过API Server获知资源变更，独立完成闭环控制	控制器之间无直接交互	⭐⭐⭐