3. 资源模型与 QoS：Requests/Limits 机制、三种 QoS 类别与资源超卖原理

Kubernetes 的资源模型是调度与隔离的基石。理解 Requests（请求量）与 Limits（上限）的语义差异，以及由此衍生的三种 QoS（服务质量）类别，是进行容量规划与准入控制的前提。本节将拆解资源模型的核心概念，并揭示节点资源超卖的底层逻辑。

3.1 Requests 与 Limits：承诺与边界

每个容器在 Pod 定义中可声明两类资源约束：

3.2 三种 QoS 类别：从 Guaranteed 到 BestEffort

K8s 根据 Pod 内所有容器的 Requests/Limits 配置组合，将 Pod 划分为三个 QoS 等级。等级决定了节点资源竞争时的驱逐优先级与 OOM 分数。

3.3 资源超卖原理：如何安全地“多塞”Pod

资源超卖（Overcommit）是指节点上所有 Pod 的 Requests 总和超过节点实际可分配资源。K8s 默认允许超卖，但依赖 QoS 机制来管理风险。

超卖的核心逻辑：

• CPU 超卖安全：CPU 是可压缩资源，超卖时通过 CFS 配额节流，不会导致进程崩溃，只会降低性能。
• 内存超卖危险：内存是不可压缩资源，超卖时一旦实际使用量超过节点容量，必须通过 OOM Killer 杀死容器来释放内存。
• QoS 保护链：BestEffort → Burstable → Guaranteed 的驱逐顺序，确保关键业务在内存压力下存活。

3.4 超卖策略与准入控制实践

在生产环境中，超卖不是“能不能”的问题，而是“如何控制”的问题。以下策略可帮助团队在利用率和稳定性之间取得平衡：

• 设置超卖比例上限：通过准入控制器（如自定义 ValidatingAdmissionWebhook）限制节点超卖比不超过 1.5x（CPU）和 1.2x（内存）。
• 区分资源类型：CPU 可超卖至 2x-3x，内存建议不超过 1.2x，且必须配合 Guaranteed Pod 的内存预留。
• 使用 PriorityClass 配合 QoS：高优先级 Pod 即使 QoS 为 Burstable，也应通过 PriorityClass 确保在驱逐顺序中靠后。
• 监控实际使用率：超卖决策不能仅依赖 Requests，需结合 Prometheus 采集的容器实际 CPU/Memory 使用量动态调整。

# 示例：ValidatingAdmissionWebhook 检查 Pod 超卖比例
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: overcommit-check
webhooks:
  - name: overcommit.overcommit.example.com
    rules:
      - operations: ["CREATE"]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
    clientConfig:
      service:
        name: overcommit-webhook
        namespace: kube-system
        path: /validate-overcommit
    admissionReviewVersions: ["v1"]
    sideEffects: None

3.5 三种 QoS 的典型配置示例

# Guaranteed QoS：Requests == Limits
apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        memory: "512Mi"
        cpu: "1"
      limits:
        memory: "512Mi"
        cpu: "1"

# Burstable QoS：Requests < Limits
apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "0.5"
      limits:
        memory: "1Gi"
        cpu: "2"

# BestEffort QoS：无资源设置
apiVersion: v1
kind: Pod
metadata:
  name: besteffort-pod
spec:
  containers:
  - name: app
    image: busybox
    command: ["sleep", "3600"]

3.6 超卖风险与缓解措施