Kubernetes Pods: How to Create and Manage Them

Kubernetes is an open-source container orchestration system mainly used for automated software deployment, management, and scaling. Kubernetes is also known as K8s. Kubernetes was originally developed by Google, but it is now being maintained by the Cloud Native Computing Foundation. It was originally designed to be interfaced with only the Docker runtime, but it now works with containers and CRI-O as well. The main purpose of Kubernetes is to automate the operational tasks of container management. It is included with built-in commands for the deployment of applications and rolling out the required changes in the application. It is currently being used by companies like Google, Spotify, and Capital One.

A pod is the smallest unit that exists in Kubernetes. It is similar to that of tokens in C or C++ languages. A specific pod can have one or more applications. The nature of pods is ephemeral, which means that in any case, if a pod fails, Kubernetes can and will automatically create a new replica or duplicate of the said pod and continue the operation. The pods have the capacity to include one or more containers based on the requirements. The containers can even be Docker containers. The pods in Kubernetes provide environmental dependencies, which include persistent storage volumes which means they are permanent and available to all pods in the cluster, and even configuration data that is required to run the container within the pod.

Pods in Kubernetes are like individual workers on a team. Each pod represents a specific task or process running in the cluster. They have their own unique address to communicate with other pods, storage space for saving data, and instructions on how to run their assigned job. While most pods have just one worker (container), some pods have a few workers that collaborate closely to get the job done efficiently.

Imagine controllers in Kubernetes as supervisors responsible for managing teams of workers called pods. These supervisors make sure that the right number of pods are running and handle tasks like hiring new workers (creating pods), replacing workers if they fail, and adjusting the team size as needed.

There are three main types of supervisors:

• Jobs: for one-time tasks like running a backup or processing data.
• Deployments: for always-available applications like websites or online stores.
• StatefulSets: for applications that need to remember things, like databases or file servers.

When a pod is created, it’s like hiring a new team member. The workers within the pod work together, sharing resources and getting their tasks done. For example, some pods may have special workers that set things up before the main workers start.

• Single Container Pod 
• Multi Container Pod 
• Static Pod 

A pod can be defined as the collection of containers and their storage inside a node of a Kubernetes cluster. There is a possibility of creating a pod with multiple containers inside them. 

Based on the number of pods present inside them, they can be classified as a Single Container Pod or Multi Container Pod. As the name suggests, a single container contains only one container, whereas a multi-container pod contains multiple containers. They can be used based on their function and use a case at the respective times. The methods of creation of both types of pods are different.  

In the following diagram, you can see cube-like structures; they are called containers Each of the containers will have one container. The cylinder-like structure is called volume, where the data of the containers will be stored and the circles are called pods. The pods are the smallest unit in a recognizable unit in Kubernetes; that is why Kubernetes will take care of the pods, and pods will take care of the containers.

A pod in a Kubernetes cluster indicates a process that is currently operating, and a pod may contain one or more containers. All of those containers share a single IP address, as well as the pod’s storage, network, and any other requirements. A pod is a collection of one or more running containers, allowing for simple container movement within a cluster. 

The creation of a pod is due to a workload resource called controller, which means rollout, replicate, and health of the pods present in a cluster. If we consider that a node in a cluster fails then a controller detects that the pod on the mode is unresponsive and then replicates a pod or pods on other nodes to carry out the same function. The three mostly used controllers used are Jobs, Deployments, and Stateful Sets. Jobs are used for batch-type jobs that are mostly ephemeral and will run a task to completion. Deployments are used for applications that are stateless and persistent, for example, web services. StatefulSets is used for applications that are both stateful and Persistent like a database. 

If any pod has any/multiple containers then all those are scheduled together on the same server in the cluster either a physical server or VM. All the containers present in the pods will share their resources and dependencies. All these clusters can coordinate their termination and execution.  For instance, if a pod contains an init container then it runs before the application container runs leveling or setting up the required environment for applications to follow.  Generally, pods are created by controllers that can automatically manage the pod lifecycle. The pod life cycle included replacing failed pods, replicating the pods when necessary, and eliminating the pod once the purpose was completed. Controllers use the information present in the pod templates to create the pods. 

