Pods are where our applications run. It’s the basic building block and the atomic unit of scheduling in Kubernetes. Each pod will include one or more containers and every time we run a container in Kubernetes, it will be inside a pod.

Overview of Pods

Pods are the atomic unit of scheduling

It is important to understand that a pod is the atomic unit of scheduling in Kubernetes. So if we want to run, say, 10 replicas of our application, we would create 10 pods instead of creating one pod with 10 containers. We will see more examples of that in practice when we start talking about deployments.

Pods' scheduling

If you remember from a previous example, we had a manifest file like this:

12345678

apiVersion: v1

kind: Pod

metadata:

name: nginx

spec:

containers:

- name: nginx-container

image: nginx

Code for our example yaml file

You will notice that we have a kind key saying that this manifest is defining a Pod. Then we have the metadata where we define a unique name for this pod (nginx), and a spec section where we define what we want to run in this pod. In our case, we are running a container called nginx-container, and saying that the docker image used for this container is called nginx.

Most manifest files will follow a similar format. There are several other keys that can be defined, but this is the minimum we need to have a running pod.

Where does the image come from?

In this manifest, we are defining nginx as the docker image name to run, but we never tell Kubernetes where it should look for this image.

The same way we can store code repositories in services like Github or Gitlab, we can store images in a docker registry. When we don’t specify which registry we want to use, Kubernetes will assume we mean DockerHub.

If we want to be more explicit, we can change our manifest to use the full image path:

12345678