Svg Vector Icons : http://www.onlinewebfonts.com/icon Return to Glossary

What are Kubernetes Pods?

A pod is the smallest execution unit in Kubernetes. A pod encapsulates one or more applications. Pods are ephemeral by nature, if a pod (or the node it executes on) fails, Kubernetes can automatically create a new replica of that pod to continue operations. Pods include one or more containers (such as Docker containers).

vSphere with Kubernetes 101 - An Introduction for vSphere Administrators

Download Now





Pods also provide environmental dependencies, including persistent storage volumes (storage that is permanent and available to all pods in the cluster) and configuration data needed to run the container(s) within the pod.



What does a Pod do?

Pods represent the processes running on a cluster. By limiting pods to a single process, Kubernetes can report on the health of each process running in the cluster. Pods have:

  • a unique IP address (which allows them to communicate with each other)
  • persistent storage volumes (as required)
  • configuration information that determine how a container should run.

Although most pods contain a single container, many will have a few containers that work closely together to execute a desired function.



What are the benefits of a pod?

When pods contain multiple containers, communications, and data sharing between them is simplified. Since all containers in a pod share the same network namespace, they can locate each other and communicate via localhost. Pods can communicate with each other by using another pods IP address or by referencing a resource that resides in another pod.

Pods can include containers that run when the pod is started, say to perform initiation required before the application containers run. Additionally, pods simplify scalability, enabling replica pods to be created and shut down automatically based on changes in demand.



How does a pod work?

Pods are created by workload resources called controllers, which manage rollout, replication, and health of pods in the cluster. For example, if a node in the cluster fails, a controller detects that the pods on that node are unresponsive and creates replacement pod(s) on other nodes.

The three most common types of controllers are:

  • Jobs for batch-type jobs that are ephemeral, and will run a task to completion
  • Deployments for applications that are stateless and persistent, such as web servers (HPPT servers)
  • StatefulSets for applications that are both stateful and persistent such as databases


If a pod has multiple containers, they are all scheduled together on the same server in the cluster, whether VM or physical server. All containers in the pod share their resources and dependencies and can coordinate their execution and termination. For example, pods can contain ‘init’ containers that run before the application containers run, setting up the environment for the applications that follow.


Pods are almost always created by controllers which then can automatically manage the pod lifecycle, including replacing failed pods, replicating pods when necessary, and evicting the pod from cluster nodes when they are complete or no longer needed.


Controllers use information in a pod template to create the pods, and controllers ensure that running pods match the deployment defined in the pod template, for example by creating replicas to match the number defined in the deployment.



How do pods communicate with each other?

When a pod is created it is assigned its own unique IP address. If there are multiple containers within the pod, they can communicate between each other simply by using localhost. Communications outside of the pod is achieved by exposing a port. Communications between pods in a cluster takes advantage of the fact that Kubernetes assigns a cluster-private IP address to every pid in a cluster, eliminating the need to either explicitly create links between pods or to map container ports to host ports. In this way, every pod in a cluster can ‘see’ each other without the need for NAT.



What are the basic kubectl commands?

Kubectl provides a number of commands that allow a user to create pods, run them by using deployments, check on status of running pods, and halt pods that are no longer needed. Either JSON (JavaScript Object Notation) or YAML (YAML Ain’t Markup Language) commands are valid for encoding commands.

Commonly used kubectl commands are listed below:

Get

The kubectl get command will display tabular information on one or more resources. Information can be filtered using label selectors. Information can be displayed just from the existing namespace or for all namespaces in the cluster.

The command “kubectl api-resources” will produce a list of all supported resources about which you can ‘get’ information. The general format for the kubectl get command is:

$ kubectl get [(-o|--output=)json|yaml|wide|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...] (TYPE[.VERSION][.GROUP] [NAME | -l label] | TYPE[.VERSION][.GROUP]/NAME ...) [flags]


Create Pods

Pods are created using the create command in the format:

$ kubectl create -f FILENAME.

For example, the command:

kubectl create -f ./mypod.yaml will create a new pod from the YAML file “mypod”


Delete Pods

The command “kubectl delete -f ./mypod.yaml” will delete the pod “mypod” from the cluster. Deleting pods is a graceful process; pods will continue running for a grace period (default of 30 seconds) before being forcefully terminated. The grace period value can be overwritten with the –grace-period flag if desired.


Related Topics
Kubernetes
Containerization Strategy
Kubernetes Networking
Kubernetes Deployment
Kubernetes Architecture
Kubernetes Monitoring
Kubernetes Security
Kubernetes Cluster
Kubernetes Infrastructure
Kubernetes Namespace
Kubernetes Services


VMware Kubernetes Pods related products, solutions, and resources