Kubernetes Object Count Quota Management

Kubernetes Object Count Quota Management is the practice of bounding the total number of API objects of a given type — Pods, Services, Secrets, ConfigMaps, ReplicationControllers, and others — that may exist within a namespace, using the count-based dimensions of a ResourceQuota object independent of any compute or storage resource consumption those objects represent. Where compute and storage quotas bound the aggregate size of resource consumption, object count quotas bound raw quantity, protecting against a namespace accumulating an excessive number of individually small, resource-light objects that could still strain etcd storage, API server list/watch performance, or controller reconciliation throughput even without ever approaching a compute or storage ceiling.

Object count quotas address a class of problem that size-based quotas cannot: many objects, each individually within acceptable resource bounds, whose sheer number still represents a governance or performance concern for the cluster as a whole.

Countable Object Types

Core Object Counts

The most commonly quota-bounded object types include pods, services, secrets, configmaps, persistentvolumeclaims, and replicationcontrollers, each tracked as an independent count dimension within a single ResourceQuota.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: codartium-object-quota
spec:
  hard:
    pods: "50"
    services: "10"
    secrets: "30"
    configmaps: "30"
    persistentvolumeclaims: "20"

Service-Type-Specific Counts

Some object count dimensions are further refined by subtype — services.loadbalancers and services.nodeports bound the number of Services specifically using those exposure types, which is useful given that LoadBalancer Services typically carry direct cloud infrastructure cost (a provisioned load balancer per Service) distinct from ordinary ClusterIP Services.

spec:
  hard:
    services.loadbalancers: "3"
    services.nodeports: "5"

Extensible to Custom Resources

Object count quota also extends to custom resources registered via CustomResourceDefinitions, using the pattern count/<resource>.<group>, allowing governance over custom, organization-specific object types using the same quota mechanism applied to built-in Kubernetes resources.

spec:
  hard:
    count/widgets.codartium.io: "25"

Why Object Count Quotas Matter Independent of Resource Size

Protecting API Server and etcd Performance

A namespace accumulating thousands of tiny Secrets or ConfigMaps, each individually negligible in size, can still degrade API server list/watch performance and increase etcd storage pressure cluster-wide — object count quotas are a direct defense against this failure mode, which size-based compute or storage quotas would never catch.

Preventing Namespace Sprawl in Multi-Tenant Clusters

In clusters shared by many teams, a namespace whose object count grows unbounded (through automation bugs, forgotten cleanup, or genuine but ungoverned growth) affects the shared control plane's performance for every tenant, not just the offending namespace — object count quotas provide a straightforward, easily reasoned-about ceiling protecting this shared resource.

Interaction with Compute Quotas

Independent Enforcement

Object count and compute/storage quota dimensions within the same ResourceQuota object are evaluated entirely independently — a namespace can hit its pods: 50 ceiling well before exhausting its requests.cpu budget if its Pods are individually small, or vice versa if a smaller number of large Pods consume compute budget faster than they accumulate count.

Combined Governance in Practice

Most production ResourceQuota configurations combine both dimension types deliberately, since neither alone fully captures the governance intent — a namespace intended for many small, lightweight microservices benefits from a generous pods count alongside a moderate compute budget, while a namespace running a small number of large batch workloads benefits from the inverse configuration.

Diagnosing Object Count Quota Rejections

kubectl create -f new-service.yaml
# Error: exceeded quota: codartium-object-quota, requested: services=1,
# used: services=10, limited: services=10

A rejection citing an object count dimension (rather than a compute or storage one) indicates the namespace has reached its object quantity ceiling for that type specifically — remediation requires either deleting unused objects of that type or requesting a quota increase, distinct from the remediation path for a compute or storage quota rejection.

kubectl get services -n codartium-team
kubectl describe resourcequota codartium-object-quota -n codartium-team

Example

apiVersion: v1
kind: ResourceQuota
metadata:
  name: codartium-object-count-example
  namespace: codartium-team
spec:
  hard:
    pods: "40"
    services: "8"
    services.loadbalancers: "2"
    secrets: "25"
    configmaps: "25"