#Manage Project Quotas

This guide explains how ACP extends Kubernetes ResourceQuota with a project-level aggregate quota (ProjectQuota). ProjectQuota lets you cap the sum of ResourceQuotas across all namespaces in a project, so you can plan and govern capacity at the project level while still delegating limits to individual namespaces.

#What is ProjectQuota?

• ResourceQuota (Kubernetes native) limits resources per namespace (CPU, memory, object counts, etc.). For concepts, keys, and usage, please refer to:
  • Resource Quotas
• ProjectQuota defines a project-wide upper bound: the total of all namespace ResourceQuotas within the project must not exceed the project's hard limits for the same keys.

In short: ResourceQuota caps a single namespace; ProjectQuota caps the sum across all namespaces in a project.

#How it works

• Workflow order: define or adjust the ProjectQuota first, then allocate per-namespace ResourceQuotas within that project budget.
• Scope: ProjectQuota applies to a platform project and governs all namespaces that belong to it.
• Aggregate enforcement at admission time:
  • When creating or updating a namespace's ResourceQuota, the platform computes the aggregate for the same keys (for example, limits.cpu, requests.memory, pods) across all namespaces in the project, including the incoming change.
  • The request is allowed only if the new aggregate remains less than or equal to the corresponding ProjectQuota hard limits. Otherwise, the change is rejected with an explanatory error.
• Execution model:
  • ProjectQuota constrains what can be allocated via namespace ResourceQuotas (pre-allocation), not the instantaneous runtime usage. Actual consumption remains governed by each namespace's ResourceQuota and the scheduler.

#When to use ProjectQuota

• Budget/capacity governance per project: allocate a fixed CPU/memory/object budget, then subdivide across namespaces.
• Multi-team or multi-environment projects (for example, dev/staging/prod) that share a common upper bound.
• Preventing quota drift: keep a single "big bucket" at the project layer so namespace quotas do not silently inflate over time.

#Quota keys and units

ProjectQuota supports the same common keys as ResourceQuota (non-exhaustive):

• Compute and memory: limits.cpu, limits.memory, requests.cpu, requests.memory
• Workload/object counts: pods, services, configmaps, secrets, pvc, and more

Units and counting rules:

• CPU uses cores (for example, 2, 500m)
• Memory uses bytes (for example, 8Gi)
• Object-style keys use integer counts

If the sum of the corresponding keys across all namespaces approaches or exceeds the ProjectQuota hard limit, ACP blocks further ResourceQuota creation or expansion for that key.

#Allocation strategy tips

• Define the project "big bucket" first (ProjectQuota), then split it into per-namespace ResourceQuotas for teams/environments.
• Keep 10% - 30% headroom for spikes and elastic scaling.
• Review regularly: reclaim underused quota and reassign; raise consistently constrained namespaces, and adjust the project cap accordingly.

#Best practices and FAQs

• Q: Increasing a namespace's limits.memory fails with an error about exceeding project quota. Why?
  • A: The project's ProjectQuota hard limit for that key would be exceeded by the requested change. Reduce other namespaces' quotas, or raise the project cap first and then retry the namespace change.
• Q: I raised the ProjectQuota, but workloads still won't schedule.
  • A: Ensure each namespace's ResourceQuota is also increased appropriately and verify underlying cluster/node capacity.
• Recommendation: Manage ProjectQuota as part of your normal change control, aligned with capacity planning (nodes/storage) and budget management.