Understanding Pods

Introduction

In this lab, you will explore the smallest deployable unit in Kubernetes: the Pod.

A pod is the object Kubernetes schedules onto a node. You usually do not run a container directly in Kubernetes by itself; instead, containers are placed inside pods.

A pod can contain one or more containers that share networking and storage context. Most beginner examples use a single container, but the shared-environment design is the important concept.

You will learn how to:

• Define a Pod using a YAML configuration file (the blueprint).
• Create the Pod in the cluster using kubectl.
• Check the status of the Pod to ensure it's running.
• Inspect the detailed configuration and history of the Pod.

By the end of this lab, you will have a real web server running inside a Pod in your cluster.

Define the Pod

In this step, you will definition of your first Pod. Kubernetes speaks the language of YAML. A YAML file is like a blueprint or a recipe that describes exactly what you want your application to look like.

A Pod is the smallest object Kubernetes schedules, but it is not the same thing as a container. A container is the running application process and its filesystem image. A Pod is the Kubernetes wrapper around one or more containers. That wrapper gives them a shared network identity, a shared lifecycle, and optional shared storage.

A Pod definition requires four main ingredients:

• apiVersion: Which version of the Kubernetes language we are speaking.
• kind: What kind of object we are making (in this case, a Pod).
• metadata: Information to identify the object, like its name and labels.
• spec: The "specification"—the meat of the recipe. This describes the containers to run.

You will create a file named nginx-pod.yaml. This file will define a Pod named nginx-pod that runs a single container using the nginx image (a popular web server).

Create the file using the nano text editor:

nano nginx-pod.yaml

Copy and paste the following content into the file. Read it carefully to see the four sections we discussed:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - containerPort: 80

To save and exit standard nano: press Ctrl+X, then type Y to confirm saving, and hit Enter to write to the filename.

You have now written your first Kubernetes blueprint! It tells Kubernetes: "I want a Pod named nginx-pod. Inside it, please run one container using the nginx image."

Create the Pod

Now that you have your blueprint (nginx-pod.yaml), it's time to hand it over to the construction crew—Kubernetes.

We use the kubectl apply command to do this. This command tells Kubernetes configuration: "Here is the desired state I want. Please make it happen."

The phrase desired state is one of the central Kubernetes ideas. You do not tell the system every low-level step to perform. Instead, you declare the end result you want, and Kubernetes controllers keep working until reality matches that declaration.

Execute the following command to create your Pod:

kubectl apply -f nginx-pod.yaml

You should see a confirmation message:

pod/nginx-pod created

When you ran this command, you sent the blueprint to the Kubernetes API server (the Control Plane). The Scheduler then found a suitable Node for your Pod, and the Kubelet on that Node started downloading the Nginx image to run it.

Check Status

In this step, you will check on the progress of your new Pod. Creating a Pod isn't instantaneous; it takes a moment to download the container image and start the application.

This is a useful point to remember: kubectl apply usually returns quickly because it only submits the request. The actual work happens asynchronously inside the cluster. That is why checking status is a normal second step, not a sign that something is wrong.

To see the status of your Pods, use the get command:

kubectl get pods

You will see a table listing your pods. Look at the STATUS column:

NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          15s

• STATUS: This is the most important field.

  • ContainerCreating: The system is still downloading the image or starting the container.
  • Running: Success! The pod is up and healthy.
  • Pending: The cluster is trying to figure out where to put the pod.
  • Error or CrashLoopBackOff: Something went wrong (e.g., the application crashed).

• READY: Shows 1/1, meaning 1 out of 1 container defined in the Pod is ready to serve traffic.

If you see ContainerCreating, give it a few seconds and run kubectl get pods again. Once it says Running, your Nginx web server is live.

Inspect Details

In this step, you will learn how to "look under the hood". The get command gave us a summary, but sometimes you need to know exactly what is happening—especially if something goes wrong.

The describe command provides a detailed report on your Kubernetes resource.

For beginners, it helps to think of kubectl get and kubectl describe as two different levels of observation. get answers "What is the current headline status?" while describe answers "What happened to get us here?" That event history is often the fastest path to the root cause.

Run the following command to inspect nginx-pod:

kubectl describe pod nginx-pod

This outputs a wealth of information. Scroll to the bottom and look for the Events section. It tells a chronological story of your Pod's startup:

Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  ...   default-scheduler  Successfully assigned default/nginx-pod...
  Normal  Pulling    ...   kubelet            Pulling image "nginx:latest"
  Normal  Pulled     ...   kubelet            Successfully pulled image "nginx:latest"...
  Normal  Created    ...   kubelet            Created container nginx
  Normal  Started    ...   kubelet            Started container nginx

This event log is your first stop for debugging. If a Pod is stuck in Pending or Error, the Events section will usually tell you why (e.g., "Insuficient CPU" or "ImagePullBackOff").

You have now created, verified, and inspected your first Kubernetes Pod!

Summary

In this lab, you mastered the concept of the Pod, the fundamental building block of Kubernetes.

You successfully:

1. Wrote a YAML blueprint for an Nginx Pod.
2. Deployed it to the cluster using kubectl apply.
3. Verified it was Running with kubectl get.
4. Detailed its startup history using kubectl describe.

Understanding Pods is crucial because every other concept in Kubernetes—Deployments, Services, StatefulSets—is ultimately about managing these Pods. You are now ready to tackle more advanced topics!