ACS clusters expose resources as virtual nodes, so you work with orchestration rules rather than raw node capacity. This page maps common scheduling requirements—availability zone distribution, workload co-location, batch job coordination, and multi-tenant resource isolation—to the ACS scheduling policies that address them, so you can choose the right policy without reading every linked guide.
Kubernetes-native scheduling policies
The Kubernetes scheduler provides a range of plug-ins. In ACS virtual nodes, affinity-based policies are the most relevant for controlling pod placement and meeting performance and high-availability requirements.
| Policy | What it does | Reference |
|---|---|---|
| Topology spread constraints | Specify a label on a virtual node in the topologyKey field to distribute workload replicas across availability zones. Use this when a single-zone outage would take your application offline. |
Use topology spread constraints to distribute pods across zones |
| Node affinity | Add labels to virtual nodes to represent attributes such as availability zone. Reference those labels in nodeSelector to pin pods to nodes with specific characteristics. |
Schedule pods based on node affinity |
| Inter-pod affinity | Control pod placement based on the labels of pods already running on nodes. Use podAffinity to schedule pods to a specific topology domain. |
Schedule pods based on pod affinity |
Resource scheduling based on custom priorities
If your cluster runs multiple compute class types, rank them by preference. When the top-priority type is out of stock, the scheduler automatically tries the next type in your list—useful for cost-sensitive workloads that prefer best-effort instances but must still run when those are unavailable.
| Policy | What it does | Reference |
|---|---|---|
| Resource scheduling based on custom priorities | Specify multiple compute classes or compute QoS classes for a pod. When resources are out of stock, the scheduler attempts to create pods of other types. |
Job scheduling
Batch and AI workloads have requirements that differ from long-running services. An AI training job typically needs all its pods to start at the same time—partially starting a group wastes resources without making progress. In clusters shared across teams, per-namespace resource caps prevent any single workload from crowding out others.
| Policy | What it does | When to use it | Reference |
|---|---|---|---|
| Gang scheduling | Allocates resources to an entire pod group as a batch. If the cluster cannot satisfy the full request, all pods in the group remain in the Pending state. | High-performance computing (HPC) and AI training jobs—for example, Message Passing Interface (MPI) jobs—where all replicas must start before the job can make progress. | |
| Capacity scheduling | Sets resource capacity limits per namespace. | Clusters shared by multiple teams or applications where you need to guarantee each group a minimum resource allocation and prevent overuse. |