All Products
Search
Document Center

Container Compute Service:Work with capacity scheduling

Last Updated:Mar 26, 2026

Container Compute Service (ACS) supports the ResourceQuota mechanism from open source Kubernetes. A ResourceQuota sets hard limits on the total resources a namespace can consume — CPU, memory, extended resources, and more. When a namespace has a ResourceQuota, Kubernetes tracks usage and rejects any request that would push the namespace over its limit.

How it works

ResourceQuotas work as follows:

  • Each team or application runs in a separate namespace.

  • A cluster administrator creates one or more ResourceQuotas for each namespace.

  • When users create resources (pods, Services, and so on), the quota system tracks usage and ensures it stays within the hard limits defined in the ResourceQuota.

  • If creating or updating a resource would exceed a quota, Kubernetes rejects the request with HTTP status code 403 Forbidden. The error message identifies the quota name, the requested amount, the current usage, and the hard limit.

Requirements

  • If a ResourceQuota sets CPU or memory limits for a namespace, every pod you create in that namespace must specify resource requests and limits. Pods without these settings are rejected. To avoid this, use a LimitRanger admission controller to set default resource limits automatically.

  • After you modify a ResourceQuota, the change applies only to new resource creation requests. Existing resources are not affected.

  • The name of a ResourceQuota must be a valid DNS subdomain.

Enable the ResourceQuota feature

By default, the ResourceQuota feature is enabled for Container Service for Kubernetes (ACK) clusters created in the ACS console. You only need to create a ResourceQuota in the namespace to enable the ResourceQuota feature for that namespace.

Supported resource types

ACS is fully compatible with the Kubernetes ResourceQuota mechanism. Both standard resources and extended resources are supported.

Standard resources

Resource Constraint
limits.cpu Across all pods in a non-terminated state, the sum of CPU limits cannot exceed this value.
limits.memory Across all pods in a non-terminated state, the sum of memory limits cannot exceed this value.
requests.cpu Across all pods in a non-terminated state, the sum of CPU requests cannot exceed this value.
requests.memory Across all pods in a non-terminated state, the sum of memory requests cannot exceed this value.
hugepages-<size> Across all pods in a non-terminated state, the sum of HugePage requests of the specified size cannot exceed this value.
cpu Equivalent to requests.cpu.
memory Equivalent to requests.memory.

Extended resources

Kubernetes does not support extended resource overcommit (limit > request). For extended resources, configure only quotas that start with requests.. For details, see Resource quotas.

Prerequisites

Before you begin, ensure that you have:

  • An ACS cluster

  • kubectl configured to connect to your cluster

  • Cluster administrator permissions to create ResourceQuotas

Create and verify a ResourceQuota

This example walks through creating a ResourceQuota that caps CPU usage in a namespace, then shows what happens when pods hit that limit.

Step 1: Create a namespace

kubectl create namespace test

Step 2: Create a ResourceQuota

Create a ResourceQuota named test-quota in the test namespace with a CPU hard limit of 4000 millicores (4 cores) for both requests and limits:

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: ResourceQuota
metadata:
  name: test-quota
  namespace: test
spec:
  hard:
    requests.cpu: "4000m"
    limits.cpu: "4000m"
EOF

This quota enforces the following constraints on the test namespace:

  • The sum of CPU requests across all pods must not exceed 4000m.

  • The sum of CPU limits across all pods must not exceed 4000m.

Step 3: Verify the ResourceQuota

kubectl -n test describe resourcequota test-quota

Expected output:

Namespace:    test
Resource      Used  Hard
--------      ----  ----
limits.cpu    0     4
requests.cpu  0     4

The Used column shows 0, confirming no pods have consumed quota yet.

Step 4: Deploy pods that consume the quota

Create a Deployment with 5 replicas, each requesting 1 CPU core (1000m). Because the quota is 4000m, only 4 pods can be scheduled:

cat << EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: test-app
  name: test-app
  namespace: test
spec:
  replicas: 5
  selector:
    matchLabels:
      app: test-app
  template:
    metadata:
      labels:
        app: test-app
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/acs/busybox:v1.29.2
        imagePullPolicy: IfNotPresent
        name: test
        command:
        - sleep
        - "360000000"
        resources:
          limits:
            cpu: "1"
EOF

Step 5: Check the pod status

kubectl -n test get pod

Expected output:

NAME                        READY   STATUS    RESTARTS   AGE
test-app-5ddxxxxx94-jdv4m   1/1     Running   0          35s
test-app-5ddxxxxx94-jhmtb   1/1     Running   0          35s
test-app-5ddxxxxx94-mr8vq   1/1     Running   0          35s
test-app-5ddxxxxx94-pjdfn   1/1     Running   0          35s

Four pods are running. The fifth pod cannot start because the namespace has no remaining CPU quota.

Step 6: Verify quota usage

kubectl -n test describe resourcequota

Expected output:

Name:         test-quota
Namespace:    test
Resource      Used  Hard
--------      ----  ----
limits.cpu    4     4
requests.cpu  4     4

The Used and Hard columns match — the quota is fully consumed.

Step 7: Confirm that the quota blocks new pods

Scale the Deployment to 5 replicas and observe the quota enforcement:

  1. Scale the Deployment:

    kubectl -n test scale deploy test-app --replicas 5
  2. Check the ReplicaSet. The DESIRED column shows 5 but CURRENT shows 4, meaning one pod failed to create:

    kubectl -n test get rs

    Expected output:

    NAME                  DESIRED   CURRENT   READY   AGE
    test-app-5ddxxxxx94   5         4         4       3m10s
  3. Inspect the ReplicaSet events to see the quota error:

    kubectl -n test describe rs test-app-5ddxxxxx94

    The Events section shows a FailedCreate warning similar to:

    Warning  FailedCreate  replicaset-controller  Error creating: pods "test-app-5ddc68c994-5s4ph" is forbidden: exceeded quota: test-quota, requested: limits.cpu=1,requests.cpu=1, used: limits.cpu=4,requests.cpu=4, limited: limits.cpu=4,requests.cpu=4

    The error identifies the quota name (test-quota), the requested amount, the current usage, and the hard limit — making it straightforward to diagnose and resolve.

What's next

  • Resource quotas — Kubernetes official reference

  • LimitRange — set default resource requests and limits for pods automatically