8.6 Kubernetes Container Structure

Kubernetes Container Structure is the field-by-field schema of an individual container entry within a Pod's containers, initContainers, or ephemeralContainers array, covering image selection, process invocation, environment configuration, networking, storage attachment, resource governance, health checking, and security settings, all scoped to that single container rather than the Pod as a whole.

Image and Process Invocation

image and imagePullPolicy

The image field specifies the container image reference to run, while imagePullPolicy governs whether and when the runtime should attempt to pull a fresh copy, together determining exactly what code the container will execute and how aggressively that determination is re-verified on each start.

command and args

The command field overrides the image's built-in entrypoint, and args overrides or supplies the arguments passed to it, giving a manifest author control over the exact process invocation without needing to rebuild the image itself just to change startup parameters.

workingDir

The workingDir field sets the process's initial working directory, overriding whatever default the image itself specifies, relevant when a container's expected file paths depend on a specific working directory context.

Environment Configuration

env for Individual Variables

The env array defines individual environment variables, each either a literal value or a valueFrom reference pulling from a ConfigMap key, a Secret key, or a Downward API field, giving fine-grained control over exactly which values are injected and from where.

envFrom for Bulk Injection

The envFrom array instead bulk-imports every key from a referenced ConfigMap or Secret as environment variables, with an optional prefix field to avoid naming collisions, offering a more concise alternative to enumerating many individual env entries one by one.

Networking Configuration

ports

The ports array declares the network ports a container listens on, primarily documentary and used for Downward API and tooling purposes, since Kubernetes networking does not actually require ports to be declared here for the container to be reachable within the Pod's shared network namespace.

Storage Attachment

volumeMounts

The volumeMounts array attaches Pod-level volumes, defined separately in spec.volumes, into this specific container's filesystem at specified paths, with each mount independently configurable as read-only or read-write and supporting different mount propagation modes.

Resource Governance

resources

The resources field specifies requests and limits for CPU, memory, and other resource types, directly informing scheduling decisions and cgroup enforcement for this specific container, independent of whatever other containers within the same Pod separately request or limit.

Health Checking

livenessProbe, readinessProbe, and startupProbe

These three probe fields each independently configure health check behavior for the container, using HTTP, TCP, gRPC, or exec-based checks, governing restart behavior, Service traffic eligibility, and startup grace handling respectively, as covered in depth elsewhere but structurally residing here at the container level.

Lifecycle Hooks

lifecycle.postStart and lifecycle.preStop

The lifecycle field's postStart hook runs immediately after the container starts, and preStop runs immediately before it is sent a termination signal, both executing either a command inside the container or an HTTP request, giving a container a way to perform setup or graceful shutdown actions tied precisely to its own start and stop transitions.

Security Context

securityContext at the Container Level

A container-level securityContext can set runAsUser, runAsNonRoot, capabilities, readOnlyRootFilesystem, and other security-relevant fields specific to this container, overriding or refining whatever broader settings the Pod-level security context establishes, giving individual containers within the same Pod different security postures where warranted.

Restart Policy for Sidecar-Style Init Containers

The restartPolicy Field Within initContainers

When used within an init container entry, a restartPolicy of Always designates that specific container as a native sidecar, altering its lifecycle to start before the main containers and continue running alongside them rather than terminating after completing its initial task, a structural field specific to this particular usage context within the broader container schema.