Skip to content

lookout cloud stockout

GCE capacity stockouts (ZONE_RESOURCE_POOL_EXHAUSTED) per zone/machine-type over —since (default 24h), with event-derived reroute candidates — the cloud-side why behind pods stuck Pending on failed scale-ups.

MCP tool: k8s_cloud_stockout

Terminal window
lookout cloud stockout [flags]
FlagTypeDefaultMeaning
--namespacestring—limit the scan to one namespace
-Abool—scan all namespaces
--workloadstring—target one workload as <Kind>/<namespace>/<name>, e.g. Deployment/prod/api
--sinceduration—how far back to look (0 = command default)
--formatstringlogfmtoutput format: logfmt|json (one record per line either way)
--timeoutduration10sabort the invocation after this long (exit 1)
--kubeconfigstring—path to a kubeconfig file, instead of $KUBECONFIG / ~/.kube/config
--contextstring—kubeconfig context to read, instead of its current-context. Selects a cluster for THIS invocation only — nothing is written back — so concurrent invocations can target different clusters. Reported as context=<name> in the summary line
--exemptionsstring—path to a git-reviewed exemption file (YAML); covered findings are ANNOTATED with their reason and expiry and counted as exempt=<n> in the summary, never dropped

Every kind= this command can emit, and the severities it carries them at. Nothing else appears in its output; a kind absent from a run means the check looked and found nothing. See the finding-kind glossary for the whole vocabulary.

KindSeverityClaim
stockout.zonewarningthe cloud had no capacity for a machine type in this zone during the window — the reason a scale-up failed and pods stayed Pending
cloud.unavailableinfothe cloud capability this check needs is unavailable, so nothing was examined — an explicit degradation record, never silence

Beyond the shared envelope fields (kind, severity, namespace, kind_of_object, name, reason, message, fingerprint, exempt_reason, exempt_expires):

FieldMeaning
machine_typethe exhausted machine type (omitted when the log record does not name one)
eventsstockout events for this zone/machine-type pair in the window
first_seenearliest event in the window (RFC3339)
last_seenlatest event in the window (RFC3339)
reroutesame-region zones active in the window with no stockout for this machine type, comma-separated; omitted when the window offers no clean candidate
windowsummary-line note: the lookback the events cover
capabilitycloud.unavailable: the provider capability this command needed (stockout)
providercloud.unavailable: the provider that was asked
unavailablesummary-line note: why the cloud read could not be served

Output: one finding per line (logfmt; —format=json for one JSON object per line), keys in fixed order; healthy resources emit nothing. The final line is always the summary: scanned= findings= elapsed= — findings=0 with a summary present means “scanned and healthy”; a stream without a summary line is void. Exit 0 data, 1 runtime error (diagnostics on stderr only), 2 usage.

Terminal window
lookout cloud stockout
lookout cloud stockout --since=6h
lookout cloud stockout --format=json