Introduction

The error saying a container name must be specified means the pod contains more than one container, so kubectl logs does not know which log stream you want. The fix is not a cluster issue or a logging bug. You simply need to identify the container name and request logs for that container explicitly.

Why the Error Happens

A Kubernetes pod can include:

• one main application container
• one or more sidecars
• one or more init containers

If a pod contains both wait and main, Kubernetes sees two valid log sources. Running kubectl logs my-pod without further detail is ambiguous, so the CLI tells you to choose one.

You can confirm the container names like this:

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

If the pod also has init containers, inspect those separately:

kubectl get pod my-pod -o jsonpath='{.spec.initContainers[*].name}'

Knowing the exact container list is the first step before asking for logs.

Fetch Logs from a Specific Container

Use the -c or --container flag with the pod name.

kubectl logs my-pod -c main
kubectl logs my-pod -c wait

If the pod is in a non-default namespace, include -n:

kubectl logs my-pod -n jobs -c main

This is the normal workflow for multi-container pods. Sidecars are common in service meshes, proxy setups, and batch jobs, so it is worth getting comfortable with the flag rather than treating the message as exceptional.

Follow Logs and Inspect Previous Runs

Once you specify the container, all the standard kubectl logs options still work.

Follow a live stream:

kubectl logs -f my-pod -c main

Show timestamps:

kubectl logs my-pod -c main --timestamps

Read logs from the previous crashed container instance:

kubectl logs my-pod -c main --previous

That last command is especially useful in CrashLoopBackOff cases where the current container restarts too quickly to inspect.

Show Logs from All Containers

Sometimes you want the combined picture, especially when a sidecar and main container interact. kubectl can aggregate them for you.

kubectl logs my-pod --all-containers=true

You can also combine that with follow mode:

kubectl logs -f my-pod --all-containers=true

This is convenient for quick debugging, although it can get noisy on busy pods. For deeper analysis, reading one container at a time is usually easier.

Logs from Deployments and Jobs

You do not always need to resolve the pod name manually. Kubernetes can select the pod behind a higher-level resource.

kubectl logs deployment/my-app -c main
kubectl logs job/data-import -c main

This helps when pod names are generated dynamically, but the same rule still applies: if the underlying pod has multiple containers, specify the container you want.

Common Pitfalls

The most common mistake is assuming the first listed container is always the application container. In many pods, the interesting logs actually come from a proxy, init container, or lightweight coordination container such as wait.

Another common issue is forgetting namespaces. A perfectly valid kubectl logs command will fail or target the wrong pod if the namespace is omitted in clusters with similarly named workloads.

People also often miss --previous when debugging restarts. If the current container is freshly restarted, its current logs may look empty even though the failed run produced the information you need.

Finally, --all-containers=true is useful but not magic. It does not merge application context for you. If one container prints readiness checks and another prints business errors, you still need to interpret the streams separately.

Summary

• The error appears because the pod has multiple containers and kubectl logs needs one container name.
• List container names first, then use kubectl logs POD -c CONTAINER.
• Add -f, --timestamps, or --previous as needed once the container is specified.
• Use --all-containers=true for a quick multi-stream view.
• Remember to include the namespace and check init containers when debugging startup issues.