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

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



1. 资源限制配置示例



• 

1）CPU单位换算

• 单位换算规则：
  • 1核CPU = 1000m（毫核）
  • 2核CPU = 2000m
  • 0.5核 = 500m
  • 0.1核 = 100m
• 表示方式：
  • 可直接使用浮点数（如0.5）
  • 也可使用毫核单位（如500m）
  • 两者等价：

    0.5=500m0.5=500m0.5=500m

    ，

    1=1000m1=1000m1=1000m

2）资源配置参数

• 
• requests：
  • 容器请求的基础资源（预留资源）
  • 调度依据：K8s根据requests值选择有足够资源的Node
  • 示例：requests: memory: "64Mi", cpu: "250m"
• limits：
  • 容器最大可用资源上限
  • 示例：limits: memory: "128Mi", cpu: "500m"

3）配置比例建议

• 黄金比例：
  • request应小于limit的20%-30%（推荐值）
  • request绝对不允许大于limit
• 计算示例：
  • 当request.cpu=0.5时，limit.cpu建议=0.7（增加40%）
  • 当request.memory=256Mi时，limit.memory建议=350Mi（增加约37%）
• 设计原则：
  • 多副本轻量化优于少副本高配
  • 通过增加Pod数量扩展并发能力

4）完整配置示例

apiVersion: v1
kind: Pod
metadata:name: pod1
spec:containers:- image: nginxname: pod1resources:requests:memory: "256Mi"cpu: "0.5"limits:memory: "350Mi"cpu: "0.7"

2. 容器资源限制与查看

1）CPU资源单位与配置

• 计量单位：
  • 毫核(m)是Kubernetes中CPU的计量单位
  • 1核=1000m，0.5核=500m，0.1核=100m
  • 支持浮点数表示法(如0.5)和毫核表示法(如500m)
• 配置规则：
  • Request值应小于Limits值的20%-30%(推荐比例)
  • Request值绝对不能大于Limits值

2）资源查看方法

• 
• describe命令：
  • 通过kubectl describe pod <pod名称>查看详细配置
  • 显示内容包括实际生效的CPU/内存限制值
• 节点资源查看：
  • 使用kubectl describe node <节点名>查看节点资源分配情况
  • 可获取节点总资源和已分配资源数据

3）资源分配原理

• 抽象资源池：
  • Kubernetes将多个节点抽象为统一资源池
  • 实际物理资源不共享(与公有云虚拟化不同)
  • 调度基于节点的Allocatable资源值
• 调度机制：
  • 创建Pod时根据request值寻找满足条件的节点
  • 节点资源耗尽后无法调度新Pod(如2核节点已分配1.5核request)

4）实际案例分析

• 
• 资源监控要点：
  • Allocated resources显示已分配资源占比
  • 示例：750m/2000m(37%)表示已分配37%CPU资源
  • Limits可能超过100%(超卖情况)
• 配置建议：
  • 对外服务Pod必须配置资源限制
  • 内部可控服务可不配置(但存在风险)
  • 系统组件(如calico)通常只配置request

5）配置示例

• YAML配置模板：

resources:requests:memory: "64Mi"cpu: "250m" limits:memory: "128Mi"cpu: "500m"

• 关键参数：
  • requests：调度依据，保证最小资源
  • limits：硬性限制，防止资源耗尽

3. 资源配额配置示例



1）资源请求与限制的基本概念

• CPU单位换算：
  • 1核 = 1000m（毫核）
  • 2核 = 2000m
  • 0.5核 = 500m
  • 0.1核 = 100m
• 资源分配原则：
  • request值应小于limits值20%-30%（推荐）
  • request不能大于limits值
  • 节点上limits值不能超过宿主机实际物理配置的20%，否则限制就失去意义

2）资源配额验证实验

• 
• 实验现象：
  • 当设置request(800m) > limits(700m)时，系统会报错"must be less than or equal to cpu limit"
  • 验证了Kubernetes对资源请求的逻辑性约束
• 特殊案例：
  • 在2核节点上设置limits为3核时，Pod仍能创建成功
  • 但实际使用时会导致节点资源过载（显示150% CPU使用率）

3）资源配额最佳实践

• 配置建议：
  • limits最大值建议不超过宿主机实际资源的80%
  • 预留20%资源供系统和其他程序使用
  • 例如2核CPU节点，limits建议不超过1.7-1.8核
