1.12 Kubernetes Container Specification Definition
Kubernetes Container Specification Definition explains how containers are structured, managed, and integrated into Kubernetes clusters.
Kubernetes Container Specification Definition is the precise characterization of the container specification embedded within a Pod's spec, defined as the declarative description of a single container's image, runtime parameters, and resource requirements, forming the smallest configurable unit inside a Pod's overall desired state.
Scope of a Container Specification
One Entry per Container
A Pod's spec contains a list of container specifications, with each entry describing exactly one container that should run within that Pod; the number of entries in this list directly determines how many containers the kubelet will attempt to create for the Pod.
Declarative, Not Imperative
Like the rest of a Pod's spec, a container specification is defined declaratively: it states what the container should look like and how it should behave, leaving the kubelet and container runtime responsible for actually realizing that description as a running process.
Required Fields
Name and Image
Every container specification must define a name, unique within its Pod, and an image, identifying the container image to be pulled and run; without both of these, the specification is incomplete and will be rejected.
Fields That Default When Omitted
Many other fields, such as command, arguments, and working directory, are optional and fall back to values defined by the container image itself when not explicitly specified in the container specification.
Resource-Related Fields
Requests and Limits
A container specification may define resource requests and limits for CPU and memory, and these values are defined at the level of the individual container, not the Pod as a whole, meaning a single Pod's total resource footprint is the sum of its individual container specifications.
Ports
A container specification may declare ports it listens on; this declaration is documentation of intent within the specification and does not by itself restrict which ports the container can actually use, since the Pod's shared network namespace exposes all ports regardless.
Behavioral Fields
Environment Variables and Volume Mounts
A container specification includes environment variables and volume mounts, both of which reference other objects, such as ConfigMaps, Secrets, or Pod-level volumes defined elsewhere, meaning the container specification often depends on and links together data defined outside of it.
Probes
Liveness, readiness, and startup probes are defined per container, not per Pod, meaning each container within a multi-container Pod can have independent health-checking behavior tailored to its own role.
Boundaries of the Specification
What It Does Not Define
A container specification does not define scheduling behavior, restart policy, or shared volumes themselves; those are properties of the enclosing Pod specification, since they apply across all containers within the Pod rather than to any single one.