📚 课程目录第2章 K8s资源管理基础

2. K8s资源管理基础：Pod资源请求与限制、QoS类别、节点资源分配单元的概念

在Kubernetes集群中，资源管理是保障应用稳定性与成本效率的基石。本章将深入剖析Pod的资源请求（Requests）与限制（Limits）、服务质量（QoS）类别以及节点资源分配单元（Resource Quota / LimitRange）三大核心概念，为后续的节点碎片整理与FinOps标签治理奠定理论基础。

2.1 Pod资源请求与限制

每个Pod中的容器都可以声明两类资源参数：Requests（请求）和Limits（限制）。Requests用于调度决策，Limits用于运行时压制。

参数	含义	调度影响	运行时行为
requests.cpu	容器保证可用的CPU最小值	节点必须满足所有Pod requests总和 ≤ 节点可分配资源	CPU按requests权重分配时间片，超限时被节流（Throttle）
requests.memory	容器保证可用的内存最小值	节点必须满足所有Pod requests总和 ≤ 节点可分配资源	内存不足时触发OOM Killer，优先杀死超限Pod
limits.cpu	容器可使用的CPU上限	不影响调度（仅用于运行时压制）	CFS配额限制，超过则节流
limits.memory	容器可使用的内存上限	不影响调度（仅用于运行时压制）	超过则触发OOM Kill

  关键原则：Requests ≤ Limits。若只设置Limits未设置Requests，则Requests默认等于Limits。生产环境建议显式设置两者，避免资源争抢与调度偏差。

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"

2.2 QoS类别：服务质量分级

Kubernetes根据Pod中所有容器的Requests与Limits配置，自动将Pod归入三种QoS类别。当节点资源紧张时，QoS类别决定了Pod被驱逐的优先级。

QoS类别	判定条件	驱逐优先级	典型场景
Guaranteed	每个容器Requests == Limits（CPU和内存均相等）	最低（最后被驱逐）	数据库、关键中间件
Burstable	至少一个容器Requests < Limits，且所有容器都设置了Requests	中等	Web服务、微服务
BestEffort	所有容器均未设置Requests和Limits	最高（最先被驱逐）	批处理、测试任务

FinOps视角：Guaranteed Pod资源利用率稳定，适合预留容量规划；BestEffort Pod适合利用闲置资源，但不可靠。合理混合QoS类别可提升整体节点资源利用率，降低碎片率。

2.3 节点资源分配单元

Kubernetes通过ResourceQuota和LimitRange两个资源分配单元，实现命名空间级别的资源治理与Pod级别的默认约束。

2.3.1 ResourceQuota（资源配额）

ResourceQuota作用于命名空间，限制该命名空间内所有Pod的资源总和上限，防止单个团队或应用过度占用集群资源。

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"
    pods: "50"

2.3.2 LimitRange（默认限制范围）

LimitRange为命名空间内的Pod设置默认的Requests/Limits值，以及最小/最大约束，确保未显式设置资源的Pod也能获得合理的默认值。

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

常见陷阱：ResourceQuota与LimitRange配合使用时，若LimitRange设置的默认值导致Pod资源总和超过Quota上限，Pod将无法调度。建议先规划Quota总量，再设置合理的LimitRange默认值。

2.4 资源管理最佳实践

始终设置Requests：避免BestEffort Pod意外抢占关键资源，导致节点不稳定。
Limits不宜过高：过高的Limits会导致节点资源碎片化，降低调度效率。
Guaranteed Pod用于关键业务：确保数据库、消息队列等有状态服务获得稳定资源。
ResourceQuota与LimitRange成对配置：防止命名空间资源失控，同时为未配置资源的Pod提供安全默认值。
定期审计QoS分布：通过监控工具分析集群中Guaranteed/Burstable/BestEffort Pod的比例，优化资源利用率。