2. Pod资源请求与限制

在OpenShift中，Pod的资源管理不是“配了就行”的装饰项，而是调度器、kubelet、HPA和集群容量规划共同依赖的契约。理解requests与limits的语义差异，是后续弹性伸缩与容量规划能否成立的前提。

requests与limits的语义分工

requests是Pod对节点资源的“最低保障声明”。调度器（kube-scheduler）在选节点时，只把requests计入节点的已分配资源，并据此判断节点是否还有足够余量。它不关心容器实际用了多少，只关心“声明要多少”。因此，requests直接决定Pod能否被调度、被调度到哪类节点，以及一个节点上最多能塞下多少个同类Pod。

limits是容器运行时的“上限约束”。kubelet通过cgroup把限制施加到容器上：CPU超过limit会被节流（throttle），内存超过limit会触发OOM Kill。注意，limits不参与调度决策——一个节点可能因为requests之和未满而接收新Pod，但该Pod的limits之和早已超过节点物理容量，这正是超卖（overcommit）的来源。

CPU与内存的单位

CPU是“可压缩资源”，单位以核为基准。1表示1个CPU核，500m表示0.5核，100m表示0.1核。m是millicore，1核=1000m。CPU可以被任意切分，且超限时只是变慢，不会杀死进程。

内存是“不可压缩资源”，单位是字节，常用Mi、Gi。例如256Mi、1Gi。内存超限无法“节流”，只能OOM Kill。因此内存的requests与limits设置需要更谨慎，通常建议两者相等或limits略高，避免节点内存被过度超卖导致连锁驱逐。

resources:
  requests:
    cpu: "250m"      # 0.25 核
    memory: "256Mi"
  limits:
    cpu: "500m"      # 0.5 核
    memory: "512Mi"

QoS等级：由requests/limits组合决定

Kubernetes根据容器是否设置requests和limits，自动为Pod分配三种QoS等级，它决定了节点资源紧张时的驱逐优先级：

• Guaranteed（最高保障）：每个容器都同时设置了CPU和内存的requests与limits，且对应值相等。这类Pod最不容易被驱逐，适合核心数据库、关键网关。
• Burstable（弹性）：至少一个容器设置了requests或limits，但不满足Guaranteed条件。大多数业务Pod属于此类，可在有余量时突发使用资源。
• BestEffort（最低）：所有容器都没有设置任何requests和limits。节点压力大时最先被驱逐，只适合临时任务或测试。

驱逐顺序为：BestEffort → Burstable（超出requests越多越先被驱逐）→ Guaranteed。因此QoS不是标签，而是资源紧张时的生存排序。

对调度与伸缩的实际影响

requests设置过小，调度器会认为节点还有余量，把更多Pod塞进来，结果节点实际负载远超预期，CPU争抢、内存压力上升，最终触发驱逐。requests设置过大，则节点明明有物理余量却无法再调度新Pod，集群利用率低下，容量规划被迫提前扩容。

对HPA而言，requests是计算利用率的分母。HPA默认按“实际用量 / requests”得到利用率百分比，再与目标值比较。如果requests设得远大于实际用量，利用率会长期偏低，HPA迟迟不扩容，业务高峰时响应变慢；反之requests过小，利用率虚高，HPA会频繁扩容，造成副本震荡。因此requests不仅是调度参数，也是伸缩灵敏度的调节旋钮。

配置建议与判断依据

CPU的requests建议参考业务常态用量，limits可设为requests的1.5～2倍，允许突发但避免无限争抢。内存的requests与limits建议相等或limits略高10%～20%，因为内存不可压缩，超卖风险高。核心服务应配置为Guaranteed，普通业务用Burstable，临时任务才用BestEffort。

掌握requests/limits的语义、单位与QoS规则后，才能进一步讨论HPA如何基于这些声明做伸缩决策，以及容量规划中如何计算可调度余量与超卖比例。这是弹性伸缩从“能跑”走向“可控”的关键一步。