擴展階層式佇列：面向 AI 多租戶的 Kubernetes 叢集架構

Problem

Enterprise AI platforms live and die by their GPU utilization. When organizations consolidate machine learning workloads onto shared Kubernetes clusters, they inevitably hit a wall with native scheduling primitives. Standard Kubernetes schedulers treat pods as independent entities, lacking awareness of hierarchical business units, tenant budgets, and multi-node job dependencies.

In a flat namespace model, the first team to submit a massive distributed training run consumes every available GPU node. Subsequent requests from other teams sit in pending states, regardless of business priority or SLA requirements. Static resource quotas offer marginal relief, but they create artificial scarcity and leave expensive accelerators idle when specific teams underuse their allocations. With the recent release of Volcano v1.16, the platform engineering community has a robust toolset for namespace queuing and hierarchical fair-share scheduling, but designing the surrounding architecture requires careful consideration of control plane bottlenecks and failure modes.

Architecture overview

Solving AI tenancy at scale requires decoupling request ingestion from cluster scheduling while enforcing strict hierarchy across business units, cost centers, and workload types. The architecture establishes a multi-tier pipeline that intercepts incoming AI workloads, evaluates them against tenant-specific quotas and priority trees, and dispatches them to specialized node pools equipped with MIG-sliced accelerators and high-throughput storage.

The edge layer handles ingress and authentication, routing requests to a centralized queue controller. This controller manages a hierarchical tree structure where parent queues hold overall departmental budgets, and child queues represent specific projects or ephemeral environments. Below the scheduling layer, the worker tier utilizes topology-aware resource allocation to minimize inter-node communication latency during distributed training jobs.

Step-by-step flow

1. Client dispatches inference or training batch to the API Gateway.
2. API Gateway authenticates request and forwards it to the Queue Controller.
3. Queue Controller evaluates hierarchical fair-share rules across tenant namespaces.
4. Scheduler allocates pod groups to isolated worker nodes using topology constraints.
5. GPU operator provisions MIG slices and mounts storage volumes for execution.
6. Telemetry agent exports cluster utilization and queue latency to Prometheus.

Design decisions and trade-offs

Choosing hierarchical scheduling over flat quotas involves a deliberate exchange of control plane complexity for operational predictability. Evaluating complex priority trees and parent-child quota borrowing adds overhead to the scheduling cycle. In large clusters with thousands of pending workloads, scheduling latency can increase significantly compared to native FIFO schedulers.

Another major design decision involves preemption policies. Soft limits allow teams to burst into idle capacity belonging to other tenants, maximizing overall cluster utilization. However, when the owning tenant demands their resources back, active jobs must be preempted. This requires robust checkpointing infrastructure to prevent catastrophic loss of training progress. Without automated checkpointing, aggressive preemption results in wasted compute cycles and developer frustration.

Here is an example configuration snippet for a hierarchical queue structure using Volcano CRDs:

apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: department-ai
spec:
  weight: 50
  capability:
    cpu: "500"
    memory: "2000Gi"
    nvidia.com/gpu: "64"
---
apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: team-inference
spec:
  weight: 30
  parent: department-ai
  capability:
    cpu: "200"
    memory: "800Gi"
    nvidia.com/gpu: "24"

Failure modes

Control plane saturation is the primary failure mode in scaled queue architectures. If the queue controller becomes bottlenecked during high-frequency job submissions, scheduling throughput drops, causing cascading timeouts at the API gateway. Implementing rate limiting and request batching at the ingress layer mitigates this risk.

Another critical failure mode involves deadlocks in gang-scheduling requests. If a distributed training job requires all pods to start simultaneously, but the cluster only has capacity for a subset due to strict tenant limits, the scheduler can hold resources indefinitely while waiting for the remaining slots. Setting strict timeouts and automatic eviction policies for unsatisfied pod groups prevents cluster-wide resource lockup.

When not to use this

Hierarchical queueing and advanced GPU scheduling introduce substantial operational overhead. Do not adopt this architecture if your organization runs a small, homogenous machine learning environment with fewer than a dozen GPUs and a single team of users. In small-scale deployments, native Kubernetes namespaces and standard resource quotas provide sufficient isolation without the complexity of custom schedulers and multi-tier queue controllers.

Key takeaways

Flat namespace queues inevitably fail when multiple business units compete for limited GPU resources. Hierarchical fair-share scheduling protects critical workloads from starvation while enabling dynamic capacity borrowing. Platform engineers must balance scheduling latency against fairness guarantees, ensuring that control plane complexity delivers tangible business ROI.