> **本文是「架构实战·第二季」第 43 篇**。上一篇讲了集群自动伸缩（41-42），这一篇把视角从"扩"转到"省"——同样的业务量，把月度账单砍掉 30%-50% 到底要怎么做。

---

## 引子：那个 80 万的账单

2025 年初，我们运维总监拿着 AWS 账单来找我，上面赫然写着：**8 套生产 K8s 集群，月度费用 82 万人民币**。

最离谱的是其中一套"非生产"的预发布集群，光是开发人员跑 CI/CD 的临时 Pod，月度就烧掉 9 万。

复盘下来，发现三个共性问题：

1. **Requests 配得偏大**——为了"避免被 OOM kill"，所有人把 CPU 配成 4 核、内存 8Gi，但实际峰值只用 1 核 2Gi；
2. **节点常年低负载**——节点池平均利用率 18%，但每个节点都是按"满配"按需付费；
3. **没有 Spot**——所有节点都是 On-Demand，没用任何抢占式实例。

三个月后，这 9 万变成了 2.8 万，集群性能没退化、稳定性反而更好（因为终于有人真的去看资源水位了）。

这篇文章把这次优化的完整方法论复盘出来：**K8s 成本优化的四大杠杆 + 落地的实操路径**。

---

## 一、K8s 成本的四层结构

很多人以为"K8s 省钱就是节点换成 Spot"，其实真正的成本结构分四层：

```
┌─────────────────────────────────────────┐
│ L4: 业务方用量（怎么算账 / 怎么分摊）   │  ← 财务杠杆
├─────────────────────────────────────────┤
│ L3: 工作负载（Request / Limit / 副本数）│  ← 应用杠杆
├─────────────────────────────────────────┤
│ L2: 调度策略（Spot / 节点池 / 反亲和）  │  ← 调度杠杆
├─────────────────────────────────────────┤
│ L1: 节点规格（机型 / 存储 / 网络）      │  ← 基础设施杠杆
└─────────────────────────────────────────┘
```

**核心认知**：L1 省 10% 很容易（换机型），L2-L3 才是真正能砍 30%-50% 的地方。但 L1-L3 都需要 L4 给出"谁能用多少"的额度才能算账。

下面按从下往上的顺序讲。

---

## 二、L1：节点规格与机型选型

### 2.1 不要盲目追求"最新一代"

我们曾把所有节点从 `m5.xlarge` 升到 `m6i.xlarge`，以为"新一代性能更好"，结果账单涨了 20%。

真相是：m6i 单核价格确实便宜 10%，但 m5 是已经摊完折旧的"老机型"，云厂商经常给老机型 30% 以上的折扣。**新一代 ≠ 更便宜**。

```yaml
# nodeSelector 选择性价比最高的机型（按业务区分）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  template:
    spec:
      nodeSelector:
        node.kubernetes.io/instance-type: m5.2xlarge  # 优先用老一代
        workload-class: cost-optimized                 # 自定义标签
```

### 2.2 节点池要"分池子"

不要把所有节点塞进一个池子，按业务特征分：

| 池子 | 适用场景 | 选型 |
|------|----------|------|
| `critical-pool` | 核心交易 | On-Demand + 最新一代 + 预留实例 |
| `general-pool` | 通用服务 | On-Demand + 老一代 + Savings Plans |
| `batch-pool` | 离线/CI | **Spot** + 老一代 |
| `burst-pool` | 弹性业务 | Spot + 按需 fallback |

**我们那次 82 万砍到 38 万的第一刀，就是把 CI 集群全部切到 Spot**——CI 失败重跑就行，Spot 被回收完全无所谓。

### 2.3 存储不要"乱给钱"

存储成本经常被忽略，特别是：

- `emptyDir` 用 `medium: ""`（内存盘）能快，但贵；
- `PVC` 默认 `gp3` 是好，但有些日志/缓存场景用 `st1`（吞吐优化型 HDD）能省一半；
- 快照要**自动清理**，别让 EBS 快照越积越多。

```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cost-optimized-hdd
provisioner: ebs.csi.aws.com
parameters:
  type: st1
  iopsPerGB: "500"   # HDD 不需要高 IOPS
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
```

---

## 三、L2：Requests 与 Limit——80% 的浪费在这里

### 3.1 Requests 决定了"成本基线"

一个常见的误解是：**Requests 是给 K8s 看的"上限"，Limit 才是硬限制**。完全反了。

- `Requests` = 节点调度的"占位符"，**会被计入节点容量**；
- `Limit` = cgroup 实际限制，超了就 throttled/OOM。

也就是说：**Requests 决定你付多少钱，Limit 决定程序能跑多快**。

很多人两个都配得很大，结果就是：

- Requests 大 → 调度器给你预留资源 → 你付钱；
- Limit 更大 → 实际 CPU/内存用不上 → 资源浪费。

