Kubernetes Pods: an Introduction

In this article, I’m going to explain Kubernetes pods, use cases, and lifecycle, as well as how to use pods to deploy an application.

This post assumes you understand the purpose of Kubernetes and you have minikube and kubectl installed.

(This article is part of our Kubernetes Guide. Use the right-hand menu to navigate.)

What is a K8s pod?

Of object models in Kubernetes, the pod is the smallest building block. Within a cluster, a pod represents a process that’s running. The inside of a pod can have one or more containers. Those within a single pod share:

• A unique network IP
• Network
• Storage
• Any additional specifications you’ve applied to the pod

Another way to think of a pod—a “logical host” that is specific to your application and holds one or more tightly-coupled containers. For example, say we have an app-container and a logging-container in a pod. The only job of the logging-container is to pull logs from the app-container. Locating your containers in a pod eliminates extra communication setup because they are co-located, so everything is local and they share all the resources. This is the same thing as execution on the same physical server in a pre-container world.

There are other things to do with pods, of course. You might have an init container that initializes a second container. Once the second container is up and serving, the first container stops—its job is done.

Pod model types

There are two model types of pod you can create:

• One-container-per-pod. This model is the most popular. The post is the “wrapper” for a single container. Since pod is the smallest object that K8S recognizes, it manages the pods instead of directly managing the containers.
• Multi-container-pod. In this model, a pod can hold multiple co-located containers that are tightly coupled to share resources. These containers work as a single, cohesive unit of service. The pod then wraps these multi containers with storage resources into a single unit. Example use cases include sidecars, proxies, logging.

Each pod runs a single instance of your application. If you need to scale the app horizontally (such as running several replicas), you can use a pod per instance. This is different from running multiple containers of the same app within a single pod.

It is worth mentioning that pods are not intended as durable entities. If a node fails or if you’re maintaining nodes, the pods won’t survive. To solve this issue, K8S has controllers—typically, a pod can be created with a type of controller.