Check whether a ConfigMap's data stays within Kubernetes' 1MiB size limit.
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.
totalSize = keys × avgValueSize
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.
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.
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.