kubectl get: Usage, Options & Common CI Errors
List and inspect any resource type in one command.
kubectl get is the primary read command: it lists one or more resources and prints them as a table, YAML, JSON, or a custom layout. It is the first thing you run when a deploy looks wrong.
What it does
kubectl get RESOURCE [NAME] queries the API server and prints matching objects. With no name it lists all objects of that type in the current namespace; add -A (--all-namespaces) to span every namespace. -o controls output (wide, yaml, json, name, jsonpath, custom-columns), -w streams changes, and -l filters by label.
Common usage
kubectl get pods # pods in current namespace
kubectl get pods -A -o wide # all namespaces, node + IP columns
kubectl get deploy,svc -l app=web # multiple types, filtered by label
kubectl get pod my-pod -o yaml # full object as YAML
kubectl get pods -o jsonpath='{.items[*].metadata.name}'
kubectl get events --sort-by=.lastTimestampCommon errors in CI
In a pipeline you often see "No resources found in <namespace> namespace." - get exited 0 with an empty list because the objects are in a different namespace (you forgot -n) or have not been created yet. A script that greps that output silently passes. Pin the namespace and assert on the count: kubectl get pods -n prod --no-headers | wc -l, or use kubectl wait instead of polling get. "Error from server (NotFound)" means you named a specific object that does not exist; "the server doesn't have a resource type" means a CRD is not installed.
Options
| Flag | Effect |
|---|---|
| -A, --all-namespaces | List across every namespace |
| -o wide|yaml|json|name | Output format |
| -l, --selector | Filter by label (app=web) |
| -w, --watch | Stream changes as they happen |
| --field-selector | Filter by field (status.phase=Running) |
| --no-headers | Omit the header row (scripting) |
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.
# 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