Координатор

Координатор ожидает подключения сборщиков и учащихся (агрегатор и его несколько DDP-учащихся рассматриваются как логический учащийся), а затем начинает выдавать задачи для начала обучения.

Мы можем вручную отправить запрос на di-сервер, чтобы добавить или удалить сборщики или учащиеся, и координатор будет периодически запрашивать количество доступных сборщиков и учащихся и принимать решение о создании или отключении подключений к ним.

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

Di-оператор

Di-оператор — это компонент, отвечающий за управление DIJob в K8s. Он использует шаблон оператора Kubernetes для мониторинга состояния объектов DIJob в кластере Kubernetes через цикл управления в шаблоне контроллера и для обновления статуса DIJob при необходимости. Статус изменяется таким образом, чтобы фактическое состояние DIJob максимально соответствовало нашему предопределённому статусу.

Определение API

В соответствии с характеристиками каждого модуля мы определили два пользовательских ресурса: DIJob и AggregatorConfig. Первый используется для определения предварительных условий для запуска координатора, сборщика и учащегося, включая образы Docker, команды запуска, вычислительные и запоминающие ресурсы, переменные среды и т. д. Второй используется для определения предварительных условий для агрегатора.

Определение DIJob описывается следующим образом:

type DIJobSpec struct {
    // Group — это коллекция DIJobs
    Group string `json:"group,omitempty"`

    // Priority labels the priority of DIJob
    PriorityClassName PriorityClassName `json:"priorityClassName,omitempty"`

    // CleanPodPolicy определяет политику очистки модулей после завершения DIJob
    CleanPodPolicy CleanPodPolicy `json:"cleanPodPolicy,omitempty"`

    // Volumes определяет общие тома для компонентов DI-engine
    Volumes []corev1.Volume `json:"volumes,omitempty"`

    Coordinator CoordinatorSpec `json:"coordinator"`

    Collector CollectorSpec `json:"collector,"`

    Learner LearnerSpec `json:"learner,"`
}

Определение AggregatorConfig описывается следующим образом:

type AggregatorConfigSpec struct {
    Aggregator AggregatorSpec `json:"aggregator,"`
}

Почему агрегатор должен быть определён отдельно?

Агрегатор является общим модулем для всех RL-тренировочных заданий, использующих фреймворк DI-engine, поэтому мы определяем агрегатор как глобальный и общий ресурс под названием AggregatorConfig. После отправки RL-заданий di-server будет считывать глобальный AggregatorConfig в кластере K8s для создания агрегаторов для этих RL-заданий. Кроме того, агрегатор предназначен только для наиболее распространённого параллельного обучения данных. Вам необходимо определить новый пользовательский ресурс, если используются другие методы параллельного обучения.

Определение статуса

После отправки DIJob di-operator берёт на себя управление жизненным циклом DIJob. Чтобы облегчить пользователю просмотр статуса DIJob, мы определяем следующие этапы:

const (
    // JobCreated означает, что задание было отправлено в кластер,
    // но не все модули и службы были созданы,
    // или ни один модуль не работает
    JobCreated Phase = "Created"

    // JobRunning означает, что все модули находятся в рабочем состоянии
    JobRunning Phase = "Running"

    // JobSucceeded означает, что задание выполнено без ошибок
    JobSucceeded Phase = "Succeeded"

    // JobFailed означает, что некоторые модули вышли из строя, задание также считается неудачным
    JobFailed Phase = "Failed"

    // JobUnknown означает, что задание находится в неизвестном состоянии
    JobUnknown Phase = "Unknown"
)

Нормальный DIJob, который запускается и успешно завершается, проходит три этапа: Создан, Выполняется и Успешно выполнен:

• Когда DIJob отправляется, di-operator переходит в фазу Создан после создания координатора.

• Когда модуль координатора находится... В фазе «Running» DIJob переходит в фазу «Running».

• Когда модуль координатора находится в фазе «Completed», DIJob переходит в фазу «Succeeded».

