ConfigMap Size Calculator
Estimate a ConfigMap's total size from its key count and average value size, and check it against the 1MiB etcd object limit.
Inputs
Estimated ConfigMap Size
160.0KB
Percent of 1MiB Limit
15.6%
Exceeds 1MiB Limit
false
Remaining Before Limit
864.0KB
Step by step
Total size = keys × avg value size
40 × 4KB
= 160.0KB
Percent of 1MiB etcd limit
0.156MiB ÷ 1MiB
= 15.6%
How it works
ConfigMaps (and Secrets) are stored as single objects in etcd, which enforces a hard 1MiB size limit per object — this isn't a Kubernetes-imposed soft limit but a gRPC message size constraint on etcd itself. This calculator multiplies key count by average value size to estimate total ConfigMap size and flags how close that estimate is to the ceiling, since the API server will reject the object outright once it's exceeded.
Formula
totalSize = keys × avgValueSize
- K
- Number of keys in the ConfigMap
- V_{avg}
- Average value size in KB
- S
- Estimated ConfigMap size in KB
Frequently Asked Questions
What happens when a ConfigMap exceeds 1MiB?
The API server rejects the create/update request with an error like 'etcdserver: request is too large' — the object is never persisted, so this fails fast at apply time rather than causing runtime issues.
How can I work around the 1MiB limit for large configs?
Split the config into multiple ConfigMaps mounted at different paths, use an external config store (e.g. object storage, a config service) fetched at startup, or mount large static assets via an init container instead of a ConfigMap.
Does binaryData count differently than data?
Both binaryData and data count toward the same 1MiB total object size limit — binaryData is base64-encoded internally in etcd similar to Secrets, so it carries the same ~33% encoding overhead as raw bytes.