Agent-Skills.md

Agent Skills: Troubleshoot GKE TPU slice creation blocked by an unstable MIG

>-

ContainersID: aibangjuxin/knowledge/gke-ai-troubleshooting-tpu-slice-mig-stuck-updating

Repository

aibangjuxin/knowledge
aibangjuxin
2

Install this agent skill to your local

pnpm dlx add-skill https://github.com/aibangjuxin/knowledge/tree/HEAD/skills/.kiro/skills/gke-ai-troubleshooting-tpu-slice-mig-stuck-updating

Skill Files

Browse the full folder contents for gke-ai-troubleshooting-tpu-slice-mig-stuck-updating.

Download Skill

Loading file tree…

skills/.kiro/skills/gke-ai-troubleshooting-tpu-slice-mig-stuck-updating/SKILL.md

Skill Metadata

Name
gke-ai-troubleshooting-tpu-slice-mig-stuck-updating
Description
>-

Troubleshoot GKE TPU slice creation blocked by an unstable MIG

This skill helps diagnose GKE TPU Dynamic Slice creation failures and JobSet scheduling delays when the Compute Engine managed instance groups (MIGs) that back the TPU node pool aren't stable (status.isStable: false).

A SliceCreationFailed status reason means that slice creation failed because prerequisites weren't met (for example, required Compute Engine resources are missing) or preflight checks failed (see Use dynamic slicing with a custom scheduler). A MIG that is still creating, updating, or repairing instances is one cause to check. This skill checks the slice status first, then the stability of the backing MIGs.

Prerequisites

Read-only rule: Run read-only diagnostic commands only. Never drain, delete, or re-create nodes, or run any other command that changes the cluster. Give the user any fix to apply themselves.

When you recommend a fix, link the doc section that describes it.

Diagnostic workflow

Step 0: Collect context and set the investigation window [Low Risk]

Collect the necessary contextual parameters from the user prompt or environment:

  • {project_id}, {cluster_name}, {location}, {nodepool_name}, and {issue_time}.
  • {mig_name} and {zone}: Name and zone of the managed instance group that backs {nodepool_name}, from the node pool's instanceGroupUrls field (see View node pools in a Standard cluster and Resource: NodePool). If {nodepool_name} or {mig_name} isn't already known from a failing Slice, find the affected partition, nodes, and backing MIG by following Verify the status of the nodes and the partitions.
  • Time window: By default, query a 60-minute window [{issue_time} - 30m, {issue_time} + 30m] ({start_time} to {end_time}).

Step 1: Detect slice creation failures and MIG errors [Low Risk]

  1. Inspect Slice status and partition nodes: Check the Slice custom resource Status.Conditions for a SliceCreationFailed status reason and identify the affected partitions, nodes, and {mig_name} by following the "Monitor the status of the Slice custom resource" and "Verify the status of the nodes and the partitions" sections of Use dynamic slicing with a custom scheduler, and Monitor the status of the slice.
  2. Query Cloud Logging for MIG errors: Once {mig_name} is identified (or by narrowing the results to {mig_name} once known), run this Cloud Logging query to detect errors on the backing instance group manager across [{start_time}, {end_time}]: 
    resource.type="gce_instance_group_manager"
resource.labels.instance_group_manager_name="{mig_name}"
severity>=ERROR
timestamp >= "{start_time}" AND timestamp <= "{end_time}"
  • Findings:
    • If the Slice status reports SliceCreationFailed or the logs show instance group errors, proceed to Step 2.
    • If no error logs match and the TPU Slice status is ACTIVE, rule out MIG instability and check workload configuration.

Step 2: Check MIG stability (status.isStable) [Low Risk]

