Kueue 提供 Kubernetes 原生的工作佇列與批次及 AI 工作負載的資源准入。 它根據可用的隊列配額和已設定的政策，決定工作負載何時可以開始。 經准入後，Kubernetes 排程器會將工作負載的 pod 放在節點上。
在 Azure Kubernetes Service （AKS） 上，建議使用受管理的 Kueue 擴充功能（預覽版）來安裝和管理支援的 Kueue 控制器，並為叢集產生受管理資源。 請參見 「在 AKS 上安裝受管理的 Kueue 擴充功能」。
本文說明 Kueue 及受管理的 Kueue 擴展的基本概念。
Important
整個 AKS 文件和範例都會提及開放原始碼的軟體。 您部署的軟體會從 AKS 服務等級協定、有限保固和 Azure 支援 中排除。 當您搭配 AKS 使用開放原始碼技術時，請參閱個別社群和專案維護人員所提供的支援選項，以開發計畫。
Microsoft 負責建置我們在 AKS 上部署的開源套件。 該責任包括擁有組建、掃描、簽署、驗證和 Hotfix 程式的完整擁有權，以及控制容器映像中的二進位檔。 如需詳細資訊，請參閱 AKS 弱點管理和 AKS 支援涵蓋範圍。
何時使用 Kueue
使用 Kueue 處理那些可以等待足夠配額和資源才執行的工作負載，例如：
- 人工智慧與機器學習訓練。
- GPU 密集型批次作業。
- 資料處理與分析。
- 超參數調校與批次推論。
- 媒體編碼及其他有限處理作業。
Kueue 與 Kubernetes Jobs 及支援的工作負載 API 如 RayJob 整合。 受管理擴充套件所支援的整合功能列於 受管安裝指南中。
Kueue 準入並不等同於 Pod 排程或 Azure 容量配置。 可用佇列配額並不保證 pod 能立即排程。 關於准入前的容量配置，請參見 將受管 Kueue 與叢集自動擴展器搭配使用。
理解 Kueue 的基本概念
以下資源將已提交的工作負載與配額及准入政策連結起來：
| 資源 | Purpose |
|---|---|
ResourceFlavor |
描述在分配資源給工作負載時所使用的節點特性。 受控擴充功能會為符合資格的使用者節點產生資源規格。 |
ClusterQueue |
定義叢集範圍的資源配額、flavor 參照，以及如排隊和搶佔等政策。 |
LocalQueue |
提供一個命名空間範圍的提交點，並參考ClusterQueue。
LocalQueue 通常以團隊、事業單位、使用者或專案命名。 |
Workload |
記錄工作負載的資源請求、配額預留及准入狀態。 受支援的工作負載整合會建立此物件。 |
WorkloadPriorityClass |
為工作負載分配優先順序，用於准入排序及適用的搶占政策。 受控擴充功能會提供預設類別。 |
準入流程如下：
工作或其他支援的工作負載→ LocalQueue → ClusterQueue → 准入檢查與配額保留→工作負載准入→ pod 排程
工作負載的 kueue.x-k8s.io/queue-name 標籤用於識別其命名空間中的一個 LocalQueue。 LocalQueue 會將工作負載路由到其 ClusterQueue。 如果所需配額或准入檢查尚未準備好，工作負載就會等待，而非啟動其 Pod。
ClusterQueue 配額是一種准入政策，不是節點池大小或 Azure 訂閱配額。 佇列擁有者會根據容量與共享政策配置配額。
了解 AKS 受控 Kueue 擴充功能的受控資源與優先順序
受管理擴充會產生資源，例如供符合資格的 CPU 使用者節點使用的 aks-cpu ResourceFlavor，並提供 aks-low-priority、aks-medium-priority 和 aks-high-priority 工作負載優先權類別。 GPU 的類型名稱取決於偵測到的 GPU 硬體。 檢查為您的叢集所產生的資源，而不要假設名稱。
從您的佇列與工作負載參考受控資源。 不要用保留的 AKS 名稱重建它們，也不要更改它們的防護標記。 你仍然擁有你的 ClusterQueues、LocalQueues、工作負載請求和配額政策。
優先級會影響入院順序。 只有當 ClusterQueue 的搶占政策允許時，才會啟用搶占。 僅有較高優先權並不代表某個工作負載可以驅逐另一個工作負載。 請參考 低優先順序與高優先順序的作業範例。
受控擴充功能中的 Kueue 功能
受管理的預覽提供以下功能配置：
| Feature | 受管理的設定 |
|---|---|
拓撲感知排程（TopologyAwareScheduling） |
默認為啟用。 在支援的情況下，請配置你的佇列與工作負載，使用具備拓撲意識的放置。 |
LocalQueue 指標 （LocalQueueMetrics） |
默認為啟用。 Kueue 會公開 LocalQueue 活動與準入的計量。 |
| ClusterQueue 資源指標 | 已啟用。 Kueue 會揭露每個 ClusterQueue 的配額與資源使用指標。 |
| 工作負載整合 | Kubernetes Job、Pod、Deployment、StatefulSet、JobSet、RayJob、RayService、RayCluster、MPIJob 以及 Trainer v2 TrainJob 都已啟用。 Legacy Kubeflow Trainer v1 工作、AppWrapper 和 LeaderWorkerSet 都沒有啟用。 |
| MultiKueue | 預設為停用。 Azure 服務會為受支援的多叢集案例管理其設定。 |
公開計量並不會設定其收集或儲存方式。 請另外設定監控。
功能閘門、控制器設定與工作負載整合皆作為擴充套件發行的一部分進行管理。 你無法透過客戶提供的擴充功能設定或 Helm 值來覆寫它們。 你仍然可以透過 Kueue APIs 自行設定 ClusterQueues、LocalQueues、配額，以及工作負載政策。
Responsibilities
平台系統管理員通常會：
- 佈建和管理 AKS 節點集區。
- 安裝受管理擴充功能並確認控制器健康狀況。
- 配置 ClusterQueues、配額、分享及搶佔政策。
- 提供 LocalQueues，並監控准入及叢集容量。
工作負載擁有者通常：
- 將支援的工作負載提交至 LocalQueue。
- 選擇適當的工作負載優先類別。
- 設定資源請求及任何必要的放置限制。
- 監視工作負載準入、Pod 排程及應用程式結果。
選擇安裝方式
推薦：管理式 Kueue 擴充功能
使用受管理擴充功能來管理支援的 Kueue 版本和控制器設定，透過 Azure。 AKS 也會產生受管理的 ResourceFlavors，並提供預設的工作負載優先類別。 請在 AKS 上安裝受管理的 Kueue 擴充功能。
關於叢集與用戶端的需求，請參閱 受管理擴充的前置條件。
關於生命週期操作，請參見 移除受管理的 Kueue 擴充功能。 卸載會刪除 Kueue 的自訂資源和佇列設定;這不是控制器健康度的變通方法。
替代方案（不推薦）
如果你需要自行選擇並管理 Kueue 版本或控制器配置，也可以選擇安裝開源專案，包括透過 Helm 安裝。 使用 上游 Kueue 的安裝說明 來處理該路徑，而不是直接套用上游安裝指令到受管理擴充功能。
自行託管安裝的設定與生命週期則需分開管理。 不要在同一叢集上同時運行自架的 Kueue 控制器和受管理擴充功能。