Analyzing Kubernetes Logs in Linux: A Complete Guide to kubectl logs

Introduction / Why This Matters

Logs in Kubernetes are the primary source of information about container and pod operations. They help diagnose errors, track application status, and understand what's happening inside the cluster. In this guide, you'll learn how to efficiently view, filter, and analyze logs using the standard kubectl tool on Linux. After completing this, you'll be able to quickly find the necessary information in logs and debug applications in Kubernetes.

Prerequisites / Preparation

Before you begin, ensure that:

• You have access to a Kubernetes cluster (kubeconfig file is configured).
• kubectl is installed (version compatible with your cluster). Verify with: kubectl version --client.
• You have permissions to view pods and logs in the required namespaces.
• You are familiar with basic kubectl commands (get, describe).

If kubectl is not installed, install it according to the official documentation for your Linux distribution.

💡 Tip: If you're just starting with Kubernetes, first master the basic commands kubectl get pods and kubectl describe pod to understand the cluster structure.

Basic Commands for Working with Logs

Viewing a Pod's Logs

The simplest way to get a pod's logs is with the command:

kubectl logs <pod_name>

For example:

kubectl logs nginx-7cdbd8cd56-abcde

This command outputs logs from the first container in the pod. If the pod has multiple containers, you must specify the container name.

Specifying a Container in a Multi-Container Pod

If a pod contains multiple containers, use the -c flag:

kubectl logs <pod_name> -c <container_name>

Example:

kubectl logs my-app-pod -c sidecar-container

Following Logs in Real Time

To see logs as they appear, add the -f (follow) flag:

kubectl logs -f <pod_name>

This is particularly useful for debugging starting applications or monitoring.

Getting Logs from the Previous Container Instance

If a container has restarted, you can retrieve logs from the previous instance using the --previous flag:

kubectl logs <pod_name> --previous

Filtering Logs by Time

To get logs from a specific period, use:

• --since — relative time (e.g., 5m, 1h).
• --since-time — absolute time in RFC3339 format (e.g., 2026-02-16T10:00:00Z).

Examples:

kubectl logs <pod_name> --since=5m
kubectl logs <pod_name> --since-time=2026-02-16T09:00:00Z

Limiting the Number of Lines

By default, kubectl logs outputs all available logs. To limit output to the last N lines, use --tail:

kubectl logs <pod_name> --tail=100

Working with Namespaces

If the pod is in a non-default namespace, specify it with the -n flag:

kubectl logs <pod_name> -n <namespace>

Exporting Logs to a File

To save logs to a file on your local machine, redirect the output:

kubectl logs <pod_name> > pod-logs.txt

For a multi-container pod:

kubectl logs <pod_name> -c <container> > container-logs.txt

Viewing Logs from Multiple Pods Simultaneously (Advanced Method)

Standard kubectl logs does not support viewing logs from multiple pods at once. For this, you can use third-party tools, such as:

• stern — logging by label selector.
• kubetail — a bash script for multi-pod viewing.

Install stern:

# For Linux (example for Ubuntu)
sudo wget https://github.com/wercker/stern/releases/download/1.24.0/stern_linux_amd64 -O /usr/local/bin/stern
sudo chmod +x /usr/local/bin/stern

Example stern usage:

stern . --namespace default

This command will output logs from all pods in the default namespace matching the selector (in this case, all).

Verification

After running the commands, you should see text logs in the terminal or in the saved file. Ensure that:

• The logs contain expected entries (e.g., application messages, errors).
• The log timestamps match the applied filters (if used).
• For multi-container pods, you are viewing logs from the correct container.

If logs are empty, check that the container actually writes to stdout/stderr. Some applications write logs to files inside the container; in that case, you need to use kubectl exec to access the file.

Potential Issues

⚠️ Important: Some issues may arise due to Kubernetes limitations (e.g., log storage volume) or RBAC settings. This section covers common cases.

"Error from server (NotFound): pods ... not found"

Ensure the pod name is correct and that it exists in the specified namespace. Check the pod list: kubectl get pods -n <namespace>.

Empty Logs

The container might not output logs to stdout/stderr. Check the application configuration. It's also possible the pod just started and logs haven't appeared yet. Wait a moment or check logs from the previous instance (--previous).

Access Error (Forbidden)

Your user may lack permissions to view logs. Check RBAC roles. You need get, list permissions on pods/log resources.

Logs Are Truncated or Incomplete

By default, Kubernetes stores a limited volume of logs (depends on kubelet configuration). If logs are too old, they may have been rotated and removed. Use external log collection (e.g., Elasticsearch, Fluentd) for long-term storage.

Slow Log Transfer When Using -f

With a large volume of logs or high network latency, streaming can be slow. In such cases, fetch the log as a file first and then analyze it locally.

Logs Not Loading After Pod Restart

If a pod restarts, logs from the previous instance are only available if the container retained them (--previous flag). However, if the pod was deleted and recreated (new UID), logs from the previous pod are unavailable. In this scenario, you need to set up centralized logging.