Follow Check whether a MIG is stable to inspect the stability (status.isStable) and version target status (status.versionTarget.isReached) of {mig_name}:

  • What the fields mean:
    • status.isStable: false: Changes are active or pending, or the MIG itself is being modified. Proceed to Step 3.
    • status.versionTarget.isReached: false: At least one instance isn't running the target version yet (see Automatically apply VM configuration updates in a MIG). Proceed to Step 3.
    • status.isStable: true and status.versionTarget.isReached: true: No instances are undergoing or scheduled for changes (currentAction is NONE for all instances), and the MIG itself isn't being modified. This rules out MIG instability. If the Slice is still in SliceCreationFailed, hand off to gke-ai-troubleshooting-tpu-dynamic-slices-monitoring, or follow the "Create a Slice custom resource" and "Verify the status of the nodes and the partitions" sections of Use dynamic slicing with a custom scheduler.

Step 3: Find failed or stalled instance operations [Low Risk]

Direct the user to the "Check the status of managed instances" and "List instance errors" sections of View information about MIGs and managed instances (include both section names and the document title) to inspect individual instance states (currentAction and instanceStatus) and list the most recent errors in {mig_name}:

  • If the errors show capacity or quota failures such as ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS or QUOTA_EXCEEDED, go to Step 5, item 2.
  • Otherwise, proceed to Step 4 to check for node pool upgrade or auto-repair operations.

Step 4: Check node pool operations [Low Risk]

A MIG that is still changing instances can be the result of a node pool upgrade or repair:

  1. Check node pool upgrades: Follow Check node pool upgrade status to list the cluster operations and find upgrade operations targeting {nodepool_name} in [{start_time}, {end_time}]. Also review Upgrade your node pools for dynamic slicing upgrade requirements (required surge settings and deleting active super-slices before upgrading).
    • If an upgrade operation is still running, go to Step 5, item 1 or item 3.
    • If an upgrade operation was cancelled, failed, or is incomplete, go to Step 5, item 4.
  2. Check automated node repairs: Follow Get information about recent automated repair events to check for repair operations on {nodepool_name}.
    • If a node auto-repair operation is running, go to Step 5, item 1.
  3. If no operation or error explains the unstable MIG: Go to Step 5, item 5 to contact Cloud Customer Care.

Step 5: Resolution [High Risk]

Guardrail: Don't modify GKE-managed instance groups or VMs directly through Compute Engine. Manage node pools through GKE.

  1. Wait for an ongoing update or auto-repair to finish: If a node pool upgrade or automated repair is still making progress, the user can wait until the MIG is stable (status.isStable: true) by following Check whether a MIG is stable.
  2. Resolve capacity or quota errors: When Step 3 shows ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS or QUOTA_EXCEEDED, rolling back an upgrade won't resolve the shortage. Follow Issue: Node pool creation fails due to insufficient resources and the "Insufficient quota to satisfy the TPU request" and "Insufficient TPU resources to satisfy the TPU request" sections of Troubleshoot TPUs in GKE.
  3. Cancel an in-progress node pool upgrade: If the user wants to stop an upgrade that is still running, follow Cancel a node pool upgrade. For dynamic slicing node pools, also check Upgrade your node pools for the required surge settings and deleting active super-slices before upgrading.
  4. Resume or roll back a cancelled, failed, or incomplete node pool upgrade:
    • Follow the "Resume a node pool upgrade" or "Roll back a node pool upgrade" sections of Manually upgrade a cluster's control plane or node pools. As documented there, rollback applies if an in-progress upgrade was cancelled, the upgrade failed, or the upgrade is incomplete due to a maintenance window timing out (you can't roll back node pools once they have been successfully upgraded); alternatively, a cancelled or failed, partially completed upgrade can be resumed.
    • Afterwards, verify that the MIG is stable by following Check whether a MIG is stable.
  5. Escalate unexplained MIG instability: If no node pool upgrade, repair operation, or capacity/quota error explains why {mig_name} remains unstable, direct the user to Cloud Customer Care by following Get support.
  6. Verify node pool and slice recovery: After the instance group is stable (status.isStable: true), follow the "Monitor the status of the Slice custom resource" and "Create a Slice custom resource" sections of Use dynamic slicing with a custom scheduler to verify that the Slice reaches the ACTIVE state. If the Slice stays in SliceCreationFailed after the MIG stabilizes, check whether the retry annotation documented in "Create a Slice custom resource" is set on the Slice.