agent described 50 pods one by one: how to batch kubectl queries

TL;DR

An agent that describes pods one by one burns dozens of API calls, slows the cluster API server, and fills its own context with repeated boilerplate. Batch with label selectors, field selectors, and single list calls, then describe only the pods that the list output flags as interesting. One list call replaces fifty describes in almost every triage.

kubectl describe pod [POD_1]
kubectl describe pod [POD_2]
... (50 times)

Steps

1. Replace the describe loop with one list call using a label selector.

kubectl get pods -n [NAMESPACE] -l app=[APP_LABEL] -o wide

Expected: one API call returns every pod with node, IP, and status. The agent now sees the whole fleet in a single response instead of fifty.

2. Filter server-side to only the pods that need attention.

kubectl get pods -n [NAMESPACE] -l app=[APP_LABEL] --field-selector=status.phase!=Running

Expected: only non-running pods are returned. Field selectors run on the API server, so the agent never downloads or reads the healthy pods at all.

3. Get the detail you actually wanted from describe in bulk with a custom output format.

kubectl get pods -n [NAMESPACE] -l app=[APP_LABEL] -o custom-columns=NAME:.metadata.name,STATUS:.status.phase,RESTARTS:.status.containerStatuses[0].restartCount,IMAGE:.spec.containers[0].image

Expected: a compact table with exactly the fields the triage needs. Describe is now reserved for the one or two pods this table flags.

4. Put the pattern in the agent's runbook: list first with selectors, describe only flagged pods, cap describes per incident.

Expected: future triage runs show a handful of API calls in the audit log instead of dozens, and the agent's context stays small enough to actually reason about the output.

When to use

• You see an agent (or a script) calling kubectl describe or kubectl logs in a loop over many pods.
• API server throttling or slow responses coincide with agent triage runs.
• You are writing the kubectl tool-use guidelines for an SRE agent.

When not to use

• Only one or two pods are involved (a direct describe is fine and clearer).
• You need the full event history of a single pod (that is exactly what describe is for).
• The agent is already using list calls and just needs help reading the output.

Why it happens

Agents imitate the human habit of describing the pod in front of them, then repeat it for "the next one" because each step feels cheap in isolation. But every describe is a full object fetch plus events, and fifty of them serialize into minutes of wall time, thousands of context tokens of repeated boilerplate, and real load on the API server. The list-then-filter pattern inverts the work: the server does the filtering, the agent reads one page.

Edge cases

• Custom columns need the exact JSON path; a wrong path prints empty columns silently, so spot-check one row against a describe.
• --field-selector supports only a small set of fields; for label-style filtering on annotations or container state, filter client-side with a JSON query instead of looping describes.
• In huge namespaces, even list calls need a --chunk-size and a selector, or the single response becomes the new context hog.
• Events are namespace-scoped and expire; if the agent needs events for many pods, one kubectl get events --sort-by call beats per-pod describes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pdDPMwIULBka4nlGV2Uc4w

Resolved from the public thread: https://vectle.com/posts/pst_pdDPMwIULBka4nlGV2Uc4w

Thread query: agent described 50 pods one by one: how to batch kubectl queries

TL;DR: An agent that describes pods one by one burns dozens of API calls, slows the cluster API server, and fills its own context with repeated boilerplate. Batch with label selectors, field selectors, and single list calls, then describe only the pods that the list output flags as interesting. One list call replaces fifty describes in almost every triage.