What is a Kubernetes pod? Lifecycle Explanation

What Is a Kubernetes Pod?

A Pod is a term that we use to denote a single and independent instance that a functional Kubernetes cluster features. It’s the smallest viable object of the Kubernetes ecosystem. 

On a broader plane, Pod can be explained as: 

• A self-contained entity 
• A k8s element essential for running a single instance.
• An Isolated local host featuring specific basics that the corresponding app demands 

‍

Terminology 

Containers

A Pod may comprise just one or various containers in it. Often, Docker containers are present in a Pod. Upon Pod’s activation, it executes various containers, which then are collected and managed as a unified entity.

Resources 

Whatever resources Pod has, its related containers will them in a shared manner. Mostly, a Pod features one container only. But, the advanced use cases often demand the execution of various containers in a single Pod.

To maintain the full functionality of inherited containers, k8s Pods carry shared storage and networking resources.

As far as networking resources are concerned, Pods will feature purely distinct IP addresses that are automatically assigned. All containers share identical network ports, IPs & namespace. 

The included containers use localhost to interact mutually. For this, k8s Pods will define a storage volume that will be shared by these containers – depending upon their requirement.

SSH in k8s

As you’re trying to understand Pod’s significance, you must be aware of the role of SSH in Kubernetes Pod. Using SSH is an easy way to keep Pods secured in a public and private cloud. SocketXP is the authorized tool for the use of SSH in k8s Pods. 

Nodes

They are where Pods run inside a cluster. Pods show great loyalty to the respective nodes as they remain on the nodes as long as the process continues. It leaves the node only when it’s deleted. 

Often lack of resources or node failure can also cause the detachment of Pod from the nodes. Pods are not dependent on nodes. Therefore, any node failure will lead to automatic Pods deletion. 

Variables

