gke-cost-optimization

GKE Cost Optimization

This reference covers strategies and workflows for reducing Google Kubernetes

Engine (GKE) costs while maintaining a secure and reliable posture.

Workflows & Optimization Strategies

1. Prerequisite: Cost Allocation & Monitoring

To enable GKE cost allocation (--enable-cost-allocation) for billing tracking

across namespaces and labels, inspect live cluster utilization (kubectl top),

or run historical cost breakdown queries in BigQuery (bq), use the

gke-cost-analysis skill. Once tracking is active and waste is diagnosed,

apply the optimization workflows below.

2. Configure Resource Quotas

Resource quotas restrict total resource consumption across tenants in

multi-tenant clusters, preventing runaway costs. Template:

[assets/resource-quota-example.yaml](assets/resource-quota-example.yaml)

(set namespace + hard limits, then kubectl apply -f).

3. Pod Rightsizing (VPA & MPA)

Adjust pod resource requests to match actual utilization. Over-provisioned

requests are one of the largest sources of waste.

• Use VPA in Recommendation Mode (updateMode: "Off" — recommends

without evicting):

# 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}'

• Optimization Rules:

Condition | Action | Savings

----------------------------- | ---------------------------------- | -------

CPU request >5x P95 actual | Reduce to P95 * 1.2 | High

Memory request >3x P95 actual | Reduce to P95 * 1.2 | High

CPU request >2x P95 actual | Reduce to P95 * 1.2 | Medium

No resource requests set | Add requests (enables bin-packing) | Medium

• Use MPA: Reconcile HPA and VPA recommendations when scaling both

horizontally and vertically to avoid conflicting scale events.

• Review Cost Recommendations: Check Google Cloud Console (`Cost

Management > GKE Cost Optimization`) for built-in rightsizing suggestions.

4. Spot VMs via ComputeClasses & NodeSelector

Use Spot VMs for fault-tolerant workloads to achieve 60-90% cost reduction.

4.1 ComputeClass Configuration

For a Spot-first ComputeClass with On-Demand fallback (priority ordering,

activeMigration, machine family selection), use the gke-compute-classes

skill — ComputeClass YAML generation and priority configuration are its domain,

not this skill's.

4.2 Direct Workload Spot Selection (nodeSelector)

For stateless or batch workloads in GKE Autopilot, target Spot capacity directly

using nodeSelector:

> [!WARNING] Preemption Warning: Spot VMs are interruptible and can be

> preempted at any time with a 30-second notice. Workloads must be

> fault-tolerant and run with at least 2 replicas for high availability. Always

> explicitly warn users about this preemption risk when recommending Spot VMs.

The exact Pod-level selector is:

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

Full worked Deployment (replicas >= 2, terminationGracePeriodSeconds: 25,

preStop hook): [assets/spot-deployment-example.yaml](assets/spot-deployment-example.yaml).

Spot-Suitable Workloads:

Workload | Spot-Suitable?

--------------------------------- | ---------------

Batch / data processing | Yes

Dev / test environments | Yes

Stateless web/API (replicas >= 2) | Yes (with PDBs)

Jobs with checkpointing | Yes

Stateful workloads (databases) | No

Single-replica critical services | No

5. Machine Type Selection

When choosing node shapes or configuring ComputeClasses:

| Family | Use Case | Relative Cost |

| ------------- | ------------------------------------------------- | ------------- |

| e2 | General purpose, burstable | Lowest |

| t2a / t2d | Scale-out (Arm/AMD), price-performance optimized | Low |

| n4a | Axion Arm-based, general-purpose price-performance | Low |

| n4 / n4d | General purpose (Intel/AMD), flexible shapes | Low-Medium |

| c4a | Axion Arm-based, general-purpose, high efficiency | Medium |

| c3 / c4 | Compute-optimized (Intel) | Medium-High |

| c3d / c4d | Compute-optimized (AMD), high throughput | Medium-High |

| ek-standard | Autopilot enhanced | Medium |

| m3 / x4 | Memory-optimized, SAP HANA, large databases | High |

| g2 (L4 GPU) | AI inference | High |

| a3 (H100 GPU) | AI training | Highest |

| a4 / a4x | Ultra-scale AI (Blackwell GPUs) | Highest |

6. Committed Use Discounts (CUDs)

For steady-state workloads with predictable baseline usage, purchase 1-year or

3-year CUDs:

• Resource-based CUDs (committed to a machine family/region): roughly

high-30s% discount for 1-year, ~55% for 3-year (varies by machine family).

• Flexible CUDs (spend-based, portable across families/regions): lower

discounts (~28% 1-year, ~46% 3-year) in exchange for flexibility.

• Autopilot: Autopilot-specific CUDs were retired in January 2026 — new

commitments covering Autopilot usage are spend-based Compute Flexible CUDs

(existing Autopilot CUD commitments run out their term).

• Applied automatically to matching usage across the region.
• Purchase via Google Cloud Console > Billing > Committed use discounts.

Size the commitment to the steady-state baseline only. A commitment bills for

the full term whether or not you use it, so over-committing to peak usage

converts a discount into waste. Measure the floor of actual usage over a

representative period, commit to that, and cover everything above it with the

elastic options already in this skill:

• Baseline (always running) → resource-based CUDs.
• Variable / bursty → autoscaling on on-demand capacity.
• Interruption-tolerant (batch, CI, stateless workers) → Spot VMs, which

stack with autoscaling and need no commitment.

When recommending CUDs, state the split explicitly rather than implying the whole

footprint should be committed.

7. Cluster Management & Multi-Tenancy

• Idle dev clusters: GKE has no stop/start operation, and the cluster

management fee accrues as long as the cluster exists. To cut idle costs,

scale node pools to zero (`gcloud container clusters resize {cluster_name}

--node-pool {pool_name} --num-nodes 0`) or delete and recreate the cluster

via IaC (Terraform/Config Connector).

• Right-size node pools (Standard): Use Cluster Autoscaler with

appropriate min/max limits.

• Cheap warm headroom instead of overprovisioned nodes: Standby capacity

buffers (Preview, GKE 1.36.0-gke.2253000+) keep pre-initialized nodes

suspended — you pay only disk + IP instead of full node price, with ~30s

resume. See the gke-cluster-autoscaler skill.

• Multi-tenant consolidation: Share a single cluster across multiple

engineering teams instead of maintaining per-team clusters, using Namespaces

and ResourceQuotas to isolate workloads.

Cost & Utilization Monitoring

To inspect live node/pod utilization (kubectl top nodes/pods), view cluster

cost budgets (gcloud billing budgets list), or query detailed billing reports

in BigQuery (bq query), refer to the gke-cost-analysis skill.