Kubernetes Fundamentals · Module 03 of 14

Pods: lifecycle, logs and exec

Work with the smallest deployable Kubernetes object and learn how Pod phase, container state, logs and exec fit together.

Learning objectives

By the end of this module, you should be able to:

Explain why Kubernetes schedules Pods rather than individual containers.
Inspect Pod phase and container state.
Use logs, describe and exec for first-line troubleshooting.

A Pod is the scheduling unit

A Pod groups one or more tightly coupled containers that share network and selected storage resources. Containers in the same Pod share the Pod IP and can communicate through localhost.

Pod phase is coarse-grained

Pending, Running, Succeeded, Failed and Unknown are Pod phases. Container states such as Waiting, Running and Terminated provide more detailed runtime information. A Running Pod can still contain an unhealthy application.

Pods are disposable

Higher-level controllers normally create Pods. If a controller replaces a failed Pod, the replacement gets a new identity and usually a new IP. Persist important data outside the Pod writable layer.

Worked examples

See the idea in practice.

Observe a Pod

kubectl -n gnu-k8s-fundamentals run pod-demo --image=busybox:1.36 --restart=Never -- sh -c 'echo started; sleep 3600'
kubectl -n gnu-k8s-fundamentals get pod pod-demo -o wide
kubectl -n gnu-k8s-fundamentals logs pod-demo

The Pod runs one container.
The startup line is available through logs.
The Pod receives its own cluster network identity.

Hands-on lab

Lab — Observe and enter a running Pod

Goal: Create a Pod, read its state, inspect output and execute a command inside it.

Before you start

kubectl is installed and can reach the lab cluster.
Use the dedicated gnu-k8s-fundamentals namespace unless a step explicitly says otherwise.

STEP 1

Create the Pod

kubectl -n gnu-k8s-fundamentals run pod-demo --image=busybox:1.36 --restart=Never -- sh -c 'echo started; sleep 3600'

STEP 2

Wait for Running

kubectl -n gnu-k8s-fundamentals wait --for=condition=Ready pod/pod-demo --timeout=90s

STEP 3

Read logs and state

kubectl -n gnu-k8s-fundamentals logs pod-demo
kubectl -n gnu-k8s-fundamentals get pod pod-demo -o wide
kubectl -n gnu-k8s-fundamentals describe pod pod-demo

STEP 4

Execute inside the container

kubectl -n gnu-k8s-fundamentals exec pod-demo -- sh -c 'echo pod=$HOSTNAME; cat /etc/os-release | head -1'

STEP 5

Clean up

kubectl -n gnu-k8s-fundamentals delete pod pod-demo --wait=true

Verify

The Pod reaches Ready.
Logs contain started.
exec runs inside the existing container.

Expected outcome

kubectl get reports 1/1 Ready while the sleep process is running.

If it fails

If the Pod stays Pending, inspect Events with kubectl describe pod.
If ImagePullBackOff appears, verify image name, registry access and DNS.

Real-world connection

Logs, describe and exec form the basic evidence-gathering toolkit for application Pods.

Avoid these traps

Common mistakes

Treating Pod phase Running as proof that the application is healthy.
Writing persistent application state only to the container writable layer.
Creating naked Pods for production workloads that need self-healing.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What is the smallest deployable scheduling unit in Kubernetes?

A Pod.

2How do containers inside one Pod communicate with each other?

They share the Pod network namespace and can use localhost.

3What should you inspect when a Pod is Pending?

Describe the Pod and inspect scheduling/events information.