Kubectl Demystified: Mastering the `kubectl logs` Command

Kubernetes has become the de facto standard for container orchestration, and kubectl is the primary command-line tool for interacting with Kubernetes clusters. One of the most essential kubectl commands for debugging and monitoring is kubectl logs, which allows you to retrieve logs from containers running in pods. In my previous article, I explained most things about the kubectl get command. This article will explain what kubectl logs is, how to use it, when to use it, and provide practical examples to prepare you for real-world scenarios and the Certified Kubernetes Administrator (CKA) exam.

What is kubectl logs?

The kubectl logs command fetches logs generated by containers running inside Kubernetes pods. Containers in pods write their output (e.g., application logs, errors, or system messages) to stdout and stderr, which Kubernetes captures and stores. This command lets you access those logs directly from your terminal without logging into the node where the pod is running.

What Does kubectl logs Do?

1. Retrieves Logs: Fetches logs from a specific container in a pod.  
2. Real-Time Log Streaming: Streams logs in real-time (similar to tail -f).  
3. Handles Restarted Containers: Displays logs from previous container instances if a pod has restarted.  
4. Multi-Container Support: Works with pods that have multiple containers.  
5. Filtering Options: Allows filtering logs by time, limiting output, or formatting as JSON.

When to Use kubectl logs

Common use cases include:  

• Debugging application errors or crashes.  
• Monitoring application behavior in real-time.  
• Inspecting logs after a pod restart to identify crashes.  
• Auditing or compliance checks.  
• Troubleshooting failing init containers.  

Examples with Explanations

1. Basic Log RetrievalFetch logs from a pod named nginx-pod:

  

kubectl logs nginx-pod

Explanation: This returns all logs written to stdout/stderr by the default container in the pod.  

2. Specify a Container in a Multi-Container PodIf a pod has multiple containers, use -c to specify the container name:

  

kubectl logs nginx-pod -c nginx-container

Explanation: Pods with multiple containers (e.g., a sidecar) require the -c flag to select the correct container.  

3. Real-Time Log StreamingStream logs live using the -f (follow) flag:

  

kubectl logs nginx-pod -f

Explanation: This continuously prints new logs to your terminal, ideal for monitoring live issues.  

4. View Logs from a Previous Container InstanceIf a container crashed and restarted, view its pre-crash logs with --previous:

  

kubectl logs nginx-pod --previous

Explanation: Critical for debugging crashes, as Kubernetes deletes logs from terminated containers by default.  

5. Show TimestampsInclude timestamps with --timestamps:

  

kubectl logs nginx-pod --timestamps

Output:

  
2024-01-01T00:00:00Z Starting nginx..
.

Explanation: Helps correlate logs with events in other systems (e.g., monitoring tools).  

6. Limit Log OutputShow only the last 100 lines with --tail:

  

kubectl logs nginx-pod --tail=100

Explanation: Reduces noise when investigating recent issues.  

7. Filter Logs by TimeView logs from the last 2 hours with --since:

  

kubectl logs nginx-pod --since=2h

Use relative time (e.g., 5m, 1h) or a timestamp (--since-time="2024-01-01T00:00:00Z").  

8. Filter Logs with grepCombine with grep to search for errors:

 

kubectl logs nginx-pod | grep -i "error"

Explanation: Useful for isolating specific patterns (e.g., "404", "timeout").  

9. Output Logs in JSON FormatFormat logs as JSON with --output json:

 

kubectl logs nginx-pod --output json

Explanation: Facilitates parsing logs programmatically or with tools like jq.  

10. Use Label SelectorsFetch logs from pods matching a label (e.g., app=nginx):

  

kubectl logs -l app=nginx

Explanation: Avoids typing pod names, especially useful for pods managed by deployments (which have dynamic names).  

Common Mistakes to Avoid

1. Not Specifying the Container: Fails in multi-container pods. Always use -c if the pod has >1 container.  
2. Ignoring --previous: Misses crash logs if you don’t include --previous for restarted pods.  
3. Assuming Log Persistence: Kubernetes only stores logs for running pods. Use a logging solution (e.g., Elasticsearch) for long-term retention.  
4. Overlooking Init Containers: Use kubectl logs pod-name -c init-container-name to debug init failures.  

CKA Exam Tips

1. Use Short Flags: Save time with -f instead of --follow, -c instead of --container.  
2. Label Selectors: When asked to debug a deployment, use -l app=deploy-name to target pods quickly.  
3. Practice Multi-Container Logs: Exam scenarios often include sidecar containers (e.g., logging agents).  
4. Know --since: Filtering logs by time is a common task.  

Conclusion

The kubectl logs command is indispensable for debugging and monitoring Kubernetes workloads. Whether you’re troubleshooting a crashing application, auditing behavior, or preparing for the CKA exam, mastering its flags and use cases will streamline your workflow. For comprehensive debugging, remember to combine it with other commands (e.g., kubectl describe pod or kubectl get events). Happy logging!