• 配置意义：
  • 防止单个容器占用过多资源影响节点稳定性
  • 确保系统有足够资源处理突发情况
  • 实现资源使用的合理限制而非完全放任

4）节点资源查看方法

• 查看命令：
  • kubectl describe node <节点名>
  • 可查看已分配资源(Allocated resources)和事件(Events)
• 关键指标：
  • Requests：容器保证能获得的资源量
  • Limits：容器最大能使用的资源量
  • 百分比表示占节点总资源的比例

4. 资源配额配置示例

1）Pod资源配置规范

• 基本结构：
• 单位规范：
  • 1核CPU =1000m（毫核）
  • 0.5核 =500m
  • 0.1核 =100m

2）资源配置原则

• requests与limits关系：
  • requests应小于limits 20%-30%（推荐比例）
  • 禁止：request值不能大于limits值
• 节点限制：
  • limits总值不应超过宿主机实际物理配置的80%
  • 超过宿主机20%的limits设置将失去限制意义

3）资源调度机制

• 调度原理：
  • Kubernetes将多个节点作为抽象资源池统一管理
  • 调度时检查所有节点的可用资源是否满足Pod的requests要求
• 实际案例：
  • 当配置requests.cpu=2时：
    • 需要节点有2核可用资源
    • 若所有节点已分配47%/37%资源（约1核），则无法满足调度

4）资源预留特性

• request本质：
  • 是预留性质的请求值，非实际占用
  • 示例：节点显示37%使用率时，实际CPU占用远低于该值
• 调度影响：
  • 直接影响Pod的节点分配决策
  • 当节点剩余资源<requests时，Pod将处于Pending状态
  • 

5）实践验证

• 验证方法：
  • 通过kubectl describe node查看节点资源分配情况
  • 关键字段：
• 典型错误：
• 

5. 内容总结

1）Kubernetes资源请求与限制配置

• request与limit的关系:
  • request必须小于limit的20%-30%（推荐比例）
  • request绝对不能大于limit（存在约束限制）
• 节点limits配置原则:
  • 节点上limits值不建议超过宿主机物理配置
  • 超过物理配置20%时限制将失去意义
  • 建议配置不超过宿主机物理资源的80%

2）资源请求(request)特性

• 
• 调度性质:
  • 是预留性质而非实际占用
  • 作为资源调度的参考值
  • 只会分配到满足request配置的节点
• 异常情况:
  • 当没有节点能满足request时，Pod将处于Pending状态
  • request值设置过大会导致宿主机资源浪费

3）资源池概念

• 抽象资源池:
  • Kubernetes将多个节点作为抽象资源池管理
  • 统一管理所有节点的资源
  • 调度时参考request值进行分配

4）实际配置示例

• CPU单位表示:
  • 可以使用m（毫核）或浮点数表示

  • 0.5=500m

  • 1=1000m

• 内存单位表示:
  • 使用Mi（兆字节）等单位
  • 示例配置中为"64Mi"和"128Mi"

5）调度场景分析

• 节点选择逻辑:
  • 示例：request 1核 limit 3核
  • node1配置2核，node2配置4核
  • 会优先分配到node2（资源更充足）
• 特殊说明:
  • limits值可以超过节点实际配置（但会失去限制意义）
  • 影响调度的关键因素是request值
  • 调度算法会考虑节点空闲资源，但不是唯一因素

二、知识小结

知识点	核心内容	配置要点/易错点	重要性
Nginx内存配置	常规运行建议256MB-512MB内存	- 测试环境建议256MB - 生产环境根据流量调整	⭐⭐⭐⭐
CPU单位换算	1核=1000m单位 0.5核=500m	- 支持直接写核数(如0.5)或m单位 - 调度时自动转换为m单位	⭐⭐⭐⭐
Request/Limit关系	Request ≤ Limit的70-80% Limit建议≤节点资源的80%	- Request>Limit会创建失败 - Limit超节点容量无实际约束	⭐⭐⭐⭐⭐
资源调度机制	基于Request值进行节点选择	- 无满足节点时Pod处于Pending状态 - Request非实际占用资源	⭐⭐⭐⭐⭐
配置误区	- Limit超过节点物理资源 - Request设置过大	- 会导致资源浪费 - 可能触发节点过载	⭐⭐⭐⭐
最佳实践	- 多副本替代大资源配置 - 预留20%宿主机资源	- 通过kubectl describe node查看分配情况	⭐⭐⭐⭐