✦ For everyone, free.

Practical knowledge for real and everyday life

Home

1.19 Kubernetes Configuration Definition

Kubernetes Configuration Definition explains how clusters are structured using YAML files to define and manage desired states in Kubernetes.

Kubernetes Configuration Definition is the precise characterization of ConfigMaps and Secrets as API objects defined specifically to hold configuration data external to a container image, distinguished from one another primarily by the sensitivity of the data they are intended to carry rather than by any structural difference in how they are consumed.


Configuration Objects Defined by Purpose, Not Structure

Key-Value Data as the Common Form

Both ConfigMaps and Secrets are defined around the same basic structure: a set of key-value pairs, where values may be short strings or the contents of entire files, stored as data associated with the object's identity rather than embedded in any workload's own specification.

Distinguished by Intended Sensitivity

The defining distinction between the two is intended sensitivity: a ConfigMap is defined for non-sensitive configuration values, while a Secret is defined for values requiring more careful handling, such as credentials or tokens, even though both are technically similar containers for arbitrary key-value data.

ConfigMap, Secret = key-value store + sensitivity classification

Consumption Modes as Part of the Definition

Environment Variable Injection

A configuration object's data can be defined for consumption as environment variables within a container, either individually selected or injected in bulk, a mode of consumption suited to applications that read configuration from their process environment.

Volume Mount Projection

Alternatively, a configuration object's data can be defined for consumption as files projected into a container's filesystem through a volume mount, suited to applications that expect configuration to be read from disk rather than from environment variables.


What Distinguishes Secrets Specifically

Encoding, Not Encryption, by Default

A Secret's data is defined to be stored base64-encoded, a detail that is part of its structural definition but explicitly not equivalent to encryption; the definition of a Secret does not by itself guarantee confidentiality unless paired with separately configured encryption at rest.

Handling Conventions Beyond Structure

Beyond its structural similarity to a ConfigMap, a Secret is defined by additional handling conventions, such as being held in memory-backed storage on nodes where possible, reflecting its intended sensitivity even though the underlying object schema closely mirrors that of a ConfigMap.


Boundaries of the Configuration Definition

Not a Replacement for Application Logic

Configuration objects are defined strictly as data carriers; they do not execute any logic themselves, meaning any interpretation, validation, or application of the values they hold is entirely the responsibility of the workload consuming them.


Configuration Object Structure Diagram

ConfigMap (non-sensitive) Secret (sensitive) key-value data