kubectl logs: Usage, Options & Common CI Errors
Read the container output that explains the failure.
kubectl logs prints (or follows) a container's stdout/stderr. The --previous flag, which shows the log of the last crashed instance, is the single most useful option for debugging CrashLoopBackOff in CI.
What it does
kubectl logs POD streams the current container's output. For multi-container pods use -c to pick one, or --all-containers. --previous (-p) reads the prior, crashed instance's log - essential when a container restarts before you can attach. --since, --tail, and --timestamps bound and annotate the output.
Common usage
kubectl logs my-pod -f # follow live
kubectl logs my-pod -c sidecar # a specific container
kubectl logs my-pod --previous # the last crashed instance
kubectl logs -l app=web --tail=100 --timestamps
kubectl logs deploy/web --since=10mCommon errors in CI
"previous terminated container ... not found" means the container has not restarted (so there is no previous log) or the node already rotated it away - read the current log instead. "a container name must be specified for pod X" appears on multi-container pods; pass -c or --all-containers. In CI, also watch for empty output when you log a Deployment that has rolled to a new ReplicaSet: kubectl logs deploy/web targets the newest pod, so a just-replaced crashing pod may need an explicit pod name plus --previous.
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