Kubernetes Pods: How to Create and Manage Them

A Pod represents a single instance of a running process in your Kubernetes cluster and can contain one or more containers. Think of a Pod as a lightweight, application-specific logical host. All containers within a Pod are co-located on the same worker node and share the same execution environment.

This shared context is what makes Pods special, and it includes:

Shared Networking
Each Pod gets a unique IP address. All containers within that Pod share this IP and port space, allowing them to communicate with each other over localhost.

Shared Storage
Containers in a Pod can share storage volumes, providing a common filesystem for data exchange and persistence.

The Pod Lifecycle
A Pod progresses through several lifecycle phases:

Pending: The Pod has been accepted by the Kubernetes system, but one or more container images have not yet been created. This could be due to image download delays or the scheduler finding a suitable node.

Running: The Pod is bound to a node, and all containers are created. At least one container is running or is in the process of starting or restarting.

Succeeded: All containers have terminated successfully (exit status 0) and will not restart. This phase is typical for batch jobs.

Failed: All containers have terminated, and at least one container failed (non-zero exit code).

Unknown: The Pod state cannot be determined—often due to a network issue with the node.

Kubernetes Pods Overview
In Kubernetes, Pods are represented as circles in diagrams, with cube-like structures as containers and cylinder-like structures as shared volumes.

A Pod can contain one or more containers, all sharing:

The same IP address

Storage volumes

Network resources

Other required configurations

Pods make it easier to move containers around the cluster. They are managed by controllers, which handle:

Rollouts: Deploying new versions of Pods

Replication: Maintaining the desired number of Pods

Health monitoring: Restarting or replacing failed Pods

If a node fails, Kubernetes controllers automatically recreate the affected Pods on another node to maintain availability.

Common Controllers
Jobs → For batch tasks that run once and complete (ephemeral workloads).

Deployments → For stateless or persistent apps (like web services).

StatefulSets → For stateful, persistent apps (like databases).

Pod Operating System
The operating system inside a Pod depends on the container image it uses. For example:

An Ubuntu-based image → Ubuntu OS inside the Pod

An Alpine Linux image → Alpine Linux OS inside the Pod

The choice of base image depends on the application’s requirements and the developer’s preference.

Pods and Controllers
Pods are ephemeral — they don’t get rescheduled once they expire. Therefore, we generally don’t create Pods directly. Instead, we use higher-level objects that manage Pods automatically, such as:

Deployments

Replication Controllers

ReplicaSets

These controllers maintain Pod replicas and ensure high availability.

Getting Started with Kubernetes Pods

1. Create a Pod Imperatively A quick way to test your cluster setup is by creating a simple Nginx Pod:

kubectl run nginx --image=nginx
This command creates a Pod named nginx using the official Nginx image.

1. Generate a Declarative Manifest Instead of writing YAML manually, you can generate it using kubectl:

kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml
The --dry-run=client -o yaml flags generate YAML output without actually creating the Pod.

Your pod.yaml will look like this:

apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx
name: nginx
spec:
containers:

• image: nginx name: nginx resources: {} dnsPolicy: ClusterFirst restartPolicy: Always status: {} Key Fields:

apiVersion: API version (e.g., v1)

kind: Type of object (Pod)

metadata: Object identifiers such as name and labels

spec: Desired configuration — containers, images, ports, etc.

1. Create a Pod Declaratively First, delete the Pod created imperatively:

kubectl delete pod nginx
Now, create it from the YAML manifest:

kubectl apply -f pod.yaml
Running kubectl apply again after modifying the YAML intelligently updates the Pod to match the new desired state.

Inspecting and Interacting with Your Pod
Get Pod Status
kubectl get pods
Example output:

NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 60s
Describe the Pod
For detailed status, events, and configuration:

kubectl describe pod nginx
View Container Logs
kubectl logs nginx
Execute Commands Inside a Container
To open an interactive shell inside the container:

kubectl exec -it nginx -- bash
Once inside, use standard Linux commands (ls, cat, ps, etc.) to inspect the container.

Advanced Patterns: Multi-Container Pods
Pods can include multiple containers that work closely together. Two common design patterns are:

Init Containers
Init Containers run before the main application containers and must complete successfully before the main app starts.

Use Cases:

Waiting for a dependent service (e.g., database)

Running setup or migration scripts

Cloning a Git repository into a shared volume

Registering the Pod with a central service

Sidecar Containers
Sidecars run alongside the main application containers throughout the Pod’s lifecycle. They extend or enhance the main app’s functionality.

Use Cases:

Logging: Collect and forward logs

Monitoring: Gather metrics for Prometheus

Service Mesh Proxy: Handle traffic via Istio or Linkerd

Data Sync: Sync files from S3 or Git

Pod Communication
Internal Communication
Containers in the same Pod communicate via localhost.

Inter-Pod Communication
Pods within the same cluster communicate using cluster-private IPs assigned by Kubernetes networking.

If external access is required, you can expose a Pod using a Service.

Updating and Replacing Pods
Kubernetes manages Pod updates gracefully:

Updating Pods: Makes configuration or image changes while keeping services running (rolling updates).

Pod Replacement: When a Pod crashes or is terminated, Kubernetes automatically recreates a new Pod instance — ensuring continuous availability.

Static Pods
Static Pods are created directly by the kubelet on a node — not by the Kubernetes control plane.

You define them by placing a Pod manifest file in /etc/kubernetes/manifests/. The kubelet automatically starts and monitors the Pod on that node.

Static Pods are commonly used for control plane components like kube-apiserver, kube-scheduler, and etcd.

Basic Kubectl Commands for Kubernetes Pods
Create a Pod
kubectl create -f
For example, to create a Pod named AskTech:

kubectl create -f asktech-pod.yaml
Delete a Pod
kubectl delete -f
This deletes the Pod defined in the file.

Get Pods
kubectl get pod --namespace
Lists Pods within a specified namespace.

Troubleshooting with kubectl
kubectl get pods → List all Pods in the current namespace.

kubectl describe pod → Get detailed Pod info.

kubectl logs → Retrieve logs from a specific Pod.

✅ In Summary:
Kubernetes Pods are the fundamental execution unit in your cluster, enabling efficient container orchestration, networking, and storage sharing. While you can create Pods manually, managing them via higher-level controllers like Deployments or StatefulSets ensures reliability, scalability, and resilience for your workloads.