How do you follow pod logs in real time with kubectl?
kubectl logs -f [pod] — Follow logs
kubectl logs -f [pod] streams the pod's log output until you interrupt it with Ctrl + C. Without -f the command prints the current log and exits; add -n [namespace] when the pod is not in the default namespace.
-f streams new lines as they arrive, like tail -f. Add --tail=100 to skip the scrollback and start from the last hundred lines, and --timestamps when you need to correlate against events elsewhere. If the pod restarted, the interesting lines are usually in the previous container: --previous shows them.
For pods with more than one container, kubectl asks you to pick with -c container-name. Following a whole deployment rather than one pod works too: kubectl logs -f deployment/name aggregates its pods' output.
Related Kubernetes (kubectl) shortcuts: View Resources
| Shortcut | Action | Notes |
|---|---|---|
| kubectl get pods | List pods | List pods in current namespace. |
| kubectl get svc | List services | List services. |
| kubectl get nodes | List nodes | List cluster nodes. |
| kubectl get all | All resources | List all resources. |
| kubectl describe pod [name] | Pod details | Show detailed pod information. |
| kubectl logs [pod] | View logs | View pod logs. |
| kubectl logs -f [pod] | Follow logs | Follow pod logs in real time. |
From the Kubernetes (kubectl) reference (17 entries) · all how-to answers
Choosing the container and the past
A pod with several containers needs -c container-name, otherwise kubectl picks the first and warns. --since=10m or --tail=200 keeps the initial dump short before following starts, and --timestamps prefixes each line with the time the container wrote it, which matters when correlating with another pod. --previous shows the log of the last crashed instance of the container — the single most useful flag when a pod is in CrashLoopBackOff, because the current instance has not lived long enough to log anything.
Following many pods
Following one pod at a time does not scale to a Deployment with replicas; kubectl logs -f -l app=myapp --all-containers follows every pod matching a label selector, interleaved with a prefix per pod. The community tool stern does the same with colour and regex selection and is worth installing on any workstation that touches Kubernetes daily.
When logs are empty
An empty log with a running pod usually means the application writes to a file rather than stdout — the container convention is stdout and stderr, and a sidecar or a change to the app's logging config is the fix. If kubectl reports the pod has no logs at all, check kubectl describe pod; a container that never started has events but no log.