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.

2. 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.

3. 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 <FILENAME>

For example, to create a Pod named AskTech:


kubectl create -f asktech-pod.yaml

Delete a Pod


kubectl delete -f <FILENAME>

This deletes the Pod defined in the file.

Get Pods


kubectl get pod <pod-name> --namespace <namespace>

Lists Pods within a specified namespace.

Troubleshooting with kubectl

kubectl get pods → List all Pods in the current namespace.
kubectl describe pod <pod-name> → Get detailed Pod info.
kubectl logs <pod-name> → 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.

Search This Blog

AskTech