Introduction

Welcome back, everyone! 👋 I hope you’re as excited as I am to continue our Kubernetes journey together. After our journey through Docker and container fundamentals, it’s time to take our first exciting step into the world of Kubernetes objects. Today, we’re focusing on something special - Kubernetes pods, the fundamental building blocks that make cloud-native applications possible.

In our [previous article]((https://www.iamachs.com/p/kubernetes/part-1-introduction-journey-begins/), we explored Kubernetes at a high level - its architecture, components, and why it’s become so crucial in modern application deployment. Now, we’re diving deeper into pods, the smallest deployable units in Kubernetes. Don’t worry if that sounds a bit technical - by the end of this article, you’ll have a solid grasp of what pods are and how they work.

Why Start with Pods?

You might be wondering, “Why focus on pods first?” Well, remember when we learned about containers and how they package our applications? Pods take this concept to the next level. They’re where your containers actually run in Kubernetes, and understanding them is crucial for anyone preparing for the KCNA (Kubernetes and Cloud Native Associate) certification.

Think of our learning journey like building a house - we started with containers as our foundation, and now pods are the first walls we’re putting up. Everything else in Kubernetes builds upon this understanding.

What We’ll Cover

In this article, we’ll explore:

• What pods are and why Kubernetes uses them instead of working directly with containers
• How pods manage shared resources between containers
• The basic lifecycle of a pod
• How to create and work with pods
• Best practices for working with pods at the KCNA level

By the end of this article, you’ll understand how pods work and how they fit into the bigger Kubernetes picture. You don’t need to memorize every detail - focus on understanding the core concepts, as that’s what’s most important for the KCNA exam.

Ready to dive into the world of Kubernetes pods? Let’s get started!

What is a Pod?

Let’s start with the fundamental question: what exactly is a pod in Kubernetes?

In Kubernetes, a pod is the smallest deployable unit you can create and manage. Now, you might be thinking, “Wait a minute - I thought containers were the basic unit?” That’s a great question! While containers are indeed the basic unit of packaging applications, pods are the basic unit of deployment in Kubernetes.

Remember in our Docker series when we talked about how containers provide isolation for running applications? Pods build on this concept but add something crucial: they can group together one or more containers that need to work together closely.

Why Does Kubernetes Use Pods?

You might be wondering why Kubernetes introduced this extra layer instead of just working with containers directly. The reason is both practical and powerful. When we explored Docker, we learned that containers are great for isolating applications, but in real-world scenarios, some applications need to:

• Share the same network space
• Share storage volumes
• Be scheduled and scaled together
• Share the same lifecycle

This is exactly what pods enable. Think of a pod as a logical host for your containers - it provides a shared environment for one or more containers to run in.

Pod Environment Basics

When Kubernetes creates a pod, it sets up a shared space with some important characteristics that make it perfect for containers that need to work closely together:

1. Shared Network Space: All containers in a pod share the same IP address and port space. What’s really powerful about this is that containers within the same pod can communicate with each other using localhost, just like processes running on the same computer. This removes all the complexity of container-to-container networking within a pod - no need to worry about networking configurations or service discovery between these containers.

2. Shared Storage: Containers in a pod can share storage volumes, enabling them to work on the same files. This is particularly useful when you have containers that need to collaborate on data. For example, one container might generate log files while another processes them - the shared storage makes this interaction seamless.

3. Co-location and Scheduling: Kubernetes ensures that all containers in a pod run on the same node in your cluster. This is crucial because:

   • Containers in a pod start and stop together
   • If a pod needs to be moved to a different node, all its containers move together
   • When you scale your application, the entire pod (with all its containers) is replicated

This “all-or-nothing” approach makes perfect sense when you have containers that are truly meant to work as a unit. There’s no point in running one container without its essential companions.

Pod vs Container: Understanding the Difference

At this point, you might be wondering about the exact relationship between pods and containers. Here’s what you need to know for the KCNA level:

• A pod always runs at least one container
• A pod can run multiple containers when those containers need to work closely together
• All containers in a pod share the pod’s environment
• Containers in a pod are always co-located and co-scheduled

Remember how we talked about container isolation in our Docker series? Pods maintain that isolation at the pod level while allowing controlled sharing between containers within the same pod.

I’ve created a video that explores the fascinating origin story of Kubernetes pods and why they were designed this way. You can watch it here:

Pod Architecture and Resources

Now that we understand what pods are and why they’re so important, let’s explore how they fit into the broader Kubernetes world. To understand this better, we first need to look at how Kubernetes itself is structured.

Understanding the Kubernetes Cluster

A Kubernetes cluster consists of two main parts:

• The control plane (the brain of Kubernetes)
• Worker nodes (where our applications actually run)

The control plane manages the overall state of our cluster, making decisions about where pods should run and ensuring everything stays healthy. Think of it as the conductor of an orchestra, ensuring all parts work together harmoniously.

Worker nodes are the machines that run our applications. Each worker node has a crucial component called the kubelet, which is responsible for managing everything that runs on that node. The kubelet:

• Ensures pods are running and healthy
• Manages the resources assigned to pods
• Reports back to the control plane about the status of its pods

How Pods Work with Nodes

When you create a pod in Kubernetes, several things happen:

1. The control plane decides which worker node should run your pod
2. The kubelet on that node takes responsibility for running the pod
3. The pod gets its own IP address and resources on that node

Remember those shared characteristics we talked about earlier? The kubelet ensures that all containers in a pod get their shared networking, storage, and other resources they need to work together.

Resource Management

One of the kubelet’s key responsibilities is managing resources for pods. When we create a pod, we can specify:

1. Resource Requests: How much CPU and memory the pod needs to function
2. Resource Limits: The maximum amount of resources the pod can use

This helps Kubernetes:

• Choose the right node for your pod
• Ensure fair resource sharing between different pods
• Prevent any single pod from consuming too many resources

Pod Networking

We’ve talked about how containers in a pod share networking - here’s how that actually works in the cluster:

1. Every pod gets its own unique IP address within the cluster
2. All containers in the same pod share this IP address
3. This enables containers within the pod to communicate using localhost

In our next section, we’ll explore how Kubernetes monitors and maintains the health of pods, ensuring your applications keep running reliably.

Pod Lifecycle

Now that we understand how Kubernetes manages pods within the cluster, let’s explore what happens throughout a pod’s life - from creation to removal. Understanding this lifecycle is crucial because it shows us how Kubernetes maintains our applications’ reliability.

Pod Lifecycle Phases

Every pod in Kubernetes goes through various phases. Most pods are designed to run continuously (like web servers or databases), but some are meant to run one-time tasks. Let’s look at these phases:

1. Pending: This is the pod’s initial phase after Kubernetes accepts it but before it can run. During this time, Kubernetes is:

   • Downloading the necessary container images
   • Finding a suitable node with enough resources
   • Setting up the pod’s networking and storage

2. Running: The pod has been scheduled to a node, and all its containers have started. For most applications, this is where pods spend most of their time, continuously running and serving requests.

3. Failed: Something has gone wrong - one or more containers in the pod have stopped working. This could happen due to:

   • Application crashes
   • Resource exhaustion
   • Container runtime issues

4. Succeeded: This phase is specifically for pods that are designed to complete a task and stop, like batch jobs or data processing tasks. When all containers in such a pod finish their work and exit successfully, the pod moves to this state.

5. Unknown: Kubernetes has lost contact with the pod’s node and can’t determine its state. This typically happens due to network issues between the control plane and the node.

When it’s time to remove a pod (whether manually or through scaling), Kubernetes follows a careful termination process:

1. Sends a termination signal to all containers in the pod
2. Gives containers time to shut down gracefully (default 30 seconds)
3. Forces any remaining containers to stop
4. Removes the pod from the cluster

How Kubernetes Monitors Pod Health

Kubernetes uses two types of probes to monitor the health of applications running in pods. What’s interesting is that these probes check individual containers, allowing Kubernetes to maintain health at the most granular level:

1. Liveness Probes: These check if a container is running properly. If a container’s liveness probe fails:

   • Kubernetes marks the container as unhealthy
   • The container is restarted based on the pod’s restart policy
   • The pod remains in the Running state unless all containers fail

2. Readiness Probes: A container might be running but not ready to serve requests. For example:

   • Still loading configuration
   • Warming up application caches
   • Waiting for dependent services

   If a readiness probe fails, Kubernetes:

   • Keeps the container running
   • Removes the pod from service load balancing
   • Waits for the probe to succeed before sending traffic again

Kubernetes can perform these health checks in several ways:

• HTTP checks for web applications (checking if an endpoint responds)
• TCP socket checks for database connections
• Running commands inside the container

Restart Policies

When containers within a pod stop running, Kubernetes needs to know what to do. This is controlled by the pod’s restart policy:

• Always (Default): Kubernetes will always restart containers that stop, regardless of why they stopped. This is perfect for applications that should run continuously.
• OnFailure: Containers are only restarted if they stop with an error. If a container completes successfully, it won’t be restarted.
• Never: Containers won’t be restarted under any circumstances. This is useful for one-time task pods.

By handling these different aspects of a pod’s lifecycle, Kubernetes ensures our applications remain healthy and available. Now that we understand how pods work, let’s put this knowledge into practice by creating our first pod!

Creating Your First Pod

All the concepts we’ve discussed come together when we create a pod. In Kubernetes, we define our pods using YAML files, which tell Kubernetes exactly what we want our pod to look like and how it should behave.

Setting Up Your Environment

Before we create our first pod, you’ll need a few tools:

• Docker: installed on your computer - Get Docker here
• Kind (Kubernetes in Docker): for running a local cluster - Install Kind
• kubectl: command-line tool to interact with Kubernetes - Install kubectl

If you haven’t already, create a local cluster with:

1

kind create cluster

This gives you a working Kubernetes environment right on your computer. Now we’re ready to create our first pod!

Understanding Pod YAML Structure

Let’s look at a simple pod definition and break it down piece by piece:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

apiVersion: v1
kind: Pod
metadata:
  name: my-first-pod
  labels:
    app: web-server
    environment: learning
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Let’s break this down:

1. apiVersion and kind: These tell Kubernetes what type of object we’re creating

   • apiVersion: v1 indicates we’re using the core Kubernetes API
   • kind: Pod specifies that we’re creating a pod

2. metadata: Information that helps identify and organize our pod

   • name: A unique name for our pod
   • labels: Tags that help organize and select pods (useful for service discovery)

3. spec: The heart of our pod definition

   • containers: List of containers in our pod
   • Each container needs:
     • A name
     • An image to run
     • Any ports it needs to expose
     • Resource requests and limits

Resource Management

Notice how we specified resources in our pod definition. This is a crucial practice that helps Kubernetes:

• Find the right node for our pod
• Ensure fair resource sharing
• Prevent resource exhaustion

The requests tell Kubernetes what our pod needs to function, while limits set the maximum resources it can use.

Creating the Pod

With our YAML file ready, we can create our pod using:

1

kubectl apply -f my-first-pod.yaml

To check on our pod’s status:

1

kubectl get pod my-first-pod

You’ll see your pod move through the lifecycle phases we discussed earlier, from Pending to Running (assuming everything is configured correctly).

Viewing Pod Details

Want to know more about your pod? Try:

1

kubectl describe pod my-first-pod

This shows you detailed information about your pod, including:

• Current status
• Node it’s running on
• IP address
• Events (useful for troubleshooting)

Accessing Your Pod

Once your pod is running, you can interact with it:

1
2

# Forward local port 8080 to pod's port 80
kubectl port-forward my-first-pod 8080:80

Now you can access your web server at localhost:8080!

In the next section, we’ll wrap up what we’ve learned about pods and peek at what’s coming next in our Kubernetes journey.

Conclusion

Congratulations! You’ve just completed your journey through one of the most fundamental concepts in Kubernetes - pods. We’ve covered quite a bit of ground, from understanding what pods are to creating your very first one.

Let’s recap what we’ve learned:

• Pods are the smallest deployable units in Kubernetes, providing a shared environment for containers that need to work together
• Kubernetes manages pods through their lifecycle, from creation to termination, ensuring our applications stay healthy
• Pods can have different states (Running, Pending, Failed), and Kubernetes monitors their health through probes
• We can define exactly what we want our pods to look like using YAML files, including resource requirements and container specifications

But here’s something interesting - while pods are fundamental to Kubernetes, they’re rarely used on their own in production environments. Why? Because pods by themselves don’t provide some key features we need for running reliable applications, like:

• Automatically replacing pods that fail
• Scaling to handle more load
• Rolling updates to new versions

This is where ReplicaSets come in - our topic for the next article. ReplicaSets build upon everything we’ve learned about pods and add powerful management capabilities that make our applications more resilient and scalable.

Ready to take your Kubernetes journey to the next level? Join me in the next article where we’ll explore how ReplicaSets help us manage multiple pods and ensure our applications stay running reliably!