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.

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