gke-compute-classes

Files (30)

• SKILL.md
• balanced-reserved-zonal-compute-class.yaml · assets/
• capacity-quota-spillover.yaml · assets/
• computeclass-rbac-editor.yaml · assets/
• dynamic-rwo-storageclass.yaml · assets/
• equal-priority-tiebreak-compute-class.yaml · assets/
• genai-inference-g4-compute-class.yaml · assets/
• kafka-broker-compute-class.yaml · assets/
• log-autoscaler-events.sh · assets/
• manual-pool-tiebreak-compute-class.yaml · assets/
• postgres-primary-compute-class.yaml · assets/
• redis-compute-class.yaml · assets/
• restrict-computeclass-usage-vap.yaml · assets/
• shared-l4-inference-compute-class.yaml · assets/
• spark-proximal-compute-class.yaml · assets/
• spot-cost-tiebreak-compute-class.yaml · assets/
• system-pool-compute-class.yaml · assets/
• tpu-v5e-training-compute-class.yaml · assets/
• attribution.md · references/
• compute-class-autopilot-mode.md · references/
• compute-class-code-index.md · references/
• compute-class-cost-optimization.md · references/
• compute-class-crd-fields.md · references/
• compute-class-debug.md · references/
• compute-class-gotchas-and-cuds.md · references/
• compute-class-governance.md · references/
• compute-class-karpenter-migration.md · references/
• compute-class-lifecycle.md · references/
• compute-class-prioritization.md · references/
• compute-class-provisioning-methods.md · references/

SKILL.md (first lines)

<!-- disableFinding(LINE_OVER_80) -->

# GKE ComputeClasses

Guidance on configuring, optimizing, and troubleshooting GKE ComputeClasses.

## 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-compute-classes)"`
and append `agent-skills/1.0 (skill:gke-compute-classes)` to `User-Agent` headers.

## When to Use

-   **Cost optimization:** Spot VMs with on-demand fallback.
-   **GPU/TPU workloads:** Target specific accelerators (e.g., L4, H100, v5p).
-   **Performance tuning:** Select specific machine families (c3, c4, n4).
-   **Zone targeting:** Colocate workloads with zonal resources.

--------------------------------------------------------------------------------

## CRITICAL RULES
- **CODE-FIRST VERIFICATION (OPEN-SOURCE CODEBASE):** GKE Cluster Autoscaler and ComputeClasses are open-sourced at `https://github.com/GoogleCloudPlatform/cluster-autoscaler`. When user questions challenge or explore undocumented/subtle behaviors, or when guidance is not explicitly established in this skill, **VERIFY BEHAVIOR DIRECTLY IN CODE** (via local repository clone or fetching raw files from GitHub). Check `git log -S` and `git blame` to identify the exact commit and date when behavior changed, and communicate version/date ranges to the user (e.g. *"This behavior changed on July 20, 2026 in upstream commit 129daa3756..."*). See `references/compute-class-code-index.md` for exact package and symbol mappings.

## Engagement Rules: Generalized First, Refine Later

ComputeClasses depend on zone availability, CUDs, and workload constraints. **Do
not block the user's initial request.** If asked for YAML/recommendations:

