Requests & Limits

在 Kubernetes 中，为 Pod 和容器管理资源主要是通过 Requests（请求） 和 Limits（限制） 来控制 CPU 与内存的使用。这是保证集群稳定性和公平调度的关键机制。

---

🧩 核心概念

• Requests
  👉 表示容器运行时至少需要的资源量。调度器会根据 Requests 来决定 Pod 可以被调度到哪个节点。
• Limits
  👉 表示容器最多能使用的资源量。如果超过限制，可能会被限制或直接终止。
• QoS 类别
  👉 根据 Requests 和 Limits 的设置，Pod 会被划分为不同的 QoS（Quality of Service）等级：
  • Guaranteed：Requests = Limits，保证资源。
  • Burstable：Requests < Limits，允许突发。
  • BestEffort：没有设置 Requests 和 Limits，最低优先级。

---

🧩 Requests 的作用

在 Kubernetes 中，Requests（请求）定义了容器运行时所需的最小资源量，是调度器分配 Pod 到节点的依据。它保证容器至少能获得指定的 CPU 或内存资源，但如果节点空闲，容器可以使用超过 Requests 的资源。

• 调度依据：调度器会根据 Requests 判断 Pod 是否能被放置到某个节点。
• 资源保证：系统会确保容器至少获得 Requests 指定的资源。
• QoS 分类影响：Requests 与 Limits 的关系决定 Pod 的 QoS 等级（Guaranteed、Burstable、BestEffort）。

---

🧩 Limits 的作用

Limits 是 Kubernetes 中用于定义容器可使用的最大资源量的机制。它与 Requests 搭配使用，构成了 Pod 的资源管理体系。

• 资源上限：限制容器最多能使用多少 CPU 和内存。
• 防止资源滥用：避免单个容器占用过多资源影响其他 Pod。
• 强制执行：超过限制时，Kubelet 会采取措施：
  • CPU：超出限制时会被 节流（Throttling）。
  • 内存：超出限制时可能会被 OOM Kill（直接终止）。

---

📝 Requests 与 Limits 的关系

属性	作用	结果
Requests	调度依据，保证最低资源	Pod 至少获得该资源量
Limits	运行时上限，内核强制执行	超过限制会被节流或 OOM Kill
QoS 分类	Requests 与 Limits 的关系决定优先级	Guaranteed、Burstable、BestEffort

---

📌 类比理解

• Requests = 基本工资：保证你至少能拿到这么多。
• Limits = 工资上限：最多只能拿到这么多，不能超出。
• QoS = 员工等级：不同的工资设定决定你在公司里的优先级。

---

📝 使用示例

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: demo
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

👉 这个 Pod 的容器会请求 64Mi 内存和 0.25 CPU，最多可以使用 128Mi 内存和 0.5 CPU。

---

⚠️ 注意事项

• 合理设置 Requests：Requests 太小可能导致性能不足，太大可能导致调度失败。
• 合理设置 Limits：Limits 太小可能导致应用频繁被杀掉，太大可能影响其他 Pod。
• 只设置 Limits：如果没有设置 Requests，Kubernetes 会默认把 Requests 设置为与 Limits 相同。
• CPU 与内存差异：
  • CPU 超过限制时会被 节流。
  • 内存超过限制时可能会被 OOM Kill。
• QoS 分类：不同 QoS 会影响 Pod 在资源紧张时的优先级。
• 监控与优化：结合 Metrics Server 或 Prometheus 监控资源使用情况。

---

💡 总结

• Requests 和 Limits 是 Kubernetes 的 资源管理机制。
• Requests 决定调度，Limits 决定上限。
• QoS 分类保证集群在资源紧张时的公平性。

---

🧩 Quality of Service

在 Kubernetes 中，QoS（Quality of Service，服务质量） 是一种资源管理策略，用来决定 Pod 在资源紧张时的优先级。它由容器的 Requests 和 Limits 的配置情况决定。

---

🧩 QoS 的三种类别

• Guaranteed（保证型）
  👉 当所有容器的 Requests 和 Limits 都设置，并且两者相等时，Pod 属于 Guaranteed。
  • 优先级最高，资源最稳定。
  • 在资源紧张时，Guaranteed Pod 最不容易被驱逐。
• Burstable（可突发型）
  👉 当至少一个容器设置了 Requests，但 Requests 小于 Limits 时，Pod 属于 Burstable。
  • 优先级中等。
  • 在资源紧张时，Pod 至少能保证 Requests 的资源，但可能会被限制在 Limits 范围内。
• BestEffort（尽力而为型）
  👉 当所有容器都没有设置 Requests 和 Limits 时，Pod 属于 BestEffort。
  • 优先级最低。
  • 在资源紧张时，最容易被驱逐。

---

📌 类比理解

• Guaranteed = VIP 客户：有明确的合同（Requests = Limits），保证资源。
• Burstable = 普通客户：有基本保障（Requests），但可以临时多用一些（Limits）。
• BestEffort = 免费用户：没有保障，资源紧张时最先被清理。

---

📝 示例配置

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
spec:
  containers:
  - name: guaranteed-container
    image: nginx
    resources:
      requests:
        cpu: "500m"
        memory: "256Mi"
      limits:
        cpu: "500m"
        memory: "256Mi"
  - name: burstable-container
    image: nginx
    resources:
      requests:
        cpu: "250m"
        memory: "128Mi"
      limits:
        cpu: "500m"
        memory: "256Mi"
  - name: besteffort-container
    image: nginx

👉 在这个 Pod 中：

• 第一个容器属于 Guaranteed。
• 第二个容器属于 Burstable。
• 第三个容器属于 BestEffort。

---

⚠️ 注意事项

• QoS 是 Pod 级别 的分类，而不是容器级别。
• Pod 的 QoS 由所有容器的 Requests 和 Limits 决定。
• 在资源紧张时，驱逐顺序通常是：BestEffort → Burstable → Guaranteed。

---

💡 总结

• QoS 是 Kubernetes 的 资源优先级机制。
• 分为 Guaranteed、Burstable、BestEffort 三类。
• 合理设置 Requests 和 Limits，可以提升 Pod 的稳定性和优先级。