k8s pod resources:{}设置的含义及说明
作者：岳来
一、resources: {} 含义
未声明资源请求和限制：
当 Pod 的 resources 字段设置为 {}，表示该 Pod 未声明任何 CPU 和内存的请求（requests）或限制（limits）。
- 无资源保障：Kubernetes 不会为该 Pod 保证任何 CPU 或内存资源（即 requests 未定义）。
- 无资源上限：Pod 可以使用节点上剩余的 CPU 和内存，但 不能超过节点的物理资源总量（即使未设置 limits，系统仍会通过 QoS 策略限制其优先级）。
QoS 级别为 BestEffort：
根据 Kubernetes 的服务质量（QoS）分类，未设置 requests 的 Pod 被归类为 BestEffort（最低优先级）。
- 优先级最低：在资源不足时，BestEffort Pod 会被优先驱逐（OOM Killer 或调度器拒绝调度）。
- 仅使用剩余资源：只能使用节点上未被其他 Pod 的 requests 占用的资源。
二、不设置是可以无限使用机器资源吗？
并不是。Pod 的资源使用仍受以下约束：
- 节点物理资源上限：Pod 的资源使用不能超过节点的 CPU 和内存总量。
- 系统保留资源：Kubernetes 会为系统组件（如 kubelet、容器运行时）保留部分资源，剩余资源由 Pod 竞争。
- 其他 Pod 的请求：设置了 requests 的 Pod 会优先获得其声明的资源，剩余资源才会被 BestEffort Pod 使用。
那么，pod 资源使用有什么优先级吗？当然有！
三、资源分配的优先级规则
当节点资源紧张时，Kubernetes 根据 QoS 级别 决定资源分配顺序：
| QoS级别 | 定义 | 资源保障 | 优先级 |
|---|---|---|---|
| Guaranteed | requests == limits 且所有资源均被声明 | 系统强制保障其 requests | 最高（优先保护） |
| Burstable | requests < limits 或仅声明 requests | 保障 requests，超出部分需竞争 | 中等（剩余资源可使用） |
| BestEffort | 未声明任何资源（resources: {}） | 无保障 | 最低（可能被驱逐） |
具体分配逻辑：
优先保障高 QoS Pod：
- 系统首先满足 Guaranteed 和 Burstable Pod 的 requests 需求。
- 剩余资源由所有 Pod（包括 BestEffort）竞争使用。
资源不足时的驱逐顺序：
当节点资源耗尽时，Kubernetes 会优先终止 BestEffort Pod（QoS 最低），以保障高优先级 Pod 的资源需求。
四、如何设置尽可能避免被驱逐
首先言明，任何一种QoS都有可能被驱逐。
| QoS 级别 | 驱逐顺序 | 是否可能被驱逐 |
|---|---|---|
| BestEffort | 最先被驱逐 | 是（资源不足时优先被终止） |
| Burstable | 在 BestEffort 之后驱逐，但 可能在极端情况下被驱逐 | 是（资源极度紧张时） |
| Guaranteed | 最后被驱逐，但并非绝对安全 | 是（极端情况下，如节点崩溃） |
具体逻辑如下：
BestEffort Pod：
- 优先被驱逐，因为其 QoS 级别最低，且无资源请求保障。
Burstable Pod：
在资源极度紧张（如节点内存耗尽）时，可能因超出 limits 或系统强制回收资源而被驱逐。例如：
- 如果 Pod 的内存使用超过 limits，会被 OOM Killer 终止。
- 当节点资源完全耗尽（如内存不足），Kubernetes 会按优先级逐步驱逐 Pod。
Guaranteed Pod：
通常不会被驱逐，因为其 requests == limits，系统会尽力保障其资源。但以下极端情况下仍可能被驱逐：
- 节点崩溃或硬件故障：如节点宕机，所有 Pod 均会被终止。
- 资源总量不足：如果节点总资源（如 CPU 或内存）无法满足所有 Guaranteed Pod 的 requests（例如调度器误调度），则可能触发驱逐。
如上，Guaranteed最安全，只有节点崩溃情况下才会被驱逐，其次是Burstable，最不安全的是BestEffort，故要避免被驱逐，最好不要设置成BestEffort。
五、limits 和requests 的含义
- requests 是资源调度的“入场券”：决定 Pod 是否能被调度到节点。
- limits 是资源使用的“天花板”：防止 Pod 占用过多资源影响其他应用。
- QoS 级别决定生存优先级：合理配置可避免资源争抢和意外驱逐。
5.1、含义
requests（资源请求）：
定义 Pod 运行所需的最小资源保障。
- Kubernetes 调度器根据 requests 确定 Pod 可调度到的节点。
- 节点必须提供至少 requests 指定的资源量，否则 Pod 无法调度到该节点。
- 作用：确保 Pod 启动时获得基本资源，避免因资源不足崩溃。
limits（资源限制）：
定义 Pod 允许使用的最大资源量。
- 当 Pod 资源使用超过 limits 时，Kubernetes 会通过限制或终止 Pod 防止资源滥用。
- 作用：防止 Pod 占用过多资源影响其他应用。
5.2、不同设置的含义及影响
| 设置组合 | QoS 级别 | 含义与影响 |
|---|---|---|
| requests 和 limits 均设置 | Guaranteed | 资源保障：requests 和 limits 相等或 requests ≤ limits。 优先级最高：资源不足时最后被驱逐。 示例：requests.cpu=1, limits.cpu=1 → 确保始终获得 1 核 CPU。 |
| 仅设置 requests | Burstable | -资源保障：requests 定义最小资源，limits 未设置则默认为节点最大资源。- 优先级中等：资源不足时在 BestEffort 后驱逐。 示例：requests.memory=512Mi → 保证 512 MiB 内存，但可使用剩余资源。 |
| 仅设置 limits | Burstable | - 不推荐：requests 未设置时，requests 默认为 0。 - 与未设置资源类似，QoS 级别为 Burstable，但资源保障不足。 |
| 均不设置 | BestEffort | - 无资源保障：仅在节点资源充足时使用剩余资源。 - 优先级最低：资源不足时最先被驱逐。 |
5.3、哪些设置是有风险或者错误的
未设置 requests：
Pod 可能因资源不足被调度到无法运行的节点（例如节点内存不足但未声明 requests）。
limits < requests：
配置无效，Kubernetes 会以 requests 为准，limits 被忽略。
过度设置 requests：
可能导致节点资源碎片化，其他 Pod 无法调度。
未设置 limits：
Pod 可能占用过多资源，影响其他高优先级应用（如 Burstable Pod 的内存无上限）。
5.4、 资源调度与驱逐规则
调度规则：
- 调度器确保节点的 总可用资源 ≥ 所有 Pod 的 requests 总和。
- 若节点资源不足，Pod 会被标记为 Pending 直到资源可用。
资源使用与限制：
CPU：
- requests：Pod 可稳定使用的 CPU 资源。
- limits：超过 limits 时会被 CPU 限制（如降速）。
内存：
- requests：Pod 可稳定使用的内存。
- limits：超过 limits 时会被 OOM Killer 终止。
驱逐顺序：
- BestEffort → 2. Burstable → 3. Guaranteed
- Guaranteed Pod 例外：若节点资源完全耗尽（如内存不足），仍可能被
OOM Killer终止。
5.5、典型场景
| 场景 | 配置建议 | 说明 |
|---|---|---|
| 关键服务（如数据库） | requests == limits（Guaranteed） | 确保资源隔离，避免因资源波动导致服务不稳定。 |
| 普通应用（如 Web 服务） | 设置 requests，并适当设置 limits（Burstable） | 允许短暂超限，但防止资源滥用。 |
| 测试 Pod | resources: {}（BestEffort） | 仅用于低优先级任务，资源不足时可容忍终止。 |
5.6、最佳实践
始终设置 requests：
- 确保 Pod 被调度到有足够资源的节点。
合理设置 limits：
- 对关键服务设置 requests == limits（Guaranteed）。
- 对普通应用设置 limits 防止资源滥用。
监控资源使用：
- 使用 Prometheus 或 Metrics Server 监控实际资源使用，调整配置。
避免过度声明：
- 过度声明 requests 会降低集群资源利用率。
5.7、常见问题
Q1 :设置 requests 但未设置 limits 会怎样？
- Pod 可使用节点上所有剩余资源（不超过节点物理限制），但无上限保护。
- QoS 级别为 Burstable，资源不足时可能因超限被 OOM Killer 终止。
Q2: limits 是否能超过节点资源？
- 否：limits 的总和不能超过节点的物理资源，否则 Pod 无法调度。
Q3: 如何避免 Pod 被驱逐？
- 设置合理的 requests（至少满足应用基线需求），并确保节点资源充足。
- 关键 Pod 使用 Guaranteed 类型。
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。