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).
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.
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.
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.
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.
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.
Commonly used kubectl commands are listed below:
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]
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”
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.