A ConfigMap stores non-confidential configuration data separately from a workload. A pod can receive its data through environment variables or a volume mounted in a container. Use a Secret instead when the data is sensitive. section 4.2.4 section 4.3
To create and use one:
- Generate a YAML starting point: `kubectl create cm redis-config --from-literal=key1=config1 --from-literal=key2=config2 --dry-run=client -o yaml > redis-config.yaml`. The dry run writes a manifest without creating the object. section 4.2.4
- Edit the `data` entries as needed; use `|` for a multiline value such as Redis configuration. Create or update the object with `kubectl apply -f redis-config.yaml`. section 4.2.4
- Reference the ConfigMap from the pod as a mounted volume or through environment variables. For the Redis volume example, check the volume and mount configuration, then inspect the configuration through Redis CLI. section 4.2.4
ConfigMaps also hold cluster-component configuration. In `kube-system`, separate ConfigMaps contain kubelet and CoreDNS settings; inspect them with `kubectl -n kube-system get cm`. After changing the kubelet ConfigMap for a new cluster DNS Service address, run the node's kubelet-configuration upgrade step and verify the address in a newly created pod. section 6.2.2 section 6.1
Verify a kubelet DNS change
Edit the configuration with `kubectl -n kube-system edit cm kubelet-config`, then run `kubeadm upgrade node phase kubelet-config`. Create a new pod and inspect its `/etc/resolv.conf`; in the illustrated Service-range change, its nameserver is `100.96.0.10`. Test name resolution from that pod as well. section 6.1
