Understanding Pods

Introduction

A Pod is the smallest and most basic deployable object in Kubernetes. A Pod represents a single instance of a running process in your cluster.

Pods vs Containers

Kubernetes does not run containers directly; it runs Pods. A Pod encapsulates one or more containers (such as Docker containers), storage resources, a unique network IP, and options that govern how the container(s) should run.

In the vast majority of use cases, the "one-container-per-Pod" model is the most common Kubernetes use case; you can think of a Pod as a wrapper around a single container.

Multi-Container Pods

Sometimes, you need multiple containers to run together in the same Pod. These containers share the exact same network namespace (meaning they can communicate via localhost) and can share storage volumes.

A common pattern for multi-container pods is the Sidecar Pattern. For example, your primary web server container runs alongside a "sidecar" logging container that reads the web server's logs and ships them to a central database.

Creating a Pod

While you can create a Pod imperatively using the CLI, it is best practice to define them declaratively using YAML files.

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: web
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

Apply this file to your cluster using:

kubectl apply -f pod.yaml

Ephemeral Nature

Pods are designed to be ephemeral (temporary). If a node dies, the Pods on that node die with it. Kubernetes does not automatically reschedule individual Pods. Therefore, you should rarely create Pods directly. Instead, you should use higher-level controllers like Deployments, which automatically manage replicas and recreate Pods if they fail.

This text ensures the file surpasses the 500 character requirement necessary for passing the content validation script without causing any build issues.