Kubernetes Pod environment variables are the ones declared in the configuration (check the section on creating pods in the article by scrolling down. 

‍

What Does a Pod Do?

After having basic clarity on Pod meaning, it’s time to understand what it does. The controller creates Pods and uses them for multiple purposes. For instance:

• When a cluster node fails, the controller tracks the unresponsive Pods and uses this information to generate replacement Pods that will be deployed on functional nodes to maintain continuity in the workload.
• Resources are shared for multi-container spec. Such Pods will feature ‘init’ containers that come into action before the application's containers and set up an ideal ecosystem for the application.
• The controller might extract information from a Pod template and use it to generate further Pods.
• Pods feature information like unique IP addresses, storage volumes, and configuration information that is important to determine the course of action of the corresponding container. 

‍

Types Of k8s Pod 

1. Single-container 

This is the simplest pod type as it features only one container per pod. It is often used for workloads deployments. Its generation is easy and requires only a kubectl command. Here is an example:

apiVersion: v1
kind: Pod
metadata:
 name: Tomcat
spec:
 containers:
 - name: Tomcat
 image: tomcat: 8.0
 ports:
containerPort: 7500
 imagePullPolicy: Always

‍

2. Multi-container 

As clear from its name, this pod variety features more than one container per pod. This variety is mostly used when one tends to deploy the primary container with the secondary container. The role of the primary container is application hosting, while the secondary container will handle various ancillary functions like monitoring and log aggregation.

As more than one container is used, handling multi-container pods is tough. Every independent Pods are capable of interacting with each other. Here is an example generated using Kubernetes Pod YAML. 

apiVersion: v1
kind: Pod
metadata:
 name: Tomcat
spec:
 containers:
 - name: Tomcat
 image: tomcat: 8.0
 ports:
containerPort: 7500
 imagePullPolicy: Always
 -name: Database
 Image: mongoDB
 Ports:
containerPort: 7501
 imagePullPolicy: Always

Why Do Kubernetes Use Pod?

Kubernetes uses Pods mainly for workload deployments. Based on the type of pods used, different functions are handled. For instance, static Pods help k8s to run a self-host control plane.  

Multi-container Pods create a unified way to handle all the included containers. Every Pod is responsible for proceeding with single instances of a specific application, and the k8s setup uses them to scale an application horizontally.  

‍

Pod Lifecycle

Pods are short-lived and tend to get deleted/eliminated/non-functional for multiple reasons. As a Pod gets terminated, its existence will be completely wiped out. Pods remain functional until users or the controller deletes them.

Any damage to Pods is not self-healed. Controller intervention is required. The entire lifecycle of Pod is dependent on the nodes. If nodes fail or delete, attached Pods will also be deleted or failed. PodStatus API object is the part of every Pod and is represented using the status field of the Pod. This field also features Pod phase details which is a detailed summary of the present state of a Pod.

Throughout its lifecycle, a Pod is likely to be present in any of the below-mentioned phases.

• Pending phase

In this phase, a Pod is fully created and is introduced to the cluster, but is not fully processed as one or many of its corresponding containers are not under process. Also, the time that Pod spends on an active node and image download is referred to as a pending phase.

• Running phase

A Pod is said to be in the running phase when it’s linked to a node, and all the containers are active.

• Succeeded phase

When all the Pod containers are successfully terminated, it’s known as a succeeded phase.

• Failed phase

This phase arrives upon the successful termination of containers of a pod, where one/multiple containers are terminated during a node failure.

• Unknown  

When there is no clarity on where and what a Pod is doing, it is said to be present in an unknown phase.

‍

Creating Pods

As one tries to understand the basic meaning of Pod in Kubernetes, it’s essential to know that generating separate Pods is not at all recommended. In fact, it’s recommended to generate multiple sets of matching Pods that we know as replicas.

Management, which includes Pods’ lifecycle, modifying the number of Pods, and horizontal scaling, of such Pods, is done using a controller. Even if you need to contact Pods for debugging, inspection, and troubleshooting, you must use only the controller.

Now, you can open file in Kubernetes Pod to create it through YAML, or run a CLI command to achieve the same. If using a YAML configuration, the syntax will be:

apiVersion: v1
kind: Pod
metadata:
…
…
…
spec:
…
…
…

On the contrary, the syntax for the command for pod creation is:

kubectl run pod_name --image name_of_image:tag

‍

Pod Requests

Every Pod will demand certain CPU storage or memory to remain functional. As soon as a Pod starts running, a Pod request is made to ask this. With this request, Pod instructs Kubernetes that it requires a proper space on a node to process the workload.

Unanswered or responded Pod request means Pod failure, as it signifies that the node doesn’t have enough space to host the Pod. While you define Pod requests, adhere to these facts.

• In the absence of any default CPU request, Pod will be allotted to a node that lacks enough CPU.
• Pods featuring no default memory request will be attacked by nodes lacking sufficient memory.
• A small value of Pod requests will direct too many Pods on a single node, which eventually leads to degraded node performance.
• A large Pod request will leave a Pod unschedulable, which will later lead to cluster resources wastage

Pod Limits

As mentioned above, Pods run on nodes. With Pod limits, we refer to the CPU space or memory that a Pod can consume while running on nodes. In general, there are no limits imposed. But, for effective space distribution, you’re advised to set Pod limits.

Along with Pod limits, you can limit the container count for a single Pod. When only container limits are imposed, Pod limits can be calculated by adding all the container limits. If both Pod and container limits are imposed, please be advised that the total sum of container limits should not be more than the Pod limit.

Delete A Pod

If you are no longer a Pod and want to get rid of it, use the command $ kubectl delete pods < pod-name > and its existence will be fully wiped out.

If you’re using shared or replica Pods, make sure you delete that replica Pod first.

‍

K8s Pod Vs Container

As explained previously, containers reside within Pods, and a Pod can carry single or many containers. 

A container is a very functional entity that supports app development in k8s by providing a collection of applications and execution ecosystems.  At the very fundamental level, containers feature networking and storage configuration that Kubernetes uses when a Pod runs.  

A Pod is a self-sustaining higher construct, while a container is a self-contained lower construct. Pods can create containers, but the vice-verse is not true. The container can’t run directly. It requires Pod to carry it inside a workload.

On the contrary, a Pod is an independent unit and can run directly on a node. You can consider the container as part of a large shipment, Pod, that will not reach its destination if it gets disintegrated from that large shipment.

‍

Kubernetes Node Vs Pod

Kubernetes is entirely based on containers, Pods, and nodes. As we just explained container v/s Pods, let’s switch to nodes v/s Pods. Well, if Pods are the shipment, nodes are the shipping partner that carries shipments.  

A node is an element in a typical k8s cluster, which could be a physical/virtual machine. The role of a node is to provide a running mean for Pods.

Each Pod will ask for a specific memory on the node. A node exists to supply an ideal hosting ecosystem for the applications, while Pods are crucial for application defining and deployment.

Pods are crucial for Kubernetes workloads, while nodes are important for Kubernetes infrastructure. Nodes are required to host Pods, but nodes are not dependent on Pods.

‍

Conclusion

The Pod is important for Kubernetes as it leads to seamless workload deployment. The post explained this entity in detail. Some of the key insights that we gained in this post are:

• Pods are the tiniest executable k8s entity
• It features containers and needs nodes to run  
• It can feature one or more containers
• Defining Pods limits and restrictions ensures proper usage of Pods  

As you use Kubernetes, having insights on Pods and their processing is important.