kubectl logs

kubectl logs is a command in Kubernetes used to retrieve the logs from a container running in a pod. It helps developers and DevOps engineers debug applications by showing standard output (stdout) and standard error (stderr) streams.

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. kubectl logs <pod-name>
• Multi-container support: Specify a container when the pod has more than one. kubectl logs <pod-name> -c <container-name>
• Real-time streaming: Follow logs as they’re written (like tail -f). kubectl logs -f <pod-name>
• Previous container logs: Get logs from the previous container instance (after a crash or restart). kubectl logs <pod-name> --previous
• Label selectors (indirect): Use them to get the pod name before logging. 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. kubectl 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: 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