kubectl get -o wide: Usage, Options & Common CI Errors
Add the node, pod IP, and extra columns to the default table.
kubectl get -o wide keeps the familiar table layout but adds the columns the default view omits - the node a pod landed on, its IP, and the container images. It is the quick way to see scheduling and placement at a glance.
What it does
kubectl get pods -o wide appends NODE, NOMINATED NODE, READINESS GATES, IP, and (for pods) the underlying images to the table. For nodes it adds internal/external IP, OS image, kernel, and container runtime. It is purely a richer human view - the data is the same objects.
Common usage
kubectl get pods -o wide
kubectl get pods -A -o wide # placement across all namespaces
kubectl get nodes -o wide # OS, kernel, runtime versions
kubectl get pods -o wide -l app=web | sort -k7 # group by node columnCommon errors in CI
The mistake is scripting against -o wide columns: the column set and order are not a stable contract and can shift between kubectl versions, so an awk '{print $7}' that reads the NODE column silently breaks on upgrade. For scripts use -o jsonpath or -o custom-columns, which name the fields explicitly. -o wide also does not add columns for custom resources that lack additionalPrinterColumns, so a CRD may look identical to the plain table. Use it to eyeball placement (all pods on one node = an anti-affinity or topology-spread gap), then switch to jsonpath for assertions.
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