Introduction

Yes, you can get logs from a Kubernetes pod, but the right command depends on where the application writes them. If the container logs to standard output, use kubectl logs; if it writes to a file inside the container, inspect that file with kubectl exec or copy it out with kubectl cp.

Start With kubectl logs

The preferred Kubernetes logging model is that applications write to standard output and standard error. The container runtime captures those streams, and Kubernetes exposes them directly.

Useful commands:

1kubectl logs my-pod
2kubectl logs my-pod -c api
3kubectl logs my-pod --since=10m
4kubectl logs -f deployment/api

Use -c when the pod has more than one container. Use -f to follow the stream in real time.

If the current container already restarted and you need the previous crash output, ask for the earlier logs:

kubectl logs my-pod --previous

That flag is easy to miss and very helpful during crash-loop debugging.

Reading a Log File Inside the Pod

Some applications still write to files such as /var/log/app.log or /app/logs/server.log. In that case, you need to inspect the container filesystem.

Open a shell if the image has one:

kubectl exec -it my-pod -- sh
ls /var/log
ls /app/logs

Or run the commands directly:

kubectl exec my-pod -- ls /app/logs
kubectl exec my-pod -- tail -n 100 /app/logs/server.log

This is often enough when you only need a quick look at the latest lines.

Copying the File Out of the Pod

If you want to inspect the log locally, archive it, or attach it to a bug report, copy it from the pod.

kubectl cp default/my-pod:/app/logs/server.log ./server.log

After that, you can use ordinary local tools:

tail -n 50 ./server.log
grep ERROR ./server.log

This is useful when the file is large or when the pod may disappear before you finish debugging.

Which Approach Is Best?

For production systems, the best operational pattern is usually:

• write application logs to standard output
• collect them with a central logging system
• avoid depending on pod-local files for important diagnostics

Why? Because pods are disposable. If logs only exist in the container filesystem, they can disappear during restarts, rescheduling, or rollouts.

When file-based logs are unavoidable, place them on a mounted volume and make sure your logging pipeline knows how to collect them.

Multi-Container Pods and the Wrong Target Problem

A frequent source of confusion is looking at the wrong container or even the wrong pod.

Start by locating the exact workload instance:

kubectl get pods -l app=api
kubectl describe pod my-pod

If the pod includes sidecars such as proxies or log shippers, make sure you use the correct container name with -c for both kubectl logs and kubectl exec.

Common Pitfalls

The biggest mistake is assuming every application writes to a log file. In Kubernetes, many well-behaved containers write only to standard output, so kubectl logs is the right first step.

Another issue is forgetting -c in a multi-container pod and reading logs from the wrong container.

People also often expect every image to contain /bin/sh. Minimal images may not, so direct command execution is sometimes necessary.

Finally, storing critical logs only inside the pod filesystem is fragile. Kubernetes is designed around replaceable containers, not durable in-container log files.

Summary

• Use kubectl logs first when the application writes to standard output or standard error.
• Use kubectl exec to inspect in-container log files and kubectl cp to copy them locally.
• Add --previous when you need logs from a crashed earlier container.
• Be careful to target the correct pod and container in multi-container setups.
• For production systems, centralized logging is more reliable than pod-local files.