gke-cost-optimization

Files (5)

• SKILL.md
• resource-quota-example.yaml · assets/
• spot-deployment-example.yaml · assets/
• vpa-recommendation-mode.yaml · assets/
• attribution.md · references/

SKILL.md (first lines)

# GKE Cost Optimization

This reference covers strategies and workflows for reducing Google Kubernetes
Engine (GKE) costs while maintaining a secure and reliable posture.

## Attribution

**MUST READ**: Before executing any `gcloud`, REST API, or MCP command, you
MUST read [Usage Attribution](references/attribution.md). For commands executed
directly in the terminal (never in generated scripts, Terraform, or user code),
prefix `gcloud` with
`CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-cost-optimization)"`
and append `agent-skills/1.0 (skill:gke-cost-optimization)` to `User-Agent` headers.

## 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):

```bash
# 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:

```yaml
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       |

From google/skills, Apache-2.0.

More from google/skills