<p>Though <code>resourceQuotas</code> may limit the number of configmaps in a namespace, is there any such option to limit the size of the individual configmap?
I will not like some user to start uploading large text files as configmaps.</p>

<p>What is the max size of ConfigMap etcd support? If there is a reasonable limit on the etcd side, should be fine then.</p>

Ijaz Ahmad
<p>There are no <a href="https://github.com/kubernetes/kubernetes/issues/19969" rel="noreferrer">hard-limits</a> on either the ConfigMap or Secret objects as of this writing. </p>

<p>There's, however, a 1MB limit from the <a href="https://github.com/kubernetes/kubernetes/issues/19781" rel="noreferrer">etcd</a> side which is where Kubernetes stores its objects.</p>

<p>From the API side, if you actually see the API <a href="https://github.com/kubernetes/api/blob/master/core/v1/types.go#L5027" rel="noreferrer">code</a> and the ConfigMap type, you'll see that its <a href="https://github.com/kubernetes/api/blob/master/core/v1/types.go#L5040" rel="noreferrer">data</a> field is Golang map of strings so this appears memory bound and managed at runtime unless somewhere else it gets defined with <code>make()</code>. Technically the max size for the number of keys on hashmap is the map length which is an <code>int</code> and the max value is explained here: <a href="https://stackoverflow.com/questions/32600763/maximum-number-of-elements-in-map">Maximum number of elements in map</a>. That would also be the theoretical limit for the value of data as the maximum value for <code>len(string)</code>.</p>

<p>If you actually want to get more insights from the API side where the kube-apiserver receives protobufs (or JSON for that matter) you can take a look at the <a href="https://stackoverflow.com/questions/34128872/google-protobuf-maximum-size">google protobuf maximum size</a>. That will give you some measure as to the limitation of sending the <code>data</code> field through the wire. There may be other limitation from the kube-apiserver itself when it comes to processing any large message.</p>
