Meet the Last9 team at AWS re:Invent 2024!Join us →

Aug 22nd, ‘24/9 min read

Using Kubectl Logs: Guide to Viewing Kubernetes Pod Logs

Learn how to effectively use kubectl logs to view and analyze Kubernetes pod logs. Master advanced techniques, troubleshoot issues, and optimize your K8s deployments.

Using Kubectl Logs: Guide to Viewing Kubernetes Pod Logs

Let's face it: Kubernetes is like a hyperactive toddler on a sugar rush - it's constantly moving, changing, and occasionally throwing tantrums that leave you wondering what the heck just happened. In this chaotic playground, kubectl logs is your trusty sidekick, helping you make sense of the madness.

Why should you care about kubectl logs? Well, unless you enjoy playing "guess the error" or "why is everything on fire?" here's the deal:

  1. Troubleshooting: When your app decides to have an existential crisis, logs are your therapist. They'll tell you what's wrong, even if it's just "I don't want to work today." (Pro tip: Start using Distributed Tracing too, because sometimes your logs are too painful to be useful.)
  2. Performance Sleuthing: Logs are like the gossip column of your app. They'll spill the beans on which parts are slacking off or hogging all the resources.
  3. Security Theater: Logs are the bouncers of your app club. They'll rat out any shady characters trying to sneak in where they shouldn't.
  4. Compliance Checkbox Ticking: Because nothing says "we're responsible adults" like having a bajillion log files that nobody ever reads, but auditors love.

The kubectl logs command is your VIP pass to this backstage drama. It lets you eavesdrop on your containers without the hassle of SSH-ing into them (because who has time for that?). It's like having x-ray vision for your pods, minus the radiation and fancy glasses.

Contents

  1. What is Kubectl
  2. Kubernetes Architecture & Logging Internals
  3. How Logging Works in Kubernetes
    1. Container Logs
    2. Node Level Logging
    3. Cluster Level
    4. Log Lifecycle
    5. Centralized Logging Solutions
  4. Kubectl Logs
    1. Tailing logs in real-time
    2. Viewing logs from previous instances
    3. Limiting output
    4. Viewing logs from multiple pods
    5. Including timestamps
    6. Time-based log retrieval
    7. View logs up to a specific time
    8. stdout vs stderr
  5. How does kubectl logs work?
  6. Log Management in Kubernetes
  7. Logging Cheat Sheet

What is kubectl?

Kubectl is the command-line interface for interacting with Kubernetes clusters. It allows developers and administrators to deploy applications, inspect and manage cluster resources, and view logs.

Kubernetes Architecture and Logging Internals Explained

Before diving into the specifics of kubectl logs, it's crucial to understand the basics of Kubernetes architecture and how logging fits into this ecosystem.

Kubernetes Architecture: Key Components and Their Roles

Kubernetes follows a distributed architecture with several key components:

  1. Master Node(s):
    • API Server: The central management entity that receives all REST requests.
    • etcd: A distributed key-value store that stores all cluster data.
    • Scheduler: Assigns pods to nodes.
    • Controller Manager: Manages various controllers that regulate the state of the cluster.
  2. Worker Nodes:
    • Kubelet: Ensures containers are running in a pod.
    • Container Runtime: Software responsible for running containers (e.g., Docker, containerd).
    • Kube-proxy: Maintains network rules on nodes.
  3. Pods: The smallest deployable units in Kubernetes, containing one or more containers.

How Logging Works in Kubernetes

Kubernetes doesn't provide a native, cluster-wide logging solution. Instead, it relies on the underlying container runtime to capture stdout and stderr streams from each container. Here's how logging works:

  1. Container Logs:
    • Applications inside containers write logs to stdout and stderr.
    • The container runtime captures these streams and writes them to files on the node's disk.
  2. Node-level Logging:
    • Kubelet on each node is responsible for exposing these logs to the Kubernetes API.
    • Log files are typically stored /var/log/pods/ on the node.
  3. Cluster-level Access:
    • The Kubernetes API server provides endpoints to access these logs.
    • kubectl logs command uses these endpoints to retrieve logs from specific pods or containers.
  4. Log Lifecycle:
    • Logs are tied to the lifecycle of the container. When a container is deleted, its logs are typically deleted as well.
    • Some container runtimes implement log rotation to manage disk space.
  5. Advanced Logging Solutions:
    • For production environments, cluster-wide logging solutions (like Levitate, ElasticSearch, and Kibana stack) are often implemented to aggregate logs from all nodes and provide advanced search and analysis capabilities.

Understanding this architecture is crucial for effective log management and troubleshooting in Kubernetes environments. With this context, let's explore how kubectl logs interface with this system to provide access to container logs.

Getting Started with kubectl logs

The simplest form of the command is:

kubectl logs <pod-name>

For multi-container pods, specify the container:

kubectl logs <pod-name> -c <container-name>

Expected output:

2023-08-24 10:15:30 INFO  Application started
2023-08-24 10:15:31 DEBUG Connecting to database
2023-08-24 10:15:32 INFO  Database connection established

Advanced Techniques

1. Label Selectors: Logging Across Multiple Pods

In the real world, you're often dealing with multiple pods that make up a single application. Label selectors let you grab logs from all of them at once.

kubectl logs -l app=my-app --all-containers=true

This command says, "Hey Kubernetes, give me logs from all containers in all pods labeled with 'app=my-app'." It's like casting a wide net to catch all your log fish.

Example:

kubectl logs -l app=user-service --all-containers=true

Output:

[pod: user-service-abcd1] 2023-09-21 11:00:01 INFO User login successful
[pod: user-service-efgh2] 2023-09-21 11:00:02 WARN Failed login attempt
[pod: user-service-ijkl3] 2023-09-21 11:00:03 DEBUG Processing user data

2. Combining kubectl logs with Other Commands

The real magic happens when you start piping kubectl logs output to other commands. Here are some power-user moves:

Grep for specific patterns:

kubectl logs my-pod | grep ERROR

This will show only the lines containing "ERROR". It's like having a search party for your log disasters.

Count occurrences:

kubectl logs my-pod | grep -c "User logged in"

This tells you how many times "User logged in" appears. Great for quick analytics!

Tail and follow in real-time:

kubectl logs -f my-pod | grep --line-buffered ERROR

This streams logs in real-time, but only shows lines with "ERROR". It's like having a live error radar.

3. Parsing JSON Logs with jq

If your application spits out JSON logs (and let's face it, in 2023, whose doesn't?), jq is your new best friend.

kubectl logs my-json-logging-pod | jq .

This prettifies your JSON logs. But wait, there's more!

kubectl logs my-json-logging-pod | jq 'select(.level == "error")'

This filters and shows only the error-level logs. It's like having a bouncer for your log messages.

4. Time-based Log Retrieval

Need logs from a specific time range? Kubernetes has you covered:

kubectl logs --since-time=2023-09-20T10:00:00Z --until-time=2023-09-20T11:00:00Z my-pod

This grabs logs between 10 AM and 11 AM on September 20, 2023. It's like a time machine for your logs!

5. Logging from Previous Container Instances

Sometimes, you need to see logs from a container that's already gone to the great data center in the sky:

kubectl logs my-pod --previous

This shows logs from the previously terminated instance of the container. It's like container necromancy!

6. Logging from Init Containers

Init containers can be tricky beasts. Here's how to peek into their logs:

kubectl logs my-pod -c my-init-container --previous

This command says, "Show me what that init container was up to before it finished." Useful for debugging those pesky startup issues.

7. Exporting Logs to a File

Need to save logs for posterity (or to appease the audit gods)?

kubectl logs my-pod > my-pod-logs.txt

This saves the log output to a file. You can then analyze it offline or email it to that one developer who swears their code is perfect.

8. Verbose Logging

Sometimes, you need ALL the details:

kubectl logs my-pod --v=9

This increases the verbosity to the max. Warning: May cause information overload!

9. Timestamp Prefixing

Want to know exactly when each log line was generated?

kubectl logs my-pod --timestamps=true

This prefixes each log line with a timestamp. Great for correlating events across your cluster.

10. Logging from Crashed Containers

If a container has crashed, you can still retrieve its logs:

kubectl logs --previous --tail=100 my-crashed-pod -c my-container

This grabs the last 100 lines from the previous (crashed) instance of the container. It's like performing a post-mortem on your container.

Remember, with great logging power comes great responsibility. Use these techniques wisely, and may your logs always be informative and your errors few!

Understanding stdout vs stderr

Kubernetes captures both stdout and stderr streams. To see only stderr logs:

kubectl logs <pod-name> --container <container-name> --stderr

Where Does kubectl logs Retrieve Logs From?

Understanding where kubectl logs retrieve their information is crucial for effective log management and troubleshooting in Kubernetes. Let's dive deeper into this process:

Container Runtime Log Files

  1. Local Node Storage: When you run kubectl logs, it reads log files directly from the local storage of the node where the pod is running. These log files are typically stored in a directory on the node's filesystem.
  2. Container Runtime: The exact location and format of these log files depending on the container runtime being used (e.g., Docker, containerd, CRI-O). For example:
    • Docker: /var/lib/docker/containers/<container-id>/<container-id>-json.log
    • containerd: /var/log/pods/<pod-uid>/<container-name>/0.log
    • CRI-O: /var/log/pods/<pod-namespace>_<pod-name>_<pod-uid>/<container-name>/0.log
  3. Log Rotation: The container runtime usually handles log rotation to prevent log files from consuming too much disk space. The rotation policy can affect how far back you can retrieve logs using kubectl logs.