Pod Operating System

The operating system (OS) running inside pods is typically determined by the container image used to create the pod’s containers. Pods in Kubernetes can run containers based on various Linux distributions, such as Ubuntu, Alpine Linux, or CentOS, among others. The choice of OS depends on the requirements of the application and the preferences of the container image author. If a container image is based on Ubuntu, the pod will run Ubuntu as its OS. Similarly, if the container image is based on Alpine Linux, the pod will run Alpine Linux.

Pods and controllers on Kubernetes

Pods are like the smallest building blocks in Kubernetes. They can hold one or more containers that work together. Think of them as a mini-environment where your application runs.

The pod will not be rescheduled to a different node when it expires because it is ephemeral (lasting only a very brief time). , we shouldn’t directly construct or use pods; instead, we should deploy pod-like deployment, replica sets, and daemon sets to maintain the pod with the aid of Kubernetes services. We have to deploy the pods with the help of objects. The main objects are

• Deployment.
• Replication Controller.
• Replica Set.
• DemonSet.

By using the below template we can create the pod in the Kubernetes cluster. Here is the pod template example.

Kubernetes Pod templates

Here is the sample pod template to create the nginx pod in the Kubernetes. Let’s create a YAML file for an example image (Nginx) so that it can be deployed as a container.

apiVersion: v1
Kind: pod 
metadata: 
  name: nginx
spec: 
  containers: 
  - name: nginx
    image: 
nginx:latest
    ports: 
    - containers: 80 

After creating the yaml file run the below command to deploy it as a container. 

kubectl apply -f <name of yaml file>

Kubernetes Pods Networking

Networking in Kubernetes will play a major role in Kubernetes where it will establish the communication between the two microservices like pods by which each of them can communicate with each other following are some if the networking concepts that are used in Kubernetes.

• Pod-to-pod communication: ClusterIP is the default service and its visibility is cluster internal which means it’s not possible to use clusterIP service to reach a micro-service from the internet from outside the cluster. You can establish the connection inside the cluster between two pods.
• Service Discovery: Kubernetes provides built-in DNS for service discovery. The particular service will assigned to a particular DNS based on their service names for example as shown below.

# Accessing a service from within a pod
curl http://example-service.default.svc.cluster.local

• Ingress: The Ingress controller will act as a load balancer to the Kubernetes cluster and also it will also manage the external access to services within the cluster. Following the sample yaml file for the ingress.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: <Name of the Ingress>
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /path
        pathType: Prefix
        backend:
          service:
            name: <Name Of The Service> 
            port:
              number: 80

The creation of a pod has made it easy for communication between various components. If a pod contains multiple containers then they can communicate with each other by using a local host. Communication with outside pods can be made by exposing a pod. Communication within the clusters of the same pod is easy because Kubernetes assigns a cluster private IP address to each pod in a cluster. 

In Kubernetes, updating and swapping out pods is like applying an additional application of create to your application.

• Updating Pods: It’s like making changes to your application while it’s still running. You can tweak settings or replace the code without interrupting service. Think of it as a smooth, rolling upgrade that keeps everything running smoothly.
• Pod Replacement: This happens when a pod needs to be swapped out entirely, maybe because it’s crashed or needs an update. Kubernetes automatically replaces it with a new one to keep your application running without missing a beat. It’s like changing a flat tire while your car is still moving, ensuring you keep going without any down

Static pods in Kubernetes are like manually starting a program on your computer. You create a configuration file with details about the program you want to run and place it in a specific folder (usually /etc/kubernetes/manifests), and then your computer automatically starts running it without needing any extra commands. Similarly, in Kubernetes, you create a configuration file for a pod, place it in a designated folder on a node, and Kubernetes automatically starts running that pod on that node without needing to go through the usual Kubernetes control mechanisms.

Think of pods with multiple containers in Kubernetes like a team of workers collaborating on a project. Each container is like a specialized worker with its own job to do, and they all work together within the same pod to accomplish a common goal. Sidecar containers are used for the enhancement of the main containers’ functionality and overall pod efficiency.

