Pods vs Containers: What Are the Differences?

For those new to Kubernetes, the sheer amount of terms you need to know can be intimidating. Many people hit a roadblock in understanding the difference between pods and containers. Understanding the key differences between the two — and how Kubernetes pods and containers interact with each other — can help you become more comfortable with K8s, meaning you're one step closer to leveraging all the benefits of kube. 

Ready to Learn Kubernetes?

Kubernetes can make your life easier — especially if you’re a network administrator or engineer. If you’re ready to learn how to leverage this powerful and versatile platform, an online training course can teach you the skills you need to know. 

CBT Nuggets trainer Trevor Sullivan has created a variety of Kubernetes courses that are designed to get you up and running with Kubernetes. Start your free trial today and explore Kubernetes!

What is a Kubernetes Pod?

A pod is the fundamental building block of Kubernetes. Remember, the core purpose of Kubernetes is to manage containerized applications. As a web application grows, more containers are required to run it. Thus, the need for Kubernetes. These containerized applications need a place to reside — and that place is in a pod.

In order for a pod to be created successfully, it needs to have the following instructions: an apiVersion, a kind (i.e, the type of service it is), metadata, and a list of containers it will manage. That declarative code to create a Pod looks like this:

apiVersion:v1

kind:Pod

metadata:

  name:my-pod 

spec:

  containers:

  - name:busybox

    image:busybox:latest ##This is the container.

restartPolicy:never

The imperative code looks like this: kuectl run my-pod —image=busybox:latest —restart=Never

These two pieces of code do the same thing. However, for complex pod requirements, you will probably want to create it using a YAML file as in the former example. This is by far the simplest example of pod creation. It is important to know that pods are ephemeral. That means once they are created, they can’t be edited. Instead, the pod is killed and restarted with the new configurations.

The essential difference between a pod and a container is that a container resides inside of a pod. Now, let’s delve a bit into what a container actually is.

What is a Container in Kubernetes?

A container is that actual application (or piece of application) that you wish to run in Kubernetes. It could be a database, a web application, or a backend service. It can be anything, but it must be a Docker container. Other containerization software can be used, but for all practical purposes, they are Docker containers.

RELATED: Is It Hard to Learn Kubernetes?

What is a Docker Image?

All containers are pulled from images. In the Docker world, think of an image like a Java class. It is a set of instructions on how that container should be created. So in a Kubernetes pod, we are just providing instructions that say, “Hey, create a container based on the image I provided.” The image is being pulled from the Docker registry.

So we know that a pod holds a container, and a container is an image of the particular application we want to run. Now, let’s discuss what a Pod does beyond that.

How Do Pods Manage Containers?

Pods let you manage the entire lifecycle of your containerized application. Kubernetes is amazing in this respect because it provides a single place to configure an application’s resources, replicas, ports, and more. Here is an example of assigning CPU to a container:

apiVersion: v1

kind: Pod

metadata:

  name: my-web-app-pod

spec:

  containers:

  - name: my-web-app-container

    image: nginx:latest

    resources:

      limits:

        cpu: “1"

memory: “200Mi"

      requests:

        cpu: “0.5”

        memory: “100Mi"

In the example above, we are assigning CPU and memory allocation to a container. In other words, the pod is managing how many resources the application can consume. 

If we were not using Kubernetes, it is very possible this application could take up 100% of the CPU or memory and crash the server — but Kubernetes is doing its job. It is managing the application by assigning the desired amount of resources, along with an upper bound. 

This is just the tip of the iceberg with regards to how a pod manages a container. A pod can also provide command line arguments for an image to execute upon startup. A pod can also provide security context to a container. For example, a pod can tell the container, “When you finally start up, only run as User 2000, and don’t let the user gain root access!” That would look something like this:

apiVersion:v1

kind:Pod

metadata:

  name:my-web-app-pod

spec:

  containers:

  - name:my-web-app-container

    image:nginx:latest

    securityContext:

      runAsUser:2000

      allowPrivilegeEscalation:false

Final Thoughts

There's a lot of ground to cover when you're learning Kubernetes. But for pods and containers, the key takeaway is this: A pod’s whole reason for existing is to manage a container (or containers) within it. That is the key difference between a pod and a container. 

A pod is able to manage a container in several ways. In this article, we discussed applying security and requesting resources. Hopefully, this has helped in understanding what a pod is and where it fits in the broader Kubernetes context.