In this lesson, you will learn why the Pod is the fundamental building block of Kubernetes and how it serves as the smallest unit for deploying your applications.
The Pod as a Wrapper
In the world of Docker, you likely think of a container as the primary unit of deployment. In Kubernetes, however, we use the Pod abstraction. A Pod is essentially a thin wrapper around one or more containers. Think of a Pod as a "logical host" that provides a shared environment for your application components.
Why bundle containers together?
While most Pods contain a single container, Kubernetes allows you to run multiple containers inside a single Pod if they are "tightly coupled." These containers share the same network namespace, meaning they can communicate via localhost and share the same IP address and port space. They can also share storage volumes, allowing them to read and write to the same files.
This is useful for sidecar patterns—for example, a primary application container and a "log shipper" container that reads files from a shared volume to send logs to a central server.
Defining a Pod
To define a Pod, we use a declarative YAML file. Even though you might define the image and the port, Kubernetes handles the lifecycle of the entire Pod as a single atomic unit:
apiVersion: v1
kind: Pod
metadata:
name: my-web-app
spec:
containers:
- name: main-app
image: nginx:latest
ports:
- containerPort: 80
By encapsulating containers within a Pod, Kubernetes ensures that everything inside the Pod is scheduled on the same node, starts together, and dies together. It abstracts away the complexity of managing individual container lifecycles, allowing the Kubernetes control plane to manage the Pod as the desired state of your application.
Key Takeaway: A Pod is the smallest deployable unit in Kubernetes, acting as a shared execution environment that encapsulates one or more tightly coupled containers that share network and storage resources.