{"id":"b4ad73c7-a091-498a-9f7b-e63cd1ea7741","slug":"gke-cost-optimization","kind":"skill","name":"gke-cost-optimization","summary":"Optimizes GKE costs, rightsizes workloads, and configures Spot VMs, CUDs, cost allocation, and resource quotas. Use when optimizing GKE cluster or workload costs, configuring GKE cost allocation or qu","owner":"google","repoUrl":"https://github.com/google/skills/tree/HEAD/skills/cloud/gke-cost-optimization","license":"Apache-2.0","licenseTier":"permissive","trust":"official","stars":21260,"match":null,"fewStars":false,"format":"skill","createdAt":null,"addedAt":"2026-10-14T05:35:43.744Z","logoUrl":"https://avatars.githubusercontent.com/u/1342004?v=4","linkOnly":false,"collection":{"name":"skills","repo":"google/skills"},"skillPath":"skills/cloud/gke-cost-optimization","categories":["memory-knowledge"],"tags":["google","googlecloud"],"runtime":"binary","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-10-14T05:35:43.743Z","sample":false,"url":"https://conduits.dev/tools/gke-cost-optimization","language":"Python","transports":[],"install":{},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"> Optimizes GKE costs, rightsizes workloads, and configures Spot VMs, CUDs, cost allocation, and resource quotas. Use when optimizing GKE cluster or workload costs, configuring GKE cost allocation or quotas, rightsizing CPU/memory requests, or selecting Spot VMs and machine types. Don't use for general compute class provisioning or GPU Selection (use gke-compute-classes instead).\n\n# GKE Cost Optimization\n\nThis reference covers strategies and workflows for reducing Google Kubernetes\nEngine (GKE) costs while maintaining a secure and reliable posture.\n\n## Workflows & Optimization Strategies\n\n### 1. Prerequisite: Cost Allocation & Monitoring\n\nTo enable GKE cost allocation (`--enable-cost-allocation`) for billing tracking\nacross namespaces and labels, inspect live cluster utilization (`kubectl top`),\nor run historical cost breakdown queries in BigQuery (`bq`), use the\n**`gke-cost-analysis`** skill. Once tracking is active and waste is diagnosed,\napply the optimization workflows below.\n\n### 2. Configure Resource Quotas\n\nResource quotas restrict total resource consumption across tenants in\nmulti-tenant clusters, preventing runaway costs. Template:\n[assets/resource-quota-example.yaml](assets/resource-quota-example.yaml)\n(set namespace + `hard` limits, then `kubectl apply -f`).\n\n### 3. Pod Rightsizing (VPA & MPA)\n\nAdjust pod resource requests to match actual utilization. Over-provisioned\nrequests are one of the largest sources of waste.\n\n-   **Use VPA in Recommendation Mode** (`updateMode: \"Off\"` — recommends\n    without evicting):\n\n```bash\n# 1. Deploy VPA in recommendation mode (template: assets/vpa-recommendation-mode.yaml)\nkubectl apply -f assets/vpa-recommendation-mode.yaml\n# 2. Wait 24+ hours for data collection, then read recommendations\nkubectl get vpa {deployment_name}-vpa -o jsonpath='{.status.recommendation}'\n```\n\n-   **Optimization Rules:**\n\nCondition                     | Action                             | Savings\n----------------------------- | ---------------------------------- | -------\nCPU request >5x P95 actual    | Reduce to `P95 * 1.2`              | High\nMemory request >3x P95 actual | Reduce to `P95 * 1.2`              | High\nCPU request >2x P95 actual    | Reduce to `P95 * 1.2`              | Medium\nNo resource requests set      | Add requests (enables bin-packing) | Medium\n\n-   **Use MPA**: Reconcile HPA and VPA recommendations when scaling both\n    horizontally and vertically to avoid conflicting scale events.\n-   **Review Cost Recommendations**: Check Google Cloud Console (`Cost\n    Management` > `GKE Cost Optimization`) for built-in rightsizing suggestions.\n\n### 4. Spot VMs via ComputeClasses & NodeSelector\n\nUse Spot VMs for fault-tolerant workloads to achieve 60-90% cost reduction.\n\n#### 4.1 ComputeClass Configuration\n\nFor a Spot-first ComputeClass with On-Demand fallback (priority ordering,\n`activeMigration`, machine family selection), use the **`gke-compute-classes`**\nskill — ComputeClass YAML generation and priority configuration are its domain,\nnot this skill's.\n\n#### 4.2 Direct Workload Spot Selection (`nodeSelector`)\n\nFor stateless or batch workloads in GKE Autopilot, target Spot capacity directly\nusing `nodeSelector`:\n\n> [!WARNING] **Preemption Warning**: Spot VMs are interruptible and can be\n> preempted at any time with a 30-second notice. Workloads must be\n> fault-tolerant and run with at least 2 replicas for high availability. Always\n> explicitly warn users about this preemption risk when recommending Spot VMs.\n\nThe exact Pod-level selector is:\n\n```yaml\nnodeSelector:\n  cloud.google.com/gke-spot: \"true\"\n```\n\nFull worked Deployment (replicas >= 2, `terminationGracePeriodSeconds: 25`,\n`preStop` hook): [assets/spot-deployment-example.yaml](assets/spot-deployment-example.yaml).\n\n**Spot-Suitable Workloads:**\n\nWorkload                          | Spot-Suitable?\n--------------------------------- | ---------------\nBatch / data processing           | Yes\nDev / test environments           | Yes\nStateless web/API (replicas >= 2) | Yes (with PDBs)\nJobs with checkpointing           | Yes\nStateful workloads (databases)    | No\nSingle-replica critical services  | No\n\n### 5. Machine Type Selection\n\nWhen choosing node shapes or configuring ComputeClasses:\n\n| Family        | Use Case                                          | Relative Cost |\n| ------------- | ------------------------------------------------- | ------------- |\n| e2            | General purpose, burstable                        | Lowest        |\n| t2a / t2d     | Scale-out (Arm/AMD), price-performance optimized  | Low           |\n| n4a           | Axion Arm-based, general-purpose price-performance | Low          |\n| n4 / n4d      | General purpose (Intel/AMD), flexible shapes      | Low-Medium    |\n| c4a           | Axion Arm-based, general-purpose, high efficiency | Medium        |\n| c3 / c4       | Compute-optimized (Intel)                         | Medium-High   |\n| c3d / c4d     | Compute-optimized (AMD), high throughput          | Medium-High   |\n| ek-standard   | Autopilot enhanced                                | Medium        |\n| m3 / x4       | Memory-optimized, SAP HANA, large databases       | High          |\n| g2 (L4 GPU)   | AI inference                                      | High          |\n| a3 (H100 GPU) | AI training                                       | Highest       |\n| a4 / a4x      | Ultra-scale AI (Blackwell GPUs)                   | Highest       |\n\n### 6. Committed Use Discounts (CUDs)\n\nFor steady-state workloads with predictable baseline usage, purchase 1-year or\n3-year CUDs:\n\n-   **Resource-based CUDs** (committed to a machine family/region): roughly\n    high-30s% discount for 1-year, ~55% for 3-year (varies by machine family).\n-   **Flexible CUDs** (spend-based, portable across families/regions): lower\n    discounts (~28% 1-year, ~46% 3-year) in exchange for flexibility.\n-   **Autopilot:** Autopilot-specific CUDs were retired in January 2026 — new\n    commitments covering Autopilot usage are spend-based Compute Flexible CUDs\n    (existing Autopilot CUD commitments run out their term).\n-   Applied automatically to matching usage across the region.\n-   Purchase via Google Cloud Console > Billing > Committed use discounts.\n\n**Size the commitment to the steady-state baseline only.** A commitment bills for\nthe full term whether or not you use it, so over-committing to peak usage\nconverts a discount into waste. Measure the floor of actual usage over a\nrepresentative period, commit to that, and cover everything above it with the\nelastic options already in this skill:\n\n-   **Baseline** (always running) → resource-based CUDs.\n-   **Variable / bursty** → autoscaling on on-demand capacity.\n-   **Interruption-tolerant** (batch, CI, stateless workers) → Spot VMs, which\n    stack with autoscaling and need no commitment.\n\nWhen recommending CUDs, state the split explicitly rather than implying the whole\nfootprint should be committed.\n\n### 7. Cluster Management & Multi-Tenancy\n\n-   **Idle dev clusters**: GKE has no stop/start operation, and the cluster\n    management fee accrues as long as the cluster exists. To cut idle costs,\n    scale node pools to zero (`gcloud container clusters resize {cluster_name}\n    --node-pool {pool_name} --num-nodes 0`) or delete and recreate the cluster\n    via IaC (Terraform/Config Connector).\n-   **Right-size node pools (Standard)**: Use Cluster Autoscaler with\n    appropriate min/max limits.\n-   **Cheap warm headroom instead of overprovisioned nodes**: Standby capacity\n    buffers (Preview, GKE 1.36.0-gke.2253000+) keep pre-initialized nodes\n    suspended — you pay only disk + IP instead of full node price, with ~30s\n    resume. See the **`gke-cluster-autoscaler`** skill.\n-   **Multi-tenant consolidation**: Share a single cluster across multiple\n    engineering teams instead of maintaining per-team clusters, using Namespaces\n    and ResourceQuotas to isolate workloads.\n\n## Cost & Utilization Monitoring\n\nTo inspect live node/pod utilization (`kubectl top nodes/pods`), view cluster\ncost budgets (`gcloud billing budgets list`), or query detailed billing reports\nin BigQuery (`bq query`), refer to the **`gke-cost-analysis`** skill."}