Pods Explained

Pods Explained

A Pod is the smallest deployable unit in Kubernetes — a wrapper around one or more containers that share the same network namespace, IP address, and storage volumes. All containers within a Pod communicate via localhost and see the same filesystems. In practice, most Pods contain a single container. Multi-container Pods are used for the sidecar pattern: a helper container that runs alongside the main application (for example, a log shipper or a service mesh proxy).

What is a Pod?

Pod (shared network namespace + storage):
+--------------------------------------------------+
|  Container A (main app)    Container B (sidecar) |
|    port 8080                  reads /logs        |
|         shared localhost                         |
|         shared volume: /logs                     |
|  IP: 10.244.1.15  (one IP for the whole Pod)     |
+--------------------------------------------------+
         |
         | scheduled onto
         v
  Worker Node: k8s-worker-01

Pod lifecycle

Writing a Pod manifest

nano nginx-pod.yaml

nginx-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx:alpine
      ports:
        - containerPort: 80
      resources:
        requests:
          memory: "64Mi"
          cpu: "100m"        # 100 millicores = 0.1 CPU
        limits:
          memory: "128Mi"
          cpu: "200m"
      livenessProbe:         # Restart container if this fails
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 10
        periodSeconds: 10
      readinessProbe:        # Remove from Service endpoints if this fails
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 5

# Create the pod:
kubectl apply -f nginx-pod.yaml

# Watch pod come up:
kubectl get pods -w

# Describe pod (shows events, conditions, and resource usage):
kubectl describe pod nginx-pod

# Get pod logs:
kubectl logs nginx-pod

# Execute a command inside the pod:
kubectl exec -it nginx-pod -- /bin/sh

# Delete the pod:
kubectl delete pod nginx-pod

kubectl get pods output

NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          45s
# 1/1 = 1 container running out of 1 total

Multi-container pods

nano multi-pod.yaml

multi-pod.yaml — nginx + log-sidecar example

apiVersion: v1
kind: Pod
metadata:
  name: nginx-with-logger
spec:
  containers:
    - name: nginx
      image: nginx:alpine
      volumeMounts:
        - name: logs
          mountPath: /var/log/nginx
    - name: log-shipper           # Sidecar: reads nginx logs
      image: alpine
      command: ["/bin/sh", "-c", "tail -f /logs/access.log"]
      volumeMounts:
        - name: logs
          mountPath: /logs        # Same volume, different mount path
  volumes:
    - name: logs
      emptyDir: {}               # Shared in-memory volume, lost when pod dies

# Specify which container to get logs from (multi-container pod):
kubectl logs nginx-with-logger -c nginx
kubectl logs nginx-with-logger -c log-shipper

# Exec into a specific container:
kubectl exec -it nginx-with-logger -c nginx -- /bin/sh

Conclusion

In production, you never create Pods directly — you create Deployments, which create Pods and manage their lifecycle. Direct Pods have no self-healing: if the node they run on fails, the Pod is gone and nothing recreates it. Deployments solve this. However, understanding Pod manifests is essential because Deployment manifests embed a Pod template, and all Pod fields (resource limits, probes, volumes, environment variables) appear inside the Deployment spec.