kubectl logs

When to Use kubectl logs

kubectl logs is the primary tool for viewing application output from containers. Every process running in a container that writes to stdout or stderr has its output captured by the container runtime and made accessible through this command.

Basic Log Viewing

# View all logs for a pod
kubectl logs my-pod

# View the last 50 lines
kubectl logs my-pod --tail=50

# View logs from the past 30 minutes
kubectl logs my-pod --since=30m

# View logs since a specific time
kubectl logs my-pod --since-time='2024-01-15T10:00:00Z'

# Include timestamps in output
kubectl logs my-pod --timestamps

Streaming Logs

The -f flag streams logs in real-time, similar to tail -f:

# Stream logs from a single pod
kubectl logs -f my-pod

# Stream with a tail to skip historical logs
kubectl logs -f --tail=0 my-pod

# Stream logs from all pods in a deployment
kubectl logs -f -l app=my-app

Press Ctrl+C to stop streaming. When streaming from multiple pods with a label selector, logs are interleaved and prefixed with the pod name.

Multi-Container Pods

Pods with sidecar containers, init containers, or multiple application containers require you to specify which container's logs to view:

# List containers in a pod
kubectl get pod my-pod -o jsonpath='{.spec.containers[*].name}'

# View logs from a specific container
kubectl logs my-pod -c nginx
kubectl logs my-pod -c istio-proxy

# View logs from all containers
kubectl logs my-pod --all-containers

# View init container logs
kubectl logs my-pod -c init-db

If you do not specify a container in a multi-container pod, kubectl will show an error listing the available container names.

Debugging Crashes

When a container is in CrashLoopBackOff, the current container may have no logs because it just started. Use --previous to see the logs from the container that crashed:

# View logs from the crashed container
kubectl logs my-pod --previous

# View the last 100 lines from the crashed container
kubectl logs my-pod --previous --tail=100

# Check a specific container in a multi-container pod
kubectl logs my-pod -c app --previous

The --previous flag only retains logs from the most recent previous instance. If the container has crashed multiple times, you can only see the immediately preceding run.

Aggregating Logs Across Pods

For services running multiple replicas, aggregate logs using label selectors:

# View logs from all pods in a deployment
kubectl logs -l app=nginx

# Stream from all pods with a limit
kubectl logs -f -l app=nginx --max-log-requests=20

# View logs from a specific deployment's pods
kubectl logs deployment/my-app

# View logs from a job
kubectl logs job/my-batch-job

The --max-log-requests flag controls how many concurrent log streams are opened. The default is 5, which limits the number of pods you can follow simultaneously.

Log Output Pipelines

Combine kubectl logs with standard Unix tools for analysis:

# Search for errors
kubectl logs my-pod | grep -i error

# Count occurrences of a pattern
kubectl logs my-pod | grep "ERROR" | wc -l

# Extract JSON log fields with jq
kubectl logs my-pod | jq 'select(.level == "error")'

# Tail and search in real-time
kubectl logs -f my-pod | grep --line-buffered "WARNING"

# Save logs to a file
kubectl logs my-pod --timestamps > pod-logs.txt

Logging Best Practices

Applications should log to stdout and stderr rather than to files inside the container. Kubernetes captures stdout/stderr automatically, and this approach works with log aggregation systems.

For production environments, do not rely solely on kubectl logs. Set up a centralized logging stack that collects, stores, and indexes logs from all pods. Popular options include the EFK stack (Elasticsearch, Fluentd, Kibana), Grafana Loki, and cloud provider logging services.

Container logs are rotated by the container runtime when they exceed a size threshold (typically 10 MB). To prevent log loss, ensure your aggregation system collects logs faster than the rotation interval.