Skip to main content
In this lesson we cover how containerized applications emit logs, how container runtimes capture those logs, and how to view them in Kubernetes using standard tooling. You’ll learn the basic commands for local Docker workflows and the equivalent kubectl patterns for Kubernetes, plus how to handle multi-container Pods.
A presentation slide titled "Application Logs" with a dark blue curved panel on the right showing an icon of a rolled-up log or list and a clock. The left side is mostly white with the title text centered.
Docker: logging to stdout/stderr
  • Containerized applications should write logs to standard output (stdout) and standard error (stderr). Container runtimes capture these streams and expose them via CLI tools.
  • Example: run a sample container that prints simulated web-server events to stdout:
  • If you start the container in detached/background mode (-d), logs won’t appear on the terminal. Use docker logs to view or tail logs:
Kubernetes: kubectl logs
  • Kubernetes relies on the same best practice: write logs to stdout/stderr. The kubelet (via the container runtime) captures those streams and exposes them using kubectl logs.
  • To test the same image in Kubernetes, create a Pod and stream its logs.
Create the Pod:
Stream logs from the Pod:
Pod manifest example
  • A minimal Pod manifest that runs the event-simulator image:
Multi-container Pods
  • Pods can host multiple containers. When more than one container exists, kubectl logs needs the specific container name.
  • Use the -c / --container flag to indicate which container to fetch logs from:
  • If you omit the container name in a multi-container Pod, kubectl returns an error and asks you to specify which container’s logs you want.
Example multi-container Pod manifest:
Best practice: Applications running in containers should write logs to stdout/stderr. This makes them compatible with the container runtime and Kubernetes log collection tools.
Quick reference — common commands Wrap-up
  • For development and basic troubleshooting, docker logs and kubectl logs are often sufficient to inspect application output.
  • In production environments, teams typically deploy cluster-wide log collectors and aggregators (for example Fluentd / Fluent Bit forwarding to Elasticsearch + Kibana, or hosted SaaS log platforms) to collect, index, and retain logs centrally for search, alerting, and long-term analysis.
  • Next steps: explore structured logging in your application (JSON logs), sidecar log processors, and Fluentd/Fluent Bit integrations to ship logs to central storage.
Links and references Practice working with logs using the provided exercises to reinforce viewing, tailing, and targeting container logs in multi-container Pods.

Watch Video

Practice Lab