5 kubectl Commands to Aggregate K8s Logs in Seconds: Ditch Pod-by-Pod Debugging

When a production service suddenly throws 5xx errors, engineers often run kubectl get pods, see 10 replicas, and then manually tail each pod with kubectl logs -f pod-0, pod-1, etc. This wastes minutes, especially when errors are intermittent and the source pod is unknown.

Why Not EFK / Loki?

Large environments have centralized logging stacks (EFK/ELK, Loki), but many projects lack them. Even when available, writing complex Elasticsearch DSL queries or waiting for Loki's ingestion latency is often slower than a single kubectl command on the command line.

Command 1: Label Selector for Targeted Log Collection

Instead of copying pod names, use the Deployment or Service label (e.g., app=backend) to fetch logs from all matching pods at once:

# Last 30 minutes, last 100 lines
kubectl logs -l app=backend --tail=100 --since=30m

Advanced: Pipe to grep with context to isolate errors and surrounding stack traces:

kubectl logs -l app=backend --since=30m | grep -B 5 -A 5 "ERROR"

Note: -B 5 prints 5 lines before each match, -A 5 prints 5 lines after. Essential for viewing Java stack traces.

Command 2: Time-Range Filtering to Avoid Log Flood

High-traffic services generate hundreds of lines per second; --tail alone may miss errors from minutes ago. Use time filters: --since=30m: Relative window (supports h, d). --since-time="2026-08-20T15:00:00Z": Absolute RFC3339 timestamp with timezone suffix.

Best practice: Combine time window with keyword search:

kubectl logs -l app=backend --since=10m | grep -i "exception"

Command 3: Prefix Each Line with Pod Name for Full-Trace Analysis

The previous commands merge logs from all pods, losing pod identity. Fix with a shell loop that tags each pod's output:

for pod in $(kubectl get pods -l app=backend -o name); do
  echo "============== $pod 日志开始 =============="
  kubectl logs $pod --tail=50 --since=10m
  echo "============== $pod 日志结束 =============="
done

This prints clear start/end markers per pod, making it obvious which replica produced an error.

Command 4: The Ultimate Tool — kubetail (Highly Recommended)

If writing loops is tedious, use the open-source kubetail (Shell script, no runtime dependencies). Install:

curl -L https://raw.githubusercontent.com/johanhaleby/kubetail/master/kubetail -o /usr/local/bin/kubetail
chmod +x /usr/local/bin/kubetail

Usage (specify Deployment name, not pod):

kubetail backend -s 30m -k

-s 30m

: Follow logs from the last 30 minutes. -k: Color-highlight each pod's stream differently.

It automatically aggregates all pods of a Deployment into one colored terminal view.

Command 5: Debugging CrashLoopBackOff with --previous

When a pod crashes and restarts before you can read its logs, do not use logs; use logs --previous to see the terminated container's output:

# View previous (crashed) container logs
kubectl logs your-pod-name --previous

# With label selector
kubectl logs -l app=backend --previous

Golden Troubleshooting Template

Combine all techniques into a repeatable first-response workflow:

# 1. Check pod health
kubectl get pods -l app=backend -o wide

# 2. If restarts or errors appear, aggregate last 30 min, top 100 lines, filter anomalies
kubectl logs -l app=backend --tail=100 --since=30m | grep -E "ERROR|Exception|503|500|panic" -B 5

This reduces a typical 10-minute firefighting cycle to under one minute.