kubectl
Getting at what a cluster is actually doing.
Verified against kubectl v1.34.1.
Commands
Everything, everywhere, with node placement:
kubectl get pods -A -o wideOnly the pods that are not behaving:
kubectl get pods -A --field-selector status.phase!=RunningLogs from the container that died, not the one running now:
kubectl logs POD --previous --tail=200
kubectl logs -f POD --all-containers --since=10mEvents for one object, which is where scheduling and image pull failures live:
kubectl events --for pod/POD --watchA shell in a distroless image that has no shell, by attaching a second container to the running pod:
kubectl debug -it POD --image=busybox --target=CONTAINERReach a service without an ingress:
kubectl port-forward svc/NAME 8080:80Roll a deployment without changing the manifest:
kubectl rollout restart deployment/NAME
kubectl rollout status deployment/NAME --timeout=2mWhat is actually consuming the node:
kubectl top pod -A --containers --sort-by=memoryThe field names a resource really has, which beats guessing from a blog post:
kubectl explain deployment.spec.strategy --recursiveEvery kind the cluster knows, including the ones a controller installed:
kubectl api-resources --verbs=list --namespaced -o nameNotes
--field-selector runs server side and only supports a few fields, mostly
metadata.name, metadata.namespace and status.phase. Anything richer needs
-o json and jq.
kubectl events is the newer command. The older kubectl get events --sort-by=.lastTimestamp still works, but events are namespaced and default to
the current namespace, which is why an event you expect often appears missing.
kubectl debug needs the target container name, not the pod name, for
--target. Without it the new container gets its own process namespace and you
cannot see the failing process.
Deleting with --force --grace-period=0 removes the object from the API and
leaves the container running on the node. It is for a stuck finalizer, not for
impatience.