Introduction

Kubernetes does log ordinary application output, but only when the application writes to standard output or standard error in a way the container runtime can capture. If print() statements are not showing up in kubectl logs, the usual causes are buffering, writing to a file instead of stdout, looking at the wrong container, or running the application through a wrapper process that swallows output. The fix is usually in the container or application setup, not in Kubernetes itself.

What kubectl logs Actually Shows

kubectl logs reads the stdout and stderr streams of a container.

kubectl logs my-pod
kubectl logs my-pod -c app

That means simple print, printf, and console.log calls should appear if they reach those streams. Kubernetes does not automatically scrape arbitrary files inside the container.

If your application writes to /var/log/app.log, kubectl logs will not show that file unless another process forwards it to stdout.

Buffering Is a Common Cause

Many languages buffer output, especially when they do not detect an interactive terminal. Inside containers, that can make print output appear late or not at all before the process exits.

For Python, unbuffered mode is a common fix.

1import time
2
3for i in range(3):
4    print(f"tick {i}", flush=True)
5    time.sleep(1)

Or start Python with unbuffered output:

CMD ["python", "-u", "app.py"]

The same idea applies in other languages: make sure logs are flushed promptly.

Confirm You Are Looking at the Right Container

In multi-container Pods, kubectl logs my-pod may default to the first container, not the one you care about. Always check the container name.

kubectl get pod my-pod -o jsonpath='{.spec.containers[*].name}'
kubectl logs my-pod -c worker

This is a frequent source of confusion when a sidecar and the main app run together.

Prefer a Real Logging Stream Over Ad Hoc Prints

Short debugging prints are fine, but production containers should usually log through the process’s normal logging configuration to stdout or stderr.

A simple Python example:

1import logging
2
3logging.basicConfig(level=logging.INFO)
4logging.info("Application started")

This scales better than scattered print statements and is easier to structure, filter, and ship into a centralized logging system.

Wrapper Scripts Can Hide Output

If the container launches a shell script that starts the real application in the background and then exits or redirects output elsewhere, Kubernetes may never see the expected logs.

A safer pattern is to let the main application run as the container’s foreground process.

CMD ["python", "app.py"]

That keeps the log stream tied directly to the main container process.

Check Restarts and Previous Logs

If the container crashes quickly, the missing output may actually be in the previous container instance rather than the current one. In that case, inspect restart count and use the previous-log flag.

kubectl describe pod my-pod
kubectl logs my-pod --previous

This is especially useful when startup prints appear briefly and the process exits before you check the normal log stream.

Common Pitfalls

• Writing logs to a file inside the container and expecting kubectl logs to show them.
• Forgetting to flush buffered output.
• Looking at the wrong container in a multi-container Pod.
• Starting the app through a wrapper that redirects or detaches the real process.
• Treating print() as a long-term logging strategy instead of using the language’s logging facilities.

Summary

• Kubernetes captures container stdout and stderr, not arbitrary log files.
• If prints are missing, check buffering and flushing first.
• Use kubectl logs -c when the Pod has more than one container.
• Run the main application in the foreground so Kubernetes can capture its output.
• Prefer structured logging to stdout or stderr for production workloads.