Kubernetes Container Structure

Kubernetes Container Structure is the field-level composition of an individual container entry within a Pod's containers (or initContainers) list, describing the image to run, how to run it, what resources it may consume, and how its health should be observed — the granular unit of configuration that, multiplied across a Pod's full container list, together determines everything the Pod actually executes.

Image and Execution Fields

image and imagePullPolicy

The image field identifies what container image to run, typically as a registry path with a tag or digest, while imagePullPolicy (Always, IfNotPresent, or Never) governs when the runtime should fetch a fresh copy versus reuse whatever is already cached locally on the node.

command and args

command overrides the image's built-in entrypoint, and args overrides its built-in default arguments; when both are omitted, the container runs exactly what the image itself was built to run by default, and specifying either allows a manifest to adapt a generic image's behavior without needing a custom-built image just to change its startup invocation.

workingDir and env

workingDir sets the directory the container's process starts in, while env supplies environment variables, either as literal values or as references resolved from ConfigMaps, Secrets, or Downward API fields, giving the container access to configuration and identity information without that data being baked into the image itself.

Resource Configuration

resources.requests and resources.limits

The resources field specifies, separately, what the container is guaranteed to receive (requests, used by the scheduler for placement decisions) and the ceiling it may never exceed (limits, enforced by the kernel through cgroups), a two-tier structure that underlies both scheduling decisions and the Quality of Service classification the Pod as a whole receives.

Extended and Ephemeral Resources

Beyond CPU and memory, the same resources structure can request extended resources such as GPUs exposed through device plugins, and, separately, ephemeral-storage limits govern how much of the node's local disk the container's writable layer and any emptyDir volumes it uses may consume.

Volume Attachment

volumeMounts Referencing Pod-Level Volumes

volumeMounts lists which of the Pod's declared volumes this specific container should mount, and at what filesystem path, with an optional readOnly flag; this field is what actually connects a container to storage the Pod as a whole has made available, since declaring a volume at the Pod level alone does not make it appear inside any container without a corresponding mount entry.

Probes

livenessProbe, readinessProbe, and startupProbe

Each of these three probe fields independently configures a health check — executing a command inside the container, issuing an HTTP request, or opening a TCP connection — with liveness determining whether the container should be restarted, readiness determining whether it should receive traffic, and startup delaying the other two probes until the container has finished its initial startup sequence.

Security Context

Container-Level Overrides of Pod Defaults

A container's own securityContext can override Pod-level security defaults for that specific container alone — running as a different user, adding or dropping specific Linux capabilities, or enabling a read-only root filesystem — giving fine-grained control when one container in a multi-container Pod genuinely needs different security posture than its siblings.

Lifecycle Hooks

postStart and preStop

lifecycle.postStart and lifecycle.preStop define actions — a command execution or an HTTP request — triggered immediately after the container starts and immediately before it is terminated respectively, giving a container a way to perform setup or graceful shutdown work synchronized precisely with its own start and stop events rather than needing to embed that logic in the main process itself.

Ports Declaration

containerPort as Documentation, Not Enforcement

The ports field declares which ports a container listens on, primarily serving as documentation and metadata consumed by tooling (and, for host networking scenarios, actually reserving the port); critically, omitting a port from this list does not prevent a container from actually listening on it or receiving traffic, since Kubernetes networking does not enforce port declarations as an access control mechanism.