kubectl logs for debugging in Kubernetes - Commands & Configuration

Introduction

Sometimes your app inside Kubernetes does not work as expected. You need to see what it is doing inside. The kubectl logs command shows the messages your app writes, helping you find problems.

When your app crashes or restarts and you want to see error messages.

When your app is running but not behaving correctly and you want to check its output.

When you want to verify that your app started successfully inside the pod.

When you want to see recent activity or debug information from your app.

When you want to check logs from a specific container in a pod with multiple containers.

Commands

This command lists all pods in the current namespace so you can find the exact pod name to check logs from.

Terminal

kubectl get pods

Expected Output

NAME           READY   STATUS    RESTARTS   AGE

my-app-pod     1/1     Running   0          10m

This command shows the logs from the main container in the pod named 'my-app-pod'. It helps you see what your app printed to its output.

Terminal

kubectl logs my-app-pod

Expected Output

Starting application...

Listening on port 8080

Connection established

Error: failed to connect to database

Retrying connection...

This command shows logs from the previous instance of the container if it crashed and restarted. Useful to see what caused the crash.

Terminal

kubectl logs my-app-pod --previous

Expected Output

Starting application...

Fatal error: out of memory

Container terminated unexpectedly

→

--previous - Show logs from the last terminated container instance

If your pod has multiple containers, this command shows logs from the container named 'sidecar-container'.

Terminal

kubectl logs my-app-pod -c sidecar-container

Expected Output

Sidecar started

Syncing data with main app

Sync complete

→

-c - Specify which container's logs to show

Key Concept

If you remember nothing else from this pattern, remember: kubectl logs lets you see what your app inside a pod is saying, which is key to finding and fixing problems.

Common Mistakes

Trying to get logs from a pod name that does not exist or is misspelled.

kubectl will return an error because it cannot find the pod to show logs from.

Run 'kubectl get pods' first to find the exact pod name and use that name in the logs command.

Not specifying the container name in a pod with multiple containers.

kubectl logs will fail or show logs from the wrong container, missing the information you need.

Use the '-c container-name' flag to specify which container's logs you want.

Not using the '--previous' flag when checking logs after a crash.

You will see only the current container logs, which may be empty if the container restarted, missing the crash details.

Use 'kubectl logs pod-name --previous' to see logs from the crashed container instance.

Summary

Use 'kubectl get pods' to find the pod name before checking logs.

Use 'kubectl logs pod-name' to see the current logs from the main container.

Use '--previous' to see logs from a crashed container before it restarted.

Use '-c container-name' to get logs from a specific container in a multi-container pod.

Practice

1. What does the kubectl logs command do in Kubernetes?

easy

A. Deletes a pod from the cluster

B. Lists all pods running in the cluster

C. Creates a new pod with specified configuration

D. Shows the output logs of a container inside a pod

Solution

1. Step 1: Understand the purpose of kubectl logs

   This command is used to view the logs generated by containers running inside pods in Kubernetes.

2. Step 2: Differentiate from other commands

   Deleting pods uses kubectl delete, creating pods uses kubectl create, and listing pods uses kubectl get pods. None of these show logs.

3. Final Answer:

   Shows the output logs of a container inside a pod -> Option D

4. Quick Check:

   Logs = Output from container [OK]

Hint: Logs show container output, not pod creation or deletion [OK]

Common Mistakes:

• Confusing logs with pod creation or deletion
• Thinking logs list pods instead of showing output
• Assuming logs show cluster-wide events

2. Which of the following is the correct syntax to follow logs live from a pod named webapp-123?

easy

A. kubectl logs webapp-123 --follow

B. kubectl logs --tail webapp-123

C. kubectl logs webapp-123 -t

D. kubectl logs -t webapp-123

Solution

1. Step 1: Recall correct flag placement

   The --follow flag comes after the pod name in the kubectl logs command syntax.

2. Step 2: Check distractor flags

   Distractors use --tail (shows last lines, no streaming) or -t (timestamps, no follow). Only --follow streams live.

3. Final Answer:

   kubectl logs webapp-123 --follow -> Option A

4. Quick Check:

   Pod name first, then flags [OK]

Hint: Put pod name before flags like --follow [OK]

Common Mistakes:

• Placing flags before pod name
• Using --tail or -t instead of --follow
• Mixing order of arguments

3. Given the command kubectl logs mypod --tail=5, what will be the output?

medium

A. Shows all logs except the last 5 lines from the pod named mypod

B. Shows the first 5 lines of logs from the pod named mypod

C. Shows the last 5 lines of logs from the pod named mypod

D. Shows logs only if the pod has more than 5 containers

Solution

1. Step 1: Understand the --tail option

   The --tail=5 option limits the output to the last 5 lines of the logs.

2. Step 2: Confirm it applies to the specified pod

   The command targets the pod named mypod, so logs shown are from that pod only.

3. Final Answer:

   Shows the last 5 lines of logs from the pod named mypod -> Option C

4. Quick Check:

   --tail = last lines [OK]

Hint: --tail shows last lines, not first [OK]

Common Mistakes:

• Thinking --tail shows first lines
• Confusing pod logs with container logs
• Assuming it filters by container count

4. You run kubectl logs mypod -c mycontainer but get an error saying container not found. What is the likely cause?

medium

A. The pod mypod is not running

B. The container name mycontainer does not exist in pod mypod

C. You forgot to add the --follow flag

D. The pod mypod has multiple containers but you did not specify one

Solution

1. Step 1: Analyze the error message

   The error says container not found, which means the container name given is incorrect or missing in the pod.

2. Step 2: Check command correctness

   You specified -c mycontainer, so if the container name is wrong, the error appears. Pod running state or missing --follow flag does not cause this error.

3. Final Answer:

   The container name mycontainer does not exist in pod mypod -> Option B

4. Quick Check:

   Container name must match exactly [OK]

Hint: Check container name spelling matches pod's containers [OK]

Common Mistakes:

• Assuming pod state causes container not found error
• Forgetting to specify container when multiple exist
• Using wrong flag for container name

5. You want to debug a pod with two containers named frontend and backend. Which command correctly streams live logs from the backend container only?

hard

A. kubectl logs podname -c backend --follow

B. kubectl logs podname --tail -c backend

C. kubectl logs -c backend podname --tail

D. kubectl logs --tail podname -c backend

Solution

1. Step 1: Recall correct argument order

   The pod name must come immediately after kubectl logs, followed by flags like -c and --follow.

2. Step 2: Confirm container and follow flag usage

   Using -c backend specifies the backend container, and --follow streams logs live.

3. Final Answer:

   kubectl logs podname -c backend --follow -> Option A

4. Quick Check:

   Pod name first, then container and flags [OK]

Hint: Pod name first, then container (-c) and --follow [OK]

Common Mistakes:

• Placing flags before pod name
• Mixing order of container and follow flags
• Using unsupported shorthand flags