# kubectl get: Command Reference for CI/CD

> Reference for kubectl get: list resources, output formats, label and field selectors, jsonpath extraction, and a CI example that asserts on counts.

Source: https://latchkey.dev/learn/command-reference/kubectl-get-command-cli-reference  
Updated: 2026-06-26

List and inspect any resource type, in any output format.

kubectl get is the primary read command and the first thing a pipeline runs when a deploy looks wrong. This reference covers output formats and selectors, plus a CI pattern that asserts on a count instead of trusting an empty success.

## Common flags and usage

- -A, --all-namespaces: list across every namespace
- -o wide|yaml|json|name: choose the output format
- -o jsonpath='{...}': extract a specific field for scripting
- -l, --selector: filter by label (app=web)
- --field-selector: filter by field (status.phase=Running)
- --no-headers: omit the header row for clean parsing

## Example

```shell
# Fail the job if no ready pods match the app label
READY=$(kubectl get pods -n prod -l app=web \
  --field-selector=status.phase=Running --no-headers | wc -l)
[ "$READY" -gt 0 ] || { echo "no running pods"; exit 1; }

kubectl get deploy web -o jsonpath='{.status.readyReplicas}'
```

## In CI

get exits 0 even when it finds nothing, so a script that greps its output can silently pass. Pin the namespace with -n and assert on a count or a jsonpath value, or prefer kubectl wait to gate on an actual condition.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectl get: Command Reference for CI/CD?

kubectl get is the primary read command and the first thing a pipeline runs when a deploy looks wrong. This reference covers output formats and selectors, plus a CI pattern that asserts on a count instead of trusting an empty success.

### In CI?

get exits 0 even when it finds nothing, so a script that greps its output can silently pass. Pin the namespace with -n and assert on a count or a jsonpath value, or prefer kubectl wait to gate on an actual condition.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt