Lab Solution Pods optional

This lesson walks through a practical solution for a pods lab. You’ll practice: listing and inspecting pods, creating pods imperatively and declaratively, diagnosing image-pull failures, and updating pod manifests to resolve issues.

How many pods exist on the system?

List pods in the current namespace with:

kubectl get pods

By default kubectl get pods shows pods in the current namespace. To target a specific namespace use -n <namespace>. To list pods across all namespaces use --all-namespaces.

If no pods exist you’ll see:

# example output when no pods exist in the namespace
No resources found in default namespace.

Task: Create a new pod using the nginx image

To create a bare Pod object for a single container image you can use kubectl run. Note: on newer kubectl versions kubectl run defaults to creating a Deployment unless you specify --restart=Never.

# View help for kubectl run
kubectl run --help

A minimal example to create a pod:

# Start a nginx pod (create a bare Pod object)
kubectl run nginx --image=nginx --restart=Never

Example session creating the nginx pod:

controlPlane ~ ➜ kubectl run nginx --image=nginx --restart=Never
pod/nginx created

Check the pod list:

controlPlane ~ ➜ kubectl get pods
NAME                READY   STATUS              RESTARTS   AGE
nginx               0/1     ContainerCreating   0          17s
newpods-llstt       0/1     ContainerCreating   0          11s
newpods-pnnx8       0/1     ContainerCreating   0          11s
newpods-k87fx       0/1     ContainerCreating   0          11s

In this example there are four pods: nginx, newpods-llstt, newpods-pnnx8, and newpods-k87fx.

Important: In many kubectl versions kubectl run <name> --image=<image> will create a Deployment by default. Use --restart=Never to create a single Pod instead. If you intend to manage manifests declaratively, consider generating YAML with --dry-run=client -o yaml and then kubectl apply.

Inspect a pod to determine the image used

Use kubectl describe pod <pod-name> to get detailed pod metadata, container images, status, and events. Example:

controlPlane ~ ➜ kubectl describe pod newpods-llstt
Name:         newpods-llstt
Namespace:    default
Priority:     0
Node:         controlplane/172.25.0.47
Start Time:   Fri, 15 Apr 2022 18:12:04 +0000
Labels:       tier=busybox
Annotations:  <none>
Status:       Running
IP:           10.42.0.12
IPs:
  IP:         10.42.0.12
Controlled By:  ReplicaSet/newpods
Containers:
  busybox:
    Container ID:  containerd://b05cd692af1f3b433883f9a8ece19ec2e8c4fcf861aa97ae6a82857ed6037a6d
    Image:         busybox
    Image ID:      docker.io/library/busybox@sha256:d2b53584f580310186df7a2055ce3ff83cc0df6caacf1e3489bff8cf5d0af5d8
    Port:          <none>
    Host Port:     <none>
    Command:
      sleep
      1000
    State:          Running
      Started:      Fri, 15 Apr 2022 18:12:19 +0000
    Ready:          True
    Restart Count:  0
    Environment:    <none>

Conditions:
  Type       Status
  Initialized True
  Ready       True
  PodScheduled True

From the Containers: section you can see the image used for each container — in this example the container image is busybox.

Which node are the new pods placed on?

To determine the node a pod is scheduled on:

Use kubectl describe pod <pod> and check the Node: field, or
Use kubectl get pods -o wide to include the NODE column.

kubectl get pods -o wide

The NODE column shows the node on which each pod is scheduled. In the examples above the pods were scheduled on the controlplane node.

How many containers are part of the pod `webapp`?

The READY column in kubectl get pods shows “ready containers / total containers”. For container-level details, run:

kubectl describe pod webapp

Example excerpt showing two containers (nginx and agentx):

Containers:
  nginx:
    Container ID:   containerd://42fc9932fb07a3047ea1902a6255e75139e981a37426e0ed31ea5ec7a833481d
    Image:          nginx
    Image ID:       docker.io/library/nginx@sha256:2275af0f20d71b293916f1958f8497f987b8d8fd8113df54635f2a5915002bf1
    State:          Running
      Started:      Fri, 15 Apr 2022 18:14:24 +0000
    Ready:          True
    Restart Count:  0

  agentx:
    Container ID:
    Image:          agentx
    Image ID:
    State:          Waiting
      Reason:       ErrImagePull
    Ready:          False
    Restart Count:  0

From this output you can conclude webapp has two containers (nginx and agentx). Quick reference table for interpreting the READY column:

READY value	Meaning
`1/1`	Pod has one container and it is ready.
`1/2`	Pod has two containers; one is ready and one is not.
`0/1`	Pod has one container and it is not ready.

What is the state of the container `agentx` in the pod `webapp` and why?

The agentx container shows State: Waiting with Reason: ErrImagePull. The Events section from kubectl describe provides more context:

