Core Workload Resources: Pods, Deployments, and ReplicaSetsLesson 2.1

What is a Kubernetes Pod and why you rarely create one directly

Pod definition, shared network namespace, shared storage volumes, multi-container pods, sidecar pattern, Pod lifecycle phases, why Pods are ephemeral, naked pods anti-pattern

A Pod Is the Smallest Deployable Unit

Kubernetes Pod internal structure diagram

A Pod wraps one or more containers that share a network namespace and storage volumes. Containers in the same Pod communicate over localhost — no service discovery needed between them. They are always scheduled together on the same node.

Multi-Container Pods and the Sidecar Pattern

Most Pods run a single container. But the sidecar pattern is common: your main app container runs alongside a helper container (log shipper, proxy, config loader) that shares its filesystem and network.

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
  - name: main-app
    image: my-app:1.0
    volumeMounts:
    - name: logs
      mountPath: /var/log/app
  - name: log-shipper          # sidecar
    image: fluent/fluent-bit:2.1
    volumeMounts:
    - name: logs
      mountPath: /var/log/app  # reads same directory
  volumes:
  - name: logs
    emptyDir: {}

Why Not Create Naked Pods

A Pod created directly has no self-healing. If the node it runs on fails or the Pod is deleted, it is gone. Nothing recreates it. In production, you almost always manage Pods through a higher-level resource (Deployment, StatefulSet, DaemonSet) that provides reconciliation. Naked Pods are fine for debugging and one-off jobs.