Volcano · Rate Limits

Volcano Rate Limits

Volcano does not expose a vendor-side request-rate limit. As a Kubernetes-native scheduler running in the customer's cluster, "limits" in Volcano are workload-level resource quotas - CPU, memory, GPU, and queue capacity - enforced via the Queue CRD and standard Kubernetes ResourceQuota objects. Consumers of the Volcano API interact with the Kubernetes API server, whose rate-limit and admission-controller behavior governs request throttling.

Volcano Rate Limits is the machine-readable rate-limit profile for Volcano on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 2 rate-limit definitions, measuring varies.

The profile also includes 3 backoff/retry policies defined.

Tagged areas include Open Source, Kubernetes, Rate Limiting, and Quotas.

2 Limits
Open SourceKubernetesRate LimitingQuotas

Limits

Kubernetes API Server (cluster-side) cluster
varies
see kube-apiserver --max-requests-inflight / --max-mutating-requests-inflight
Volcano is consumed via the Kubernetes API; rate enforcement is whatever the cluster's API server is configured with.
Volcano Queue Capacity queue
varies
see Queue CRD spec.capability
Multi-dimensional resource cap (CPU, Memory, GPU) per Queue; enforced by Volcano scheduler, not as a request-rate limit.

Policies

Kubernetes-Native Throttling
All client interaction is via kubectl / client-go against the Kubernetes API server. Use the standard client-go QPS / burst tunables and respect 429 responses from the API server.
Queue-Based Fairness
Volcano enforces fairness through Queues with hierarchical resource inheritance, weight, and capability caps rather than per-second request limits.
Gang Scheduling Admission
Jobs are admitted only when the full PodGroup can be scheduled atomically; partial submissions are gated by the scheduler rather than throttled at the API surface.

Sources