2. 云原生成本调优基础：Kubernetes资源模型、Request与Limit、Pod资源QoS等级
在深入VPA（Vertical Pod Autoscaler）处理资源调优漂移告警之前，必须牢固掌握Kubernetes最核心的资源抽象体系。成本调优的本质，是在资源供给与应用需求之间寻找最优平衡点，而Request、Limit与QoS等级正是定义这一平衡的基石。
2.1 Kubernetes资源模型：可压缩与不可压缩资源
Kubernetes将计算资源分为两大类，其调度与抢占行为截然不同：
| 资源类型 | 代表 | 可压缩性 | 超卖风险 | 资源耗尽时的行为 |
|---|---|---|---|---|
| 可压缩资源 | CPU | 是（通过CFS配额限流） | 低（仅性能下降） | Pod不会被杀死，但CPU使用被节流（Throttling） |
| 不可压缩资源 | Memory、Ephemeral Storage | 否 | 高（触发OOM Kill） | Pod因OOM（Out of Memory）被Kubelet强制终止 |
成本调优关键认知： CPU可以安全地超卖（Overcommit），因为节流只会导致延迟增加；而Memory超卖一旦触发OOM，将直接导致Pod重启或驱逐，这是成本优化中必须避免的“硬故障”。
2.2 Request与Limit：资源承诺与上限
每个Pod中的Container都可以声明两个关键参数，它们直接决定了调度决策与资源竞争行为：
- Request（请求量）：容器保证能获取到的资源下限。Kube-Scheduler依据所有Pod的Request总和来决定节点能否容纳新Pod。
- Limit（上限量）：容器允许使用的资源上限。当容器试图使用超过Limit的资源时，CPU会被节流，Memory会被OOM Kill。
Request与Limit的四种组合模式，直接影响成本与稳定性：
| 模式 | Request = Limit | Request < Limit | 仅设置Request | 仅设置Limit |
|---|---|---|---|---|
| 资源保障 | 强保障，无弹性 | 有保障，有弹性 | 有保障，无上限 | 无保障，有上限 |
| 成本效率 | 低（预留资源无法复用） | 高（允许突发复用） | 中等（无上限风险） | 高（但调度可能失败） |
| 典型场景 | 数据库、有状态服务 | Web服务、批处理任务 | 开发/测试环境 | 不推荐，易导致OOM |
# 一个典型的Web应用Pod资源声明示例
apiVersion: v1
kind: Pod
metadata:
name: cost-optimized-web
spec:
containers:
- name: app
image: nginx:latest
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
VPA优化切入点： VPA的核心工作就是动态调整这些Request与Limit值。它通过分析历史指标，推荐一个既能满足SLA（服务等级协议）又能最大化节点利用率的Request值，从而消除“资源漂移”导致的浪费。
2.3 Pod资源QoS等级：资源竞争的优先级体系
当节点资源紧张时，Kubelet必须决定先杀死哪些Pod。这个决策完全基于Pod的QoS（Quality of Service，服务质量）等级。QoS等级由Container的Request与Limit配置自动推导得出。
下图展示了三种QoS等级的推导逻辑与优先级关系：
2.4 三种QoS等级的详细对比
| 特性 | Guaranteed | Burstable | BestEffort |
|---|---|---|---|
| 配置要求 | 所有容器Request == Limit | 至少一个容器Request != Limit | 所有容器均未设置Request/Limit |
| 资源保障 | 完全保障（等于Request） | 部分保障（至少Request） | 无保障 |
| 弹性能力 | 无（不可突发） | 有（可突发至Limit） | 有（可耗尽节点资源） |
| OOM分数 | 最低（默认2） | 中等（默认5-6） | 最高（默认1000） |
| 成本效率 | 低（资源浪费风险高） | 高（适合大多数生产负载） | 极高（但极不稳定） |
| VPA适用性 | 推荐（VPA可安全调整） | 推荐（VPA优化空间最大） | 不推荐（无Request基准） |
成本调优陷阱： 不要为了追求高装箱率而将所有Pod设置为BestEffort。一旦节点内存压力升高，大量BestEffort Pod会同时被OOM Kill，导致大规模服务中断。合理的策略是：核心服务保持Guaranteed或高Burstable，非核心批处理任务使用Burstable，禁止在生产环境使用BestEffort。
2.5 成本调优视角下的QoS选择策略
结合VPA的工作机制，我们推荐以下分层策略来平衡成本与稳定性：
- 关键在线服务（数据库、API Gateway）：使用Guaranteed，Request = Limit，VPA仅推荐调整值，由人工审核后应用。
- 普通微服务（Web后端、Worker）：使用Burstable，Request < Limit，VPA自动调整Request，保留Limit作为安全缓冲。
- 批处理/离线任务（数据清洗、模型推理）：使用Burstable，Request较低，Limit较高，VPA根据历史峰值动态调整Request。
- 禁止策略：生产环境禁止使用BestEffort；禁止将Limit设置得远大于Request（如Request 100m，Limit 4Core），这会导致节点调度过载。