Agent skill · google
gke-node-notready
Diagnoses GKE nodes reporting NotReady or Unknown status by inspecting node conditions, events, kubelet/containerd logs, and node metrics, then proposing safe remediations. Use when nodes show NotReady, when the kubelet stops posting node status, or when workloads are evicted or stuck Pending due to node health. Don't use for pod-level application failures (use gke-workload-troubleshooting), autoscaler scale-up/scale-down decisions (use gke-cluster-autoscaler), or non-GKE compute.
What it needs
About 6k tokens when loaded.
What this skill does
GKE Node NotReady Troubleshooting Skill Use this skill to systematically diagnose why one or more GKE nodes report a NotReady (or Ready: Unknown) status and to propose safe remediations. A NotReady status means the node's kubelet is not reporting to the control plane correctly, so Kubernetes stops scheduling new Pods on the node, which can reduce application capacity and cause downtime. This skill operates non-interactively and enforces a read-only diagnostics boundary: gather evidence first, then propose a fix (a kubectl/gcloud command or a GitOps manifest change) for a human to apply. Never mutate the cluster, drain, delete, or recreate nodes automatically. [!IMPORTANT] First rule out an expected NotReady: a node that is newly provisioning, upgrading, being repaired, cordoned, or scaling down will transiently report NotReady. Only treat it as a fault if it persists beyond the expected window. 🔍 Diagnostic Workflow Step 0: Context discovery & time window 1. Parameter extraction — obtain projectid, clustername, clusterlocation, and nodename non-interactively from the user prompt, active SETTINGS.md, or environment defaults (kubectl config current-context, gcloud config get-value project). 2. Credentials & fallback — attempt gcloud container clusters get-credentials {clustername} --location {clusterlocation} --project {projectid}. If the cluster is unreachable or commands fail (sandbox/dry-run/offline), present the exact diagnostic commands for a human to run and continue the analysis from the reported symptoms. 3. Time window — determine {issuetime} (explicit, relative, or now) and center a 1-hour window around it (start = issuetime - 30m, end = issuetime + 30m) for all log/metric queries. -------------------------------------------------------------------------------- Step 1: Identify NotReady nodes and gather initial status Equivalent via Cloud Logging (preferred when kubectl access is limited or for historical events). …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills google/gke-node-notready