Kubectl logs is the Kubernetes command used to view logs from a pod, container, or workload resource. You can use it to inspect current logs, stream logs in real time, view logs from a previously crashed container, filter logs by time, and troubleshoot application behavior inside Kubernetes.
What Are kubectl Logs?
Kubernetes is an open-source container orchestration platform that helps automate the deployment, scaling, and management of containerized applications. kubectl is a command-line tool used to interact with a Kubernetes cluster. It allows users to deploy and manage applications, view and troubleshoot clusters, and more.
kubectl logs is a command that allows users to view the logs generated by a particular pod in a Kubernetes cluster. This can be useful for debugging and troubleshooting issues with applications running in the cluster.
| Use case | Command | When to use it |
|---|---|---|
| View pod logs | kubectl logs <pod-name> | Check current container output |
| Follow logs live | kubectl logs -f <pod-name> | Watch logs during debugging |
| View previous crashed container logs | kubectl logs --previous <pod-name> | Debug CrashLoopBackOff |
| View a specific container | kubectl logs <pod-name> -c <container-name> | Multi-container pods |
| View all containers | kubectl logs <pod-name> --all-containers=true | Sidecars/init/debug containers |
| View logs by label | kubectl logs -l app=<label> | Multiple pods for the same app |
| View deployment logs | kubectl logs deployment/<deployment-name> | Workload-level logs |
| Show last N lines | kubectl logs --tail=100 <pod-name> | Avoid dumping huge logs |
| Show recent logs | kubectl logs --since=1h <pod-name> | Time-bounded debugging |
| Show logs since exact time | kubectl logs <pod-name> --since-time=<RFC3339-time> | Incident-window analysis |
| Add timestamps | kubectl logs --timestamps <pod-name> | Correlate logs with events |
| Prefix source pod/container | kubectl logs <pod-name> --prefix | Multi-pod or multi-container readability |
Working with the kubectl log Command
The kubectl logs command is a command used to view the logs generated by a particular pod in a Kubernetes cluster. It allows users to view the logs generated by a particular pod in real-time, or to view the logs of a pod that has already terminated. This command can be useful for debugging and troubleshooting issues with applications running in the cluster.
To use the kubectl logs command, you must specify the name of the pod whose logs you want to view, as well as the container within the pod from which you want to view the logs. You can also specify options such as the number of lines of log output to display, or the time range of log entries to display.
The kubectl logs command supports several options for streaming logs, checking previous container instances, narrowing logs by time, selecting containers, and working with multiple pods. The most useful options are listed below.
| Option | What it does | Example |
|---|---|---|
-f, --follow | Streams logs in real time instead of returning a static snapshot. | kubectl logs -f nginx |
-p, --previous | Shows logs from the previous terminated container instance, useful for crashed or restarted pods. | kubectl logs nginx --previous |
-c, --container | Prints logs from a specific container in a multi-container pod. | kubectl logs nginx -c app |
--all-containers=true | Prints logs from all containers in the selected pod or pods. | kubectl logs nginx --all-containers=true |
--all-pods=true | Gets logs from all pods for a selected resource, such as a deployment. | kubectl logs deployment/nginx --all-pods=true |
--since | Returns logs newer than a relative duration, such as 5s, 2m, or 3h. | kubectl logs nginx --since=1h |
--since-time | Returns logs after a specific RFC3339 timestamp. Only one of --since or --since-time can be used. | kubectl logs nginx --since-time=2024-08-30T06:00:00Z |
--tail | Shows only the most recent number of log lines. | kubectl logs nginx --tail=100 |
--timestamps | Adds timestamps to each log line. | kubectl logs nginx --timestamps=true |
-l, --selector | Gets logs from pods matching a label selector. | kubectl logs -l app=nginx |
--prefix | Prefixes each log line with the source pod and container name. Useful when viewing logs from multiple pods or containers. | kubectl logs nginx --prefix |
--limit-bytes | Limits the number of bytes returned. Useful when logs are very large. | kubectl logs nginx --limit-bytes=500 |
--max-log-requests | Limits concurrent log requests when using a selector. | kubectl logs -l app=nginx --max-log-requests=10 |
--pod-running-timeout | Sets how long kubectl waits for at least one pod to start running. | kubectl logs nginx --pod-running-timeout=20s |
--ignore-errors=true | Keeps streaming logs even if non-fatal errors occur while following logs. | kubectl logs nginx -f --ignore-errors=true |
Tips from the expert
Itiel Shwartz
Co-Founder & CTO
In my experience, here are tips that can help you effectively use the kubectl logs command:
Use Log Aggregation Tools
Implement log aggregation tools like Fluentd, Logstash, or Fluent Bit to collect and centralize logs from multiple pods and nodes. This makes it easier to search, analyze, and visualize logs across your Kubernetes cluster.
Implement Structured Logging
Use structured logging formats like JSON to include key-value pairs in your logs. This improves log readability and makes it easier to query and analyze log data programmatically.
Enable Persistent Log Storage
Set up persistent log storage solutions like Elasticsearch, Amazon S3, or Google Cloud Storage to retain logs for longer periods. This is essential for compliance, auditing, and historical analysis.
Leverage kubectl Log Streaming
Use the kubectl logs -f option to stream logs in real-time. This is particularly useful for monitoring live application behavior and troubleshooting issues as they occur.
Filter Logs by Time
Use –since to return logs from a relative time window, such as the last 30 minutes or the last hour. Use –since-time when you need logs after a specific timestamp in RFC3339 format.
kubectl logs nginx --since=1h kubectl logs nginx --since-time=2024-08-30T06:00:00Z --timestamps=true
Only one of –since or –since-time can be used in the same command.
Combine kubectl logs with Grep
Pipe kubectl logs output to grep or other text processing tools to search for specific patterns or keywords. This enhances log analysis and makes it easier to pinpoint relevant log entries.
For quick local debugging, piping kubectl logs into grep can help you find specific errors. For production troubleshooting, teams usually need more than a text search. They need to correlate logs with Kubernetes events, deployment history, configuration changes, and workload health.
This is where platforms like Komodor can help teams move from searching logs to understanding root cause.
Understanding kubectl Logs
Logging helps you track events in your application, which can be very useful for debugging purposes and understanding why your application is behaving the way it is. These logs can be checked when the application crashes or behaves differently than expected.
Pod Logs
Pod logs are the logs generated by the containers running within a pod in a Kubernetes cluster. These logs can include information such as application output, error messages, and other diagnostic information.
You can view the pod logs of a particular pod using kubectl logs command, specifying the name of the pod and the container within the pod from which you want to view the logs.
Owner Object Logs
An owner object is a Kubernetes resource that has a pod or set of pods as its child resources. Examples of owner objects include Deployments, ReplicaSets, and StatefulSets. The kubectl logs command can be used to view the logs generated by the pods associated with a particular owner object.
To view these logs, you can use the kubectl logs command and specify the name of the owner object as well as the container within the pods that you want to view the logs for.
View Logs from Pods, Deployments, Jobs, and Label Selectors
A node in a Kubernetes cluster is a physical or virtual machine that runs one or more pods. The kubectl logs command can be used to view the logs generated by the pods running on a particular node in the cluster.
To view these logs, you can use the kubectl logs command and specify the name of the node as well as the container within the pods that you want to view the logs for. You can also use the --tail option to view the most recent log entries in real-time as they are generated.
kubectl logs
kubectl logs deployment/
kubectl logs job/
kubectl logs -l app=nginx --all-containers=true
Kubectl Logging Challenges and Solutions
There are several limitations to kubectl logging:
- Limited log retention: By default, kubectl logs only retain the logs generated by a pod for the lifetime of the pod. Once the pod is terminated, the logs are no longer available. This can make it difficult to retain logs over a longer period of time for analysis or compliance purposes.
- Limited log searching and analysis: kubectl logs do not provide any built-in search or analysis capabilities. Users must manually search through the logs or use external tools to analyze the logs.
- Limited log centralization: kubectl logs allow users to view the logs generated by a particular pod or node, but does not provide a way to centralize logs from multiple pods or nodes in a single location. This can make it difficult to get a comprehensive view of the logs generated by an entire application or cluster.
- Limited log security: kubectl logs does not provide any built-in security features, such as encryption or access controls. This can be a concern for sensitive log data or for environments where compliance requirements mandate certain security measures for log data.
There are several tools that can help address the limitations of kubectl logging:
- Logging aggregators: Logging aggregators, such as Fluentd or Logstash, can be used to collect and centralize logs from multiple pods and nodes in a single location. This makes it easier to get a comprehensive view of the logs generated by an entire application or cluster.
- Log management platforms: Log management platforms, such as Splunk or Logz.io, provide advanced log searching, analysis, and visualization capabilities, as well as the ability to retain logs over a longer period of time.
- Cloud-native logging solutions: Cloud providers often offer their own logging solutions specifically designed for use with Kubernetes. For example, Google Cloud offers Stackdriver, which provides log management and analysis capabilities for applications running on Google Kubernetes Engine.
- External log storage: External log storage solutions, such as Amazon S3 or Google Cloud Storage, can be used to store and retain logs over a longer period of time. These solutions may also provide additional security features, such as encryption and access controls.
These tools help centralize and retain logs, but log storage alone does not always solve Kubernetes troubleshooting. During production incidents, teams usually need to connect logs with events, deployments, configuration changes, metrics, and workload health. That broader context is where Kubernetes troubleshooting platforms and AI SRE workflows become useful.
Where Komodor Fits in Kubernetes Log Troubleshooting
kubectl logs is useful when you already know which pod, container, or workload to inspect. But during a real Kubernetes incident, logs are only one piece of the puzzle. Teams also need to understand recent deployments, configuration changes, events, health signals, resource behavior, dependencies, and ownership context.
That is where Komodor helps.
Komodor is an autonomous AI SRE platform for Kubernetes, powered by Klaudia, built to help teams visualize, troubleshoot, and optimize cloud-native infrastructure at scale. Instead of manually jumping between kubectl logs, kubectl describe, events, dashboards, and deployment history, Komodor correlates Kubernetes signals in one place so teams can move from log inspection to root cause analysis faster.
With Komodor, teams can:
- Detect Kubernetes issues before they turn into wider incidents
- Correlate logs with events, configuration changes, metrics, and deployment history
- Understand what changed before a pod, deployment, or service started failing
- Use AI-assisted investigation to identify likely root causes
- Get remediation guidance instead of only raw log output
- Reduce the manual back-and-forth between developers, DevOps, and SRE teams
For example, kubectl logs --previous can show output from a crashed container, but it will not explain whether the crash was caused by a bad deployment, missing configuration, resource pressure, a failing dependency, or an infrastructure change. Komodor helps connect those signals so teams can troubleshoot Kubernetes issues with more context and less guesswork.
Use Komodor to investigate Kubernetes issues with full workload context, AI-assisted root cause analysis, and remediation guidance.
FAQs About Kubectl Logs
Kubectl logs is a Kubernetes command used to view the logs generated by containers running inside pods. It helps developers, DevOps engineers, and SRE teams inspect application output, troubleshoot errors, check container behavior, and investigate failed or restarted workloads.
Kubectl logs shows the output written by a container, usually from stdout and stderr. It is best for checking application behavior, errors, stack traces, and runtime messages.
Kubectl describe pod shows Kubernetes-level information about the pod, including status, events, containers, restart count, image details, scheduling issues, and probe failures. In practice, teams often use both commands together when troubleshooting Kubernetes issues.
Kubectl logs may show no output if the application has not written anything to stdout or stderr, the wrong container was selected, the pod has not started yet, or the logs were already rotated or removed. In multi-container pods, you may need to specify the container name with -c.
Kubernetes pod logs are usually stored on the node where the pod runs and are tied to the container lifecycle and node-level log rotation settings. This means kubectl logs is useful for recent troubleshooting, but it is not a long-term log retention solution.
For historical log analysis, compliance, search, or post-incident review, teams usually need a centralized logging or observability platform.
kubectl logs can show recent logs from the current container and, with --previous, logs from a previously terminated container instance. However, it is not designed for long-term historical log storage.
If pods are deleted, containers are rotated, or node logs are cleaned up, older logs may no longer be available through kubectl logs.
AI SRE tools help by connecting logs with the wider Kubernetes context, including events, deployments, configuration changes, metrics, workload health, and ownership data. Instead of manually jumping between kubectl logs, kubectl describe, dashboards, and deployment history, teams can use AI-assisted investigation to identify likely root causes faster.
Komodor, for example, helps Kubernetes teams move beyond raw log inspection by correlating workload behavior, recent changes, events, and reliability signals so teams can troubleshoot incidents with more context and less guesswork.
