What is a Pod?

A Pod is the smallest deployable unit in Kubernetes, representing a single instance of a running process within a cluster. It acts as a wrapper for one or more application containers.

Pod Deployment Models

Two primary models exist for deploying applications within Pods:

1. Single-container Pod: The most common pattern, where a single container runs with in a Pod.
2. Multi-container Pod: A Pod that orchestrates multiple tightly-coupled containers, allowing them to share resources and communicate efficiently.

The Pod Infrastructure Container (Pause Container)

Every Pod includes a special infrastructure container, often referred to as the "pause" container. This container, part of the Kubernetes platform, establishes the foundational environment for the Pod. It enables two key forms of resource sharing among all containers in the Pod:

• Network: The Pod is assigned a unique IP address. All containers within the Pod share the same network namespace (IP and port range). Inter-container communication uses localhost, while external communication occurs through the Pod's shared IP.
• Storage: Pods can define shared volumes. All containers in the Pod can access these volumes, which can also be used to persist data beyond the lifecycle of individual containers.

The infrastructure container provides the shared Linux namespaces (like network and PID) for the Pod and manages the lifecycle of the init process.

Pod Lifecycle Management

• Static Pods: Managed directly by the kubelet on a node. They cannot self-heal. Once created, a static Pod remains on its node until its process terminates, it is manually deleted, it is evicted due to resource constraints, or the node fails.
• Managed Pods (via Controllers): The standard method managed by Kubernetes control plane components like Deployments, StatefulSets, or DaemonSets. Controllers provide declarative updates, replication, self-healing, and rolback capabilities for Pods.

Pod Container Types

1. Infrastructure Container

Establishes the Pod's network and storage foundations. It starts automatically when a Pod is scheduled to a node.

# Example kubelet configuration showing the pause image
cat /opt/kubernetes/cfg/kubelet | grep pause
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0

2. Init Containers

Specialized containers that run to completion before the main application containers start. They run sequentially, each must succeed before the next begins. Their purposes include:

• Running setup scripts or utilities not needed in the main application image.
• Delaying application startup until preconditions (e.g., dependent services being available) are met.
• Safely handling sensitive data like secrets, which the main app containers might not need to access directly.

If an init container fails, the Pod restarts it according to the Pod's restartPolicy. If the policy is Never, the Pod fails.

3. Application Containers

These are the primary containers that run the application workload. They start in parallel after all init containers have completed successfully.

Example: Pod with Init Containers

apiVersion: v1
kind: Pod
metadata:
  name: service-dependent-app
  labels:
    app: myapp
spec:
  containers:
  - name: app-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo "Main app started!" && sleep 3600']
  initContainers:
  - name: check-api-service
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup api-service; do echo "Waiting for API..."; sleep 3; done;']
  - name: check-database
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup database; do echo "Waiting for DB..."; sleep 3; done;']

This Pod's main container (app-container) only starts after both check-api-service and check-database init containers succeed in resolving their respective service names.

Image Pull Policy

Controls when the kubelet attempts to pull a container image.

• IfNotPresent: (Default) Pull the image only if it is not already present locally.
• Always: Always pull the image, even if it exists locally.
• Never: Only use the local image. Never pull from a registry.

Pod Restart Policy

Defines the action the kubelet takes when a container inside the Pod exits. This restartPolicy applies to all containers in the Pod.

• Always: (Default) Restart the container regardless of its exit code.
• OnFailure: Restart the container only if it exits with a non-zero status (i.e., it failed).
• Never: Do not restart the container. Note: This policy governs container restarts within a Pod. To "restart" an entire Pod, it must be recreated by its controller.

Resource Management (Requests and Limits)

Pods can specify compute resource requirements and constraints for each container.

• requests: The minimum amount of a resource (CPU/memory) that must be available for the container to be scheduled.
• limits: The maximum amount of a resource a container is allowed to use.

Units:

• CPU: Measured in CPU units. 1 CPU core is equivalent to 1 vCPU/Core. 250m represents 250 millicpu (0.25 cores).
• Memory: Measured in bytes. Can use decimal (KB, MB, GB) or binary (KiB, MiB, GiB) prefixes.
  • 64Mi = 64 Mebibytes (64 * 2^20 bytes)
  • 128MB = 128 Megabytes (128 * 10^6 bytes)

Example: Pod with Resource Specifications

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: web-server
    image: nginx:alpine
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: log-processor
    image: fluentd:latest
    resources:
      requests:
        memory: "32Mi"
        cpu: "100m"
      limits:
        memory: "64Mi"
        cpu: "200m"

This Pod's total resource requests are 86MiB memory and 350m CPU. Its total resource limits are 192MiB memory and 700m CPU. The scheduler uses the sum of requests to decide on node placement.