金属网站模板石家庄做网站公司

一、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 类型。