Events:
  Type     Reason     Age    From              Message
  ----     ------     ---    ----              -------
  Normal   Scheduled  36s    default-scheduler Successfully assigned default/webapp to controlplane
  Normal   Pulling    36s    kubelet           Pulling image "nginx"
  Normal   Pulled     35s    kubelet           Successfully pulled image "nginx"
  Normal   Created    35s    kubelet           Created container nginx
  Normal   Started    35s    kubelet           Started container nginx
  Normal   Pulling    21s    kubelet           Pulling image "agentx"
  Warning  Failed     21s    kubelet           Failed to pull image "agentx": rpc error: code = Unknown desc: failed to pull and unpack image "docker.io/library/agentx:latest": failed to resolve reference "docker.io/library/agentx:latest": pull access denied, repository does not exist or may require authorization
  Warning  Failed     21s    kubelet           Error: ErrImagePull
  Normal   BackOff    9s     kubelet           Back-off pulling image "agentx"
  Warning  Failed     9s     kubelet           Error: ImagePullBackOff

The failure message indicates Docker Hub does not have an image named agentx (or the image requires authentication). As a result, the kubelet cannot pull the image and the container stays in a waiting/error state.

What does the READY column in `kubectl get pods` indicate?

READY indicates how many containers in the pod are currently ready vs. the total number of containers in that pod. Use it for a quick health indicator. Examples:

1/1 — single container, it is ready.
1/2 — pod has two containers, one is ready and one is not.

Delete the `webapp` pod

To delete the pod:

controlPlane ~ ➜ kubectl delete pod webapp
pod "webapp" deleted

Create a new pod named `redis` with the image `redis123` (intentional invalid image)

You can create a pod imperatively with kubectl run, or generate a pod manifest with --dry-run=client -o yaml and apply it later. (Note: --dry-run without a value is deprecated; use --dry-run=client.)

Use --dry-run=client to generate the resource manifest without creating it. Redirect the output to a YAML file to edit before applying.

Generate a YAML manifest (this manifest intentionally uses a wrong image name redis123):

controlPlane ~ ➜ kubectl run redis --image=redis123 --dry-run=client -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: redis
  name: redis
spec:
  containers:
  - image: redis123
    name: redis
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

Save this output to redis.yaml, then create the pod:

controlPlane ~ ➜ kubectl create -f redis.yaml
pod/redis created

Because redis123 does not exist on the registry, the pod will fail to pull the image and enter a state such as ImagePullBackOff.

Fix the pod by changing the image to `redis`

You can fix the manifest by editing the YAML and re-applying it, or use kubectl edit pod redis to change the image in-place (note: editing a running pod may be limited — manifests are generally managed declaratively). Corrected YAML (image set to redis):

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: redis
  name: redis
spec:
  containers:
  - image: redis
    name: redis
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

Apply the corrected manifest:

controlPlane ~ ➜ kubectl apply -f redis.yaml
pod/redis configured

Verify the pod is running:

controlPlane ~ ➜ kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
redis   1/1     Running   0          10s

Common pod debugging commands

Task	Command	Notes
List pods	`kubectl get pods`	Add `-o wide` to see assigned node.
Describe a pod	`kubectl describe pod <pod-name>`	Shows container images, states, and recent events.
View container logs	`kubectl logs <pod-name> [-c <container>]`	Include `-c` when multiple containers exist.
Exec into a container	`kubectl exec -it <pod-name> -c <container> -- /bin/sh`	Useful for interactive troubleshooting.
Generate manifest without creating	`kubectl run <name> --image=<image> --dry-run=client -o yaml`	Save and edit before `kubectl apply -f`.

This completes the lab solution for pods. You practiced listing pods, inspecting details with kubectl describe, interpreting READY and event messages, creating pods both imperatively and declaratively, diagnosing image-pull failures, and updating a pod manifest to fix a broken image reference. Links and references

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Lab Solution Pods optional

How many pods exist on the system?

Task: Create a new pod using the nginx image

Inspect a pod to determine the image used

Which node are the new pods placed on?

How many containers are part of the pod `webapp`?

What is the state of the container `agentx` in the pod `webapp` and why?

What does the READY column in `kubectl get pods` indicate?

Delete the `webapp` pod

Create a new pod named `redis` with the image `redis123` (intentional invalid image)

Fix the pod by changing the image to `redis`

Common pod debugging commands

Watch Video

​How many pods exist on the system?

​Task: Create a new pod using the nginx image

​Inspect a pod to determine the image used

​Which node are the new pods placed on?

​How many containers are part of the pod webapp?

​What is the state of the container agentx in the pod webapp and why?

​What does the READY column in kubectl get pods indicate?

​Delete the webapp pod

​Create a new pod named redis with the image redis123 (intentional invalid image)

​Fix the pod by changing the image to redis

​Common pod debugging commands

Watch Video

How many pods exist on the system?

Task: Create a new pod using the nginx image

Inspect a pod to determine the image used

Which node are the new pods placed on?

How many containers are part of the pod `webapp`?

What is the state of the container `agentx` in the pod `webapp` and why?

What does the READY column in `kubectl get pods` indicate?

Delete the `webapp` pod

Create a new pod named `redis` with the image `redis123` (intentional invalid image)

Fix the pod by changing the image to `redis`

Common pod debugging commands