### 3.2 用 VPA 自动算"刚刚好"

`Vertical Pod Autoscaler`（VPA）能基于历史数据自动算出"刚刚好"的 Requests：

```yaml
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-service-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-service
  updatePolicy:
    updateMode: "Auto"        # 自动滚动更新
  resourcePolicy:
    containerPolicies:
      - containerName: "*"
        minAllowed:
          cpu: "100m"
          memory: "128Mi"
        maxAllowed:
          cpu: "4"
          memory: "8Gi"
        controlledResources: ["cpu", "memory"]
```

**落地三步走**：

1. **第一周**：VPA 跑 `updateMode: "Off"`（只推荐不应用），观察推荐值；
2. **第二周**：把推荐值人工写到 Deployment 里（避免重启风险）；
3. **第三周起**：切到 `updateMode: "Auto"`，VPA 自动滚动更新。

我们那次优化，光 VPA 一项就把 18 个服务的 Requests 平均砍了 40%。

### 3.3 Limit 要"留余量但别太大"

一个简单的经验公式：

```
CPU Limit    = Requests × 2~3
Memory Limit = Requests × 1.2~1.5
```

为什么 CPU Limit 比例大？因为 CPU 是可压缩资源，突发用一下不会出问题；而内存是硬资源，Limit 太松反而掩盖内存泄漏。

**反面教材**：

```yaml
resources:
  requests:    # 这两个值完全一样，等于没弹性
    cpu: "2"
    memory: "4Gi"
  limits:
    cpu: "2"     # 突发一点就 throttled
    memory: "4Gi"  # 泄漏一点就 OOM
```

**正确示例**：

```yaml
resources:
  requests:
    cpu: "500m"     # 调度占位
    memory: "1Gi"
  limits:
    cpu: "2"        # 突发能用到 4 倍
    memory: "1.5Gi" # 内存只多给 50%
```

---

## 四、L2 续：HPA、VPA、CA 的组合拳

三个自动伸缩组件各有侧重：

| 组件 | 作用 | 节省什么 |
|------|------|----------|
| **HPA** | 横向扩 Pod 副本 | 业务高峰多副本 |
| **VPA** | 纵向调 Requests/Limit | Requests 砍 40% |
| **CA**（Cluster Autoscaler） | 节点数伸缩 | 节点空载率下降 |
| **Karpenter** | 替代 CA，更智能 | 节点选型更精准 |

**推荐组合**：

```yaml
# HPA：业务波动型
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-service
  minReplicas: 3
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60  # 不是 80%，是 60%
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # 别缩太快
```

注意 HPA 的 target utilization 是 **60% 不是 80%**：80% 等到触发扩容时已经晚了，60% 给扩容留出时间。

### Karpenter 替代 Cluster Autoscaler

CA 是按节点组扩缩，比较"笨"；Karpenter 直接看 Pod 的资源需求，**选最便宜的机型组合**：

```yaml
# Karpenter NodePool
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]  # 优先 Spot
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["4"]   # 至少 4 代
      nodeClassRef:
        name: default
  limits:
    cpu: "1000"
    memory: 4000Gi
  disruption:
    consolidationPolicy: WhenUnderutilized  # 节点空了就合并
    expireAfter: 720h
```

`consolidationPolicy: WhenUnderutilized` 是关键——Karpenter 会自动合并空载节点，把小节点换成大节点，**实测能再省 15%**。

---

## 五、L2 续：Spot 实例的正确使用姿势

Spot 能便宜 60%-90%，但有个致命问题：**随时可能被回收**（2 分钟通知）。

### 5.1 哪些业务能用 Spot

| 业务类型 | 能否 Spot | 原因 |
|----------|-----------|------|
| 核心交易 | ❌ | 不可中断 |
| 异步任务 | ✅ | 重试即可 |
| CI/CD Runner | ✅ | 失败重跑 |
| 离线计算 | ✅ | 任务可重入 |
| 缓存/无状态 | ✅ | 数据可重建 |
| 状态ful 数据库 | ❌ | 持久化数据 |

### 5.2 用 PriorityClass + PodDisruptionBudget 保护关键 Pod

```yaml
# 给关键 Pod 高优先级，防止被 Spot 回收时的 Pod 驱逐影响
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: critical-no-evict
value: 1000000
globalDefault: false
description: "核心业务，禁止被驱逐"
---
# 即使节点被回收，也保证至少 2 个 Pod 在跑
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-service-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: api-service
```

### 5.3 优雅处理 Spot 中断

Karpenter/Cluster Autoscaler 在回收前会发 `preemption` 信号，Pod 应该监听 SIGTERM 做优雅退出：

