Поделиться через

Планирование и развертывание пакетных заданий с помощью Kueue в службе Azure Kubernetes (AKS)

В этой статье вы узнаете, как запланировать и развернуть примеры пакетных заданий в службе Azure Kubernetes (AKS) с помощью Kueue. Кроме того, в этом руководстве рассматривается установка Kueue, настройка ResourceFlavors и ClusterQueues для точного управления ресурсами и отправка заданий с помощью LocalQueues. Вы также узнаете, как использовать Kueue, чтобы поставить в очередь пример пакетного задания и отслеживать результаты в состояниях (Ожидание), (Выполнение) и (Готово).

Это важно

Программное обеспечение с открытым кодом упоминается во всей документации и примерах AKS. Программное обеспечение, которое вы развертываете, не покрывается соглашениями об уровне обслуживания AKS, ограниченной гарантией и поддержкой Azure. При использовании технологии с открытым исходным кодом вместе с AKS ознакомьтесь с вариантами поддержки, доступными от соответствующих сообществ и обслуживающих проектов для разработки плана.

Корпорация Майкрософт несет ответственность за создание пакетов с открытым кодом, которые мы развертываем в AKS. Эта ответственность включает полное управление процессами сборки, сканирования, подписывания, проверки и исправления ошибок, а также контроль над двоичными файлами в образах контейнеров. Для получения дополнительной информации см. Управление уязвимостями в AKS и Покрытие поддержки AKS.

Дополнительные сведения о Kueue и распространенных вариантах использования для администраторов и пользователей пакетной рабочей нагрузки см. в обзоре Kueue в AKS.

Предпосылки

Определение объекта ResourceFlavor

В Kueue ResourceFlavors обеспечивает детальное управление ресурсами путем связывания рабочих нагрузок с определенными узлами, таинтами, толерантностями или зонами доступности. Для узлов можно определить такие характеристики, как цены, доступность, бренды ResourceFlavors , модели и архитектура (то есть x86 и ЦП ARM). Эти ClusterQueue варианты используются для управления квотами и политиками допуска для рабочих нагрузок.

Эта конфигурация определяет ResourceFlavor без меток или параметров, известных как пустое ResourceFlavor. Эта конфигурация идеально подходит, если квотами для различных типов не нужно управлять.

  1. Создайте и сохраните ResourceFlavor в файл с именем resourceflavor-sample.yaml с использованием следующего манифеста:

    cat << EOF > resourceflavor-sample.yaml
apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
 name: on-demand
EOF

  2. apply

    kubectl apply -f resourceflavor-sample.yaml

  3. verify

    kubectl get resourceflavors

    Пример результата

    NAME        AGE
on-demand   5m32s

Создание ClusterQueue

ClusterQueue — это кластерный ресурс, который управляет пулом ресурсов, определяет ограничения использования и правила справедливого распределения. Если применимо, правила справедливого доступа позволяют другой очереди в кластерной группе в той же когорте использовать неиспользуемую квоту для ожидающих заданий. Каждый ClusterQueue указывает, какие варианты он поддерживает и сколько квот доступно для каждого.