Кроме того, когда модуль координатора находится в фазе «Failed», DIJob также переходит в фазу «Failed». Агрегаторы, сборщики и обучающиеся перезапускаются сразу после сбоя, но они не влияют на фазу DIJob.

Неизвестная фаза не была определена.

Контрольный цикл

Построенный на основе kubebuilder v3 (https://github.com/kubernetes-sigs/kubebuilder/releases/download/v3.0.0/kubebuilder_linux_amd64), компоненты, такие как отражатели, информеры, индексаторы (https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md) и контроллеры, необходимые оператору, все заключены в менеджер (https://github.com/kubernetes-sigs/controller-runtime/blob/master/pkg/manager/manager.go) контроллера-среды выполнения. Kubebuilder предоставляет нам только общую функцию с именем Reconcile для реализации логики согласования для DIJob.

func (r *DIJobReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    // ваша логика согласования здесь
    return ctrl.Result{}, nil
}

Когда DIJob отправляется, мы сначала перечисляем модули, которые принадлежат DIJob, в функции согласования и обнаруживаем, что координатор не был создан. Затем мы читаем шаблон координатора, определённый в DIJob, и создаём соответствующий модуль координатора (используется для запуска основного процесса координатора) и службу (используется для межмодульного взаимодействия), а также записываем некоторые переменные среды в модуль, включая имя модуля, пространство имён модуля, порт, который слушает координатор, и URL для доступа к координатору.

Порт, занимаемый каждым модулем фреймворка DI-engine, имеет значение по умолчанию, как показано ниже:

DefaultCollectorPort   = 22270
DefaultLearnerPort     = 22271
DefaultAggregatorPort  = 22272
DefaultCoordinatorPort = 22273

После создания координатора di-operator будет отслеживать состояние модуля и изменять статус DIJob. После завершения DIJob (успешно или неудачно) di-operator удалит все службы DIJob и все модули, находящиеся в фазе выполнения DIJob по умолчанию.

Вебхук

Могут быть некоторые ошибки при отправке DIJob, такие как орфографические ошибки в полях DIJob, несоответствие значения поля предопределённому и т. д., что приводит к потенциальным ошибкам при управлении жизненным циклом DIJob. С другой стороны, необходимо установить значения по умолчанию для некоторых полей DIJob. Если значение по умолчанию DIJob может быть установлено до отправки DIJob, и проверка правильности может быть выполнена, это поможет нам заранее обнаружить проблемы.

Чтобы достичь вышеуказанных целей, мы можем настроить вебхуки в K8s. Вебхук K8s состоит из MutatingWebhook и ValidatingWebhook. Первый используется для изменения значения объекта ресурса K8s, а второй — для проверки правильности объекта ресурса K8s.

Проверка вебхука реализована в di-operator. MutatingWebhook создан для установки значения по умолчанию для DIJob; ValidatingWebhook создан для проверки правильности DIJob. Например, для поля CleanPodPolicy в DIJob мы устанавливаем его значение по умолчанию в MutatingWebhook равным Running, что означает, что все запущенные модули будут удалены после завершения DIJob. Мы проверяем значение поля CleanPodPolicy в ValidatingWebhook, если значение, установленное пользователем, не равно ни одному из None, ALL или Running, то DIJob будет отклонён.

DI Server

Di-server — это http-сервер, настроенный для фреймворка DI-engine, предоставляющий API для добавления, удаления и запроса сборщиков, обучающихся и агрегаторов. Вызывая соответствующие API di-сервера, di-сервер может предоставить DIJob возможность динамического масштабирования сборщиков и обучающихся. Ниже кратко описывается дизайн di-сервера, включая локальный кэш для хранения AggregatorConfig, DIJob и всех модулей DIJob; дизайн интерфейса http для динамического добавления, удаления и запроса сборщиков, обучающихся и агрегаторов. Предоставляет интерфейсы HTTP, чтобы мы могли динамически регулировать количество сборщиков и учеников. Это позволяет DIJob адаптировать соотношение сборщиков и учеников в соответствии со своими потребностями для оптимизации пропускной способности.