```python
import signal, sys, time

def graceful_shutdown(signum, frame):
    print("收到 SIGTERM，停止接收新请求")
    # 1. 从 Service endpoints 中摘除
    deregister_from_service()
    # 2. 处理完已有请求
    drain_in_flight_requests(timeout=30)
    # 3. 关闭数据库连接
    close_db_connections()
    sys.exit(0)

signal.signal(signal.SIGTERM, graceful_shutdown)
```

---

## 六、L3：调度策略——把对的应用放对的节点

### 6.1 反亲和 + Topology Spread

避免所有 Pod 跑同一个节点（节点挂了全挂）：

```yaml
affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          topologyKey: kubernetes.io/hostname
          labelSelector:
            matchLabels:
              app: api-service
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: api-service
```

### 6.2 资源配额（Quota）——给业务方"额度"

让业务方有"花自己钱的意识"：

```yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "100"        # 总共 100 核
    requests.memory: 400Gi
    limits.cpu: "200"
    limits.memory: 800Gi
    persistentvolumeclaims: "50"
```

配上 **Chargeback 报表**（按 Namespace 拆分账单），让业务方自己优化，比你追着他们改配置有效 10 倍。

---

## 七、L4：成本可视化与归因

最后也是最容易被忽略的：**让业务方看到自己花了多少钱**。

### 7.1 用 Kubecost 算账

```bash
helm install kubecost oci://public.ecr.aws/kubecost/cost-analyzer --version "$VERSION"
```

Kubecost 能按 Namespace、Label、Deployment 维度拆账，导出 CSV 喂给财务系统。

### 7.2 自建成本看板（用 Prometheus + Grafana）

```promql
# 每个 Namespace 的 CPU 成本估算（按小时）
sum by (namespace) (
  rate(container_cpu_usage_seconds_total{container!="",container!="POD"}[1h])
) * on(namespace) group_left
sum by (namespace) (kube_namespace_labels)
* 0.05   # 假设每核时 0.05 美元
```

把这张图每周发给每个团队的负责人，**没人愿意当"最贵"的那个**。

---

## 八、踩坑提示

### 8.1 不要一上来就上 Spot

**先做 Requests 优化，再上 Spot**。否则 Spot 节点被回收时，因为 Requests 配得大，Pod 调度会很慢，触发稳定性问题。

### 8.2 VPA 和 HPA 不能同时用同一个资源

VPA 调 CPU/内存 Requests 时，HPA 是基于 CPU 利用率算副本数的——两者会打架。

**推荐方案**：

- VPA 调 memory，HPA 看 CPU；
- 或者 VPA 给推荐，HPA 不变。

### 8.3 不要被"利用率低"骗了

很多团队看到节点利用率 18% 就开始合并节点，结果合并后业务高峰一上来就 OOM。

**正确的判断标准**：

- 看 **P99 资源使用量** 不是平均值；
- 给节点留 30% 缓冲；
- 配合 HPA 自动扩容，**不要靠节点常驻来扛峰值**。

### 8.4 成本优化是个持续过程

不要指望"做一次就完事"。建议：

- 每月做一次 Kubecost 报表 review；
- 每季度重新跑一遍 VPA 推荐；
- 每年重新评估机型和 Spot 比例。

---

## 本篇要点回顾

1. K8s 成本结构分四层：节点规格 / 工作负载 / 调度策略 / 业务归因
2. **Requests 决定你付多少钱**——优先用 VPA 自动算出"刚刚好"
3. HPA + VPA + Karpenter 组合拳能砍 30%-50% 成本
4. Spot 适合可中断业务，配 PriorityClass + PDB 兜底
5. 成本可视化是终极大招——让业务方自己优化

---

## 下篇预告

下一篇讲 **44-K8s GitOps 进阶：ArgoCD 多集群交付模式**。K8s 集群从 1 个变成 10 个之后，单纯靠 kubectl apply 已经管不动了；用 ArgoCD 的 Hub-Spoke / Hub-Hub 模式，把 100 个集群的发布收敛到一个控制平面。敬请期待。

本文是「架构实战·第二季」第 43 篇。上一篇讲了集群自动伸缩（41-42），这一篇把视角从"扩"转到"省"——同样的业务量，把月度账单砍掉 30%-50% 到底要怎么做。

【架构实战】K8s 成本优化：Spot 实例、Requests 与资源回收

研发部经理

云计算

架构设计

运维

K8s成本优化四层杠杆：节点规格、工作负载、调度策略、业务归因。VPA自动调Requests，HPA+Spot+Karpenter组合可省30%-50%。优先级分配与PDB保障关键Pod，Kubecost可视化让业务方自主优化。

腾讯云双十一大促

tcmg

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【架构实战】K8s 成本优化：Spot 实例、Requests 与资源回收-腾讯云开发者社区-腾讯云

【架构实战】K8s 成本优化：Spot 实例、Requests 与资源回收

【架构实战】K8s 成本优化：Spot 实例、Requests 与资源回收

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