Kubernetes Book 4 - Working with Pods

From 탱이의 잡동사니
Revision as of 00:13, 9 January 2020 by Pchero (talk | contribs) (Created page with "== Pod theory == The atomic unit of scheduling in the virtualization world is the Virtual Machine(VM). This means deploying applications in the virtualization world means sche...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Pod theory

The atomic unit of scheduling in the virtualization world is the Virtual Machine(VM). This means deploying applications in the virtualization world means scheduling them on VMs.

In the Docker world, the atomic unit is the container. This means deploying applications on Docker means deploying them inside of containers.

In the Kubernetes world, the atomic unit is the Pod. Ergo, deploying application on Kubernetes means stamping them out in Pods.

This is fundamental to understanding Kubernetes. Virtualization does VMs, Docker does containers, and Kubernetes does Pods.

As Pods are the fundamental unit of deployment in Kubernetes, it's vital to understand how they work.

Pods vs containers

Digging a bit deeper, a Pod is a shared execution environment for one or more contrainers. Quite often it's on container per Pod, but multi-container Pods are gaining in popularity. One use-case for multi-container Pods is co-scheduling tightly-coupled workloads. For example, two containers that share memory wouldn't work if they were scheduled on different nodes in the cluster. Other increasingly common use-cases include logging and service meshes.