Pods

Kubernetes uses Pods as its basic, atomic unit for Deployment and scaling, and represents processes running in the cluster – an analogy from Microsoft Hyper-V would be a single virtual machine that you deploy as an atomic unit in your Hyper-V cluster. A Kubernetes Pod consists of one or more containers that share kernel namespaces, IPC, network stack (you address them by the same cluster IP and they can communicate via localhost), and storage. To understand Pods, it is good to know the origin of the name: in the English language, a pod is a group of whales, and Docker uses a whale for its logo – think of a whale as a Docker container!

In their simplest form, you can create single-container Pods – this is what we did in the introduction to this section when demonstrating nginx Pod creation. For some scenarios, you may need multiple-container Pods, where the main container is accompanied by additional containers that serve multiple purposes. Let's take a look at a few of these:

• Sidecar containers, which can perform various helper operations, such as log collection, data synchronization for the main container, and so on.
• Adapter containers, which can normalize output or monitor the data of the main container so that it can be used by other services.
• Ambassador containers, which proxy the communication of the main container with the outside world.
• Init containers, which are specialized containers that run before application containers in the Pod. For example, they may set up the environment, which isn't performed in the main container image. 

The concept of a Pod can be seen in the following diagram:

There are a couple of considerations that you should keep in mind when using Pods:

• Pod's containers always run on one node and once a Pod is created, it is always bound to one node.
• You scale your application by adding more Pods, not by adding more containers inside the same Pod.
• A Pod is considered ready and able to serve requests when all its containers are ready. The status of a container is determined by Probes, for example, liveness and readiness Probes, which can be defined in the Spec.
• Pods are ephemeral. They are created, they die, and new ones are recreated in their place (if needed).
• When a Pod is recreated, it receives a new cluster IP. This means that your application design should never rely on static IP assignments and assume that the Pod may even be recreated on a different node.

Pods have a finite life cycle and if the containers inside crash or exit, they may not be automatically recreated, depending on the restart policy. To maintain a desired number of Pods with a certain Spec and metadata in the cluster, you need ReplicaSet objects.