History
The kubectl logs
command has been part of Kubernetes since its early releases. It was introduced to offer direct insight into what’s happening inside a container, especially for applications that don’t store logs externally or use centralized logging solutions. Over time, support for tailing logs, selecting containers in multi-container pods, and following logs in real time has made it more versatile.
Value Proposition
Understanding application behavior and troubleshooting failures in Kubernetes often starts with logs. kubectl logs
gives engineers a fast, native way to inspect container output without needing extra tools or logging infrastructure. It’s especially valuable during development, incident response, and early-stage deployments.
Key Features
- Single container logs: View logs from the main container in a pod. bashCopyEdit
kubectl logs <pod-name>
- Multi-container support: Specify a container when the pod has more than one. bashCopyEdit
kubectl logs <pod-name> -c <container-name>
- Real-time streaming: Follow logs as they’re written (like
tail -f
). bashCopyEditkubectl logs -f <pod-name>
- Previous container logs: Get logs from the previous container instance (after a crash or restart). bashCopyEdit
kubectl logs <pod-name> --previous
- Label selectors (indirect): Use them to get the pod name before logging. bashCopyEdit
kubectl get pods -l app=my-app kubectl logs my-app-pod
Best Practices
- Use
-f
when debugging real-time issues like crash loops or slow startup. - Avoid using
kubectl logs
in production for long-term observability. Instead, forward logs to a centralized solution like Fluent Bit, Fluentd, or Loki. - Always specify
-c
when dealing with multi-container pods, or the command will fail. - Use
--tail
to limit output and avoid overwhelming your terminal with large logs. bashCopyEditkubectl logs <pod-name> --tail=100
- Automate log inspection with scripts during CI/CD for post-deployment checks.
- Include timestamps if your logs don’t have them by default: bashCopyEdit
kubectl logs <pod-name> --timestamps
Challenges
- Logs disappear when pods terminate unless logging is forwarded elsewhere.
- Can’t use for pods that never started properly, unless using events (
kubectl describe pod
). - Not suited for historical log analysis or correlating logs across pods or services.
Similar Concepts
kubectl describe pod
– for event-level diagnostics- Logging agents – for persistent and centralized log storage
kubectl exec
– for inspecting runtime behavior beyond logs- Fluent Bit / Fluentd / Loki – log aggregation tools