Этот пример ClusterQueue определяет:

  • namespaceSelector: {}: указывает, что sample-jobs принимает рабочие нагрузки из любого пространства имен, ссылающегося на это ClusterQueue с помощью LocalQueue (можно ограничить использование (например, только пространство имен группы А) с помощью селектора меток.
  • coveredResources: ["cpu", "memory"] in resourceGroups: определяет стандартные типы ресурсов ЦП и памяти, управляемые этим ClusterQueueпараметром.
  • flavor on-demand узлов с 4 ЦП и 8Gi памятью: только запланированные рабочие нагрузки на on-demand узлах используют эту квоту. Если кластер исчерпает квоту, он не принимает другие нагрузки, использующие этот тип (если вы не разрешили заимствование из cohort).

  1. Создайте и сохраните Kueue ClusterQueue в файле с именем clusterqueue-sample.yaml со следующим манифестом.

    cat <<EOF > clusterqueue-sample.yaml
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: sample-jobs
spec:
   cohort: general
  namespaceSelector: {} # Accept workloads from any namespace
  resourceGroups:
   - coveredResources: ["cpu", "memory"]
     flavors:
       - name: on-demand
         resources:
           - name: "cpu"
             nominalQuota: 4
           - name: "memory"
             nominalQuota: 8Gi
EOF

  2. ClusterQueue Примените манифест с помощью kubectl apply команды.

    kubectl apply -f clusterqueue-sample.yaml

  3. Убедитесь, что манифест ClusterQueue был применён

    kubectl get clusterqueues

    Пример результата

    NAME          COHORT    PENDING WORKLOADS
sample-jobs   general   0

Замечание

ClusterQueue не готов к использованию до тех пор, пока объект ResourceFlavor не будет настроен. Если вы создаете ClusterQueue без какого-либо существующего ResourceFlavor, рабочие нагрузки, ссылающиеся на него, помечаются как Inadmissible.

Создание LocalQueue

LocalQueue — это ресурс, ограниченный областью пространства имен, который служит шлюзом для пользователей, отправляющих задания. Назначается LocalQueue одному ClusterQueue, из которого выделяются ресурсы для выполнения рабочих нагрузок.

В этом примере LocalQueue настроены следующие параметры:

  • Позволяет пользователям в batch-jobs пространстве имен отправлять пакетные рабочие нагрузки в Kueue.
  • Перенаправьте пакетные рабочие нагрузки в sample-jobsClusterQueue, которые управляют фактическими квотами вычислительных ресурсов и политиками планирования.

  1. Создайте пространство имен с именем пакетных заданий с помощью kubectl create команды.

    kubectl create ns batch-jobs

  2. Создайте и сохраните LocalQueue в файл с именем localqueue-sample.yaml со следующим YAML-манифестом:

    cat <<EOF > localqueue-sample.yaml
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  name: sample-queue
  namespace: batch-jobs
spec:
  clusterQueue: sample-jobs
EOF

  3. LocalQueue Примените манифест с помощью kubectl apply команды.

    kubectl apply -f localqueue-sample.yaml

  4. Убедитесь, что манифест LocalQueue был применен

    kubectl get localqueues --all-namespaces

    Пример вывода

    NAMESPACE    NAME           CLUSTERQUEUE   PENDING WORKLOADS   ADMITTED WORKLOADS
batch-jobs   sample-queue   sample-jobs    0                   0

Создание 2 пакетных заданий

Эта конфигурация определяет два пакетных задания Kubernetes, отправленные в пространство имен 'batch-jobs' и назначенные на очередь 'sample-queue', управляемую Kueue. Оба задания одноэкземплярные (параллелизм: 1, завершений: 1) и настроены с Never политикой перезапуска. Поля parallelism и completions управляют количеством подов и тем, когда задание считается завершенным. Поэтому parallelism и completions 1 означает, что один модуль pod может выполняться одновременно, и задание помечается как завершенное после успешного завершения одного модуля pod для каждого пакетного задания.

  • Тест задания пакетной службы 1: запрашивает один ЦП и 500Mi памяти.
  • Тестовый пакет задания 2: Запрашивает два ЦП и 1 Гибибайт памяти

  1. Создайте два примера пакетных заданий для развертывания в пространстве имен пакетных заданий с помощью следующего манифеста YAML:batch-workloads.yaml

    cat <<EOF > batch-workloads.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: test-batch-1
  namespace: batch-jobs
  labels:
    kueue.x-k8s.io/queue-name: sample-queue
spec:
  parallelism: 1
  completions: 1
  template:
    spec:
      containers:
        - name: dummy-job
          image: registry.k8s.io/e2e-test-images/agnhost:2.53
          command: ["sh", "-c", "echo Running test-batch-1; sleep 60"]
          resources:
            requests:
              cpu: "1"
              memory: "500Mi"
            limits:
              cpu: "1"
              memory: "500Mi"
      restartPolicy: Never
---
apiVersion: batch/v1
kind: Job
metadata:
  name: test-batch-2
  namespace: batch-jobs
  labels:
    kueue.x-k8s.io/queue-name: sample-queue
spec:
  parallelism: 1
  completions: 1
  template:
    spec:
      containers:
        - name: dummy-job
          image: registry.k8s.io/e2e-test-images/agnhost:2.53
          command: ["sh", "-c", "echo Waiting in queue for CPUs...; sleep 30"]
          resources:
            requests:
              cpu: "2"
              memory: "1Gi"
            limits:
              cpu: "2"
              memory: "1Gi"
      restartPolicy: Never
EOF

  2. Примените манифест для пакетных заданий с помощью kubectl apply команды.

    kubectl apply -f batch-workloads.yaml

Убедитесь, что пакетные задания отправляются в LocalQueue

  1. Просмотрите состояние пакетных рабочих нагрузок с помощью kubectl get команды.

    kubectl get workloads --namespace batch-jobs

    Пример результата

    NAME            ADMITTED    AGE
test-batch-1    True        10s
test-batch-2    False       5s

  2. Следующую команду test-batch-2 выполните, пока она находится в состоянии Pending

    kubectl get workloads test-batch-2 -o yaml

    Ожидаемые выходные данные

    ...
...
Status:
  Conditions:
    Type:              Admitted
    Status:            False
    Reason:            QuotaUnavailable
    Message:           Insufficient quota in ClusterQueue sample-jobs 
    (flavor on-demand): requested 2 CPUs, available 1
...
...

    После завершения test-batch-1, test-batch-2 будет выполнено и запущено.

    Теперь выходные данные должны выглядеть следующим образом:

    Status:
  Conditions:
    Type:              Admitted
    Status:            True
    Last Transition Time:  1234-56-78T00:00:00Z
  Admission:
    ClusterQueue:      sample-jobs
    PodSetAssignments:
      Name:            main
      Flavors:
        cpu:           on-demand
        memory:        on-demand
      ResourceUsage:
        cpu:           2
        memory:        1Gi

  3. Просмотрите окончательное состояние batch-jobs пространства имен с помощью kubectl get команды.

    kubectl get job,deploy,rs,pod,workload --namespace batch-jobs

    Пример результата

    NAME                     STATUS     COMPLETIONS   DURATION   AGE
job.batch/test-batch-1   Complete   1/1           97s        3m15s
job.batch/test-batch-2   Complete   1/1           35s        3m15s

NAME                     READY   STATUS      RESTARTS   AGE
pod/test-batch-1-hb8zl   0/1     Completed   0          3m15s
pod/test-batch-2-dx9hk   0/1     Completed   0          3m15s

NAME                                             QUEUE          RESERVED IN   ADMITTED   FINISHED   AGE
workload.kueue.x-k8s.io/job-test-batch-1-6fb85   sample-queue   sample-jobs   True       True       3m15s
workload.kueue.x-k8s.io/job-test-batch-2-84f49   sample-queue   sample-jobs   True       True       3m15s

Часто задаваемые вопросы

Вопрос 1. Как убедиться, что контроллер Kueue доступен и работает должным образом?

  1. Убедитесь, что модуль pod диспетчера контроллеров Kueue выполняется с помощью kubectl get команды.

    kubectl get pods --namespace kueue-system

    Модуль pod менеджера контроллеров Kueue должен находиться в Running состоянии с 1/1 готовыми контейнерами, например, это отображается в следующем образце результата.

    NAME                                                 READY   STATUS      RESTARTS    AGE
kueue-controller-manager-xxxxxxx    1/1        Running     0                  2m

  2. Status Если отображается CrashLoopBackOff или Pending, проверьте журналы развертывания с помощью команды kubectl logs.

    kubectl logs --namespace kueue-system deployment/kueue-controller-manager

Вопрос 2. Один или несколько пользовательских ресурсов Kueue (CRD) отсутствуют при установке через Helm. Как проверить, что установлены все CRD?

  1. После установки Kueue согласно руководству «Обзор Kueue на AKS», убедитесь, что все CRD установлены, используя команду .

    kubectl get crds | grep kueue

    Эти CRD должны быть перечислены, как показано в следующем примере результатов.

    admissionchecks.kueue.x-k8s.io
clusterqueues.kueue.x-k8s.io
cohorts.kueue.x-k8s.io
localqueues.kueue.x-k8s.io
multikueueclusters.kueue.x-k8s.io
multikueueconfigs.kueue.x-k8s.io
provisioningrequestconfigs.kueue.x-k8s.io
resourceflavors.kueue.x-k8s.io
topologies.kueue.x-k8s.io
workloadpriorityclasses.kueue.x-k8s.io
workloads.kueue.x-k8s.io

  2. Если один или несколько CRDs отсутствуют, могут возникнуть ошибки в журналах контроллера, сбой в очереди заданий, CrashLoopBackOff для контроллера или невозможность принять или запланировать рабочие нагрузки. В этом случае можно вручную переустановить CRD Kueue с помощью kubectl apply команды.

    kubectl apply -f https://github.com/kubernetes-sigs/kueue/releases/latest/download/kueue-crds.yaml

    Замечание

    Обратите внимание, что при ручной установке CRD необходимо вручную удалить их после завершения работы с помощью kubectl delete команды.

Вопрос 3. Разница между LocalQueue и ClusterQueue

ClusterQueue — это кластеризованный ресурс, который определяет и управляет пулом вычислительных ресурсов, таких как ЦП, память, модули pod и акселераторы во всем кластере Kubernetes. LocalQueue — это ресурс в пределах пространства имен, который выступает в качестве шлюза, позволяющего пользователям отправлять задания в определенном кластере Kubernetes. Это разделение позволяет точно контролировать управление ресурсами и планирование в многопользовательской среде без предоставления квот на уровне кластера напрямую пользователям.

Как они работают вместе:

  1. Пользователь отправляет задание в LocalQueue в своем пространстве имен.
  2. Kueue перенаправляет задание в упоминаемую ссылку ClusterQueue.
  3. ClusterQueue проверяет доступность ресурсов и ограничения квот.
  4. Если допущено, задание возобновляется и планируется.

Дальнейшие шаги

В этой статье вы:

  • Установили Kueue в кластере Azure Kubernetes Service (AKS) с помощью Helm и проверили CRDs, работоспособность контроллера и настройку пространства имен.
  • Настроены ClusterQueue и LocalQueue для рабочих нагрузок общего назначения с квотами ресурсов и типами ресурсов (например, по требованию).
  • Отправлены два пакетных задания для демонстрации очереди: одно принято немедленно, второе задержано из-за квотных ограничений, а затем принято, когда ресурсы стали доступными.
  • Отслеживались состояние рабочей нагрузки и журналы контроллера для подтверждения поведения при планировании и логики очередей.

Дополнительные сведения о Kueue см. в следующих ресурсах:

  • Last updated on