> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Lab Solution Pods optional > Guide to Kubernetes pod operations and debugging, including creating and inspecting pods, diagnosing image pull errors, updating manifests, and common kubectl commands. 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: ```bash theme={null} kubectl get pods ``` By default `kubectl get pods` shows pods in the current namespace. To target a specific namespace use `-n `. To list pods across all namespaces use `--all-namespaces`. If no pods exist you'll see: ```bash theme={null} # 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`. ```bash theme={null} # View help for kubectl run kubectl run --help ``` A minimal example to create a pod: ```bash theme={null} # Start a nginx pod (create a bare Pod object) kubectl run nginx --image=nginx --restart=Never ``` Example session creating the nginx pod: ```bash theme={null} controlPlane ~ ➜ kubectl run nginx --image=nginx --restart=Never pod/nginx created ``` Check the pod list: ```bash theme={null} 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 --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 ` to get detailed pod metadata, container images, status, and events. Example: ```bash theme={null} 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: 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: Host Port: Command: sleep 1000 State: Running Started: Fri, 15 Apr 2022 18:12:19 +0000 Ready: True Restart Count: 0 Environment: 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 ` and check the `Node:` field, or * Use `kubectl get pods -o wide` to include the `NODE` column. ```bash theme={null} 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: ```bash theme={null} kubectl describe pod webapp ``` Example excerpt showing two containers (`nginx` and `agentx`): ```bash theme={null} 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: ```bash theme={null} 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: ```bash theme={null} 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`): ```bash theme={null} 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: ```bash theme={null} 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`): ```yaml theme={null} 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: ```bash theme={null} controlPlane ~ ➜ kubectl apply -f redis.yaml pod/redis configured ``` Verify the pod is running: ```bash theme={null} 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 ` | Shows container images, states, and recent events. | | View container logs | `kubectl logs [-c ]` | Include `-c` when multiple containers exist. | | Exec into a container | `kubectl exec -it -c -- /bin/sh` | Useful for interactive troubleshooting. | | Generate manifest without creating | `kubectl run --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 * [Kubernetes Pods documentation](https://kubernetes.io/docs/concepts/workloads/pods/) * [kubectl reference](https://kubernetes.io/docs/reference/kubectl/) * [Kubernetes Troubleshooting](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-application/) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.