ConfigMap Size Calculator
Check whether a ConfigMap's data stays within Kubernetes' 1MiB size limit.
About ConfigMap Size Calculator
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
Worked example
With the default values below, ConfigMap Size Calculator returns Estimated ConfigMap Size of 160.0. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Number of Keysaccepts 0–1,000,000 keys
- 40 keys
- Average Value Sizeaccepts 0–10,000 KB
- 4 KB
Results
- Estimated ConfigMap Size
- 160.0 KB
- Percent of 1MiB Limit
- 15.6%
- Exceeds 1MiB Limit
- false
- Remaining Before Limit
- 864.0 KB
Step by step
- 1Total size = keys × avg value size= 160.0KB
- 2Percent of 1MiB etcd limit= 15.6%
Assumptions and limits
- The result is derived only from the 2 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
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.