Kubernetes API server quotas

To keep your cluster healthy and predictable, the Cloudfleet Kubernetes API server enforces two quotas: a per-object size limit and an overall data store size limit. Both are designed to protect the control plane from runaway growth that can make a cluster slow, unstable, or impossible to recover.

Per-object size limit (1 MiB)

Any single Kubernetes object you create or update, such as a ConfigMap, Secret, CustomResource, or large annotation set, must be 1 MiB or smaller. Requests that exceed this limit are rejected by the API server.

If you see an error similar to:

Request entity too large: limit is ...

or your client reports ResourceExhausted, the object you’re trying to write is over the limit.

What to do

• Split large ConfigMap or Secret payloads into multiple smaller objects.
• Move large blobs (binaries, datasets, generated artifacts) out of Kubernetes and into object storage (S3, GCS, etc.), and reference them by URL.
• Trim large annotations. They are intended for small metadata, not bulk data.
• For Custom Resources, reconsider the schema: large status or spec fields are a common cause.

Data store size quota (6 GiB)

The cluster’s data store (the etcd-compatible backend that holds all Kubernetes objects) has a total quota of 6 GiB across all namespaces and resource types combined. When the data store reaches this quota, the API server stops accepting writes and returns a NOSPACE condition until space is freed.

You’ll see this most often as failed kubectl apply/create calls with errors mentioning mvcc: database space exceeded or a NOSPACE alarm in the cluster status.

What to do

1. Delete objects you no longer need. The most common culprits are:
   • Old Job and completed Pod records that were never cleaned up.
   • Stale Event objects (these can accumulate in busy clusters).
   • Unused ConfigMap / Secret revisions left behind by Helm or rollout tooling.
   • Custom Resources from operators that don’t garbage-collect on their own.
2. Wait a few minutes. After deletion, the data store needs time to compact and reclaim space in the background. Writes will resume automatically once the size drops back below the quota, with no manual intervention against the cluster needed.
3. If writes still fail after deleting objects and waiting, open a ticket in the Cloudfleet support center. Some recovery paths require operator action on the underlying data store that you can’t perform yourself.

Avoiding the quota

The 6 GiB ceiling is large enough for the vast majority of clusters, but a few patterns push clusters toward it faster than expected:

• Storing application data in ConfigMap or Secret objects instead of a real datastore.
• Running operators that create one Custom Resource per work item without cleanup.
• High-cardinality controllers that emit large numbers of Event objects.

If your workload genuinely needs more capacity, reach out to support before you hit the limit. Recovering from a full data store is slower than planning ahead.