---

name: gke-ai-troubleshooting-tpu-slice-mig-stuck-updating description: >- Diagnose and resolve GKE TPU Dynamic Slice creation and JobSet scheduling failures blocked by underlying Compute Engine managed instance groups (MIGs) stuck in an updating or unstable state (isStable=False). Use when TPU slice creation fails with a SliceCreationFailed status reason, when JobSets remain stuck in pending, or when MIG status reflects isStable=False or versionTarget.isReached=False during TPU slice formation. Don't use for SliceCreationFailed causes unrelated to MIG stability (use gke-ai-troubleshooting-tpu-dynamic-slices-monitoring) or general pod scheduling failures unrelated to TPU slices. metadata: version: "1.0.1" category: Containers

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.

Attribution

MUST READ: Before executing any gcloud, REST API, or MCP command, you MUST read Usage Attribution. 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-ai-troubleshooting-tpu-slice-mig-stuck-updating)" and append agent-skills/1.0 (skill:gke-ai-troubleshooting-tpu-slice-mig-stuck-updating) to User-Agent headers.

Prerequisites

• Google Cloud SDK & Tools:
  • For installing and initializing gcloud (project selection and authentication) and enabling the GKE API, follow Before you begin.
  • For installing kubectl and configuring cluster credentials, follow the "Install kubectl", "Install required plugins", and "Store cluster information for kubectl" sections of Install kubectl and configure cluster access.
• API Enablement & Billing:
  • Verify that the project has an active Cloud Billing account.
  • Enable APIs: container.googleapis.com, compute.googleapis.com, and logging.googleapis.com.
• Required IAM Roles:
  • Logs Viewer (roles/logging.viewer): Inspect Cloud Audit Logs for MIG errors.
  • Compute Viewer (roles/compute.viewer): Check MIG stability (isStable) and instance progress.
  • Kubernetes Engine Viewer (roles/container.viewer): Inspect Slice custom resources (slices.accelerator.gke.io), nodes, and cluster operations.
• Documentation:
  • Use dynamic slicing with a custom scheduler (Sections: "Before you begin", "Create a Slice custom resource", "Monitor the status of the Slice custom resource", "Verify the status of the nodes and the partitions", "Upgrade your node pools")
  • Install kubectl and configure cluster access (Sections: "Install kubectl", "Install required plugins", "Store cluster information for kubectl")
  • Add and manage node pools (Sections: "View node pools in a Standard cluster")
  • View information about MIGs and managed instances (Sections: "Check whether a MIG is stable", "Check the status of managed instances", "List instance errors")
  • Automatically apply VM configuration updates in a MIG (Sections: "Verify whether an update rollout is complete")
  • Manually upgrade a cluster's control plane or node pools (Sections: "Check node pool upgrade status", "Cancel a node pool upgrade", "Resume a node pool upgrade", "Roll back a node pool upgrade")
  • Auto-repair nodes (Sections: "Get information about recent automated repair events")
  • Troubleshoot GKE Standard node pools (Sections: "Issue: Node pool creation fails due to insufficient resources")
  • Troubleshoot TPUs in GKE (Sections: "Insufficient quota to satisfy the TPU request", "Insufficient TPU resources to satisfy the TPU request")
  • REST Resource: projects.locations.clusters.nodePools (Sections: "Resource: NodePool")
  • Schedule dynamic slices with Kueue and TAS (Sections: "Monitor the status of the slice")
  • About TPUs in GKE
  • Get support (Sections: "Before you contact support")

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.