2. Kubernetes 资源模型基础：Requests 与 Limits 的区别与原理

在 Kubernetes 中，CPU 和 内存 是两种可压缩（CPU）与不可压缩（Memory）的资源。Operator 作为长期运行的控制面 Pod，其资源配额设置直接影响调度稳定性、节点压力与 OOM 风险。理解 requests 与 limits 的底层机制，是性能调优的第一步。

2.1 资源单位与语义

2.2 Requests：调度保证与资源预留

requests 是 Pod 启动时向 kube-scheduler 声明的“最低资源需求”。调度器根据每个 Node 上所有 Pod 的 requests 总和决定能否放置新 Pod。

• CPU requests： 基于 CFS（Completely Fair Scheduler）的 cpu.shares 实现。每个 Pod 按 requests 比例获得 CPU 时间片。
• 内存 requests： 作为内存资源预留的参考值，Kubelet 在计算节点压力时使用 requests 判断是否驱逐 Pod。

# 示例：Operator Deployment 资源声明
resources:
  requests:
    cpu: 500m        # 调度保证 0.5 核
    memory: 256Mi    # 调度保证 256 MiB
  limits:
    cpu: 1000m       # 最多使用 1 核
    memory: 512Mi    # 最多使用 512 MiB

2.3 Limits：硬上限与 OOM 防护

limits 是 Pod 运行时不能超过的硬性上限。超过 CPU limits 会被节流（throttle），超过内存 limits 会触发 OOM Killer。

• CPU limits： 通过 CFS 的 cpu.cfs_quota_us 实现。Kubelet 在每个调度周期内强制限制 Pod 的 CPU 使用量。
• 内存 limits： 通过 cgroup 的 memory.limit_in_bytes 实现。一旦超过，内核直接发送 SIGKILL。

2.4 Requests 与 Limits 的三种配置模式

2.5 资源模型核心原理：调度与运行时双视图

下面的 SVG 展示了 调度阶段 与 运行时阶段 两个视角下 requests 与 limits 的作用路径。

2.6 性能调优视角的关键结论

1. Operator 推荐使用 Guaranteed QoS： 设置 requests == limits，避免被 BestEffort 或低优先级 Burstable Pod 抢占，保证控制面响应稳定。
2. 内存 limits 必须精确： 通过压测获取 Operator 的稳态内存 + 20% 缓冲，设置 limits.memory。过高会导致节点超卖，过低会导致频繁 OOM。
3. CPU limits 可适当宽松： 如果 Operator 有突发计算需求，可将 limits.cpu 设为 requests.cpu 的 2 倍，利用 Burstable 模式提升吞吐。
4. 监控实际使用量： 使用 kubectl top pod 或 Prometheus 持续观察 Operator 的 CPU 和内存实际使用曲线，定期调整 requests/limits。