在本文中，你将在 Azure Kubernetes 服务 (AKS) 上为 Ray 工作负载配置 Kueue 准入控制。 Kueue 对 RayJob 提交进行准入控制：作业创建时会带有 suspend: true 和队列标签。 Kueue 在配额可用时通过设置 suspend: false来承认它们，这会触发 KubeRay 运算符创建 Ray 群集。
提供两种队列配置。 选择适合你的使用场景的选项：
| Configuration | 它演示的内容 |
|---|---|
| 单个队列 | 一个带有反压的 ClusterQueue - 一个工作负荷运行，下一个等待 |
| 团队队列 | 同一共享 cohort 中的两个 ClusterQueue，包含每个团队的配额、借用和抢占 |
Important
AKS 文档和示例中都提到了开源软件。 您部署的软件被排除在 AKS 服务级别协议、有限保修和 Azure 支持之外。 将开源技术与 AKS 一起使用时，请查阅相应社区和项目维护者提供的支持选项来制定计划。
Microsoft 将负责生成我们在 AKS 上部署的开源包。 该责任包括拥有构建、扫描、签名、验证和快速修复流程的完整所有权，并掌控容器镜像中的二进制文件。 如需了解详细信息，请参阅 AKS 漏洞管理和 AKS 支持范围。
先决条件
- 按照 在 AKS 上为 Ray 和 Kueue 部署基础结构进行部署的基础结构。
-
kubectl已连接到群集。 - Kueue 控制器正在运行（可使用
kubectl -n kueue-system get pods验证）。
创建命名空间和服务帐户
导航到克隆存储库中的队列配置模块：
cd <path-to-cloned-repo>/AKS/examples/kueue-and-ray-on-aks/2-kueue-queues
kubectl apply -f manifests/00-namespace.yaml
kubectl apply -f <(terraform -chdir=../1-infrastructure/terraform output -raw ray_workload_sa_yaml)
验证服务帐户是否具有工作负荷标识注释：
kubectl -n ray get serviceaccount ray-workload -o yaml
输出应包含azure.workload.identity/client-id和azure.workload.identity/tenant-id批注，允许 Ray Pod 在没有凭据的情况下访问Azure Blob 存储。
创建 ResourceFlavors
ResourceFlavors 描述群集中可用的节点类型。 创建两种风格 - default （任何节点） 和 gpu （NVIDIA 加速器节点）：
kubectl apply -f manifests/10-resource-flavors.yaml
验证：
kubectl get resourceflavors
预期输出：
NAME AGE
default 1m
gpu 1m
gpu flavor 针对带有标签 accelerator=nvidia 的节点，而该标签会由 AKS 自动应用到 GPU 节点池。
选项 A：配置单个队列
单队列配置会创建一个 ClusterQueue，其配额按同一时间仅支持一个工作负载的规模进行设置。 当配额已全部用完时，下一次提交将一直处于待处理状态，直到前一个提交完成。
kubectl apply -f manifests/20-single-queue.yaml
验证 ClusterQueue 和 LocalQueue：
kubectl get clusterqueue cluster-queue
kubectl -n ray get localqueue default
预期输出：
NAME COHORT PENDING WORKLOADS
cluster-queue 0
NAME CLUSTERQUEUE PENDING WORKLOADS ADMITTED WORKLOADS
default cluster-queue 0 0
检查配置的配额：
kubectl get clusterqueue cluster-queue -o jsonpath='{.spec.resourceGroups}' | python3 -m json.tool
默认配额设置为一次可容纳此解决方案中的一个工作负载：96 个 CPU、768 Gi 内存、8 个 GPU。
选项 B：配置启用借用功能的团队队列
团队队列配置将 GPU 节点拆分为两个团队，每个团队都有自己的 ClusterQueue，通过共享队列进行连接：
kubectl apply -f manifests/30-team-queues.yaml
Important
选择选项 A 或选项 B，而不是同时选择。 若要在它们之间切换，请先删除活动配置：
kubectl delete -f manifests/20-single-queue.yaml
验证：
kubectl get clusterqueues
kubectl -n ray get localqueues
预期输出：
NAME COHORT PENDING WORKLOADS
team-a-cq shared-cohort 0
team-b-cq shared-cohort 0
NAME CLUSTERQUEUE PENDING WORKLOADS ADMITTED WORKLOADS
team-a team-a-cq 0 0
team-b team-b-cq 0 0
注释
工作负荷示例默认为 QUEUE_NAME=default与选项 A 匹配。如果选择了选项 B，请设置 export QUEUE_NAME=team-a 或 export QUEUE_NAME=team-b在每个 工作负荷目录中运行 source env.example 之前。
每个团队获得 4 个 borrowingLimit GPU，保证其值为 4，因此当另一个团队处于空闲状态时，团队最多可以使用 8 个 GPU。 关键行为：
| Scenario | 发生的情况 |
|---|---|
| 团队 A 提交，团队 B 空闲 | 团队 A 获得全部 8 块 GPU（4 块自有的 + 4 块借来的） |
| 团队 B 提交，而团队 A 使用 8 | Kueue 抢占了 A 团队借用的 GPU，B 团队获得了其有保障的 4 个 GPU |
| 两个团队都忙 | 每个团队都使用其有保证的 4 个 GPU |
Troubleshooting
| 症状 | 原因 | 修复 |
|---|---|---|
| 工作负荷保持挂起状态 | 配额已用尽 | 等待正在运行的工作负荷完成，或在 ClusterQueue 中增加nominalQuota |
LocalQueue not found |
错误的队列名称标签 | 验证 kueue.x-k8s.io/queue-name 标签是否与现有 LocalQueue 名称匹配 |
| ResourceFlavor 与节点不匹配 | 缺少节点标签 | 检查 GPU 节点是否具有 accelerator=nvidia 标签 kubectl get nodes --show-labels |
| Kueue 控制器未运行 | Helm 发布问题 | 通过 kubectl -n kueue-system logs deploy/kueue-controller-manager 进行检查 |
有关完整的清单详细信息，请参阅存储库中的 2-kueue-queues 目录 。
清理资源
若要删除 Kueue 队列配置（保留群集和运算符）：
kubectl delete -f manifests/20-single-queue.yaml # or 30-team-queues.yaml
kubectl delete -f manifests/10-resource-flavors.yaml
kubectl delete -f manifests/00-namespace.yaml
注释
ray删除命名空间会删除该命名空间中的所有工作负荷、LocalQueues 和 ServiceAccount。 ClusterQueues 和 ResourceFlavors 是集群级别的，必须单独删除。 若要拆除整个基础结构，请参阅 在 AKS 上部署 Ray 和 Kueue 的基础结构。
后续步骤
在配置的队列上运行工作负荷示例。 步骤 1-2 和步骤 3-4 是独立的对：
- 微调极光天气模型
- 使用 Ray Serve 提供微调的极光模型 （需要步骤 1）
- 使用 Ray 训练 LLM
- 使用 Ray 运行批处理推理 （需要步骤 3）