DEV Community: member_1f4b7040

kubectl logs: Every Flag You'll Actually Use

member_1f4b7040 — Sun, 11 Oct 2026 12:14:26 +0000

kubectl logs is the first command you reach for when something breaks — and most people know only the bare version. The flags below are the difference between scrolling through a million lines and finding the error in the first ten.

The basics
Follow and tail
Multi-container pods
Logs from many pods at once
Time filtering
Crashed containers: --previous
Debugging when logs are empty
Beyond kubectl logs

The basics

kubectl logs <pod-name>                  # current container logs
kubectl logs <pod-name> -n <namespace>   # non-default namespace

Logs come from the container's stdout/stderr — if your app writes to a file instead of stdout, kubectl logs shows nothing. That's a container-design problem (log to stdout), not a kubectl problem.

Follow and tail

kubectl logs -f <pod>            # stream live, like tail -f
kubectl logs --tail=100 <pod>    # last 100 lines only
kubectl logs <pod> | tail -50    # same, via pipe

-f is your deploy-verification workhorse: kubectl logs -f deploy/my-app right after kubectl rollout watches the new version come up.

Multi-container pods

Sidecars mean one pod, several log streams. -c picks the container:

kubectl logs <pod> -c app              # one container
kubectl logs <pod> --all-containers    # every container, prefixed
kubectl logs <pod> -c istio-proxy      # the sidecar specifically

Forgetting -c on a multi-container pod gets you a container name must be specified — or silently the wrong container's logs.

Logs from many pods at once

kubectl logs accepts a selector or a workload instead of a pod name — it streams from one matching pod, or fans out with --prefix:

kubectl logs -l app=web --all-containers --prefix   # every web pod, prefixed
kubectl logs deploy/api --tail=50                    # one pod from the deployment
kubectl logs -l app=web --max-log-requests 10        # cap concurrent streams

For serious multi-pod tailing, stern (a tiny dedicated tool) does it better: stern web streams all matching pods with color-coded prefixes.

Time filtering

kubectl logs --since=10m <pod>     # last 10 minutes
kubectl logs --since=1h <pod>      # last hour
kubectl logs --since-time=2026-10-15T09:00:00Z <pod>   # absolute RFC3339

--since after an incident narrows the haystack before you grep.

Crashed containers: --previous

kubectl logs <pod> --previous    # logs of the *last* crashed container

This is the CrashLoopBackOff move: the current container keeps restarting, so its logs are empty or truncated — --previous gets the logs from the run that just died, which is where the actual panic/error lives. If --previous returns "container not found," the pod restarted more than once or was rescheduled — check kubectl describe for the restart count and reason.

Debugging when logs are empty

kubectl logs returning nothing is itself a signal:

Container never started — check kubectl describe pod events (probe failures, CreateContainerError, ImagePullBackOff — see fixing ImagePullBackOff).
App logs to a file — kubectl exec in and read it, or reconfigure the app to log to stdout.
Log rotation evicted data — kubelet keeps a bounded file; long-running pods lose early logs. For anything beyond "what just happened," you need a log pipeline.
Pod was deleted and recreated — logs die with the pod. --previous only works for restarts within the same pod.

Beyond kubectl logs

kubectl logs is for live debugging — it's not retention. For history across restarts, pod deletions, and multi-node searches, you want log aggregation: Grafana Loki is the lightweight Kubernetes-native option, and pairs with the alerting covered in Prometheus Alerting.

Author: CloudOpsGuide Team

ImagePullBackOff: How to Fix It Step by Step

member_1f4b7040 — Sun, 11 Oct 2026 12:14:23 +0000

ImagePullBackOff means Kubernetes tried to pull your container image, failed, and is now retrying with exponential backoff. The pod will never start until the pull succeeds — but the fix is usually one of five causes, and kubectl describe tells you which within seconds.

See the real error
Cause 1 — Wrong image name or tag
Cause 2 — Private registry auth
Cause 3 — Rate limits and network
Cause 4 — Platform/architecture mismatch
Cause 5 — Tag exists but was overwritten
When it's actually ErrImagePull

See the real error

Don't guess — get the event:

kubectl describe pod <pod-name> -n <namespace>

Scroll to Events at the bottom. The Failed to pull image line carries the real reason verbatim:

Failed to pull image "myregistry/app:v2":
rpc error: code = NotFound desc = failed to pull and unpack image:
failed to resolve reference: myregistry/app:v2: not found

Each cause below maps to a distinct event message.

Cause 1 — Wrong image name or tag

Event says: not found, manifest unknown, or does not exist.

The image name or tag doesn't exist in the registry. Check for typos first — ngnix vs nginx is embarrassingly common — then verify the tag actually exists:

# For Docker Hub, check the tag exists
crane ls myrepo/myimage        # or check the registry UI
docker pull myregistry/app:v2  # test the pull from your machine

Watch for latest — it only exists if someone pushed it, and on some registries it means nothing at all. Pin explicit tags in the manifest.

Cause 2 — Private registry auth

Event says: unauthorized, 401, access denied, no basic auth credentials.

Kubernetes can't authenticate to your registry. Fix: create an image pull secret and reference it:

kubectl create secret docker-registry regcred \
  --docker-server=myregistry.example.com \
  --docker-username=robot_user \
  --docker-password=<token> \
  -n my-namespace

spec:
  imagePullSecrets:
    - name: regcred
  containers:
    - name: app
      image: myregistry.example.com/app:v2

For ECR/GCR/ACR, prefer workload identity or node-level IAM over static secrets — cloud registries rotate tokens. Gotcha: the secret must be in the same namespace as the pod, and default service accounts can carry it cluster-wide via imagePullSecrets on the SA.

Cause 3 — Rate limits and network

Event says: toomanyrequests, connection refused, i/o timeout, context deadline exceeded.

Docker Hub rate limits — anonymous pulls are capped per IP; a busy cluster NATs all pulls through one egress IP and hits the ceiling fast. Fix: authenticate pulls (higher limit) or mirror images to your own registry.
Corporate proxy/firewall — nodes can't reach the registry. Test from a node: crictl pull <image> bypasses Kubernetes entirely.
DNS — lookup myregistry on 10.96.0.10:53: no such host means CoreDNS can't resolve it; check kube-dns pods.

Cause 4 — Platform/architecture mismatch

Event says: no matching manifest for linux/arm64 (or amd64).

The image was built for the wrong CPU architecture — common when developers build on Apple Silicon and deploy to amd64 nodes. Fix: build multi-arch images:

docker buildx build --platform linux/amd64,linux/arm64 \
  -t myregistry/app:v2 --push .

Cause 5 — Tag exists but was overwritten

Event says: pull succeeds but the container is wrong, or pull used to work and silently changed.

Someone repushed the tag with different content. imagePullPolicy: Always pulls every restart; IfNotPresent caches whatever it first pulled — a moving latest tag gives different nodes different images. Pin digests for reproducibility:

image: myregistry/app@sha256:abc123...

When it's actually ErrImagePull

ErrImagePull is the initial failure state; ImagePullBackOff is the retry state — same root causes. If the pod later shows CreateContainerConfigError or CrashLoopBackOff, the pull succeeded and your problem moved elsewhere — see Fixing CrashLoopBackOff for the next tier of debugging.

The one-line summary: describe the pod, read the event, fix the named cause. ImagePullBackOff is never the disease — it's the symptom.