Kubernetes Pods are the smallest deployable computing units in the open source Kubernetes container scheduling and orchestration environment.
A Pod is a grouping of one or more containers that operate together. Pods reside on Nodes; more than one Pod can share the same Node. The containers within each Pod share common networking and storage resources from that host Node, as well as specifications that determine how the containers run. Pod is an illustrative name, as they are designed to function like pods in nature, such as a pea pod. While a Pod can encapsulate many containers, typically each Pod is home to only one container, or a small number of tightly integrated containers.
The contents of a Pod are scheduled and located together, modeling an application-specific logical host. A Kubernetes user should host together tightly integrated application containers in a Pod; without containers, these applications or services would have to run on the same virtual or physical machine.Content Continues Below
The shared context of a Pod is set by facets of isolation, such as Linux namespaces or cgroups. For an individual Pod, single applications can be further isolated.
The operator can expose information about the Pod, Node and/or containers by using environment variables. Pod environment variables tell the application in the Pod's container(s) where to find resources that it needs, or how to configure a component. This information is injected into the container at runtime. While Nodes also contain environment variables, these are not exposed to the containers. Kubernetes environment variables are statically defined or written by the user.
Kubernetes Pod management
Kubernetes supports the Docker container runtime as well as CoreOS rkt and CRI-O, which stands for Kubelet Container Runtime Interface using runtimes conformant with the Open Container Initiative.
The user can create Pods, but more often the Kubernetes Controller makes Pods and replicas thereof for high availability or horizontal scaling. When the user requests, for example, three new instances of a Pod, Kubernetes creates three Pods as API-level resources. The scheduler finds the appropriate Node for each Pod based on the Kubernetes user's policies, and places the Pod there.
Containers within a Pod share a common IP address and port space. They can discover each other through localhost. Applications assigned to the same Pod access shared volumes, which are attached to the Pod.
Pods also enable containers to communicate using other standard communications such as POSIX shared memory or SystemV semaphores. Containers in one Pod have different IP addresses from containers in the other, and are unable to use the IPC protocol. However, Kubernetes Pod to Pod communication occurs easily via services. For example, if a front end of an application resides in a Pod on one Node, the back end can reside on the same Node, on a different node, in 10 instances spread across various Nodes, and the front-end Pod simply connects to a service that represents the back-end Pod or Pods.
How Pods are used
In the Kubernetes environment, Pods are generally ephemeral along with application containers. Users design a Pod; assign it unique identification and resource requirements; and allow the system to schedule it to an appropriate Node, perhaps with settings around quality of service. The Pod uses that Node until the session is terminated or the Pod is deleted.
When a Node shuts down, Pods attached to it are scheduled for deletion, following a timeout period. An individual Pod, marked by a unique identifier, will not be rescheduled to a new Node; it can be copied and replaced with an identical Pod. The user can recycle the same name and ID for the new Pod. The Kubernetes roadmap includes work on a high-level API to migrate Pods, which would eliminate this issue.