Pods in Kubernetes: Understanding the Building Blocks of Scalable Applications

Overview

A Kubernetes pod represents the smallest building block of a Kubernetes application, comprising one or more Linux® containers. Pods can either consist of a single container, which is a common scenario, or multiple tightly coupled containers in more advanced use cases. The grouping of containers into Kubernetes pods enhances resource sharing intelligence, promoting efficient operation within the Kubernetes ecosystem.

Types of pods in Kubernetes

Single-Container Pods: This is the usual way Kubernetes does things. It’s like having one container neatly wrapped up in a pod. Instead of juggling individual containers, you manage these pods, and each pod holds just one container. It keeps things organized.
Multi-Container Pods: Now, picture a special pod that can hold more than one container. These containers inside the pod work closely together, like a team with a common goal. For instance, one container might show information to the public, while another updates that info. This pod becomes a cozy home for a bunch of containers that collaborate. They share things like storage and a special network connection, forming a tight-knit unit. It’s like having a container family inside one pod.

Why does Kubernetes uses the concept of pods?

The connection between pods and clusters is the reason Kubernetes opts for running pods instead of individual containers. This approach ensures that each container within a pod shares the same resources and local network. By grouping containers in this manner, they can communicate with each other as if they’re on the same physical hardware, all while maintaining a certain level of isolation.

This arrangement, where containers are organized into pods, lays the foundation for one of Kubernetes’ notable features: replication. With containers snugly packed into pods, Kubernetes can utilize replication controllers to horizontally scale an application as necessary. In simple terms, if a single pod is handling too much, Kubernetes can effortlessly create duplicates and distribute them across the cluster. This not only supports smooth operation during high-demand periods but also provides a continuous replication of Kubernetes pods to bolster the system against failures.

Lifecycle of a Pods

In the world of Kubernetes, pods have a lifecycle that controllers manage based on their status. Think of controllers as the managers making sure everything is running smoothly.

Every Kubernetes pod has a status field where it tells everyone how it’s doing. This status is summed up in a cool thing called the “Phase” field, kind of like a summary of what’s happening with the pod right now.

Now, a pod can be in different states:

Pending: The pod is created, but one or more of its containers are not up and running yet. It’s like the pod is waiting for everyone to get ready.
Running: The pod is happily living on a node, and all its containers are doing their thing—either created, running, or restarting. It’s like a smooth operation.
Succeeded: All the containers in the pod have finished their tasks perfectly. Once done, the pod won’t restart; it’s like a job well done.
Failed: Uh-oh. One of the containers in the pod didn’t finish its job or is refusing to leave. All the good pods should give a zero status after finishing. Anything else is a bit of a failure.
Unknown: Sometimes, the controller is scratching its head, and it can’t figure out what’s going on with the pod. It’s like a little mystery.

Additionally, the PodStatus has something called PodConditions. These are like additional details showing why the pod is in its current state. It has:

Type: This can be about scheduling, readiness, initialization, or being unschedulable.
Status: This tells if everything is good (True), bad (False), or the controller is not sure (Unknown).

Working with Pods in Kubernetes

You can manage a pod using imperative or declarative approach. In imperative approach you use kubectl command to manage the pod while declarative approach uses YAML or JSON manifest files.

Creating a pod imperative way:

root@k8:~# kubectl run nginx --image=nginx -l app=server
pod/nginx created

The above command will create a pod named nginx using the nginx image and label it app: server. You can run kubectl get pods command to see if the pod is created or not.

root@k8:~# kubectl get pods
NAME               READY   STATUS    RESTARTS   AGE
nginx              1/1     Running   0          102s

To get more details about the pod like the pod IP address and on which node the pod has been scheduled on you can use the -o wide flag as shown in below example

root@k8:~# kubectl get pods -o wide
NAME               READY   STATUS    RESTARTS   AGE     IP             NODE             NOMINATED NODE   READINESS GATES
nginx              1/1     Running   0          3m29s   10.244.0.214   default-xjlt9    <none>           <none>

You can use the kubectl describe pod <pod-name>command to see more details about the pod, its state and recent events. You will get an output similar to below:

Creating a pod declarative way:

You can use your favourite text editor to create a yaml file as below:

vim nginx.yaml

You can then add below code to the yaml file

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: server
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx

apiVersion: v1: Indicates the API version being used. In this case, it’s using the v1 version of the Kubernetes API.
kind: Pod: Specifies the type of Kubernetes resource being defined, which is a Pod in this instance.
metadata:: Contains metadata about the Pod, such as labels and the name.
- labels:: Assigns a label to the Pod. In this case, the label “app” is set to “server.”
- name: nginx: Specifies the name of the Pod as “nginx.”
spec:: Describes the desired state of the Pod.
- containers:: Defines the containers running within the Pod.
  - image: nginx: Specifies the container image to be used, in this case, “nginx.”
  - name: nginx: Assigns a name to the container, also “nginx” in this case.

This configuration, when applied to a Kubernetes cluster using kubectl apply -f nginx.yaml, instructs Kubernetes to create a Pod named “nginx” running an Nginx web server. The Pod is labeled with “app: server.” The container within the Pod uses the Nginx image and is named “nginx.”

Conclusion

This article provided a comprehensive overview of Kubernetes pods for beginner users of this popular orchestration platform. After reading the article, you should know what pods are, how they work, and how they are managed.

FAQ

1. What is a Pod, and why are Pods essential in Kubernetes?

A: A Pod is the smallest deployable unit in Kubernetes, representing one or more containers closely coupled and sharing resources. Pods are fundamental for application deployment and scaling.

2. How do Pods facilitate communication between containers?

A: Pods share the same network namespace, allowing containers within a Pod to communicate over localhost. This simplifies coordination and data exchange.

3. Can I run multiple copies of the same Pod for scalability?

A: Yes, Kubernetes allows you to replicate Pods using controllers like Deployments. Each replica ensures consistent and scalable application performance.

4. How do Pods contribute to application resilience in Kubernetes?

A: Pods are designed for reliability. If a Pod fails, Kubernetes automatically restarts it or creates a new one, contributing to the overall resilience of your application.

5. What’s the difference between a Pod and a Deployment in Kubernetes?

A: A Pod is the basic unit, while a Deployment is a higher-level abstraction managing multiple Pods. Deployments offer features like rolling updates and rollbacks for more control.