[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6994VG2AR02TP7SK35MSP69":3,"skill-same:01M6994VG2AR02TP7SK35MSP69":94},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M6994VG2AR02TP7SK35MSP69","gke-upgrades",null,"Plans, executes, and validates Google Kubernetes Engine (GKE) cluster upgrades and maintenance operations for both Standard and Autopilot clusters. Produces upgrade plans, pre\u002Fpost-upgrade checklists, maintenance runbooks with gcloud commands, release channel strategy, and troubleshooting guides. Handles node pool upgrade strategies (surge, blue-green), version compatibility, PDB management, and workload-specific concerns (stateful, GPU, operators). Use this skill whenever the user mentions GKE upgrades, Kubernetes version bumps, node pool maintenance, GKE patching, cluster version management, release channel selection, maintenance windows, surge upgrades, stuck upgrades, or any GKE lifecycle management task — even casual mentions like \"we need to upgrade our clusters\" or \"plan our next GKE maintenance\" or \"our upgrade is stuck.\" Don't use for GKE cluster creation, application onboarding, general networking\u002Frouting setup, or security policy configurations (use gke-basics or relevant GKE skills instead).","google\u002Fskills","google","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1342004?v=4","01M698VYEFDM0VJBZDYYJ2T83S","Google","01M698WR0H76ENHE587T9EJT89",24044,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-upgrades\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,9,36,37,38,39,40,41,42,43,44],"gke upgrades","gke","upgrades","selection","stateful","blue-green","relevant","runbooks","surge","guides","pdb","creation","operators","strategies","green","upgrade","next","node","plan","release","gke cluster creation","policy","security","kubernetes","containers","gcloud","2026-11-10 10:12:30",false,"---\nname: gke-upgrades\nmetadata:\n  version: \"1.1.1\"\n  category: Containers\ndescription: >-\n  Plans, executes, and validates Google Kubernetes Engine (GKE) cluster upgrades\n  and maintenance operations for both Standard and Autopilot clusters. Produces\n  upgrade plans, pre\u002Fpost-upgrade checklists, maintenance runbooks with gcloud\n  commands, release channel strategy, and troubleshooting guides. Handles node\n  pool upgrade strategies (surge, blue-green), version compatibility, PDB\n  management, and workload-specific concerns (stateful, GPU, operators). Use this\n  skill whenever the user mentions GKE upgrades, Kubernetes version bumps, node\n  pool maintenance, GKE patching, cluster version management, release channel\n  selection, maintenance windows, surge upgrades, stuck upgrades, or any GKE\n  lifecycle management task — even casual mentions like \"we need to upgrade our\n  clusters\" or \"plan our next GKE maintenance\" or \"our upgrade is stuck.\" Don't\n  use for GKE cluster creation, application onboarding, general networking\u002Frouting\n  setup, or security policy configurations (use gke-basics or relevant GKE skills\n  instead).\n---\n\n# GKE Upgrades & Maintenance\n\nProduce clear, actionable documents — upgrade plans, runbooks, or checklists — tailored to the user's environment. Output should be specific to their cluster mode, release channel, version, and workload types rather than generic advice.\n\nAlways frame guidance around the auto-upgrade model: auto-upgrade with maintenance windows and exclusions is the preferred control mechanism.\n\n## Attribution\n\n**MUST READ**: Before executing any `gcloud`, REST API, or MCP command, you\nMUST read [Usage Attribution](references\u002Fattribution.md). For commands executed\ndirectly in the terminal (never in generated scripts, Terraform, or user code),\nprefix `gcloud` with\n`CLOUDSDK_METRICS_REQUEST_ATTRIBUTION=\"agent-skills\u002F1.0 (skill:gke-upgrades)\"`\nand append `agent-skills\u002F1.0 (skill:gke-upgrades)` to `User-Agent` headers.\n\n## Context Gathering\n\nBefore producing any upgrade artifact, establish:\n\n- **Cluster mode** — Standard or Autopilot? (Autopilot has no node pool management, mandatory resource requests, no SSH)\n- **Current and target versions** — Node version skew must be within 2 minor versions of control plane.\n- **Release channel** — Rapid, Regular, Stable, or Extended.\n- **Environment topology & Rollout Sequencing** — Single vs multi-cluster, dev\u002Fstaging\u002Fprod tiers, and whether Rollout Sequencing is used.\n- **Workload sensitivity** — StatefulSets, databases, GPU, long-running batch need special handling.\n\nIf the user provides these upfront, skip straight to the deliverable. If they're vague, fill in reasonable defaults and flag assumptions.\n\n## Core Principles\n\nGKE versions follow Kubernetes version terminology: **Major.Minor.Patch** (e.g., 1.30.1-gke.1187000). A **Minor** version bump (e.g., 1.29 → 1.30) introduces new features and APIs. A **Patch** version bump (e.g., 1.30.1 → 1.30.2) introduces security and bug fixes. Ensure the user understands this distinction.\n\n1. **Sequential control plane, skip-level node pools** -- Control plane upgrades are sequential (N → N+1 → N+2). Node pools support skip-level (N+2) upgrades.\n2. **Control plane first** -- Control plane must be upgraded before node pools. Nodes can trail by up to 2 minor versions.\n3. **Environment progression** -- Always upgrade dev\u002Fstaging before production. Use **Rollout Sequencing** (preferred) to automate and enforce this progression across environments (e.g., dev → staging → prod), or manually coordinate version progression if Rollout Sequencing is not used.\n4. **Workload-aware** -- Upgrade strategy depends on what's running (stateless, stateful, GPU, batch).\n5. **Release channels first** -- Always recommend release channels. Note that \"No channel\" (static versioning) is deprecated and clusters should be migrated to release channels.\n6. **Rollback\u002FDowngrade** -- Control Plane patches and Node Pools (minor and patches) can be rolled back (downgraded to a target version). GKE supports a 2-step Control Plane minor upgrade where step 1 is rollbackable. Other Control Plane minor version rollbacks are NOT customer-doable and require GKE Support.\n7. **Node pool upgrade ordering** -- When upgrading multiple node pools, always recommend sequential ordering: upgrade non-critical\u002Fstateless pools first (acting as a canary) to verify cluster health before upgrading critical stateful (database) or GPU pools.\n\n## Release Channels\n\n| Channel | Best for | SLA |\n|---------|----------|-----|\n| **Rapid** | Dev\u002Ftest, early feature access | No upgrade stability SLA |\n| **Regular** (default) | Most production | Full SLA |\n| **Stable** | Mission-critical, stability-first | Full SLA |\n| **Extended** | Compliance, EoS enforcement control | Full SLA |\n\n### Support Lifecycle\nStandard GKE versions are supported for 14 months after they become available in the **Regular** channel. This means:\n\n- **Rapid** channel versions may be supported for longer than 14 months (since they enter Rapid before Regular).\n- **Stable** channel versions may be supported for less than 14 months (since they enter Stable after Regular).\n- **Extended** support extends this period up to 24 months. Note that extra cost applies only during the extended support period (months 15-24).\n\n### Current Capabilities\n\n- **Extended channel math**: 14 months of standard support + ~10 months of extended support ≈ 24 months total per minor version. Even on Extended, forced upgrades still occur: if you take no action, GKE auto-upgrades the cluster at End of Support — averaging a minor version bump roughly every 4 months, the same cadence as other channels (features just arrive later).\n- **Upgrade reliability (KubeCon NA 2025)**: Google reports a 99.99% upgrade success rate across GKE control planes and nodes, with safe rollback and skip-version upgrade support positioned to let teams upgrade less often (e.g., annually instead of quarterly). Pilot skip-version upgrades in non-production clusters first.\n- **Autoscaled blue-green node upgrades** (Preview): a blue-green variant that scales the green pool on demand instead of pre-provisioning a full duplicate pool — for disruption-sensitive workloads that cannot reserve 2x capacity.\n- **Scheduled cluster upgrade notifications** (Preview): opt in to be notified ahead of scheduled minor upgrades and wire the notifications into alerting.\n- **Graceful termination and PDBs during drains**: blue-green (including autoscaled blue-green, Preview) is the *only* strategy that honors `terminationGracePeriodSeconds` for up to 24 hours; surge upgrades honor it for up to 60 minutes. During node drains, GKE respects PDBs for a maximum of 60 minutes, after which pods are force-deleted (a notification is sent).\n\n## Maintenance Windows & Exclusions\n\nConfigure maintenance windows to control auto-upgrade timing. GKE also supports node pool level maintenance exclusions (in addition to cluster level) to block upgrades for specific workloads.\n\n**Exclusion types & Limits:**\n\n- **\"No upgrades\" (Scope: `no_upgrades`)**: Blocks all upgrades (minor, patch, node).\n  - **Limits**: Max **90 days per exclusion**, and a cluster can have at most **3** such exclusions. Together they must still allow at least **48 hours of maintenance availability in any rolling 92-day window** — so you cannot chain them into a continuous freeze longer than 90 days. GKE recommends keeping these under 30 days.\n- **\"No minor or node upgrades\" (Scope: `no_minor_or_node_upgrades`)**: Blocks minor and node upgrades, but allows control plane patch upgrades (low risk).\n  - **Limit**: No fixed day cap — bounded by the minor version's **End of Support (EoS)**. Recommendation: keep under ~6 months.\n- **\"No minor upgrades\" (Scope: `no_minor_upgrades`)**: Blocks minor upgrades, but allows control plane patches and node upgrades.\n  - **Limit**: No fixed day cap — bounded by EoS. Recommendation: keep under ~6 months.\n\n**Important Exclusion Rules (MUST follow when recommending exclusions and MUST include in the final text response):**\n\n1. **Auto-upgrades only**: Maintenance exclusions **only block automatic upgrades**. Manual upgrades initiated by the user will bypass exclusions. You MUST explain this to the user.\n2. **Warn against \"No channel\"**: You MUST explicitly warn that disabling release channels (\"No channel\" \u002F static versioning) is deprecated and must not be used as a replacement for exclusions.\n3. **Compare Scopes**: You MUST explain the difference between 'No upgrades' (limitations, blocks patches) and 'No minor or node upgrades' (allows patches, longer duration). Recommend 'No minor or node upgrades' when the user wants to allow security patches\u002Ffixes while blocking minor version jumps.\n4. **Handle periods > 90 days**: If the user needs to block upgrades for more than 90 days, you MUST explain that 'No upgrades' is limited to 90 days per exclusion (max 3 per cluster, and 48 hours of maintenance availability must remain in any rolling 92-day window, preventing chaining into longer continuous freezes) and advise using scoped exclusions ('No minor or node upgrades' \u002F 'No minor upgrades'), which have no fixed day cap and can run until the minor version's End of Support.\n5. **Version skew**: Be mindful of version skew (between control plane and node pools) when using exclusions. Ensure skew does not exceed the supported 2 minor versions. Use `--add-maintenance-exclusion-until-end-of-support` for persistent exclusions.\n6. **Correct gcloud syntax**: When providing `gcloud` commands for exclusions, you MUST use the separate flag syntax: `--add-maintenance-exclusion-name`, `--add-maintenance-exclusion-start`, `--add-maintenance-exclusion-end` (or `--add-maintenance-exclusion-until-end-of-support`), and `--add-maintenance-exclusion-scope` (do NOT use a single comma-separated `--add-maintenance-exclusion` flag).\n\n## Mandatory Upgrade Overrides\n\nGKE reserves the right to override user-defined maintenance windows and exclusions for mandatory operations. These overrides cannot be disabled or blocked.\n\n**Common Override Scenarios:**\n\n- **Critical Security Patches**: Urgent vulnerability fixes that must be applied immediately to protect infrastructure.\n- **End of Support (EoS) \u002F End of Life (EOL) Enforcement**: If a cluster is running an unsupported version, GKE will force upgrade it to a supported version.\n- **Expiring Certificates**: If control plane certificates (CAs) are expiring (within 30 days) and rotation is required to prevent cluster unrecoverability.\n- **Maintenance Starvation**: GKE requires at least 48 hours of maintenance availability in any rolling 92-day window. If exclusions block too much, GKE may force an upgrade.\n\n**Guidance (MUST follow when overrides are discussed):**\n\n1. **Correlate with Bulletins**: If GKE performs an unexpected upgrade, you MUST explicitly suggest checking GKE Release Notes or Security Bulletins to correlate the event with emergency patches (do not just suggest checking Cloud Audit Logs).\n2. **Design for Resilience**: Workloads must be designed to survive unexpected control plane or node rotation. You MUST recommend:\n   - Regional clusters (multi-master) to ensure API availability during control plane upgrades.\n   - Multi-zone workload deployments.\n   - Replicas > 1 for critical deployments.\n   - Properly configured Pod Disruption Budgets (PDBs) that are not overly restrictive.\n\n## Upgrade Planning\n\nWhen asked to plan an upgrade, produce a structured document covering:\n\n- Version compatibility (breaking changes, deprecated APIs) (minor version upgrades only)\n- Upgrade path (sequential minor version upgrades) (minor version upgrades only)\n- Node pool upgrade strategy (Standard only)\n- Workload readiness (PDBs, resource requests)\n- Rollback\u002FContingency procedure (how to revert node pools or coordinate with GKE Support for master rollback)\n\n**Compatibility Search Rule:**\n\n- If compatibility information (e.g., third-party operator compatibility, GPU driver\u002FCUDA compatibility matrix) is not immediately available in the workspace or via a quick web search, **do NOT loop or make multiple search attempts**. Instead, list the compatibility verification as a **critical pre-upgrade action item** for the user in the checklist.\n\n### Node Pool Strategy (Standard Only)\n\nRecommend **Surge upgrade** as the default and most common strategy, with per-pool settings:\n\n- **Stateless**: Higher `maxSurge` (2-3) for speed, `maxUnavailable=0` for safety.\n- **Stateful\u002FDB**: `maxSurge=1, maxUnavailable=0` (conservative).\n- **GPU (fixed reservation)**: `maxSurge=0, maxUnavailable=1` (no surge capacity).\n- **Large (50+ nodes)**: `maxSurge=20, maxUnavailable=0` (max parallelism).\n\nFor mission-critical workloads requiring fast rollback or strict validation, recommend **Standard Blue-Green** upgrades. Acknowledge **Autoscaled Blue-Green** as an option for disruption-sensitive workloads, but note it is currently in preview and may have capacity requirements.\n\n**Upgrade Ordering (User-initiated only):** When planning manual upgrades, specify the sequence of node pool upgrades. Recommend upgrading stateless pools first, verifying cluster stability, and then upgrading stateful\u002FGPU pools. For auto-upgrades, GKE automatically manages sequential node pool upgrades.\n\nFor standard command sequences and runbook templates, see [`references\u002Frunbook-template.md`](references\u002Frunbook-template.md).\n\n### Large-Scale AI\u002FML Clusters (GPU\u002FTPU)\n\nWhen advising on GPU\u002FTPU upgrades, you MUST cover all of the following:\n\n- **No Live Migration**: GPU VMs do not support live migration; GKE upgrades will force pod restarts. Explain this to the user.\n- **Fixed Reservations & Quota**: H100\u002FA100 typically use fixed reservations with no spare quota. Recommend a **rolling upgrade with zero surge** (`maxSurge=0, maxUnavailable=1`), which releases the reservation of the node being upgraded before provisioning its replacement. Explain that **Blue-Green upgrades are not feasible** here because they require double (2x) the GPU resources (both quota and reservations) during the transition.\n- **Driver Coupling**: The GPU driver is tightly coupled to the node OS image, so node upgrades introduce new Linux kernels and NVIDIA drivers that can break CUDA compatibility. Advise upgrading and testing CUDA compatibility in a staging environment\u002Fcluster first, and updating workload dependencies (CUDA version in container images) to match the new driver before attempting the upgrade again. To diagnose driver regressions, compare OS image, kernel version (`uname -r`), and driver versions between old (working) and new (non-working) nodes, and deploy a test pod (e.g., vector addition) to verify GPU access. If production is blocked, rolling the node pool back to the previous version is the quickest mitigation.\n- **Operational Safety**: Recommend GKE **maintenance exclusions** to block auto-upgrades during active training campaigns. Prior to manual upgrades, cordon GPU nodes and wait for active training jobs to checkpoint\u002Fcomplete.\n- **TPU Considerations**: TPU slices are recreated atomically (not rolling); maintenance on one slice restarts all slices in the environment.\n\n## Checklists\n\nProduce checklists as copyable markdown with checkboxes. See [`references\u002Fchecklists.md`](references\u002Fchecklists.md) for the full pre-upgrade and post-upgrade checklist templates. Adapt them to the user's environment.\n\n**Stateful Workloads:** When stateful workloads (databases) are present, always include checks for PV backup completion and verification of PV reclaim policies (e.g., Retain vs Delete) in the pre-upgrade checklist.\n\n**Autopilot Checklists:** For Autopilot clusters, ensure the checklists include:\n\n- Verification of `resources.requests` on all containers (Autopilot requirement).\n- You MUST include specific `kubectl` commands for API deprecation checks, specifically: `kubectl get --raw \u002Fmetrics | grep apiserver_request_total | grep deprecated` to check if any active workloads are using deprecated APIs.\n- Verifying PDBs to ensure they don't block node drain (even though GKE manages nodes, PDBs are still respected).\n- Identifying and deleting \"bare pods\" (pods not managed by a ReplicaSet\u002FDeployment\u002FStatefulSet) as they won't be rescheduled during node recreation.\n- Verification of `terminationGracePeriodSeconds` to ensure pods have enough time to shut down gracefully during node recreation.\n\n## Maintenance runbooks\n\nProduce step-by-step runbooks with actual `gcloud` and `kubectl` commands. See `references\u002Frunbook-template.md` for the standard command sequences.\n\n**Any runbook that relaxes a safety control must restore it in the same runbook.** This applies above all to PDBs during a node-pool migration or rollback: back the PDBs up before draining, and make re-applying them a numbered step with its own verification, not a closing remark. A runbook that patches `maxUnavailable: 100%` to unblock a drain and never reverts it leaves the cluster without disruption protection, and the gap is invisible until the next voluntary eviction. The same rule covers maintenance exclusions, cordons, and autoscaler `minNodes` overrides added to get through the procedure.\n\n## Maintenance Window Pauses\n\nWhen diagnosing a \\\"stuck\\\" upgrade, consider if it was paused by a maintenance window:\n\n- **Silent Pause Behavior:** If a maintenance window closes before an upgrade (auto or manual) completes, GKE intentionally pauses the rollout to prevent disruption outside allowed times.\n- **Mixed-Version State:** The cluster is left in a stable mixed-version state (some nodes upgraded, some not). You MUST explicitly state that this is a supported and safe intended outcome.\n- **Resumption:** The upgrade will automatically resume when the next maintenance window opens.\n- **Mitigation for immediate completion:** If the user wants to complete the upgrade immediately, you MUST suggest **temporarily widening the maintenance window** to include the current time (e.g., using `gcloud container clusters update ... --maintenance-window-start ... --maintenance-window-duration ...`). Do not suggest re-triggering the manual upgrade or bypassing the window.\n\n## Troubleshooting\n\nWhen a user reports a stuck or failing upgrade, you MUST systematically analyze and address ALL 5 potential causes in your final response. Do not omit checks even if you suspect one is the primary cause:\n\n1. **PDB blocking drain:** Identify if any PDB has `ALLOWED DISRUPTIONS = 0` using `kubectl get pdb -A`.\n2. **Resource constraints:** Check if pods are stuck in `Pending` due to capacity limits.\n3. **Bare pods:** Identify pods without owner references that are blocking the drain (recommend deleting them).\n4. **Admission webhooks:** Check if Validating\u002FMutating webhooks are rejecting pod creation on new nodes.\n5. **PVC attachment issues:** Check for volume attachment failures (especially zone constraints).\n\n**Stockout \u002F Quota Exhaustion Rule:**\n\n- If the upgrade is stuck due to `ZONE_RESOURCE_POOL_EXHAUSTED` (stockout) or `QUOTA_EXCEEDED` for Compute Engine resources:\n  1. Recommend modifying the upgrade strategy to `maxSurge=0` (rolling in-place) to bypass quota limits.\n  2. For `QUOTA_EXCEEDED`, suggest requesting a quota increase from Google Cloud.\n  3. You MUST suggest **migrating workloads or creating new node pools in a different zone or region** where capacity\u002Fquota is available as a mitigation.\n\nRefer to [`references\u002Ftroubleshooting.md`](references\u002Ftroubleshooting.md) for the exact diagnostic commands and fix procedures for each step.\n\n## References\n\n- [GKE Release Notes](https:\u002F\u002Fcloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Frelease-notes)\n- [Upgrading GKE Clusters](https:\u002F\u002Fcloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fhow-to\u002Fupgrading-a-cluster)\n- [Troubleshoot GKE upgrades](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Ftroubleshooting\u002Fupgrades.md.txt)\n- [Get upgrade information (upgrade assist)](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fhow-to\u002Fupgrade-assist.md.txt)\n- [Node pool upgrade strategies (surge & blue-green)](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fhow-to\u002Fnode-pool-upgrade-strategies.md.txt)\n- [Maintenance Windows & Exclusions](https:\u002F\u002Fcloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fconcepts\u002Fmaintenance-windows-and-exclusions)\n- [Rollout Sequencing Concepts](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fconcepts\u002Frollout-sequencing\u002Fabout-rollout-sequencing)\n- [Configure Rollout Sequencing](https:\u002F\u002Fcloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fhow-to\u002Frollout-sequencing\u002Fmanage-upgrades-with-rollout-sequencing)\n","# GKE Upgrades & Maintenance\n\nProduce clear, actionable documents — upgrade plans, runbooks, or checklists — tailored to the user's environment. Output should be specific to their cluster mode, release channel, version, and workload types rather than generic advice.\n\nAlways frame guidance around the auto-upgrade model: auto-upgrade with maintenance windows and exclusions is the preferred control mechanism.\n\n## Attribution\n\n**MUST READ**: Before executing any `gcloud`, REST API, or MCP command, you\nMUST read [Usage Attribution](references\u002Fattribution.md). For commands executed\ndirectly in the terminal (never in generated scripts, Terraform, or user code),\nprefix `gcloud` with\n`CLOUDSDK_METRICS_REQUEST_ATTRIBUTION=\"agent-skills\u002F1.0 (skill:gke-upgrades)\"`\nand append `agent-skills\u002F1.0 (skill:gke-upgrades)` to `User-Agent` headers.\n\n## Context Gathering\n\nBefore producing any upgrade artifact, establish:\n\n- **Cluster mode** — Standard or Autopilot? (Autopilot has no node pool management, mandatory resource requests, no SSH)\n- **Current and target versions** — Node version skew must be within 2 minor versions of control plane.\n- **Release channel** — Rapid, Regular, Stable, or Extended.\n- **Environment topology & Rollout Sequencing** — Single vs multi-cluster, dev\u002Fstaging\u002Fprod tiers, and whether Rollout Sequencing is used.\n- **Workload sensitivity** — StatefulSets, databases, GPU, long-running batch need special handling.\n\nIf the user provides these upfront, skip straight to the deliverable. If they're vague, fill in reasonable defaults and flag assumptions.\n\n## Core Principles\n\nGKE versions follow Kubernetes version terminology: **Major.Minor.Patch** (e.g., 1.30.1-gke.1187000). A **Minor** version bump (e.g., 1.29 → 1.30) introduces new features and APIs. A **Patch** version bump (e.g., 1.30.1 → 1.30.2) introduces security and bug fixes. Ensure the user understands this distinction.\n\n1. **Sequential control plane, skip-level node pools** -- Control plane upgrades are sequential (N → N+1 → N+2). Node pools support skip-level (N+2) upgrades.\n2. **Control plane first** -- Control plane must be upgraded before node pools. Nodes can trail by up to 2 minor versions.\n3. **Environment progression** -- Always upgrade dev\u002Fstaging before production. Use **Rollout Sequencing** (preferred) to automate and enforce this progression across environments (e.g., dev → staging → prod), or manually coordinate version progression if Rollout Sequencing is not used.\n4. **Workload-aware** -- Upgrade strategy depends on what's running (stateless, stateful, GPU, batch).\n5. **Release channels first** -- Always recommend release channels. Note that \"No channel\" (static versioning) is deprecated and clusters should be migrated to release channels.\n6. **Rollback\u002FDowngrade** -- Control Plane patches and Node Pools (minor and patches) can be rolled back (downgraded to a target version). GKE supports a 2-step Control Plane minor upgrade where step 1 is rollbackable. Other Control Plane minor version rollbacks are NOT customer-doable and require GKE Support.\n7. **Node pool upgrade ordering** -- When upgrading multiple node pools, always recommend sequential ordering: upgrade non-critical\u002Fstateless pools first (acting as a canary) to verify cluster health before upgrading critical stateful (database) or GPU pools.\n\n## Release Channels\n\n| Channel | Best for | SLA |\n|---------|----------|-----|\n| **Rapid** | Dev\u002Ftest, early feature access | No upgrade stability SLA |\n| **Regular** (default) | Most production | Full SLA |\n| **Stable** | Mission-critical, stability-first | Full SLA |\n| **Extended** | Compliance, EoS enforcement control | Full SLA |\n\n### Support Lifecycle\nStandard GKE versions are supported for 14 months after they become available in the **Regular** channel. This means:\n\n- **Rapid** channel versions may be supported for longer than 14 months (since they enter Rapid before Regular).\n- **Stable** channel versions may be supported for less than 14 months (since they enter Stable after Regular).\n- **Extended** support extends this period up to 24 months. Note that extra cost applies only during the extended support period (months 15-24).\n\n### Current Capabilities\n\n- **Extended channel math**: 14 months of standard support + ~10 months of extended support ≈ 24 months total per minor version. Even on Extended, forced upgrades still occur: if you take no action, GKE auto-upgrades the cluster at End of Support — averaging a minor version bump roughly every 4 months, the same cadence as other channels (features just arrive later).\n- **Upgrade reliability (KubeCon NA 2025)**: Google reports a 99.99% upgrade success rate across GKE control planes and nodes, with safe rollback and skip-version upgrade support positioned to let teams upgrade less often (e.g., annually instead of quarterly). Pilot skip-version upgrades in non-production clusters first.\n- **Autoscaled blue-green node upgrades** (Preview): a blue-green variant that scales the green pool on demand instead of pre-provisioning a full duplicate pool — for disruption-sensitive workloads that cannot reserve 2x capacity.\n- **Scheduled cluster upgrade notifications** (Preview): opt in to be notified ahead of scheduled minor upgrades and wire the notifications into alerting.\n- **Graceful termination and PDBs during drains**: blue-green (including autoscaled blue-green, Preview) is the *only* strategy that honors `terminationGracePeriodSeconds` for up to 24 hours; surge upgrades honor it for up to 60 minutes. During node drains, GKE respects PDBs for a maximum of 60 minutes, after which pods are force-deleted (a notification is sent).\n\n## Maintenance Windows & Exclusions\n\nConfigure maintenance windows to control auto-upgrade timing. GKE also supports node pool level maintenance exclusions (in addition to cluster level) to block upgrades for specific workloads.\n\n**Exclusion types & Limits:**\n\n- **\"No upgrades\" (Scope: `no_upgrades`)**: Blocks all upgrades (minor, patch, node).\n  - **Limits**: Max **90 days per exclusion**, and a cluster can have at most **3** such exclusions. Together they must still allow at least **48 hours of maintenance availability in any rolling 92-day window** — so you cannot chain them into a continuous freeze longer than 90 days. GKE recommends keeping these under 30 days.\n- **\"No minor or node upgrades\" (Scope: `no_minor_or_node_upgrades`)**: Blocks minor and node upgrades, but allows control plane patch upgrades (low risk).\n  - **Limit**: No fixed day cap — bounded by the minor version's **End of Support (EoS)**. Recommendation: keep under ~6 months.\n- **\"No minor upgrades\" (Scope: `no_minor_upgrades`)**: Blocks minor upgrades, but allows control plane patches and node upgrades.\n  - **Limit**: No fixed day cap — bounded by EoS. Recommendation: keep under ~6 months.\n\n**Important Exclusion Rules (MUST follow when recommending exclusions and MUST include in the final text response):**\n\n1. **Auto-upgrades only**: Maintenance exclusions **only block automatic upgrades**. Manual upgrades initiated by the user will bypass exclusions. You MUST explain this to the user.\n2. **Warn against \"No channel\"**: You MUST explicitly warn that disabling release channels (\"No channel\" \u002F static versioning) is deprecated and must not be used as a replacement for exclusions.\n3. **Compare Scopes**: You MUST explain the difference between 'No upgrades' (limitations, blocks patches) and 'No minor or node upgrades' (allows patches, longer duration). Recommend 'No minor or node upgrades' when the user wants to allow security patches\u002Ffixes while blocking minor version jumps.\n4. **Handle periods > 90 days**: If the user needs to block upgrades for more than 90 days, you MUST explain that 'No upgrades' is limited to 90 days per exclusion (max 3 per cluster, and 48 hours of maintenance availability must remain in any rolling 92-day window, preventing chaining into longer continuous freezes) and advise using scoped exclusions ('No minor or node upgrades' \u002F 'No minor upgrades'), which have no fixed day cap and can run until the minor version's End of Support.\n5. **Version skew**: Be mindful of version skew (between control plane and node pools) when using exclusions. Ensure skew does not exceed the supported 2 minor versions. Use `--add-maintenance-exclusion-until-end-of-support` for persistent exclusions.\n6. **Correct gcloud syntax**: When providing `gcloud` commands for exclusions, you MUST use the separate flag syntax: `--add-maintenance-exclusion-name`, `--add-maintenance-exclusion-start`, `--add-maintenance-exclusion-end` (or `--add-maintenance-exclusion-until-end-of-support`), and `--add-maintenance-exclusion-scope` (do NOT use a single comma-separated `--add-maintenance-exclusion` flag).\n\n## Mandatory Upgrade Overrides\n\nGKE reserves the right to override user-defined maintenance windows and exclusions for mandatory operations. These overrides cannot be disabled or blocked.\n\n**Common Override Scenarios:**\n\n- **Critical Security Patches**: Urgent vulnerability fixes that must be applied immediately to protect infrastructure.\n- **End of Support (EoS) \u002F End of Life (EOL) Enforcement**: If a cluster is running an unsupported version, GKE will force upgrade it to a supported version.\n- **Expiring Certificates**: If control plane certificates (CAs) are expiring (within 30 days) and rotation is required to prevent cluster unrecoverability.\n- **Maintenance Starvation**: GKE requires at least 48 hours of maintenance availability in any rolling 92-day window. If exclusions block too much, GKE may force an upgrade.\n\n**Guidance (MUST follow when overrides are discussed):**\n\n1. **Correlate with Bulletins**: If GKE performs an unexpected upgrade, you MUST explicitly suggest checking GKE Release Notes or Security Bulletins to correlate the event with emergency patches (do not just suggest checking Cloud Audit Logs).\n2. **Design for Resilience**: Workloads must be designed to survive unexpected control plane or node rotation. You MUST recommend:\n   - Regional clusters (multi-master) to ensure API availability during control plane upgrades.\n   - Multi-zone workload deployments.\n   - Replicas > 1 for critical deployments.\n   - Properly configured Pod Disruption Budgets (PDBs) that are not overly restrictive.\n\n## Upgrade Planning\n\nWhen asked to plan an upgrade, produce a structured document covering:\n\n- Version compatibility (breaking changes, deprecated APIs) (minor version upgrades only)\n- Upgrade path (sequential minor version upgrades) (minor version upgrades only)\n- Node pool upgrade strategy (Standard only)\n- Workload readiness (PDBs, resource requests)\n- Rollback\u002FContingency procedure (how to revert node pools or coordinate with GKE Support for master rollback)\n\n**Compatibility Search Rule:**\n\n- If compatibility information (e.g., third-party operator compatibility, GPU driver\u002FCUDA compatibility matrix) is not immediately available in the workspace or via a quick web search, **do NOT loop or make multiple search attempts**. Instead, list the compatibility verification as a **critical pre-upgrade action item** for the user in the checklist.\n\n### Node Pool Strategy (Standard Only)\n\nRecommend **Surge upgrade** as the default and most common strategy, with per-pool settings:\n\n- **Stateless**: Higher `maxSurge` (2-3) for speed, `maxUnavailable=0` for safety.\n- **Stateful\u002FDB**: `maxSurge=1, maxUnavailable=0` (conservative).\n- **GPU (fixed reservation)**: `maxSurge=0, maxUnavailable=1` (no surge capacity).\n- **Large (50+ nodes)**: `maxSurge=20, maxUnavailable=0` (max parallelism).\n\nFor mission-critical workloads requiring fast rollback or strict validation, recommend **Standard Blue-Green** upgrades. Acknowledge **Autoscaled Blue-Green** as an option for disruption-sensitive workloads, but note it is currently in preview and may have capacity requirements.\n\n**Upgrade Ordering (User-initiated only):** When planning manual upgrades, specify the sequence of node pool upgrades. Recommend upgrading stateless pools first, verifying cluster stability, and then upgrading stateful\u002FGPU pools. For auto-upgrades, GKE automatically manages sequential node pool upgrades.\n\nFor standard command sequences and runbook templates, see [`references\u002Frunbook-template.md`](references\u002Frunbook-template.md).\n\n### Large-Scale AI\u002FML Clusters (GPU\u002FTPU)\n\nWhen advising on GPU\u002FTPU upgrades, you MUST cover all of the following:\n\n- **No Live Migration**: GPU VMs do not support live migration; GKE upgrades will force pod restarts. Explain this to the user.\n- **Fixed Reservations & Quota**: H100\u002FA100 typically use fixed reservations with no spare quota. Recommend a **rolling upgrade with zero surge** (`maxSurge=0, maxUnavailable=1`), which releases the reservation of the node being upgraded before provisioning its replacement. Explain that **Blue-Green upgrades are not feasible** here because they require double (2x) the GPU resources (both quota and reservations) during the transition.\n- **Driver Coupling**: The GPU driver is tightly coupled to the node OS image, so node upgrades introduce new Linux kernels and NVIDIA drivers that can break CUDA compatibility. Advise upgrading and testing CUDA compatibility in a staging environment\u002Fcluster first, and updating workload dependencies (CUDA version in container images) to match the new driver before attempting the upgrade again. To diagnose driver regressions, compare OS image, kernel version (`uname -r`), and driver versions between old (working) and new (non-working) nodes, and deploy a test pod (e.g., vector addition) to verify GPU access. If production is blocked, rolling the node pool back to the previous version is the quickest mitigation.\n- **Operational Safety**: Recommend GKE **maintenance exclusions** to block auto-upgrades during active training campaigns. Prior to manual upgrades, cordon GPU nodes and wait for active training jobs to checkpoint\u002Fcomplete.\n- **TPU Considerations**: TPU slices are recreated atomically (not rolling); maintenance on one slice restarts all slices in the environment.\n\n## Checklists\n\nProduce checklists as copyable markdown with checkboxes. See [`references\u002Fchecklists.md`](references\u002Fchecklists.md) for the full pre-upgrade and post-upgrade checklist templates. Adapt them to the user's environment.\n\n**Stateful Workloads:** When stateful workloads (databases) are present, always include checks for PV backup completion and verification of PV reclaim policies (e.g., Retain vs Delete) in the pre-upgrade checklist.\n\n**Autopilot Checklists:** For Autopilot clusters, ensure the checklists include:\n\n- Verification of `resources.requests` on all containers (Autopilot requirement).\n- You MUST include specific `kubectl` commands for API deprecation checks, specifically: `kubectl get --raw \u002Fmetrics | grep apiserver_request_total | grep deprecated` to check if any active workloads are using deprecated APIs.\n- Verifying PDBs to ensure they don't block node drain (even though GKE manages nodes, PDBs are still respected).\n- Identifying and deleting \"bare pods\" (pods not managed by a ReplicaSet\u002FDeployment\u002FStatefulSet) as they won't be rescheduled during node recreation.\n- Verification of `terminationGracePeriodSeconds` to ensure pods have enough time to shut down gracefully during node recreation.\n\n## Maintenance runbooks\n\nProduce step-by-step runbooks with actual `gcloud` and `kubectl` commands. See `references\u002Frunbook-template.md` for the standard command sequences.\n\n**Any runbook that relaxes a safety control must restore it in the same runbook.** This applies above all to PDBs during a node-pool migration or rollback: back the PDBs up before draining, and make re-applying them a numbered step with its own verification, not a closing remark. A runbook that patches `maxUnavailable: 100%` to unblock a drain and never reverts it leaves the cluster without disruption protection, and the gap is invisible until the next voluntary eviction. The same rule covers maintenance exclusions, cordons, and autoscaler `minNodes` overrides added to get through the procedure.\n\n## Maintenance Window Pauses\n\nWhen diagnosing a \\\"stuck\\\" upgrade, consider if it was paused by a maintenance window:\n\n- **Silent Pause Behavior:** If a maintenance window closes before an upgrade (auto or manual) completes, GKE intentionally pauses the rollout to prevent disruption outside allowed times.\n- **Mixed-Version State:** The cluster is left in a stable mixed-version state (some nodes upgraded, some not). You MUST explicitly state that this is a supported and safe intended outcome.\n- **Resumption:** The upgrade will automatically resume when the next maintenance window opens.\n- **Mitigation for immediate completion:** If the user wants to complete the upgrade immediately, you MUST suggest **temporarily widening the maintenance window** to include the current time (e.g., using `gcloud container clusters update ... --maintenance-window-start ... --maintenance-window-duration ...`). Do not suggest re-triggering the manual upgrade or bypassing the window.\n\n## Troubleshooting\n\nWhen a user reports a stuck or failing upgrade, you MUST systematically analyze and address ALL 5 potential causes in your final response. Do not omit checks even if you suspect one is the primary cause:\n\n1. **PDB blocking drain:** Identify if any PDB has `ALLOWED DISRUPTIONS = 0` using `kubectl get pdb -A`.\n2. **Resource constraints:** Check if pods are stuck in `Pending` due to capacity limits.\n3. **Bare pods:** Identify pods without owner references that are blocking the drain (recommend deleting them).\n4. **Admission webhooks:** Check if Validating\u002FMutating webhooks are rejecting pod creation on new nodes.\n5. **PVC attachment issues:** Check for volume attachment failures (especially zone constraints).\n\n**Stockout \u002F Quota Exhaustion Rule:**\n\n- If the upgrade is stuck due to `ZONE_RESOURCE_POOL_EXHAUSTED` (stockout) or `QUOTA_EXCEEDED` for Compute Engine resources:\n  1. Recommend modifying the upgrade strategy to `maxSurge=0` (rolling in-place) to bypass quota limits.\n  2. For `QUOTA_EXCEEDED`, suggest requesting a quota increase from Google Cloud.\n  3. You MUST suggest **migrating workloads or creating new node pools in a different zone or region** where capacity\u002Fquota is available as a mitigation.\n\nRefer to [`references\u002Ftroubleshooting.md`](references\u002Ftroubleshooting.md) for the exact diagnostic commands and fix procedures for each step.\n\n## References\n\n- [GKE Release Notes](https:\u002F\u002Fcloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Frelease-notes)\n- [Upgrading GKE Clusters](https:\u002F\u002Fcloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fhow-to\u002Fupgrading-a-cluster)\n- [Troubleshoot GKE upgrades](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Ftroubleshooting\u002Fupgrades.md.txt)\n- [Get upgrade information (upgrade assist)](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fhow-to\u002Fupgrade-assist.md.txt)\n- [Node pool upgrade strategies (surge & blue-green)](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fhow-to\u002Fnode-pool-upgrade-strategies.md.txt)\n- [Maintenance Windows & Exclusions](https:\u002F\u002Fcloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fconcepts\u002Fmaintenance-windows-and-exclusions)\n- [Rollout Sequencing Concepts](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fconcepts\u002Frollout-sequencing\u002Fabout-rollout-sequencing)\n- [Configure Rollout Sequencing](https:\u002F\u002Fcloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fhow-to\u002Frollout-sequencing\u002Fmanage-upgrades-with-rollout-sequencing)\n",{"name":5,"metadata":50,"description":7},{"version":51,"category":52},"1.1.1","Containers","main","bb9b3f464aae37af360d079c1d863524955b0363","skills\u002Fcloud\u002Fgke-upgrades",2002,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills","https:\u002F\u002Fgithub.com\u002Fgoogle","https:\u002F\u002Fopensource.google\u002F","Google ❤️ Open Source","2026-11-13 02:42:47",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add google\u002Fskills --skill gke-upgrades",{"tool":68,"command":69},"bunx","bunx skills add google\u002Fskills --skill gke-upgrades",{"tool":71,"command":72},"pnpm","pnpm dlx skills add google\u002Fskills --skill gke-upgrades","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-upgrades\u002FSKILL.md",true,[76,82,86,90],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fattribution.md","REFERENCE","参考文档",1876,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-upgrades\u002Freferences\u002Fattribution.md",{"path":83,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fchecklists.md",3412,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-upgrades\u002Freferences\u002Fchecklists.md",{"path":87,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Frunbook-template.md",6243,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-upgrades\u002Freferences\u002Frunbook-template.md",{"path":91,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Ftroubleshooting.md",12360,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-upgrades\u002Freferences\u002Ftroubleshooting.md",[95,131,162,191,218,243],{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":109,"publishedAt":45},"01M6998S2EZKD3GEJ7F943RZTE","sign-in-with-google-web","Implement, configure, and secure Sign In With Google (SiwG) using Google Identity Services (GIS \u002F `https:\u002F\u002Faccounts.google.com\u002Fgsi\u002Fclient`) across web architectures. Use when creating Google sign-in buttons, implementing Google One Tap with FedCM, integrating GIS in React\u002FNext.js\u002FAngular\u002FHTML, verifying ID tokens on backend runtimes (Python\u002FNode.js\u002FGo\u002FJava), enforcing Google Workspace domain restrictions (`hd`), securing client-side ID tokens via WebCrypto nonces or encrypted IndexedDB, embedding in cross-origin iframes via the Intermediate Iframe API (`https:\u002F\u002Faccounts.google.com\u002Fgsi\u002Fintermediate`), configuring Content Security Policy (CSP), COOP, and Permissions Policy (`identity-credentials-get`) headers, or handling sign-out and revocation. Don't use for legacy Google Sign-In (`gapi.auth2`), Google Cloud IAM service accounts, or Android\u002FiOS native Credential Manager.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fidentity\u002Fsign-in-with-google-web\u002FSKILL.md",[101,106],{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":107,"categoryName":108,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000010","后端与接口",[9,110,111,112,113,114,115,41,116,117,118,40,119,120,121,122,123,124,125,126,127,128,129,130],"sign in with google web","sign","with","web","android","go","google workspace","google cloud","implement","python","implementing","react","iam","permissions","buttons","secure","manager","identity","architectures","domain","runtimes",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":146,"publishedAt":45},"01M6998PHPDCAD684VW5WRG83D","dpop-adoption","Implement and debug OAuth 2.0 DPoP (RFC 9449) refresh token sender-constraining for WebCrypto, Node.js ES6, and browser runtimes integrating with Google's OAuth platform. Use when configuring non-extractable asymmetric key pairs (P-256), generating DPoP Proof JWTs for authorization code exchange and token refresh, or handling 400 use_dpop_nonce challenge retry loops at oauth2.googleapis.com\u002Ftoken. Don't use for unconstrained OAuth 2.0 flows (where refresh tokens are not bound to a client key pair), or for Google Cloud IAM \u002F service account authentication.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fidentity\u002Fdpop-adoption\u002FSKILL.md",[137,138,141],{"categoryNo":107,"categoryName":108,"taxonomyType":104,"taxonomyTypeDesc":105},{"categoryNo":139,"categoryName":140,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[147,148,9,117,149,150,151,152,153,154,122,155,156,157,36,158,159,127,130,160,161],"dpop adoption","adoption","es6","retry","authentication","flows","challenge","code","browser","loops","at","token","pair","platform","when",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":174,"publishedAt":45},"01M6998M72TC73EEAQH4XC7EXW","retrieving-developer-knowledge","Searches, retrieves, and synthesizes official Google developer documentation across Google Cloud, AI\u002FGemini, Android, Chrome, Web, Flutter, Go, Firebase, and other Google developer platforms. Integrates with the Developer Knowledge MCP server (search_documents, get_documents, answer_query) or the Developer Knowledge REST API fallback. Use when searching for gcloud CLI commands, API syntax, IAM permissions, official documentation, architectural comparisons, or product choice overviews. Don't use for local filesystem lookups or non-Google documentation.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopers\u002Fretrieving-developer-knowledge\u002FSKILL.md",[168,169,172,173],{"categoryNo":107,"categoryName":108,"taxonomyType":104,"taxonomyTypeDesc":105},{"categoryNo":170,"categoryName":171,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":139,"categoryName":140,"taxonomyType":104,"taxonomyTypeDesc":105},{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},[175,176,177,178,117,179,180,181,182,183,184,185,186,161,187,188,189,122,190,123],"retrieving developer knowledge","knowledge","developer","MCP","mcp server","official","developer documentation","get","search","local","choice","documents","query","api","across","documentation",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":197,"publishedAt":45},"01M6998J2CZEXS9BES9S3WWFKC","migrate-to-rust","Clones, analyzes, plans, and migrates legacy codebases (C++, Fortran, Java, Python, C, Shell) from a GitHub URL or local directory to a modern, high-performance, deterministic, 100% Safe Rust architecture, tracking live telemetry across every task bucket, test failure\u002Ffix cycle, and Profile-Guided Optimization (PGO) stage, and producing a first-person AI storytelling report and interactive HTML infographic. Use when migrating a GitHub repository or local codebase to Rust, porting legacy C++, Fortran, Python, or Java workloads to memory-safe Rust, designing Struct-of-Arrays (SoA) or SIMD Rust architectures, or optimizing Rust ports with LLVM PGO. Don't use for unrelated non-Rust refactoring or single-line syntax questions.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopers\u002Fmigrate-to-rust\u002FSKILL.md",[],[198,199,200,201,202,203,204,205,119,206,207,208,209,210,211,184,212,213,214,161,215,216,189,217],"migrate to rust","rust","migrate","github","memory","performance","directory","safe","ports","llvm","soa","cycle","porting","fix","arrays","infographic","high-performance","URL","architecture","unrelated",{"skillNo":219,"name":220,"nameZh":6,"description":221,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":222,"categories":223,"keywords":227,"publishedAt":45},"01M6998GCC3K29WZ82KXMB9E02","finding-google-skills","Google platform decision and setup guidance, loaded on demand from Google's skill catalog. Use when a developer is choosing or setting up part of their stack, such as where to run a service, a database, storage, messaging, authentication, analytics, ads, or AI model serving, and a Google product is a reasonable candidate - whether or not a vendor is named - or when a request names a Google product or API. Brings in the matching Google skill so the answer can weigh Google options, their trade-offs, and when they are not the right fit. Skip when the stack is already settled on another provider and no Google product is named, or the task involves no platform choice.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopers\u002Ffinding-google-skills\u002FSKILL.md",[224,225,226],{"categoryNo":107,"categoryName":108,"taxonomyType":104,"taxonomyTypeDesc":105},{"categoryNo":139,"categoryName":140,"taxonomyType":104,"taxonomyTypeDesc":105},{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},[9,228,229,230,231,160,232,233,234,235,236,151,237,238,239,185,240,241,161,242,188],"finding google skills","storage","as","messaging","model","trade-offs","provider","answer","fit","catalog","up","decision","use","database","candidate",{"skillNo":244,"name":245,"nameZh":6,"description":246,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":247,"categories":248,"keywords":251,"publishedAt":45},"01M6998DWNHTH0BS6W1CY8ZXMP","workload-manager-basics","Use this skill to manage Google Cloud Workload Manager evaluations, rules, scanned resources, and validation results by using public client libraries and the REST API. Use when you need to inspect workload best-practice rules, create and run evaluations for Google Cloud general best practices, SAP, SQL Server, or custom organizational rules, review violations, export results to BigQuery, or automate Workload Manager through client libraries because no service-specific public CLI or MCP server is available. Don't use for general Google Compute Engine instance management, VPC configuration, or standard IAM auditing.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fworkload-manager-basics\u002FSKILL.md",[249,250],{"categoryNo":107,"categoryName":108,"taxonomyType":104,"taxonomyTypeDesc":105},{"categoryNo":139,"categoryName":140,"taxonomyType":104,"taxonomyTypeDesc":105},[252,253,126,254,9,178,255,117,179,256,257,258,259,161,260,188,122,261,262,263,264],"workload manager basics","workload","basics","cli","review","vpc","resources","inspect","you","create","libraries","server","run"]