Storage and object count quotas — bounding PVCs, secrets, and cluster objects

Storage and object count quotas bound the persistent volumes and cluster objects a namespace can consume. This lesson walks the fields, the operational impact, and the discipline.

Storage quotas

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-quota
  namespace: tenant-a-prod
spec:
  hard:
    requests.storage: 1Ti
    persistentvolumeclaims: "50"
    requests.ephemeral-storage: 100Gi
    limits.ephemeral-storage: 200Gi

The storage fields:

• requests.storage. Sum of all PVCs’ storage requests cannot exceed 1 TiB.
• persistentvolumeclaims. Count of PVCs cannot exceed 50.
• requests.ephemeral-storage / limits.ephemeral-storage. Sum of Pods’ ephemeral storage requests/limits.

Object count quotas

apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-count-quota
  namespace: tenant-a-prod
spec:
  hard:
    pods: "200"
    services: "100"
    services.loadbalancers: "5"
    services.nodeports: "0"
    secrets: "100"
    configmaps: "100"
    persistentvolumeclaims: "50"
    count/deployments.apps: "50"
    count/statefulsets.apps: "20"
    count/daemonsets.apps: "10"
    count/jobs.batch: "50"
    count/cronjobs.batch: "20"

Object count quotas bound:

• pods. Maximum number of Pods.
• services. Maximum number of Services, with optional sub-quotas for LoadBalancer and NodePort.
• secrets. Maximum number of Secrets.
• configmaps. Maximum number of ConfigMaps.
• count/<resource>.<group>. Maximum number of objects of a specific kind.

Service type quotas

apiVersion: v1
kind: ResourceQuota
metadata:
  name: service-quota
  namespace: tenant-a-prod
spec:
  hard:
    services: "100"
    services.loadbalancers: "5"
    services.nodeports: "0"

Service type quotas:

• services.loadbalancers. Limit the number of LoadBalancer Services (each creates a cloud load balancer; cost matters).
• services.nodeports. Limit or zero out NodePort Services (security; many teams disallow NodePort).

A team that does not restrict LoadBalancer Services may rack up unexpected cloud costs.

Setting object count quotas

flowchart LR
    A[Setting object quotas] --> B["Pods: 5x expected average"]
    B --> C["Services: 2x expected average"]
    C --> D["Secrets: 1.5x expected average"]
    D --> E["ConfigMaps: 1.5x expected average"]
    E --> F[Review based on actual usage]

The discipline:

• Pods. 5x expected average to allow for rollouts, scaling.
• Services. 2x expected average.
• Secrets. 1.5x expected (Secrets grow slowly).
• ConfigMaps. 1.5x expected.

Adjust based on actual usage patterns.

The operational trade-offs

flowchart LR
    A[Object count quotas] --> B[+ Prevents namespace exhaustion]
    A --> C[+ Limits etcd pressure]
    A --> D[+ Limits cloud costs]
    A --> E[- Tight quotas cause rollouts to fail]
    A --> F[- Adjustment requires care]

The trade-offs:

• Pros: Prevents namespace exhaustion, etcd pressure, cloud cost surprises.
• Cons: Tight quotas cause rollouts to fail (the new ReplicaSet needs Pods, but the quota is reached); adjustments require care.

Quiz

The operational discipline

Storage and object count quotas in production rest on five non-negotiable elements:

• Bound PVCs and storage. A namespace without storage quotas can exhaust the backend.
• Bound secrets. etcd pressure.
• Bound LoadBalancer services. Cloud cost.
• Monitor utilisation. Alert when approaching quota.
• Review quarterly. Workloads change; quotas must adapt.

Object quotas are production contracts. Set them deliberately; the contract protects the cluster.