4. Kubernetes 资源管理基础：Pod 资源请求与限制、服务质量(QoS)等级、资源配额与限制范围

在云原生环境中，资源管理是成本优化与容量规划的基石。Kubernetes 通过 资源请求与限制、服务质量(QoS)等级 以及 资源配额与限制范围 三大机制，确保集群资源被合理分配、避免资源争抢，并为后续基于 Cilium 网络策略的精细化成本控制提供数据基础。理解这些概念，是制定高效容量规划方案的第一步。

4.1 Pod 资源请求与限制

每个 Pod 中的容器都可以声明两类资源参数：requests（请求）和 limits（限制）。

• requests：调度器依据此值为 Pod 选择节点，确保节点剩余资源满足请求值。它是 Pod 启动的“最低保障”。
• limits：kubelet 在运行时强制限制容器不能超过此值。当容器试图使用超过 limits 的 CPU 时，会被节流；超过内存 limits 时，可能被 OOM Kill。

以下是一个典型的 Pod 资源声明示例：

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "500m"
      limits:
        memory: "512Mi"
        cpu: "1000m"

4.2 服务质量(QoS)等级

Kubernetes 根据 Pod 中所有容器的 requests 和 limits 配置，自动为每个 Pod 分配一个 QoS 等级。该等级决定了节点资源紧张时 Pod 被驱逐的优先级。

4.3 资源配额与限制范围

在多租户或团队共享集群的场景下，仅靠 Pod 级别的资源声明不足以防止资源滥用。ResourceQuota 和 LimitRange 提供了命名空间级别的资源管控能力。

4.3.1 ResourceQuota（资源配额）

ResourceQuota 用于限制命名空间内所有 Pod 的资源总量上限，包括 CPU、内存、存储卷数量、PVC 数量、Service 数量等。它防止单个团队或项目消耗过多集群资源。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    persistentvolumeclaims: "10"
    pods: "50"

4.3.2 LimitRange（限制范围）

LimitRange 为命名空间内未显式设置资源请求/限制的 Pod 或容器提供默认值，并设置最小/最大约束。它确保每个 Pod 都遵循统一的资源规范，避免出现极端配置。

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: team-a
spec:
  limits:
  - max:
      cpu: "2"
      memory: "2Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    type: Container

4.4 资源管理对成本优化的影响

在 Cilium 网络策略驱动的成本优化方案中，资源管理数据是容量规划的直接输入：

• 资源利用率分析：通过 requests 和 limits 计算命名空间的实际资源消耗，识别过度配置或低利用率 Pod。
• QoS 等级与网络策略联动：Guaranteed Pod 通常承载关键业务，Cilium 网络策略应为其提供高优先级网络路径；BestEffort Pod 可被限制带宽或延迟敏感度。
• 配额驱动的容量规划：ResourceQuota 定义了团队资源上限，容量规划需基于此上限进行节点扩缩容决策，避免超卖。