Kubernetes Container Environment

Kubernetes Container Environment is the complete set of environment variables a container's process actually receives at startup, assembled from multiple possible sources — literal values, references to ConfigMap or Secret keys, Downward API fields, and bulk imports through envFrom — each contributing to a single flattened environment the process sees no differently than if every value had been set identically through a single mechanism.

Sources of Environment Variables

Literal Values

The simplest form, env entries with a plain value field, sets a fixed string directly in the manifest, appropriate for configuration that is genuinely static and not sensitive, since anything written as a literal value is visible to anyone with read access to the Pod's spec.

ConfigMap and Secret Key References

An env entry can instead use valueFrom.configMapKeyRef or valueFrom.secretKeyRef to source a single variable's value from a specific key within a ConfigMap or Secret, resolved by the kubelet at container creation time and injected as a plain environment variable, with the sensitivity of Secret-sourced values protected only by whatever access controls guard the Secret object itself, not by any special handling once the value becomes a container environment variable.

Downward API References

As covered under Pod metadata usage, valueFrom.fieldRef and valueFrom.resourceFieldRef populate a variable from the Pod's own metadata or from that container's own resource requests and limits, giving the container self-referential information about its own identity or allocation without any external data source.

Bulk Import Through envFrom

Importing an Entire ConfigMap or Secret

envFrom imports every key from a referenced ConfigMap or Secret as individual environment variables in one entry, using each key's name directly as the resulting variable name, a more concise alternative to listing many individual env entries when a container genuinely needs most or all of a ConfigMap's or Secret's contents as environment variables.

The prefix Option

envFrom supports an optional prefix, prepended to every imported key's name, useful for avoiding collisions when importing from a source whose key names might otherwise clash with other environment variables set through different mechanisms in the same container.

Resolution Order and Conflict Handling

env Entries Take Precedence Over envFrom

When a variable name appears both in an explicit env entry and in a bulk envFrom import, the explicit env entry's value wins, giving authors a way to import a broad set of defaults through envFrom while still overriding specific individual values through targeted env entries in the same container.

Later env Entries Override Earlier Ones

Within the env list itself, if the same variable name is specified more than once, the last occurrence in the list order takes precedence, though relying on this behavior deliberately is uncommon practice compared to simply avoiding duplicate variable names in the first place.

Cross-Referencing Between Environment Variables

Referencing One Variable's Value in Another

Kubernetes' $(VAR_NAME) substitution syntax, described under container startup command, also applies within env values themselves, allowing one environment variable's value to incorporate the resolved value of an earlier-defined variable, evaluated in the order the variables are declared, which lets authors compose derived values (such as a full URL built from a separately defined host and path) without needing shell-level string concatenation.

Environment Variables Are Fixed at Container Start

No Live Updates for Standard env Entries

Unlike Downward-API-populated volume files, which the kubelet periodically refreshes, environment variables populated via env or envFrom are fixed at the moment the container process starts and do not update if the underlying ConfigMap, Secret, or Pod metadata changes afterward; reflecting an updated value into a running container's environment requires restarting that container, typically triggered by a Pod replacement rather than any in-place update mechanism.