Kubernetes API Server

  1. API Request: When you run kubectl logs, it sends a request to the Kubernetes API server.
  2. Kubelet Communication: The API server then communicates with the kubelet on the specific node where the pod is running.
  3. Kubelet Retrieval: The kubelet accesses the container runtime to fetch the requested logs.
  4. Stream Back: The logs are then streamed back through the API server to your kubectl client.

stdout and stderr Streams

  1. Standard Streams: Kubernetes captures logs that are written to the stdout (standard output) and stderr (standard error) streams of the container processes.
  2. Application Logging: This means that your application needs to write its logs to stdout/stderr for them to be accessible via kubectl logs. Logging to files inside the container won't be captured unless you've set up a logging sidecar.

Logging Drivers

  1. Container Runtime Logging: The container runtime uses logging drivers to capture the stdout/stderr streams and write them to files.
  2. Driver Configuration: The logging driver can be configured to affect how logs are stored and rotated. For example, Docker's JSON file driver stores logs in JSON format with metadata.

Important Considerations for Log Management in Kubernetes

  1. Log Persistence: Logs are only available for the lifetime of the pod's containers. Once a container is terminated and removed, its logs are no longer accessible through kubectl logs.
  2. Previous Containers: The --previous flag allows you to access logs from a previous instance of a container, but only if the pod is still present on the node.
  3. Node Failures: If a node fails, logs stored locally on that node become inaccessible. This is one reason why centralized logging solutions are often used in production environments.
  4. Performance Impact: Excessive logging or frequent log queries can impact the performance of the node and the Kubernetes API server.
  5. Security: Access to logs is controlled by Kubernetes RBAC (Role-Based Access Control). Users need appropriate permissions to view logs from pods.

Additional Topics to Explore

  • Kubernetes Pods: Understanding pod concepts for effective log management.
  • Log Rotation: Learn about Kubernetes log rotation policies.
  • Exposing Logs: Methods to expose logs for external monitoring systems.
  • Open Telemetry Logs: Using Open Telemetry send your logs to a central system like Levitate

Quick Reference (Cheat Sheet)

# Basic log viewing
kubectl logs <pod-name>

# View logs from a specific container
kubectl logs <pod-name> -c <container-name>

# Tail logs in real-time
kubectl logs <pod-name> -f

# View previous instance logs
kubectl logs <pod-name> --previous

# Limit log output
kubectl logs <pod-name> --tail=100

# View logs from multiple pods
kubectl logs -l app=myapp

# Include timestamps
kubectl logs <pod-name> --timestamps

# View logs since a specific time
kubectl logs <pod-name> --since=1h

# View logs until a specific time
kubectl logs <pod-name> --until=2023-08-24T10:00:00Z

# View only stderr logs
kubectl logs <pod-name> --container <container-name> --stderr

Enhance Your Kubernetes Logging with Levitate Logs

While kubectl logs are powerful, managing logs at scale can be challenging. Levitate Logs offers a robust solution for centralized log management in Kubernetes environments.

Key features include:

  1. Aggregation: Collect logs from all pods and containers.
  2. Search and Filtering: Advanced options for log analysis.
  3. Real-time Streaming/ Live Tail: View logs in real-time across your cluster. Just like your local tail -f you can use tail your logs through levitate directly in the browser.
  4. Retention: Store logs for extended periods.
  5. Alerts: Set up alerts based on log patterns including Scheduled Search.
  6. Visualization: Create dashboards for log data trends through Grafana.
  7. Integration: Seamless integration with Kubernetes infrastructure through helm charts and open telemetry support.

Levitate Logs addresses many limitations of kubectl logs, especially in complex, distributed systems.

💡
Golang Logging Guide : Make your applications easy to debug

Conclusion

Mastering kubectl logs is essential for effective Kubernetes development and operations. As your applications grow, consider complementing them with advanced logging solutions like Levitate Logs.

By understanding the various options and use cases for kubectl logs, you'll be better equipped to diagnose issues, monitor applications, and ensure smooth Kubernetes deployments.

Explore related topics like pod management, log rotation, and advanced Kubernetes commands to enhance your overall expertise including log aggregation.

Happy logging!

How can I search for specific text in the logs?

Use grep:kubectl logs <pod-name> | grep "error"

Can I save logs to a file?

Yes, redirect the output:kubectl logs <pod-name> > pod_logs.txt

How do I view logs from all containers in a pod?

Use the --all-containers flag:kubectl logs <pod-name> --all-containers

Is there a way to aggregate logs from multiple pods?

While kubectl doesn't provide this natively, you can use tools like stern or a centralized logging solution.

How can I view logs from a specific time range?

Combine the --since and --until flags:kubectl logs <pod-name> --since=2023-08-24T09:00:00Z --until=2023-08-24T10:00:00Z

What's the verbose definition of kubectl logs?

Run kubectl logs --help to see all available options and flags.

Contents


Newsletter

Stay updated on the latest from Last9.

Authors

Anjali Udasi

Helping to make the tech a little less intimidating. I love breaking down complex concepts into easy-to-understand terms.

Handcrafted Related Posts