• Sidecar containers will help you to add more capabilities to the main containers like logging, monitoring, proxy services, or even data processing.
• Sidecar will manage processes like queuing, and database connections in the background.

Create Pod: A pod can be created by using the create command format.

$ kubectl create -f [FILENAME]

In the [FILENAME], you need to insert the required filename with which you want to create your file, and then a new pod with the name w3wiki will be created.

To Delete Kubernetes Pod: Delete the pod using the below command.,

$ kubectl delete -f FILENAME 

Here the pod named w3wiki will be deleted

To Get Kubernetes Pod: To see the number of pods available in the particular namespace can be seen using the below command.

Kubectl get pod <name> --namespace

Troubleshooting with kubectl

• kubectl get pods: Lists all pods in the current namespace.
• kubectl describe pod <pod-name>: Provides detailed information about a specific pod.
• kubectl logs <pod-name>: Retrieves the logs from a specific pod.

• If a pod contains many containers working towards a common goal then it is easy for them to communicate and share data among themselves. 
• We know that all the containers in a pod will have the same network namespace due to which they can locate each other and communicate with the help o localhost. 
• Pods can communicate with each other by using another pod’s IP address or even by referring to a resource that is located in another pod. 
• Any pod can even include containers that run when the pod is started mainly to run any operation before the application containers run. 
• The presence of pods has made it more Scalable as each pod and its replicas can be created and shut down automatically considering the changes in demand. 

Pods are fundamental unit blocks in the Kubernetes following are the some of the advanced concepts of Kubernetes.

• Init Containers: These are the containers which are used for setting up the environment for the actually application containers. This init container will be deployed in the Kubernetes so they will run one after the another this type of containers are specially designed for the proper functioning of the application containers.
• Sidecar Containers: Sidecar containers are used for the enhancement of the main containers functionality and overall pod efficiency.
  • Sidecar containers will helps you to add the more capabilities to the main containers like logging, monitoring, proxy services or even data processing.
  • Sidecar will manage the processes like queuing, database connections in the background.
• Resource Requests and Limits: You request the resources from the Kubernetes cluster for the pod by depending on the incoming traffic resource request like CPU and memory and so on.
• Liveness and Readiness Probes: Liveness and Readiness Probes are are very useful services in the Kubernetes cluster which are used for the monitoring the pods health as follows.
  • Liveness probes: Detects if the pod is alive if not it will restart the pods.
  • Readiness probes: Checks the pod is actually ready to serve the traffic.

A Pod represents the processes running on a cluster. If one pod is limited to a single process then it is possible to report and maintain the health of each process running within the cluster. Every Pod has some unique features like a Unique IP address, persistent storage volumes, and configuration information required to run the working. Mostly all the pods have a single container but many of them will have a few containers working closely together to execute a particular function or activity.

Kubernetes Pods Stuck In Terminating

You can troubleshoot by using following steps

1. Check for Running Processes: docker ps | grep <pod_id>
2. Inspect Containers: docker inspect <container_id>
3. Delete the Pod Forcefully: kubectl delete pod <pod_name> –grace-period=0 –force

After troubleshooting you can perform the task according to the problem.

Kubernetes Pods Commands

To know more Kubernetes pod commands refer to the kubernete cheat sheet.

Kubernetes Pods Crashloopbackoff

When a container within a Pod keeps crashing and restarting the Pod, it is said to be in the “CrashLoopBackOff” state in Kubernetes. When there is a problem preventing the container from operating correctly, this state is frequently seen in the pod’s status.

What is eks pod?

An EKS pod refers to a pod running within Amazon Elastic Kubernetes Service (EKS), Amazon’s managed Kubernetes service. It behaves like any other Kubernetes pod, encapsulating one or more containers, but it’s specifically managed within the EKS environment.

How many containers per pod?

Pod typically contains one or more containers that work together as a cohesive unit. While most pods have a single container, some may have multiple containers, such as sidecar containers for logging or monitoring purposes.