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.

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.