8.1 Kubernetes Pod Structure

Kubernetes Pod Structure is the internal composition of a Pod object's specification, defining the group of one or more containers it wraps, the shared execution context those containers operate within, and the collection of supporting fields, volumes, init containers, and scheduling directives, that together describe everything needed to run that group as a single, cohesive unit on a node.

The Pod as a Grouping of Containers

Why Pods Group Rather Than Run Single Containers

A Pod exists specifically because some workloads benefit from tightly coupled processes sharing network identity and certain filesystem resources, and the Pod abstraction provides exactly that shared context, letting Kubernetes schedule, network, and manage a group of containers as one atomic unit rather than forcing every container to be an independently placed, independently networked entity.

The containers Array

The spec.containers array lists every long-running application container that makes up the Pod's primary workload, each with its own image, command, resource requirements, and probes, but all sharing the Pod's network namespace and, depending on volume configuration, portions of its filesystem.

Init Containers

Sequential Pre-Application Execution

The spec.initContainers array lists containers that run to completion, one after another in order, before any container in the main containers array starts, commonly used for setup tasks such as waiting for a dependency to become available or populating a shared volume with initial data.

Distinct Lifecycle From Main Containers

Init containers are not restarted once they complete successfully and are not subject to the same readiness and liveness probing that governs the main application containers, reflecting their fundamentally different role as one-time setup steps rather than ongoing, continuously monitored processes.

Ephemeral Containers

Debugging Without Modifying the Pod Spec

The spec.ephemeralContainers array, populated through a dedicated subresource rather than typical Pod creation, allows a debugging container to be injected into an already-running Pod, sharing its namespaces, without requiring the Pod to be recreated, a capability specifically designed for live troubleshooting of a Pod that may be difficult or risky to restart.

Shared Namespace Context

Network Namespace Sharing

Every container within a Pod shares the same network namespace by default, meaning they share a single IP address and can reach one another over localhost, a structural characteristic that underlies much of what makes multi-container Pod patterns, such as sidecars, practical to implement.

Optional IPC and PID Namespace Sharing

Pods can additionally opt into sharing the IPC namespace, through shareProcessNamespace for PID visibility across containers, extending the default network-only sharing to cover inter-process communication and process tree visibility when a workload's design specifically calls for it.

Volumes at the Pod Level

Pod-Scoped Volume Definitions

The spec.volumes array defines storage resources at the Pod level, which individual containers then mount into their own filesystem at whatever paths they specify through volumeMounts, meaning a single volume definition can be shared and mounted by multiple containers within the same Pod simultaneously.

Volumes Outlive Individual Container Restarts

Because volumes are defined at the Pod level rather than per-container, their content persists across a container restart within the same Pod, even though the container's own writable layer is discarded and recreated fresh each time it restarts.

Scheduling and Runtime Directives

Fields Governing Placement and Execution Context

Beyond containers and volumes, a Pod's spec carries fields governing where and how it runs: nodeSelector and affinity for placement, tolerations for taint compatibility, restartPolicy for failure handling, securityContext for Pod-wide security settings, and serviceAccountName for the identity the Pod's containers authenticate to the API server with.

A Single Spec, Many Concerns

This breadth of fields within a single PodSpec reflects the Pod's role as the fundamental unit Kubernetes actually schedules and runs, meaning nearly every concern relevant to a workload's execution, from image selection to network sharing to security posture, ultimately finds its place somewhere within this one structure.