Config, storage and labels in Kubernetes

A pod needs settings, sometimes secrets, often a disk, and an identity for calling the API. Kubernetes gives each need its own object: a ConfigMap for settings, a Secret for sensitive values, a volume for storage, and a ServiceAccount for identity. Labels tie it all together by grouping objects so you can query them.

ConfigMaps and Secrets

A ConfigMap holds non-secret settings as key-value pairs or files. You mount it as environment variables or as files.

Changing a ConfigMap has different effects depending on how it is used. A file mount updates after a delay. An environment variable does not change in a running pod. You need a rollout to pick it up.

A Secret has the same shape, but its values are only base64-encoded in etcd by default. Base64 is an encoding, not encryption. Turn on encryption at rest, or use an external secrets manager, for anything valuable. Never bake secrets into images.

Volumes and where pods can run

• emptyDir is scratch space that lasts as long as the pod.
• configMap, secret and projected put config into the filesystem.
• PersistentVolumeClaim (PVC) requests durable storage. A provisioner creates the disk and binds it to the claim.

Most block volumes are ReadWriteOnce (RWO). They attach to one node at a time. A pod that mounts one is tied to that node.

Here is what happens when that node dies:

1. The node stops responding, and the pod on it is gone.
2. The replacement pod is scheduled, but the old volume is still attached to the dead node.
3. The volume must detach from that node and attach to the new one.
4. Only then can the replacement pod start.

Plan for this delay. Shared storage across nodes needs a filesystem that allows multi-attach, such as EFS or Filestore.

ServiceAccounts

A ServiceAccount gives a pod an identity for talking to the Kubernetes API. The token is mounted automatically. If the app never calls the API, turn automount off. Scope RBAC to only the verbs the app needs.

Namespaces and labels

Namespaces split the cluster by team or environment, such as payments-prod and payments-staging. RBAC and quotas usually apply per namespace. Namespaces are not a hard security boundary against a hostile tenant with node access.

Labels are key=value tags on objects. Deployments, Services and NetworkPolicies find their targets through labels. A consistent convention makes it possible to ask "show me everything for checkout":

app.kubernetes.io/name: checkout
app.kubernetes.io/instance: checkout-prod
app.kubernetes.io/component: api
app.kubernetes.io/part-of: payments
app.kubernetes.io/managed-by: helm

Common mistakes

• Believing Secrets are encrypted by default. They are base64 unless you enable encryption.
• Expecting an env var change to apply without a rollout. It will not.
• Choosing RWO storage for shared data. Pods on other nodes cannot mount it.
• Inventing labels per team. Use one convention, or selectors will miss things.

Check yourself

1. You change a ConfigMap that pods read as environment variables. What has to happen? The pods must be rolled out. Env vars only change in new pods.
2. Why can't replicas on different nodes share one RWO volume? An RWO volume attaches to one node at a time, so the others cannot mount it.

Key takeaways

• ConfigMaps hold settings, Secrets hold sensitive values, and volumes hold data.
• Secrets are not encrypted unless you enable encryption or use an external store.
• RWO volumes pin a pod to a node and add reattach delay after a node failure.
• Labels are part of your API. Keep one convention.

Further learning

Next, when a pod keeps crashing, use the steps in debugging CrashLoopBackOff.