gke-cost-optimization

GKE 成本优化

本参考介绍了在保持安全可靠的前提下，降低 Google Kubernetes Engine（GKE）成本的策略和工作流。

归属信息

务必阅读：执行任何 gcloud、REST API 或 MCP 命令前，必须阅读使用归属信息。对于直接在终端中执行的命令（切勿用于生成的脚本、Terraform 或用户代码），请在 gcloud 前添加 CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-cost-optimization)"，并在 User-Agent 请求头中添加 agent-skills/1.0 (skill:gke-cost-optimization)。

工作流和优化策略

1. 前提条件：成本分配与监控

如需启用 GKE 成本分配（--enable-cost-allocation），以跟踪跨命名空间和标签的账单情况，检查集群实时利用率（kubectl top），或在 BigQuery（bq）中运行历史成本明细查询，请使用 gke-cost-analysis 技能。跟踪启用并诊断出浪费后，请应用以下优化工作流。

2. 配置资源配额

资源配额可限制多租户集群中各租户的总资源消耗，防止成本失控。模板：assets/resource-quota-example.yaml（设置命名空间和 hard 限制，然后运行 kubectl apply -f）。

3. Pod 资源规格优化（VPA 和 MPA）

调整 Pod 资源请求，使其符合实际利用率。资源请求设置过高是造成浪费的主要原因之一。

• 以建议模式使用 VPA（updateMode: "Off" — 仅提供建议，不驱逐 Pod）：

# 1. Deploy VPA in recommendation mode (template: assets/vpa-recommendation-mode.yaml)
kubectl apply -f assets/vpa-recommendation-mode.yaml
# 2. Wait 24+ hours for data collection, then read recommendations
kubectl get vpa {deployment_name}-vpa -o jsonpath='{.status.recommendation}'

• 优化规则：

条件	操作	节省
CPU 请求 > 实际 P95 的 5 倍	降至 P95 * 1.2	高
内存请求 > 实际 P95 的 3 倍	降至 P95 * 1.2	高
CPU 请求 > 实际 P95 的 2 倍	降至 P95 * 1.2	中
未设置资源请求	添加请求（支持装箱调度）	中

• 使用 MPA：同时进行水平和垂直扩缩时，协调 HPA 和 VPA 的建议，以避免扩缩事件相互冲突。
• 查看成本建议：在 Google Cloud Console 中查看（Cost Management > GKE Cost Optimization）内置的资源规格优化建议。

4. 通过 ComputeClasses 和 NodeSelector 使用 Spot VM

对可容错工作负载使用 Spot VM，可降低 60-90% 的成本。

4.1 ComputeClass 配置

如需配置优先使用 Spot VM、并在必要时回退到按需实例的 ComputeClass（包括优先级排序、activeMigration 和机器系列选择），请使用 gke-compute-classes 技能——ComputeClass YAML 生成和优先级配置属于该技能的职责范围，而非本技能。

4.2 直接为工作负载选择 Spot（nodeSelector）

对于 GKE Autopilot 中的无状态或批处理工作负载，可使用 nodeSelector 直接指定 Spot 容量：

警告

抢占警告：Spot VM 可中断，可能会在任何时候提前 30 秒通知后被抢占。工作负载必须具备容错能力，并至少运行 2 个副本以实现高可用性。推荐使用 Spot VM 时，务必明确提醒用户存在被抢占的风险。

Pod 级别的具体选择器如下：

nodeSelector:
  cloud.google.com/gke-spot: "true"

完整的 Deployment 示例（副本数 >= 2，terminationGracePeriodSeconds: 25，preStop 钩子）：assets/spot-deployment-example.yaml。

适合使用 Spot VM 的工作负载：

工作负载	适合使用 Spot VM？
批处理 / 数据处理	是
开发 / 测试环境	是
无状态 Web/API（副本数 >= 2）	是（需配置 PDB）
带检查点的作业	是
有状态工作负载（数据库）	否
单副本关键服务	否

5. 机器类型选择

选择节点形状或配置 ComputeClasses 时：

系列	使用场景	相对成本
e2	通用型，可突发	最低
t2a / t2d	横向扩展（Arm/AMD），针对性价比优化	低
n4a	基于 Axion Arm，通用型，针对性价比优化	低
n4 / n4d	通用型（Intel/AMD），形状灵活	低至中
c4a	基于 Axion Arm，通用型，高效率	中
c3 / c4	计算优化型（Intel）	中至高
c3d / c4d	计算优化型（AMD），高吞吐量	中至高
ek-standard	Autopilot 增强型	中
m3 / x4	内存优化型、SAP HANA、大型数据库	高
g2（L4 GPU）	AI 推理	高
a3（H100 GPU）	AI 训练	最高
a4 / a4x	超大规模 AI（Blackwell GPU）	最高

6. 承诺使用折扣（CUD）

对于基线用量可预测的稳定工作负载，可购买 1 年或 3 年 CUD：

• 基于资源的 CUD（承诺使用特定机器系列/区域）：1 年折扣约为 30% 多，3 年约为 55%（因机器系列而异）。
• 灵活 CUD（基于支出，可跨系列/区域使用）：折扣较低（1 年约 28%，3 年约 46%），以换取灵活性。
• Autopilot： Autopilot 专属 CUD 已于 2026 年 1 月停用 — 覆盖 Autopilot 用量的新承诺属于基于支出的 Compute Flexible CUD（现有 Autopilot CUD 承诺会持续至期限结束）。
• 自动应用于区域内符合条件的用量。
• 通过 Google Cloud Console > Billing > Committed use discounts 购买。

承诺额度仅应按稳定状态下的基线用量确定。 无论是否使用，整个期限内都要为承诺付费，因此承诺额度超过峰值用量会把折扣变成浪费。应在有代表性的时段内测量实际用量的最低水平，并据此承诺；超出部分则使用本技能中已有的弹性选项：

• 基线（始终运行）→ 基于资源的 CUD。
• 可变 / 突发用量 → 在按需容量上自动扩缩容。
• 可容忍中断的工作负载（批处理、CI、无状态工作进程）→ Spot VM，可与自动扩缩容叠加使用，且无需承诺。

建议使用 CUD 时，应明确说明承诺用量的拆分方式，而不要暗示应将全部资源用量都纳入承诺。

7. 集群管理与多租户

• 闲置的开发集群：GKE 没有停止/启动操作，而且只要集群存在，就会持续产生集群管理费。要降低闲置成本，可将节点池缩减至零（gcloud container clusters resize {cluster_name} --node-pool {pool_name} --num-nodes 0），或通过 IaC（Terraform/Config Connector）删除并重新创建集群。
• 合理调整节点池大小（Standard）：使用 Cluster Autoscaler 并设置适当的最小值/最大值。
• 以低成本预留充足的可用容量，而不是过度预配节点：待命容量缓冲区（预览版，GKE 1.36.0-gke.2253000+）会让预初始化节点保持挂起状态 — 只需支付磁盘和 IP 费用，而不是完整节点价格，恢复约需 30 秒。参见 gke-cluster-autoscaler 技能。
• 整合多租户：多个工程团队共用一个集群，而不是为每个团队单独维护集群，并使用 Namespaces 和 ResourceQuotas 隔离工作负载。

成本与利用率监控

如需检查节点和 Pod 的实时利用率（kubectl top nodes/pods）、查看集群成本预算（gcloud billing budgets list），或在 BigQuery 中查询详细账单报告（bq query），请参阅 gke-cost-analysis 技能。