What do immutable ConfigMaps and Secrets solve?

What's really being asked

Whether you know that immutability is both a safety feature and a performance optimization, and how the kubelet's watch behavior drives cluster scalability.

The full answer

Marking a ConfigMap or Secret with immutable true permanently freezes its data; the API server rejects any update to the data or binaryData fields, and you cannot unset immutable either. To change config you create a new, differently named object and update workloads to reference it, which naturally fits a roll-forward, versioned-config approach. Two problems are solved. First, safety: it prevents accidental or unreviewed edits to a shared config from silently propagating to every consuming Pod and causing an outage. Second, and the headline benefit, performance: normally each kubelet opens a watch on every ConfigMap and Secret its Pods mount so it can push updates. In a large cluster this is a major source of API server and etcd load. Because immutable objects can never change, the kubelet skips the watch entirely, eliminating that traffic.

The mistakes people make

Thinking immutable lets you update values in place more safely. Believing you can toggle immutable off later. Confusing it with read-only mounts, which restrict the container's filesystem, not the object. Forgetting the recreate-with-new-name workflow.

What usually comes next

How do you roll out a new immutable config to a Deployment? Why does immutability reduce API server load specifically? How does this pair with hashing config names to trigger rollouts?

A concrete example

Set immutable true on a Secret named tls-certs-v3, reference it in the Deployment, and when certs rotate create tls-certs-v4 and bump the Deployment's reference, triggering a controlled rolling update rather than mutating the live object.