A ConfigMap has grown to hold a large multi-file config bundle — what's the practical size limit, and what would you do instead if you hit it?

ConfigMaps (and Secrets) are limited to roughly 1MiB total, because that's etcd's own default maximum object size — Kubernetes stores the entire ConfigMap as a single etcd value, so this isn't a Kubernetes-specific policy choice but a constraint inherited from the underlying data store. Once you hit it, the fix is almost never "increase the limit" (etcd's limit is a stability-motivated default, not casually raised in most managed clusters) — instead, split the content into multiple ConfigMaps, or move genuinely large/binary content out of ConfigMaps entirely and into a purpose-built storage mechanism (an image layer, object storage, a persistent volume).

The ~1MiB limit comes from etcd, not from a Kubernetes-specific ConfigMap policy: etcd's default --quota-backend-bytes-adjacent per-value size constraint (historically around 1.5MiB, with Kubernetes' API validation enforcing a conservative ~1MiB ceiling for ConfigMaps/Secrets specifically) exists to protect etcd's own performance and stability — large values slow down etcd's replication and increase memory pressure, which affects the entire cluster's control plane, not just the object that happens to be large.

This is a hard practical ceiling, not something most teams should try to raise: while etcd's own limits are technically configurable, doing so on a production cluster (especially a managed one like EKS/AKS/GKE, where you typically don't control etcd configuration at all) isn't a realistic path — the intended fix is architectural, not a config bump.

Splitting into multiple ConfigMaps is the most direct fix for genuinely text-based configuration: if the bundle is naturally separable (different config files for different components, or a large file that can reasonably be split), multiple smaller ConfigMaps, each mounted at the appropriate path, solves the problem without changing how the application consumes configuration — it just requires the mount setup to reference multiple ConfigMap sources instead of one.

Genuinely large or binary content usually shouldn't be in a ConfigMap at all: static assets, generated binary artifacts, or large data files are architecturally a poor fit for ConfigMaps regardless of the size limit — baking them into the container image (if they're static per-version), storing them in object storage and fetching at startup (if they're large and change independently of the image), or using a PersistentVolume (if they need to be written to as well as read) are all more appropriate mechanisms that don't fight against etcd's constraints.

A ConfigMap growing large over time is often itself a signal worth investigating: rather than just working around the limit, it's worth asking why the ConfigMap accumulated so much content — sometimes it's a sign that config management responsibilities have blurred (generated build artifacts ending up in what should be a small, hand-maintained config file), which is worth addressing at the source rather than just splitting the symptom away.

• The ~1MiB ConfigMap/Secret size limit comes from etcd's own per-value size constraint, protecting cluster-wide control-plane stability — it's not a casually-adjustable Kubernetes policy.
• Splitting genuinely text-based configuration into multiple smaller ConfigMaps is the most direct fix without changing the application's consumption pattern.
• Large or binary content is architecturally a poor fit for ConfigMaps regardless of the limit — consider baking it into the image, object storage, or a PersistentVolume instead.
• A ConfigMap growing large over time is sometimes a signal of blurred config-management responsibilities worth investigating at the source.

• Kubernetes: ConfigMaps — Motivation