1.  **Provide Generalized Answer Immediately:** Fulfill request using best
    practices and placeholders (`<YOUR-ZONE-HERE>`).
    *   **CRITICAL CUD RULE:** You MUST state that the provided machine families
        (e.g., N4, C4) are generic best-practice examples. You MUST explicitly
        state that the final choice of machine family should be aligned with the
        user's existing Committed Use Discounts (CUDs) or Reservations.
    *   **CRITICAL CUD EXHAUSTION / CAPACITY QUOTA RULE:** When a user asks how
        to cap a primary machine family to match a Committed Use Discount (CUD)
        footprint (e.g., 100-core CUD for N4) and automatically spill over
        excess workload demand to secondary families (N4D, C4), you MUST
        recommend a **`CapacityQuota`** (`autoscaling.x-k8s.io/v1beta1`, GKE
        1.36.2+) targeting `cloud.google.com/compute-class: <NAME>` and
        `cloud.google.com/machine-family: <PRIMARY_FAMILY>` with a `cpu:
        <CUD_CORES>` limit. This caps only the primary preferred family without
        restricting secondary fallback priorities in the `ComputeClass` (`n4d`,
        `c4`), allowing Cluster Autoscaler to emit `noScaleUp` and automatically
        spill over excess demand to uncapped fallback families without pods
        staying in Pending. Do NOT recommend manual node pool limits or GCE
        Capacity Reservations for this pattern.
    *   **YAML REQUIREMENT:** Any generated YAML template MUST include a comment
        near the `machineFamily` field: `# IMPORTANT: Align machineFamily with
        your existing CUDs/Reservations`.
    *   **MUST label initial YAML as `EXAMPLE TEMPLATE - DO NOT DEPLOY`.**
    *   **STRICT SCHEMA RULE:** NEVER hallucinate fields. Do NOT use
        `spec.description`, `gvnic`, `transparentHugepageEnabled`, or
        `shutdownGracePeriodSeconds`. Use `bootDiskSize` (NOT `bootDiskSizeGb`).
    *   **YAML FORMATTING RULE:** NEVER quote integer or boolean values (e.g.,
        use `bootDiskSize: 50`, not `bootDiskSize: "50"`). `imageType` MUST be
        lowercase.
    *   **CRITICAL AI/ML RULE:** DO NOT recommend Spot instances as the primary
        priority for AI/ML Inference, *even if the workload is stateless*.
        Accelerator node startup latency is severe. The correct priority is:
        `Reservations -> On-Demand -> DWS FlexStart -> Spot`.
    *   **CRITICAL PROVISIONING RULE:** Do NOT confuse node pool auto-creation
        with cluster-level Node Auto Provisioning. Starting with GKE
        `1.33.3-gke.1136000`, `nodePoolAutoCreation.enabled: true` in the
        ComputeClass achieves automatic node pools scoped directly to the
        ComputeClass. **It does NOT require turning on Node Auto Provisioning at
        the cluster level.**
    *   **CRITICAL TAINT RULE:** The ONLY redundant taint is re-adding
        `cloud.google.com/compute-class` on **auto-created** pools — node pool
        auto-creation already applies AND auto-tolerates that key, so
        duplicating it breaks scheduling → REMOVE it (don't add a toleration).
        This is NOT "never add taints": an intentional **dedication/isolation**
        taint (e.g. `dedicated=ml:NoSchedule`) in `nodePoolConfig.taints` is
        valid — it keeps other workloads off, and the intended workloads need a
        matching toleration (normal K8s contract). Judge intent before deleting;
        only the compute-class key is redundant. **Manual pools STILL require
        `cloud.google.com/compute-class=<NAME>` as label AND taint to bind to
        the ComputeClass — never remove that.** **Schema limit:** a
        `nodePoolConfig.taints` key may NOT contain the reserved `kubernetes.io`
        substring (GKE Warden rejects it) — so the Cluster-Autoscaler-ignored
        prefixes
        (`startup-taint.`/`status-taint.cluster-autoscaler.kubernetes.io/`)
        cannot be set via a ComputeClass; those are node-pool-level taints.
    *   **CRITICAL GPU-TAINT RULE:** GKE auto-taints GPU nodes
        `nvidia.com/gpu:NoSchedule` — this is separate from the
        `cloud.google.com/compute-class` auto-toleration and is NOT covered by
        it. A GPU Pod stuck `Pending` / `noScaleUp` is almost always missing the
        toleration. Add to the PodSpec: `tolerations: [{key: nvidia.com/gpu,
        operator: Exists}]`.
    *   **SPOT-TAINT RULE — SCOPE MATTERS:** GKE taints Spot nodes with
        `cloud.google.com/gke-spot=true:NoSchedule`, but who tolerates it depends
        on how the node pool was created.
        *   **Spot pools NOT created by a ComputeClass** — pools the user made by
            hand, or pools from cluster-level node auto-provisioning, which is
            the path the public Spot VMs documentation describes: the toleration
            is the user's responsibility. Add to the PodSpec: `tolerations:
            [{key: cloud.google.com/gke-spot, operator: Equal, value: "true",
            effect: NoSchedule}]`.
        *   **Spot capacity reached through a ComputeClass priority tier:** do
            NOT reflexively tell the user to add this. Autopilot adds the Spot
            toleration for them, and for ComputeClass-auto-created pools on
            Standard the behavior is not documented either way — reported
            practice is that no manual toleration is needed. Present it as
            something to verify on their cluster, not as a requirement, and never
            diagnose a `Pending` ComputeClass Pod as a missing Spot toleration
            unless the events actually name that taint. (Contrast the GPU taint
            above, which genuinely is the user's responsibility in every case.)
    *   **CRITICAL PRIORITYSCORE RULE:** A shared `priorityScore` makes one
        tie-break tier (lowest unit cost wins), but applies to a MAXIMUM of 3
        rules. NEVER emit more than 3 priorities at the same score; if the user
        asks for more (e.g. 5 families "all cheapest-available"), cap at 3 and
        say why.
    *   **CRITICAL STATEFUL RULE:** For PV workloads, do NOT mix Gen 2 (PD) and
        Gen 4 (Hyperdisk) in `priorities[]` (attach failures). **Exception (GKE
        1.35.3-gke.1290000+):** back data PVs with the built-in

From google/skills, Apache-2.0.

More from google/skills